/goal 命令深度解析：AI Agent 长任务从逐轮指挥到目标驱动

/goal 命令深度解析：AI Agent 长任务从逐轮指挥到目标驱动

2026 年 5 月，Anthropic 在 Claude Code v2.1.139 中上线了 /goal 命令；三周之前，OpenAI 已经在 Codex CLI v0.128.0 里发布了同名功能的 Preview 版本。两家先后用同一个名字做同一件事：让 AI Agent 在无人逐轮批准的情况下朝着设定好的目标连续工作，直到完成条件满足或资源耗尽。Nous Research 的 Hermes 随后跟进。

这篇文章整理自对 20 余篇中外文章和 8 个以上 GitHub 仓库的调研，讲清四件事：/goal 的底层机制、Goal Prompt 的写法模板、三种典型失败模式和修复手段、以及一批能直接拿去用的开源资源。读完可以直接写出第一个不会跑飞的 /goal。

/goal 是什么：定义「完成」，不定义「下一步」

普通 prompt 是指令驱动：你说一步，Agent 做一步，每轮停下来等你确认。/goal 换成目标驱动：你描述一个可验证的终态（Verifiable End-state），Agent 自己规划路径、连续执行、自我检查，直到终态达成。

goal-prompt-architect 项目里有一句总结比官方文档更直白：

Don't ask the agent to keep going. Ask it to keep reducing uncertainty with verified evidence inside a bounded risk envelope. （别让 Agent「继续跑」，让它在受限的风险边界内，用验证过的证据持续把不确定性降下来。）

发布时间线如下：

平台	版本	日期	状态
OpenAI Codex CLI	v0.128.0	2026-04-30	Preview
Claude Code	v2.1.139	2026-05-13	Released
OpenAI Codex CLI	v0.133.0	2026-05-21	GA
Nous Research Hermes	---	2026-05	Released
Anthropic 官方 Loops 指南	---	2026-07-07	Published

几周之内三家厂商用同一个名字发布同一功能，explainx.ai 把它称为 "the single most underrated AI feature of 2026"。这个巧合指向一个正在成形的行业共识：Agent 在连续循环中运行到可测量的终态，中途不需要人工批准------这会成为一个通用接口。

底层机制：Stop Hook + 独立评估器

/goal 的实现是一个 Stop Hook：每轮主 Agent 执行完后，一个独立的小型快速模型（Claude Code 默认用 Haiku）读取对话 transcript，判断目标条件是否满足。满足则停止并报告，不满足则自动开始下一轮。

设定目标 → 主 Agent 执行一轮 → 评估器检查条件
   ↑                                 ↓
   └── 条件未满足，自动开始下一轮 ←──┘
        条件满足 → Agent 停止并输出报告

labuladong 对 Claude Code 的实现做过逆向分析，几个值得记录的细节：评判器以 JSON schema 输出 {ok, reason, impossible} 三个字段；运行时界面显示 ◎ /goal active 指示器，并持续记录已运行时长、轮数和 token 花费；进程崩溃后可以通过 --resume 或 --continue 恢复，已消耗的进度不丢。

单靠这个循环还不够。Anthropic 在官方工程文章《Harness design for long-running application development》里给出了更适合长任务的多 Agent 结构，设计灵感来自 GAN：

• Planner（规划者）：接收 1-4 句的简短 prompt，扩展成完整的产品 spec。只负责产品上下文和高层技术设计，不写细粒度实现。
• Generator（生成者）：按 Sprint 一个特性一个特性地实现，每个 Sprint 结束先自我评估，再交给 QA。
• Evaluator（评估者）：用 Playwright MCP 像真实用户一样点击应用，测试 UI 功能、API 端点、数据库状态。每个 Sprint 设硬阈值，低于阈值就判失败并把问题反馈给 Generator。

这套结构里最有价值的经验是：把干活的 Agent 和验收的 Agent 分开，比让一个 Agent 自我批评有效得多。独立的评估器可以被调教成「怀疑论者」，而让 Agent 批评自己的产出，几乎不可能得到客观结论------这也是 /goal 底层 Stop Hook 的设计哲学。

Goal Prompt 怎么写：社区收敛出的四类模板

/goal 上线几个月后，社区和开源项目对「Goal Prompt 长什么样」给出了高度一致的答案。以下四个模板按复杂度递增，来源都标注在文末的资源列表里。

最简的一行式模板，适合入门：

