Codex 长期任务五层工作系统：让 AI 跨小时、跨会话持续推进

枫叶丹4

832人浏览 · 2026-07-21 08:00:00

枫叶丹4 · 2026-07-21 08:00:00 发布

文章目录

在这里插入图片描述

前言

适用对象：已经会让 Codex 完成单次任务，希望把它用于持续研究、周期维护、复杂交付的人。
核心观点：长期任务不是“把提示词写得更长”，而是把目标、上下文、方法、门禁和续跑机制分层管理。

很多人第一次尝试让 Codex 做长期任务，会采用一种直觉做法：把背景一次性塞进对话，再要求它“持续做到完成”。短任务里这可能有效，任务一旦跨越几个小时、多个会话或多个执行环境，问题很快出现：目标逐渐漂移、历史决定被遗忘、验证标准时有时无、同一个错误反复发生，自动任务还可能在没有价值时继续消耗资源。

真正可持续的做法，是把长期工作视为一个小型运行系统。本文提出一套五层结构：目标层、上下文层、方法层、门禁层、续跑层。五层各自解决一种不同的问题，也使用不同的 Codex 能力。它们不是越多越好，而是需要各司其职。

版本与可用性边界：Goal、Memories、Hooks、Scheduled Tasks、Worktree 等能力可能因客户端、套餐、工作区策略、平台和后续发布而变化；文中的五层是工作流设计框架，不等于所有环境都同时具备这些功能。实施前应核对当前官方文档与实际界面，并为不可用能力准备手动或 CI 兜底。

在这里插入图片描述

一、先定义什么叫“长期任务”

长期任务不只指耗时很久的任务。只要满足下面任意一项，就值得按长期任务设计：

工作会跨越多个会话，下一次继续时不能从头解释；
中间存在多个阶段，每个阶段有自己的完成标准；
需要定期醒来检查新变化，例如依赖更新、测试回归或资料变化；
允许 AI 自主推进，但某些动作必须由人确认；
产出会被反复修订，历史决策与失败路径具有复用价值；
多条工作线可以并行，但必须避免改到同一批文件或相互污染状态。

因此，长期任务的难点不是单次推理能力，而是四种连续性：目标连续、知识连续、质量连续、执行连续。五层系统就是把这四种连续性落实到可管理的载体上。

二、五层分别解决什么问题

层级	核心问题	推荐载体	常见误用
目标层	最终要得到什么，何时算完成	Goal Mode、明确任务说明、阶段验收条件	把待办清单误当成目标
上下文层	AI 必须知道哪些事实与约束	`AGENTS.md`、项目文档、当前会话、必要记忆	把所有历史材料都塞进提示词
方法层	这类任务应按什么步骤执行	Skills、模板、可复用脚本、检查表	每次临时发明流程
门禁层	哪些规则必须确定性执行	Hooks、测试、lint、权限与人工确认	让模型“记得”执行硬性规则
续跑层	什么时候继续，如何恢复，何时停止	Scheduled Tasks、同一任务续跑、独立 Worktree	无停止条件地循环运行

这五层之间有一个重要边界：模型负责判断，系统负责约束。例如，“这个修改是否符合产品意图”通常需要模型和人共同判断；“提交前必须通过测试”则更适合由命令、Hook 或 CI 确定性执行。把硬规则只写进提示词，会让本可确定的控制变成概率行为。

三、第一层：目标层，让任务有稳定终点

OpenAI 的长期工作指南把结果、约束和完成定义放在最前面。Codex 的 Goal Mode 可以通过 /goal 建立一个持久目标；目标文本既是工作提示，也是完成判据。目标不清楚时，可以先用 /plan 把范围、阶段和验收方式收敛，再正式启动。

一个合格目标至少包含六项：

结果：最终交付物是什么，而不是“研究一下”“优化一下”；
范围：涉及哪些模块、数据或页面；
边界：明确不做什么，避免顺手扩张；
约束：兼容性、权限、风格、时间或成本限制；
验证：用哪些命令、样本或观察确认正确；
停止条件：完成、阻塞、预算到限或需要人工决策时如何停下。

例如，不要写：

帮我持续优化这个项目。

可以写成：

目标：把现有导入流程改造成可恢复的批处理，并交付实现、迁移说明和验证记录。
完成标准：
1. 中断后可从最近检查点恢复；
2. 重复输入不会生成重复记录；
3. 原有小批量路径行为不变；
4. 单元测试、集成测试和类型检查全部通过；
5. 任何数据结构变更必须先获得人工确认。
不做：不改管理后台视觉，不替换现有任务队列，不处理历史脏数据。

