考察点
「如果 Agent 陷入死循环怎么办」是 ReAct 话题下的高频追问，也被列进「生产环境踩过什么坑」的标准清单。面试官想听的不只是「设最大步数」，而是你有没有一套分层的防御思路，以及从真实故障里长出来的经验。
参考答案
死循环长什么样
先识别症状，实战里死循环有三种典型形态：
- 工具复读机：模型反复调同一个工具、同样的参数。比如搜索返回空，模型换个标点符号再搜，结果一样，再搜。
- 两个状态间震荡：A 步骤产出指向 B，B 步骤产出又指回 A，来回横跳。多 Agent 系统里就是两个 Agent 互相甩锅。
- 永不停歇型：没有死循环但也停不下来——模型总觉得「再查一步信息会更全」，任务其实早做完了，它还在自我感动地优化。
三层防御体系
第一层：硬上限（兜底，必须有）
max_iterations：单任务最大步数，我的经验值是 10-15，超过直接终止。- Wall-clock 超时：比如单任务 5 分钟，防止某步工具调用挂死拖着整个循环。
- Token 预算：累计消耗到阈值（比如 10 万 token）强制停。这条比步数更能控成本，因为某一步可能塞进来一个超长 observation。
硬上限到点了不能让任务直接暴毙，要有体面退出：让模型基于已有信息给出「当前最佳答案 + 未完成说明」，或者转入人工队列。
第二层：循环检测（语义层）
硬上限是被动的，聪明的做法是主动识别循环模式：
- 动作去重：维护最近 N 步的 (tool_name, args_hash) 列表，发现重复就注入一条系统消息「你已经调用过该工具且参数相同，结果为 X，请换策略」。
- 进展检测：连续 K 步 observation 没有引入新信息（比如信息熵没变化，简单点可以用文本相似度判断），判定停滞，强制收尾。
- 状态指纹：对 Agent 的整体状态做哈希，发现回到历史状态直接干预。
第三层：Prompt 与工具设计（源头治理）
很多死循环是设计缺陷，不是模型笨：
- 在 system prompt 里写明「同一方法失败两次就换思路，三次尝试后放弃并说明原因」，给模型一个体面的台阶。
- 工具返回空结果时，别只回「无结果」，附上建议：「未找到，可尝试：1) 放宽时间范围 2) 换用 xxx 工具」。模型收到可操作的建议就不容易复读。
- 工具报错返回结构化的错误摘要而不是原始堆栈，几百行 traceback 会把模型绕晕，绕晕了就乱调。
多 Agent 场景的加强版
多 Agent 的循环更隐蔽，除上述手段外还要：任务级消息计数器（一个任务总共最多传 50 条消息）、Supervisor 强制仲裁权（检测到两个 Agent 来回踢皮球，由 Supervisor 拍板）、任务 TTL 随任务创建时下发，任何 Agent 收到过期任务直接丢弃。
观测是前提
所有这些控制手段要能调优，前提是你在 trace 里记录了每一步的输入输出。上线初期把 max_iterations、超时这些参数做成配置而不是常量，对着 trace 数据调——看正常任务平均几步完成，P95 是多少，上限设在 P99 附近，既不误杀正常任务又能兜住失控的。
可能的追问
- 「上限触发后直接报错给用户吗？」 不要。降级策略：返回当前最佳部分结果 + 明确告知未完成原因，或转人工。用户拿到半成品加解释，比拿到一个报错好得多。
- 「怎么区分『正常的多步探索』和『死循环前兆』？」 看信息增量：正常探索每步 observation 带来新事实；死循环的 observation 高度重复。用相似度或新实体计数就能区分开。
- 「循环控制的参数怎么定？」 别拍脑袋。上线前用评估集跑分布，看成功任务的步数分布，上限取 P99；上线后按 trace 持续修正。