很多人使用Codex做短任务时，体验其实已经很好。

比如：

修一个Bug。

改一个接口。

补几个测试。

调整一段逻辑。

通常第一轮分析之后，Codex就能比较准确地理解你想做什么。

但任务一旦拉长，另一种情况就容易出现：

刚开始，它明明理解得很准确。

知道为什么改。

知道哪些地方不能动。

甚至自己给出的Plan也没有问题。

可执行了一段时间以后，慢慢开始出现一些奇怪的变化：

原本说好只修改认证模块，后面顺手改到了其他目录；

原本要求保持API兼容，后面为了让测试通过改变了接口；

原本只是修Bug，做着做着开始重构；

甚至到了最后，你不得不重新提醒：

“我们一开始要解决的不是这个问题。”

于是很多人会把这种现象理解成：

Codex是不是把前面的内容忘了？

但如果往下挖一层，会发现真正的问题并没有这么简单。

长任务里最危险的，并不一定是“忘记”。

而是：

任务执行过程中产生的新信息越来越多，Agent当前正在解决的问题，开始逐渐覆盖最初的目标。

这可以叫做：

目标漂移。

---

一、短任务为什么很少出现“前面懂、后面忘”？

先看一个非常简单的任务：

修复login.ts里的Token刷新Bug，不修改API结构，完成后运行现有测试。

这个任务的信息结构很简单。

目标：

修Token Bug。

边界：

不改API。

验收：

测试通过。

Codex读取相关代码以后，很快就可以进入：

分析 → 修改 → 测试 → 完成。

整个过程中产生的新信息有限。

所以最开始的目标和最后执行的目标，很容易保持一致。

但如果换成：

重构整个认证模块，同时迁移Token机制，保持旧客户端兼容，并补齐测试。

事情就完全不同了。

Codex可能需要：

先分析Repository；

理解认证流程；

寻找Token调用；

分析客户端兼容逻辑；

设计迁移方案；

修改多个文件；

运行测试；

处理测试失败；

再次修改；

发现新的依赖；

重新验证。

任务越往后走，Agent需要处理的信息就越多。

问题也开始从一个变成很多个。

最初的问题可能是：

怎么迁移认证模块？

执行两小时以后，当前问题可能已经变成：

为什么这个Integration Test一直失败？

这时候真正危险的事情发生了。

---

二、Codex不一定“忘了”，而是当前问题的权重变高了

这才是长任务最值得理解的机制。

Agent执行任务时，不是在脑子里永久保存第一条Prompt，然后所有后续决策都机械服从它。

任务执行过程中会不断产生新的Context：

代码读取结果；

工具调用结果；

测试错误；

新的文件；

新的依赖关系；

刚刚做出的修改；

失败过的方案；

新的推断。

于是一个长任务里实际上同时存在两种东西：

Original Goal

最开始为什么做这个任务。

以及：

Current State

现在做到哪里，眼前正在解决什么问题。

短任务里，两者通常高度一致。

但是任务越长，Current State会越来越复杂。

比如：

原始目标：

保持API兼容完成认证迁移。

后来测试失败。

Codex发现如果修改一个Response字段，测试马上能通过。

此时局部问题变成：

怎样让这个测试通过？

如果最初的“API必须兼容”没有持续成为一个高优先级约束，Agent就可能做出一个局部看起来完全合理的决定：

修改Response。

测试通过了。

当前问题解决了。

但是：

原始目标被破坏了。

所以这种现象看起来像：

“Codex忘了前面的要求。”

实际上更准确的说法应该是：

局部最优开始覆盖全局目标。

这比单纯的“Context不够长”更值得注意。

---

三、为什么长任务特别容易出现“局部最优”？

因为长任务不是一个Prompt。

它是一串连续的决策。

假设一个任务有：

分析；

Plan；

第一次修改；

第一次测试；

修复；

第二次测试；

再次修改；

Review。

每一个阶段都会产生一个新的局部目标。