目标层最容易犯的错误，是把“过程很忙”当成“目标在推进”。长期任务每完成一个阶段，都应回看最终完成标准，而不是只看已经执行了多少命令、生成了多少文件。

四、第二层：上下文层，让必要事实稳定可得

长期任务会遇到两类遗忘：会话被压缩后的遗忘，以及换会话后的遗忘。解决方法不是无限扩大提示词，而是把信息放到正确的上下文载体。

建议按权威性与寿命分配：

必须遵守的团队规则放进 AGENTS.md 或版本库中的正式文档；
项目事实和架构决定放进项目文档、ADR、README 或任务 handoff；
可复用的个人偏好和经验可以由 Memory 召回，但不应成为唯一规则来源；
只对当前判断有用的临时证据留在当前会话；
任务恢复所需的最小状态写成阶段摘要，而不是保存整段原始对话。

官方说明指出，Codex 会在工作前读取 AGENTS.md，并按全局到项目的层级组合指令。这个机制适合承载稳定、强制、可审计的规则。相反，Memory 是召回层：它可能帮助 Codex 记住偏好和背景，但生成时机、召回结果和额度状态都可能影响可用性，因此不能替代正式规则。

上下文层的核心指标不是“存了多少”，而是：

下次继续时，是否能在两三分钟内恢复当前状态；
AI 是否能解释某个决定的理由和证据来源；
已否定的方向是否会被再次提出；
新材料是否覆盖旧事实，还是只在旁边继续堆积；
敏感信息是否被不必要地写进长期存储。

一个实用的阶段摘要可以固定为：当前目标、已完成、关键决定、验证结果、未解决问题、下一步、禁止事项。它比完整聊天记录更短，也更容易核对真伪。

五、第三层：方法层，把成功路径做成 Skill

如果某类任务每次都需要重新说明步骤，说明它还没有成为可复用能力。Codex Skills 用来打包任务说明、参考资料和可选脚本。官方文档采用渐进披露：初始只暴露技能名称、描述和路径，真正命中任务时再加载完整 SKILL.md，以减少无关上下文占用。

适合做成 Skill 的内容包括：

固定的调研方法和来源优先级；
文档、表格、演示稿的生产与验收流程；
某类迁移的预检、备份、执行、回滚和验证模板；
浏览器测试的视口、交互路径和截图要求；
安全审查的授权边界、证据格式和分级口径；
团队特有的交付目录、命名和 handoff 结构。

方法层不应塞入会频繁变化的项目事实，也不应替代权限控制。一个好 Skill 描述“如何做这类事情”，项目文档描述“这个项目现在是什么状态”，两者混在一起会导致复用时携带过期背景。

判断是否值得制作 Skill，可以问三个问题：

这套步骤是否至少会复用三次？
不按步骤执行是否容易漏掉关键环节？
是否能通过脚本或清单验证结果？

三个答案中有两个为“是”，通常就值得沉淀。

六、第四层：门禁层，把硬要求变成确定性动作

Hooks 是 Codex 生命周期中的确定性脚本，可在输入提交、工具调用前后、权限请求、停止等事件发生时运行。适合做日志、敏感信息预检、停止前测试、目录特定提醒等工作。

门禁层要遵守一个设计原则：只阻断真正不能继续的情况。如果每个低风险提示都阻断任务，长期执行会频繁停顿，最终用户只能关闭门禁。建议分成三档：

阻断：检测到凭据、将操作生产数据、测试明确失败、目标目录越界；
要求确认：对外发送、不可逆变更、扩大权限、产生显著费用；
仅记录：格式建议、低风险告警、性能趋势、可维护性提示。

还要注意，官方文档说明同一事件下的多个命令 Hook 会并发运行，一个 Hook 不能阻止另一个已经启动。因此，不能把多个相互依赖的安全检查拆成假定串行的独立 Hook。需要严格顺序时，应由一个受控脚本在内部按顺序执行。

Hook 自身也是代码。非受管理的 Hook 需要审查和信任，信任绑定到精确内容；内容变化后应重新审查。它不只是便利插件，而是能够介入工作流的执行边界。

七、第五层：续跑层，让任务在正确时间继续