/goal [task] until [success condition], verified by [check], while [constraints], or stop after [limit]

五个组成部分：任务描述、成功条件、验证方式、约束、停止限制。三个真实例子：

/goal migrate auth to the new API until all auth tests pass and unrelated test files are unchanged
/goal refactor the user service until tests pass, or stop after 10 turns
/goal complete the migration, or stop after 30 minutes

第三个例子里 or stop after 10 turns 这种预算限制值得单独学：它把「失败也不会无限烧 token」写进了命令本身。

复杂长任务用八段式模板，来自 BolasLien/skills 的 codex-goal-writer。完整结构如下，读者重点看 Validation 和 Stop condition 两段：

/goal [complete one objective], without stopping until [verifiable end state].

Objective:
- [One durable objective.]

Context:
- Read first: [AGENTS.md / CLAUDE.md / PLAN.md / issue / docs / key files].
- Background: [short project or task context].

Scope:
- Allowed changes: [files, folders, modules].
- Do not change: [forbidden areas].
- Preserve: [behavior, UI, API, data format, compatibility].

Non-goals:
- [Explicit things not to expand into.]

Execution:
- Work in checkpoints and keep a short progress log.
- Before each checkpoint, state the immediate intent.
- After each checkpoint, run the relevant validation.
- Prefer minimal changes aligned with existing project patterns.

Validation:
- Run: [command or artifact check].
- If validation fails, inspect failure, make smallest targeted fix, rerun.

Pause conditions:
- Pause only if [specific blocking or risky conditions].

Stop condition:
- Stop when [specific commands pass / artifact works / score is reached].
- Final report must include changed files, validation evidence, and remaining risks.

这份模板的可取之处在于 Non-goals 和 Pause conditions 两段：前者显式声明「不要扩展到哪些范围」，防止 Agent 自作主张加需求；后者定义了哪些情况必须暂停等人，把「何时可以自作主张、何时不行」提前写清。

第三类是最小化 6 要素合约，来自 circuitstudioai/circuit-skills：

**Objective:** <one concrete outcome>
**Read first:** <files/issues/docs>
**Constraints:** <public APIs, dependencies, architecture, scope limits>
**Validate:** `<exact command>` after meaningful changes
**Document:** Update concise docs for changed behavior or setup.
**Do not:** Delete, skip, weaken, or narrow tests/checks to make the goal pass.
**Stop when:** <verifiable condition>, or when further progress needs human/product input.

最后那条 Anti-gaming rule 是全部模板里最值得抄走的一句：明确禁止 Agent 通过削弱、跳过、删除测试来「通过」验收。Agent 为了达成目标会走捷径，删掉挡路的测试就是最常见的捷径------不写这条，前面所有条件都可能被架空。

第四类面向企业级场景，来自 myceldigital/goal-prompt-architect，把 Goal Prompt 当作一份执行合约来设计，包含八个要素：mission（任务使命）、risk envelope（允许与禁止的操作边界）、grounded strategy search（基于事实的策略搜索）、evidence matrix（每一步产出什么证据）、memory loop（跨轮次状态持久化）、stop rules、verification oracle（验证来源）、persistent state（用于马拉松级任务的持久化状态）。这套模板适合无人值守 20 小时以上的任务，日常任务用不上全部要素。

中文社区（jimo.studio）的总结把有效 Goal Prompt 归纳成三层：Goal 描述层写可验证的交付物，粒度决定成败------可枚举、可验证、有边界；约束条件层用硬性约束（轮次/时间/token 预算）防止 Agent 在错误方向上无限循环；决策框架层定义 Agent 判断「做完了」的标准，这层最容易被忽视，也最影响结果。

四类模板语言不同、详略不同，骨架一致：目标、范围、验证方式、预算、停止条件。写 Goal Prompt 时把这五样补齐，就超过了大多数用法。

Stop Condition 决定成败

评估器只读取对话 transcript，它不能独立运行命令、不能打开文件。所以停止条件必须是 Agent 自己的输出能证明的东西。这一条限制直接划出了好条件和坏条件的分界线。

好条件的共同点：可枚举、可验证、有边界。

All tests in test/auth pass and npm test exits 0
git status is clean and no other test files are modified
Every call site in the module compiles with no errors
Lighthouse accessibility score is 90+
Playwright 截图与基线匹配

坏条件的共同点：主观、无终态、或者需要评估器看不到的证据。

