链载Ai

标题: 深读 Manus：寻找 Agent 产品的“品味”与“定力” [打印本页]
作者: 链载Ai    时间: 6 小时前
标题: 深读 Manus：寻找 Agent 产品的“品味”与“定力”

一晃有 3 个月没有更新了，今天正好是 26 年的第一天，听了个非常精彩的播客，终于又激发起一些分享和表达的欲望。

这个播客是来自于张小珺商业访谈录的对 Manus 首席科学家 Peak 的访谈[1]，我对其评价为 25 年最棒的一期播客，Peak 的技术深度，对产品与商业的理解，表达能力等，在我看来不亚于李沐、Andrej Karpathy 等顶级大佬。尤其是在如今顶级实验室日益“封闭”、工业界 Paper 产出渐少的背景下，Manus 团队这种开放分享的精神显得尤为难能可贵。最近一年的确反倒是从很多中国科技从业者的分享中学到了很多，包括 DeepSeek，Kimi，Manus 等，不仅有实打实的技术创新，也有开放分享的自信，必须给他们点赞！

下面还是按惯例，摘录一些我在收听过程中的笔记，并附带上一些我的思考和感想。

手机浏览器创业

Peak 觉得浏览器市场不太适合创业者以一种颠覆者的姿态来做，而更适合巨头有了分发渠道之后，去锦上添花的一件事。例子就是历史上只有 2 次大规模的浏览器市场份额转变，一次是微软通过预装 IE 干掉了 Netscape，另一次是谷歌在搜索引擎成为老大的基础上，趁着 IE 的各种技术问题，推出了 Chrome。

在后面 Manus 做 AI 浏览器的过程中，这部分的经历和思考有进一步的加深。

创业做 Magi 搜索

目标是通过知识图谱为用户提供更好的搜索体验（接近问答）。当时知识图谱最大的问题在于需要大量的人工建设与维护，所以他们想使用 NLP 技术来做自动化的图谱构建。这是一个很好的 The Bitter Lesson 的真实案例，从人工定义和维护，到利用 NLP “小”模型来自动抽取和维护，再到 GPT 这样的通用大模型出来达到接近的效果，可以说人类植入先验是越来越少的，但效果和能力却在不断提升。

Peak 提到的另外很重要的一点是，当时他们是同时做模型训练和产品迭代，但是发现模型的开发，训练，eval 和部署等，都需要花很多精力投入，最多也只能做到 2-3 周迭代一个版本。这样的话产品那边就需要“等”模型的迭代，拖慢了速度；更可怕的是，模型层面的创新也是日新月异，抱着“旧架构”和流水线训练出来的模型，可能会被新的模型技术快速抹平优势。这听起来是不是一种非常熟悉的场景？但现在我的体感是，仍然有 80% 的人可能会觉得，如果你不自己训练模型，那么就是“没有技术的套壳”。

在商业上的一些反思：

  1. 从头写一个搜索引擎的决定：不能只看到技术层面的东西，谷歌积累了 20 多年，有很多非技术层面的因素导致了你很难去挑战它。
  2. 一开始做问答搜索的出发点是来自于对可穿戴设备或新的人机交互形式普及的假设，但这部分的进展显然低于预期了。
  3. 商业化也没有想得很清楚，一开始想做 to C，后来转做 to B 但团队也没有这方面的基因。

职业路径选择

在两次创业之后有一段探索期，Peak 也分享了他对于事业方向选择的一些思考。一些比较有意思的点：

  1. 认识自己，比如他很早就发现自己不适合做 CEO/一号位。听从自己的内心，做自己擅长的事，放下 ego 和攀比心态其实挺好的，减少了很多不必要的内耗。
  2. 在大模型领域发展的早期，更应该选择一个产品还没有定型，可以自由探索的“画布”的方向。就有点像这个产品本身做出来可能有些 PMF，但却有很大的潜力去变换它的形态。所以像成熟产品里外挂一个 copilot，把 LLM 当成一个非常垂直功能的增强，就不是他想考虑的方向。

加入 Monica

沿着上面一点聊到了浏览器插件的绝妙之处，首先它没有改变用户日常习惯，因此是一个非常好的“观察”用户会如何使用 AI 的窗口。另外在插件上叠加新功能，不会让产品变得更复杂（更多界面和按钮），而是自动随着网页 context 的变化加载相关的能力。相信很多做 to B 产品的同学对这个复杂度爆炸的问题都深有体会。

判断一个好 CEO 的标准：身心健康，相信常识，相信团队。哈哈，说起来我们观远不敢说认知有多领先，但务实这一个特质可能还是我们比较有底气的地方。

当前的 AI 产品创业，因为有 token 消耗的存在，更像是“制造业”，如果没有优化的话，会随用户规模线性增长，因此对于经营的操作能力的要求会比之前移动互联网时代的产品创业会高很多。所以对于单位经济模型的考虑与优化可能需要更早开始。

