那个因等待另一个 Agent 而死锁的 Agent

一个研究员智能体向一个检索智能体请求一份文档。检索智能体在任务执行到一半时，决定需要研究员智能体澄清查询意图后才能继续搜索。而正在等待文档的研究员智能体，在拿到文档之前不会做出响应。它们谁都没有出错，也没有陷入死循环。它们只是都在礼貌地、无限期地等待着对方——而你的编排器（orchestrator）根本没有“这两个智能体正在互相阻塞”的概念，它会一直愉快地维持这个状态，直到你从未配置过的超时设置最终触发，或者直到某个大活人注意到这个运行已经“进行中”整整 40 分钟了。

这就是死锁（Deadlock）。它是计算领域最古老的故障模式之一，且与你的模型有多聪明毫无关系。它是工作协调方式的一种属性，而不是工作执行方式的属性。过去一年多智能体研究中一个令人不安的发现是：在智能体集群中，大部分出问题的地方都在这里，即协调层，而不是任何单个智能体的推理能力。

单智能体思维永远无法暴露这些 Bug。当一个模型运行工具调用循环时，它最坏的情况也就是空转——而空转至少是肉眼可见的。一旦你拥有两个或更多可以互相等待的智能体，你就继承了分布式系统所有的病理特征：循环等待、活锁、丢包、过早终止、共享状态下的竞态条件。没有人会坐下来决定构建一个分布式系统，但在你添加第二个智能体的那一天，你就已经构建了一个分布式系统。

协调才是故障真正的源头

当多智能体系统表现异常时，人的本能是换一个更大的模型。这种本能通常是错误的。过去一年发布的各种大规模追踪研究都得出了相同的结论：系统级故障集中在协调（coordination）和规范（specification）上，而非原生能力上。

其中被引用最多的一项研究——基于对 7 个流行智能体框架中 1,600 多个带注释的执行追踪进行的分类，具有很强的评估者间一致性——将 14 种不同的故障模式分成了三个桶。规范问题约占故障的 42%：角色模糊、任务未定义、缺少约束。协调崩溃占了另外 37%：通信失败、状态脱节、智能体不知道何时停止。验证缺口占剩余的 21%。请注意，名单上没有这一项：“模型不够好”。生产环境中的多智能体系统故障率据测量在 41% 到 87% 之间（取决于任务），而主要原因在于智能体无法可靠地进行协调——而不是它们个体无法思考。

死锁是最典型的例子，因为它是分布式系统工程师一眼就能认出来的。一项竞争基准测试让 5 个智能体在一个房间里，在没有智能体间通信的情况下竞争共享资源，结果显示在处理相同任务时，尖端模型的死锁率在 25% 到 90% 之间。模型之间的差异告诉你这部分是行为问题；而即使是最好的模型也会在四分之一的时间里陷入死锁，这告诉你这是结构性问题。你无法通过提示词（prompt）逃离循环等待。

智能体卡住的四种方式

给具体的停滞状态命名是有帮助的，因为每种状态都有不同的修复方法，而且它们很容易被懒惰地归类为“智能体挂了”。

**死锁（Deadlock）**是循环等待。智能体 A 持有资源 X 且需要 Y；智能体 B 持有资源 Y 且需要 X。谁都不让步。在智能体系统中，“资源”很少是数据库锁——它更多时候是一段上下文、一个决策或对话中的一个回合。智能体 A 在 B 确认之前不会回答；B 在 A 回答之前不会确认。经典的 Coffman 条件依然适用：互斥、请求与保持、不可剥夺和循环等待必须同时成立。打破其中任何一个，死锁就无法形成。

**活锁（Livelock）**更难调试，因为系统看起来很忙碌。两个智能体不停地互相响应、不断采取行动、不断消耗 Token——但全局状态从未推进。一个规划者把工作交给评审者，评审者带个备注退回，规划者重新制定再交回去，如此循环往复。每个环节看起来都很健康。你唯一的症状就是 Token 账单，而它要在月底才寄到。

**循环交接（Cyclic handoffs）**是同一种疾病的路由版本。智能体 A 认为这项任务属于 B，B 认为属于 C，C 认为该回给 A。每一次交接在局部看来都是合理的。只有在有人跟踪完整路径时，这种循环才可见。步骤重复（Step repetition）——由于历史记录在跳转之间丢失而导致同一动作被重新执行——在追踪中被显示为最常见的单项故障模式之一，发生率约占失败运行的六分之一。

**都在等待同一个工具（Both-waiting-for-a-tool）**是资源竞争的表现。两个智能体需要同一个受限的 API、同一个文件锁，或同一个只允许单调用者的下游服务。如果没有分配规则，它们要么发生冲突，要么各自退缩等待对方先走，而这种“礼貌版”冲突就是停滞。

为什么你的编排器察觉不到

加载中…