多 Agent 协作正在从演示级玩法走向生产环境，问题也随之暴露出来：角色分工越细，系统越容易在局部协商里打转。对习惯确定性流程的工程团队来说，真正难的往往不是把 Agent 接起来，而是避免它们在看似忙碌的对话中持续消耗 Token、时间和预算。
这类问题不能只靠“换个更强的模型”解决，更有效的做法是把协作失控拆成几个可治理的层面。下面从死循环为什么会发生讲起，再分别落到观察者监控、状态机约束和资源止损三种常见方案，帮助你判断哪些措施适合直接放进生产系统。
为什么多 Agent 容易陷入死循环
多 Agent 协作里的死循环，通常不是偶发现象，而是系统结构天然会放大的结果。表面看是两个 Agent 一直在“讨论”，本质上却是三个底层问题叠加在一起。
语义镜像：彼此复述，误当成新信息
Agent 本质上仍是概率预测模型。当 Agent A 给 Agent B 一条指令，B 的回复如果重复了其中的关键词、约束或背景描述，A 很容易把这种复述误判为“确认”或“新增需求”。一旦双方都在对对方的话进行再加工，系统就会进入一种低信息增量的镜像对话：你复述我，我再复述你。
这种情况的危险在于，文字表面看起来一直在变化，但任务并没有实质推进。对于调研、写作、评审这类链式任务，它尤其常见，因为每个角色都天然倾向于补充上下文和提出修订意见。
幻觉补偿：做不出来时，继续把问题抛回去
第二个诱因是幻觉补偿机制。当某个 Agent 由于工具调用失败、知识盲区，或者上下文不足而无法完成子任务时，它未必会明确承认失败。出于“尽量有帮助”的倾向，它更可能生成一段模糊建议，或者把需求重新包装后丢给其他协作方。
问题在于，另一个 Agent 收到的已经不是清晰任务，而是一段模糊、带猜测色彩的请求。它只能继续补充模糊信息，于是系统就在低质量内容之间反复往返，最终把对话拖进垃圾信息堆里。
根因在于缺少全局状态机
最根本的问题，往往不是某个 Agent 不够聪明，而是整个系统没有显式的全局流转规则。早期的多 Agent 编排常常采用点对点自由对话，每个角色只看得到自己眼前的一小段上下文，无法判断整个任务处于什么阶段，也不知道何时应该停止争论、进入交付。
这也是为什么越来越多框架开始强调图式编排。像 LangGraph 这类方案，本质上是在用节点（Nodes）和有条件的边（Edges）把协作逻辑写成状态机，让原本开放式的聊天，变成一个可预测、可干预、可终止的工作流。
策略一：用“看门狗”观察者识别空转对话
如果你不希望每个 Agent 都自己判断“是否该停”，最实用的方式之一是引入一个不直接执行任务的 Supervisor，或者说观察者角色。它的职责不是参与内容生成，而是专门盯住协作过程有没有开始空转。
这种观察者模式的关键，在于做语义重合度检测。系统可以维护最近 N 轮对话的滑动窗口，对这些消息提取 Embedding，再通过欧氏距离或余弦相似度来判断最近几轮是否正在重复表达同一件事。
func (o *Observer) CheckLoops(history []Message) error {
if len(history) < 4 { return nil }
// 提取最近消息的 Embedding 并检测相似度
emb := getEmbeddings(history[len(history)-4:])
if isSimilarityTooHigh(emb) {
return fmt.Errorf("detect potential semantic loop")
}
return nil
}这段代码的思路很直接：只看最近几轮消息，提取语义特征，再判断它们是否高度相似。它不是在比对字面重复，而是在识别“措辞不同、逻辑相同”的回路，因此比简单关键词统计更适合生产场景。
一旦观察者判定存在风险，就不该继续把控制权交给协作 Agent 自己解决。更稳妥的做法，是由系统层强制插入一条 System Message，要求当前角色切换思路、输出最终结论，或者直接进入下一状态。这样做的意义，是把“停止空转”的责任从模型行为里抽出来，交给编排层处理。
策略二：用有限状态机把自由协作改成确定性流转
观察者适合发现异常，但如果想从源头减少死循环，仅靠监控还不够。更进一步的治理方式，是把多 Agent 的互动写进有限状态机（FSM），让每个角色只在允许的状态里做允许的动作。
在这种设计里，Agent 不再根据上下文“自由社交”，而是根据任务所处阶段流转。例如一个典型写作流程，可以显式拆成 Researching -> Drafting -> Reviewing -> Finalizing。这样做的核心价值，不是把流程画得更漂亮，而是给每一步建立清晰的输入、输出和退出条件。
先限制方向，再限制回退次数
状态机治理的第一步，是做严格的方向性控制。不是所有角色都可以随时向任意角色发起新一轮对话，更不是所有不满意都应该无限次打回重做。
例如在评审阶段，Review Agent 如果认为稿件质量不足，可以退回 Drafting，但退回次数必须设上限。文中的建议是最多 2 次；一旦超过这个次数，系统就不再允许 Research、Writer、Reviewer 继续彼此拉扯，而是强制切到“仲裁状态（Arbitration）”。
这个仲裁状态的作用，是引入更强模型进行一次性裁定，比如 GPT-4o 或 Claude 3.5 Sonnet。它不是为了让更强的模型继续陪着争论，而是为了切断原本无穷无尽的回退路径，给流程一个可执行的终点。
交付物必须结构化，别让“我觉得可以”进入流程
状态机要真正起作用，还需要第二层约束：强制交付物检查，也就是 Schema Validation。很多团队在设计多 Agent 协作时，最大的隐患不是模型答错，而是角色之间传递的结果太松散，像“我觉得还行”“建议再补一点背景”这样的自然语言很难作为稳定的工作流输入。
更可靠的方式，是要求 Agent 输出符合 JSON Schema 的结构化评估结果。比如评审阶段必须给出评分项、缺失点、是否允许进入下一阶段等字段；如果输出不符合规范，应由框架层进行拦截和重试，而不是把这份不合格结果继续丢给其他 Agent 解释。
这样做的好处很明确：把“沟通偏差”拦在框架层，而不是让多个 Agent 继续用自然语言互相猜测。对于生产系统来说，这比单纯优化 Prompt 更接近真正可控的工程手段。
策略三：加上预算、超时和降级，给系统留出止损出口
即便你已经有观察者和状态机，也不能假设系统永远按预期运行。生产环境里，总会遇到复杂任务、工具故障或上下文污染。这时候还需要最后一层物理防线：资源配额管理。
最直接的做法，是给每个多 Agent 任务设置对话预算，也可以理解为 Conversation Budget。它和网络治理中的令牌桶思路类似，不关注“谁说得更有道理”，只关心“这件事最多允许消耗多少轮对话”。
事实上，不少主流框架已经内置了这类熔断参数。比如 AutoGen 提供 max_consecutive_auto_reply，CrewAI 提供 max_iter。这些设置本质上都在做同一件事：当协作回合超过预期，就由系统直接截断，而不是继续纵容模型互相往返。
type TaskContext struct {
Budget, Round int
}
func (c *TaskContext) Consume() error {
c.Round++
if c.Round > c.Budget {
return errors.New("budget exhausted")
}
return nil
}这段代码体现的是最朴素也最有效的止损思路。任务一开始就定义好天花板，执行过程中每轮对话都消耗一次额度，超过预算就返回 budget exhausted。例如一个简单邮件撰写任务，只给 5 次对话机会，系统就不会因为两个 Agent 的意见分歧无限加码成本。
当共识迟迟不来，主动降温并强制交付
只有“超预算就停”还不够，真正成熟的系统还会在预算即将耗尽时提前介入。文章里给出了两个很实用的超时惩罚与降级手段。
第一是降低 Temperature。当对话进行到第 4 轮仍未形成结论时，可以把模型温度强制下调到 0.1，压缩它的随机性，让回复更保守、更聚焦，不再继续尝试新方向。这种做法不一定能让结果更优秀，但往往能让系统更快收敛。
第二是触发 Summarizer Intervention，也就是让专门的汇总 Agent 接管局面。它不再参与争论，而是把当前所有对话压缩成一份半成品结果交给用户，并明确说明系统因分歧被强制终止。对于 B 端应用来说，这种“宁可交付一个可解释的半成品，也不要无限等待完美答案”的思路非常关键，因为它直接关系到可用性和成本可控性。
多 Agent 治理的重点，不是更聪明，而是更可控
多 Agent 死循环本质上是一种缺乏中心调度的自发混乱。Research 和 Writer 互相打回、Reviewer 长时间不给出口，这些表面现象背后，其实都指向同一个工程问题：系统没有为协作设置明确的停机条件、回退边界和资源上限。
因此，治理思路也不该停留在“把 Prompt 写得更细”上。更有效的路线，是在架构层建立一整套防御性编排机制：用观察者识别语义空转，用有限状态机规范流转方向和回退次数，再用预算、超时和降级手段给系统留出最后的止损出口。
随着 Agentic Workflow 持续成熟，未来像 LangGraph 这类框架大概率会进一步内置冲突仲裁与死循环识别能力。但对开发者来说，核心竞争力已经越来越清晰：不只是让模型会做事，更要让系统知道什么时候该收敛、什么时候该终止，以及在失控前由哪一层接管。
在 AI 应用进入工程化阶段之后，真正可靠的系统标准也随之改变了。它不仅要能思考，更要能在合适的时候停下来。
