Codex 怎么突然变慢了？一个需求跑几十分钟，我才发现它的工作方式已经变了

最近这两天用 Codex 写项目，我有一个非常明显的感觉：怎么突然变慢了？

以前用 Codex，尤其是处理一些比较明确的开发任务时，基本就是把需求丢进去，它读取一下项目代码，分析几步，很快就开始改文件。简单需求几分钟就能结束，就算稍微复杂一点，也不会让我感觉等得特别久。

但最近一次需求让我有点懵。

我只是让 Codex 优化项目里一个图片引用方式，本来以为属于比较常规的代码调整。结果任务跑起来以后，右边一下出现了一大堆东西：

text 复制代码

Review fallback core spec
Fallback classifier
Review fallback task1 quality
Review action quality
Review virtual backend spec
Virtual material docs
Virtual material frontend
Jieyun action layer
Review action spec
...

有些任务几分钟，有些几十分钟，甚至还有任务跑了几个小时。

最关键的是，左边其实已经显示：

text 复制代码

1 个文件已更改 +93 -0

也就是说，代码实际上早就改了，但 Codex 依然没有结束，还在不停 Review、检查、验证。

我的第一反应就是：

我明明只选择了"计划模式"，什么时候变成智能体模式了？

仔细研究了一下，再结合最近使用 Codex 的体验，我发现问题可能不是简单的"模型变慢了"，而是 Codex 现在处理开发任务的方式，和以前已经不太一样了。

一、以前的 Codex，更像一个坐在旁边的程序员

以前我对 Codex 的使用习惯其实很简单。

比如项目里有一个接口需要修改，我会直接告诉它：

text 复制代码

修改 UserController 的分页接口，
新增 status 参数，
同时调整对应 Service 查询条件。

以前整个流程给我的感觉大概是：

text 复制代码

读取相关代码
↓
理解需求
↓
找到对应文件
↓
修改代码
↓
告诉我修改结果

这种方式其实特别适合日常开发。

因为程序员平时真正遇到的需求，大部分根本没有复杂到需要重新分析整个系统。

比如：

修改一个 SQL；
增加一个字段；
调整一个接口；
修复一个空指针；
修改 Vue 页面；
增加一个按钮；
调整一个配置；
修改 Docker 部署脚本。

这些任务本身范围非常明确。

我需要的不是 AI 给项目做一次"技术审计"，而是：

找到地方，改掉，测试一下，结束。

以前 Codex 在这方面给我的体验确实非常好。

但现在明显不一样了。

二、现在的 Codex，越来越像一个真正的 Agent

这次让我感受最明显的，就是右侧突然出现大量任务。

如果只是普通代码助手，其实完全没有必要出现这么多步骤。

但如果从 Agent 的角度来看，一切就合理了。

现在它可能会把一个需求理解成：

text 复制代码

接收用户需求
↓
分析需求边界
↓
扫描项目
↓
寻找相关代码
↓
判断影响范围
↓
拆分任务
↓
设计修改方案
↓
执行代码修改
↓
检查修改结果
↓
Review
↓
验证是否影响其他模块
↓
再次 Review
↓
输出最终结果

这和以前已经不是同一种工作方式了。

以前更像是：

"帮我改一下这段代码。"

现在更像：

"这个需求交给你负责，你自己把整个事情做完。"

听起来后者明显更高级，但问题也随之出现了：

很多小需求根本用不上这么重的流程。

这就像我只是让一个程序员改个字段，结果他先拉上产品、测试、架构师开了一场需求评审会，然后出技术方案，再做 Code Review，最后跑一轮回归测试。

流程当然更加完整。

但我只是想改个字段啊。

三、为什么代码已经改完了，Codex 还在跑？

这也是我这次最困惑的地方。

左边已经明确显示：

text 复制代码

1 个文件已更改
+93
-0

正常来说，到这里任务应该差不多结束了。

但是右边仍然有很多：

text 复制代码

处理中
Review action quality
Review virtual backend spec
Review virtual material frontend
...

后来想明白以后，其实很好理解。

"代码修改完成"和"Agent 任务完成"，现在可能已经变成两件事情。

以前 Codex 的目标可能是：

完成代码修改。

现在 Agent 的目标更接近：

