最近用 ChatGPT、Codex 跑复杂任务时，我越来越关注一个问题：
Agent什么时候应该继续，什么时候其实应该停下来。
因为真实项目里经常会出现这种情况：
一开始只是让Agent修一个Bug。
结果它先读代码。
再搜调用链。
然后改两个文件。
测试失败以后继续修。
又发现一个关联模块。
再补测试。
再跑一轮。
接着顺手重构。
最后本来半小时能判断清楚的问题，任务跑了很久还没有真正结束。
最容易产生的错觉是：
Agent还在工作，说明任务还在推进。
但实际上并不一定。
很多长任务真正的问题不是：
执行能力不够。
而是：
没有明确的停止条件。
这也是复杂Agent Workflow里一个越来越重要的问题：
Execution Budget——执行预算。
一、先分清：执行得久，不等于推进得多
假设Codex执行了20个步骤。
表面上看：
工作量很大。
但拆开以后可能是：
读取相关文件：4步
定位根因：3步
有效修改：3步
验证：2步
重复搜索：3步
重复测试：2步
无效尝试：2步
无关重构：1步
真正推动任务接近完成的可能只有：
12步。
另外8步虽然也在“执行”，却没有明显增加任务完成度。
所以复杂任务里更重要的不是：
Agent执行了多少步。
而是：
有多少步骤真正产生了有效进展。
这两个概念差别很大。
二、为什么Agent任务特别容易越跑越长？
最常见的原因之一就是：
任务边界会在执行过程中不断扩张。
例如一开始只是：
修复订单接口偶发失败。
Agent开始以后发现：
接口失败来自数据库。
继续查数据库又发现：
事务边界有问题。
再往下又看到：
消息队列可能重复消费。
然后测试覆盖还不够。
最后任务从：
修一个接口
变成：
接口
+ 数据库
+ 消息队列
+ 测试
+ 重构
问题不是这些发现一定没价值。
而是：
这些东西是不是都应该在当前任务里处理？
如果没有边界控制，
Agent非常容易从：
解决问题
变成：
顺着所有关联问题一直往下挖。
三、第二个原因：失败以后默认继续重试
Agent的一个明显优势就是：
失败以后可以继续尝试。
但这也是风险。
比如：
修改方案A
↓
测试失败
↓
修方案A
↓
再次失败
↓
换方案B
↓
又失败
↓
继续调整
如果没有限制，
它可能不断尝试新的路径。
问题在于：
前三次失败之后，
继续尝试第四次是否还有足够的新Evidence？
如果没有，
那后面的动作很可能只是：
Retry Without New Information
没有新信息的重复尝试。
这种执行最容易消耗：
时间。
Token。
调用次数。
却没有增加多少成功概率。
四、第三个原因：Agent会把“发现问题”当成“应该修问题”
比如Agent在修改支付模块时，
顺手发现：
一个函数命名不好。
一个测试结构很乱。
一个旧API已经Deprecated。
一段代码可以重构。
这些都是真的问题。
但它们和当前任务：
未必有关。
如果Agent每发现一个问题都继续处理，
任务就会不断膨胀。
所以复杂Workflow里最好明确区分：
Blocking Issue
不解决就无法完成当前任务。
和：
Related Issue
和当前任务相关，但可以以后处理。
还有：
Opportunistic Improvement
顺手优化。
后两类默认都不应该自动进入当前Write Scope。
五、所以任务开始前最好有“执行预算”
所谓Execution Budget，不只是：
最多运行30分钟。
它更像是：
提前定义Agent能把任务推进到什么程度。
我现在更推荐至少控制五类预算。
第一类：步骤预算
例如：
最多执行15个主要步骤
目的不是机械限制。
而是当任务跑到15步还没明显收敛时，
强制触发一次检查：
为什么还没结束？
第二类：修改范围预算
例如：
预计修改不超过6个文件
如果最后已经改到：
15个文件。
就说明：
任务范围可能发生了变化。
这时候应该暂停，
重新确认影响面。
第三类：失败重试预算
例如：
同一假设最多验证3次
连续失败以后：
不要继续换参数硬试。
先重新检查：
根因假设是不是错了。
第四类：验证预算
例如：
允许两轮完整测试
如果每一轮都出现完全不同的问题：
说明任务可能已经超过原始边界。
第五类：资源预算
例如：
时间。
Token。
工具调用。
长任务尤其需要考虑：
执行成本是否还值得继续。
六、什么时候应该主动暂停？
我通常会看几个很明显的信号。
第一个：
修改范围突然扩大
例如预计：
3个文件。
实际已经改了：
12个文件。
这时候不要继续往下写。
先重新确认：
为什么扩散。
第二个：
连续失败，但没有新Evidence
例如三次测试失败，
每次只是换一种猜法。
这种时候继续尝试的价值通常已经很低。
第三个：
新发现的问题开始偏离原始目标
比如原本修Bug，
做到最后开始重构框架。
这就是典型的Scope Drift。
第四个：
Agent已经不能清楚解释下一步为什么有价值
这是一个很好用的判断方式。
直接问：
下一步动作会验证什么假设？
如果Agent自己都无法明确回答，
那通常说明任务已经开始失去方向。
七、最危险的其实不是“停下来”
很多人会担心：
Agent一停，
任务是不是就断了？
但工程上真正危险的往往是：
不该继续的时候继续执行。
因为每一次错误修改都会增加：
Diff。
上下文。
验证成本。
回滚成本。
例如原本只需要撤销：
2个文件。
继续执行10步以后，
可能已经变成：
15个文件。
所以：
暂停不是失败。
很多时候它是一种：
风险控制机制。
八、Continue ≠ Progress
这是这篇最核心的一句话。
Agent还能继续做，
只说明：
它还有下一步动作。
不代表：
下一步值得执行。
比如：
再搜一个文件
再试一个参数
再补一个测试
再重构一个模块
这些都可以无限继续。
真正需要判断的是：
每一步是不是让任务更接近完成。
如果不是：
继续执行本身就没有价值。
九、我更推荐设置一个“暂停检查点”
例如每完成5个关键步骤，
让Agent输出一次：
当前目标：
当前进度：
已确认Evidence：
剩余问题：
修改范围：
下一步动作：
继续执行的理由：
然后再判断：
继续。
暂停。
或者重新规划。
这相当于给长任务增加：
Execution Checkpoint
避免Agent一口气从：
分析
一路跑到：
大规模修改。
十、暂停以后应该做什么？
停下来不是：
什么都不做。
我更推荐四步。
第一步：总结Current State
现在已经确认了什么。
第二步：列出未解决问题
哪些是真正阻塞当前任务的。
第三步：清理无关分支
哪些问题先不处理。
第四步：重新决定预算
后续还值得执行多少步。
也就是：
Pause
↓
Summarize
↓
Refocus
↓
Resume
这样恢复执行以后，
Agent会重新回到主目标。
十一、执行预算不是越小越好
也不要走另一个极端：
给Agent限制得特别死。
比如：
只能改两个文件。
只能尝试一次。
只能跑一次测试。
这样复杂任务根本没法做。
Execution Budget真正的作用不是：
限制Agent能力。
而是：
在任务失控之前建立一个重新判断的机会。
预算可以动态调整。
但调整本身应该是：
显式决策。
而不是无上限地继续。
十二、不同任务的预算应该不一样
例如一个明确的小Bug：
可以用很小的预算：
5—8步
3个文件以内
2次测试
但一个大型重构可能需要：
30个步骤
多个阶段
十几个文件
多轮验证
所以预算不是统一数字。
真正应该提前定义的是：
什么情况代表“超出预期”。
一旦超过这个阈值，
就触发暂停。
十三、Agent最应该停下来的时刻：假设已经不可信
比如原始假设：
慢查询来自索引失效。
Agent围绕这个方向：
改索引。
调SQL。
重新测试。
结果性能还是没变化。
这时候真正应该做的不是：
继续优化索引。
而是：
停下来重新验证根因。
因为继续执行已经建立在：
一个可能失效的假设上。
这和昨天讲的Plan Drift其实类似：
计划没变。
但支撑计划的前提已经没有足够Evidence。
十四、给自己看一个指标：有效执行率
这篇我建议只看一个指标：
Effective Execution Rate——有效执行率
可以简单理解为：
真正推动任务接近完成的有效步骤 ÷ 总执行步骤
比如：
一次任务共执行20个主要步骤。
真正产生：
根因确认。
有效修改。
验证结果
的只有：
12个。
那么：
有效执行率 = 60%。
剩下40%可能都花在：
重复搜索。
重复重试。
无关修改。
无效验证。
十五、有效执行率低说明什么？
不一定说明Agent能力差。
更可能说明：
任务边界不清。
停止条件不足。
重试机制失控。
影响面不断扩大。
Evidence不够。
如果有效执行率长期只有：
40%—50%。
再增加更多AI调用，
并不会自动让任务更高效。
反而可能只是：
更快地执行更多无效步骤。
十六、怎么提高有效执行率？
我会优先做几件事。
第一：
任务开始前明确目标和完成条件。
第二：
提前设置修改范围。
第三：
连续失败必须带来新Evidence才能继续。
第四：
相关问题和阻塞问题分开。
第五：
阶段性执行Checkpoint。
第六：
达到预算后必须重新判断。
核心目标只有一个：
让每一步执行都有理由。
十七、Plus和Pro怎么判断？
如果你现在跑复杂任务时经常出现：
Agent越跑越长。
范围越来越大。
重复测试。
不断换方案。
最终还要人工大量收尾。
那当前真正限制效率的，
通常不是 ChatGPT、Codex 容量。
而是：
执行控制还没有建立起来。
这种阶段Plus通常已经够用。
更值得先把：
Execution Budget。
Checkpoint。
重试上限。
范围边界。
暂停条件
做好。
否则增加更多容量，
很可能只是让Agent：
跑得更久。
改得更多。
如果你的Workflow已经能够做到：
每个任务有明确预算。
超过范围自动暂停。
重复失败会重新验证假设。
每一步都能解释为什么继续。
有效执行率也比较稳定。
同时还有大量成熟任务排队等待Agent处理，
这时候Pro才更容易放大真实效率。
因为增加的容量是在：
一个可控的执行系统里工作。
最后
Agent任务为什么会越跑越长？
很多时候不是因为任务真的那么复杂。
而是因为：
没有人告诉它什么时候“不值得继续”。
复杂Agent Workflow真正成熟以后，
不应该只拥有：
执行能力。
还应该拥有：
停止能力。
当任务出现：
范围扩张。
重复失败。
Evidence不足。
目标漂移。
无效步骤越来越多。
主动暂停，
重新整理Current State，
往往比继续往前冲更重要。
所以以后再让 ChatGPT、Codex 跑长任务时，
除了问：
“它还能继续做什么？”
也应该多问一句：
“下一步真的还值得做吗？”
真正高效的Agent，
不是永远不停下来。
而是知道：
什么时候继续，什么时候应该停。
持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。
