最近用Codex跑长任务时，我越来越在意一个问题：

Agent开始任务时看到的项目，和它真正结束任务时面对的项目，可能已经不是同一个状态了。

这类问题特别隐蔽。

因为很多时候，你回头看Agent生成的代码，会发现：

逻辑没明显错误。

修改方向也合理。

测试甚至也能通过。

但真正准备合并时，却发现：

分支已经变了。

接口已经被别人改过。

依赖版本更新了。

另一个Agent也碰了同一个模块。

甚至你自己中途提交了一次新的代码。

于是就会出现一种很典型的情况：

Agent不是把代码改错了，而是在一个已经过期的项目状态里，把代码改对了。

这两者差别很大。

也是多Agent、长任务越来越常见以后，一个很容易被低估的工程问题。

---

一、先看一个很真实的场景

假设你让Codex处理一个登录模块Bug。

任务开始时，项目状态是A。

它读取代码以后，发现：

问题来自旧的Session处理逻辑。

于是开始修改：

Auth Service。

Session类型。

相关测试。

这个任务需要二三十分钟。

但在这段时间里，另一个开发者刚好合并了一个PR。

那个PR也修改了Session结构。

于是项目已经从状态A变成了状态B。

问题来了。

Codex当前的整个判断链，仍然建立在：

状态A。

它继续修改。

继续跑测试。

继续完成任务。

最后交给你一个看起来很完整的Diff。

但真正合并到最新代码时：

冲突出现了。

类型对不上。

旧假设失效。

甚至修复逻辑已经不适合现在的项目结构。

这就是一个很典型的：

Project State Drift——项目状态漂移

---

二、什么叫“项目状态”？

很多人理解项目状态，只会想到：

代码文件。

但真实项目状态其实远不止代码。

它至少包括：

当前分支。

最新Commit。

依赖版本。

数据库Schema。

环境变量。

配置。

Feature Flag。

接口契约。

测试数据。

其他并行任务产生的修改。

所以Agent开始工作时，它实际上是在一个具体的“世界状态”里做判断。

如果这个世界中途变化了，而Agent没有重新同步，就会出现：

推理仍然自洽，但前提已经失效。

这才是最麻烦的地方。

---

三、为什么这类问题特别难发现？

因为它不像普通Bug那样明显。

普通Bug通常是：

代码错了。

类型错了。

测试失败了。

而状态漂移很多时候表现成：

代码本身没错。

问题只是：

它属于旧版本的正确答案。

比如Agent认为：

getUser()返回的是：

User

于是所有修改都围绕这个前提展开。

但中途最新代码已经变成：

User | null

Agent如果没有重新读取，就会继续基于旧契约工作。

这时候你逐行看它的代码，甚至会觉得：

“写得挺合理。”

但放到最新项目里就不成立了。

---

四、为什么Agent时代，这个问题会比以前更明显？

因为过去人类开发时，项目状态变化通常更容易被自己感知。

你在写代码。

看到别人刚合并PR。

你会拉一下最新代码。

发现冲突。

重新处理。

整个过程是连续的。

但Agent不一样。

Agent一旦开始一个长任务，可能会持续：

读取。

分析。

修改。

测试。

修复。

再测试。

这个过程中，它很可能把最开始读到的上下文，当成当前真实状态。

如果外部世界发生变化，它未必会主动知道。

所以Agent任务越长：

状态漂移风险越高。

---

五、多Agent并行以后，状态漂移会进一步放大

如果只有一个Agent，问题还相对容易控制。

但一旦同时跑多个Agent：

Agent A改Auth。

Agent B改User Schema。

Agent C改API。

它们可能一开始互不冲突。

但随着任务推进：

A依赖了B正在修改的类型。

C又依赖A的接口。

于是最开始三个“独立任务”，逐渐产生了交叉。

这时候一个Agent的输出，可能会让另一个Agent的项目状态发生变化。

结果就是：

Agent之间开始彼此制造状态漂移。

这也是为什么多Agent并发并不等于简单多开几个窗口。

真正需要管理的是：

每个任务基于什么状态开始。

中途状态有没有变化。

什么时候必须重新同步。

---

六、最容易发生状态漂移的几个地方

1. 分支和Commit

这是最直观的。

Agent开始时基于Commit A。

任务执行期间，主分支已经到了Commit F。

如果中间改动影响当前模块，Agent输出就很可能过时。

---

2. API契约

一个接口参数或返回值变化，可能影响多个Agent。

尤其是：

Backend和Frontend并行开发时。

只要一边先变，另一边如果继续按旧契约工作，就会产生漂移。

---

3. 数据库Schema

数据库字段一旦变化，很多依赖它的：

Model。

Migration。

Query。

Test Fixture。

都会受到影响。

这类状态漂移通常影响面很大。

---

4. 依赖版本

Agent开始时依赖某个库的旧版本。

任务中途项目升级。

API已经变化。

那么原本正确的实现可能马上变成旧写法。

---

5. 配置和环境

Feature Flag、环境变量、部署配置发生变化以后，也可能让Agent之前的判断失效。

而这些变化往往不直接出现在代码Diff里，所以更难发现。

---

七、为什么“测试通过”也不一定能发现状态漂移？

因为很多测试也是在Agent自己的工作环境里跑的。

如果它的本地状态仍然是旧状态：

代码和测试可能彼此一致。

于是全部通过。

但当你真正拿去和最新主分支合并时：

问题才出现。

所以测试通过只能说明：

当前工作树里的代码，在当前测试环境下成立。

它不能证明：

这份修改仍然适配最新项目状态。