完整解决用户提出的问题，并验证解决方案可靠。

所以文件修改只是整个任务链中的其中一步。

假设它认为一个需求需要经历：

text 复制代码

需求理解
→ 方案设计
→ 修改代码
→ 检查代码
→ 测试
→ Review
→ 风险检查
→ 最终总结

那么即使第三步"修改代码"已经完成，后面的步骤还是会继续执行。

于是用户看到的现象就是：

代码明明已经写好了，Codex 怎么还在那里转？

实际上不是它卡死了，而是它认为任务还没有真正结束。

四、我明明选择的是"计划模式"，为什么还是像智能体？

这是这次最容易让我误解的地方。

我的理解原本是：

text 复制代码

计划模式 = 只给方案

智能体模式 = 自己执行

但从现在的使用体验来看，已经不能完全这么理解了。

现在的 Plan Mode 更像是：

优先规划任务，然后按照计划推进。

而不是：

禁止 Agent 行为，只允许输出文字方案。

这两个概念区别其实非常大。

也就是说，计划模式控制的可能更多是 Codex 如何开始处理这个任务，而不是决定它是不是一个 Agent。

现在 Codex 本身的底层工作方式就越来越 Agent 化。

所以即使选择 Plan，它仍然可能：

读取大量代码；
分析仓库；
建立任务；
调用工具；
做验证；
做 Review；
根据结果继续处理。

这也解释了为什么我明明没有主动选择所谓的"智能体模式"，最后看到的却是一套非常典型的 Agent 工作流。

五、为什么以前几分钟，现在可能几十分钟？

这里面其实有几个因素叠加。

第一个就是前面说的：任务步骤变多了。

以前：

text 复制代码

分析 → 修改

现在：

text 复制代码

分析 → 规划 → 搜索 → 修改 → 验证 → Review → 再验证

模型单次生成速度可能没有慢多少，但工具调用次数增加以后，整个任务自然会被拉长。

第二个问题是 项目上下文越来越大。

尤其是我们程序员很容易犯一个习惯：一个对话窗口一直用。

今天让 Codex 修登录，明天让它改支付，后天继续调整图片，然后再改数据库。

慢慢一个 Session 里面就积累了：

大量历史对话；
已读取文件；
修改记录；
命令执行结果；
测试日志；
Git Diff；
之前的任务上下文。

虽然长上下文对大型任务非常有帮助，但对于一个只有几十行代码的小需求来说，这些东西反而可能成为负担。

所以我现在越来越倾向于：

一个相对独立的需求完成以后，就新开一个 Session。

没必要把整个项目开发生命周期全部塞进同一个对话。

六、Agent 越强，不代表所有任务都应该用 Agent

这一点是我这次最大的感受。

现在大家都在追求 Agent。

AI 自动写代码、自动测试、自动提交、自动 Review，甚至未来可能一个需求直接扔进去，半小时以后整个功能都开发好了。

这个方向肯定没有问题。

但真实开发中其实存在一个很现实的问题：

任务复杂度是不一样的。

比如下面这种需求：

text 复制代码

把 User 表增加 avatar 字段，
对应 Entity、DTO、Mapper 一起调整。

如果模型能够快速定位 4 个文件，然后直接修改，可能两分钟结束。

但如果 Agent 先分析数据库设计，再扫描所有用户模块，再研究字段兼容性，然后生成 Spec、Review、测试......

最后花了 20 分钟。

从工程质量来看，它可能更加严谨。

但从开发效率来看，未必更高。

所以真正好用的 AI 编程方式，不应该是：

所有事情全部交给 Agent。

而应该是：

根据任务复杂度决定 Agent 参与程度。

七、我现在使用 Codex 的方式也开始调整了

经过这几次体验，我现在会主动控制任务范围。

以前我可能直接写：

text 复制代码

优化体验中心图片引用方式。

这句话对人来说可能很好理解。

但对于 Agent 来说，"优化"这个词范围太大了。

它可能会思考：

什么叫优化？

是不是要重新设计？

前端要不要调整？

后端有没有影响？

原来的图片数据怎么办？

历史数据兼不兼容？

是否需要 fallback？

异常情况怎么处理？

于是一个原本很简单的需求，被扩展成一个系统级任务。