什么是品味？听到这个问题当时我还特地暂停问了下自己，我的第一反应是，对于事物应该是如何运作的直觉的好坏。比如软件工程中的一个功能，最自然的划分是 A 模块负责还是 B 模块负责，比如一个 Agent 可以用的工具应该有哪些，sub agents 之间是如何划分与协作的，比如看到 MCP 的第一反应是什么等等……

Peak 给出的回答更加具体，就是体现在公司内部的 evaluation/benchmark 上。的确这在很大程度上决定了产品的方向。如果泛化到对员工的评估，那也会很大程度上塑造公司的文化。OpenAI 的研究员之前也在 X 上分享过，团队的 lead 都会花很多时间在写 eval 上。

为什么不去大模型公司？做大模型也挺痛苦的，如果你的模型不是 SoTA 那可能没有什么意义，但现在 SoTA 模型的保质期只有 1 到 1 个半月。加上都是通用大模型，所以很少有差异化竞争腾挪的空间。

模型与应用的关系

未来可能很快不会区分模型公司和应用公司。这是之前行业中分歧很大的一个话题，有很多人觉得“模型即产品”，也有很多人会说，模型只是“缸中大脑”，没有脚手架无法完成任何实际的工作。但的确行业中的头部公司已经给了我们很好的答案：

所以 Peak 总结说这其实是个先后问题，最好的思路是先做产品（对应到前面的，同时做模型会拖慢迭代速度），在达到一定 PMF、用户量级和产品稳定性后，再根据你的诉求，如降低成本，提速，增加稳定性，突破垂直领域天花板等角度，去针对性训练自己的模型。

我们在实践过程中获得的认知也非常一致：

AI 浏览器

复盘了他们团队的 AI 浏览器开发历程，极其精彩。为什么要做 AI 浏览器？通过 Monica，他们觉得自己已经是全球最懂用户怎么在浏览器中使用 AI 的团队了。然后分析一下 Chrome 应用市场的顶级插件安装量，如 AdBlock，Grammarly 等，也只有 5000 万的量级，相比 Chrome 20 亿的日活来说还是太低了。所以一个很自然的思路就是做一款 AI 浏览器，去突破这个天花板。

他们踩的第一个坑是，想引入一个端侧模型，这样既没有 API 消耗，还能尊重用户数据隐私。但实际上的情况是，你做的是一个浏览器，天然就是联网的；另外也发现用户对于智能的诉求要远高于“数据安全”的诉求。当前能在 Apple Silicon 上跑起来的模型基本也只有 3B 大小（应该是普通 Mac 的测算），这相比模型厂商的顶级模型来说差距有点大。既然用户在用浏览器完成任务，那说明他的数据其实已经“上云”了，这跟把数据发给模型厂商的 API 其实没什么区别。

第二个坑是使用场景上，大家都想做的是让 agent 接管用户电脑来完成一些操作。这里的一个悖论是，如果是一个简单的点外卖任务，用户可能觉得价值不大，如果是一个价值比较大的“长程”任务，agent 又需要“占用”电脑很久。在这期间，用户不能用电脑做别的事情，也不能让电脑锁屏或休眠，这个体验就非常奇怪。

最大的灵魂拷问是，当做了这个 AI 浏览器之后，有什么是 Chrome + Monica 插件做不到的？他们想了很久发现好像也并没有。The Browser Company 停止 Arc 浏览器开发时说了一句：我做 Arc 浏览器这么久，甚至无法说服我的亲朋好友从 Chrome 换成 Arc。这也印证了他们的担忧，也呼应了 Peak 之前做浏览器时形成的那种创业公司难以颠覆巨头的感觉。

所以即使付出了公司几个月的时间和精力，他们还是决定不发布这个产品。有些人可能会觉得，做都做了，发布出来试试也行啊。但他们觉得，作为一个负责任的团队，产品一旦发布肯定需要进行持续维护，就可能损失更大的机会成本。这个问题在 to B 领域可能会更加严重，而且往往除了技术团队外对这个持续维护的成本感知并不明显。Manus 团队能够达成这样的共识，作出这个勇敢的决定，很令人钦佩。

这里也非常好奇其它做 AI 浏览器产品的团队是如何看待这个问题的？

另外一点值得一提，他们公司当时是有 Monica 这个产品在持续盈利的，因此做决策时就能有足够的理性思考和安全感。所以其它初创公司也不要随便模仿，看到 DeepSeek 这么有理想，豆包这么豪气，就照着学……人家背后可是有其它业务充足的现金流在支撑的。

公司决策逻辑

中间穿插介绍了他们的几位合伙人，和共同的优秀特质，比如都在各自领域有比较深入的积累，同时又能听得进去别人的话。这里比较有意思的是关于公司决策机制的一个分享，Peak 把决策分成 3 个阶段，不同阶段有不一样的处理方式：

这部分也深有体会，对于 AI 产品这么新的东西，大家各自都有不一样的认知和信息来源很正常，所以在方案收集的时候一定要集思广益。但我们也会发现，通过纯“理性”的探讨，很多时候也不可能达成完全一致，这时候“与其悬而未决，不如赶紧试试”。就跟模型 ReAct 一样，reason 和 act 最好是交替进行，一直 reason 收益可能也不大。

