Multi-Agent 复盘：我为什么删掉了两个 Agent

五月份我给自己搭了个看起来很美的系统：一个 Orchestrator 负责拆任务，一个 Coder 负责写代码，一个 Reviewer 负责把关。三个 Agent 各司其职、互相制衡，画在架构图上像那么回事。

两周后，我删掉了其中两个。这篇是复盘。

实际发生了什么

• 上下文接力损耗：Orchestrator 的意图传到 Reviewer 时只剩一半。Reviewer 经常基于一份被简化过的理解，提出「正确但无关」的意见；
• 错误放大：一环的小错到下一环被当成事实，错误带着信心往下传，越传越理直气壮；
• 调试像拆盲盒：三个会话三本账，出了问题要回放半天，才知道是哪一环开始歪的。

最讽刺的是，为了「让它们更好地协作」，我写的协调代码，比被协调的业务逻辑还多。

删成单 Agent 之后

结构变成：单 Agent + 一份显式的检查清单 + 上一篇文章里说的那套工具设计。

在我自己的小任务集上（非严格统计，看看就好）：完成率从六成左右提到九成，token 成本几乎减半。原因不难理解——没有信息损耗，所有上下文都在一个会话里；出错时只需要看一条时间线。

什么时候才值得拆

我现在的清单是三条，满足其一再考虑：

• 真正可并行：子任务互不依赖，比如批量处理互不相干的输入；
• 需要不同档位的模型：贵的干难活，便宜的干粗活，省钱且各得其所；
• 需要权限隔离：一个只读做分析，一个可写做执行，出错半径可控。

除此之外的多 Agent，多半是用架构复杂度去掩盖工程没做扎实。

多 Agent 是扩展手段，不是默认架构。先把一个 Agent 做到可靠，再考虑拆。

· 完 ·