做多 Agent 系统的第一周，我最大的感受是：管理 AI 比管理人还累。
人至少有常识——你说"去查一下这个数据"，他不会问"什么是数据"，也不会查完回来跟你聊半小时闲天。但 Agent 会。两个 Agent 对话能空转到让你怀疑人生。
这篇是踩坑记录，不是教程。坑都是我自己踩的，结论都是用真实代价换的。
为什么要多 Agent：单 Agent 先撞的墙
先说我为什么非要拆成多个 Agent。起因是单 Agent 撞了四堵墙：
- 上下文爆炸——所有工具描述、历史、检索结果塞一个窗口，几十轮之后开始"失忆"
- 角色冲突——一个 Agent 又要发散想方案又要严谨审逻辑，这两种思维模式在一个上下文里互相打架，输出质量两头都不行
- 工具过载——工具超过 20 个，选错率肉眼可见地上升
- 没法调试——一条长链路全在一个上下文里，出了错根本说不清是"哪一步想歪了"
拆成多 Agent 之后这四堵墙确实都缓解了。但新的问题来了——协作本身成为新的复杂度来源。
坑一：Agent 之间说废话
第一个坑，也是最搞笑的一个。
我搭了个"研究员 + 评审员"的双 Agent 对话，期望它们互相切磋、产出高质量方案。实际跑起来：
研究员: 方案 A 的优势在于实现成本低。
评审员: 你说得对，方案 A 确实成本较低。
研究员: 谢谢认可，我认为成本是关键因素。
评审员: 是的，成本很重要。五轮，零信息增量。token 烧了一堆，啥也没干。
解法是给每个 Agent 加硬约束：每轮必须输出新信息——新观点、新证据、或者明确的反对理由。纯附和的回复直接被系统判定为无效，强制重新生成。加了这条之后空转少了很多，但偶尔还会出现"换着花样说废话"——两个 Agent 用不同的措辞重复同一个观点。防不胜防。
坑二：上下文不同步
第二个坑更阴险，因为它不报错，只是结果错。
Agent A 在自己的上下文里有一份信息（比如"这个项目预算上限 50 万"），基于它做了决策"选方案 B"。Agent B 执行方案 B 时，它的上下文里没有这个预算信息，按无限预算的假设去执行——直接跑偏。
最气人的是这种错误从外面看不出来。B 的执行没有任何问题，每一步都合理，只是基于了错误的前提。
解法：设计 Agent 间消息协议时，要求显式携带决策依据，不只传结论。"选方案 B（因为预算上限 50 万，A 超预算）"比"选方案 B"多几个 token，但省掉了灾难。现在的默认规则：任何跨 Agent 的消息里，结论和依据必须一起传。
坑三：成本爆炸
这个坑不需要过多解释——数字自己会说话。
4 个 Agent 讨论 5 轮 = 20 次模型调用。每个 Agent 独立维护上下文，每次调用都是全量计费。一个单 Agent 跑一遍 2 块钱的任务，多 Agent 版本跑一遍 30 块。
15 倍。而质量提升可能只有 30%。
几个补救措施：
- 给整个系统设预算上限——到了就强制终止，哪怕任务没完成
- 非关键 Agent 换便宜的小模型——审校员不需要用和主推理同样的旗舰模型
- 能管道就别对话——流程确定的任务用管道式（A→B→C），不要用对话式。管道每步只调一次，对话可能聊五轮
坑四：调试是噩梦
单 Agent 出错，看一眼对话记录基本能定位。多 Agent 出错，你要追一条 A→B→C→A→B 的消息链路，每个 Agent 的完整输入输出都要看。没有一个好的日志系统，多 Agent 项目没法维护。
我的教训是：日志系统要在第一天就建，不是出了问题再补。每个 Agent 的每次调用，输入、输出、用了什么工具、推理了多少轮，全都要记。后来我用的是最笨的办法——每个 Agent 的每次调用存一个 JSON 文件，出问题顺着文件链看。土，但有效。
编排模式：两个维度的选择
踩完坑回头看，编排模式其实就两个维度：
维度一：中心化还是去中心化？
中心化（有个主 Agent 负责拆任务、分派、汇总）——流程清晰、容易追踪，但主 Agent 是瓶颈和单点故障。去中心化（没有主 Agent，大家在共享空间里对话）——灵活、能涌现，但难收敛、难调试。
我最终的落脚点是混合：一个轻量的 Orchestrator 管路由和汇总，但允许 Agent 之间在需要时直接通信。可控性和灵活性都能接受。
维度二：管道式还是对话式？
管道式（A 的输出直接给 B）——简单、可预测、易调试，但刚性——C 发现 B 有问题没法回头。对话式（来回讨论、互相纠正）——灵活、能自纠错，但难收敛、成本高。
我的经验：流程确定用管道，需要讨论再用对话，能管道就管道。大部分企业场景流程是已知的，不需要 Agent 自由发挥。对话式留给真正的开放性任务——方案头脑风暴、复杂决策这类。
角色设计的几条原则
多 Agent 系统的核心设计是"怎么分角色"。踩坑之后沉淀的几条：
按职责分，不按功能分。不要按"能做什么"分（那样每个 Agent 都能做很多事，边界模糊），按"负责什么"分。研究员负责信息收集、分析师负责数据处理、撰写者负责输出——每个角色的边界清晰。
角色之间要有信息差。如果两个 Agent 拥有完全相同的信息和能力，它们没有理由分开。好的分工是：每个 Agent 知道别人不知道的东西。
2-3 个角色最优，5 个是上限。角色越多，管理成本越高，协作链路越长，出错概率越大。不是角色越多越智能——是越少越好协作。
必须有终止条件。没有终止条件的多 Agent 讨论会无限循环。共识达成即停止、N 轮后强制停止、Orchestrator 主动叫停——三种都要有。
什么时候不该用多 Agent
写了这么多坑，必须说清楚反面：多 Agent 不是银弹，大部分场景不需要它。
- 任务流程简单、线性——单 Agent 加好工具就够了，编排开销不值得
- 上下文窗口装得下——单 Agent 够用就别拆
- 延迟敏感——多 Agent 的通信和协调会加延迟
- 预算有限——多 Agent 的成本是单 Agent 的好几倍
我的判断标准：当"角色冲突"或"工具过载"已经实际影响输出质量了，才拆。不要为了用多 Agent 而用。架构应该被问题驱动，不是被概念驱动。
一个意外的收获
最后记一个做技术时没想到的感受。
做多 Agent 系统的过程中，我慢慢发现：好的多 Agent 系统和好的人类团队，遵循同样的原则——角色清晰、信息透明、有终止条件、有成本意识。反过来，人团队里的很多毛病（推诿、空转、信息孤岛），在 Agent 团队里也原样复现。
这让我对这些技术的心态平和了很多。Agent 框架再新，底层逻辑还是人类几千年积累的组织智慧。技术新，道理不新。理解了这一点，既不会被新概念吓到，也不会盲目追新。