Manus，我错了

今天是 2025 年的最后一晚，我决定用写文章的方式跨年。

这两天我一直在看 Manus。之前我其实一直对它自称“通用智能体”是存疑的，但现在我慢慢想通了：如果只看对互联网与电脑系统的操作层面，它确实做到了极少数团队能做到的那种通用与可靠。

这一层本身就是极难的工程问题，而 Manus 把它做成了产品级、规模级的能力。

本文把 Manus 到底解决了什么样的脏活累活、又是怎样把这件事做到这个水准的说清楚，并再向前走一步：Manus 之后，智能体时代的临界点在哪！

很长一段时间里，我对 Manus 的态度其实不太客观。

我会下意识把它归到那类“又一个号称通用的 Agent”里：看上去什么都会，真正落地就各种翻车。再加上我自己在做 Agentbase，天然会有一种本能的防御——觉得对方的叙事可能被高估，甚至会不自觉地产生一点嫉妒和不屑。

直到这两天 Meta 20亿美元收购 Manus 的新闻出来，我逼着自己认真看、认真试、认真对照细节，才意识到：我之前那套“先入为主”的批判方式，是错的。

我才意识到，我之前根本没有真正面对现实世界对智能体的第一性需求。

因为我一直盯着“它能不能理解复杂任务”，却没有真正把注意力放到更硬的一层——它到底能不能在现实世界里把事情做完。

现实世界的问题是：“我每天被一堆软件压着，我只想有人替我点完它们。”

现实世界对 agent 的理解是自动进到各种 app 里干活：CRM、ERP、表格、后台、广告投放、报表导出、工单系统。。。这些不是抽象问题，是操作负担。这就是现实用户的第一性原理！

所以：

• dify 走的是：workflow + tool calling

• Manus 走的是：browser + api + action

他们一旦出来，火爆全球！因为它们在缓解痛感，市场总是先为能缓解当下痛感的东西买单，这是一种非常朴素也非常真实的选择。

Manus 的通用性，恰恰在这一层成立。

Manus 路径是：一看就懂、一试就爽、一用就省事、一付费就心甘情愿！

我现在愿意把这件事说得更直白一点：绝大多数智能体失败，不是失败在聪明，而是失败在手脚。

现实世界的工作并不优雅，它由无数“很烦但必须做”的动作组成：

• 需要登录、跳转、等待；

• 页面会变、按钮会换位置、弹窗会出现；

• 表单会报错、上传会失败、网络会卡；

• 有的系统根本没有 API，只能靠人点；

很多时候你得在几个系统之间来回切换，复制粘贴，核对字段。

这些东西在 demo 里几乎看不见，但在真实业务里占了 80% 的时间。

Manus 的价值就在这里：它把这类动作层面的“脏活累活”做成了可靠能力，而且不是偶尔成功，是能持续、可重复、可规模化地成功。

我之前最核心的一个疑问是：“Manus 真的通用吗？”

现在我的答案变成：如果把“通用”限定在“对互联网与电脑系统的操作层面”，它确实做到了少数团队才能做到的通用和可靠。

举几个例子：

绝大多数 agent：

• 会规划

• 会拆解

• 会给建议

但一到“进网站 / 登录 / 点按钮 / 填表 / 翻页 / 下载 / 导出”就崩！

Manus 把 最脏、最烦、最容易失败、最不性感 的那一层做到了工业级稳定：这是一种极端偏工程、极端偏 infra、极端偏执行链路可靠性的胜利。

怎么实现的？Manus Cofounder 季逸超点出的关键：

他们不是“多 agent”，而是“同构并行 agent”——Each sub-agent has the same action space as the main agent.

