一场"Agent团队"的失败实验
2026年初，一家硅谷创业公司尝试用"多Agent协作"来构建一个AI客户支持系统。他们设计了5个Agent：一个负责"理解客户问题"，一个负责"搜索知识库"，一个负责"生成回复"，一个负责"质量审核"，一个负责"发送回复"。
理论上，这个设计很完美——每个Agent各司其职，像一支训练有素的团队。但实际运行结果是灾难性的：Agent之间的沟通产生了大量"幻觉传递"，Agent A的错误理解被Agent B放大，Agent C的回复被Agent D误判为"不合格"，整个流程的延迟比单Agent系统高了5倍，成本高了3倍，准确率反而降低了15%。
金句：多Agent协作不是"1+1>2"的魔法，而是"1+1可能<1"的陷阱。设计不当，Agent越多，问题越多。
三个最常见的坑
坑一：幻觉传递（Hallucination Cascade）
这是多Agent系统最致命的陷阱。Agent A产生了一个"幻觉"（如把客户的公司名称搞错了），这个幻觉被传递给Agent B，Agent B基于这个错误的公司名称检索知识库，检索到的是完全不相关的信息，Agent C基于这些不相关信息生成的回复自然是错误的，Agent D审核时可能认为"格式正确"就放行了。
在一个多Agent系统中，幻觉不是"被纠正"的，而是"被放大"的。每一个Agent都可能引入新的错误，错误在Agent之间传递时不断累积和放大，最终输出的质量可能比单Agent更差。
解决方案：在每个Agent之间设置"事实核查"节点。Agent A的输出在传递给Agent B之前，必须经过"事实核查"——验证关键信息是否准确。这增加了系统的复杂度和延迟，但可以有效阻断"幻觉传递链"。
坑二：由Agent选择下一个Agent（Agent-to-Agent routing）
这听起来很酷——Agent A完成任务后，自己判断"下一步应该由哪个Agent处理"，然后自动路由。但问题是：Agent A的判断经常出错。它可能把"技术问题"路由给了"销售Agent"，把"投诉"路由给了"FAQ Agent"。
更糟糕的是，错误的路由决策可能导致"无限循环"——Agent A路由给Agent B，Agent B觉得自己处理不了，又路由回Agent A，Agent A又路由给Agent C……Agent们在系统里像"无头苍蝇"一样乱转，消耗大量API费用，但问题始终没有被解决。
解决方案：不要用Agent做路由决策。用一个"确定性"的规则引擎或一个"专门的"路由Agent来做路由。路由逻辑应该简单、可预测、可监控。
坑三：多Agent的"沟通成本"被严重低估
多Agent协作有一个"隐形成本"——Agent之间的沟通成本。每个Agent需要"理解"上一个Agent的输出，这个"理解"过程需要消耗Token（即API费用）和时间。如果5个Agent协作完成一个任务，沟通成本可能占总成本的30-50%。
而且，Agent之间的沟通是"串行"的——Agent B必须等Agent A完成后才能开始工作。多Agent系统的总延迟，是所有Agent延迟之和，加上沟通延迟。在很多场景中，单Agent的延迟可能只有2-3秒，但多Agent系统的延迟可能高达15-20秒——用户早就等不及了。
什么时候该用多Agent？
多Agent协作不是"银弹"。它只适用于以下场景：
场景一：任务可以被清晰分解。 如果任务可以被分解为多个独立的子任务，且子任务之间依赖关系清晰，多Agent协作才有意义。
场景二：子任务需要不同的专业知识。 如果所有子任务都可以被同一个Agent完成，多Agent就是"过度设计"。只有当子任务需要不同的"技能"（如"翻译"需要语言能力，“数据分析"需要数学能力）时，多Agent才有价值。
场景三：任务的"可靠性"比"速度"和"成本"更重要。 多Agent系统通过"冗余"和"审查"来提高可靠性，但代价是速度和成本。如果速度或成本是首要考虑，多Agent可能不是最佳选择。
多Agent协作是一个强大的架构模式，但它不是"免费午餐”。在决定使用多Agent之前，先问自己：单Agent真的不够用吗？