Scheduled Tasks 解决的是“何时再次运行”，而不是“任务应该做什么”。一个稳定的计划任务需要明确：输入从哪里来、每次只检查什么、没有变化时如何报告、发现异常时何时停止、连续失败如何升级。

根据官方说明，桌面端的本地计划任务可以针对本地项目运行，并选择 Local 或隔离 Worktree；涉及本地文件时，设备与应用需要保持可运行状态。Web 端计划任务适合使用上传的上下文和可用工具，但不能直接依赖本地文件夹。CLI 与 IDE 当前也不提供计划任务管理界面。

续跑有两种基本模式：

模式	特征	适用场景	主要风险
独立运行	每次从新的任务上下文开始	每日扫描、固定报告、状态检查	背景不足，重复解释
原任务续跑	在已有任务中继续，保留相关上下文	长期研究、迭代交付、持续排障	旧假设积累，任务越来越重

选择标准不是“哪种更聪明”，而是本次运行是否必须理解此前判断。纯状态采集优先独立运行；需要沿用未完成计划和历史证据时，才使用原任务续跑。

在这里插入图片描述

八、一个可落地的案例：每周依赖健康检查

假设团队希望 Codex 每周检查项目依赖，但不能自动升级生产依赖。五层可以这样配置：

目标层：每周产出依赖风险报告；只对低风险开发依赖生成候选补丁；任何锁文件变化都等待人工确认；完成标准包括测试与构建结果。

上下文层：AGENTS.md 写明包管理器、支持版本、禁止修改的模块；架构文档记录为何锁定某些依赖；当前任务保存上周已接受和已拒绝的升级理由。

方法层：Skill 规定先读取官方变更日志，再按直接依赖、传递依赖、安全修复、破坏性变化分类，最后生成变更摘要和回滚方法。

门禁层：Hook 在准备提交前扫描凭据和范围外文件，运行测试、lint、类型检查；锁文件或 CI 文件出现变化时要求人工确认。

续跑层：每周在隔离 Worktree 中启动。没有可行动变化时只给一行结论；连续两次因同一环境问题失败则停止并升级，而不是无限重试。

这套设计的价值不是让 AI 自动升级一切，而是把人的注意力留给“是否接受这个变化”，把资料收集、候选修改、验证和报告交给系统提前完成。

九、搭建顺序：不要一次上齐五层

从零开始时，建议按风险而不是按功能完整度推进：

先写完成标准：没有目标层，其他自动化只会更快地产生偏差；
再整理最小上下文：只放继续工作必需的事实与规则；
跑通一次人工流程：确认步骤和验收命令真的有效；
把重复步骤做成 Skill：先固化高频、稳定部分；
把硬规则移到门禁：尤其是测试、敏感信息和不可逆动作；
最后增加计划运行：只有手动执行稳定后，才让任务自动醒来；
每两到四周删减一次：移除过期上下文、无效 Hook 和无人阅读的报告。

这一顺序有意把 Scheduled Tasks 放在最后。自动化一个尚未稳定的流程，只会把偶发错误变成周期性错误。

十、最常见的失败模式

1. 目标写成无限愿望

“持续优化质量”没有终点。改成可观测结果、时间窗口和停止条件。

2. 上下文只增不减

旧结论与新事实同时存在，AI 无法判断哪个更权威。为文档标注状态、日期和替代关系，阶段结束时主动归档。

3. Skill 变成万能手册

一个 Skill 覆盖所有任务，会让触发含糊、正文过长。按稳定工作流拆分，并让描述足够明确。

4. 把 Hook 当成智能审查员

Hook 适合确定性检查，不擅长替代产品判断。规则无法写清时，应让模型提出证据，再由人决策。

5. 定时任务没有静默条件

每天都发送“没有变化”的长报告，会迅速消耗注意力。规定无变化时的最小回执，并只在达到阈值时升级。

6. 多条长期任务共享同一工作目录

并行目标可能修改同一文件、覆盖状态。官方建议避免对同一文件并发工作，必要时使用独立 Worktree，并明确最终合并责任人。

7. 误以为 Goal 会扩大权限

Goal Mode 不会绕过沙箱或审批。需要额外访问时仍应显式授权，并遵循最小权限。

十一、什么时候不需要这套系统

下面这些任务通常用一次清晰对话就够了：

十分钟内能完成且结果容易目视判断；
不跨会话，也没有历史状态；
不涉及不可逆动作、敏感数据或对外承诺；
没有重复执行价值；
失败后直接重做比恢复更便宜。

