先做对前两步：四阶段编码 Agent 工作流，以及它在 Codex CLI 里的落法

Wed, 23 Sep 2026 07:50:00 +0800

你一定见过这个场景。规划阶段里，某个人对架构做了一条看起来无关紧要的假设。实现阶段，Agent 忠实地沿着这条假设往前走了几个小时。你在中途或者最后发现了问题，让它改。它给你回来一个补丁，叠在原来的结构上。

结果是代码里同时躺着原来的错误和后来的修正，逻辑重复，归属模糊。你评估这个 diff 花费的时间，比重新写一遍还长。

大多数人对这个场景的归因是：模型不够强，换一个就好了。Infobip 的 AI 研究团队在 CIKM ‘26 上发表的论文（arXiv:2608.30701）直接挑战了这个假设。他们的原话是：非平凡任务上的效果，取决于实践者如何配置 Agent 的运行环境与协作方式，而不是取决于基础模型的选择。

这句话值得停下来读两遍。我们花了两年时间在模型排行榜上追逐几个百分点的差距，而论文说真正的变量在别处。

一、上游错误会复利，下游补丁只会堆积

论文里有一个关于错误传播的判断，和绝大多数团队的实际做法相反。

研究阶段与规划阶段的错误，会跨阶段复利。而实现阶段生成的代码出了问题，你打的补丁带来的是臃肿和脆弱，不是干净的修复。

这两件事的性质不同。研究阶段的一个错误事实，会变成规划阶段的一个错误前提，再变成任务定义里的一段错误验收标准，最后变成整个模块的错误结构。四个阶段跑完，错误已经被固化进了骨架。

而实现阶段的错误，至少在结构层面是局部的，你能看见它在哪里。

所以论文给出的答案不是「更仔细地 review 实现」，而是把人力投入到研究与规划上，投入到一个足以让实现环节几乎不需要人工介入的强度。

这就是所谓的前置加载（front-load）。真正被前置的不是工作量，是判断力。

二、四个阶段，以及每一步的 Codex CLI 对应物

论文描述的流程分四步，人力参与程度逐级下降，产物则逐级固化。

阶段一：研究，只读，必须有验证门

实践者和 Agent 一起探索问题空间，但访问权限被限制在只读操作上：检索代码库、拉取文档、调用领域工具。不写文件，不改环境。

关键约束在最后一条：所有发现都要经过实践者验证，才能进入下一步。产物是一份经过整理的调研文档，不是一段对话记录。

在 Codex CLI 里，这一步靠沙箱和审批策略来强制。你可以用 --approval-policy on-failure 起一个研究会话，更稳的做法是给它一个专门的 profile，把可写根目录设为空：

# ~/.codex/config.toml
[profiles.research]
model = "gpt-5.6-sol"

[profiles.research.sandbox]
writable_roots = [] # 不允许任何文件系统写入
network = true # 允许检索文档

会话结束时把调研结论导出成文件。文件取代对话，成为持久的产物。对话本身是可以丢掉的。

阶段二：规划，迭代讨论，手工归档

拿调研文档作为输入，实践者和 Agent 通过多轮讨论确定方案。

这里论文有一个明确的反对意见，反而和很多人的直觉相悖：这个阶段不要使用专门的「规划模式」，它会导致过早定稿，方案还没被真正理解就被锁死了。

在 Codex CLI 上对应的是：让模型保持在默认模式，把调研文档作为上下文带进来，一轮一轮讨论设计，然后由人手工把结论整理成规划产物。论文特别提醒，不要让模型替你总结规划会话，它会把你推理过程中的分支和权衡全部压平。

也就是说，规划产物里应该包含架构决策记录，包括「为什么否决了另外两个方案」，而不只是「最终定了什么」。

阶段三：任务定义，机器可读，按会话大小切分

任务被定义为机器可读的单元，每张任务卡包含六个字段：稳定标识符、目标陈述、依赖关系、相关代码路径、验收标准、验证方法。