产品和技术的话语权问题，首先明确技术是要服务于产品的，但技术对于很多事情有一票否决权。比如是否要放弃“纯血 agent”的想法。

应该基于共同的目标去达成共识，而不是搞投票，容易变成为各自的观点服务，异化团队。

打造 Manus

产品 idea 的来源：看到公司有很多非技术背景的同事在用 Cursor 完成一些日常工作，意识到编程不是一个垂直能力，它是一个通用能力，而拓展到通用场景，Cursor 可能就不是一个很好的形态。结合他们之前的经验，有几个具体的改进点：

最后这一点也很有同感，找准目标用户非常重要。比如我们做 Data Agent，要找的用户也不是企业高管，虽然看起来他们的问数、洞察、决策的价值很高，但他们往往提出的问题更加复杂和综合，对于 agent 的理解能力，底层数据基建的完善程度都有更高的要求。更加关键的是，我们的 agent 产品很可能是在跟之前的高管专属分析师竞争，这在用户体验上几乎就没有什么胜算。更加理想的用户群体反而是那些之前有基于数据做决策，但却没有很好被服务的群体。

他们在发布时机上也做了个有意思的选择，Manus 产品其实在 25 年 1 月就完成了，但他们决定等到 Sonnet 3.7 发布的时候再发布产品，以获得最大的一个智能代际提升。

这个选择也非常机智。当年 Cursor 并没有用类似的方式，但的确是因为 Sonnet 3.5 的发布而逐渐开始走红。到了 agent 类产品开始多起来了之后，我观察到产品的“第一印象”开始变得越来越重要。以前产品少的时候，我可能时不时就把同样的任务交给不同的模型做一做比较一下效果。但产品选择太多之后，很多人是没有这个精力再去持续做这种对比的。所以很天然的做法是拿几个当前的问题测试一遍产品（或者有新产品推出时），找出表现最好的，然后就会有一段时间会锁定这少数几个产品来使用。如果你能在模型升级的时候同步推出，那的确可能因为用上新模型之后的优势窗口期而给用户留下一个好印象，从而提升转化率。

过程中的“下注”

第一个重要的下注是，相信通用 agent 这个产品能做出来。的确开创了一个品类还是很有意义的。而且他们也是以一种非常务实的渐进加码的方式来寻找这个第二曲线。

第二个下注，不训练模型。虽然当时模型在 agentic 任务上表现并不好，但仍然相信模型能力的提升，把重点放在 context engineering 上。

第三个下注，不做中国版的 Cursor，而是面向 prosumer 做一个创新的产品。

AI 时代产能的放大，让“不做什么”这个选择更加重要。Peak 举了个例子，很多产品都会想着给 agent 增加更多的 tool，而他们每个月都在想着可以删掉哪些工具。

这也是我观察到的 AI 时代开发产品的一个很有意思的新特点，以往我们主要出于技术债管理，架构优化等方面的诉求去删除代码，而现在，你完全可以通过删除代码去提升 agent 的能力上限。

为什么做通用 agent

很多创业相关的课程都会建议新产品都要找一个非常垂直的领域，先切入市场去找到 PMF，再慢慢深化价值或拓展场景。但 Manus 为什么从一开始就定位成通用 agent？

从技术层面思考，Peak 的上一次创业经历了专有模型被通用模型吃掉的过程。当前的 agent 领域创业，即使做的是一个垂直场景，底层使用的仍然是一个通用大模型。另外 Manus 的本质就是一个通用大模型加上一台虚拟机，这台虚拟机是图灵完备的，理论上可以去做任何模拟或者运行任何算法。既然底层的两个最主要的技术供给是通用的，那么做垂直其实是在上面做了约束。

这一点可能很多人会不太同意，最常见的反对是，我针对一个场景来设计和优化，可以做到更快、更稳定、效果更好。但在我们自己的实践过程中，也找到过很多反例，当你想把毕生绝学传授给 agent，把 prompt 写得非常细节和具体，给它一些精心设计的垂直工具/DSL，根据人类的组织形式设计多 agent 架构，会在很多 case 上大大限制住 agent 的主动探索、发挥的空间，导致最终的效果不理想。尤其是在环境变化快，任务流程长（端到端交付）的场景中，更要注意不要拖 agent 后腿。

第二点思考呼应上面所说的，想要给用户一个可以自由探索的“画布/容器”型的产品，以一种类似达尔文的心态观察用户整体的行为模式，去捕获到头部的场景。然后他们再针对这些场景去做最后一公里的优化。比如他们观察到用户喜欢做 ppt，做网页，做批量文件处理，然后他们再介入去做一些定向优化。

这里的思考是另外一种 The Bitter Lesson 的应用，不是先入为主去定义，用户想要这个，用户想要那个，而是交给大量行为数据，去自动涌现出应该优化哪些方向，跟早年的门户网站与搜索引擎的区别有点类似。

通用性还有很多好处，比如更能让长尾的需求得到满足，甚至收获惊喜。这里的长尾也有两个维度：

