先做对前两步：四阶段编码 Agent 工作流，以及它在 Codex CLI 里的落法
你一定见过这个场景。规划阶段里，某个人对架构做了一条看起来无关紧要的假设。实现阶段，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 上对应的是：让模型保持在默认模式，把调研文档作为上下文带进来，一轮一轮讨论设计，然后由人手工把结论整理成规划产物。论文特别提醒，不要让模型替你总结规划会话，它会把你推理过程中的分支和权衡全部压平。
也就是说，规划产物里应该包含架构决策记录，包括「为什么否决了另外两个方案」，而不只是「最终定了什么」。
阶段三：任务定义，机器可读，按会话大小切分#
任务被定义为机器可读的单元，每张任务卡包含六个字段：稳定标识符、目标陈述、依赖关系、相关代码路径、验收标准、验证方法。
最容易被忽略的是切分约束：每个任务必须能在一个全新的会话里完成。如果定义一个任务所需的前后文超过了 Agent 的有效工作区间，就把它再切开。
这个约束不是洁癖，它同时买到了两件事：实现环节可以并行，以及每个任务的结果可以被独立审计。
任务卡通常放在 AGENTS.md 或者它引用的同伴文件里：
## Task Registry
### TASK-004: 把鉴权中间件迁移到 OAuth2
**Status:** pending
**Depends on:** TASK-001, TASK-003
**Paths:** src/middleware/auth.ts, src/routes/login.ts
**Criteria:** 现有 session 测试全部通过；新的 OAuth2 流程通过 e2e/auth.spec.ts
**Validation:** `npm test -- --grep auth`
这张登记表跨会话存在，成为事实上的唯一真相来源。
阶段四：实现，每个任务一个新会话#
每张任务卡在一个全新的会话里执行，只给它项目级指令和这张任务卡，不带前面阶段的长篇历史。
工作流维持三个持久产物：
| 产物 | 存什么 |
|---|---|
| 任务登记表 | 状态、依赖、验收标准、执行结果 |
| 只追加的活动日志 | 做了哪些动作、跑了哪些验证、遇到哪些失败 |
| Git | 代码状态 |
对话状态被明确视为可丢弃、可从上面三者重建的东西。这是整套方法里最反直觉的一点：绝大多数团队把会话历史当主要记录，这套流程把它当成缓存。
# 为单个任务起一个干净的实现会话
codex exec --input-file task-004.md "执行 TASK-004，按验证方法自证完成"
# 或者用队列做发射后不管的分发
codex queue --session "TASK-004" --text-file task-004.md
任务结束后，Agent 通过 PostToolUse hook 或一条约定格式的提交信息往活动日志里追加记录。记录因此独立于会话记忆。
三、上下文管理：四个动作，四种失效#
论文把上下文管理，而不是模型能力，摆在整个工作流的核心位置。它引用了 LangChain 的 Martin 在 2025 年提出的四象限分类，并按阶段调配这四种策略的比例。
| 策略 | 含义 | Codex CLI 里的机制 |
|---|---|---|
| Write | 把信息持久化到窗口之外 | 导出调研文档、AGENTS.md、任务登记表、活动日志 |
| Select | 只把相关上下文拉进窗口 | 每个任务一份 --input-file，精确的 @path 引用 |
| Compress | 只保留必要的 token | 会话压缩配置，实现开始前先做一次压缩 |
| Isolate | 把上下文拆到多个会话或 Agent | 每个任务一个新会话，并行任务用 agents 视图管理 |
配比是随阶段变化的。研究阶段重 Write（整理发现）和 Select（定向检索文档）；实现阶段重 Isolate（全新会话）和 Select（只注入任务定义，别的什么都不给）。
与之对应，论文按阶段而非按事后补救来处理四类上下文失效：
| 失效模式 | 机制 | 工作流里的缓解方式 |
|---|---|---|
| Distraction 分心 | 过度依赖累积的历史模式 | 每任务新会话，实现阶段只带任务定义 |
| Confusion 混淆 | 无关内容争夺注意力 | 上下文按阶段隔离，调研文档取代完整记录 |
| Poisoning 污染 | 幻觉在后续轮次里持续复现 | 研究与规划之间设人工验证门 |
| Clash 冲突 | 长会话里累积互相矛盾的信息 | 规划产物取代规划对话，半成品方案不进上下文 |
四种里最需要强调的是污染。研究与规划之间的那道验证门，专门用来在幻觉事实变成架构决策依据之前拦住它。一旦一个错误假设进了规划文档，它就很难被干净地摘出去，因为实现会建立在它上面。
四、一个反直觉的发现：AGENTS.md 里指令越多，遵守越差#
论文里有一条关于项目级指令文件的实现注记，值得单独说。指令跟随的准确率随指令条数增加而下降。加更多规则不会带来更好的遵守，只会带来选择性遵守和优先级冲突。
他们建议的做法是：当 Agent 重复犯某个具体错误时，加一条针对性的一行纠正；而不是去扩充一份通用规则集。指令应当尽可能少、尽可能具体。
对比一下：推荐写法是一行 模块文件统一用 snake_case，要避免的是那种模型会选择性忽略的详尽风格指南。
这个结论对那些把 AGENTS.md 当政策文件来写的实践者来说相当刺。但它的操作性建议其实很温和：把 AGENTS.md 当作一组行为纠正的集合，每一条都由一次观察到的失败驱动，并且定期清理已经过期的条目。
五、论文自己承认的两个未解问题#
这套流程不是终点，作者明确指出了两个当下没有任何工具（包括 Codex CLI）能很好解决的问题。
第一，缺少工作流指标。没有任何公认的度量能说明一套四阶段流程是否被应用得好。候选指标比如单会话任务成功率、指令纠正频率、任务完成时的上下文占用率，在文献里都还没有被探索过。团队没有有依据的方式去比较自己的流程配置与替代方案。
第二，组件与模式之间存在断层。研究形式化了单个上下文管理组件（Write、Select、Compress、Isolate），但没有形式化实践者真正需要的工作流级模式。团队缺少共同词汇来描述这些组件如何跨阶段组合。
落到 Codex CLI 上：agents 视图提供了会话可见性，活动日志模式提供了审计线索，但两者都不产出工作流级指标。一个记录每任务 token 消耗、验证结果和会话时长的 PostToolUse hook，是补上这个缺口的起点。
六、我的判断：这套流程值不值得抄#
先说结论：值得抄的是结构，不必抄的是仪式感。
它真正解决的问题是 review 成本的左移。 传统做法把质量成本的绝大部分放在最后的 diff review 上，而越靠后的修复越贵。四阶段流程把成本搬到研究和规划，代价是前期需要人多投入四到六小时。这个交换在任务规模超过一天工作量时几乎总是划算的，在半小时的小改动上则明显亏本。所以它不是普适规范，它是一条规模门槛之上的做法。
「规划阶段不要用规划模式」这条我保留意见，但理解它的来源。 论文的担忧是过早定稿。但真正的问题不在模式本身，而在于你把模式输出当成了最终结论还是当成了讨论素材。如果你把 plan 模式的产物当作讨论的第一稿，它的价值是正的；如果你把它当作可以直接执行的东西，那论文的批评完全成立。工具是中性的，用法决定了它是不是陷阱。
任务切分那一条，是整套流程里最有杠杆的部分。 「能在一个全新会话里完成」这个约束，同时约束了任务粒度、依赖清晰度和验收标准的可写性。它有一个副作用很值钱：当一张任务卡写不出来的时候，你立刻知道自己对问题的理解还不够，而不是等到实现跑偏了才发现。
AGENTS.md 那条发现，和社区的主流习惯是冲突的。 现在的风气是往 AGENTS.md 里堆一切，堆成一份几百行的规范。论文的观测是：这会让模型选择性遵守，并且制造优先级冲突。我的补充是，这个现象有一个更朴素的原因，长的规则集里必然有冗余和潜在矛盾，而人自己也不会逐条核对。所以与其讨论「加多少条」，不如换一个维护方式：每一条规则都必须能追溯到一次真实失败，追溯不到的条目就删掉。
两个未解问题里，我更在意第二个。 指标缺失是工程问题，迟早会有人做出来一个 hook 搞定。但组件与模式的词汇断层是认知问题：团队在讨论 Agent 工作流时，往往连「我们现在在讨论哪个阶段」都没对齐，就开始争「要不要上多 Agent」。前者是后者的前提。
七、从哪里开始#
如果你只打算做一件事，那就是在研究与规划之间立一道验证门，并且要求研究阶段的产物落成文档。
这一条的成本很低，收益却覆盖了论文里最贵的那个失效模式。剩下的三个阶段，可以等你的任务规模真的涨上来之后再补。
参考来源：
- Kapetanovic, A., Duricic, T., Mercep, A., & Lacic, E. (2026). A Phased Workflow for Operating LLM-Based Coding Agents. arXiv:2608.30701，将收录于 CIKM ‘26 论文集。https://arxiv.org/abs/2608.30701
- Daniel Vaughan, Front-Load or Fail: The Four-Phase Coding Agent Workflow and Its Codex CLI Implementation（2026-09-06，2026-09-22 更新）。https://codex.danielvaughan.com/2026/09/06/front-load-human-review-phased-coding-agent-workflow-codex-cli
- Martin, L. (2025). Context engineering for agents. LangChain Blog。https://www.langchain.com/blog/context-engineering-for-agents
- Breunig, D. (2025). How Contexts Fail and How to Fix Them。https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html