Codex 的 goal，不是多一条命令，是把“做到什么算完”抬成一等公民

先把新东西说清楚

Codex 的 goal 不是普通 prompt，也不是计划模式的另一个名字。

OpenAI 当前官方文档给出的定义很清楚：你用 /goal <objective> 设定目标，用 /goal 查看当前状态，用 /goal pause、/goal resume 和 /goal clear 控制它；目标会一直附着在当前 thread 上，工作继续时它不会自己掉线。官方在 use case 页面里又补了一层：一个好的 goal，应该明确“要实现什么、不能动什么、怎么验证进度、什么时候停”。

这意味着 goal 真正抬起来的，不是一句新命令，而是一个新的控制面：

先把目标写成可停机的条件。
再让 agent 围着这个条件跑多轮。
每轮都拿测试、构建、日志、截图、diff 之类的证据证明进度。
满足条件就停，不满足就继续。

普通 prompt 更像“你帮我做一轮”。goal 更像“你围着这个完成条件持续干，直到真的过线”。

如果还是觉得抽象，把官方那套写法翻成一个团队里真会拿去跑的目标，大概会长这样：

/goal 把这个 React Router 管理后台迁到 Next.js App Router。登录页、订单列表、订单详情和下单页的视觉结果要和旧版一致，用 Playwright interactive 逐页比对；只有 `npm test`、`npm run build` 和这四条页面流都通过，才算 done。

这类写法比“帮我迁一下前端”多出来的，不是礼貌，而是停机条件。Codex 后面每一轮跑不跑、停不停，都得围着这几句证据走。

它怎么工作

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 和文档里、并且在中途纠偏时不丢线程。

拿上面那个迁移后台的 goal 举例，一轮 loop 往往就是这么走的：

先把路由和数据获取从客户端模式迁到 App Router。
跑 npm run build，结果报 window is not defined 或 hydration 错误，说明 SSR 适配没过。
回头拆浏览器专属逻辑，再补边界处理，继续跑构建。
构建过了，再跑 Playwright；这时可能发现订单详情页样式错位，或者下单页按钮状态和旧版不一致。
它继续修 DOM 结构、样式或状态同步，再把那几条页面流重跑一遍。
只有构建、测试和页面验证一起过线，它才真的有资格停。

所以，如果只用一句话概括 Codex 的 goal，我会写成：

goal = 一个绑定在线程上的完成条件 + 一个围着验证证据不断自驱的 agent loop

为什么它会持续工作很长时间

很多人第一眼看到 goal，会下意识把它理解成“后台 daemon”或者“超长一次性生成”。这两个理解都不太对。

它能持续跑久，至少有三层原因。

第一层：它不是一次生成，而是多轮接力

OpenAI 在 Follow a goal 文档里写得很直接，Codex 可以在一个 goal 下独立工作很多小时，而且当它“确信已经达到 stopping condition”时才会停。换句话说，长时间持续不是异常，而是这套接口本来就鼓励的运行形态。

这里的核心不是时长，而是回合制。它每跑完一轮，都可以继续下一轮，而不是把整个任务压成一次输出。

第二层：done-when 被提前钉住了

OpenAI 官方反复强调的一点，是 contract。用户在开跑前最好先告诉 Codex：

这次到底要完成什么
哪些边界不能动
用什么命令或产物证明进度
什么情况下必须暂停

这会直接改变 agent 的行为方式。没有 stopping condition，agent 很容易在“继续做点什么”和“该停了”之间漂。把停机条件写清楚以后，长时运行反而更稳，因为每一轮都知道自己要拿什么证据回来。

所以 done when 最怕写成“差不多可用”。你最好把它拆成这种能执行、能回放的条件：

npm test 退出码为 0
npm run build 退出码为 0
Playwright 跑完 login -> orders -> detail -> checkout 没有视觉 diff
除迁移所需目录外，不改 API 合约和数据库 schema

这样 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. 迁移

官方页面给的模板非常直接：把项目从旧栈迁到新栈，所有 screen 视觉上保持一致，用 Playwright interactive 验证。这个例子如果落到真实团队里，通常会变成下面这种东西：

/goal 把旧版 React SPA 迁到 Next.js。主页、搜索、商品详情、支付确认四个页面必须保持视觉一致；每完成一批页面，就跑 `npm run build` 和 Playwright 截图。只要还有截图 diff 或构建失败，就继续。

这个案例最能说明 goal 的典型边界：目标明确、验证手段明确，而且一轮做不完。它不是让 agent “改到你觉得差不多”，而是让它反复跑到页面一致性和构建证据都回来。

2. 原型开发

官方建议先写一个 PLAN.md，把 milestone、测试和期望行为写清楚，然后让 Codex 依着计划边做边验。比如你要做一个内部数据看板，PLAN.md 里可以直接拆成三段：M1 登录和权限、M2 CSV 导入和校验、M3 图表页和导出；每段后面都挂上测试命令和 Playwright 验证路径。