意识到这个问题，Manus 在设计上会坚持一个统一的 agent 框架，因此用户在 Manus 中进行不同任务时，他的上下文、记忆是可以自由流转的。

有一些其它产品看起来也强调“通用”，但背后的设计可能是针对各个场景分别开发一个垂直 agent，然后包在一起可以让用户自由选择，更像是门户网站的模式。

使用统一 agent 框架的好处在于：

通用 agent 的几个要素讨论

环境

Manus 使用的是基于 Firecracker 的虚拟机，而不是 container，主要带来的好处是不光可以跑 Linux，还可以跑 Windows，这样支持的专业软件范围就更广了。

Wide Research，由于模型 context window 的限制，加上模型偷懒等问题，对于很多需要重复执行的任务，很多 agent 都会失败。通过 scale out 虚拟机的方式，可以启动成百上千的 sub agents 来完成这类大规模的并行 research 任务。

Tool call 的拓展，虚拟机的预装软件/工具等可以进一步拓展 Manus 的动作空间。这部分在 Manus 之前的分享中有提到过，现在也越来越成为一种业界主流思想。比如 OpenAI 官方的 tool call 演示是给了个get_weather的工具，但这个其实是挺低效的一种做法。目前更流行的是直接给 agent 一系列非常通用的工具，比如write_file，bash等，然后 agent 就能通过写一段代码，再用命令行执行的方式，来实现广泛的任务。而其中一些高频的功能，就可以考虑做成预装工具放在虚拟机中方便 agent 直接调用。这个思路在 agent skills，MCP 的 code mode 中都有所体现。

模型

Manus 的 token 消耗量在各个模型厂商应该都是全球 Top 2-5 的水平，估计这里主要指的是御三家（OpenAI，Anthropic，Gemini）。当你的产品和用量都有足够的影响力时，你的需求是能够影响模型发展的，这也是挺有意思的一点。

在如此大的用量基础上，Manus 仍然通过很多技术优化，做到快要能通过用户的订阅收入来覆盖 token 成本了。偏应用的公司看起来会比较有动力做这方面的优化，比如 Claude Code 和 Codex 的套餐，基本上都是“亏本”售卖的，20 美元的订阅费可以用到上百美元的 token 量。反观 Cursor 这类公司，在上下文工程和成本优化上就有更多的投入，实际使用下来感觉明显是更节约 token 的。这里也是个非共识的问题，到底是“摩尔定律”会使得 token 使用量的优化收益呈指数下降，还是用户会持续追求“最贵”的模型，agent 会持续通过消耗更多 context length 来达到更好的效果？

典型 chatbot 应用的输入输出 token 比大概是 3:1，而 Manus 这种 agent 的比例是 100:1 到 1000:1。假设 output 长度差不多的话，agent 应用的 token 消耗量大概是 chatbot 的几十到上百倍。在这个背景下，Manus 的选择仍然是“智能优先”，优化成本和速度是第二位的。

对于模型层的优化，Manus 目前并不是自己做，而是“外包”出去给模型原厂做。比如帮助模型厂商构建一些 evaluation，以及一些 feature 的 proposal 等。对于模型厂商来说，应该也比较乐意服务这类 token 消耗的超级大户的，感觉上他们自家做的产品在 token 费用上的补贴都比较高，从毛利上来说应该不如卖 API 的生意。

目前模型层比较大的问题是，大部分的模型仍然是为 chatbot 去做的 alignment。无论用户的问题多么复杂，模型都会倾向于在一轮交互中去完成回答。而 agent 的典型范式是 ReAct 的形式，在一个循环中不断基于外部环境的输入去决定下一步的动作，这是一个很有耐心的逐步尝试的过程，与 chatbot 的交互形式区别很大。虽然在模型训练的数据中肯定也包含了 agentic task 的轨迹数据，但这部分的数据仍然是比较小的比例。因此我们在实际使用过程中就会观察到：

也正是由于这些原因，在实际工作中我们比较少会用到非常长的 context（比如超过 128K），通常都会使用 context engineering 或产品设计的方式，来保持一个相对比较短的 context window 占用。

模型的另一个问题是没有为现代的 context engineering 做专门的训练。关于 context engineering，也可以参考我的上一篇文章[2]，以及 Manus 与 LangChain 联合做的分享，干货满满！

Peak 提出了个很有意思的想法，他觉得 200K 以上的 context 不重要了，比起更长的 context，更重要的是让模型具备 compression awareness，对压缩 context 这件事的意识。如果让 context 无限单调递增的话，即使有 KV cache 的存在能降低延迟和成本，但它仍然是个增长过程，即使有 efficient attention（比如 linear, sparse attention 等），也并不值得。

更重要的是让模型知道：我现在 context 已经很长了，我能不能把一些 context 中的信息去 offload，把它外化到比如文件系统中，以后在需要的时候再取回来。或者是针对之前的一段工作过程，在需要的时候可以触发一次 compression，忘掉不需要记住的细节。但模型又要能意识到这段东西不是凭空消失了，它是被压缩了。让模型意识到被压缩这件事是需要专门训练的，这是为 chatbot 训练的模型其实没有很好训练过的点。

