最近用Codex做长任务时，有一种变化会越来越明显。

以前一个功能交给AI以后，开发者往往需要一路跟着：

读代码、告诉它改哪里、提醒它跑测试、发现错误再让它继续修。

但现在Agent能自己完成的步骤越来越多。

比如一个常见任务：

修复接口Bug → 找相关代码 → 修改实现 → 补测试 → 运行测试 → 根据失败结果继续修改。

很多时候，人并不需要每一步都参与。

表面上看，这意味着开发者终于可以把任务完整交出去。

但真正连续跑一段时间以后，会出现一个很有意思的现象：

正常任务越来越不需要人管，真正把开发者叫回来的，反而越来越集中在那些“不正常”的任务上。

比如：

权限突然不够。

测试环境和预期不一致。

依赖升级产生冲突。

需求本身存在歧义。

修改触碰了公共接口。

数据库Migration风险太高。

Agent发现有两种完全不同的实现路线。

某个失败到底应该继续Retry，还是直接停下来。

这意味着未来Agent工作流里，一个新的能力正在变得越来越重要：

Exception Path Management

异常路径管理。

不是教Agent怎么完成每一个正常步骤，而是提前设计：

当事情没有按照预期发展时，它应该怎么办。

---

一、以前为什么很少讨论“异常路径”？

因为过去大部分任务本来就是人在执行。

开发者自己：

写代码。

运行命令。

看报错。

决定下一步。

如果中途出现异常，人天然就在现场。

比如测试失败。

开发者可以马上判断：

是代码问题。

环境问题。

还是测试本身有问题。

所以过去很多异常处理并不会被单独设计成一套机制。

它们存在于开发者脑子里。

但Agent工作流不同。

当一个任务开始自动执行以后，人可能已经去做其他事情。

这时候如果Agent遇到异常，就必须自己回答三个问题：

还能不能继续？

应该怎么继续？

什么时候必须叫人回来？

如果这三个问题没有提前定义，自动化程度越高，风险反而越大。

---

二、Agent真正难的，不是“Happy Path”

很多开发流程其实都有一条很清楚的正常路径：

读任务。

定位代码。

修改。

Build。

Test。

输出结果。

这就是：

Happy Path

正常路径。

而Agent能力增强以后，这部分正在快速自动化。

真正麻烦的是：

正常路径一旦被打断以后怎么办？

例如Codex修改代码以后：

测试失败。

最简单的Agent可能直接继续修。

但这里其实存在很多不同情况。

如果只是一个明确的Assertion失败，继续修可能没问题。

但如果失败来自：

数据库连接异常。

测试环境缺少Secret。

依赖下载失败。

CI服务异常。

那继续修改代码，很可能完全没有意义。

所以：

“测试失败 → 继续修改”

看起来是自动化。

实际上可能只是把错误路径自动执行得更快。

---

三、深层问题：Agent执行的是动作，但异常处理需要“状态判断”

正常流程大多可以写成：

A → B → C → D。

但真实工程系统不是一条直线。

更接近：

A成功 → B。

A失败 → A1。

B失败 → B1或者B2。

C触碰高风险区域 → 暂停。

D验证不充分 → 回到C。

也就是说，真正成熟的Agent Workflow本质上更接近一个：

State Machine

状态机。

每一个关键步骤之后，不只是：

“下一步做什么？”

还应该判断：

当前任务现在处于什么状态？

例如测试完成以后，可能进入：

Verified。

Failed-Recoverable。

Failed-Environment。

Blocked。

Need-Human-Decision。

High-Risk。

这些状态对应的下一步完全不同。

所以未来Agent越来越成熟以后，开发者真正需要设计的，可能不再只是Prompt。

而是：

状态、边界和异常转移规则。

---

四、为什么AI越强，这个问题反而越明显？

因为以前Agent能力弱的时候，人会频繁介入。

每走两三步就要确认一次。

很多异常其实被人类手动吸收了。

但随着Agent越来越能自己：

读Repository。

运行Terminal。

修改多个文件。

执行测试。

