/goal 目标模式怎么用：Codex 与 OpenCode 长任务教程
让编程 Agent 干长活，最烦的是每轮结束都得补一句「继续」。OpenAI Codex 和开源的 OpenCode 现在都有 /goal：给一个目标，会话会自己一轮轮往下推，直到判定目标达成、被你暂停，或者卡住。下面按两边的官方文档、发布说明和合并的 PR（2026-11-02 北京时间查阅），讲清怎么开、怎么写目标、两家的停止规则有什么不同，以及哪些活不该交给它。
前置条件
- Codex：OpenAI cookbook 写明 Goals 从 Codex 0.128.0 开始提供，npm 上
@openai/codex当前是 0.166.0。CLI、IDE 扩展和 ChatGPT 桌面端都能用。 - OpenCode：10 月 29 日发布的 v2.2.1 内置了
/goal，TUI 和桌面端都有。1.x 线（最新 v1.19.5）没有内置这个命令。 - 一个能自己证明「做完了」的任务：测试套件、基准脚本、能构建的页面，或者一份可检查的产出物。没有验证手段，目标模式就只能靠模型自己说了算。
- 项目在 git 里，开工前
git status干净。长任务会改很多文件，出问题要能整体回滚。
第一步：把命令打开
Codex 里先输入 / 看列表里有没有 goal。没有的话，在 ~/.codex/config.toml 里打开功能开关：
[features]
goals = true也可以直接在终端跑 codex features enable goals，或者让 Codex 自己去跑。版本太旧就先升级：npm install -g @openai/codex@latest，再用 codex --version 确认。配置文件的层级和覆盖顺序，站内 Codex config.toml 教程讲过。
OpenCode 2.2.1 以后不用额外配置，/goal 是内置插件。两边的控制命令一样：
| 命令 | 作用 | Codex | OpenCode |
|---|---|---|---|
/goal 目标 | 设定目标并开工 | 有 | 有，最多 4000 字符，会替换旧目标 |
/goal | 查看当前目标和状态 | 有 | 有，状态以命令报错的形式返回 |
/goal pause / resume | 暂停、恢复自动续跑 | 有 | 有，恢复时轮数额度重置 |
/goal clear | 删除目标 | 有 | 有 |
| 界面提示 | 目标状态显示在哪 | 桌面端在输入框上方，可暂停、恢复、编辑、清除 | TUI 在输入框下方显示 ◎ goal，桌面端是输入框旁的小标签 |
| 非交互模式 | 脚本里能不能用 | 交互会话里用 | opencode run 不支持斜杠命令，暂时用不了 |
第二步：按六要素写目标
OpenAI 的 cookbook 把一个好目标拆成六件事：做完时什么为真（结果）、用什么证明（验证依据）、什么不能退步（约束）、能动哪些文件和工具（边界）、每轮之后怎么选下一步（迭代方式）、走不通时停下来报告什么（卡住条件）。官方给的模板可以直接套：
/goal <期望的最终状态>，由 <具体证据> 验证，同时保持 <约束>。
只使用 <允许的输入、工具或范围>。每轮之间，<如何选择下一步>。
如果卡住或没有可行路径，<报告什么、需要什么才能继续>。拿官方的性能优化例子对比一下。弱版本是 /goal Improve performance，没有终点，也没法验证。强版本是这样：
/goal Reduce p95 checkout latency below 120 ms, verified by the checkout benchmark,
while keeping the correctness suite green. Use only the checkout service,
benchmark fixtures, and related tests. Between iterations, record what changed,
what the benchmark showed, and the next best experiment to try. If the benchmark
cannot run or no valid paths remain, stop with the attempted paths, the evidence
gathered, the blocker, and the next input needed.cookbook 是这么判的：p95 从 180 ms 降到 135 ms，目标没完成；降到 120 ms 以下但正确性测试挂了，也没完成；基准跑不起来，就该报告阻塞，不能宣布成功。
开工前先定好三件事：什么算完成，什么算卡住，用哪条命令证明。
想不清楚怎么写，可以先让 Agent 帮你起草。Codex 文档建议先用 /plan 让它问你问题、理清约束，再把结果整理成带可测标准的目标，你审一遍再用 /goal 启动。官方 use case 页还给了三类现成模板：迁移（例如要求页面视觉不变，用 Playwright 核对）、照着 PLAN.md 做原型并给每个里程碑写测试、对着评测集优化提示词直到达到目标分数。
第三步：跑起来以后怎么盯
官方的建议是让它按检查点推进，并维护一份简短进度记录。每次状态汇报要说清四件事：当前检查点、验证了什么、还剩什么、是否卡住。汇报开始变含糊，就收紧目标本身，别一条条追加零碎指令。
中途可以继续发消息调整约束，比如指定用某个库。Codex 文档提到，要断网或离开前先 /goal pause，回来再恢复或编辑。想问进度又不打断主任务，Codex 有 /side 侧聊。
两家的停止规则不一样
Codex 把目标存成线程级状态，只在一轮结束、没有排队的输入、线程空闲时才考虑续跑。规划模式不触发续跑，用户打断会暂停目标；如果某次续跑一个工具都没调用，下一次自动续跑会被压住，防止空转。模型只能在证据支持时把目标标为完成，暂停、恢复、清除和预算耗尽都由用户或系统控制。预算用完时它会停下来总结进度和阻塞点，cookbook 特意说明这不等于完成。
OpenCode 的做法写在合并的 PR #59437 里：每次会话要进入空闲时，插件用同一个模型、带着完整历史问一个「审查器」，答案是 done、continue、blocked、paused、wait 之一。continue 就插入一条隐藏的续跑消息，重申目标和下一步。几条硬性刹车：连续 3 轮停滞（没调用工具，或审查理由和上一轮一样）就暂停，并提示 Not making progress；兜底上限 50 轮；后台任务卡住超过 30 分钟也暂停；服务重启后，之前进程留下的目标一律暂停，不会自己恢复。整段目标算一次执行，结束时只响一次提示音。
Codex 有预算上限，OpenCode 的 PR 写明暂不支持 token 预算，靠轮数和停滞检测兜底；审查用的也是会话本身的模型，暂时不能单独配置。
常见坑
- 目标太散：官方明确说别把一串不相关的活塞进一个目标。「把这个仓库变好」没有终点，会一直跑到预算或轮数耗尽。
- 没有验证命令：只写「修好登录 bug」，Agent 只能自评。至少写上哪条测试命令要通过、哪个页面要能打开。
- 以为重启后会接着跑：OpenCode 重启后目标是暂停状态，要手动
/goal resume。Codex 侧被打断也会暂停。 - 在脚本里调用：
opencode run不支持斜杠命令，CI 里想用目标模式暂时走不通。 - OpenCode 里随手覆盖目标：
/goal 新目标会直接替换旧目标，命令立即生效，改之前先看一眼当前目标。
哪些活别用 /goal
cookbook 列得很清楚：一行改动、简单解释、短代码审查、只想要一个答案就停的问题，用普通提示词更好；终点模糊的任务也不行。适合它的是三样都有的活：一个持久目标、一条看证据的终点线、需要好几轮摸索的路径，比如修偶发失败的测试、依赖迁移、跑基准调性能、复现论文结果。
完成标准
- 输入
/goal能看到你设的目标和当前状态（Codex 桌面端或 OpenCode 的◎ goal标记）。 - 目标里写明了验证命令或产出物，以及卡住时要报告的内容。
- 跑完后，Agent 的总结能对上具体证据：改了哪些文件、跑了哪些命令、测试或基准结果是多少。
- 你试过一次
/goal pause和/goal resume，知道怎么随时刹车。
最后
挑一个手上本来就有测试的任务，比如一个偶发失败的用例，按上面的模板写一个目标跑一次，看它的收尾报告能不能对上证据。怎么让 Agent 交付时附上证据，可以接着看 Agent 完成证据这篇。