结合前面提到的模型的 context pressure 来看，应该是有机会能做到这点的，但可能需要构建不少这方面的数据和 evaluation。像之前 Devin 团队就分享过他们为信息总结压缩单独构建了一个模型。Peak 在之前的分享中也提到了当前为了绕过模型没有很好训练的问题，做了一些细节优化，比如在做压缩总结后保留最近几轮的工具调用，以实现“平滑过渡”。

另外还有一个比较有意思的观察是，如果直接把一个针对数学和竞赛编程设计的 reasoning model 用于 agent 场景，其效果反而是下降的。比如指令遵循，出现幻觉和幻觉工具调用等。ReAct 的思考应该更面向工作流程本身，比如我之前做了什么，观察到了什么，下一步应该做什么。这个思考内容跟解复杂数学题的思考内容可能是很不一样的。

我们在实际工作中观察到，ReAct loop 的主模型可能大多数还是用的 non-thinking mode，但会给模型一个thinktool，或者搞个深度思考的 sub agent，它可以使用思考模式来处理真正需要复杂逻辑推演的问题。

Manus 的上述各种观察能够切实影响头部模型厂商对于模型适配 agent 场景的开发投入，然后也会进一步影响到开源厂商的跟进，用 Peak 的话来说，“好像全世界都在帮我们一起训模型”，令人羡慕。

几个头部模型的特色，应该也是大家的共识：

与模型厂商的竞和关系

模型厂商也做应用，他们来抄 Manus 怎么办？

  1. Manus 可以用所有模型，综合起来肯定是体验更好的。
  2. 模型厂商如果做垂直整合（比如包括应用和模型联合后训练等），迭代速度上肯定没有 Manus 快。
  3. Agent 这种长链路、环境强相关的场景下，用户的使用轨迹和 feedback 数据是很关键的，而这个是留存在应用层的。

针对迭代速度快这一点，我们也发现很多时候最懂如何使用 LLM 的并不是模型厂商，而是应用厂商。Peak 也提到了像 think tool，通过代码来调用 MCP，agent skills 这种渐进式披露的做法，都是他们比模型厂商更早发现并使用的。

Cursor 训练出了业界评价很不错的 Composer-1 模型，也是上面第 3 点的体现。而 chatbot 好像数据飞轮的效应的确比较弱，更多是通过品牌，或者所谓的用户记忆来提升用户粘性。

当然 agent 产品还在很早期，不确定性因素非常多。个人感觉 to C 大场景的竞争的确会是不再严格区分所谓模型厂商还是应用厂商，大概率是两者都做。

Manus 的用户

有三类典型画像：

  1. 在互联网或者技术公司里的白领，但不是程序员。
  2. Freelancer 或者 sole proprietor，自己做外包或者小生意的人。
  3. 金融和咨询行业的人，有比较强的自驱力且任务是高价值的。

Peak 提到做通用 agent 更像是做一个人，而垂直 agent 则更像是做一个工具。我大概理解了一下，可能是通用 agent 才能端到端地完成一个任务，从而达到替代真人工作的效果。而垂直 agent 往往只能完成一个人工作中的某些环节。

前面提到了 agent 的模型和环境，这里用户也是一个非常重要的元素。用户的瓶颈主要在于需要输入 prompt 来触发 agent 工作，所以很重要的一个方向是去提升 agent 的“主动性”。但 Peak 认为主动性并不是像 ChatGPT Pulse 那样去给用户推送很多东西，这个其实是在占用用户时间。更应该关注的是如何让 agent 主动去完成更多的事情。

以我们做 data agent 为例，可能不要给用户太多推送说你的某个业务指标有问题；更好的方案还是要更深入去完成背后的分析、诊断、建议行动等，这样用户只需要做一个简单的审批确认，真正提供了完成任务的价值。

数据飞轮

Chatbot 的用户 feedback 可能比较少，很多用户会选择重试，或者修改 prompt 再次发送。而在 agent 场景下，用户会教这个 agent。一种是通过自然语言反馈的方式，另一种是直接接管电脑来完成具体的修改，再告诉 agent。这类数据在 chatbot 时代非常难获得。

有了这些反馈数据，就可以做一些不涉及参数变化（主要指模型训练）的 self evolving 了。最常见的就是所谓的 user memory 的挖掘和使用，例如 Cursor，Devin 等都有这个功能。根据我们的经验，的确第一个难点是怎么激发用户给出这类反馈；而另一个难点是怎么设计 evaluation，来保证个性化记忆的挖掘和使用是有正向提升效果的，而不会对用户造成太多困扰。

在此基础上，还可以总结通用的 failure pattern，把用户共识性的东西变成系统原生的一部分，这样用的人越多，agent 的失败率会越低，完成同样任务的开销会越小。

Manus 也会收集用户最朴素的反馈，比如打一星到五星作为指导。这里构建起来的 benchmark，往往比业界很多自动化的 benchmark（如 GAIA, SWE-bench）要更接近用户关注的东西和真实体验。

