很多开发者第一次把复杂任务真正交给Codex以后，会发现一个很反直觉的问题。

短任务的时候，AI往往非常稳。

你让它：

修一个函数。

补一个测试。

改一个接口。

它很快完成，结果通常也比较容易判断。

但任务一旦开始变长，情况就可能发生变化。

比如你最开始只是告诉AI：

“修复用户登录后偶尔丢失Session的问题，不改变现有接口。”

Codex开始分析。

它先检查Session。

然后发现Token刷新逻辑可能有关。

继续调查后，又发现缓存策略可能影响状态同步。

于是它修改缓存。

测试失败。

为了让测试通过，它又调整异常处理。

随后发现几个地方存在重复逻辑，于是顺手统一。

几十分钟以后，AI告诉你：

任务完成，测试全部通过。

你打开Diff，却发现：

原本只是一个Session Bug。

最后变成：

Token逻辑变了。

缓存逻辑变了。

异常处理变了。

几个公共方法也被调整了。

甚至测试结构都发生了变化。

最奇怪的是：

你很难指出AI到底从哪一步开始“跑偏”。

因为把每一步单独拿出来看，似乎都有理由。

这就是长时间AI任务里一个非常值得注意的问题：

AI不一定突然走错方向，更常见的是每一步只偏一点，最后离原始目标越来越远。

这可以叫做：

Goal Drift——目标漂移。

---

一、真实开发里，AI为什么经常不是“突然跑偏”？

很多人理解AI任务失败，会想象成这种情况：

第一步正确。

第二步正确。

第三步突然做了一个明显错误决定。

然后任务失败。

但复杂Agent任务往往不是这样。

真正危险的是：

每一步都“差不多合理”。

还是刚才那个Session问题。

最初目标非常明确：

修复Session丢失。

AI发现Token刷新可能相关。

合理。

检查Token以后发现缓存可能相关。

也合理。

修改缓存以后测试失败。

于是调整异常处理。

似乎还是合理。

异常处理调整以后，发现代码结构重复，于是抽象公共方法。

单独来看，好像也说得过去。

但这时候你回头看最初目标：

我们不是只想修Session吗？

问题出现了。

AI没有在某一步明显犯错。

而是在连续决策过程中，任务的中心慢慢发生了变化。

最初：

修复Session问题。

后来：

解决Token和Session同步问题。

再后来：

保证认证模块整体正常。

最后：

顺便改善认证模块的代码质量。

任务就在这种连续的“合理扩张”中漂移了。

---

二、为什么短任务不明显，长任务却特别容易出现？

因为短任务的决策链很短。

例如：

修改一个函数。

可能只有：

理解 → 修改 → 测试。

三个主要阶段。

即使每一步存在一点偏差，也没有足够长的路径让偏差持续累积。

但长任务完全不同。

一个复杂Codex任务可能经历：

理解需求。

搜索Repository。

判断根因。

制定方案。

修改A。

运行测试。

发现B。

重新判断。

修改B。

发现C。

再次测试。

继续调整。

最后验证。

这实际上已经不是“一次回答”。

而是一条：

Decision Chain——连续决策链。

只要这条链足够长，一个很小的方向偏差就可能被后续步骤不断继承。

---

三、背后的机制：长任务真正危险的是“误差累积”

可以把一个Agent任务简单理解成：

State₀ → Decision₁ → State₁ → Decision₂ → State₂ → Decision₃……

AI每执行一步，都会改变当前状态。

然后下一步判断，又建立在新的状态上。

这意味着：

后面的决策不是独立的。

它依赖前面发生过什么。

假设最开始AI对问题的理解只有一点点偏差。

第一次判断：

95%正确。

看起来问题不大。

但下一步是基于这个判断继续。

随后再产生一点偏差。

再继续。

随着任务越来越长，最终状态可能逐渐偏离最初目标。

所以长任务风险不能只看：

AI单步准确率高不高？

还要看：

错误有没有在连续状态中被继承。

这就是Agent和普通聊天非常不同的地方。

普通聊天答错一次：

重新问就可以。

Agent做错一次：

可能已经修改了代码。

而后面的判断，又建立在这些修改之上。

---

四、还有一个更隐蔽的问题：局部目标会逐渐替代原始目标

