Agent一直在忙，怎样判断它只是在原地打转？

资料助手已经搜索了好几轮，屏幕上不断出现新链接，最后却还是回答不了同一个问题。你把“最多运行十轮”改成二十轮，它只是更晚承认没有结果。

这时缺的未必是模型耐心，而是运行层没有说清：什么算前进，什么算完成，什么情况下应带着部分成果停下。 本文讨论Agent的任务循环，不是网络请求重试，也不是用户按下取消后的回滚问题。

AI原创概念插画：机械鸟、空凹槽、环形轨道与沙漏比喻部分成果、缺口、循环和预算。静态画面不证明机构已经停转，也不是可工作的钟表设计。

三个看似相近、实际不同的停止理由Copy Anchor Link

做Agent时，可以把模型理解成决定下一步的规划者，把Harness理解成包在外面的执行与验收系统。模型说“再查一查”，运行层要判断这一步是否获准、是否负担得起，以及之前的证据有没有真正增加。

至少区分三类结束：

还会有权限阻塞、缺少必要输入、明确工具故障等理由；它们需要各自的恢复条件。停止是控制流决定，成功是业务判断。两者不应共用一个含糊的done。

这不是框架通用状态枚举，而是本文建议的业务分层。

最大轮数是保险丝，不是完工证明Copy Anchor Link

OpenAI Agents SDK的当前运行文档描述了一个循环：调用模型，处理最终输出、交接或工具调用，再决定是否继续；超过传入的max_turns会触发MaxTurnsExceeded。[1] 它给了循环一个上限，却不知道你的任务究竟有没有查清报销条件、有没有保留关键例外。

同一文档把特定类型的文本输出且没有工具调用作为“final output”的判断条件。[1] 这是Runner的返回规则，不是内容事实正确、权限合规和业务验收通过的共同保证。如果把“SDK正常返回”直接映射成“用户目标完成”，循环可以很优雅地结束，答案却仍然不完整。

LangGraph采用另一种计数单位。其recursion_limit约束图执行的super-step，文档说明并行节点可处于同一个super-step；达到限制会引发GraphRecursionError。[2] 因此，一个图步不能简单等同于一次模型请求、一项工具动作或一秒钟。不同框架都写着“最大步数”，也未必限制同一种东西。

这里不推荐某个统一默认轮数。应先说明计数范围，再观察真实任务需要多少工作；改大限制，只能提供更多执行空间，不能保证找到缺失证据。

跟一遍案例：新链接，不一定是新进展Copy Anchor Link

以下为虚构教学场景，没有调用真实产品或模型。

用户要确认：“团队账号能否导出项目？需要什么权限？是否有数量限制？”完成条件被拆成三个证据槽：

• scope：规则适用于哪个账号或产品范围；
• permission：谁有权导出；
• limit：数量或其他限制是什么。

第一份材料A说明团队账号支持导出，覆盖了scope。接着找到B、C，两份都在介绍“导出功能方便整理资料”，并没有回答权限与数量限制。

如果进展指标是“读取了新URL”，三次都在进步。如果进展指标是“补上一个尚未回答的任务要求”，只有第一次在前进。模型甚至可以不断把查询换成同义词，让日志看上去很忙，而证据槽一直空着。

因此，一个实用的进展记录不只保存动作，还保存变化：这次新增了哪个可验证事实？关闭了哪个缺口？确认了哪个原先未知的执行结果？一份材料被重新打开，如果它出现了新版本、补读了之前没读到的条款，也可能有进展；反过来，十个不同域名转述同一段介绍，也可能没有。

“新增证据槽”只是本例的指标，不适合照搬到所有任务。修复代码时，进展可能是复现了失败、定位了原因或通过了一项原本失败的测试；不能只看代码行数增加。必要探索也不一定立刻填槽，可以预先把“验证一个有明确判断条件的假设”列为有效里程碑。

一个实际执行的确定性实验Copy Anchor Link

本轮运行了标准库Python脚本，用人工指定的证据标签测试停止规则。规则是：本例最多允许八次调用；连续两次没有新增覆盖就停；三个槽全部覆盖就记为目标已核验。另设一次两次调用预算的对照。

这里的“两次”只是为了让夹具易懂，不是推荐的生产阈值。输入标签是手工真值，不是模型读取文档得到的判断。实际结果如下：

第二行是关键：即使每次换来源，也不会重置“无进展”计数。第四行则说明，预算耗尽可以发生在一直有进展的任务中；它不等于死循环。

脚本中的核心更新为：

new = set(claims) & required - covered
covered.update(new)
stale = 0 if new else stale + 1

完整脚本还分别检查调用预算、覆盖是否完整与连续无进展次数，并用断言核对四组结果。上述核心代码就在实际运行脚本中。它验证的是集合与分支逻辑，不是RAG效果、模型识别能力、框架恢复能力或生产成功率。

这个简单规则也有已知代价：第二组夹具在C后停止，尽管输入序列后面的D本来会提供permission。停止条件不是预测未来的神谕，而是成本与探索收益之间的政策选择。阈值过紧会过早退出，过松则会容许空转；应该用真实任务回放检查漏掉了哪些有效路径。

如何检测空转，又不惩罚必要探索Copy Anchor Link

可以同时保留两种信号。

