如何避免多个 Agent 陷入循环？
未标记
考查重点：交接进展与协作循环。子任务归属、交接与进度由编排维护，重复无新证据触发停止/重规划，总预算限轮次，工具可恢复错误才重试
本题目录
参考答案
核心回答
避免多个 Agent 陷入循环，要让任务归属、交接规则、进展判断和预算都由编排层管理，不能只在提示词里写“不要循环”。
- 明确谁负责交付：每个子任务有负责人、范围和完成条件；处理不了时返回缺什么或为什么失败，由协调者重新决策，避免互相转交。
- 限制任务如何流转：区分新任务、执行结果和通知，只有合法的任务交接才触发执行；终态任务不能被普通消息反复唤醒。
- 检测是否有进展：观察反复路由、相同工具与参数、重复结果及状态变化，识别“换个说法继续聊”或无效重试。
- 设置全局边界并收敛：限制总时间、调用量、委派深度和交接次数，子任务消耗计入整体预算；到界后返回已有结果、缺失信息或失败原因。
合理的评审修改、补充检索可以循环，但每次应有明确目的、新信息或可检查的状态变化。
展开说明
1. 先解决“谁该做”，避免 Agent 相互推诿
任务分发时应说明目标、必要输入、产物、工具范围及何时结束。只有角色名不同，实际工作范围相同，仍容易重复劳动。
例如一个设计场景：用户查询内部药品库存，网络专家没有内部数据能力，应向主调度返回“需要数据库信息”；主调度重新分配给数据库专家。若数据库专家缺药品规格，应返回缺失字段，由主调度向用户澄清，而不是再把任务交回网络专家。整个任务仍有一个最终负责交付的人或协调器。
子 Agent 可以提出转交建议，但实际选择应经过能力、任务状态和交接规则检查。简单主子结构中，让子 Agent 返回结果给主 Agent，就能减少任意互相委派造成的环路。
2. 消息到达，不等于又有一份新任务
通信内容至少应区分任务请求、结果、进度和结束通知，并关联任务、父任务及对应请求。结果是给原调用方的交付，确认收到或“谢谢”之类消息不应自动触发对方再回复一轮。
编排器根据权威状态决定是否运行：依赖满足后才能启动，结束的任务不再因为旧结果重跑；需要返工时，明确返工原因和新的修订轮次。对于直接交接模式，也应检查允许的接收方和已经经历的交接路径。
不能简单禁止所有 A → B → A：代码生成后评审、再返回修改本来就有回边。需要拦的是同一任务、相同条件下没有进展的重复转交。消息 ID 去重只能处理重复投递，无法阻止双方用不同消息 ID 重复创建同一件工作。
3. 用任务进展判断循环，而不是只比较文本
可以记录当前执行者、规范化后的动作和参数、结果摘要、关键状态版本，以及新增证据或待办变化。若两个 Agent 来回选择对方，或多轮调用始终得到同一错误且不调整方法，就有理由暂停并检查原因。
正常轮询则应关联真实任务句柄、查询间隔、外部状态和截止时间；分页查询还应检查游标是否前进。它们可能重复调用同一个工具，却在推进任务，不能一律拦截。
发现无进展后，应针对原因处理：缺输入就澄清，能力不匹配就重新路由，分歧来自不同资料版本就核对来源，服务故障则按限定策略重试。仅让另一个 Agent 重新说一遍，不一定构成有效降级。
4. 全局预算不能通过创建子任务重新获得
根任务维护总 Deadline、模型与工具消耗、派生数量和委派深度，子任务获得的是剩余预算中的一部分。局部重试也计入整体消耗，避免每个子 Agent 单独遵守上限，整条链路却不断创建新任务继续运行。
达到边界时停止派发新任务，并尽可能取消在途工作；迟到结果只能按原任务状态处理，不能再次打开已经取消的任务。外部写操作已经发生时，还需核对真实状态和业务幂等，停止聊天不会自动撤销副作用。
LangGraph 的 recursion_limit 可以限制一次图执行的 super-step，但它不是业务交接计数，也不能自动约束图外独立启动的 Agent。任务预算仍需在实际执行边界落实。
5. 监控要能看出“在忙，但没推进”
除耗时和 Token 外，还应关注同一任务的转交次数、重复行动、未变化的状态、不断增长的子任务树，以及长时间未交付的产物。执行轨迹应能回答：是谁再次派发、依据是什么、有没有新增信息、剩余预算是多少。
验证时可以覆盖双方都声称不归自己、互相复述结论、评审反复提出同一问题、消息重复投递、正常轮询和子任务递归派生等场景，检查系统是否分别选择收敛或继续。
常见追问
把任务全部改成 DAG，就没有循环了吗？
DAG 可以消除图内拓扑回环，适合依赖明确的固定任务。但节点内部仍可能无限重试，节点也可能另外启动子任务。需要反馈修改的任务又确实需要有界回边，所以拓扑和运行预算应一起设计。
由一个 Supervisor 统一调度就够了吗？
它能统一任务归属，但 Supervisor 自己也可能反复派发相同任务。仍需检查已完成结果、派发历史、进展和剩余预算，并为不可继续的任务返回明确状态。
到上限后直接返回当前最优答案可以吗？
可以返回已经取得且有依据的部分，但要说明未完成项；证据不足时不应强行生成确定结论。等待补充输入、降级和失败都可能是正确的收敛结果，不能统一标为成功。
对应教程
- 研搜：主智能体搭建与异步执行：主 Agent 负责调度与最终交付，三个业务专家按数据来源分工，可据此理解明确任务归属的价值。
- Agent 智能体：回看工具反馈后继续或结束的循环；多 Agent 还需把交接和预算放到整个任务范围管理。
参考资料
- 国内：JavaGuide：多 Agent 协作系统设计：依据角色边界、任务生命周期与失败恢复，说明正文中谁能推进任务，以及局部重试为何仍受全局预算约束。
- 国内：ranxi2001：多 Agent 防推诿与循环：借鉴路由、交接次数与状态迁移的控制，说明正文中如何减少反复转交，以及提示约束与编排检查的区别。
- 国内：WeThinkIn：无效搜索与循环调用：依据无进展检测与预算机制，区分正文中的重复调用和正常轮询，并说明子任务为何不能绕过根任务限制。
- 国外：LangChain：Graph API：依据状态驱动路由、图终止与 recursion limit，说明正文中图内步数上限的作用及应用仍需承担的全局控制。
- 国外：Anthropic：多 Agent 研究系统：借鉴委派边界、资源投入与协作观测经验，说明正文中重复工作、过度派生和缺少收敛的诊断。
