单 Agent 还是多 Agent：四家生产结论对撞
一句话：这个问题没有通用答案，但有一个非常清晰的判据——你的子任务之间有没有共享的隐式决策。
一、正面对撞
2025 年 6 月，两篇博客隔了几天先后发出来，标题几乎是对 着干的。
Cognition：《Don't Build Multi-Agents》
他们的论证是两条原则：
原则 1：Share context, and share full agent traces, not just individual messages 原则 2：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 把对话历史总结成关键细节和决策
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 安全。写同一份 → 隔离会打架。
② 有没有大量没法写进任务描述的隐式决策？ 有 → 单线程。没有 → 可以拆。
③ 结果能不能机械合并？ 能（列表、表格、事实集合）→ 拆。要人工缝合风格和逻辑 → 别拆。
Flappy Bird 三条全中，所以拆了就崩。研究任务三条全反，所以拆了提速 90%。
一个更有意思的证据：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 决定 |
三条横着看才能发现的规律：
规律 1：隔离粒度和并发上限是同一件事的两面
| 隔离单位 | 代表 | 并发量级 |
|---|---|---|
| 一台 VM | Manus | 上百 |
| 一个沙箱容器 | Suna | 数十 |
| 一个 LangGraph 分支（同进程） | DeerFlow | 3 |
隔离越重，反而并发越高。 因为轻量隔离共享同一个进程的资源，并发天花板由进程决定；重隔离往外扩就是加机器。
所以「我要不要上重隔离」这个问题，等价于「我要不要几十上百路并行」。要，就得付 VM 的钱；不要，同进程 3 路够用。
规律 2：禁止递归是压倒性多数
四家有明确表态的里，三家禁止（Kimi 硬编码、DeerFlow 默认禁、Manus 推测单层），只有 Claude Code 默认允许 3 层。
而且 Claude Code 的允许是带刹车的允许：深度计数器、到顶撤走工具、Agent(type1, type2) 限定可派工种。没有一家是无限制放开的。
结论：默认单层，除非你能说清楚为什么需要更深。
规律 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 那份中间件清单 上，而不是在拓扑设计上。
六、全专题最该带走的七条
- 多 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