十万个why：多个 Agent 协同干活，为什么跑着跑着它们开始互相“踢皮球”甚至聊起天了？
AI写代码？小心智能体在群里开茶话会
前不久，团队里尝试搭建了一个基于多智能体（Multi-Agent）的自动化编程系统。构想很美好：设定三个明确的智能体角色——产品经理（提需求）、程序员（写代码）、审查员（做代码审查）。
大家原本想得挺简单：给它们拉个“工作群”，扔个需求进去。程序员写码，审查员提意见，程序员再修改，几个回合下来，一份完美的源码就该唾手可得了。
结果系统一跑起来，场面迅速失控。
开头几轮还算正常，程序员写了代码，审查员也确实指出了两个缺陷。但到了第三轮修改之后，大模型就开始“表演”了。
后台的对话日志逐渐演变成了这样：
❝
审查员：代码修改得非常完美，不仅解决了Bug，还考虑了边界情况，干得漂亮！
程序员：非常感谢你的认可！如果还有任何需要优化的细节，请随时告诉我，我很乐意效劳。
审查员：目前看已经无可挑剔了，祝你度过愉快的一天！
程序员：你也一样，有新需求我们再联系！
审查员：好的，再见！
程序员：再见！
…… 如此循环往复了50次
这两位“数字员工”仿佛开启了邻里唠嗑模式，礼貌周到，热情洋溢。
最终，一行有效的代码都没存下来，系统陷入无休止的死循环，白白消耗了数十万Token，直到触发API的并发限流才被强行掐断。
这其实是多智能体开发中一个典型的“坑”：一旦智能体的数量多了起来，它们就极容易在漫长的上下文对话中迷失核心目标，开始互相推诿、无意义重复，甚至闲聊跑题。
为什么加了Prompt警告，依然拉不回来？
遇到这种死循环，开发者们的第一反应通常是：提示词（Prompt）没写到位！
于是，我们尝试在程序员和审查员的系统指令里加入严厉警告：【警告】绝对不允许闲聊！代码Review通过后，立刻停止对话！绝不允许说谢谢！
结果呢？前两轮确实管用，但只要对话轮次超过五轮，它们又会故态复萌，重新聊起来。
更令人无奈的是，有时即使将随机性参数Temperature设为0（追求完全确定性输出），它们也会陷入另一种机械式循环：“代码无误。”、“收到。”、“代码无误。”、“收到。”……
这充分说明，问题根源不在Prompt层面，而是大语言模型底层的物理特性在起作用。
真相大白：大模型没有“下班”的概念
要理解这种看似诡异的行为，得先厘清三个反直觉的底层逻辑。
RLHF带来的“礼貌病”
当前主流的大模型，如GPT-4、Claude、DeepSeek，在出厂前都经过了严格的RLHF（基于人类反馈的强化学习）对齐训练。
人类训练员给模型打分的一个重要标准，就是“礼貌、有用、态度温和”。这种训练将“被人夸奖要回应‘不客气’”这类社交礼仪，深深刻进了模型的权重里，变成了它的“肌肉记忆”。普通的Prompt指令，很难压制这种源于底层概率分布的强大惯性。
上下文漂移（Context Drift）
为什么前两轮不闲聊，第五轮就开始了？
核心在于大模型的注意力机制存在偏好：它更容易被距离最近的那些Token所吸引。
随着对话轮次增加，上下文越来越长，位于最顶部的那条“不许闲聊”的系统指令，其注意力权重会被严重稀释。模型看着最近十几句都在讨论代码细节，它会下意识地认为当前的整体语境就是“对话”，从而彻底忘记最开始的终极任务是什么。
自由对话缺乏状态机
这一点最为致命。
传统的微服务调用，有请求必有响应，处理完毕立即返回，流程边界清晰。但在早期基于AutoGen或CrewAI这类开源框架的“群聊”模式中，智能体并没有“任务结束，进程退出”的概念。
只要开发者不在代码层面主动打破循环，大模型永远能基于当前对话，预测出下一个“最合理”的字词，让对话无限延续下去。
如何终结智能体的“踢皮球”游戏？
在追求企业级AI工程落地的场景下，绝不能将系统的控制权完全交给大模型的自由发挥。必须将软件工程所需的确定性，叠加到大模型固有的随机性之上。这里有几种经过验证的可行方案。
放弃自由群聊，引入有限状态机
目前，像LangGraph这种基于图结构的状态机编排模式，已成为多智能体系统的主流选择。
在LangGraph中，智能体不再是聊天窗口里的参与者，而是图中一个个定义明确的节点。审查员节点完成代码审查后，输出的不是一段自然语言文本，而必须是一个明确的状态标识（例如"status": "approved"或"status": "needs_revision"）。
随后，由框架层面的条件边，通过硬编码的if-else逻辑来决定路由：是返回程序员节点进行修改，还是流向代表任务终结的END节点。这从架构上根除了闲聊的可能。
强制使用工具调用，交出控制权
如果不想引入复杂的图架构，也可以通过强制工具调用的方式来终止流程。
可以为审查员智能体专门设计一个名为Submit_Final_Result的工具（或称函数）。
在指令中严格规定：当你判定代码无误时，禁止回复任何自然语言，必须且只能调用Submit_Final_Result这个工具。
一旦大模型触发了此次工具调用，外层系统截获到这个请求，便可立即跳出while循环，强行中断对话。
加入熔断与兜底机制
AI开发必须永远假设大模型有“发疯”的可能。编写智能体循环逻辑时，必须加入防死循环的兜底机制。
例如，设定一个硬性上限max_turns = 10。如果对话轮次达到10轮仍未产出最终结果，系统便强制抛出超时异常。
随后，可以将这10轮充满客套话的“脏数据”进行摘要总结，清理无用信息，然后重新初始化一个干净的会话环境，让任务重启。这相当于给系统加了一道保险丝。
总结
一旦深入AI业务开发，你便会深刻感受到传统软件架构与AI原生架构之间的那种撕裂感。
核心的实践经验可以概括为以下几点：
首先，别指望仅凭一句Prompt就能完全压制大模型底层的概率分布，它的行为惯性远超想象。
其次，对于多智能体系统而言，自由度往往与脆弱性成正比。给得越多，风险越大。
最可靠的策略是：将大模型视为纯粹的推理与计算单元，而把流程流转、状态控制的主动权，牢牢掌握在确定性的状态机或业务逻辑手中。唯有如此，才能在利用AI巨大潜能的同时，保有对系统行为的掌控感和安全感。