闭环升级漏洞：当你的专精型智能体陷入循环路由

一个用于市场数据研究的多智能体系统在无人察觉的情况下，在四周内悄悄烧掉了 47,000 美元的推理成本。原本的每周账单仅为 127 美元。原因既不是流量激增，也不是模型升级——而是两个智能体在十一天里来回传递同一个对话，每个智能体都确信对方才是处理该请求的正确位置。没有任何报错。没有任何警报触发。一个机器人的“队列已转移”指标和另一个机器人的“任务已接收”指标都在同步增长，两边的仪表盘看起来都很健康。

这就是闭环升级漏洞 (closed-loop escalation bug)。它是两个热心的同事互相坚持“不，你来处理”的多智能体版本，只不过他们谁都不会感到厌烦并走开。你在设计时画的架构图中，每个专业智能体都拥有一块清晰的问题领域。而运行时实际执行的架构却包含了一个房间里没人能看到的路由循环。

这是一种在发布前评估中无法捕获的故障模式，因为从单个智能体的角度来看，其质量表现非常出色。你的客服智能体能正确回答客服问题。你的计费智能体能正确回答计费问题。漏洞存在于它们之间的衔接处——而这个衔接处不属于任何一个团队。

循环是如何形成的

起初的设置很平凡。你有一个客服智能体和一个计费智能体。客服智能体的路由提示词写着：如果是计费问题，移交给计费部门。计费智能体的路由提示词写着：如果是服务问题，移交给客服部门。每个提示词都由不同的子团队编写，经过独立评审，并在同一个监督者 (supervisor) 之下发布。

接着，一个真实用户提出了一个确实处于衔接点上的请求——“我从未收到的服务被扣了费，我希望恢复我的访问权限。”客服智能体读到了“扣费”并路由给计费。计费智能体读到了“恢复访问权限”并路由回去。由于监督者没有路由图的全局视野，它忠实地传递了每一条消息。对话弹跳了四十次，直到触发单次对话的 Token 预算或达到轮数限制，用户最后得到一个通用的兜底回复，说“让我为你连接人工客服”——而此时系统在这个单一请求上消耗的计算资源已经超过了人工客服一周的成本。

伯克利的研究人员系统地标注了七个流行多智能体框架中的 150 个生产轨迹，并在其 MAST 分类法中将此类问题归为“智能体间失调” (inter-agent misalignment)：即智能体基于谁负责什么的错误假设进行操作、忽略同伴信号，或未能验证是否有人正在取得进展。这三个顶层的故障类别——规范与系统设计故障、智能体间失调，以及任务验证与终止——共同导致了同一个结果：一个在不产生答案的情况下消耗资源的循环。

这种模式之所以如此容易发布，其结构性原因是路由逻辑是 局部 的。每个智能体仅根据其面前的信息决定将任务移交给何处。分布式系统工程师在这个特定的问题领域上花费了几十年的时间。生成树 (Spanning-tree)、BGP、IS-IS——第 2 层和第 3 层协议栈中的每种路由协议之所以存在，部分原因在于 局部路由决策可能会组合成全局循环，而停止这种循环的方法不是编写更好的局部启发式方法。通过工具调用和纯文本路由提示词进行移交的智能体框架，本质上是在构建一个路由架构，却缺乏路由社区在 20 世纪 80 年代就已经成为标准配置的循环检测原语。

为什么单智能体评估看不见它

大多数团队评估智能体的方式与评估其他模型输出的方式相同：输入提示词，对响应打分，然后重复。每个专业智能体根据自己的基准进行评分——计费智能体是否回答计费问题，客服智能体是否回答服务问题。两边都通过了。而真正能捕获此漏洞的评估切片——真正跨越两个领域的对抗性意图——正是没人编写的那部分，因为它处于两个团队评估套件之间的鸿沟中。

更糟糕的是，在循环对话期间，两边的现有仪表盘通常 都 显示为绿色。客服团队的仪表盘显示“智能体未提供帮助，已转接计费”——干净的移交，根据其定义是成功的。计费团队的仪表盘显示“队列错误，已转接客服”——根据其定义也是干净的。没有团队负责衔接处。没有任何团队的指标能反映出同一个对话 ID 在同一分钟内，连续 20 次在两个仪表盘上同时作为“转出”事件出现。

最近一系列关于智能体应用中无监督循环检测的研究，量化了这种现象在标准观测手段下是多么地不可见。在来自 LangGraph 股票市场应用的 1,575 个轨迹中，仅靠结构化调用栈分析发现循环的 F1 分数为 0.08，仅靠语义冗余检测的 F1 分数为 0.28。只有将两者结合的混合方案才能达到 0.72 的 F1 分数和 0.86 的召回率。换句话说：如果你的平台只是在观察“智能体是否返回了结果”，你几乎无法捕获流量中的任何循环。你需要同时观察 调用图的形状 和 消息的语义冗余。

必须落地的规范

将多智能体交付（handoffs）视为路由协议——而非领域抽象——在你第一次避免事故时，这种投入就值回票价了。必须存在的原语并不奇特；它们是生产级路由协议在很久以前就已解决的承重部分。

全局交付账本（A global hand-off ledger）。 对话的每一次交付事件都会记录到每一条对话的账本中，管理者（或路由端中间件）在做出每一次路由决策时都会读取该账本。规则很简单：对话不能在没有明确、经管理者确认的理由的情况下，重新进入一个它刚离开的智能体。账本存在于任何单一智能体的上下文窗口之外，因为不能指望任何智能体能在长对话中可靠地记住自己的路由历史。

加载中…