Codex /goal：不是多敲一个命令，是少盯几个小时

OpenAI 给 Codex CLI 加了 /goal。

简单说：你给 Codex 一个目标，它可以长时间围着这个目标执行。当前一轮结束后，它不会等你再发“继续”，而是自己判断任务有没有做完。没做完，就继续。

这不是概念功能。已经有人跑出来了。

Peter Steinberger 有一个 Goal 跑了 11 小时 31 分钟。Yannik（@ynkzlk）也分享了一个更完整的案例：他的 Codex /goal 连续运行 6 小时 44 分钟。中间 laptop 合上，暂停了 5 个多小时。回来后 Codex 自动恢复，最后把任务做完。

这件事值得看，不是因为“Agent 可以不睡觉”。机器本来就不睡觉。

真正值得看的是：什么样的任务，能交给 Agent 自己跑这么久？

先开启 /goal

版本需要 Codex CLI 0.128.0 或更高。

codex update
codex --version

然后开启 goals：

codex features enable goals

也可以手动改配置：

~/.codex/config.toml

加入：

[features]
goals = true

如果不想每次看到实验功能提示，可以加：

suppress_unstable_features_warning = true

目前主要是终端 Codex CLI 可用，桌面 App 还没跟上。

/goal 到底做了什么？

Yannik 的案例比较有参考价值。

他把一个 TypeScript monorepo 里的语音访谈系统交给 Codex，让它验证并修复多个端到端场景。

最后结果：

总运行时间：6 小时 44 分钟
真正模型计算时间：约 41 分钟
累计输入：约 680 万 tokens
cache hit rate：约 94%
最终状态：TASK_COMPLETE
四个目标端到端场景全部通过

中间最有意思的是恢复能力。

他在第 57 分钟合上 laptop。5 个多小时后回来，Codex 已经自己恢复执行。没有重新 prompt，没有手动恢复步骤。它往线程里注入了类似“继续朝当前目标工作”的 developer message，然后继续跑。

所以 /goal 的价值不是“自动点继续”。

它更像是在 Codex 里给长任务加了一层目标保持机制：目标还在，状态还在，下一轮继续围着这个目标走。

关键不是 /goal，是 goal 写得够不够像 contract

很多人会误用这个功能。

比如直接写：

/goal 帮我把项目优化一下

这基本等于把方向盘交出去，然后期待它刚好开到你心里想去的地方。

Yannik 的做法不是这样。他的 /goal prompt 大约 600 多字，结构很清楚，里面有：

明确目标
先读哪些文件
工作规则
不能走哪些歪路
验证方式
输出要求
done_when，也就是做到什么程度才算完成

这里最重要的是 done_when。

没有完成标准，Agent 很容易出现两种问题：

太早宣布完成
一直绕圈，反复“优化”

所以 /goal 不是一句咒语。它真正吃的是工程 contract。

你写得越清楚，它越能独立执行。你写得越虚，它越容易跑偏。

一个更靠谱的 /goal 写法

不要只写一句目标。至少写这几块。

/goal 完成【任务名称】。

目标：
【这次最终要交付什么】

先阅读：
- 【关键文件 1】
- 【关键文件 2】
- 【相关文档 / 测试 / 配置】

工作规则：
- 先理解现有实现，再修改
- 不要改无关文件
- 不要新增长期 feature flag
- 不要用 --no-verify 绕过检查
- 保留用户已有改动

完成标准 done_when：
1. 【用户侧结果可用】
2. 【相关测试通过】
3. 【build / lint / typecheck 通过】
4. 【没有引入指定失败模式】
5. 结束时说明改了什么、怎么验证、还有什么风险

遇到以下情况暂停：
- 需要登录、验证码、支付、密钥
- 需要生产环境操作
- 测试环境不可用
- 需求本身互相冲突

这个模板看着啰嗦，但它省的是后面几个小时的盯盘时间。

什么任务适合用 /goal？

适合边界清楚、验收清楚、过程可以自动验证的任务。

比如：

修一个明确 bug
做一个小功能
把一批测试修到通过
验证并修复几个端到端场景
清理 lint、type error、构建错误
按已有 SPEC.md 或 task plan 执行

这类任务的共同点是：Agent 能自己判断“现在离完成还差什么”。

什么任务不适合？

这部分更重要。

不适合：

探索型任务
成功标准不清楚的任务
安全敏感路径
依赖外部系统，但你还没确认链路可用
十分钟内本来就能交互做完的小任务

Yannik 的判断很实用：如果一个任务本来不需要跨越两个以上 session，大概率不需要 /goal。

别为了用新功能而用新功能。

短任务用普通 Codex 就够了。模糊任务先写 SPEC。高风险任务先让人卡住关键节点。

我对 /goal 的判断

/goal 的变化不在“让 Agent 跑更久”。

跑更久不难。难的是跑久了还不偏。

以前人更像 supervisor：看着它做，看到错就打断，没做完就补一句继续。

现在人的角色更像 architect：先把目标、边界、验收条件、失败模式写清楚，再让 Agent 自己执行。

这对使用者的要求反而更高。

你不能只会提需求。你要能把一个模糊想法，拆成 Agent 可以独立执行、验证、收尾的 contract。

写不出来，就别怪 Agent 跑偏。

最短使用建议

如果你要试 /goal，我建议先从这种任务开始：

/goal 修复当前项目里 failing tests。

先运行测试，定位失败原因，只修改相关文件。
完成标准：所有原本失败的测试通过，不能新增失败测试。
如果需要外部账号、密钥、生产环境权限，暂停并说明。
最后输出：失败原因、修改内容、验证命令、剩余风险。

不要一上来就让它“重构整个项目”。

先让它处理可验证的小长任务。稳定后，再放大范围。

参考信息

OpenAI Codex GitHub Release：rust-v0.128.0
Felipe Coury：/goal lands in Codex CLI 0.128.0
Greg Brockman：built-in Ralph loop++
Yannik（@ynkzlk）：6 小时 44 分钟 /goal 实战案例
Tecton & Tide：From SPEC.md to /goal: My Codex + GPT-5.5 Workflow
Michael Guo：关于 /goal 与工程 contract 的中文总结