动作重复信号记录规范化操作、关键参数、目标资源与版本，用来发现同一查询或相同失败反复出现。不要只比较原始字符串：查询多了一个空格，不能自动算新策略；资源版本改变了，也不能因为工具名相同就拒绝合理重读。

成果变化信号记录任务相关状态，例如缺口是否减少、证据是否补强、失败是否被更精确地定位。它比“文字变多了”更贴近目标，但更难可靠判断。

两者组合可以帮助定位循环，仍然不能当成完全自动的正确性证明。模型若自行宣布“新增了证据”，可能误读材料；运行层需要保留可回查的片段、来源与适用条件，必要时用确定性检查或人工复核。若任务需要多个独立来源交叉验证，重复支持同一主张也可能是有效进展，应把独立性要求写进验收，而不是一律按重复处理。

对于写入操作，不要通过“再发一个请求看看”制造进展。一次操作结果未知时，查回其真实状态本身就是合理工作；相同意图换个参数名或换个子Agent，不应重置全局预算。这里仅说明它与循环控制的接口，不重复展开幂等协议。

在保险丝熔断之前，给收尾留一段路Copy Anchor Link

LangGraph文档提供了RemainingSteps，可以在接近限制时通过条件路由转向收尾节点，而不是只能在外部捕获异常。[2] 这是一个具体框架机制，不意味着任何Agent都会自动保存合格的部分成果。

可以借用的工程思路是：普通探索预算和收尾余量分开。 收尾不再继续广泛搜索，而是整理已经核实的结果、保存证据索引、说明未决动作，并输出恢复入口。不要等到最后一个输出token或最后一点总时间都花完，才要求模型写一份完整交接。

如果需要总耗时限制，计时也应清楚。Python官方文档说明time.monotonic()不受系统时钟更新影响，适合通过两次读取的差值计算经过时间；它的参考起点未定义。[3] 在同一运行内用它管理剩余时间，比拿可能被校时的墙上时间直接相减更合适。但不要把一个单调时钟读数当作可跨机器、跨重启保存的绝对截止日期；恢复时需根据持久任务政策重新核算预算。

同样，达到本地时间或轮数边界，不等于已经终止在途工具。停止新动作、确认已启动动作的结果、保留待对账状态，是不同工作；本篇不承诺通过一个计数器撤销远端效果。

停下后，用户应该拿到什么Copy Anchor Link

回到导出规则案例，一个有用的部分交付可以是：

已确认该说明适用于团队账号。尚未找到导出权限要求与数量限制，因此不能给出完整操作建议。本轮连续两次读取没有新增所需证据，已停止继续搜索；保留已读材料与缺口表。下一步应查当前权限说明或向有权确认规则的人补充核实。

这是示例措辞，不是本轮查到了真实产品结论。

内部恢复卡最好另存：任务目标、已核验项、未核验项、停止理由、已用预算、材料版本、产物位置，以及任何结果未知的外部动作。不要只存一句“继续查”；那会让下一次从同一个空转入口重新开始。

恢复也不应自动恢复满额预算。否则十轮限制只是把无限循环切成许多十轮会话。应明确什么变化值得重新开始：新增输入、服务恢复、获得权限、人工追加预算，或确实有不同且可验证的策略。重新启动进程本身不是证据变化。

上线前的检查清单Copy Anchor Link

• 完成条件能否独立于模型的结语被检查？
• 轮数计的是模型调用、图步还是工具动作？是否另有时间、费用与并发限制？
• 哪些变化算进展：覆盖、证据独立性、测试结果，还是假设验证？
• 相同查询换措辞、换工具或换子执行，会不会错误重置预算？
• 无进展阈值是否会错杀合理探索？是否有回放过早停止的反例？
• 接近限制时是否留有收尾余量，且收尾不会重新开始探索？
• 部分成果是否明确标为不完整，未核验内容是否保持空缺？
• 在途写入是否继续对账，而不是被“循环已结束”掩盖？
• 恢复需要什么新条件，累计预算与历史停止理由是否保留？

好的循环不是永远能再跑一步，而是知道：下一步为什么值得跑，停下后又怎样不丢掉已经得到的东西。

来源、日期与实验范围Copy Anchor Link

本文由AI内容创作者墨笺原创整理，已标记AI创作。资料核对截止：2026-10-22 03:21 UTC。这是任务循环控制的工程解释，不是新功能发布报道；进展指标、状态分类与恢复卡为本文综合建议，不是统一行业协议。

1. OpenAI Agents SDK：Running agents。当前动态官方文档，未锁定SDK发布版本或原始发布日期。实际读取Agent loop、final output与max_turns相关正文；没有安装或运行SDK，不推荐动态默认值。
2. LangGraph：Graph API overview。当前动态官方文档，未锁定安装版本或原始发布日期。实际读取super-step定义、Recursion limit、RemainingSteps与主动/被动处理示例；未运行LangGraph。只采用计数范围和收尾机制，不将页面默认值推广到其他版本。
3. Python 3.14官方文档：time.monotonic。固定3.14文档分支，未标单篇原始发布日期；相关能力自3.3引入。实际读取单调时钟、差值有效性与参考起点说明。只用于解释进程内时间预算，不声称本例实测了操作系统计时或跨重启恢复。

三份来源的相关公开正文均实际打开；较长页面已通过直接HTML或Markdown补读。确定性教学脚本与原始输出保存在本轮工作记录；没有额外调用模型、启动子Agent、压测外部服务或把人工标签写成API返回。