这也是状态漂移最容易制造误判的地方。

---

八、一个重要区别：逻辑错误和基线错误不是一回事

面对这类问题，很多人会第一时间让Codex：

“重新修一下。”

但如果真正问题是状态漂移，那重新修代码往往不是最优解。

因为你首先应该确认的是：

Agent当前基于哪个基线工作？

比如：

Branch是什么？

Commit是什么？

依赖版本是什么？

最近是否有关键PR合并？

有没有其他Agent动过相关模块？

如果基线已经过时，那么再继续在旧状态上修改，只会让问题越来越大。

所以这类问题更像：

Baseline Management。

而不是普通Debug。

---

九、怎么降低项目状态漂移？

1. 长任务开始前记录基线

至少记录：

分支。

Commit。

依赖版本。

关键接口状态。

这样任务完成时可以对比：

项目有没有发生关键变化。

---

2. 任务时间越长，越要设置重新同步点

比如一个Agent任务运行很久。

做到中间阶段时，可以要求它重新检查：

当前分支是否变化。

关键文件是否被修改。

接口契约是否更新。

这样可以避免一路在旧世界里跑到最后。

---

3. 高冲突模块不要并行改

例如：

Auth。

User Schema。

核心Config。

数据库Model。

这种公共模块一旦被多个Agent同时修改，状态漂移概率会明显上升。

更适合串行处理。

---

4. 合并前必须重新验证最新基线

不要只看Agent自己最后一次Tests Passed。

更应该：

拉最新代码。

重新合并。

重新Build。

重新跑关键测试。

因为真正决定能不能合并的是：

最新项目状态下是否仍然成立。

---

十、另一个实用方法：给Agent加“状态检查”

可以要求Agent任务完成时额外输出：

开始时的Commit。

当前Commit。

任务期间关键文件是否发生外部变化。

是否发现新的依赖或接口变化。

是否需要重新基于最新代码验证。

这类信息看起来不复杂，但对长任务特别有价值。

因为它让你知道：

Agent不仅做完了任务。

还知道自己是不是仍然工作在正确世界里。

---

十一、什么时候应该直接停止任务，而不是继续补？

如果任务执行到一半发现：

核心Schema已变。

关键接口已重写。

主分支重构了当前模块。

另一个PR已经解决相同问题。

这时候继续让Agent沿着旧方案补丁式修改，通常不划算。

更好的选择是：

停止。

同步最新状态。

重新规划。

因为状态漂移超过一定程度以后：

继续修旧方案的成本，可能已经高于重新开始。

---

十二、可以自己测一个指标：状态漂移率

这篇我建议只看一个指标：

State Drift Rate——状态漂移率

统计最近一段时间的长任务。

看看有多少任务在执行过程中发生过：

关键代码变化。

接口变化。

依赖变化。

分支更新。

并行任务影响。

最后需要重新同步或返工。

例如最近20个Codex长任务：

有6个因为中途项目发生关键变化，最后需要重新调整。

那么：

状态漂移率 = 30%。

---

低于10%

说明任务隔离和项目管理比较稳定。

长任务通常能在相对固定的基线上完成。

---

10%—25%

说明已经开始出现明显状态变化。

建议加强：

任务隔离。

同步点。

基线记录。

模块边界。

---

高于25%

如果大量任务都出现：

开始时是一个项目。

结束时已经是另一个项目。

那真正的瓶颈就不是Agent代码能力。

而是：

项目状态管理。

这时候继续扩大并发，往往只会制造更多返工。

---

十三、Plus和Pro怎么判断？

如果你的状态漂移率还很高：

很多长任务都需要重新同步。

多个Agent频繁撞模块。

任务结束时经常发现基线已变化。

那当前真正应该优化的是：

任务隔离。

分支策略。

同步机制。

Agent边界。

这种阶段，Plus通常已经足够你把Workflow先稳定下来。

因为即使增加更多AI容量，也很可能只是让更多Agent同时基于过期状态工作。

---

如果你的状态漂移率已经很低：

任务隔离成熟。

不同Agent基本不会互相干扰。

长任务有清晰基线。

同步流程稳定。

但你开始长期遇到：

多个长任务等待执行。

大项目上下文很多。

高频Agent调用成为日常。

AI容量真正限制了任务吞吐。

这时候Pro的价值才会更明显。

因为增加容量以后，不是在放大混乱。

而是在放大一个已经稳定的Workflow。

---

十四、真正需要管理的，不只是代码上下文，而是“工作世界”

以后Agent越来越能独立执行以后，一个很重要的概念可能会变成：

World State。

Agent不是只需要知道代码。

它还需要知道：

现在项目到底处于什么状态。

哪些假设还成立。

哪些接口刚刚变化。

哪些依赖已经更新。

哪些文件正在被其他任务修改。

这决定了它的推理基础是不是仍然可靠。

所以未来Agent开发真正难的地方，可能不会只是：

“上下文够不够长？”

而是：

上下文是不是还新鲜。

---

最后

用ChatGPT、Codex做真实项目时，有一种错误特别值得警惕：

不是代码写错。

不是测试写错。

而是：

Agent在一个已经过期的项目世界里，持续做着逻辑正确的事情。

这种问题最麻烦，因为它看起来往往很合理。

每一步都有依据。

每一处修改都能解释。

但整个方案已经不属于最新项目。

所以以后处理长任务、多Agent并行任务时，除了问：

“Agent现在做到哪了？”

还应该多问一句：

它现在基于的，还是不是最新的项目状态？

这可能会成为Agent真正进入复杂工程以后，一个越来越重要的基本检查。

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