Do your best on the refactor      # 无可测量的终态
Looks clean / seems right         # 主观判断，无法验证
Improve the code                  # 什么算 improve 没有定义
Make progress on X                # 没有终止条件
Keep working until it looks done  # 空洞

写完条件后做一个自检：能否描述 Agent 如何在 transcript 里证明完成？描述不出来就重写，写到能为止。判断公式压缩成一行：Stop Condition = 可枚举 + 可验证 + 有边界。

几个按场景写好的例子，可以直接改成自己的：

修复测试:   /goal fix every failing test until npm test exits 0 without modifying any file outside the /auth directory
数据库迁移: /goal migrate schema from v1 to v2 until migration parity is verified by comparing dev DB outputs
安全审查:   /goal review PR #42 for security issues until file-level auth, injection, XSS, and secret risks are called out
文档优化:   /goal rewrite README.md so a new contributor can install, run, test, and understand the project until each step has a working command and expected output
视觉迁移:   /goal migrate UI components to new design system, verified by Playwright screenshot parity checks

注意第一个例子里的 without modifying any file outside the /auth directory：把改动范围写进条件，评估器才能判断「测试通过」是修好的还是绕过的。

/goal、/loop、/schedule：怎么选

Claude Code 现在有三个自主类命令，对应三种驱动方式，按需求选：

命令	驱动方式	适合	不适合
/goal	条件驱动	有明确终态的任务：迁移/重构直到测试通过、修 Bug 到 CI 变绿	主观任务、需要人类判断的任务
/loop	时间驱动	每 N 分钟重复一次：迭代重构（轮间人工审查）、监控外部状态变化	需要保持 open session，关终端即停
/schedule	后台定时	每晚跑测试、每天早上 triage issues、每周清理死代码	--- 按固定节奏启动，独立于 open session

三个命令可以组合。社区公认的极限组合是 /goal + Auto mode + 运行测试套件的 script-based Stop hook：Agent 自主工作，每轮结束自动跑测试，通过则停、失败则重试，全程零人工介入。这是 Claude Code 目前最接近完全自主 coding agent 的用法。

三种典型失败与修复

jimo.studio 对失败模式做过系统分析，社区实战补充了细节。跑飞的 /goal 基本逃不出下面三种。

一、提前宣布完成（Confidence 上溢）。 Agent 在前几轮就给出 0.95 的信心值并宣布完成，实际只完成了三成。根因是 Goal 描述太模糊，Agent 的完成标准和用户期望对不上。修复办法：把 Stop Condition 改成可枚举、可验证的形式，用具体命令、测试结果、截图对比代替主观判断。

二、无限打磨（Infinite Polish Loop）。 Agent 每轮都在「优化」已完成的部分，始终不推进新内容。原因在于 Agent 缺乏全局视野，只能在当前范围内反复打磨。修复办法：加轮数/时间/token 预算，用 PLAN.md 做里程碑分解，让每轮有明确的目标。

三、阻塞不报告（Silent Blocker）。 Agent 遇到权限问题或依赖缺失时，选择尝试各种绕行方案而不报告，浪费大量轮次。修复办法：在 prompt 里写明 If-Then 的 blocker 策略------遇到真实阻塞时记录下来，转向其他可推进的子任务。

Anti-pattern 清单也值得贴在旁边自查：Make progress on X（没有可测量的终点）、Fix all issues 不带 issue 来源和验证器（无法验证完成）、Deploy everything 不指定环境（危险且无验证）、Use best judgment 不带护栏（对 secrets、blockers、脏 worktree 都没有保护）、Make no mistakes（Agent 不知道什么算 mistake，这是常见又最无效的一条）。

实战技巧

调研中反复出现的八条经验，按使用频率排序。

复杂任务先写 PLAN.md。Codex 的 /goal objective 有 4,000 字符硬限制，Claude Code 也建议控制在 500-1,200 字符。超过 3,500 字符的目标不要直接塞进命令，写到 PLAN.md 或 docs/goal.md 里，/goal 只引用这个文件。

先 /plan 再 /goal。让 Agent 先生成计划，人工审查修改后，再用 /goal 执行这份计划。社区实测能把迭代次数减半------Agent 不会在执行中途重新设计方案。

维护 progress.md 做审计追踪。让 Agent 执行过程中持续更新一个 progress.md：你得到可读的审计记录，Agent 得到跨轮次的持久化上下文。这直接解决了上下文压缩导致的状态丢失------长任务跑到后半段忘了自己做到哪，是最常见的翻车原因。