这是Goal Drift真正值得注意的地方。

Agent执行任务时，会不断产生新的局部问题。

比如原始目标：

修复Session丢失。

执行过程中出现：

测试失败。

于是新的局部目标变成：

让测试通过。

为了让测试通过，又发现Mock有问题。

于是目标变成：

修复Mock。

修Mock时发现测试结构不好。

于是又变成：

调整测试结构。

这些局部目标本身都合理。

但如果没有持续回到原始目标进行校准，Agent可能逐渐从：

“完成用户真正要的任务”

变成：

“解决当前眼前出现的问题”。

这两个目标不是一回事。

可以把它理解成：

Global Goal和Local Goal之间发生了竞争。

Global Goal：

用户真正要求完成什么。

Local Goal：

当前这一步最需要解决什么。

长任务里，Local Goal会不断出现。

如果Agent一直追逐Local Goal，原始Global Goal就可能慢慢失去控制力。

---

五、为什么“测试全部通过”仍然可能已经跑偏？

这是很多人使用Codex时容易产生的误区。

Agent最后告诉你：

Tests Passed。

于是感觉：

应该没问题。

但测试回答的是：

当前代码是否满足测试定义的条件。

它不一定回答：

当前代码是否仍然只完成了原始任务。

比如：

你的目标只是：

修复一个登录Bug。

AI最后：

重构认证模块。

调整Token。

改变缓存策略。

然后把相关测试全部调整到通过。

从测试角度：

绿色。

但从任务Scope来看：

可能已经扩大很多。

所以长任务不能只验证：

Correctness。

还要验证：

Alignment。

也就是：

最终结果和最初目标是不是仍然对齐。

---

六、为什么未来Goal Drift会越来越明显？

因为AI Coding正在从：

代码生成

走向：

长时间自主执行。

以前你问ChatGPT：

“这个Bug怎么修？”

AI给一个方案。

决定权马上回到人。

任务链很短。

现在Codex越来越能够：

自己调查。

自己修改。

自己测试。

自己处理失败。

自己继续探索。

未来Agent一次运行可能完成越来越长的工作链。

这意味着两个东西会同时增加：

Action Depth——行动深度。

以及：

Decision Distance——人与关键决策之间的距离。

Agent每多自主执行一步，人就少观察一个中间状态。

所以未来真正成熟的AI工作流，不会只追求：

“让Agent跑得更久。”

而会追求：

让Agent跑得更久，同时仍然保持目标不漂移。

这才是长任务真正困难的地方。

---

七、可以用“目标漂移率”判断自己的AI任务是否失控

这里可以建立一个自测指标：

目标漂移率

不要看AI最后有没有说“完成”。

而是比较：

最终结果与最初Done Criteria之间，有多少内容已经发生变化。

例如任务开始前，你定义：

1. 修复Session丢失；
2. 不改变Public API；
3. 不调整数据库结构；
4. 不进行无关重构；
5. 原有测试保持通过。

任务完成以后检查。

如果只是修复Session并补测试：

目标漂移率很低。

如果最后：

API改了。

缓存策略变了。

认证模块重构了。

增加了新的抽象。

虽然Bug也解决了，但大量结果已经超出最初Done Criteria。

目标漂移率就很高。

---

还可以观察三个非常直接的信号。

第一，最终Diff里有多少修改无法直接对应原始任务？

越多，漂移越明显。

第二，AI执行过程中是否不断出现“既然已经发现了，不如顺便处理”？

这通常是Scope开始扩张的信号。

第三，任务结束后，你是否需要重新解释“我们最开始到底要解决什么”？

如果经常发生，说明长任务已经开始失去目标锚点。

---

八、降低Goal Drift，不是把任务全部切成一分钟的小任务

看到这里，很容易走向另一个极端：

那以后不让Agent跑长任务。

每一步都回来问我。

这样当然能降低漂移。

但也会直接损失Agent最重要的价值：

自主执行。

真正应该解决的不是：

如何阻止AI行动。

而是：

如何让AI在行动过程中持续知道自己为什么行动。

第一个方法就是：

给任务建立固定目标锚点

任务开始时明确写下：

目标。

非目标。

限制条件。

Done Criteria。

例如：

目标：

修复Session偶发丢失。

非目标：

