第 8 章多 Agent 不是银弹

"多 Agent"听起来就比"单 Agent"高级。但在你急着拆之前，先听一个数据：64% 的任务，单 Agent 就够了。

开篇：要不要试试多 Agent

我做那个群聊 Agent 做到中期的时候，遇到了瓶颈。

项目看着什么都有点——能对话、能记忆、能建项目，但实际跑起来又一言难尽。换模型、改代码，结果都会抖动，很不稳定。所以我跟 Claude Code 吐槽说："这个项目开发到现在进入瓶颈了，看似什么都有点，实际跑起来又一言难尽。"

得找找出路。那段时间多 Agent 协作正好是大家讨论的热点——一个 Agent 管对话，一个 Agent 管编码，听起来分工明确、各司其职。我就琢磨，是不是该往这个方向试试。

但我没有急着动手。老规矩——先让 CC 帮我调研，看看业界怎么说。

调研结果给我泼了一盆冷水。

一盆冷水：64% 的任务，单 Agent 就够了

CC 搜回来一个让我意外的数据。普林斯顿 NLP 做过一项研究：在 64% 的基准测试任务中，单 Agent 匹配或优于多 Agent 系统。

64%。接近三分之二。

这不是某个边缘实验室的结论。制造了 Devin 的 Cognition 团队专门写了一篇文章叫《Don't Build Multi-Agents》（别建多 Agent 系统），给了三条理由：

子 Agent 天生缺乏完整上下文。 两个 Agent 看到同一个问题的不同方面，会做出互相冲突的决策。
行动隐含决策。 Agent 的每个操作背后都有一堆隐含的设计决策，另一个 Agent 不了解这些决策，就会产生矛盾。
连 Claude Code 自己的子任务模式，也只做研究（读取），不做写入。 因为子任务 Agent 缺乏主 Agent 的上下文，一旦写入就容易搞乱。

LangChain 也有一个很精炼的洞察："主要做'读取'的多 Agent 系统比主要做'写入'的更容易管理。" 读取操作天生可以并行（你查你的、我查我的，不打架），写入操作会产生冲突（你改了这个文件、我也改了这个文件，谁说了算）。

这些资料的核心信息是一致的：多 Agent 不是银弹。它引入的复杂性——上下文同步、决策冲突、通信开销——往往超过它的收益。

那什么时候才该用多 Agent？

资料看完了，我回到自己的项目，认真想了一个问题：我的场景，到底需不需要多 Agent？

我的 Agent 跑在群聊里，能对话、能记忆、能管项目。但有一类活它做得不太好——写代码、搞开发。比如有人说"帮我做一个周末出游的攻略网页"，我的 Agent 对话能力没问题，但让它写代码、做网页就力不从心了。

这时候我有两个选择：

选择 A：让 Agent 自己硬啃。 理论上可以——给它加一个代码生成的工具。但这样做的成本很高，而且我的 Agent 用的是对话模型，编码能力本来就不是它的强项。

选择 B：引入另一个擅长编码的 Agent。 让对话能力强的 Agent 当"项目经理"，让编码能力强的 Agent（Claude Code）当"开发"，PM 调用开发完成具体任务。

我选了 B。理由是：这两个能力genuinely 互补——一个擅长中文对话和群聊协调，一个擅长编码和文件操作，这些能力没法在一个 Agent 里有效组合（对话模型写代码不行，编码模型做群聊 PM 不自然）。

这就是引入多 Agent 的判断标准，就三条：

确实需要不同的专业能力
这些能力无法在单 Agent 中有效组合
任务复杂度超过单 Agent 的上下文管理能力

三条都满足才值得拆。如果只是"一个 Agent 慢，拆成两个加速"——不值得，协调成本会吃掉你省下的时间。

子 Agent 是工具，不是同事

在决定引入多 Agent 之后，还有一个关键的认知需要建立。

很多人一听到"多 Agent 协作"，脑子里浮现的画面是"两个 AI 在开会讨论"。不是的。子 Agent 不是同事，是工具。

