先把新东西说清楚
Codex 的 goal 不是普通 prompt，也不是计划模式的另一个名字。
OpenAI 当前官方文档给出的定义很清楚：你用 /goal <objective> 设定目标，用 /goal 查看当前状态，用 /goal pause、/goal resume 和 /goal clear 控制它；目标会一直附着在当前 thread 上，工作继续时它不会自己掉线。官方在 use case 页面里又补了一层：一个好的 goal，应该明确“要实现什么、不能动什么、怎么验证进度、什么时候停”。
这意味着 goal 真正抬起来的，不是一句新命令，而是一个新的控制面：
- 先把目标写成可停机的条件。
- 再让 agent 围着这个条件跑多轮。
- 每轮都拿测试、构建、日志、截图、diff 之类的证据证明进度。
- 满足条件就停，不满足就继续。
普通 prompt 更像“你帮我做一轮”。goal 更像“你围着这个完成条件持续干，直到真的过线”。
它怎么工作
OpenAI 官方没有像 Anthropic 那样把 Codex goal 的 evaluator 细节完全公开出来，所以这里要分成两层说。
第一层，是官方明确公开的行为契约。
/goal会把目标挂到当前 thread。- 它适合“比一条 prompt 大、但又小于一个无限 backlog”的任务。
- 用户需要先定义 stopping condition，也就是“什么算 done”。
- 运行中可以查看状态、暂停、恢复、清除。
- 官方直接把它描述成一个你“不用一直盯着”的 background task。
第二层，是从官方文档和长时任务文章里能比较稳地推出来的工作链路。
Codex 跑长任务时，本质上不是在做一口气吐完的大回答，而是在反复执行一个 agent loop：
- 计划。
- 改代码或改文件。
- 跑工具，比如测试、lint、build、浏览器检查。
- 观察结果。
- 修失败点。
- 更新状态和文档。
- 继续下一轮。
OpenAI 在 Run long horizon tasks with Codex 那篇官方博客里，几乎把这条链路明说了。文中把 Codex 的长期运行拆成 plan -> edit -> run tools -> observe -> repair -> update docs/status -> repeat，并强调长期任务的关键不在“单次 prompt 更聪明”，而在这个 loop 能不能持续拿到真实反馈、把状态外置到 repo 和文档里、并且在中途纠偏时不丢线程。
所以，如果只用一句话概括 Codex 的 goal，我会写成：
goal = 一个绑定在线程上的完成条件 + 一个围着验证证据不断自驱的 agent loop
为什么它会持续工作很长时间
很多人第一眼看到 goal，会下意识把它理解成“后台 daemon”或者“超长一次性生成”。这两个理解都不太对。
它能持续跑久，至少有三层原因。
第一层：它不是一次生成，而是多轮接力
OpenAI 在 Follow a goal 文档里写得很直接，Codex 可以在一个 goal 下独立工作很多小时，而且当它“确信已经达到 stopping condition”时才会停。换句话说，长时间持续不是异常，而是这套接口本来就鼓励的运行形态。
这里的核心不是时长，而是回合制。它每跑完一轮，都可以继续下一轮，而不是把整个任务压成一次输出。
第二层：done-when 被提前钉住了
OpenAI 官方反复强调的一点，是 contract。用户在开跑前最好先告诉 Codex：
- 这次到底要完成什么
- 哪些边界不能动
- 用什么命令或产物证明进度
- 什么情况下必须暂停
这会直接改变 agent 的行为方式。没有 stopping condition，agent 很容易在“继续做点什么”和“该停了”之间漂。把停机条件写清楚以后，长时运行反而更稳，因为每一轮都知道自己要拿什么证据回来。
第三层：模型本身也在为长时任务做优化
这不是只有产品层在补接口，模型层也在补。
OpenAI 在 Introducing GPT-5.2-Codex 里明确说，GPT-5.2-Codex 针对 long-horizon agentic coding 做了优化，尤其提到 context compaction、大规模代码修改、迁移和重构这类长链路任务。官方长文又补了一层：最近的 Codex 模型更擅长 plan -> implement -> validate -> repair 这种多步执行，而且中途纠偏时不需要把整段进度推倒重来。
所以你看到的“持续工作很久”，并不是单靠 goal 命令魔法般变出来的。它是三样东西叠起来的结果：
goal把完成条件显式化了。- agent loop 把任务切成了可验证的多轮。
- 长时任务优化和上下文压缩，让模型更不容易中途散掉。
官方给了哪些案例
如果只看文档，OpenAI 对 goal 给了三类非常直接的官方用法。
1. 迁移
官方示例是把旧栈迁到新栈，并要求界面视觉上保持一致，再用 Playwright 去验证输出。这个案例最能说明 goal 的典型边界：目标明确、验证手段明确、而且一轮做不完。
2. 原型开发
官方建议先写一个 PLAN.md，把 milestone、测试和期望行为写清楚，然后让 Codex 依着计划边做边验。这个就不是“先让模型脑补一下方案”，而是让它围着一张可验收的清单持续交付第一版。
3. Prompt 优化
如果你手里已经有 eval suite，官方建议可以直接把 goal 用到 prompt 优化上：先看失败样本，再改 prompt，再复跑 eval，直到分数提升或达到 stopping condition。
这三类案例有一个共同点，它们都不是问答题，而是“需要反复执行和验证”的任务。
除了这些教科书式用法，OpenAI 最近两篇官方文章还给了两个更能说明方向的长时样本。
4. 官方长时实验：25 小时设计工具
2026-02-23 的官方博客里，作者给 Codex 一个空仓库和一份设计工具规格，让它在 GPT-5.3-Codex 的 Extra High 推理档位下持续运行。结果是大约 25 小时不间断、用了约 13M tokens、生成了约 30k 行代码。
这不是 goal 页面里的命令示例，但它非常说明 OpenAI 想把 Codex 往哪推：不是更会补代码，而是更能扛长期、多里程碑、可验证的大任务。
5. 官方 app 演示：7 million tokens 的赛车游戏
OpenAI 在 Introducing the Codex app 里也给了一个很抓眼球的例子：让 Codex 用一个初始 prompt 独立造一款赛车游戏，过程中用了超过 7 million tokens。
它同样不等于“人人都该开这么长的任务”，但它把产品方向说得很明白了。Codex 现在要卖给你的，不只是聊天式编程，而是“长时间、可并行、可回看、可验证”的 agent 工作流。
Claude Code 有没有类似的命名
有，而且不是“类似”，是现在就有官方 /goal。
Claude Code 当前文档写得比 OpenAI 更直白：/goal 需要 v2.1.139+，它会设置一个 completion condition。之后每一轮结束，会有一个“小而快的模型”检查条件是否成立；如果没成立，Claude 就自动进入下一轮，而不是把控制权交还给你。文档还明确说，这个 evaluator 默认走 Haiku，而且 /goal 本质上是一个 session-scoped 的 Stop hook 包装层。
这就带来一个很清楚的结论：
- OpenAI Codex 的
goal，官方公开的是行为契约和使用方式，没有把 evaluator 的内部实现完全展开。 - Claude Code 的
/goal，官方直接把评估器口径、作用范围和与/loop、Stop hook、auto mode 的关系都写明了。
所以如果你问“Claude Code 有没有类似命名”，答案已经不是“有个差不多的东西”，而是“它现在也叫 /goal，只是公开实现细节更多”。
顺手再把 Claude 这几个容易混的概念分开：
/goal：条件驱动。上一轮结束后立刻判断是否继续。/loop：时间驱动。按间隔重跑 prompt，适合轮询部署、盯 PR、看长构建。- Stop hook：自定义驱动。你自己写规则，决定何时继续或停止。
换句话说，goal 不是 cron，也不是单纯自动批准权限。它是“每一轮结束以后，谁来决定还要不要继续”。
两家终端最近值得盯的功能
下面这张表不是严格的“热度排行榜”，而是按 2025-09-29 到 2026-05-27 这段时间内，两家官方推出、并且最能提高终端 agent 吞吐量的功能整理的。
| 产品 | 功能 | 时间 / 版本 | 解决什么问题 | 我的判断 |
|---|---|---|---|---|
| Codex | Goal mode | 2026-05-21 GA |
把 outcome 和 success criteria 绑定到持续运行的 thread 上 | 这是 Codex 现在最关键的新抽象，适合迁移、重构、原型、多轮评测 |
| Codex | In-app browser annotations + browser use improvements | 2026-05-21 |
前端和网页任务里，视觉反馈、资源抽取和浏览器操作更精细 | 对 UI 迭代最实用，不再只是“看一眼截图说不像” |
| Codex | Locked computer use | 2026-05-21 |
Mac 锁屏后仍可远程继续 Computer Use | 真正把“我走开一会儿它继续跑”变成可用能力 |
| Codex | Mobile access to remote Codex environments | 2026-05-14 |
人不在电脑前时，也能从手机接入、改方向、审批动作 | 跟长时任务搭配非常实用，减少被桌面绑死 |
| Codex | 多 agent 并行、worktrees、skills | 2026-02-02 app 发布，2026-02-23 官方长文继续强调 |
把并行任务、隔离 diff、流程固化放进同一套工作流 | 真正提升吞吐量的不是模型本身，而是这一组配套能力 |
| Claude Code | /goal |
v2.1.139+ |
用 completion condition 驱动跨 turn 持续工作 | 和 Codex 已经收敛到同一个命名，但公开机制更透明 |
| Claude Code | /loop scheduled tasks |
v2.1.72+ |
轮询部署、PR、长构建，或在会话内做定时回看 | 它不是 goal 的替代，而是时间驱动那一类需求的更优解 |
| Claude Code | Checkpoints + /rewind |
2025-09-29 |
大改动前自动存状态，随时回退代码或对话 | 做宽范围探索和重构时，安全感提升非常明显 |
| Claude Code | Subagents + hooks + background tasks | 2025-09-29 |
并行分工、自动测试/格式化、长进程不阻塞主任务 | 这是 Claude 这边最像“自治工具箱”的一组能力 |
| Claude Code | Plugins + marketplace | 2025-10-09 public beta |
把 slash commands、subagents、MCP、hooks 打包分享 | 生态扩展性很强，团队标准化和社区复用价值都高 |
最后收一下
如果你只把 Codex 的 goal 看成一个新命令，结论大概率会很浅：无非是“可以让它多跑一会儿”。但真正值得注意的，不是时长，而是 agent 终端正在把“什么算完成、谁来判断完成、完成前怎么持续验证”做成一层显式接口。
这也是为什么两家最后都开始用 /goal 这个名字。它们都在把终端 agent 从“单轮对话工具”往“带停机条件的持续工作者”推。
后面真要比，重点也不该只比谁能跑更久，而是谁的完成条件更好写、验证链路更稳、纠偏成本更低、进度更容易审计。这才是 goal 这类能力真正会拉开差距的地方。
参考资料
- ChatGPT — Release Notes | OpenAI Help Center
- Slash commands in Codex CLI | OpenAI Developers
- Follow a goal | Codex use cases
- Run long horizon tasks with Codex | OpenAI Developers
- Introducing GPT-5.2-Codex | OpenAI
- Introducing the Codex app | OpenAI
- Keep Claude working toward a goal | Claude Code Docs
- Run prompts on a schedule | Claude Code Docs
- Enabling Claude Code to work more autonomously | Anthropic
- Customize Claude Code with plugins | Claude
写作附记
原始提示词
$blog-writer 详解 codex 新出的 goal 命令，工作原理是什么，为什么持续工作很长的时间，官方提供的案例是什么。claude code 有没有类似的命名，顺带整理近期 两家终端新出的，好用的、受欢迎的功能，整理为表格。
写作思路摘要
- 保留了用户最关心的三件事：
goal的机制、它为什么会长时间持续、官方到底给了哪些案例。 - 没把正文写成功能新闻汇总，而是先完成“表象 -> 机制 -> 样本 -> 边界”的解释闭环，再把近期功能压进表格。
- 对 Claude Code 没再用“类似能力”这种模糊说法，而是直接说明：当前官方文档里它也已经有
/goal。 - 压掉了未公开实现的猜测，只在 OpenAI 没有明说 evaluator 细节的地方做了明确标注。