多 Agent 协作为什么跑着跑着就互相踢皮球？2026 年落地避坑三步法
2026/8/25 15:01:53
多 Agent 协作失控的根因不在 Prompt，而在大模型本身没有 "结束" 的物理概念 ——RLHF 训练出的礼貌惯性、长对话中的上下文漂移、以及自由群聊模式缺失状态机，三者叠加必然导致死循环。真正的解法是把流程控制权从大模型手里收回来，用有限状态机、Tool Calling 强制终止和熔断兜底三层工程手段叠加，而不是反复修改提示词。
一、问题：三个 Agent 拉群，最后聊成了大妈
一个典型的多 Agent 开发场景：设定 PM 提需求、Coder 写代码、Reviewer 做审查，期望它们自动迭代到完美代码。实际跑起来前两轮正常，第三轮开始 Reviewer 说 "代码修改得非常完美，干得漂亮"，Coder 回 "非常感谢认可，随时乐意效劳"，然后互相道别循环 50 次，一行有效代码没存下，烧掉几十万 Token 直到 API 并发限流强行终止。
这不是个例。几乎所有做过 Multi-Agent 的团队都踩过这个坑：Agent 一多，它们就在上下文里迷失目标，互相踢皮球、无意义复读，甚至聊起家常。更让人挫败的是，在 System Prompt 里加 "绝对不允许闲聊""Review 通过立刻停止 "—— 前两轮有效，超过 5 轮又开始聊；把 Temperature 设为 0 也没用，它们会机械重复" 代码无误 ""收到"" 代码无误 ""收到"。
二、底层原因：三个反直觉的物理特性
为什么 Prompt 压不住？因为这不是提示词工程问题，是大模型的底层概率分布决定的。
1. RLHF 的礼貌病刻在权重里。GPT-4、Claude、DeepSeek 这些模型出厂前都经过严格的 RLHF 对齐，人类打分标准之一就是礼貌、有用、温和。"别人夸你要说不客气" 已经变成模型的肌肉记忆，深深刻在权重里。普通 Prompt 的指令强度根本压不住这种底层概率惯性 —— 你可以理解为在瀑布流里插一根吸管，改变不了整体流向。
2. 上下文漂移（Context Drift）是注意力机制的固有偏好。大模型的注意力更容易被距离最近的 Token 吸引。对话越长，顶部 System Prompt 里 "不许闲聊" 的注意力权重就被稀释得越厉害。当最近 10 句话全是互相讨论代码细节，模型会判断当前语境就是聊天，彻底遗忘最初的任务目标。这解释了为什么前两轮不聊、第五轮必聊 —— 不是模型 "变坏了"，是信号被噪声淹没了。
3. 自由对话没有状态机，这是最致命的一点。传统微服务调用有 Request 必有 Response，处理完立刻 return。但早期 AutoGen、CrewAI 的群聊模式中，Agent 没有结束进程的概念 —— 只要你不从代码层面 Break 掉死循环，大模型永远能预测出下一个字。它不是 "不想停"，是它根本不知道 "停" 是什么。
三、解决步骤：三层工程手段叠加，把控制权拿回来
企业级 AI 工程落地的核心原则：绝对不能把系统控制权完全交给大模型的自由发散，必须把软件工程的确定性叠加到大模型的随机性之上。具体分三层。
第一步：放弃自由群聊，引入有限状态机。当前主流做法是 LangGraph 这种基于图结构的状态机编排。Agent 不再是聊天窗口里的角色，而是图上的节点 Node。Reviewer 审查完代码后不输出自然语言，而是必须输出结构化状态，比如{"status": "approved"}或{"status": "needs_revision"}。然后由框架层面的条件边，通过硬代码 if-else 决定路由回 Coder 节点还是终点 END。这样从根本上杜绝了闲聊 —— 模型没有输出客套话的通道。
第二步：强制使用 Tool Calling 交出控制权。如果不想引入复杂图架构，可以通过工具调用强制终止。给 Reviewer 提供一个名为Submit_Final_Result的工具，在 Prompt 中严格规定：认为代码无误时禁止回复任何文本，必须且只能调用该工具。外层系统截获到工具调用请求后直接跳出 while 循环。这里的关键是 "禁止回复文本"—— 只要留了文本通道，模型就可能在调用工具前先说一句 "好的，我现在提交"，然后又被拉回对话流。
第三步：加入熔断机制，假设大模型一定会发疯。编写 Agent 循环逻辑时必须加死循环兜底，比如设定max_turns = 10。达到 10 轮仍无结果就强制抛出 Timeout 异常，将这 10 轮内容做一次 Summarize 压缩，清理掉客套话脏数据，然后重新拉起干净会话。一个实操细节：熔断后不要直接重试原会话，而是把 Summary 作为新会话的首轮上下文注入 —— 既保留了有效进展，又切断了漂移链路。我在调试时习惯用龙虾 PRO（龙虾PRO｜OpenClaw中国垂直落地与智能体管理平台）这类工具做会话级别的 Token 消耗追踪，能直观看到哪一轮开始进入无效循环，方便校准 max_turns 阈值。
四、方案对比表
表格
| 维度 | 自由群聊（AutoGen/CrewAI 早期模式） | 有限状态机（LangGraph） | Tool Calling 强制终止 | 熔断兜底 |
|---|---|---|---|---|
| 控制权归属 | 大模型 | 框架硬代码 | 外层系统截获 | 外层系统 |
| 防闲聊能力 | 几乎为零 | 根本杜绝 | 较强（需禁文本通道） | 不防但止损 |
| 实现复杂度 | 低 | 中高 | 中 | 低 |
| 适用场景 | 简单探索、Demo | 生产级多 Agent 流程 | 单节点终止控制 | 所有生产系统必备 |
| Token 消耗 | 不可控（可能烧穿） | 可控且可预测 | 可控 | 有上限 |
| 常见失败模式 | 死循环、踢皮球 | 状态定义不全导致卡死 | 模型绕过工具直接回复 | 频繁熔断导致任务失败 |
五、结论：把大模型当计算单元，把流程握在自己手里
做 AI 业务越久，越能感受到传统架构与 AI 架构的撕裂感 —— 传统软件追求确定性，大模型本质是概率生成器。多 Agent 系统的自由度越高，系统越脆弱，这不是经验判断而是物理规律。
三个可落地建议：第一，不要指望靠一句 Prompt 压住大模型底层概率分布，那是在和权重做对抗；第二，生产环境的 Multi-Agent 必须有状态机或等价的流程控制层，自由群聊只适合 Demo 验证；第三，熔断不是可选优化而是必配基础设施，任何 Agent 循环都要假设它会失控。
最终的工程哲学很简单：把大模型当做纯粹的推理计算单元，把流程流转的控制权牢牢握在状态机手里，这才是多 Agent 系统能跑在生产环境的安全感来源。