这是我在调研过程中最重要的一个认知转变。Cognition 那篇文章里说"子 Agent 缺乏主 Agent 的完整上下文"——这不是缺陷，这是设计。你不应该期望子 Agent 理解主 Agent 的全部思考过程。你给它一个结构化的任务，它返回一个结构化的结果，结束。

就像你叫外卖——你不需要骑手理解你为什么想吃这顿饭、你今天的营养计划是什么。你给他一个地址，他把饭送到，交易结束。子 Agent 就是那个骑手。

这个认知直接影响你怎么设计协作接口：

传入结构化任务规范，不是自然语言闲聊（"帮我做个网页"不行，"项目计划文件在 plan.md，请读取后生成 index.html"才行）
返回结构化结果，不是一篇散文（"文件已生成在 /path/to/index.html，大小 15KB"才行，不是"我做好了一个漂亮的网页"）
不共享上下文，靠文件交接（主 Agent 把信息写进 plan.md，子 Agent 去读）

这三条，就是后面第 9 章要讲的"双 Agent 协作五要素"的理论基础。

一个反直觉的结论

写到这里，我可以给出这一章的核心结论了：

多 Agent 不是"更高级的 Agent"。它是一个"有明确适用条件"的工程手段。

如果你的任务是"读取 + 汇总"（比如让多个 Agent 分别搜索不同来源，然后汇总），多 Agent 是合理的——读取可并行，不冲突。

如果你的任务是"写入 + 改变状态"（比如让多个 Agent 同时改同一份代码），多 Agent 是危险的——写入会冲突，且子 Agent 缺乏全局上下文。

大部分时候，一个设计良好的单 Agent 加上好的工具，比两个互相不知道对方在想什么的多 Agent 强得多。 只有当能力 genuinely 互补、且无法在单 Agent 内组合时，才值得承担多 Agent 的协调成本。

我的群聊 Agent 引入 Claude Code 当"开发"，是因为对话能力和编码能力确实无法在一个模型里同时做好。如果你的场景没到这一步，别急着拆。

这一章的工具：要不要引入多 Agent 的决策清单

🔧 多 Agent 决策清单

在决定引入多 Agent 之前，过一遍这个清单：

先问自己三个问题

[ ] 我真的需要两种不同的专业能力吗？（还是只是觉得"多就是好"）
[ ] 这两种能力真的没法在一个 Agent 里组合吗？（试过给单 Agent 加工具了吗）
[ ] 任务的复杂度真的超过单 Agent 的上下文管理能力了吗？

如果三个都不满足——别拆，把单 Agent 的 harness 做好更值得。

如果决定拆，再问三个问题

[ ] 两个 Agent 的能力是 genuinely 互补的吗？（不是"一个能干的活拆成两半"）
[ ] 任务主要是"读取"还是"写入"？（写入型需要更小心的协调）
[ ] 你准备好了协调成本吗？（上下文传递、产出验证、冲突处理——每一个都是工程量）

最危险的信号

[ ] 你想引入多 Agent 只是因为单 Agent"不稳定" → 多半是 harness 没做好，拆了更不稳定
[ ] 你想让多个 Agent"讨论"来解决问题 → 子 Agent 缺乏完整上下文，讨论质量不会高
[ ] 你觉得多 Agent"更先进" → 64% 的任务单 Agent 更优，先进不等于合适

小结

这一章的核心结论就一句话：多 Agent 不是银弹，64% 的任务单 Agent 就够了。

只有当能力 genuinely 互补、无法在单 Agent 内组合时，才值得拆。而且拆了之后，子 Agent 是工具不是同事——传结构化任务、收结构化结果、靠文件交接。

如果你判断完了，确实该拆，那下一章我们就讲——拆了之后，怎么让两个 Agent 稳定协作。

第 9 章 · 双 Agent 协作五要素 —— 能力互补确定之后，怎么把协作做到工程闭环。