例如：

分析阶段：

找到Root Cause。

修改阶段：

实现方案。

测试阶段：

让测试通过。

修复阶段：

消除当前Error。

这些目标单独看都没问题。

真正的问题是：

局部目标必须一直服从最开始的全局目标。

否则任务就会出现一种非常典型的漂移：

一开始：

“最小范围修复Bug。”

后来：

“为了修Bug改一下这个模块。”

再后来：

“既然已经改这个模块，不如顺便整理结构。”

最后：

“干脆重构一下。”

每一步单独看都说得过去。

但最后回头一看：

任务已经不是最开始那个任务了。

这就是为什么Agent长任务真正难的地方，不只是模型有没有足够大的Context。

而是：

它能不能在大量局部决策中持续保持目标一致性。

---

四、真正需要管理的是三个东西：Goal、State和Constraint

如果把长任务拆开，其实可以看成三个核心变量。

Goal：最终要完成什么

例如：

修复认证Bug。

State：现在做到哪里

例如：

Root Cause已经找到，目前正在修改刷新逻辑。

Constraint：哪些事情绝对不能因为执行而改变

例如：

不能改变Public API；

不能删除旧客户端兼容逻辑；

不能修改数据库Schema。

很多长任务失败，并不是Goal没有写。

而是：

Constraint只在第一条Prompt里出现了一次。

随着任务继续推进，大量新的State不断进入Context。

于是Constraint的存在感越来越弱。

所以长任务真正需要的，不是把第一条Prompt写成2000字。

而是：

让Goal和关键Constraint在整个任务生命周期里持续存在。

这也是为什么Plan、Milestone、AGENTS.md、测试和验收标准会越来越重要。

它们实际上都在做同一件事情：

把任务目标从“聊天内容”变成可持续验证的外部状态。

---

五、小华指标：你的“目标漂移率”是多少？

这里可以给自己的Codex长任务建立一个非常简单的指标：

目标漂移率

这不是OpenAI官方指标，而是一个个人自测方法。

定义：

一个任务执行过程中，你需要多少次重新提醒Codex“最开始到底要做什么”。

例如你最近10个长任务。

其中8个从Plan到最终完成基本没有改变方向。

只有2个需要你重新纠正。

那么：

目标漂移率比较低。

另一种情况：

10个长任务里面，有6个都出现：

“不要改这里。”

“这个接口不能动。”

“我们不是要重构。”

“回到原来的目标。”

“这个不是这次任务范围。”

那就说明：

目标漂移率已经比较高。

这时候不要第一时间认为：

“我需要更强模型。”

因为真正的问题可能是：

你的长任务没有稳定的目标锚点。

---

六、先别升级，先给长任务建立“目标锚点”

如果Codex经常前面懂、后面偏，可以先做几个调整。

第一，复杂任务先Plan，不要直接执行

先让Codex告诉你：

准备解决什么；

准备修改什么；

哪些地方不动；

怎么验证完成。

你确认以后再执行。

这相当于先把Original Goal固定下来。

---

第二，把“不能做什么”单独写出来

很多人特别喜欢写：

“请完成什么。”

却很少写：

“绝对不要做什么。”

长任务里，后者非常重要。

例如：

不要修改Public API。

不要做与当前Bug无关的重构。

不要删除兼容逻辑。

这些就是Constraint。

---

第三，把一个大任务拆成Milestone

例如：

第一阶段：

只分析，不改代码。

第二阶段：

确定方案。

第三阶段：

完成核心修改。

第四阶段：

补测试和验证。

每完成一个阶段，都重新检查：

现在做的事情，还是不是在服务最开始的Goal？

这比让Agent连续跑到底稳定得多。

---

第四，给任务一个明确的Done Criteria

比如：

不是：

“把认证模块弄好。”

而是：

“所有现有测试通过；旧API保持兼容；新增Token刷新测试通过；不修改数据库Schema。”

这样任务最后判断的是：