Manus 有一个不到 10 人的 evaluation 团队，同时负责相关系统的搭建。同时产品团队还有一些 junior 的同学负责主观 evaluation，所以总体加起来有 10 多人。Vibe 还是很重要的。

Evaluation 关注的核心指标包括：

  1. Coding 能力。
  2. GUI 的理解能力，主要是 browser use 的相关任务。目前没有做 computer use。
  3. 广义的 tool call 能力，不仅仅是模型的 tool call，应该还包括了特定命令行工具、代码 SDK/API 的使用等。
  4. 美学性和对错误的自我意识等。模型能否自己去检查并发现错误和不完善的地方，进而修正和优化。

Agent 该如何分类？

Peak 认为模型跟人一点都不像，不应该把 agent 跟人的常用思维体系去强行对齐。这里聊到很多 multi-agent 系统会按照人类组织的形式去设计，比如设计师，程序员，产品经理，测试工程师等。但实际上 agent 是“全能”的，并不需要按照这种方式去分，反而会带来很多 context 传递上的问题。按照 Peak 的看法，agent 应该不需要分类，或者说只能按照输入输出的角度去分。比如垂直 agent 的输入输出形式可能会与通用 agent 很不一样。

在我们日常实践中，更多会从 context 管理的角度去考虑 agent 的切分，缓解前面提到的 context pressure 问题。比如搜索问答场景，可以有一个 agent 来专门负责搜索和信息筛选，另一个 agent 来负责生产回答或报告，避免在搜索过程中大量的网页信息挤占 context。类似的在 coding 场景中，可以有一个 agent 来专门帮助查找和阅读代码，将精炼过的信息返回给主 agent 继续工作。

Peak 在之前的分享中也提到过 Manus 当时采用的 agent 分工，包括通用的执行 agent（核心流程），planner agent（专门管理 todo），knowledge management agent（可能是用户反馈知识挖掘）等。

Agent 生态

Peak 认为并不是谁有一天突然做了一款 agent OS，而是所有的 OS 都会逐渐具备 agent 的能力。当然这个词也比较大，很多人在提 agent OS 时，其实想的更多是一个 agent 的管理和运行平台，并不是严格意义上的操作系统。

To B 领域的垂直 agent 会更加百花齐放一些，尤其美国做 to B 的环境太好了，很多美国创业者已经失去了做 to C 的勇气和心气。反倒是华人创业者因为在移动互联网时代做 to C 产品拿到不少正反馈，更有勇气去做 to C agent 产品。

是否有 to C agent 的生态位？Peak 举了个很有意思的例子，讲团队的同学之前做过剪辑软件。但是做垂直 to C agent，如果要给剪辑师做一款更好的剪辑 agent，是非常困难的。专业人士对于这个 agent 的产出会有极高的要求，他会从风险控制的角度来看待这个事，但凡有一个环节没做好，对这个专业人士来说就是 0 分，它是一个乘法关系。

更好的选择是给非剪辑师但有剪辑需求的普通用户做一个 agent，比如自媒体，这样的话会变成给原本有这个需求但做不了的人，带来的是净增益。所以说 agent 虽然“像人”，但一定不要以替换人的思路去做，那样的话所有人都会从风险控制的角度去想，但凡一个环节不通就不行。更应该从提升人的思路去想。

跟 OpenAI 的竞争关系：Manus 会长期专注为真正有高价值需求的人提供他能找到的最好的 AI，永远能提供比 ChatGPT 的 Agent 更好的体验，而不是跟 ChatGPT 去抢夺最广的底层用户群（很多是 chatbot 场景）。

Manus 通用 agent 的定位，呼应前面所说的，做通用 agent 是他们在技术上的一个刻意选择，有一个更好的技术架构，可以让不同的场景之间有很好的协同性，并且互相增强那个网络效应。垂直 agent 可能还是有必要的，比如设计软件仍然会存在，可能会升级带上 agent 的能力，而 Manus 则是尝试去学习使用这些垂直 agent，比如它完全可以打开浏览器去使用 Lovart 等。

Cursor 与 Claude Code 的竞争关系

AI coding 不是一个垂直领域，而是一个通用能力，因此也是目前竞争最激烈的一个点。创业公司与大厂竞争的一个方式是“成为大厂”，因为大厂也不会倾注所有资源在做一件事，我们只需要确保我们在这件事上的能力和投入超过大厂就可以。比如 Cursor 团队应该完全有实力与负责 Claude Code 的团队去直接竞争。

这里也有一个具体体现Cursor 在选择空间上相对于 Claude Code 的优势。比如 Claude Code 只能是 Claude 模型的延伸，可能在 agentic coding 任务上比较强；但 Gemini 3 在静态前端美学上非常领先，Cursor 就可以引入进来，做到比 Claude Code 更好的综合效果。

是否要做中国市场

目前可能性不大，海外用户对于生产力工具的付费意愿更强，而在国内很难收到钱，加上 agent 产品对于 token 的巨大开销，很难持续补贴。

Manus 1.5

