无人值守的 Agent 跑到什么程度该停：Agent 停止条件怎么定

让 Agent 无人值守地跑之前，先定 Agent 停止条件：一个「任务完成」的判定，加五个上限，分别是步数、Token 预算、墙钟时间、重复相同调用、连续工具报错。数值由团队按业务定。碰到上限而停的运行不算完成，日志里要写明是哪个条件触发的，停下时正在做什么，还有什么没解决。

完成要按业务结果来判

判定一次无人值守运行是否结束，首先要给出客观的完成定义。

密歇根大学 2026 年秋季课程 EECS 498-016《Applied Agentic Software Engineering》由 Marcus Darden 主讲，课程大纲列了 Agent v0 的核心要求，包括带六种停止条件的自主循环。课程讲义写到，在基础的交互循环中，当模型返回的回复里没有工具调用时，这次运行就算结束。

我们的判断是：在企业落地场景中，模型不再调工具有时只是上下文耗尽或遇到无法处理的分支，并不代表业务目标真正达成。

我们建议企业按业务结果定义完成，比如外部校验脚本通过，或者数据库中生成了合规的目标记录并由下游系统确认接收。由客观环境给出结案信号，防止模型误报完成。

五个上限分别防什么：步数、预算、时间、循环与连续报错

五个数值上限给完成信号兜底，各拦一类失控风险。

课程讲义写到，六种停止条件是一个「任务完成」加五个上限：步数上限、Token 预算、墙钟时间、重复相同调用、连续工具报错。步数上限是其它几个条件的兜底。

第一，步数上限防无限循环，限制自主循环的最大轮次作为总保底。

第二，Token 预算管花费，单次运行消耗达到设定配额立即停机，防止递归推理空耗资源。

第三，墙钟时间管卡住，某些后台进程或外部接口无响应时，按物理时间直接掐断，避免任务永久挂起。

第四，重复相同调用管原地打转，当 Agent 连续多次以相同参数调用同一个工具时及时止损。

第五，连续工具报错管一错再错，工具连续失败达到阈值时主动中断。课程讲义写到，命令执行后返回非零值时，算不算报错要小心处理。比如在修复代码场景中，测试命令失败本身就是排查问题的信息，若算作报错，可能在修测试的半途把运行停掉。团队要区分业务反馈与接口崩溃。

碰到上限不等于完成：每个上限在日志里要有专属名称

因触碰上限而停下的任务并未真正完成，运行日志不能模糊地只写「stopped」。

课程讲义写到，碰到上限而结束的运行没有完成，每个上限在日志里要有自己的名字；具体的数值由团队按业务定，课程规格不替你定。如果日志只写「stopped」，等于藏住了最重要的事实。

在业务监控中，如果只记录系统停止，运维人员无法区分任务是正常跑完、超时被掐断，还是因为参数死循环而熔断。

我们建议企业为每种停止条件分配独立的标识字段，比如步数超限、预算超额、墙钟超时、重复调用和连续报错。只有当任务通过客观业务校验结案时，才打上成功标记；所有触碰上限的退出，都要作为未完成异常流转到人工看板，防止半成品被当成正常结果流向下游。

停下时留什么：退出信息要说明正在做什么与未决事项

Agent 触发停止条件退出时，要在日志中留下供事后排查的完整上下文。

课程讲义写到，退出信息也是写给人看的，要说明停下时正在做什么，不只说为什么停。

比如：财务对账 Agent 运行到步数上限被迫停下，如果日志只写「达到步数上限」，人工接管时必须重新拉取整条调用；如果退出信息明确说明正在比对哪一批供应商单据、哪几批已完成、哪些金额差异还没解决，接手的业务人员就能当场接力，不用从头重跑。

我们建议企业将退出信息规范为三项固定字段：停在哪一步、正在做什么、还有什么没解决。清晰的记录能缩短人工介入时的排查时间。

停止条件管不了什么：它负责结束运行，不判断单个动作

停止条件负责管理整次运行的生命周期，并不负责判断某一个单次动作是否危险。

课程讲义写到，停止条件负责结束运行，不负责判断单个动作。比如在命令行中删除关键数据或调用外部转账，即使这是任务第一步且未触碰任何上限，操作本身依然具有高风险。判断动作要靠审批层，见 Agent 的工具调用，哪些能按规则自动放行、哪些必须拦下。

出错后怎么撤回与恢复是另一件事。我们建议企业在让 Agent 无人值守跑之前，把五个上限的数值写进上线验收单。工具权限分级见 企业给 Agent 开工具权限，先开哪类、后开哪类。

自动化规模扩大前的治理考量，见 Agent 治理要赶在扩规模之前：推荐错了能不采纳，执行错了已经发生。从试点扩到生产的检查项，见 Agent 试点能跑通，扩到生产还缺哪几项？。

Agent 停止条件：常见问题

为什么不能只靠大模型自主判断任务是否完成，而要设定外部停止条件？

我们的判断是：大模型在长链路任务中可能出现误判或死循环，在任务只完成一半时误判为结案，或在出错时反复尝试同一动作空耗资源。外部停止条件由底层运行环境直接把控，脱离于模型推理之外，能提供确定性的熔断保护。

为什么测试命令返回失败等非零退出码，不能一概视为工具报错？

许多命令行工具返回非零值并不代表工具崩溃，它往往传递了特定的业务状态。比如单元测试未通过时返回非零值，这是测试框架给出的客观结果，也是 Agent 继续修代码的依据。若直接记为工具报错并触发熔断，就会让系统在修复中途被意外掐断。工程上应当区分底层调用失败与业务工具的返回码。

团队如何设计结构化格式，让停止原因完整记入决策日志？

设计记录停止状态的决策日志，关键在将运行状态与上下文拆分为结构化键值。在日志中，团队应当固化停止类型、当前动作和未决事项三项核心字段：首先以枚举值标明退出究竟是正常完成还是触发了具体上限；其次记下中断时正在处理的实体标识与工具入参；最后保留剩余未处理的任务队列与差错摘要。规范的日志为人工接手提供了现场快照，避免从头重新排查。