Codex越来越强以后一个很明显的变化是我们开始敢把更大的任务交给Agent。以前可能只是帮我写一个函数。后来变成帮我修复这个Bug。再往后是把认证模块重构一下补齐测试然后确保现有接口行为不变。甚至把整个项目从旧技术栈迁移到新技术栈持续工作直到所有测试通过。问题也随之发生变化。短任务失败时我们通常还能很快找到原因。但长任务最麻烦的情况不是直接失败。而是它一直在工作但正在慢慢偏离最初目标。你可能看到Codex第一小时还在解决核心问题第二小时开始处理边缘问题后面又顺手重构几个模块测试失败以后继续扩大修改范围最后产生了大量代码。看起来Agent非常努力。但回头检查时却发现最初真正需要解决的问题反而没有形成一个清晰、可验证的闭环。这就是Long-Horizon Agent真正困难的地方。OpenAI目前对Codex长任务的描述已经非常明确关键变化不只是模型“变聪明”而是Agent能够在更长时间内维持执行循环通过计划、修改代码、运行测试、观察结果、修复失败再继续下一轮。Codex的长任务能力依赖的也不是一个巨大的Prompt而是整个Agent Loop以及仓库、文件、日志、Diff、Worktree等外部状态。所以长任务不是“一个更大的Prompt”。它更接近一个持续运行的小型工程系统。如果还是按照“一句话交代需求然后等Agent自己做完”的方式使用任务越长失控概率通常越高。一、首先要理解长任务真正困难的是“状态”不是代码量假设有两个任务。Task A修改Login.tsx中的按钮文案。即使Codex产生一点偏差问题也很容易发现。因为整个任务可能只有读取文件 ↓ 修改一行 ↓ 检查Diff ↓ 完成状态非常少。但换成Task B重构认证系统保持现有API兼容迁移Token逻辑补齐测试并确保登录、注册、刷新Token都能正常运行。现在状态开始增加认证架构 当前API行为 兼容要求 Token逻辑 登录测试 注册测试 刷新测试 历史Bug 新实现 回滚策略而且每一次修改都会产生新的状态。例如阶段1修改Token生成 ↓ 阶段2测试登录 ↓ 发现Refresh Token异常 ↓ 修改Cookie ↓ 注册测试开始失败 ↓ 继续修改公共认证逻辑此时Agent真正需要维护的已经不是“我要写什么代码”而是“整个项目现在处于什么状态”这也是为什么OpenAI在长任务实践中把“外部化状态”列为Agent保持长期连贯的重要因素包括仓库文件、文档、Worktree、输出以及测试结果等。因此长任务的第一个原则应该是不要让任务状态只存在于模型脑子里。二、第一层控制一个长任务只能有一个Root Goal这是最容易被忽略的一点。例如有人给Codex重构登录模块同时升级React解决TypeScript错误优化页面性能再把测试覆盖率提高一些。看起来这是一个“大任务”。实际上里面至少包含Goal A登录重构 Goal B依赖升级 Goal C类型修复 Goal D性能优化 Goal E测试增强这不是一个Goal。这是一个Backlog。如果Agent连续执行几个小时它必须不断判断现在最优先处理哪个目标而不同目标甚至可能相互冲突。例如React升级导致类型变化类型变化影响登录重构登录重构又让原来的测试失效。最后因果关系越来越复杂。OpenAI目前对Codex/goal的建议也非常明确适合长任务的目标应该“比普通Prompt大但比开放式Backlog小”要明确Agent要实现什么、不应该修改什么、如何验证以及什么时候停止并明确不建议把一组互不相关的工作塞进同一个Goal。所以第一步应该先定义Root Goal例如完成认证模块重构在不改变现有API行为的前提下使登录、注册和Token刷新测试全部通过。这才是一个真正可执行的Goal。其他事情升级React 优化页面性能 整理UI暂时全部排除。不是永远不做。而是不属于当前Goal。三、第二层控制把Goal拆成Milestone而不是拆成几十个Todo确定Goal以后下一步很多人会犯另一个错误写一张巨大的Todo List。例如修改auth.ts 修改token.ts 修改cookie.ts 修改login.ts 修改register.ts 修改router.ts 修改tests 检查类型 运行lint 运行build ……问题是这只是操作列表。它没有告诉Agent完成到哪一步应该停下来检查一次真正适合Agent的任务拆分不是File-Based。而应该更加接近State-Based。例如认证系统重构可以拆成Milestone 1建立当前行为Baseline。完成标准记录现有登录测试 记录注册测试 记录Token刷新测试 记录API返回行为Milestone 2迁移Token逻辑。完成标准Token单元测试通过 旧API签名保持不变Milestone 3迁移登录流程。完成标准登录测试通过 错误码行为不变Milestone 4迁移注册与刷新Token。完成标准相关测试全部通过Milestone 5最终验证。完成标准完整测试 Lint Build 最终Diff现在Agent执行的不再是把一大堆文件改完。而是把系统从State A推进到State B。这才是Milestone真正的意义。OpenAI公开的长时任务实践也采用类似方式先冻结项目目标、约束、交付物以及“Done when”然后让Codex生成基于Milestone的计划并在每一个阶段运行测试、Lint和类型检查。四、第三层控制每个Checkpoint必须有EvidenceMilestone解决的是任务怎么分。但还缺一个关键问题怎么知道这个阶段真的结束了很多Agent任务的问题就在这里。Codex可能说Milestone 2完成。但“完成”可能只是代码已经修改而真正应该要求的是代码修改 测试通过 Diff合理 没有新增失败这就是Checkpoint。可以把Checkpoint理解成每个阶段之间的“门”。只有满足条件才能进入下一个阶段。例如Milestone 2 迁移Token逻辑它的Checkpoint可以写成[ ] Token相关单元测试通过 [ ] API输出保持兼容 [ ] 没有修改数据库Schema [ ] Build成功 [ ] Diff仅涉及预期模块只要有一项失败不要进入Milestone 3。先解决当前阶段。这会带来一个非常大的好处错误不会一直向后传播。否则很容易出现阶段1留下问题 ↓ 阶段2建立在错误状态上 ↓ 阶段3继续产生新修改 ↓ 阶段4测试全面爆炸到了最后你根本不知道最早从哪里开始出错。OpenAI针对长任务的Goal机制同样强调“verifiable stopping condition”和validation loop并建议定义能够证明进度的命令或产物让Codex按照Checkpoint工作并保持简短的进度记录。所以长任务真正可靠的结构应该是Plan ↓ Milestone ↓ Checkpoint ↓ Evidence ↓ Next Milestone而不是Plan ↓ 不停修改 ↓ 最后一次性测试五、第四层控制把Progress写进文件不要全部留在对话里上一篇我们讨论了Context Pollution。长任务里还有一个更进一步的问题即使Context没有明显污染执行状态本身也应该外部化。例如建立PLAN.md STATUS.md DECISIONS.md它们并不是为了写漂亮文档。而是承担不同状态。PLAN.md保存相对稳定的计划Goal Milestone 1 Milestone 2 Milestone 3 Constraints Done When它回答我们准备怎么完成任务STATUS.md保存当前执行状态Current Milestone2 Completed - Baseline完成 - Token生成逻辑迁移 Current Issue Refresh Token测试失败 Next 检查Cookie设置它回答现在做到哪里了DECISIONS.md保存已经确定的重要决策Decision 01 继续保持原API返回结构。 Reason 避免影响现有客户端。 Decision 02 不升级JWT依赖。 Reason 当前问题与依赖版本无关。它回答为什么之前这样决定这三个文件解决的是一个非常现实的问题如果Agent运行几个小时以后进行了Context Compaction或者中间发生大量对话它仍然可以重新读取这些文件快速恢复到Current Project State。OpenAI在长任务案例中明确把这种“durable project memory”作为最重要的技术之一把spec、plan、constraints和status写入Markdown文件让Codex可以反复读取以减少漂移并保持稳定的Done定义。所以长任务里文档不是任务结束后的记录。它可以直接成为Agent运行时的外部记忆。六、第五层控制并行任务必须隔离不要多个Agent抢同一个Workspace当Codex能够运行多个Agent以后一个非常自然的想法是那我干脆同时开三个Agent。例如Agent A重构认证 Agent B补测试 Agent C修TypeScript理论上效率提高3倍。实际如果三个Agent直接修改同一个Workspace很容易产生A修改auth.ts ↓ B基于旧auth.ts写测试 ↓ C又修改auth.ts类型 ↓ 三个任务开始互相覆盖这种问题不是模型能力问题。而是共享可变状态冲突。Codex App目前采用独立Thread和Git Worktree支持并行任务。OpenAI官方文档说明Worktree可以让多个独立Codex聊天在同一个项目中并行工作而不互相干扰每个Worktree拥有独立的仓库文件副本同时共享Git元数据。所以更稳定的并行结构应该是Repo ├── Worktree A │ └── Auth Refactor │ ├── Worktree B │ └── Test Expansion │ └── Worktree C └── Type Fix而不是一个Workspace ↓ 三个Agent一起改这里其实出现了一个很重要的Agent工程原则Context Isolation解决认知冲突。Worktree Isolation解决代码状态冲突。这两种隔离缺一不可。OpenAI目前的Codex App本身也把Agent放在项目下的独立线程中运行并内置Worktree支持让多个Agent能够在同一个仓库里工作而不直接影响彼此的代码状态。七、第六层控制任务方向变化时不要硬着头皮继续原计划长任务还有一个很常见的问题计划已经失效但Agent仍然沿着原计划继续执行。例如最开始认为登录Bug来自Token刷新。于是Plan是Milestone 1 重构Token Milestone 2 修改Refresh Milestone 3 更新Login执行Milestone 1以后却发现真正Root Cause是Cookie SameSite配置错误这时候最差的处理方式就是既然Plan已经写了那还是继续执行吧。正确做法应该是Re-plan。明确记录Original Hypothesis Token刷新错误 Status 已排除 New Root Cause Cookie SameSite Plan 停止Token重构 重新生成后续Milestone这叫Course Correction。长任务真正的优势不是永远按照最初计划执行。而是发现现实和计划不一致以后能够保持已有有效成果同时调整后续方向。OpenAI对当前Codex长时任务能力的描述也特别强调它能够在多步骤执行中接受中途纠偏而不必因为方向调整就完全重置整个运行。因此Plan不是合同。它只是当前最合理的路线。真正不能变化的是Goal和Verification Criteria。只要Goal没有改变Plan完全可以变化。八、什么时候应该用Goal什么时候只需要普通Task并不是所有任务都需要搞成Long-Horizon Workflow。一个简单判断方法是普通Task例如修复这个TypeScript类型错误。可能5—20分钟 一个模块 一个明确错误 一次验证没有必要建立复杂计划。Medium Task例如重构订单状态逻辑并补测试。可能需要2—4个Milestone 多个文件 阶段验证这时候可以使用PLAN CheckpointLong-Horizon Task例如技术栈迁移大型代码重构多模块系统改造长时间实验与优化此时才真正需要Root Goal Milestone Checkpoint External State Worktree EvidenceOpenAI目前对/goal的定位也是用于拥有明确成功条件和验证循环的长时间编码任务例如大型重构、迁移、实验和持续迭代而不是一组松散、无关的小需求。所以Agent工程并不是所有任务都复杂化。而是任务越长治理结构越完整。九、一个真正适合Codex长任务的模板假设现在要执行重构认证系统。不要只写帮我把认证模块重构好。可以改成【Root Goal】 重构认证模块 保持现有API兼容 最终所有认证相关测试通过。 【Non-Goals】 不升级框架版本。 不修改数据库Schema。 不重构无关业务模块。 【Milestone 1】 建立Baseline。 验证 - 登录测试 - 注册测试 - Refresh Token测试 - Build 【Milestone 2】 迁移Token模块。 Checkpoint - Token单元测试通过 - API行为不变 - Diff仅涉及认证模块 【Milestone 3】 迁移登录和注册流程。 Checkpoint - 登录测试通过 - 注册测试通过 【Milestone 4】 完整验证。 Checkpoint - 全部认证测试通过 - Build通过 - Lint无新增问题 【Execution Rules】 每完成一个Milestone 1. 更新STATUS 2. 总结修改 3. 保存验证结果 4. 再进入下一阶段。 如果发现原计划错误 停止继续扩张修改范围 更新Root Cause 重新规划剩余Milestone。 【Done When】 所有目标行为验证通过 最终Diff完成Review 不存在未说明的失败项。这段Prompt真正重要的不是它比较长。而是它给Agent建立了Goal ↓ Boundary ↓ Milestone ↓ Checkpoint ↓ Evidence ↓ Done这已经不是普通Prompt Engineering。它更接近Agent Execution Protocol。十、为什么“任务拆分”最终解决的不是效率而是可恢复性很多人认为拆任务主要是为了让Codex一次少做一点。这只说对了一部分。真正更重要的是Recovery。假设一个任务运行6小时。如果它是一个连续的大流程Start ↓ …………………… ↓ Failure最后失败时你可能不知道从哪里重新开始但如果任务是Milestone 1 ✓ ↓ Milestone 2 ✓ ↓ Milestone 3 ✓ ↓ Milestone 4 ✕问题就非常简单从Milestone 4恢复。前面三个阶段不需要重新证明。所以好的任务拆分带来的最大价值其实是Failure Localization。能够明确知道错误发生在哪个阶段。进一步还会带来Resume Capability。能够从最近一个可信Checkpoint继续。这和数据库事务、分布式任务以及CI Pipeline的设计思想非常接近。真正可靠的系统从来不会假设整个长流程永远不会失败。而是提前设计失败以后怎么恢复。Agent也一样。十一、Codex长任务最终需要的是一个“闭环系统”把前面6层放在一起就可以得到一个完整结构Root Goal ↓ Milestone ↓ Checkpoint ↓ External State ↓ Isolated Execution ↓ Verification ↓ Evidence ↓ Next Milestone如果失败Failure ↓ Identify Checkpoint ↓ Update State ↓ Re-plan ↓ Resume这时候Agent就不再是接受一个Prompt以后一直生成下去。而是在运行一个有目标、有状态、有检查点、有恢复能力的工程循环。这其实也是OpenAI目前对Codex长时工作的核心描述Agent通过计划、实现、运行工具、观察结果、修复错误并继续迭代的闭环工作而不是依赖一次性生成项目状态、验证反馈和可中途调整的执行循环共同维持长任务的连贯性。从Context Engineering再往前一步是Task Engineering上一篇我们讨论Context Engineering。解决的是Agent应该持续知道什么这一篇进一步解决的是Task Engineering。它关注Agent应该怎样持续完成一个复杂目标两者结合以后Codex长任务的基本框架开始变得清楚Environment ↓ Permission ↓ Context ↓ Goal ↓ Milestone ↓ Checkpoint ↓ Verification ↓ Evidence这也是为什么Agent越来越强以后开发者真正需要学习的东西反而越来越不像怎么写一个漂亮Prompt。而更像怎么设计一个可执行系统。因为模型能够连续工作几分钟以后Prompt非常重要。模型能够连续工作几小时甚至更长以后真正决定结果的开始变成任务有没有边界目标有没有冻结状态有没有外部化阶段有没有Checkpoint并行任务有没有隔离每一步有没有验证失败以后能不能恢复。这些东西共同决定Agent到底是在“长时间工作”还是在“长时间地逐渐跑偏”。最后Codex长任务容易跑偏真正的问题通常不是Agent不能连续工作。而是我们仍然用短任务的方法管理长任务。一句Prompt交代目标。然后期待Agent连续工作几个小时。中间不断追加要求。最后再一次性检查结果。这种方式在任务越来越长以后一定会变得脆弱。更稳定的方式应该是一个Root Goal 拆成多个Milestone 每个Milestone都有Checkpoint 每个Checkpoint都有Evidence 状态持续写入外部文件 并行任务通过Thread和Worktree隔离 发现方向错误立即Re-plan 最后按照明确Done条件结束当这套结构形成以后Codex真正发生的变化不是它一次能做更多事情。而是它能够在一个可控制、可验证、可恢复的系统里持续工作。从这个角度看未来AI编程真正重要的能力可能不是Prompt Engineering。甚至也不只是Context Engineering。而是Task Engineering。因为Agent越能长时间自主工作人类真正需要设计的就越不是下一句话。而是整个任务应该怎样运行。
