一、分清三个容易混淆的现象

很多同学会把三者混为一谈，但底层问题不完全一样：

1. 重复调用：一模一样的工具、一模一样参数反复执行，调用完拿到结果，又再次发起完全相同调用。比如反复调用同一个查询接口，拿到同样返回，不往下推进任务。
2. 路径震荡（振荡 oscillate）：在两个或者多个动作之间来回横跳。典型场景：调用工具 A 得到结果，觉得不对调用 B，拿到 B 结果又切回 A，来回摇摆，没有收敛，任务原地踏步，没有产出。“修 A 坏 B，修 B 坏 A” 就是典型震荡表现CSDN博...。
3. 死循环：持续不断多轮思考‑工具调用，永远达不到完成终止条件，既不报错，也不输出最终答案，无限跑下去，消耗大量 Token 与接口资源。

注意：max_steps最大轮次限制，只是熔断保护，防止程序永不停止，不能根治震荡、重复调用的根源问题，只是强制终止任务。

二、产生问题的核心原因

1. 模型侧原因

• 工具返回信息不足、返回空 / 模糊 / 冲突数据，模型得不到有效进展线索，不知道下一步该干什么，只能重复试探。
• 幻觉问题：模型误判 “还没有做过这个操作”，明明已经执行，却误以为未执行。
• 终止逻辑完全交给大模型判断：只靠 Prompt 告诉模型 “做完就结束”，大模型经常做不到，模型容易忘记终止条件，继续发起工具调用。

2. 工程状态层面原因

• 没有完整记录历史动作，Agent 不记得自己刚刚做过哪些操作；没有保存每一步动作、参数、返回结果指纹。
• 缺少 “进展判断逻辑”：无法识别 “本轮执行有没有带来新信息”，即便没有新收获还继续允许调用工具。

3. Prompt 与业务逻辑原因

• 系统提示没有约束重试策略，遇到报错无脑重试，没有区分临时错误和业务错误。
• 任务目标模糊，需求边界不清晰，模型没有明确的完成标准，不知道什么状态算任务结束。

4. 外部环境原因

工具接口返回不稳定，偶发抖动，一会成功一会失败，进一步加剧来回摇摆震荡。

三、生产环境怎么检测识别这三类问题

重点：检测逻辑要写在代码侧，不能交给大模型自己判断，模型本身会幻觉，不能信任模型自检CSDN博...。

1. 重复调用检测

维护动作指纹：对每一次工具调用，生成指纹：工具名+入参hash。 保存历史已经执行过的指纹列表。 当新生成调用的指纹已经存在历史集合中，判定为重复调用。

2. 路径震荡检测

观察最近 N 步的动作序列，比如最近 3‑5 轮，如果出现动作循环模式 A‑B‑A‑B，判定震荡。 不只是比对工具名称，也要结合参数，参数不同不算震荡。

3. 无进展检测（非常关键）

对比本轮工具返回结果，看是否带来新有效信息。 连续多轮，多轮返回没有新增有效信息，就算没有完全重复动作，也判定为卡住、停滞（stall）CSDN博...。

4. 基础熔断指标兜底

• 最大执行步数 max_steps；
• 单任务 Token 消耗上限；
• 单任务超时时间。

监控埋点：统计指标：重复调用次数、震荡触发次数、停滞无进展次数，上报告警，用于线上大盘观测。

四、完整治理方案，分层解决

第一层：Prompt 层面优化

1. 明确重试规则：区分哪些错误可以重试，哪些不允许重试；例如参数错误 4xx 禁止重试，网络超时 5xx 允许有限次数重试。
2. 明确任务完成标准：告诉 Agent 什么样的输出代表任务结束，不能模糊写 “完成任务”。
3. 约束：不要重复执行参数完全相同的工具调用，如果多次尝试仍然失败，停止工具调用，向用户反馈现状。

第二层：工程代码防护（核心，面试加分）

1. 动作指纹记录：每一轮保存工具名、参数 hash、返回摘要，做重复校验。
2. 震荡检测器 OscillationDetector：监控近期动作序列，检测循环摇摆模式，一旦命中，禁止继续工具调用。
3. 进展评估模块：判断每一轮执行之后，是否获取新信息；连续无进展直接停止工具链路。
4. 终止条件外置化：不要把是否结束全部交给 LLM，业务侧用代码设置多套终止条件：目标达成、步数超限、停滞、震荡触发，满足任意一条即可终止 Agent 流程。

第三层：触发异常之后的降级策略

检测到重复 / 震荡 / 停滞，不能直接粗暴失败，提供可选降级路径：

1. 停止继续调用工具，把目前收集全部信息整理，向用户说明现状：“多次尝试未能推进任务，当前获取信息如下”；
2. 进入 Human‑in‑the‑Loop，请求用户确认方向，询问是否调整参数、修改目标；
3. 切换备选策略，换一套工具 / 检索方式尝试，仅允许切换一次，避免继续循环。

五、线上踩坑点

1. 不要只靠 max_steps，等到步数跑满才终止，此时已经浪费大量 token 资源，要提前识别震荡、无进展，提前拦截。
2. 判断重复调用，不能只比对工具名称，要带上参数；同样工具不同参数属于合理操作，不能误拦截。
3. 震荡检测窗口不能设置太小，比如只看 2 步，容易误判；一般取最近 3‑5 轮做序列判断。
4. 降级输出的时候，要把已经拿到的中间结果返回给用户，不能直接抛一句 “执行失败”，用户完全不知道发生了什么。

面试精简总结话术

Agent 重复调用、路径震荡、死循环，根源分为模型幻觉、缺少动作历史追踪、缺少进展判断、终止条件完全依赖大模型。工程上需要外置检测器：通过动作指纹识别重复调用，通过动作序列识别路径震荡，通过信息增益判断任务是否停滞；max_steps 仅作为兜底熔断。检测到异常后执行降级，整理已有结果反馈用户或者转入人工确认，不能单纯依赖提示词约束。

文末互动

你的线上 Agent 有没有遇到过来回横跳震荡的情况？是怎么排查处理的？欢迎评论区交流。