如何识别并终止 Agent 工具调用循环，同时保留合理重试？

核心回答

识别工具调用循环，不能只看“同一工具调用了几次”，而要结合动作是否重复、任务是否推进、错误是否可恢复来判断，再由执行系统设置预算和停止条件。

1. 记录调用轨迹：保留工具名、规范化参数、结果摘要、错误类型及关键任务状态，发现同一动作反复出现或多个动作来回切换。
2. 检查实际进展：是否获得新证据、完成子任务或改变业务状态。返回文本变长、调用成功，都不一定代表推进了目标。
3. 分类处理失败：瞬时故障可以在预算内退避重试；参数错误要先修正；缺权限、明确不可恢复的错误应停止或转人工。合理轮询按接口约定等待，并设置截止时间。
4. 程序强制止损：限制单次调用、重试和整个任务的时间、次数及成本；持续无进展时切换策略、返回已有结果或交给人工，保留停止原因。

例如查询后台任务状态，重复得到“处理中”可能是正常轮询；但对不存在的任务 ID 反复请求，或不断改写同义查询却拿到相同资料，就需要处理无效循环。两者不能只凭重复次数区分。

展开说明

先确认循环为什么没有推进

先看最近几轮执行记录，判断是决策出了问题，还是执行与反馈出了问题：

• 工具已经报错，但错误没有回传给模型，模型误以为上一步尚未执行。
• 参数缺失或格式错误，模型每次只改表述，没有修正真正的错误字段。
• 结果已经足够，但任务没有明确的完成条件，模型继续搜索。
• 工具结果被截断或摘要丢失，下一轮又重复获取同一内容。
• 工作流的回边没有退出条件，或者外层调度不断重启已经失败的任务。

因此需要把模型请求、实际工具执行、结果回传和状态更新串起来。只看最终回答或模型生成的“下一步计划”，很难判断重复发生在哪一层。

用动作指纹发现重复，再用任务状态判断有无进展

动作指纹可以由工具名、规范化后的业务参数及相关任务状态组成。规范化可以统一参数顺序、补齐默认值，并排除纯日志用的随机请求 ID，避免同一调用被误认为不同动作。

但不能随意删除有业务含义的字段。例如分页游标变化，通常意味着在读取不同页；查询时间、资源版本或任务状态变化，也可能让相同工具调用变得必要。反过来，不能把每轮递增的计数器或不断追加的聊天记录当作“状态变了”，否则每一轮看起来都不同，无法发现循环。

重复检测既要看同一个动作连续出现，也要留意“搜索→读取→搜索”这样的周期。它只负责发现可疑模式，最终还要检查进展，例如：

• 检索是否得到新的相关证据，而不是相同文档换个排序。
• 代码修改后，原失败用例是否有所变化，是否修复了一个明确问题。
• 业务操作是否到达新的状态，或仍在合法的等待阶段。

“信息增益”在这里通常是任务相关的判据，不必强行套成一个通用的语义相似度分数。

按错误类型保留合理重试

瞬时网络故障、服务暂时不可用或限流，可以在接口允许、操作可安全重复的条件下，采用有上限的退避与随机抖动；服务给出等待时间时，按其约定处理。重试也应计入总截止时间，不能等待无限延长。

确定性的参数或业务错误，应把具体字段和原因回传给模型，让它修改参数、补充信息或选择其他路径。相同错误请求原样重发，通常不会得到不同结果。

权限不足或需要用户决策，应停在对应节点，说明需要什么输入或授权，不让模型通过持续重试尝试绕过边界。

写入结果不确定，要先查操作状态。请求超时不代表写入没有发生；只有结合幂等键、去重或业务状态确认，才适合重试，避免重复下单、发送或扣款。

还要区分工具层重试与 Agent 重新规划。底层 HTTP 客户端可能已经重试过，Agent 层再重复一整轮会放大请求量。应明确哪一层负责重试，并统一记录与约束总尝试次数。

无进展时先改变条件，再决定是否继续

对于可疑循环，可以回传简短、明确的反馈：已经尝试过什么、结果为什么不足，以及还缺什么。随后让 Agent 在剩余预算内改查询、换工具、补信息或重新规划。

只有表述变化、没有新依据的“再反思一次”，不能让重试计数和预算重新归零。策略切换后仍无进展，就应停止当前路径，并记录已完成部分、未完成目标、失败证据和可恢复的状态。终止循环是停止继续调度，不等于撤销已发出的写入；仍在执行的操作要按工具能力取消或查询最终状态。

正常轮询也需要清楚的契约：轮询哪个资源、预期哪些状态、间隔如何确定、何时超时。接口明确返回“仍在处理”，并且仍处于允许的等待区间时，重复查询可以保留；到达终态、明确失败或截止时间后就结束。

用分层预算兜底，并验证是否误杀

单次模型请求和工具调用要有超时；同一操作要有重试预算；整个任务还要有总耗时、调用次数及成本上限。仅在循环顶部计步，挡不住某一次工具一直不返回，因此超时和取消应落实到执行层。

模型没有生成工具调用时，应检查它是否给出有效的最终结果、明确拒绝或需要补充信息。空输出、解析失败或响应被截断属于异常，最多按预设策略有限恢复，随后明确报错，不能无条件进入下一轮。

验证时同时准备两类用例：重复坏参数、工具间来回切换、相同资料反复检索等无效循环；以及短暂故障后成功、合法分页、异步任务轮询等合理重复。检查能否及时停止浪费，也检查是否过早打断正常任务，并记录停止原因、额外调用量和恢复结果。

递进追问

直接设置最大步数不就够了吗？

最大步数可以兜底，但无法解释失败，也可能在无效循环中浪费大量预算，或截断本来需要多步的正常任务。需要同时有完成条件、进展判据和错误分类；最大步数负责最后止损。

重复次数和相似度阈值应该怎样定？

先用真实轨迹与故障用例，观察正常任务会有多少合法重复、不同错误多久能恢复，再按工具风险和任务成本选择阈值。相似度只能辅助发现模式，不能单独宣布死循环；阈值应通过误停率和无效调用量回归调整。

终止循环后，怎样让任务还能继续？

保存目标、已确认事实、已执行操作及结果、剩余工作和停止原因。恢复前先检查外部状态是否已经变化，尤其是结果未知的写入；补齐输入、服务恢复或人工决策到位后，再从合适节点继续，而不是原样重放全部调用。

对应教程

参考资料