对应的 goal 写法就会很具体：

/goal 实现 PLAN.md。每个 milestone 都补测试，并用 Playwright interactive 验证关键路径；只有 PLAN.md 里的 acceptance criteria 全部满足，才算完成。

这个就不是“先让模型脑补一下方案”，而是让它围着一张可验收的清单持续交付第一版。

3. Prompt 优化

如果你手里已经有 eval suite，官方建议可以直接把 goal 用到 prompt 优化上：先看失败样本，再改 prompt，再复跑 eval，直到分数提升或达到 stopping condition。翻成一个更像生产环境的目标，大概是这样：

/goal 把 `prompts/support-triage.md` 优化到 eval 通过率至少 `92%`。每次改完都跑 `pnpm promptfoo eval`，先看失败样本，再做最小化 prompt 修改；达到 `92%` 或继续改会触到产品/政策判断时停止。

这个案例具体就具体在，它连“什么能改，什么不能改，什么时候该停”都写进去了。你不是泛泛地让它“把 prompt 调好”，而是让它盯着 pass rate 和失败样本持续打磨。

这三类案例有一个共同点，它们都不是问答题，而是“需要反复执行和验证”的任务。

除了这些教科书式用法，OpenAI 最近两篇官方文章还给了两个更能说明方向的长时样本。

4. 官方长时实验：25 小时设计工具

2026-02-23 的官方博客里，作者给 Codex 一个空仓库和一份设计工具规格，让它在 GPT-5.3-Codex 的 Extra High 推理档位下持续运行。结果是大约 25 小时不间断、用了约 13M tokens、生成了约 30k 行代码。

这个案例真正具体的地方，不是“跑了 25 小时”，而是官方把它为什么能跑这么久也写出来了。作者不是只丢一句 prompt 就走，而是把长期记忆拆成了四个 Markdown 文件：

Prompt.md：写 goals、non-goals、硬约束、deliverables 和 done when
Plan.md：把任务切成单轮可完成的 milestone，并给每个 milestone 配 acceptance criteria 和 validation commands
Implement.md：要求严格按 plan 执行、每个 milestone 后立刻验证、失败先修再前进
Documentation.md：持续记录当前里程碑状态、决策原因、演示命令和已知问题

这就很关键了。你会发现它不是靠模型把 25 小时上下文全背住，而是靠 repo 里的外置项目记忆反复回看，所以才没有在半路把“做设计工具”做成“做个看着像设计工具的别的东西”。

这不是 goal 页面里的命令示例，但它非常说明 OpenAI 想把 Codex 往哪推：不是更会补代码，而是更能扛长期、多里程碑、可验证的大任务。

5. 官方 app 演示：7 million tokens 的赛车游戏

OpenAI 在 Introducing the Codex app 里也给了一个很抓眼球的例子：让 Codex 用一个初始 prompt 独立造一款赛车游戏，过程中用了超过 7 million tokens。

这个例子也不是一句“做个赛车游戏”就完了。官方公开的摘要 prompt 已经具体到玩法规格：

只做单人单局 3 圈比赛，1 个真人对 7 个 CPU
8 张地图、8 个角色，开局全部可选，没有解锁流程
漂移加速分成三档，持续时间分别是 0.7s、1.1s 和 1.5s
道具严格限定 8 种，而且还规定了失控和禁转向的最长时间

更重要的是，官方明确说 Codex 在这个过程中不只是写代码，还自己扮演 designer、game developer 和 QA tester，真的去玩这款游戏验证结果。这个案例说明，长任务不是 prompt 越松越好，反而是规格越细、验证越真，越容易长期跑稳。

它同样不等于“人人都该开这么长的任务”，但它把产品方向说得很明白了。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 这类能力真正会拉开差距的地方。

参考资料

写作附记

原始提示词

$blog-writer 详解 codex 新出的 goal 命令，工作原理是什么，为什么持续工作很长的时间，官方提供的案例是什么。claude code 有没有类似的命名，顺带整理近期 两家终端新出的，好用的、受欢迎的功能，整理为表格。

写作思路摘要

保留了用户最关心的三件事：goal 的机制、它为什么会长时间持续、官方到底给了哪些案例。
没把正文写成功能新闻汇总，而是先完成“表象 -> 机制 -> 样本 -> 边界”的解释闭环，再把近期功能压进表格。
对 Claude Code 没再用“类似能力”这种模糊说法，而是直接说明：当前官方文档里它也已经有 /goal。
压掉了未公开实现的猜测，只在 OpenAI 没有明说 evaluator 细节的地方做了明确标注。
这次补稿重点把“迁移、原型、prompt 优化、长时实验”都翻成了可执行案例，尽量让读者看到目标文本、验证动作和停机条件长什么样。