实际上是用一个版本号把过去一段时间的更新都打包到了一起，1.5 发布那一刻的更新反而没有多大。这里一个比较有意思的认知是，通过一个新的版本号是最好的让用户理解有更新的方式。而以往软件的版本号往往是个隐藏比较深的信息，在大模型产品中，直接凸显出来可能会更好。

Manus 1.5 的另一个技术演进是把任务完成的速度进一步提升了，能够以更快的速度完成简单任务，但在更复杂任务上去投入更多 inference time 的计算。平均来说应该快了 3-5 倍。

比较直观的做法可能是通过模型来判断任务的复杂度，来决定投入多少推理时间，当然也可以在过程中动态调整。当前也有不少模型训练在这方面做了不少优化工作，比如 GPT-5.2 模型看起来价格比 GPT-5.1 要贵，但由于在简单任务上能比较好地控制思考长度，因此综合成本反而更低了。

业务指标

Manus 追求的不是 DAU，而是把最有高要求的用户、高价值用户的高价值 task 做到最好。体现在的可能更多的是营收，或者为每个用户产生的 agent hour 上。就像张涛说的，希望做一个能够 7x24 小时为用户不间断工作的 agent。

AI 产品的网络效应

传统的网络效应主要是两种：

  1. Build on someone else's work，基于其他人的产出去进一步贡献，如开源软件生态，维基百科等。
  2. 由用户关系带来的网络效应，典型的如社交网络。

之前提到Manus 在原子能力层面可能有一定的网络效应，保证每次增加的能力能够与别的能力形成组合拳。这里 Peak 提到了一个例子，给 Manus 加入了“看图”的能力，于是 Manus 就能开始学会去检查自己做的网页是否美观，是否可以操作交互。这样这个能力就同步提升了 Manus 其它的如操作网页、coding 等方面的能力。

对于第 2 点，考虑人与 agent，或者 agent 与 agent 之间的网络效应的话，或许 Wide Research 也算是一种 agent 之间的网络效应，一个 agent 可以调度很多别的 agent，他们之间还能互相通信，去完成单个 agent 无法做到的任务。

Manus 也对接了 Slack、Email 等，使得 agent 能加入到人的协作上下文之中，这也可能是 agent 与很多人之间的网络效应的雏形。

不过 Manus 毕竟面向的是专业场景，没有大家想象中那种爆发式的网络效应。另外还有像 Second Me 这样让 agent 代替人去社交这样的尝试，更接近传统的网络效应的范畴。

坚信“纯血派” agent

这里主要讨论了 agentic workflow 和 agent 的区别，具体可以参考 Anthropic 的《Building Effective AI Agents[3]》。

为什么叫纯血的 agent，就是说它其实没有人为加的约束，而是说完成一个任务的所有的过程和方式，是由智能本身决定的。它的天花板会非常非常的高。当然现在此刻来对比的话，可能 agentic workflow 的可复现性会好一些，但是这是一个可以解决的问题。Manus 团队非常坚信，就是要做纯血的、由智能主导的 agent，而不是以规则主导的 agentic workflow，这才是更符合 The Bitter Lesson 的原则：用通用的方法，投入更大的算力去解决问题，而不是加入更多的人为的知识。

这里举的一个例子恰好是我们的场景中也会碰到的让 agent 做可视化的任务。产品希望所有语言下的数据可视化效果都非常好，比如坐标轴要设置正确，标题和图例不要发生遮挡，文字不能有乱码等等。

真知灼见，醍醐灌顶！

团队设计

两个比较有意思的团队：

Agent team 如何评估 agent 框架的有效性？他们有一个“弱到强的衡量”：选一个同源的模型家族，比如都选择 Gemini 或 Claude，拿它的弱版本跟强版本对比，跑同样的 benchmark，不断调整 agent 框架，让它们之间的 delta 最大。这样当下一代模型变强的时候，我们获得的增幅是最大的。

重要的技术决策

一些举例：

  1. 没有盲目地去追 reasoning 这条路。Manus 用了一个比较另类的方法，用一个单独的 planning stage 来做这个事。前面提到的在过程中引入使用 reasoning 模型的 sub agent 也是类似思路。
  2. 对 MCP 的决策非常保守。MCP 出来之后，整体业界都非常嗨，很多人就开始去接。但他们当时觉得这个会严重污染你的 action space，而且会导致缓存命中率下降。他们采取的方法就是后来 Anthropic 发文写的 MCP 的 code mode，在代码层面去调用，而不是在原生 tool call 层面。

后悔的决策：

一开始有点太盲信小模型了，参数量还是重要的。AK 也提过这个观点，大模型有不少参数都是在做事实性的记忆，这些是不是可以分离出去，只保留一个“认知核心”，需要事实性知识时，调用工具去获取就可以了？但实际情况是，我们很难去分离什么是知识，什么是泛化的认知能力。所以大参数量还是有用的。

Online Learning

澄清了一下大家所说的 online learning 可能有 3 种：

  1. 狭义的 online learning，通过持续改变模型参数来更新模型。
  2. 大规模个性化，也就是用户与模型交互之后，模型能学到每个用户的个性化偏好。
  3. 不 online 的 learning，类似于之前 Magi 做的，应该叫 continuous learning 或 lifelong learning。

