多智能体系统（MAS）从单机 Demo 走向高并发生产环境后，随着协作链条拉长与 Agent 数量增加，系统会呈现出极高复杂度的分布式特征。在缺乏全局治理机制的情况下，它必然会撞上三类生产级事故。
原文作者整理的灾难清单非常直白。一是“礼貌死锁与死循环”，Agent A 和 Agent B 互相谦让客套，或反复反驳，陷入无限对话死循环，架构根因是缺乏基于状态转移的终态判定、缺乏最大迭代次数与语义停机门禁。二是“通信与 Token 风暴”，一次代码变更触发全网广播，10 个子代理并发交互，5 分钟消耗约 500 美元，根因是缺乏增量信息裁剪与消息去重，广播风暴引发调用成本指数级爆炸。三是“依赖环路与级联阻塞”，Agent 1 依赖 Agent 2、Agent 2 依赖 Agent 3、Agent 3 反向依赖 Agent 1，根因是缺乏 DAG 依赖图的静态拓扑校验与分布式超时看门狗（Watchdog）。
导读中还描述了两个典型画面：两个 Agent 在群聊里互相道歉 20 轮；A 等 B 的输出，同时 B 也在等 A 的输出。原文作者给出的判断是：智能体系统的稳定性，永远不取决于它顺畅时跑得多快，而取决于它失控时能否瞬间被兜底和熔断。
死锁与死循环的三大经典模式
在分布式 Agent 系统中，原文作者将死锁主要分为三类：
- 循环等待死锁（Circular Wait）：A 等待 B 提供接口文档，B 等待 A 提供数据模型，双方永久挂起。
- 乒乓驳回死锁（Ping-Pong Reject）：Coder 提交代码 → QA 驳回 → Coder 微调重提 → QA 再次驳回……
- 客套发散死锁（Polite Echo）：Agent A 说“感谢您的建议”，Agent B 回“不客气，请问还有什么需要？”
对应地，原文给出死循环的三级判定与治理机制。第一级是硬迭代计数器（Hard Iteration Limit）：任何子任务流转超过预设阈值（如 3~5 轮），系统无条件强制挂起。第二级是语义相似度指纹检测（Semantic Fingerprint Hashing）：对连续 3 轮的回复内容计算 Embedding 余弦相似度，如果相似度超过 0.95，说明在原地打转或反复说车轱辘话，立即判定为死循环。第三级是仲裁者接管模式（Escalation & Arbitration）：触发熔断后，流程自动转入仲裁 Agent 或通知人类工程师介入，打破自我循环。原文作者对此的总结是：信任大模型的推理，但永远不要信任大模型的自觉性，必须通过外部确定性看门狗来强制终止死锁。
通信与 Token 风暴治理：多智能体网关
为了防止广播风暴与 Token 账单雪崩，系统必须在 Agent 之间建立统一的 Multi-Agent Traffic Gateway。原文给出三项治理机制：增量差分传递（Delta Streaming），仅同步 Diff 或变更 Summary，严禁全量搬运前序对话历史，避免每次通信全量回传 50K 历史，上下文开销降低 80%；局部会话沙箱（Sub-Context Box），子代理在独立会话中执行，完成后仅向主控返回结构化终态结论，中间试错报错被物理隔离，主 Agent 永远保持高信噪比；动态 Token 预算（Budget Quota），任务级别分配 Token 硬配额，如单个子任务硬限 10,000 Token，某个任务即使卡死，最多消耗预设配额，不会打爆全公司账户。原文作者的一句话是：限制通信范围，裁剪冗余增量，分配硬性预算。这是多智能体系统在企业落地时的经济学红线。
网关核心实现拆解
原文给出的实战代码基于 Python 3.11+，核心由三部分组成。TaskBudget 是基于 Pydantic 的预算模型，字段为 task_id、max_tokens（默认 20000）、consumed_tokens、max_turns（默认 5）与 current_turn。DeadlockDetector 是死锁与死循环检测看门狗，构造参数 repeat_threshold 默认为 3，内部维护 message_history 列表；record_and_check 把 sender、receiver 与消息摘要前 60 个字符拼成指纹写入历史，再取最近 N 条做集合去重，若最近 3 条完全相同则返回 True，判定为重复的乒乓调用。
MultiAgentGovernanceGateway 是网关主体。register_task 注册任务并同时创建预算与检测器；inspect_and_route 是通信拦截与安全路由入口，按顺序做四道判断：未注册的 task_id 直接拒绝；current_turn 自增后超过 max_turns，返回熔断原因；consumed_tokens 累加 estimated_tokens 后超过 max_tokens，返回预算耗尽；死锁检测命中，返回重复通信循环。任何一道不通过都返回 allowed=False 与对应 reason，全部通过则返回 allowed=True、current_turn 与 remaining_budget。原文作者将其定位为完整包含任务级 Token 配额管理、死锁看门狗与降级熔断的核心实现。
工程视角的补充分析
（以下为工程分析，不属于原文作者结论）
从这套实现出发，可以把它理解为“把不确定性挡在网关之外”。三个检查项对应三种不同的失效语义：轮次上限防的是逻辑上无法收敛，Token 预算防的是成本上无法收敛，指纹去重防的是语义上无法收敛。顺序也有讲究——先做最便宜的计数判断，再做需要累加的成本判断，最后才是需要维护历史的重复检测。
需要留意的边界是：Token 消耗用的是外部传入的 estimated_tokens 而非精确计量；指纹只比对最近 N 条完全相同的记录，对“内容不同但语义相同”的乒乓驳回并不敏感，这类情况要靠第二级的 Embedding 相似度兜底。因此工程上通常把计数器、预算与指纹当作第一道闸门，把语义相似度与仲裁者接管当作后手，而不是二选一。
单 Agent 与 Multi-Agent 的可靠性差异
原文导读给出了最凝练的对照：单 Agent 最怕死循环，Multi-Agent 最怕“礼貌扯皮”和“逻辑死锁”。结合前述事故清单可以进一步看到：多 Agent 的故障发生在协作拓扑层面，消息会随 Agent 数量往返放大，一次小重构派发 10 个子 Agent，就可能瞬间打满百万 Token 账单。这正是治理手段必须从“在提示词里写一句别死循环”，升级为“外部网关 + 硬预算 + 看门狗”基础设施的原因。原文作者的结论是：先做熔断再谈智能，是多智能体系统在企业生产环境立足的第一法则。
本篇总结
多 Agent 系统的最大敌人是未受控的死循环与 Token 账单爆炸；应建立三级死锁判定，即硬迭代计数器、语义指纹比对与人工仲裁接管；应部署 Multi-Agent 网关，通过增量差分传递、独立子会话沙箱与任务级 Token 配额进行严格治理；先做熔断再谈智能，是多智能体系统在企业生产环境立足的第一法则。
本篇为《企业级 Agent 实战指南》第三章《Multi-Agent 架构设计：从单体 ReAct 到群智协同》（共 4 篇）的第 4 篇，也是该章收官之作，作者为吴佳浩（Alben），公众号“全栈架构师笔记”。后续将开启第四章《企业级 Agent 质量保障体系：Evaluation 与安全防线》，构建端到端的 Agent 自动化评测与可观测性链路。