很多人使用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会员订阅渠道。
