Codex长任务怎么拆成可恢复队列
把 Codex 长任务讲成可恢复队列：用目标文档、队列状态、检查点、证据路径和写回机制，让 Agent 能中断、恢复、验证和交接，而不是只依赖越来越长的聊天记录。
很多人第一次把 Codex 用在长任务上，都会自然地尝试一个很朴素的办法：把需求讲得更完整，把提示词写得更长，然后让 Agent 一直做下去。这个办法在小任务里有效，但一旦任务跨过几个小时、几十个文件、多个验证步骤，问题就会冒出来：上下文越来越长，目标开始漂移，工具输出挤占窗口，中途失败后不知道从哪里恢复，另一个同事或另一个 Agent 接手时只能重读聊天记录。
长任务真正需要的不是“让一次对话更长”，而是“让工作可以中断、恢复、验证和交接”。这就是可恢复队列的价值。它把一个大目标拆成一组状态清楚的小任务，每个小任务都有输入、产物、验收标准、证据路径和下一步。聊天记录仍然有用，但它不再是唯一记忆；真正的恢复入口变成队列文件、计划文件、证据文件和状态记录。
OpenAI 官方的 Codex 长任务案例里有一个非常重要的做法：把规格、计划、约束和状态写进可反复读取的 Markdown 文件，形成 durable project memory，也就是项目级的持久记忆。Codex best practices 也强调，Codex 更像一个需要被配置和持续改进的队友，而不是一次性助手；AGENTS.md、计划、验证、MCP、Skills 和 automations 都是为了让工作跨回合、跨工具、跨人员时仍然稳定。换句话说，长任务的核心不是更会哄模型的提示词，而是工程化状态管理。
本文讲的“可恢复队列”，不是某个具体产品的专有功能，而是一种适合 Codex、Claude Code、ChatGPT Agent 或团队自动化流水线的工作方法。它尤其适合内容工厂、代码迁移、批量修复、资料整理、测试补全、审计发布这类任务：目标大、步骤多、验证慢、容易中断，又需要持续推进。
长任务为什么容易失控
长任务失控，通常不是因为模型突然“变笨”，而是任务结构本身没有给 Agent 稳定的抓手。
第一类问题是目标漂移。一个任务刚开始时可能很清楚，比如“把 150 篇文章生产成完整包”。但执行到第 20 篇、第 60 篇时，如果目标只存在于早期聊天里，Agent 很容易被旧目标、临时插话、相邻任务或历史文件带偏。它可能把旧队列当成新队列，把审计任务当成生产任务，或者把 dry-run 当成正式发布。
第二类问题是上下文膨胀。OpenAI 对 Codex agent loop 的说明指出，Agent 会在模型推理和工具调用之间循环：模型提出工具调用，系统执行工具，工具输出再进入下一轮上下文。这个过程很强大，但也意味着一次长回合中会不断累积命令输出、文件内容和中间判断。上下文窗口不是无限的，信息一多，关键约束就可能被淹没。
第三类问题是验证延后。很多人把长任务拆成“先做完所有东西，最后统一检查”。这听起来省事，但对 Agent 来说非常危险。一个早期格式错误、路径错误或接口误用，如果到最后才发现，就会污染后面几十个产物。长任务应该把验证嵌入每个里程碑，而不是攒到结尾。
第四类问题是状态丢失。聊天记录里可能有“我已经做完了前三步”的描述，但如果没有文件证据，就很难判断到底做了什么、有没有成功、输出在哪里、是否可复用。另一个 Agent 接手时，最怕看到的是一长串自然语言总结，却找不到产物、命令、日志和验收结果。
第五类问题是并行冲突。长任务往往会被拆给多个线程或多名成员。如果没有队列所有权和文件边界，两条线可能同时改同一个 CSV、同时更新同一个目标文档，或者一个线程把另一个线程的半成品误判为失败产物。
所以，长任务不是简单地要求 Agent “坚持更久”。更可靠的做法是把任务拆成许多个能独立恢复的小状态单元。
可恢复队列到底是什么
可恢复队列可以理解成“给 Agent 用的任务看板”，但它比普通待办清单更严格。一个待办清单可能只写“写第 3 篇文章”“生成图片”“发布检查”；可恢复队列必须写清楚：这一步为什么存在、从哪里读输入、要产出哪些文件、如何验证、当前状态是什么、失败后怎么接着做。
一个最小队列项可以包含这些字段：
id：稳定编号，例如XY-PLUS-AI-003。title：人类可读标题。status：明确状态，而不是一句模糊备注。input：要读取的目标文档、数据文件、上下文接口或外部资料。constraints：不能违反的边界，例如不能正式发布、不能输出 token、不能使用占位图。deliverables：必须存在的产物路径。validation：最小可行验证命令或检查方式。evidence：日志、manifest、dry-run 输出、截图或来源记录。next_step：下一次恢复时第一件该做的事。blocked_reason：如果卡住，卡在哪里，重试条件是什么。
这样写的好处是，队列项本身就变成恢复入口。Agent 不需要从几万字聊天记录里推断“我现在做到哪了”，只要读队列状态、目标文档、包内 README 和证据路径，就能继续。
更重要的是，队列让“完成”的定义从主观感觉变成客观证据。比如一篇文章不是“我写完了”就算完成，而是必须满足：article.md 存在、article.html 存在、sources.md 存在、4 张真实 Image 模型图片存在、manifest 显示没有 fallback、dry-run 输出 ok=true、队列状态已更新、Personal OS 已写回。少一个证据，状态就不能进入下一档。
不要按时间拆，要按可验证里程碑拆
很多长任务拆不好，是因为按时间或自然段落拆：上午写稿、下午生图、晚上发布；或者第 1 至 10 篇、第 11 至 20 篇。这样的拆法方便排班，但不一定方便恢复。
更稳的拆法是按“可独立验证的里程碑”拆。一个里程碑应该满足三个条件：边界清楚、产物可见、失败可重试。
例如，批量生产文章时，不要把“完成 150 篇”当成一个巨大任务，也不要只写“今天多做几篇”。可以拆成每篇一个主队列项，每篇内部再拆成五个检查点：
1. 上下文与资料准备：Personal OS context 已读取，权威来源已记录。 2. 文章包草稿：Markdown、HTML、来源、图像提示词、元数据、复审占位文件齐全。 3. 图片生成：4 张真实 16:9 图已生成，manifest 无 fallback，接触图已检查。 4. 发布 dry-run：目标站点正确，dry-run 成功，未正式发布。 5. 写回与交接：CSV、目标文档、README、Personal OS 均更新，下一篇明确。
这样拆的关键是，每个检查点都有“停在这里也能恢复”的能力。如果图片生成失败，下一次不必重写文章，只需要读 image prompts、manifest 和失败原因，单图重试。如果 dry-run 失败，下一次不必重新生图，只要修正包元数据或发布脚本参数。长任务就从一条脆弱的长线，变成一串可以单独修复的节点。
给队列设计状态机
可恢复队列最忌讳状态含糊。比如“处理中”“差不多完成”“待确认”这类状态，对人还勉强能理解，对 Agent 来说很容易误判。状态应该少而稳定，而且每个状态都对应清楚的进入条件。
一套实用状态机可以这样设计：
queued：已进入队列，但尚未开始。in_progress：当前 Agent 正在处理，最好记录 owner 和开始时间。draft_ready：主要文本或代码产物已经形成，但未完成外部资源或验证。assets_ready：图片、截图、音频、构建产物等依赖资源已生成并验收。dry_run_passed：模拟发布、测试、构建或预检查已通过。needs_review：交付物已具备审查条件，但审查线尚未完成。done：所有验收条件完成，且已写回项目状态。blocked：当前无法继续，需要用户、外部服务或权限。failed_retryable：失败但可按记录重试。failed_final：当前路径不可用，需要重新设计方案。
这些状态不一定全都要写进 CSV，可以按项目需要合并。但必须避免把“待审”和“完成”混在一起。比如内容生产中，生产线程可以把状态推进到“初稿完成、生图完成、dry-run 通过、待 ChatGPT 校验、待 Claude 复审”，这代表生产线已交付给审计线；它不代表正式发布通过，也不代表外部复审通过。状态名长一点没关系，只要边界清楚。
状态机还应该支持失败恢复。长任务一定会遇到慢接口、偶发 500、单张图生成失败、网页资料临时不可用、dry-run 上传异常。如果失败状态只写“失败”，下一次还要重新猜。更好的写法是“failed_retryable: image_3_timeout, retry_single_image_with_same_prompt”，这样恢复动作就是明确的。
让文件成为记忆，而不是只靠聊天记录
Codex 的长任务经验反复指向一个结论：重要状态要落在文件里。聊天记录适合解释思路，文件适合承载可恢复事实。
官方 long horizon tasks 文章中提到的做法，是用规格、计划、实现记录、文档状态等文件保持项目记忆。这个思路可以扩展成一套通用文件栈：
Goal.md：目标、范围、非目标、口径修正。Queue.csv或Queue.json：全部任务项和状态。Plan.md：阶段计划、里程碑、验收方式。Runbook.md：固定命令、环境要求、常见失败处理。Evidence/：每次验证输出、截图、manifest、dry-run JSON。README.md：当前包状态和下一步。Decision.md：重要口径变化和原因。
文件不需要复杂，但要稳定。对 Agent 来说，稳定路径比华丽格式更重要。每次恢复时，第一步应该是读目标文件、队列、当前包 README、最近证据，而不是从聊天摘要里直接开工。
AGENTS.md 的角色也在这里。OpenAI 的 AGENTS.md 文档说明，Codex 会在工作前读取这些指令文件，并按全局、项目、子目录的顺序叠加，靠近当前目录的规则优先。它适合放团队约定、构建命令、测试方式、完成定义和禁区。队列告诉 Agent “当前做哪一项”，AGENTS.md 告诉 Agent “在这个项目里应该怎样做”。
这也是为什么长任务需要“项目记忆”和“任务记忆”分开。项目记忆是长期规则，比如发布目标、不能输出密钥、测试命令、平台边界。任务记忆是当前进度，比如第几篇完成、哪个 dry-run 通过、哪张图失败。把两者混在聊天里，迟早会乱。
每个检查点都要留下证据
没有证据的状态，等于没有状态。长任务里最有价值的不是“我觉得已经完成”，而是“这里有可复查的证据”。
证据可以很小。一次字数检查可以是一行命令输出；一次 dry-run 可以是一个 JSON；一次生图可以是 manifest 和接触图；一次资料核验可以是 sources.md；一次发布检查可以是公开 URL 或 catalog 结果。重点不是堆很多日志，而是留下能证明状态的最小证据。
对内容生产来说，证据尤其重要。因为“文章写了”不等于“文章可发布”，“图片生成了”不等于“图片是真实模型生成且比例正确”，“dry-run 通过了”不等于“已经正式发布”。每个状态都应该能被证据反推。
一个实用习惯是，在每个包的 README 里写四件事：当前状态、关键文件、验证结果、下一步。README 不是给读者看的文章，而是给下一位执行者看的恢复卡。它应该尽量短，避免把完整聊天搬进去，但要把证据路径写全。
长任务恢复时先做什么
当一个 Codex 长任务中断后，不要急着继续执行。恢复的第一步应该是重新建立现场。
可以按这个顺序读：
1. 读项目规则：AGENTS.md、项目手册、发布边界。 2. 读真实目标：目标文档、最新口径修正、非目标。 3. 读队列：找到下一条未完成任务，确认状态统计。 4. 读当前包：README、package JSON、manifest、review 文件。 5. 读证据：最近 dry-run 输出、图片 manifest、来源记录。 6. 做最小校验：检查文件是否存在、状态是否一致。 7. 只重做缺失部分：不要因为聊天中断就从头返工。 8. 写回状态：完成后更新队列、目标文档和外部记忆系统。
这套顺序看起来慢，其实比“凭印象继续”更快。尤其在多个 Agent 并行时，恢复前的状态检查可以避免重复劳动，也能避免覆盖别人刚刚完成的修改。
OpenAI Codex automations 文档提到，线程自动化适合检查长时间运行命令、轮询外部系统、持续同一条审查循环；worktree 则可用于隔离后台自动化对文件的修改。这个思路放到人工启动的长任务里也成立：长任务要么在同一线程持续保留上下文，要么在独立工作区隔离产物；无论哪种方式，都要让状态文件成为交接中心。
并行生产时，主控比速度更重要
一旦任务规模大到可以并行，很多团队会本能地想“多开几个 Agent 一起跑”。这确实能提速，但前提是有主控角色。
主控不一定亲自做每个子任务，但必须维护三个东西：队列真相源、状态口径、合并规则。没有主控，多 Agent 很容易出现两种混乱：一种是重复做同一项，另一种是每条线都按自己的理解更新状态，最后没人知道整体进度。
对可恢复队列来说，主控要决定：
- 哪些任务可以并行，哪些必须串行。
- 哪个文件由谁写，哪个文件只能由主控更新。
- 子任务完成后交什么证据，不交什么敏感信息。
- 审计线和生产线如何分离，哪些状态不能越权标记。
- 如果两个线程状态冲突，以哪个证据为准。
例如，内容生产线可以负责文章包、图片、dry-run 和写回；审计线负责 ChatGPT Pro 和 Claude 复审；发布线负责正式发布。生产线不能因为自己 dry-run 通过就把复审标成通过，审计线也不应该顺手改生产队列的下一篇指针。分工不是为了繁琐，而是为了让长任务能持续运转。
常见误区
第一个误区是把一个巨大提示词当作项目管理。提示词再长，也很难替代队列、状态和证据。它适合作为启动说明，不适合作为唯一真相源。
第二个误区是把聊天记录当数据库。聊天里有很多中间推理、失败尝试和临时判断，它适合回顾，不适合做恢复依据。恢复依据应该是目标文档、队列、产物和验证结果。
第三个误区是状态过度乐观。比如“图片生成中”被写成“图片完成”，“dry-run 通过”被写成“已发布”，“复审待做”被写成“复审通过”。长任务越长，越要保守标记状态。
第四个误区是没有单步重试机制。生图失败就重跑整篇，dry-run 失败就重写文章，测试失败就重构全部代码，这些都会浪费时间。队列项应该让失败可以缩小到最小单元。
第五个误区是把自动化当成无人监管。Codex automations 很适合稳定、重复、可检查的工作，但自动化 prompt 也要 durable，要写清楚何时继续、何时报告、何时停止。权限、沙箱、worktree 和人工审批仍然重要。
一套可以直接复用的长任务队列模板
如果你准备把一个 Codex 长任务拆成可恢复队列，可以先用下面这套字段，不必一开始就做复杂系统：
id:
title:
owner:
status:
priority:
input_paths:
external_sources:
constraints:
deliverables:
validation_commands:
evidence_paths:
last_action:
next_action:
blocked_reason:
updated_at:每次 Agent 开始工作前，只允许它选一条 queued 或 failed_retryable 的任务。开始后改成 in_progress，完成一个检查点就更新证据。遇到阻塞就写 blocked_reason，不要沉默失败。完成后改成 needs_review 或 done，取决于是否还需要外部审查。
队列格式可以是 CSV、JSON、Markdown table、数据库，甚至项目管理工具。格式不是重点，关键是它必须满足三个条件：人能读，Agent 能读，验证能落地。
最后的行动清单
如果只记住一句话，就是：长任务不要押注在一次漫长对话上，要押注在可恢复的状态系统上。
开始一个 Codex 长任务前，先写清楚目标和非目标；把大目标拆成能独立验证的队列项；给每个队列项定义状态机；把关键约束放进 AGENTS.md 或项目规则；把运行命令和失败处理写进 runbook；每完成一个检查点，就留下证据；每次恢复，先读文件和队列，再继续执行。
这样做不会让 Agent 变成完美执行者，但会让它从“会话里的助手”变成“项目里的协作者”。它可以断点续做，可以被审计，可以被另一个线程接手，也能在失败后从最小单元重试。对真正的大任务来说，这比一次性多生成几千字提示词更有用。
Codex 长任务的关键，不是让它永远不停，而是让它每一次停下之后，都知道如何继续。