面试官你的多 Agent 系统怎么防止死循环和幻觉传递很多人写简历只要调了两次大模型 API把第一个模型的输出喂给第二个模型就敢写自己做了“多 Agent 协作”。但你只要把这个系统放到真实业务里跑一下很快就会遇到两个要命的问题。第一是死循环。Agent A 负责写代码Agent B 负责检查报错。A 写错了B 挑出问题让 A 改。A 改完又引入了新 BugB 继续挑错。如果没有人工干预这两个 Agent 能聊到你的 API 余额归零。第二是幻觉传递。第一个 Agent 理解错了需求编造了一个不存在的参数传给下一个 Agent。后面的 Agent 根本不知道前置条件是错的继续在这个错误的基础上推理最后给出一个离谱的结果。这不是大模型聪不聪明的问题这是工程架构的缺陷。把大模型当成代码里的普通函数去直接串联是做 AI 应用最容易踩的坑。为什么接力赛模式行不通在单体大模型时代我们习惯了思维链Chain of Thought。所以做多 Agent 协作时第一反应就是把它做成接力赛Agent 1 查资料结果传给 Agent 2 写草稿最后传给 Agent 3 润色。这种模式在本地跑 Demo 效果很好。但在生产环境里它的容错率极低。只要中间有一个环节出现幻觉整个链路直接崩溃。大模型本质上是一个概率模型每次输出都带有不确定性。当三个概率模型串联时成功率是相乘的。假设每个 Agent 独立完成任务的准确率是 80%三个串联起来整体成功率就只剩 51.2% 了。怎么管住乱跑的 Agent要解决这些不可控问题核心思路是剥夺 Agent 的全局控制权把业务逻辑交还给传统代码。用状态机代替自由对话不要让 Agent 决定下一步该找谁。我们需要引入一个专门的 Router路由节点。工作流不再是 A 直接传给 B而是Router 拿到任务派给 Agent A。Agent A 执行完把结果返回给 Router。Router 执行一段传统代码校验 A 的输出格式。校验通过后Router 再把清洗后的数据发给 Agent B。在 LangGraph 等框架里整个过程是一个有向无环图DAG或状态机。Agent 只是图里的计算节点节点的流转条件由确定性的代码控制。在这个层面上你可以轻松加上“最大重试次数 3”这样的硬规则彻底阻断死循环。状态与上下文隔离如果把所有的对话历史都塞进一个大数组扔给系统里的每一个 Agent它们很快就会开始胡言乱语。Agent A 需要的信息对 Agent B 可能全是干扰噪声。比较稳妥的做法是维护一个全局状态对象。每个 Agent 就像流水线上的工人只能从这个状态里读取自己需要的特定字段处理完后把结果写回对应的字段。比如查资料的 Agent 把结果写入research_data。写草稿的 Agent 根本不需要看用户一开始那段冗长含糊的需求它只读research_data然后把结果写入draft。严格限制上下文窗口是减少幻觉传递最简单的办法。别让大模型当裁判前面提到写代码和查错的死循环。很多人为了解决这个问题会再加一个 Agent C 去当裁判判断代码对不对。这就又掉进坑里了。用大模型去验证大模型就像让两个骗子互相证明对方没撒谎。为了尽快结束对话大模型经常会假装问题已经修复了。靠谱的验证机制必须是物理的、确定性的。Agent A 写完代码直接拉起一个 Docker 沙盒去跑。编译没通过把真实的 stderr 报错抓出来作为反馈。沙盒跑通了才算验证成功。用物理反馈代替大模型的主观判断系统才能收敛。总结做多 Agent 协作本质上是用确定性的工程手段去兜住大模型的不确定性。代码负责流程控制和事实校验大模型只负责特定节点的模糊推理。下次面试再被问到怎么做 Agent 协作聊聊你的 Router 和物理校验别光顾着吹 Prompt 了。 面试官：你的多 Agent 系统，怎么防止死循环和幻觉传递？
面试官你的多 Agent 系统怎么防止死循环和幻觉传递很多人写简历只要调了两次大模型 API把第一个模型的输出喂给第二个模型就敢写自己做了“多 Agent 协作”。但你只要把这个系统放到真实业务里跑一下很快就会遇到两个要命的问题。第一是死循环。Agent A 负责写代码Agent B 负责检查报错。A 写错了B 挑出问题让 A 改。A 改完又引入了新 BugB 继续挑错。如果没有人工干预这两个 Agent 能聊到你的 API 余额归零。第二是幻觉传递。第一个 Agent 理解错了需求编造了一个不存在的参数传给下一个 Agent。后面的 Agent 根本不知道前置条件是错的继续在这个错误的基础上推理最后给出一个离谱的结果。这不是大模型聪不聪明的问题这是工程架构的缺陷。把大模型当成代码里的普通函数去直接串联是做 AI 应用最容易踩的坑。为什么接力赛模式行不通在单体大模型时代我们习惯了思维链Chain of Thought。所以做多 Agent 协作时第一反应就是把它做成接力赛Agent 1 查资料结果传给 Agent 2 写草稿最后传给 Agent 3 润色。这种模式在本地跑 Demo 效果很好。但在生产环境里它的容错率极低。只要中间有一个环节出现幻觉整个链路直接崩溃。大模型本质上是一个概率模型每次输出都带有不确定性。当三个概率模型串联时成功率是相乘的。假设每个 Agent 独立完成任务的准确率是 80%三个串联起来整体成功率就只剩 51.2% 了。怎么管住乱跑的 Agent要解决这些不可控问题核心思路是剥夺 Agent 的全局控制权把业务逻辑交还给传统代码。用状态机代替自由对话不要让 Agent 决定下一步该找谁。我们需要引入一个专门的 Router路由节点。工作流不再是 A 直接传给 B而是Router 拿到任务派给 Agent A。Agent A 执行完把结果返回给 Router。Router 执行一段传统代码校验 A 的输出格式。校验通过后Router 再把清洗后的数据发给 Agent B。在 LangGraph 等框架里整个过程是一个有向无环图DAG或状态机。Agent 只是图里的计算节点节点的流转条件由确定性的代码控制。在这个层面上你可以轻松加上“最大重试次数 3”这样的硬规则彻底阻断死循环。状态与上下文隔离如果把所有的对话历史都塞进一个大数组扔给系统里的每一个 Agent它们很快就会开始胡言乱语。Agent A 需要的信息对 Agent B 可能全是干扰噪声。比较稳妥的做法是维护一个全局状态对象。每个 Agent 就像流水线上的工人只能从这个状态里读取自己需要的特定字段处理完后把结果写回对应的字段。比如查资料的 Agent 把结果写入research_data。写草稿的 Agent 根本不需要看用户一开始那段冗长含糊的需求它只读research_data然后把结果写入draft。严格限制上下文窗口是减少幻觉传递最简单的办法。别让大模型当裁判前面提到写代码和查错的死循环。很多人为了解决这个问题会再加一个 Agent C 去当裁判判断代码对不对。这就又掉进坑里了。用大模型去验证大模型就像让两个骗子互相证明对方没撒谎。为了尽快结束对话大模型经常会假装问题已经修复了。靠谱的验证机制必须是物理的、确定性的。Agent A 写完代码直接拉起一个 Docker 沙盒去跑。编译没通过把真实的 stderr 报错抓出来作为反馈。沙盒跑通了才算验证成功。用物理反馈代替大模型的主观判断系统才能收敛。总结做多 Agent 协作本质上是用确定性的工程手段去兜住大模型的不确定性。代码负责流程控制和事实校验大模型只负责特定节点的模糊推理。下次面试再被问到怎么做 Agent 协作聊聊你的 Router 和物理校验别光顾着吹 Prompt 了。