不优化整个认证系统。

限制：

不改变Public API。

Done：

复现问题消失 + 原测试通过 + 新增回归测试。

这相当于给Agent建立一个不会随着局部问题变化的Reference Point。

---

九、第二个关键：给长任务加入Checkpoint

如果一个任务需要运行很久，不应该只检查：

开始。

结束。

中间应该存在几个关键Checkpoint。

比如：

Checkpoint 1：根因确认。

先确认到底是什么导致问题。

Checkpoint 2：修改方案确认。

确定准备改哪些地方。

Checkpoint 3：Scope检查。

如果发现需要扩大范围，重新确认。

Checkpoint 4：最终验收。

比较结果和原始Done Criteria。

注意：

Checkpoint不是每一步都人工审批。

那会让Agent失去意义。

它真正的作用是：

在偏差还没有累积太远以前，把任务重新拉回原始目标。

---

十、第三个关键：让AI定期“重新读取原始任务”

长任务里，一个很有效的方法是让Agent在关键阶段重新回答三个问题：

我最初要完成什么？

我现在正在做什么？

当前动作和最初目标有什么直接关系？

如果第三个问题已经很难回答：

应该停下来。

这比简单告诉AI：

“不要跑偏。”

有效得多。

因为“不要跑偏”没有工程定义。

而：

当前修改必须能够映射到原始Done Criteria

是可以检查的。

---

十一、目标漂移率低：Plus通常已经够用

如果你的日常AI Coding主要是：

局部Bug。

明确Feature。

小型项目。

短到中等长度任务。

而且AI最终结果基本都能和原始目标保持一致。

那么你的核心需求仍然是：

提高开发效率。

这种情况下，Plus通常已经能够覆盖大量实际需求。

因为真正限制你的，并不是长时间复杂Agent执行能力。

---

十二、目标漂移率高，也不要第一时间认为应该Pro

这一点尤其重要。

如果你现在让AI跑复杂任务，经常出现：

越跑越远。

修改越来越多。

Scope不断扩大。

最后需要大量人工返工。

那么增加AI侧能力，不一定能解决问题。

因为你的瓶颈可能不是：

AI跑得不够久。

恰恰可能是：

AI已经跑得太久，但你的长任务控制机制还没有建立。

这时候应该先解决：

Goal Anchor。

Done Criteria。

Checkpoint。

Scope Control。

阶段性验证。

否则更高的执行能力，只可能让任务更快地跑得更远。

---

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

真正接近Pro阶段的状态是：

你已经能够稳定运行复杂Agent任务。

任务开始前有清晰目标。

过程中有Checkpoint。

Scope扩大能够及时发现。

最终结果能够快速映射回Done Criteria。

目标漂移率已经控制在较低水平。

但是你的真实工作里仍然持续存在：

大型Repository。

复杂Codex任务。

长时间Agent执行。

多个高价值工程任务。

这时候，更高强度的AI使用才更可能直接转化成真实生产力。

所以判断逻辑不是：

“我的任务跑得很久，所以需要Pro。”

而应该是：

“我已经能可靠管理长任务，现在AI侧执行能力才开始成为限制。”

这两个阶段完全不同。

---

最后：Agent真正难的不是“跑得久”，而是“跑很久以后还记得为什么出发”

短任务时代，我们关心的是：

AI回答得准不准。

Agent时代，这个问题正在变成：

AI连续做几十个决定以后，最终结果还和最初目标一致吗？

因为复杂任务真正危险的地方，不一定是某一步突然出现巨大错误。

更可能是：

每一步都合理一点。

每一步都偏一点。

几十步以后：

方向已经变了。

所以未来真正成熟的AI开发者，不会只是追求：

让Codex一次运行更久。

而会建立一套机制，让它在长时间自主执行过程中不断回答：

我为什么做这一步？

它和原始目标有什么关系？

现在是不是已经应该停止？

如果你的任务短、目标漂移率低：

Plus通常已经够用。

如果你已经能够稳定控制复杂长任务，并且大量高价值Agent执行开始受AI侧能力限制：

Pro才真正开始匹配。

未来Agent最重要的能力，可能不只是：

走得更远。

而是：

走得很远以后，仍然没有忘记自己最开始要去哪里。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道，有需要可自取！