根据结果继续行动。

一次任务内部的自主步骤会越来越多。

假设以前一个任务有5个关键步骤，每一步都由人控制。

现在一个Agent可能连续执行20个步骤。

那么即使每一步出问题的概率都不高，

整个任务遇到某种异常的机会仍然会越来越明显。

所以Agent越长、越自主，

开发者越不能只设计：

Success Path

成功路径。

还必须设计：

Failure Path

失败路径。

---

五、真正危险的不是失败，而是“失败以后Agent继续做错事”

一个Agent遇到错误并不可怕。

工程系统本来就会失败。

真正麻烦的是：

它不知道这是什么类型的失败，却继续执行。

例如：

依赖安装失败。

Agent认为代码有问题。

于是修改代码。

测试环境缺少配置。

Agent继续调整业务逻辑。

权限不足无法修改某个目录。

Agent绕到另一个路径重新实现一套逻辑。

一个原本很小的问题，就可能因为错误恢复策略变成：

Error Amplification

错误放大。

所以好的Agent Workflow不是要求：

永远不能失败。

而是要求：

失败以后，能够尽快识别失败类型，并进入正确的恢复路径。

---

六、异常路径至少应该分成三类

实际工程中，不需要一开始做一个特别复杂的异常系统。

先区分三类通常就已经很有价值。

第一类：可以自动恢复

例如：

Lint失败。

明确的单测失败。

格式错误。

简单类型错误。

这些问题通常：

原因明确。

影响范围有限。

可以验证修复结果。

Agent可以继续自动处理。

---

第二类：应该停止重试

例如：

第三方服务不可用。

网络问题。

权限不足。

缺失Secret。

外部资源不存在。

这类问题如果继续让Agent改代码，很容易浪费大量时间和使用量。

正确动作通常不是：

Retry Code Change。

而是：

Blocked。

---

第三类：必须人工判断

例如：

是否修改公共API。

是否引入新依赖。

是否允许Database Migration。

是否扩大任务范围。

是否接受安全边界变化。

这里的问题不是Agent“不会写”。

而是：

它没有业务授权替你做这个决定。

这时候最好的行为不是继续。

而是：

Escalate

升级给人。

---

七、未来真正重要的指标：Human Escalation Rate

如果只保留一个指标，我更建议看：

Human Escalation Rate——人工升级率

简单理解：

Agent执行的任务里，有多少最终因为异常、风险或不确定性，需要开发者重新介入。

比如一天跑20个Agent任务。

其中：

12个从开始到验证都自动完成。

5个遇到明确测试失败后自动修复。

3个需要开发者亲自判断。

那么真正值得关注的不是：

“今天跑了20个任务。”

而是：

有多少任务最后还是把人的注意力拉回来了。

如果Human Escalation Rate很高，

说明当前瓶颈可能不是AI执行能力。

而是：

异常分类。

任务边界。

风险规则。

验证标准。

还不够成熟。

---

八、为什么人工升级率比“任务完成数”更值得看？

因为两个团队都可能每天跑100个Agent任务。

团队A：

80个任务需要人工回来处理。

团队B：

只有10个。

表面看：

Agent任务量一样。

实际自动化成熟度完全不同。

团队A其实只是把很多任务：

提前启动了。

开发者最后依旧要逐个接回来。

这会形成一种新的队列：

Escalation Queue

人工升级队列。

Agent跑得越快，

人被叫回来处理异常的任务越多。

最后又会回到：

AI等人。

所以未来Agent系统真正成熟的标志，不只是：

能不能自动执行更多。

而是：

有多少正常问题可以自己闭环，又有多少真正需要人的问题才会升级。

---

九、怎么降低Human Escalation Rate？

第一，在任务开始前把边界写清楚。

比如：

允许修改哪些目录。

不能改哪些公共接口。

是否允许新增依赖。

是否允许修改Schema。

如果越界应该暂停。

很多所谓“Agent异常”，其实来自任务边界从一开始就没定义。

---

第二，把可自动恢复的问题提前分类。

例如明确：

Lint错误可以自动修。