现在我更愿意这样写：

text 复制代码

修改 xxx 模块的图片引用逻辑。

只检查与该功能直接相关的代码，
不要重构其他模块，
不要扩大修改范围。

优先直接完成代码修改，
完成必要验证即可。

甚至对于特别简单的问题，我会直接告诉它：

text 复制代码

不要全局扫描项目，
只修改当前功能涉及的文件。

实际体验确实会好很多。

八、小需求、大需求、重构任务，最好分开处理

我现在大概会把 Codex 任务分成三类。

第一类是日常小需求。

比如修改 SQL、调整接口、增加字段、修复 Bug、调整 Vue 页面、修改配置。

这种任务我更关注：

快。

让模型理解必要上下文以后直接修改就行，不需要把整个项目重新研究一遍。

第二类是中型功能。

比如：

text 复制代码

增加订单退款模块
增加新的支付渠道
增加用户积分体系
增加后台权限功能

这种就适合让 Codex 多分析一点。

因为它确实涉及 Controller、Service、数据库、前端、权限等多个模块。

第三类是真正的大型任务。

比如：

text 复制代码

重构支付系统
迁移数据库
拆分微服务
升级 Spring Boot
重新设计图片存储架构

这种任务我反而非常愿意让 Agent 慢慢跑。

因为如果 AI 能花半小时帮我扫描几十个文件、找出潜在风险、完成修改、跑测试、最后再 Review 一遍，我觉得非常值。

所以关键不是：

Agent 到底好不好。

而是：

这个任务到底值不值得启动完整 Agent 工作流。

九、Codex 变慢，也可能意味着 AI 编程进入了另一个阶段

从另外一个角度看，这种变化其实挺有意思。

最早我们用 AI 编程，本质还是：

text 复制代码

程序员写代码
AI 帮忙补全

后来变成：

text 复制代码

程序员提问题
AI 生成代码

再后来是：

text 复制代码

程序员描述需求
AI 修改项目

而现在正在逐渐变成：

text 复制代码

程序员定义目标
AI 自己完成任务

最后这一层的变化非常关键。

因为当 AI 从"代码生成器"变成"执行任务的 Agent"以后，它必然需要增加很多以前没有的东西：

规划、工具调用、上下文管理、测试、验证、Review、失败重试......

这些能力会让 AI 编程越来越强，但同时也会带来新的问题：

延迟。

以前我们衡量 AI 编程工具，很简单：

代码生成快不快？

以后可能要换一个标准：

完成整个任务需要多久？

这两个指标其实完全不同。

一个模型 5 秒生成代码，但是你还需要自己改半小时。

另一个 Agent 可能运行 15 分钟，但是最后直接给你一个基本可用的结果。

到底哪个更快？

还真不一定。

十、最后：不是 Codex 单纯变慢了，而是它开始"干更多事情"了

所以回头看我最开始的问题：

为什么今天 Codex 这么慢？

现在我觉得答案不能简单归结为服务器慢、模型慢或者电脑性能不够。

至少从这次任务表现来看，更大的原因可能是：

Codex 正在从"代码助手"进一步转向"Agent 工程师"。

以前你让它改代码，它就改代码。

现在你让它解决一个问题，它可能真的会把自己当成这个需求的负责人：

分析需求、扫描项目、设计方案、修改代码、检查影响、Review、测试，最后才告诉你：

做完了。

能力确实更强了。

但代价就是，有时候我只是想让它帮忙"拧个螺丝"，它却先给整个项目做了一次全面检查。

所以我现在对 Codex 的使用思路也变得很明确：

小需求，限制范围，让它快速改；中型需求，让它适当分析；大型需求和重构，再真正发挥 Agent 的价值。

同时，尽量不要让一个 Session 无限变长。一个独立需求结束以后，新开一个会话，往往比一直拖着几万甚至几十万上下文继续开发更舒服。

AI 编程发展到现在，我觉得我们要学习的已经不只是"怎么写 Prompt"。

更重要的是：

什么时候应该让 AI 多思考，什么时候应该让它少废话、直接干活。

这可能才是 Agent 时代真正影响开发效率的地方。

以前我们需要学会管理程序员。

现在，可能还得学会管理 AI 程序员。