五层系统的成本包括维护规则、审查 Hook、整理上下文和处理自动任务。任务越短、风险越低，越应该轻量。成熟工作流的标志不是层数最多，而是只保留对当前风险真正有用的层。

十二、把五层分成“控制面”和“执行面”

五层系统还可以从另一个角度理解。目标、上下文选择、方法、门禁和续跑策略构成控制面；读取文件、修改代码、搜索资料、运行测试和生成报告构成执行面。执行面回答“这一次做了什么”，控制面回答“为什么做、依据什么事实、允许做到哪里、怎样确认完成、何时继续”。

很多失控并不是模型不会执行，而是控制面缺失。例如，Codex 能快速批量改文件，但没有目标范围时会顺手重构；能不断定时搜索，但没有停止条件时会重复制造报告；能运行测试，但没有定义必跑测试时会选择最方便的一组。补充控制面后，同样的模型和额度往往会得到更稳定结果。

控制面应当留下可审计链条：

每个执行阶段能追到一个目标或验收条件；
每项强制约束能追到正式规则或人工决定；
每个自动步骤能说明使用了哪个 Skill 或脚本版本；
每次阻断能说明是哪一道门、命中了什么条件；
每次续跑能说明基于哪个成功状态和时间窗口；
每个最终结论都能区分事实、推断和人工采纳。

这条链不需要做成庞大平台。早期用一份结构化 handoff、验证记录和变更清单就够了。重点是不要只保留最终文件，因为最终文件无法解释中途为何改变方向，也无法支持下一次可靠续跑。

控制面也需要版本意识。目标变化、规则更新、Skill 修订或 Hook 内容改变后，应记录生效点。正在运行的任务不能默默套用新规则继续，尤其当新旧版本的权限或完成标准不同。稳妥做法是暂停、比较差异、由人确认从哪个阶段按新版本重跑。

十三、用成熟度和指标判断是否真的提效

长期工作流可以分成五个成熟阶段，而不是一开始就追求全自动。

阶段	表现	下一步重点
L0 单次对话	每次重新解释，结果靠人记住	写清目标与完成标准
L1 可恢复任务	有阶段摘要，跨会话能继续	分离规则、事实和临时证据
L2 可复用流程	高频步骤形成 Skill 与模板	增加确定性验证和失败出口
L3 受控自主	AI 可推进到人工判断点	观察误报、返工和权限边界
L4 周期运营	任务能定期续跑、报告、停止	持续删减低价值自动化

升级条件应该基于证据。L1 尚且无法稳定恢复，就不要急着进入 L4；手动执行经常需要临场改步骤，也不适合立即封装成无人值守任务。

推荐观察七个指标：

首次可用率：第一次交付无需大改即可采用的比例；
人工介入次数：一次任务中，人被迫补背景或纠偏多少次；
恢复时间：隔天继续时，从打开任务到能正确推进需要多久；
验证覆盖率：计划中的验证是否真的执行并有结果；
返工来源：问题来自目标、上下文、方法、门禁还是调度；
有效报告率：自动报告中真正触发决策或行动的比例；
失败收敛时间：出现同类失败后，系统多久停止重试并升级。

这些指标不应变成员工绩效。它们用于定位系统瓶颈：首次可用率低可能是目标和示例不足；恢复时间长说明 handoff 不够；验证覆盖率低需要门禁；报告无人处理则应降频或停用。真正的提效不是 Token 消耗更多，也不是同时开了更多任务，而是单位人工注意力换来的可用结果更多。

每月可以做一次轻量复盘：选择三个长期任务，记录各层出了什么问题，只修最主要的一层。持续三个月后，团队会得到一套基于真实失败形成的工作系统，而不是一份从未被验证的宏大规范。

还可以增加一个“降级是否顺畅”的健康信号。模型额度不足、外部工具不可用、设备离线或审查者暂时无法响应时，任务能否保存当前状态、停止高风险动作，并把最小 handoff 交给人。如果只有所有组件都在线时才能工作，这套系统仍然脆弱。真正成熟的长期任务允许暂时退回人工、只读或低成本模式，恢复后再从明确检查点继续，而不是把失败伪装成完成。

最后，指标必须与具体目标绑定。研究任务的首次可用率和证据覆盖更重要，代码任务关注测试、回归和合并成本，周期报告关注行动率与噪声。不要把一套数字强行用于所有工作，否则团队会为指标优化输出形式，却没有提高结果质量。