Unit Test失败最多Retry两轮。

网络错误不要修改代码。

权限错误直接停止。

不要把所有失败都交给Agent自由判断。

---

第三，建立Stop Condition。

这是非常重要的一步。

比如：

连续两次修改后仍然是同一错误。

修改范围超过原计划。

需要触碰安全配置。

需要改变公开Contract。

满足这些条件就停止。

否则Agent越能长时间运行，越容易把一个异常不断放大。

---

第四，升级给人时不要只丢一句“失败了”。

真正好的Escalation应该包含：

发生了什么。

已经尝试了什么。

为什么不能继续。

目前有哪些选择。

每个选择有什么风险。

这样开发者回来以后是在：

做判断。

而不是重新从头调查整个任务。

---

十、异常管理成熟以后，开发者会从“监督执行”转向“处理例外”

这可能是Agent开发里一个非常重要的长期变化。

以前开发者大量时间用于：

执行正常步骤。

以后这些Happy Path越来越容易自动化。

人的工作会逐渐集中到：

模糊问题。

高风险问题。

跨系统问题。

异常恢复。

关键决策。

换句话说：

开发者不会消失。

但人的角色可能会越来越接近：

Exception Manager

异常管理者。

真正值钱的能力不再是：

盯着Agent一步一步做。

而是：

让绝大多数正常任务不需要你，同时让真正异常的任务尽快找到你。

---

十一、为什么这会直接影响Plus和Pro的选择？

这里很容易产生一个误区：

Agent任务越来越多以后，直接升级更高容量就行。

但如果你的Human Escalation Rate很高，

结果往往是：

Agent启动得更多。

异常也产生得更多。

最后所有任务一起等你处理。

这时候增加AI容量，并没有真正增加系统吞吐。

只是增加了：

Unresolved Work

未解决工作。

---

十二、什么情况下Plus通常已经够？

如果你现在的Codex任务经常出现：

每个任务都需要中途确认。

测试一失败就要人工接管。

Agent经常不知道该不该继续。

任务边界容易扩大。

同一个问题反复Retry。

Human Escalation Rate明显偏高，

那么Plus通常已经足够帮助你改善这一阶段的问题。

真正应该优先优化：

任务边界。

异常分类。

Stop Condition。

验证规则。

Escalation Summary。

先让更多任务可以稳定自己闭环。

比单纯增加Agent执行容量更重要。

---

十三、什么时候Pro才真正开始匹配？

更接近Pro的状态应该是：

大部分低风险任务可以自主完成。

常见失败可以自动恢复。

环境问题能够准确停止。

高风险变更能够及时升级。

Human Escalation Rate已经明显降低。

开发者每天真正需要处理的异常数量可控。

但是仍然存在大量：

目标明确。

边界清楚。

验证标准成熟。

可以独立执行。

有真实业务价值。

的任务持续排队。

这时候瓶颈才真正从：

Exception Management Problem

异常管理问题

转向：

Capacity Problem

容量问题。

这时更高的Agent使用能力才更容易真正转化成：

更多有效完成的任务。

---

最后

Agent越来越能自己完成任务，并不意味着开发者以后什么都不用管。

更可能发生的是：

正常路径越来越少需要人管，异常路径越来越值得人管。

以前开发者负责：

把任务一步一步做完。

以后开发者更可能负责：

定义什么时候继续。

什么时候停止。

什么时候恢复。

什么时候必须交给人。

所以未来真正成熟的Agent Workflow，不应该只回答：

“任务成功时怎么完成？”

还必须回答：

“任务没有按照预期发展时怎么办？”

AI越强，

Happy Path越容易被自动化。

而真正决定Agent能不能安全、稳定、大规模运行的，

反而会越来越变成：

Exception Path

异常路径。

这可能才是Agent从“能完成任务”，走向“能长期可靠工作”的下一道门槛。

持续分享 Codex、大模型开发与 AI 编程实战内容。
长期深度使用各类代码大模型，也整理了稳定的Plus/Pro会员订阅渠道，有需要可自取。