让模型自己写 Goal Prompt。把粗略想法丢给 Agent，让它生成包含成功标准的 /goal 命令。模型写的 goal prompt 往往比人写的好用，因为它清楚评估器到底能检查什么。

循环不收敛时，改条件而不是重试。token 在涨、工作没推进，说明评估器无法判断完成，继续跑只会烧钱。收紧成功条件，或者 /goal clear 掉重来，不要原样重试。

非交互式运行用于 CI/CD。claude -p "/goal CHANGELOG.md has an entry for every PR merged this week" 会让整个循环在一次调用里完成，适合接进 CI pipeline 和定时脚本。

长任务用上下文重置，不用压缩。Anthropic 观察到 Sonnet 4.5 存在「context anxiety」：接近上下文上限时提前收工。压缩历史（Compaction）解决不了这个行为，完全清空上下文再做结构化交接（Context Reset）可以。Opus 4.5 基本消除了该行为。

一次只跑一个 goal。Codex 和 Claude Code 都限制为单个活跃 goal，叠加多个会产生奇怪的状态。跑完用 /goal clear 清理，再启动下一个。

还要认清一条边界：UX 打磨、文案语气、设计品味这类任务没有可被验证器检查的信号，Agent 要么放弃、要么编造假停止条件。要么把它们改写成可测量的形式（比如 Lighthouse 90+），要么回到普通 prompt 加人工判断。

开源资源

• majiayu000/awesome-goal-prompts：300+ 可运行的 /goal 合约模板，覆盖迁移、修复、审查、原型场景。每个合约含 GOAL + CONTEXT + CONSTRAINTS + DONE WHEN + VERIFY + OUTPUT + STOP RULES，有可搜索的在线目录。
• myceldigital/goal-prompt-architect：企业级 /goal prompt 架构工具，把模糊任务转成执行合约，支持 Codex、Claude Code、Hermes。
• jaysu66/agent-system-methodology：通用 AI Agent 系统方法论，从约 100 小时的实战项目抽出。作者的实战数据：30+ 个 PR 自动合并、0 次错误合并、节省 90% 以上时间。
• BolasLien/skills（codex-goal-writer）：把粗略意图转成八段式 goal prompt 的生成 Skill，即上文模板 B 的来源。
• circuitstudioai/circuit-skills（goal-prompt-contract）：最小化 6 要素合约模板，Anti-gaming rule 的出处。
• kt-aicoding/skill-goal：面向 Codex 长任务的 /goal 生成器，超过 3,500 字符时自动转为文件引用。
• lokafinnsw/claude-code-goal-mode：Sprint→Epic→Task 层级计划树，三重预算（迭代次数 + token + 挂钟时间）。
• jakubkrcmar/codex-goal-skill：审查和改进现有 goal prompt，把里程碑密集型任务转成 PLAN.md-backed goals。

结语

这次调研的结论可以压成五句话。定义「完成」而不是「下一步」------这是 /goal 与普通 prompt 的全部区别。把干活的和验收的分开------独立评估器可以被调教成怀疑论者，Agent 自我批评不可能客观。好的 Goal Prompt 是一份可执行合约，有目标、范围、验证方式、预算、停止条件，五个要素缺一个就多一分跑飞的概率。长任务的瓶颈在上下文管理，代码生成排在其后------context anxiety、状态丢失、自我评估偏差，这些问题在数小时的自主运行里才是主要矛盾。以及，/goal 正在成为行业通用接口，值得现在就开始练怎么写。

下一步动作：挑一个仓库里现成的合约模板，改掉任务和验证命令，在自己的项目上跑一次有预算限制的 /goal，观察 token 消耗和轮数的关系------第一次跑通之后，后面的路都是复用。

参考

• Anthropic: Harness design for long-running application development
• labuladong《/goal 命令：给 Agent 设定目标》（底层实现逆向分析）
• jimo.studio《Goal Mode 的 Prompt 怎么写才有效》（失败模式分析）
• SOTA Sync《/goal 命令终极指南》、knightli.com《Codex Goal Deep Dive》、explainx.ai《Claude Code Loops Guide (2026)》等
• 调研日期 2026-08-17，覆盖 20+ 篇文章与 8+ 个 GitHub 仓库；功能迭代快，具体行为以官方文档为准