单 Agent 还是多 Agent：四家生产结论对撞
前置：前面任意两篇。
本篇回答：手上这个活到底该不该拆成多个 Agent —— 四家已经上线的团队给出了互相矛盾的结论，怎么判断哪条适用于你。
2025 年 6 月，两篇博客隔了几天先后发出来，标题几乎是对着干的：一篇叫《别做多智能体》，另一篇在讲自家多智能体研究系统怎么把效果提上去的。
两家都在生产上跑着东西，两家都不是在讲空话。所以问题不是谁对，而是他们在做的事有什么不同。
这个问题没有通用答案，但有一个相当清晰的判据 —— 你的子任务之间，有没有共享的隐式决策。
一、正面对撞
1.1 Cognition：《Don't Build Multi-Agents》
他们的论证是两条原则：
- Share context, and share full agent traces, not just individual messages —— 共享上下文，而且要共享完整的 agent 轨迹，不只是单条消息
- Actions carry implicit decisions, and conflicting decisions carry bad results —— 动作里携带着隐式决策，互相冲突的决策产出垃圾结果
第 2 条是全文的核心：动作里携带着隐式决策，而互相冲突的决策会产出垃圾。
他们给的例子非常具体：让两个子 Agent 一起做一个 Flappy Bird 克隆。
- 子 Agent A 去做背景，它做成了超级马里奥风格的背景，而不是 Flappy Bird 要的绿水管
- 子 Agent B 去做小鸟，做出来的鸟长得和动起来都不像 Flappy Bird
- 父 Agent 拿到这两个东西，面临一个不可能完成的任务：把两坨风格不搭的东西缝成一个产品
问题的根源不是子 Agent 笨。是 「Flappy Bird 长什么样」这个决策是隐式的，没人显式写进任务描述里，而两个子 Agent 各自补全了这个空白，补得不一样。
他们进一步指出：把原始任务复制给子 Agent 是不够的。真实生产系统里是多轮对话 + 工具调用 + 大量细节，这些上下文没法压缩成一句任务描述。
推荐做法：
- 单线程线性 Agent，保持连续上下文
- 任务太长就用上下文压缩模型——专门训一个 LLM 把对话历史总结成关键细节和决策
1.2 Anthropic：《How we built our multi-agent research system》
同期 Anthropic 给的是相反的结论和一组数字：
| 指标 | 数值 |
|---|---|
| 多 Agent vs 普通聊天的 token 消耗 | 约 15 倍 |
| 并行子 Agent 带来的研究耗时下降 | 最多 90% |
| token 用量对评测效果方差的解释力 | 80% |
而且他们的做法恰恰是 Cognition 反对的那个：子 Agent 拿全新上下文、互相不知道对方存在、无法中途协调。
二、为什么两边都对
关键在于任务形态，两家做的产品根本不一样：
| Cognition（Devin） | Anthropic（Research） | |
|---|---|---|
| 任务类型 | 写代码 | 查资料 |
| 子任务之间 | 强依赖，改同一份代码 | 弱依赖，各查各的 |
| 操作性质 | 写为主 | 读为主 |
| 隐式决策 | 极多（风格、架构、命名） | 极少（事实就是事实） |
| 结果能否机械合并 | 不能，要缝合 | 能，拼起来就行 |
任务形态决定架构，可画成二维分区（左下为多 Agent 甜区）：
判据是三条，而且很好用：
| # | 判据 | 拆（多 Agent） | 不拆（单线程） |
|---|---|---|---|
| ① | 子任务之间是只读，还是写同一份产物？ | 只读 → 隔离是纯收益 | 写同一份 → 隔离导致决策冲突 |
| ② | 有多少无法写进任务描述的隐式决策？ | 少（事实即事实） | 多（风格 / 架构 / 命名） |
| ③ | 结果能否机械合并？ | 能（列表、表格、事实集合） | 需人工缝合风格与逻辑 |
Flappy Bird 三条全中，所以拆了就崩。研究任务三条全反，所以拆了提速 90%。
2.1 一个更有意思的证据：Anthropic 自己两边都做
04 那篇 里提到的一个细节值得再说一遍：
- Anthropic 的研究系统：子 Agent 互相不知道对方存在
- Anthropic 的 Claude Code：子智能体默认可以嵌套 3 层，而且有
SendMessage可以给兄弟发消息
同一家公司，两个产品，两种架构。 研究是只读并行，所以隔离；写代码有共享状态，所以给了通信通道。
这不是自相矛盾，这是最好的证据：架构由任务形态决定，不由信仰决定。
三、五家的五维总表
| Kimi CLI | Manus | Claude Code | DeerFlow | Suna | |
|---|---|---|---|---|---|
| D1 隔离单位 | context.jsonl | 一台 VM | 上下文窗口 / git worktree | LangGraph 分支 | 一个沙箱 |
| D2 通信拓扑 | 星型 | 星型（官方明确禁止） | 星型 + SendMessage | 星型 | 星型 |
| D3 结果回收 | 最后一条消息，低于 200 字重写 | 主 Agent 综合 | 只回最终结果 | 确定性截断 2000 字 | 由 OpenCode 负责 |
| D4 递归深度 | 硬禁止 | 未公开 | 默认 3 层 | 默认禁止 | 继承 OpenCode |
| D5 生命周期 | 前台/后台/可 resume | 一次性 | background / memory / fork | checkpointer 可续跑 | 温 fork / 失控中止 |
| 并发上限 | 未见硬编码 | 上百个 | 未公开 | 3 | 沙箱数决定 |
| 步数上限 | 1000/轮 | 官方称均值约 50 | maxTurns 可配 | 150 / 60 | 由 OpenCode 决定 |
三条横着看才能发现的规律：
3.1 规律 1：隔离粒度和并发上限是同一件事的两面
| 隔离单位 | 代表 | 并发量级 |
|---|---|---|
| 一台 VM | Manus | 上百 |
| 一个沙箱容器 | Suna | 数十 |
| 一个 LangGraph 分支（同进程） | DeerFlow | 3 |
隔离越重，反而并发越高。
所以「我要不要上重隔离」这个问题，等价于「我要不要几十上百路并行」。要，就得付 VM 的钱；不要，同进程 3 路够用。
3.2 规律 2：禁止递归是压倒性多数
四家有明确表态的里，三家禁止（Kimi 硬编码、DeerFlow 默认禁、Manus 推测单层），只有 Claude Code 默认允许 3 层。
而且 Claude Code 的允许是带刹车的允许：深度计数器、到顶撤走工具、Agent(type1, type2) 限定可派工种。没有一家是无限制放开的。
结论：默认单层，除非你能说清楚为什么需要更深。
3.3 规律 3：结果回收有两个相反的失败模式
| 失败模式 | 表现 | 谁在治 | 手段 |
|---|---|---|---|
| 太短 | 子 Agent 回一句「已完成」，父 Agent 抓瞎 | Kimi CLI | LLM 重写（SUMMARY_MIN_LENGTH=200） |
| 太长 | 子 Agent 把全 文倒回来，撑爆父 Agent 上下文 | DeerFlow | 确定性截断（2000 字，头 2/3 + 尾 1/3） |
两家各治一头，理想做法是两头都治：
下限用 LLM 保证信息量，上限用确定性截断保证不炸。这是我从这个专题里学到的最直接可用的一条。
四、选型决策树
注意这棵树上有四个「回到单 Agent」的出口。 这不是偏见——是五家生产实践的共识：多 Agent 是特例，不是默认。
Anthropic 那个「token 用量解释 80% 效果方差」的发现说得更直白：多 Agent 的效果提升，很大程度上来自它烧了 15 倍的 token。如果你的任务不值这个价，那省下来的钱就是净收益。
五、一条正在发生的趋势：编排在下沉进模型
前面拆的全是工程层的编排。但有一条线值得单独指出来：Moonshot 正在把编排往模型里做。
Kimi K2.5 官方仓库 README 的原话：
"K2.5 transitions from single-agent scaling to a self-directed, coordinated swarm-like execution scheme. It decomposes complex tasks into parallel sub-tasks executed by dynamically instantiated, domain-specific agents."
评测配置里给了具体数字：
"BrowseComp (Swarm Mode): main agent max 15 steps; sub-agents max 100 steps." "WideSearch (Swarm Mode): main and sub-agents max 100 steps."
主 Agent 只走 15 步，子 Agent 走 100 步。 主 Agent 就是个调度器，重活全在子 Agent 那边——这个比例本身就说明了编排的形状。
⚠️ 关于「300 个子 Agent / 4000 步」：这个数字来自 2026 年 4 月的二手技术报道，说的是 K2.6。我在 MoonshotAI 的 GitHub 组织下没有找到 Kimi-K2.6 仓库（只有 Kimi-K2、Kimi-K2.5、Kimi-K3），K2.5 的官方 README 也没有这个数字。引用时请以官方技术报告为准，本文不把它当作已确认事实。
值得注意的对比是：
| 编排在哪 | 谁决定拆几个子任务 | |
|---|---|---|
| Kimi CLI | 工程层，Python 代码 | 模型调 Agent 工具，工程层限流 |
| DeerFlow | 工程层，中间件 | 模型提议，中间件卡死在 6 个 |
| Kimi K2.5 Swarm | 模型层 | 模型自己（"self-directed"） |
如果这条路走通了，05 那四十多个中间件 里有一部分会变得多余——限流、路由、任务分解都在模型内部完成了。
但成本刹车不会消失。 恰恰相反：模型自主拆任务之后，Suna 那种「一直干净地成功却在死循环」的事故 只会更难查，因为你连调度日志都看不到了。
我的判断：编排会下沉，治理不会。做 Agent 平台的人，未来的价值会越来越集中在 DeerFlow 那份中间件清单 上，而不是在拓扑设计上。
这条判断已经有了一个可以直接调用的样本。 xAI 的 grok-4.20-multi-agent 把 leader 加子 Agent 的整套编排收进了一个模型 ID：换个模型名就从单 Agent 变成多 Agent，不写一行编排代码。而上一段那句「你连调度日志都看不到了」在它身上是字面意义的——子 Agent 的中间推理、工具调用和输出全部加密，默认不返回，打开开关拿到的也是只能喂回下一轮的密文。09 那篇 拆了这笔交易的完整价码。
六、全专题最该带走的七条
- 多 Agent 是特例不是默认。 决策树上有四个出口通向单 Agent。
- 判据是三条：只读还是写同一份、有没有隐式决策、能不能机械合并。
- 默认单层递归。 五家里三家硬禁止，唯一放开的那家也带三重刹车。
- 结果回收要两头治：下限逼它写详细（Kimi），上限确定性截断（DeerFlow）。
- 隔离粒度决定并发天花板。 同进程 3 路，一机一 Agent 上百路，中间没有免费午餐。
- 错误消息即 prompt。 限流、超时、失败的返回值里必须写清楚模型接下来该干什么。
- 最危险的失控是「一直成功」的死循环，且监控必须覆盖子 Agent——Suna 那两起事故都栽在这。
七、参考
- Cognition《Don't Build Multi-Agents》：https://cognition.com/blog/dont-build-multi-agents
- Anthropic《How we built our multi-agent research system》：https://www.anthropic.com/engineering/multi-agent-research-system
- Kimi K2.5 官方仓库：https://github.com/MoonshotAI/Kimi-K2.5
- Kimi K2 技术报告：https://arxiv.org/pdf/2507.20534
- LangChain 官方对这场争论的回应：https://www.langchain.com/blog/how-and-when-to-build-multi-agent-systems
- 下一篇：09 Grok Bot——反着走的隔离策略，以及编排下沉之后治理接口的缺口