这句话非常重要。意思是：他们不是角色扮演(researcher/planner/critic），而是：N 个完全一样的执行体，并行跑网页、API、表单、数据抓取。拼的是 throughput、容错、调度、重试、幂等。

这是分布式系统工程，不是认知架构设计。

更有意思的是，X 上有位叫陈剑的 90 后币圈玩家（和肖弘差不多大）写了一篇长文分析肖弘的创业史以及为什么他总能点石成金。

“武侠小说中，经常会有一类奇人，他们没有什么花里胡哨的套路，但是就是只把一招练到出神入化，不论走到哪里，都只需要这一招。肖弘就是这样一个人。”

他的总结很直白：“肖弘把 API 集成提效玩到极致。套壳到极致就是牛逼。” 

我曾花了 2 年多时间创业只做了一件事：API 集成 Meta 平台的数据，对他的这句话深有体会。这句话在工程语境下等价于：把“最后一公里的摩擦”压到趋近于 0。而这个摩擦，90% 在：

• 人类浏览器环境

• 网站登录

• 奇葩前端

• 反爬

• session

• cookie

• JS 动态加载

• 表单校验

• 导出按钮藏在 5 层菜单里

Manus = 世界上目前最强的“数字苦工 + 数字体力”这一层的极致工程化。而且它有“人为付费”意愿，说明这个苦是真的痛。

我后来又产生了第二个疑问：
“如果它能做这么多事，它一定也得会拆解任务、也得有记忆吧？那这不就跟我说的 Agentbase 的任务工程很像吗？”

答案是：当然。

一个能稳定执行复杂任务的系统，不可能没有：

• 任务拆解（把目标变成步骤）

• 过程记忆（至少要记得自己做到哪）

• 行为轨迹（否则无法回滚、无法续跑）

• 判断与重试（否则遇到异常就崩）

否则它不可能：

• 并行 sub-agent

• 回滚失败步骤

• 重试 / 续跑

• 处理异常

所以是的，它内部一定有类似：

• Task representation

• Slot filling

• Flow control

• Trace

• Retry / backoff

• Success detection

只是这些是它的 engine，不是它的 product。这些结构在 Manus 里，更多是“为了把这次执行跑通”的内部机制，它们是

• hardcoded

• 内部 schema

• 为他们自己的执行模型服务

• 会随着产品快速迭代

• 不保证稳定、不对外承诺

就像：

• 数据库内部一定有索引、buffer、WAL、GC

• 但它不会把它们当产品卖

• 像发动机的零件，强、硬，但不一定对外暴露、也不一定要变成一套公共协议。

我做 Agentbase 时想要的是另一种东西：把这些要素做成可以被看见、被继承、被治理的结构资产。

两者不冲突，只是目标不同。

Manus 改变的是：人 → 电脑 的关系，从 “人点” 变成 “AI 点”。

Agentbase 试图改变的是：人 → 任务 → 组织 的关系，从 “人记住一切” 变成 “系统记住一切”。

这两件事不在同一层级。

Manus 可能成为新的操作入口；
Agentbase 可能成为新的组织内核。

这就是为什么 Manus 被 Meta 收，Agentbase 更像 Snowflake / Palantir 的路径。

我曾经也想过：“Manus 的强项是不是把 API 玩得很溜？”

后来我意识到：会调 API 的 Agent 其实并不少，真正难的是另一类场景：

• 没 API 的系统

• 只能通过 UI 操作的遗留软件

• 网站频繁改版、状态复杂、容易出错的流程

• 一堆“人类界面”，天然不欢迎机器

这才是多数智能体的地狱。

正如 Manus 的设计把“Each sub-agent has the same action space.” 这个 action space 包含：

• API

• Browser

• 系统调用

• 表单提交

Manus 最让我佩服的地方，是它把“可控的 API 世界”和“不可控的 UI 世界”当成同一类可调度动作，统一到一个执行空间里，而且能把失败路径也跑通，能继续干活。

这就是为什么它看起来像“制造业”，不是像“互联网”。

cofounder 季逸超在《manus 决定出售前最后的访谈》说的一段话，我反复读了好几遍：

1. AI 其实不是平台变化，AI 是技术增幅。以前的优势可以惯性发挥，强者加上 AI，具有先发优势。

2. 从边际成本看，目前为止 AI 更像制造业，而不是像平台：这是非常理智的判断，因为不理智早死了。

它点醒我的地方是：AI 不是天然把机会分给所有人。很多时候它反而让“工程能力强的人”把优势放大。

也解释了为什么 Manus 这么值得尊敬：它不是讲了一个漂亮故事，而是把工程门槛顶到了极致，把“能干活”这件事做成了能力。

我之前对 Manus 的轻视，本质上就是低估了这层工程壁垒。

Manus CEO 肖弘最近和腾讯高管访谈中有段对话。

腾讯问“下一次突破口在哪”，肖弘说：

• 今年或明年初，最大的突破会出现在更通用的 Computer Use——AI 看到一个软件就知道怎么用它。

• 长期来看，外部环境会越来越 API 化，因为今天的 UI 都是给人类设计的，未来大家会更愿意把能力 API 化给 Agent 用。

这段话把一条路径讲得很清楚：

• 第一阶段：Agent 先学会用人类的工具和界面（Manus 正在做的事）

• 第二阶段：世界开始为 Agent 重写接口，越来越 API 化

• 第三阶段：Agent 会真正变成劳动力，进入组织生产系统

我以前总把“任务结构”放在第一位，忽略了：没有执行层，后面全是空谈。

现在我更愿意承认：Manus 这类公司，是把第一阶段真正打穿的人。

看到这里，我也终于想明白了我自己真正关心的那一层。

当 AI 已经能像“数字员工”一样干活时，组织里马上会出现一堆新问题：

• 一两个人带着上千个 Agent 干活，怎么管？

• 它们在做什么，谁能看得清？

• 结果好不好，怎么评估？

• 哪些策略有效，哪些在浪费钱、制造风险？

• 怎么复用，怎么迭代，怎么越跑越强？

这不是“让 AI 去点按钮”的问题了，这是组织结构问题。

这也是我最近重新理解“任务为中心”之后，才真正找到的落点：任务必须是一种可以被追踪、被验证、被演化的组织对象。

我现在更愿意用一种更朴素的表达来理解它们：

Manus 解决的是：让 Agent 先成为可靠的“手”和“脚”，能进到现实世界，能把事情做完。

Agentbase 想解决的是：当这双手脚出现之后，组织如何把它们用好，让它们可管理、可评估、可继承、可进化。

这不是谁取代谁的问题，更像是一条连续的时间轴。

Manus 让第一步发生，后面的结构问题就会被迫浮出水面。

而我真正想做的，是站在 Agent 的视角，把世界看成任务，把“做事”这件事变成可以被组织理解和治理的东西。

这一次我不再用嫉妒和轻视去看 Manus。

我更愿意把它当成一个里程碑：它把智能体必须做的苦活脏活做成了。

它把一个新阶段，从想象推到了现实。

Respect。