多 agent 系统

吸引力很明显：给每个 agent 一个角色，让它们协作，复杂工作就变得可处理了。一个研究员、一个写手、一个评审。

现实是，多 agent 系统比单 agent 更容易失败，原因值得先说在前面：可靠性会逐级衰减，而协作会增加步骤。 三个各 90% 成功率的 agent 串起来，你得到 73%。

在特定情况下，它们仍然值得搭。知道是哪些情况，能省下大量白费的功夫。

什么才真的值当用不止一个 agent

上下文隔离。 最有力的理由。每个 agent 各自拿到简短的记录，而不是让一个循环越攒越多。这直接针对限制了单 agent 长流程的上下文的二次增长——而且是唯一能规模化的理由。

真正的并行。 五个互相独立的子任务并发跑，就是五倍速度。这是真的，但只在子任务确实互不依赖时才成立。

独立的视角。 一个没看过写手推理过程的评审，能抓到写手抓不到的东西。让评审有价值的是新鲜的上下文，而这靠叫同一个 agent 自己检查自己的作业是模拟不出来的。

不同的工具集。 一个能访问数据库的 agent 和一个能部署的 agent，彼此隔开，谁都干不了对方的活。这既是能力上的理由，也是安全上的理由。

什么不构成理由

为了角色扮演而角色扮演。 让一个模型「扮演项目经理」、另一个「扮演工程师」，增加的是调用次数，不是能力。背后是同一个模型。

让难任务变简单。 把一个模型做不了的任务拆开，得到的是几个它同样做不了的子任务，外加协作开销。

因为听起来高级。 大多数工作里，一个工具配得好的单 agent 胜过一个 agent 委员会。

模式

主管型。 一个 agent 拆解工作、分派给专才，再汇总结果。控制流清晰，但主管会变成瓶颈和单点故障。

流水线型。 固定顺序，每个 agent 转换上一个的输出。可预测、好调试。注意，如果顺序确实固定，这就是一条工作流，根本不需要 agent。

并行扇出加汇总。 几个 agent 各自独立处理不同的部分，由一个 agent 合并。收益最明确的模式，因为并行是真的，协作开销很小。

辩论或互评。 一个产出，一个批评，反复迭代。评审有独立上下文时才管用，没有就退化成互相附和。

它们在哪儿崩

交接处的信息丢失。 agent A 知道某件相关的事，但它从没进到发给 agent B 的消息里。每一次交接都是一次有损压缩，而损失是看不见的。

错误传播。 一个错误结果传下去之后会被继续加工。后面的 agent 无从知道自己的输入是错的，还会自信地在上面加东西。

协作开销。 交接消息都是 token。同一件事，多 agent 系统常常比单 agent 贵好几倍。

责任分散。 输出错了，是哪个 agent 的锅？调试要把每一份记录都读一遍。

趋于一致。 建立在同一个模型上的 agent 共享它的盲区。写手和评审如果是同一个模型配不同的 prompt，就提供不了真正独立的判断。

怎么让它们管用

显式、带类型的交接。 明确定义 agent 之间传什么——用结构化输出，不用散文。这是价值最高的一条实践，因为它让信息丢失变得可见。

在边界上校验。 在下一个 agent 消费之前先检查上一个的输出。错误要在发生的地方抓住，而不是三步之后。

让图保持浅。 两层委派，不是五层。深度会同时放大成本和失败概率。

给每个 agent 窄的工具集。 工具越少，工具选择越准，也能限制爆炸半径。

把每条消息都记下来。 agent 之间的往来记录是你唯一会有的调试材料。

把总工作量做全局上限，而不是每个 agent 各自设限。否则五个 agent 各跑十轮，就是五十次模型调用。

诚实的建议

从一个 agent 开始。当你能说出第二个 agent 干了什么第一个干不了的具体事情时，再加它——通常是上下文隔离或者真正的并行。

大多数成功的生产系统，要么是一个范围划得清楚、工具配得好的单 agent，要么是一条固定流水线，在既定环节调用模型。精心设计的 agent 社会目前大多还只是演示。

要点回顾

• 可靠性逐级衰减，协作又增加步骤——多 agent 系统比单 agent 更容易失败。
• 站得住脚的理由是上下文隔离、真正的并行、独立视角和工具隔离。
• 角色扮演和任务难度都不构成理由。
• 失败集中在交接处：信息丢失、错误传播、成本、责任分散。
• 用带类型的交接，在边界校验，保持图浅，给总工作量设全局上限。

下一篇： Agent 记忆