针对大规模个性化这个需求，其实不一定要通过改变参数的方法去做。如果给每个用户不一样的模型权重，即使用 Multi-LoRA 的方式，serving 的成本还是会很高，而且会影响推理效率，比如一个 batch 里同时处理不同用户的请求时的处理就会比较复杂。所以目前更多的还是使用用户个性化的记忆挖掘，并通过 prompt 动态注入的 in-context learning 的方式去做。

到底要 online learning 还是 continuous learning？如果有些领域的理想分布会随着时间而改变（concept drift），比如今天的正确答案不一定是明天的正确答案，那么做 online learning 可能是很有价值的。其它领域的数据分布相对比较稳定，比如 coding 补全场景，那么就没有必要做 online learning。通过 continuous learning，持续收集数据做周期性的优化就可以了。甚至说如果任务本身没有动态性的话，benchmark 可能也会很快饱和，都没有持续提升的空间。

Agent 模型的提升方向

  1. 学会 compression awareness，让模型意识到自己的上下文可能会被压缩，并做出更好的选择，更好地了解文件系统该如何去 offload 跟 retrieve。
  2. Reasoning 的优化目标应该去考虑如何更好地结合 observation，做有工具集成的推理（tool integrated reasoning）。这与完全靠 RLVR 去解决竞赛编程和数学是很不一样的思路。
  3. 如何让 agent 在持续工作过程中，用户可以随时插嘴，要么是改变目标，要么是补充信息，或者是直接终止。很多模型还没有完全掌握这样的交互模式，应该也是跟训练数据构造有关。
  4. 模型应该更关注一些对错误的处理和恢复能力。Agent 在工作过程中一定有很多意料之外的事情发生，模型能否找到一条别的路径去尝试，而不是放弃或陷入死循环，这个是需要专门去做训练的。

AI 产品的竞争稳态

移动互联网可能到什么时候稳态？是当真正用户的时间被瓜分完了之后，出现了移动互联网的稳态。无论你做哪一个类型的产品，都绕不过本质上在跟抖音竞争，因为抖音吃了很多用户的时长。但 agent 是不一样的，它其实是在减少与用户直接交互的时间，但在持续后台创造价值。所以人跟产品交互的时长不是一个有限的约束条件。

一些杂谈

文章已经比较长了，本大模型也感受到了 context pressure，后续部分快速过一下。

Scaling law 停止了吗？狭义上 loss 的降低肯定还是有效的，但广义上说通过 scaling 来涌现不一样的能力，解锁全新的场景，可能不好说。但目前来看，即使是不解锁新场景，当前 agent 的产出质量仍然是不够的，所以 scaling 在这里还是有作用的。

对 Manus 最大的隐忧是失去特色，变得复杂。在产品增长的过程中，有一个很便捷的方式是做更多的功能。但是你每增加的一个东西都在稀释所有别的东西。所以希望 Manus 能一直保持这样一个克制走下去，但是又不能因为保持克制而影响了持续的增长。这还是个挺难的课题。

对田渊栋几篇工作的介绍，latent reasoning 的思路很有意思，感觉更接近“AI 原生”的思考过程。

对 Thinking Machines Lab 的评价：tinker 是个抽象设计非常好的库，不过当前的问题是成本有点高，自己搭 megatron 可能还稍微便宜点。此外他们也比较依赖开源模型能持续进步。对于做研究来说，有同源模型的不同参数版本是非常重要的，千问提供的光谱一直是最全的，所以 Thinking Machines 的成败主要看千问。

多模态的输入问题，当前如果一个 tool 调用的返回结果是个图片，模型的后续输出质量是有所下降的，可能目前的重视程度还不够。

对于之前嘉宾访谈的评论，主要不同意的一点是杨植麟说的，如果不训练模型的话，做 agent 是逆向工程，最终都是要整合进模型里面的。Peak 则认为不仅不是逆向工程，还能影响模型厂商如何训练模型。而且 agent 工作的环境，从理论上来说是不能内化到模型里的。如果说是环境的状态变化推演，我也同意说比较难内化到模型里，所以无论如何模型肯定是需要通过 tool call 与环境交互的。但对于工具调用、环境反馈的理解能力来说，这部分还是可能在模型能力不断提升的情况下去内化的。

写在最后

笔记至此，意犹未尽。

正如文章开头所说，能在 2026 年的第一天听到如此高质量的分享，不仅是认知的刷新，更是一种精神上的鼓舞。Peak 和 Manus 团队展示了一种属于技术人的浪漫——对“纯血”智能的极致追求，以及在商业世界中保持清醒与克制的定力。

站在 Agent 爆发的前夜，无论是做通用的 Manus，还是深耕垂直领域的我们，其实都在通过不同的路径去逼近那个最终的通用人工智能愿景。新的一年，期待看到更多像 Manus 这样有“品味”的产品出现，也希望我们在自己的“画布”上，能探索出更多未知的可能性。

2026，Keep Building。





欢迎光临 链载Ai (https://www.lianzai.com/) Powered by Discuz! X3.5