8476 位用户此时在线
- 本站自动实时分享网络热点
- 24小时实时更新
- 所有言论不代表本站态度
- 欢迎对信息踊跃评论评分
- 评分越高，信息越新，排列越靠前
这篇访谈挺值得听听的。
里面有一句话给我印象挺深刻：“做对一千件小事，比做对三件大事更重要”。
熟悉苦涩的教训《The Bitter Lesson》的应该能理解这句话的含义。
> AI 研究的历史反复证明，那些依赖人类精心设计的规则和知识的方法，最终都会被更简单粗暴能更好利用算力进行通用学习的方法打败。
IT技术
(
twitter.com
)
这篇访谈挺值得听听的。
里面有一句话给我印象挺深刻：“做对一千件小事，比做对三件大事更重要”。
熟悉苦涩的教训《The Bitter Lesson》的应该能理解这句话的含义。
> AI 研究的历史反复证明，那些依赖人类精心设计的规则和知识的方法，最终都会被更简单粗暴能更好利用算力进行通用学习的方法打败。
换句话说，与其让人类专家花大力气设计聪明的规则，不如让机器自己去学。
Peak 把这个道理翻译成一句话：做对一千件小事，比做对三件大事更重要。
《The Bitter Lesson》应该也深刻影响了 Manus 团队在 Agent 设计上做出的选择。
现在市面上的 Agent 产品，大致可以分成两类。
一类是“规则主导”的 Agent。开发者提前设计好工作流程：第一步做什么，第二步做什么，遇到什么情况走哪个分支。这种 Agent 的好处是可控、可预测，坏处是只能处理设计者预见到的情况。
另一类是“智能主导”的 Agent。不预设具体流程，让模型自己判断每一步该怎么走。这种 Agent 的好处是灵活、能处理意外情况，坏处是不够稳定，有时候会犯蠢。
Manus 选择的是后者。
Peak 在播客中解释这个选择时说，规则主导的 Agent Workflow 在可复现性上确实表现更好。同样的输入，每次都能得到差不多的输出。但他认为这个问题是可以解决的，而规则主导的天花板问题是解决不了的——你永远没办法提前预见用户会遇到的所有情况。
Manus 怎么做到“不设规则”的？
Peak 举了一个例子。大部分互联网服务并没有接入 MCP。如果 Manus 只能用 MCP，那能干的事情就很有限。
Manus 的策略是做降级处理。如果有 MCP 接入，直接用。如果没有 MCP 但有 API 文档，Manus 会自己去读文档，学会怎么调用这个 API。如果连 API 都没有，只要这个服务有网页界面，Manus 就用浏览器模拟人类的操作方式来使用它。
这意味着，开发者不需要专门为 Manus 做任何适配。只要一个服务是给人用的，Manus 就能想办法用上。
“它没有人为设定的约束，完成任务的所有过程和方式，都由智能本身决定。”
这就是“做对一千件小事”的含义。不是提前设计三条聪明的规则，而是让系统在面对一千种不同情况时，每次都能做出还算合理的判断。单看每一次判断，可能都不完美；但整体叠加起来，能处理的问题范围就远超任何规则系统。
这个选择背后是相信模型能力会持续变强。
如果模型能力停滞不前，那“智能主导”的路线就很危险。模型犯蠢的概率不会下降，用户体验永远不稳定。
但如果模型能力持续提升，这条路线的天花板就会不断抬高。今天模型可能在某些任务上判断失误，明天换一个更强的模型，同样的代码就能做对更多事情。
Peak 说，对 Manus 这样的应用公司来说，所有外部的模型创新都是养料和供给。他们不需要参与“模型大乐透”，不用押注哪家模型公司会赢。谁进步了，他们就受益。
这也是为什么 Manus 选择不自己训模型。他们把精力花在“怎么更好地使用模型”上，而不是“怎么训出更好的模型”。后者需要巨大的资源投入，而且有可能押错方向；前者的风险小得多，只要整个行业在进步，他们就能跟着进步。
另外 Manus 团队在 Agent 上的摸索，确实是业界顶级的，而且他们会选择将摸索出来的经验分享出来。比如那篇《AI 智能体的上下文工程：构建 Manus 的经验教训》我就看了很多遍，还有后来那篇和 LangChain 一起做的《Context Engineering for AI Agents with LangChain and Manus》分享，也特别好。
所以 Peak 说当他们读到一些模型公司发布的研究博客时，心情是“既开心又无奈”。开心是因为这些博客验证了他们的方向，无奈是因为博客里写的东西，基本都是他们早就在做的。
比如 Anthropic 提出的“thinking tool”概念，是在 Manus 上线一个月后才发布的。还有用代码方式调用 MCP、渐进式披露信息这些做法，Manus 也早就在用了。
这些 Agent 上摸索出来的经验，你要说创新也算不上多大，更多是一个个具体的工程细节。单拎出来看，每一个都不起眼，但叠加在一起，就构成了产品的核心竞争力。
Peak 把这种方法论总结为：做对一千件小事，比做对三件大事更重要。
三件大事可能是：设计一个天才的架构，发明一个突破性的算法，或者抢先拿到某个独家资源。这些事情如果能做成，当然很厉害，但风险也很高，而且往往不可复制。
一千件小事是：在每一个具体场景里做出合理的判断，处理好每一个边界情况，让每一次用户交互都顺畅一点点。这些事情每一件都不难，但需要耐心和积累，而且门槛会随着积累越来越高。
很多人觉得 Manus 不过是“套壳”，但你要真去做一个 Manus 出来，就会发现这个壳里藏着一千个细节：怎么让模型长时间保持注意力、怎么压缩和恢复记忆、怎么在没有 API 的时候优雅降级、怎么节约 Token 成本、怎么处理各种意想不到的边界情况。每一个细节都不算什么大发明，但每一个都要做对。
这可能就是“套壳”的门槛所在，不在于壳本身，在于壳里那一千件小事。
点击图片查看原图