有没有满足最初验收条件。

而不是：

“当前还有没有Error。”

这两者差别非常大。

---

七、目标漂移率低，Plus通常更符合实际使用

现在再回到Plus和Pro。

如果你的日常Codex使用主要是：

短任务；

单模块修改；

普通Bug；

小型Feature；

偶尔才跑一次长任务。

而且经过Plan、Milestone和验收标准优化以后，大多数任务都可以稳定完成，很少需要中途重新纠正方向。

那么你的：

目标漂移率低。

这种情况下，Plus通常更符合实际使用。

因为你的核心需求仍然是：

日常Coding + 偶尔复杂任务。

这时候把任务结构设计好，往往比单纯增加使用强度更重要。

---

八、目标漂移率高，但先区分两种完全不同的原因

这里不能简单写：

目标漂移率高 = Pro。

因为这会把两个完全不同的问题混在一起。

第一种：

任务设计差导致的漂移。

目标模糊；

边界没写；

没有Milestone；

没有验收标准。

这种情况应该先优化Workflow。

Plus也可以继续用。

第二种才是真正值得注意的：

你已经：

有明确Plan；

有Constraint；

有Milestone；

有Done Criteria；

任务也已经合理拆分。

但你的真实工作本身仍然大量属于：

大型Repository；

跨模块修改；

长时间Debug；

复杂迁移；

多轮工具调用；

持续验证和修复。

这时候目标漂移高背后的原因，不再只是任务写得不好。

而是：

你的任务本身就在持续产生大量新的State。

这才是高强度Agent工作真正困难的地方。

---

九、当“长任务”已经成为每天的工作方式，Pro才开始有价值

所以判断Pro不能只看：

“Codex会不会忘。”

真正应该看的是：

优化以后，你还有多少任务必须长时间持续执行？

如果偶尔只有一个：

没必要。

但如果每天大量任务都需要：

持续读取Context；

跨文件修改；

多轮工具调用；

反复验证；

失败恢复；

重新规划。

那么你的AI工作方式已经发生变化。

你不再主要是在：

让AI回答问题。

而是在：

让Agent持续完成工作。

这时候，更高的使用空间、更长时间的高强度Coding Session以及复杂任务能力，才开始真正产生价值。

于是Plus和Pro的判断就非常清楚：

如果：

长任务少；

目标漂移率低；

经过Workflow优化以后使用稳定；

Plus通常够用。

如果：

长任务已经成为日常；

项目Context复杂；

即使建立Goal、Constraint、Milestone以后，仍然每天需要大量持续执行和多轮验证；

Pro才更符合这种工作强度。

---

最后：长任务真正考验的不是“记忆”，而是目标一致性

所以以后再遇到：

Codex前面理解得很好，后面却慢慢开始跑偏。

不要只问：

“它是不是忘了？”

更应该问：

“任务执行到现在，当前局部目标是不是已经覆盖了最初的全局目标？”

这是两个完全不同的问题。

前者容易让人想到：

换更强模型。

后者会让你开始检查：

Goal有没有固定；

Constraint有没有持续存在；

Milestone有没有设置；

Done Criteria是不是明确。

Agent任务越来越长以后，真正重要的能力也会从：

一次理解正确

逐渐变成：

连续几十次决策以后，仍然知道自己为什么在做这件事。

所以今天判断自己更适合Plus还是Pro，也可以先看一个很简单的问题：

最近10个Codex长任务里，有多少次需要你中途把它“拉回原来的目标”？

很少：

先继续把Plus和Workflow用好。

很多，而且任务结构已经优化：

再看这些长任务是不是已经成为每天的主要工作负载。

如果答案仍然是“是”，Pro才真正开始有意义。

因为真正把Plus用户推向Pro的，从来不应该只是：

一个任务偶尔跑得很长。

而应该是：

长任务已经成为你的常态，而且你每天都需要Agent在复杂Context里持续保持目标一致性。

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