作者在 4 月 30 日晚启动了一个 Codex /goal 会话，看了第一轮运行 57 秒后关电脑睡觉，5.5 小时后回来，Codex 已经在自主运行，最终任务完成。
这不是因为他运气好，而是 /goal 这个功能从根本上改变了你和 Agent 之间的契约方式。
4 月 30 日发生了什么
Codex CLI v0.128.0 发布，/goal 作为头条功能推出。它的核心是持久化目标——之前的 Codex 会话是临时的，关掉终端就丢失；/goal 把目标状态存储在 app-server 里，进程重启、笔记本睡眠、多小时暂停都不丢。
运行时继续（Runtime continuation）是另一个关键机制：会话恢复时，Codex 主动注入一条开发者消息引导模型继续工作，你不需要做任何事。
实测数据
作者在一个 TypeScript monorepo（语音面试系统）上跑了完整测试：
- 提示词约 600 词，提前写好「完成合同」，包含四个具体成功标准
- 用的模型是
gpt-5.5，推理强度high - 9:19 PM 提交 → 9:20 PM 第一轮运行 57 秒后中断 → 2:50 AM 回来时已在自主运行
- 上下文压缩在约 670 万输入 token 时触发一次
- 累计输入 token 约 680 万，输出约 10K，推理 token 约 2.6K
- 缓存命中率 94%——这是让经济学账算过来的关键数字
- 墙上时间 6h 44min，实际模型计算时间约 41 分钟
- 最终状态：
TASK_COMPLETE，四个目标端到端场景全部通过验证
唯一遗憾：上游库没有发出运行时事件，一个 TTS 首字节时间字段无法测量。模型诚实地记录了这个空缺，没有掩饰。
/goal 和 Ralph Wiggum Loop 的区别
Ralph Wiggum Loop 是 Geoffrey Huntley 提出的方案，本质是 while :; do cat PROMPT.md | claude-code; done 加 git 历史做记忆。它解决的是同一个问题：如何在单个上下文窗口之外维持 Agent 工作。
| 维度 | Ralph Wiggum Loop | /goal |
|---|---|---|
| 状态持久化 | Git 历史，磁盘文件 | App-server APIs，原生目标状态 |
| 恢复行为 | 手动重新调用 | 自动运行时继续 |
| 上下文管理 | 每轮新鲜上下文（设计如此） | 会话内自动压缩 |
| 推理连续性 | 每轮之间无状态 | 会话内连续 |
| 适用场景 | 天然迭代收敛型任务 | 推理累积型长周期任务 |
两种工具适合不同问题形状。Ralph 的无状态属性有时候是优势——每轮不携带可能有误的中间结论；/goal 则在推理会跨轮累积的场景下更有效，比如调试复杂交互、导航复杂状态机。
什么时候不该用 /goal
- 成功标准不明确：
done_when合同写不出来，模型不知道何时结束，会提前宣布完成或无限循环。先写合同。 - 探索性工作：早期「摸清这个代码库」的任务需要人在回路，/goal 是执行工具，不是探索工具。
- 安全关键路径：作者的配置是
approval_policy = "never"+sandbox_mode = "danger-full-access"，只适合完全信任的项目目录。认证系统、支付流程、敏感数据相关的工作，保持审批在循环内。 - 外部依赖不清晰：先搞清楚外部系统能提供什么。六小时后第五小时撞墙的代价远高于提前半小时调研。
- 短任务：/goal 有开销，10 分钟能完成的任务不需要它。粗略判断——如果任务在旧模式下不值得分两个会话跑，就不需要 /goal。
思维方式的转变
旧模式：自主运行是你监控的会话，准备在出问题时刻干预。 新模式：自主运行是你提前写好的合同，然后让 Agent 自己执行。
质量在第一轮运行之前就确定了——提示词质量、成功标准、反模式围栏、阅读清单。一旦开始，你的任务基本结束。如果合同写得好，模型执行；如果写得不好，监控救不了你。
这更像是写规格说明书，而不是对话式提示。