3个Agent互相甩锅后，我发现了多智能体架构的隐藏陷阱

去年有个数据：单智能体系统的平均故障恢复时间是23分钟，而多智能体系统——如果设计不好——能达到4小时。

这不是因为多智能体更脆弱，而是因为故障会传染。一个Agent的上下文溢出，会带着下游三个Agent一起跑偏。你以为是某个工具调用错了，实际上是路由层在第三层就把意图理解歪了。

为什么"把Prompt写长点"是死路

我见过最典型的单智能体崩溃：一个运维Agent被塞了47个工具，从kubectl到日历API全打包。前20轮对话还正常，第21轮它突然把生产环境的Pod删了——因为上下文窗口里混进了三天前的测试指令，它把"清理临时命名空间"理解成了"清理所有命名空间"。

上下文限制只是表象。更隐蔽的是工具干扰：当你给Agent太多能力，它在选择工具时会开始"幻觉"。一个本该查日志的请求，可能因为Prompt里某个模糊的词，被路由到写操作。

我试过把Prompt从2000 token扩到8000 token。结果不是更准，是更慢、更犹豫、更容易在无关知识里迷路。就像让一个人同时当外科医生、会计和厨师——不是做不到，是每个角色都变糙了。

多智能体的真实代价：调试链比调试点难10倍

转多智能体之前，得先算一笔账。三个Agent串联，可能的故障路径不是3条，是7条（单点故障3条+两两交互3条+全链路1条）。我在homelab里跑了一套控制实际基础设施的系统， stakes足够真实——弄坏了真的得爬起来修——但又允许我故意搞砸来观察。

最折磨的一次：用户请求"检查数据库延迟"，Orchestrator（编排器）路由给了SRE Agent，SRE Agent调了监控API拿到数据，返回时Summary写得太简略，Orchestrator理解成"延迟正常"，直接回复用户。实际上延迟已经飙到800ms，只是SRE Agent觉得"数值在阈值内"就没提。

这个链条里每个环节都"正确"执行了，但结果错了。多智能体的调试不是找Bug，是找责任归属。

但代价付出去，回报也是具体的。我跑了八个月，总结出四个实打实的收益：

专业化带来的复利效应。只处理Kubernetes的Agent，工具集可以极度精简——12个kubectl相关命令，没有别的。它的System Prompt可以针对运维场景调优，上下文永远干净。同样的问题，专用Agent的准确率比通用Agent高34%，这是我对比测试的数据。

上下文天花板被拆掉。长任务拆成子任务，Orchestrator生成子Agent，每个只处理片段，最后汇总。没有单个Agent需要看到完整问题。我跑过一次持续6小时的迁移任务，中间经历了17次上下文交接，零溢出。

隐私路由成为可能。这是被低估的。我的Ops Agent调用外部API查监控，但处理个人日历的Agent跑在本地LLM，数据不出LAN。单智能体架构里，这种隔离 impossible——同一个模型实例要么都能访问，要么都不能。

爆炸半径可控。只读Kubernetes状态的Agent，物理上就不可能删Deployment。权限最小化不是写在Prompt里的"请遵守"，是架构层面的硬边界。

路由模式：默认选择，但别神化它

最通用的架构是Orchestrator-Worker模式。User → Orchestrator → Specialist Agent → 结果汇总 → User。

Orchestrator的设计原则是最小权限。我的实现里，它只有7个工具：意图分类、Agent调度、结果格式化、错误重试、人工 escalation、对话历史管理、自身状态检查。没有kubectl，没有shell，不能直接接触任何基础设施。

这个设计让Orchestrator的上下文始终保持极短。它不积累工具调用结果，只读Summary。一次典型路由：用户输入（平均120 token）→ 意图识别（内部推理约400 token）→ 调度指令（80 token）→ 等待 Specialist 返回（不占用上下文）→ 结果格式化回复用户（200 token）。全程不到1K token。

但这里有坑。Orchestrator的意图分类必须足够细，否则 Specialist 会收到"模糊需求"然后猜错。我早期把"检查服务健康"和"排查服务故障"归为一类，结果SRE Agent在健康检查时过度诊断，浪费了API调用配额。

另一个坑：Summary的质量决定一切。Specialist 返回的结果如果太技术化，Orchestrator可能无法正确判断是否需要进一步处理。我现在的做法是强制 Specialist 输出结构化结果，包含"状态摘要""需要用户注意的事项""建议的下一步"三个字段，Orchestrator只解析这个结构。

什么情况下不该用多智能体

说点反直觉的。如果你的任务链固定、可预测、很少变化，多智能体是过度设计。一个精心调优的单Agent，配合Function Calling，可能更简单可靠。

我在homelab里保留了一个单Agent系统：专门处理定时备份检查。任务单一，输入输出格式固定，没有隐私隔离需求，也没有长上下文问题。强行拆成三个Agent，只会增加延迟和故障点。

多智能体的收益曲线是阶梯式的。复杂度跨过某个阈值后，收益陡增；但在阈值以下，纯成本。

那个阈值怎么判断？我的经验是：当你发现自己在Prompt里写"如果是A情况请做X，如果是B情况请做Y，如果是C情况请做Z……"超过三层嵌套时，就该考虑拆了。

最后留个我在跑的实验：如果让两个 Specialist Agent对同一个任务给出独立答案，Orchestrator做一致性校验，能 catch 多少隐性错误？初步数据是12%——不算高，但都是单Agent模式下会漏过去的"合理错误"。

这个方案的成本是延迟翻倍。值不值，我还在测。你们在生产环境里，会愿意为这12%多等3秒吗？