历经五小时暂停的六小时Codex运行（10分钟阅读）

# /goal: 经受住五小时暂停的六小时 Codex 运行 来源：https://tectontide.com/en/blog/codex-goal-six-hour-run/ ## TL;DR - **`/goal`** 随 **Codex CLI v0.128.0** 于 **2026年4月30日** 作为命名主打功能发布。 - 它引入了**持久化目标**：一种目标状态，能够在终端重启、笔记本合盖休眠、以及暂停数小时后依然保持，无需重新输入提示。 - **运行时续接**意味着 Codex 会在恢复时自动注入一条开发者消息，而不是等待你输入任何内容。 - 我在一个 TypeScript monorepo 上运行了一个真实会话。墙上时钟时间：约 **6 小时 44 分钟**。实际模型计算时间：约 **41 分钟**。最终状态：`TASK_COMPLETE`。 - 该会话累计消耗约 **6.8M 输入 token**，缓存命中率约 94%。自动上下文压缩触发了一次，可通过 `model_auto_compact_token_limit` 配置。 --- 我本没打算让 Codex 整夜运行。我在柏林时间 4 月 30 日晚上 9:19 开始了一个会话，看着一个轮次运行了 57 秒，然后合上笔记本睡觉去了。五个半小时后我回来时，`/goal` 已经在运行了。它正好从上次中断的地方继续。我没有任何重新输入提示。 这就是 `/goal` 在更新日志条目中无法体现的东西。它不仅仅是一个新命令。它是你与代理之间的一种不同契约。 ## 4月30日发布的内容 Codex CLI `v0.128.0`（标记为 `rust-v0.128.0`）于 2026 年 4 月 30 日发布。发布说明中的要点：“添加了持久化 /goal 工作流，包括应用服务器 API、模型工具、运行时续接，以及用于创建、暂停、恢复和清除的 TUI 控件。” 那一句话包含了很多内容，让我来拆解一下。 **持久化目标**是核心思想。之前的 Codex 会话是临时性的：关闭终端，线索就断了。`/goal` 将活动目标存储在应用服务器状态中，因此它比进程本身存活时间更长。 **应用服务器 API** 是这种持久化的底层机制。Codex 现在与一个跟踪目标状态的本地服务器层通信。 **模型工具**意味着模型本身获得了与目标生命周期交互的工具。它可以发出完成信号、请求续接、以及在其推理过程中检查目标状态。 **运行时续接**就是我那天晚上看到的行为。当你恢复（或者当 Codex 检测到会话再次活跃时），它会注入一条开发消息，提示模型继续工作。你不必输入任何内容。 **TUI 控件**完善了整个功能面。终端 UI 获得了明确的创建、暂停、恢复和清除操作，用于管理目标。你可以主动暂停一个正在运行的目标，而不仅仅是通过合盖来中断。 `v0.128.0` 的其他内容也值得简要提一下。回滚重排现在在终端调整大小时生效，而不会导致文本混乱。新增了一条 `codex update` 命令来处理 CLI 自更新。编译器在某个任务看起来适合规划时会显示规划模式提示。TUI 键位映射现在可配置。权限配置文件已扩展。`--full-auto` 标志已被弃用，转而使用显式的审批配置文件。同一周桌面应用也获得了改进，不过本博客的重点是 CLI。规划模式本身更早推出，在 2026 年 4 月 20 日的 v0.122.0 中。`/goal` 构建在这个基础之上。 ## /goal 实际做了什么 基本的机制很简单。你输入 `/goal` 后跟你的提示。Codex 存储该目标并开始工作。如果会话中断（网络故障、合上笔记本、故意暂停），目标会保持持久。当会话恢复时，Codex 通过运行时续接自动恢复。 模型通过 `TASK_COMPLETE` 或 `task_complete` 工具发出完成信号。在此之前，目标保持活动状态。 让它真正不同于长时间运行的 `--continue` 会话的是持久化层。在 `/goal` 之前，关闭终端意味着会话死亡。你可以通过仔细管理上下文文件和重新注入提示来近似实现连续性，这基本上就是 Ralph Wiggum Loop 以更简陋的方式所做的。`/goal` 将连续性作为一等特性。 这里有几个重要的配置旋钮。在 `~/.codex/config.toml` 中，`model_auto_compact_token_limit` 键设置了自动上下文压缩的阈值。`[features]` 块是功能标志所在的位置。`model_reasoning_effort` 键设置会话的推理努力程度。如果你想要无监督的自主运行，你还需要正确配置 `approval_policy` 和 `sandbox_mode`。我会在后面谈到这些。 TUI 也发生了变化。你可以看到目标状态。你可以主动暂停一个正在运行的目标，而不会杀死进程。恢复操作会通过运行时续接重新开始。 下面是一个真实会话的样子。 该项目是我正在开发的一个 TypeScript monorepo。一个语音采访系统，包含几个端到端场景，需要在一组定义明确的条件下正确工作。 我将 Codex 配置为 `approval_policy = "never"` 和 `sandbox_mode = "danger-full-access"` 以进行自主的 `/goal` 会话。这两个设置是实现无监督长时间运行的先决条件：模型不会停下来请求许可，并且拥有完整文件系统访问权限来完成工作。这只有在受信任的项目目录中并且具有干净的 git 状态时才合理。 `/goal` 提示大约有 600 个单词。我采用结构化方法编写：使用 XML 风格的块组织目标，一个明确的阅读列表（列出模型应首先查阅的 10 个以上文件），工作规则（编辑前检查 git 状态，优先使用 `rg` 而不是 `grep`，使用 `apply_patch`），一个 `done_when` 约定，明确列出四个具体的成功标准，以及明确的反模式围栏。其中一个围栏是：“不要添加基于字符串匹配的补丁来通过一个转录。” 如果你处理过语音系统，你就知道为什么需要那个围栏。 编写这样的提示本身就是一个任务。如果你想了解我是如何为此类工作设计提示的，《The Interview Method》一文介绍了该工作流。 模型：`gpt-5.5`。推理努力程度：`high`。 会话时间线： - **晚上 9:19** - 提交 `/goal`。 - **晚上 9:20** - 第一个轮次运行。我观察了 57 秒，然后中断（`turn_aborted`）。 - **5.5 小时** - 我合上了笔记本。没有重新输入提示。 - **大约凌晨 2:50** - 当我回来时，`/goal` 已经注入了一条开发者消息（“继续朝着活动目标努力”），并且正在运行。自主运行。 - **上下文压缩** 触发了一次，大约在累计输入 token 达到 6.7M 时。 - **累计 token**：约 6.8M 输入，约 10K 输出，约 2.6K 推理 token。缓存命中率：约 94%。 - **墙上时钟时间**：6 小时 44 分钟。实际模型计算时间：约 41 分钟，分布在各个轮次中。 - **最终状态**：`TASK_COMPLETE`。所有四个目标端到端语音场景都通过了验证。 人工转录审阅未发现任何提示循环、活性螺旋或过早关闭。模型有条不紊地处理了各个场景，并在满足标准时报出了完成。 一个值得一提的真实天花板。我原本希望获取的 TTS 首字节时间字段无法测量，因为上游库没有发出相关的运行时事件。模型诚实地记录了这一点。在产物中显式地设为 null，并附上了解释为何缺失该字段的注释。它没有掩盖这个缺口。`/goal` 可以给你一个自主的运行，但它无法绕过外部环境实际提供的能力。 约 94% 的缓存命中率是使经济性可行的一个数字。6.8M 输入 token 听起来很吓人，但当你意识到在该缓存率下实际增量成本只是名义数值的一小部分时，就不会那么担心了。 ## /goal vs Ralph Wiggum Loop 我之前写过关于 Ralph Wiggum Loop 的文章。Geoffrey Huntley 提出了这个词，他的原始文章仍然是权威参考：该技术本质上是 `while :; do cat PROMPT.md | claude-code; done` 并将 git 历史作为记忆。它解决了 `/goal` 要解决的同一个核心问题：如何让 AI 代理在单个上下文窗口无法容纳的任务上持续工作？ 这两种方法在特性上有所不同。 | 维度 | Ralph Wiggum Loop | `/goal` | |------|-------------------|---------| | 设置方式 | Shell 脚本或插件，外部编排 | 内置于 Codex CLI | | 状态持久性 | Git 历史，磁盘上的文件 | 应用服务器 API，原生目标状态 | | 恢复行为 | 手动重新调用 | 自动运行时续接 | | 上下文管理 | 每次迭代全新的上下文（有意为之） | 会话内压缩 | | 推理连续性 | 迭代之间无状态 | 会话内连续 | | 模型 | Claude Code | Codex 搭配 `gpt-5.5` | | 适用场景 | 每次传递都受益于全新视角的任务 | 需要累积上下文的长周期任务 | Ralph Wiggum Loop 确实有用。有意设计的无状态有时是一种优势：每次迭代重新面对问题，不会把错误的中期结论带过来。如果模型困惑了，下一次迭代会从头开始。 `/goal` 则押注于连续性。模型会在多个轮次中建立起对代码库的理解，不必在每次传递时从头读一遍所有内容。对于需要累积推理的任务（调试一个微妙的交互、导航一个复杂的状态机），连续性胜出。对于自然迭代收敛的任务（添加测试、修复 lint），Ralph 的新鲜上下文模型通常也同样有效。 两者都不是默认的正确选择。它们适用于不同形状的问题。 ## 何时不应使用 /goal 以下几种情况我不会选择使用 `/goal`。 **未定义的成功标准。**`done_when` 约定不是可选项。如果你在开始之前无法写出四个具体的成功标准，模型就无法知道什么时候完成。它要么过早声明 `TASK_COMPLETE`，要么无限循环。先写好约定。 **探索性工作。**早期阶段“搞清楚这个代码库在干什么”的工作最好有人类参与。你在模型揭示信息的同时也在学习。`/goal` 用于执行，而非探索。 **安全关键路径。**我使用 `approval_policy = "never"` 和 `sandbox_mode = "danger-full-access"` 运行。这种设置只适用于我完全信任的项目目录。认证系统、支付流程、任何涉及敏感数据的东西：都要让审批保持在线。 **不明朗的外部依赖。**如果你的任务依赖于你不太确定的外部系统，先弄清楚。我上面提到的 TTS 时间字段是温和版本。更昂贵的版本是运行了六小时，却在第五小时撞墙，因为外部 API 不支持你假设的功能。 **短任务。**`/goal` 有开销。一个你可以在交互式 Codex 中十分钟完成的任务，不会因为包裹在持久化目标中而变得更好。低于某个阈值，复杂性不值得。我的粗略启发式方法：如果任务在旧模型下不会舒适地跨越两个或更多独立会话，那么它可能不需要 `/goal`。 ## 思维模式的转变 > **旧思维**：自主 AI 运行是需要你监控、准备在事情出错时干预的会话。 > **新思维**：自主 AI 运行是你预先写好契约，然后放手不干预的会话。 转变是从监督者到架构师。`/goal` 会话的质量几乎完全在第一个轮次运行之前就已经决定了。提示的质量、成功标准、反模式围栏、阅读列表。一旦开始，你的工作基本就完成了。如果你写好了合同，模型就会执行。如果没有，再多的监控也救不了。 这是一种与交互式提示不同的技能。它更接近于编写一份规范，而不是进行一场对话。 --- ## 结论 `/goal` 是 Codex 自规划模式以来发布的最重要的功能。持久化层和运行时续接使其在实践中与长时间的 `--continue` 会话截然不同。六小时四十四分钟的墙上时钟时间，四十一分钟的实际计算时间之所以可能，是因为模型保持了它的上下文，缓存保持了命中，而且目标在我没有进行任何操作的情况下经受住了五小时的间隙。 经济性因为缓存命中率而变得可行。质量因为前期的提示纪律而得以保证。这两者都不是自动发生的。 这是两部分系列文章的第一篇。配套文章覆盖工作流方面：我如何在规范进入 `/goal` 之前进行准备。**《从 SPEC.md 到 /goal：我的 Codex + GPT-5.5 工作流》**。 --- ## 来源 - Codex v0.128.0 发布说明 (https://github.com/openai/codex/releases/tag/rust-v0.128.0) - Codex 更新日志 (https://developers.openai.com/codex/changelog) - Codex CLI 特性参考 (https://developers.openai.com/codex/cli/features) - Geoffrey Huntley: Ralph Wiggum, the goat (https://ghuntley.com/ralph/)