/goal 不是功能。是原语。
HTTP 是原语。JSON 是原语。/goal 正在成为 coding agent 的原语。
几周前，OpenAI 的 Codex CLI 添加了 /goal，作为给 coding worker 一个带定义完成状态的工作的方式。Claude Code 本周添加了它。Hermes Agent——作者在 Mac Mini 上运行来协调 coding worker 的 orchestrator——内置 /goal 已有一段时间。
现在作者有一个 builder、一个 reviewer 和一个 orchestrator，都接受相同的指令格式，尽管它们在其他方面毫无共同之处。
#/goal 改变了什么
如果你只见过 /goal 被当作更 fancy 的 prompt 使用，你错过了它改变的东西。
普通 prompt 要求 Agent 给出下一个响应。你读返回的内容，判断是否正确，然后推动 Agent 进入下一步。你在掌舵每一轮。
/goal 翻转了这一点。你写下"完成"是什么样，提交一次，Agent 朝着它工作直到达成。
/goal Build the app described in SPEC.md. Done means tests pass,
build passes, README is accurate, and git status only shows
relevant project files.
目标保持活跃直到达成、暂停、阻塞、清除或预算耗尽。
这与在正常 one-shot 命令里放"goal"这个词不同。如果你写 codex exec 'goal: build the app'，那仍然是一个有标签的 prompt。真正的原语活在交互式 worker session 内部。你启动 CLI，提交 /goal，然后走开。
转变是从 prompting（你驱动）到 assigning（Agent 向你定义的目标驱动）。
#三个工具，同一原语
三个接受 /goal 的工具不是同一种东西：
- Codex ：OpenAI 的 coding CLI。擅长实现，尤其是给定清晰 spec 时。/goal 是你给它那个 spec 的方式。
- Claude Code ：Anthropic 的 coding CLI。擅长反向操作：找出看起来正确但实则错误的代码中的问题。Spec 合规性、安全问题、错误状态、安全漏洞。/goal 是你指向代码并要求审查的方式。
- Hermes Agent ：完全不同的工具。不是 coding worker，而是协调上述两种 coding worker 的 orchestrator。/goal 是 Hermes 把任务交给合适工具的方式，也是作者告诉 Hermes 想要什么的方式。
重要的不是任何一个 ship 了 /goal。重要的是三个不同团队 converge 到同一原语 ，而这种 convergence 让它们可以组合。
#实战：一条消息，六张卡片
作者给 Hermes 发了一条消息：
/goal Build a CLI tool that finds X mentions of me and pings me when
something blows up.
Hermes 把请求拆成六张卡片：
Card 1: Spec — Hermes 自己写了 SPEC.md，捕获技术栈、repo 路径、只读约束、mock 模式需求、测试和验证命令。PM 角色拥有。
Card 2: Codex builds — Codex 对 SPEC.md 运行 /goal。创建项目文件，实现 UI 和 backend，添加测试，让 app 达到通过状态。约 15 分钟。完成时 npm test 通过，npm run build 通过，git status 只显示相关新文件。
Card 3: Claude Code reviews — Claude Code 运行 /goal 审查 Codex 构建的内容。检查 spec 合规性、只读安全性、API key 处理、错误状态、测试、UI 有用性、bug 和安全问题。结果：PASS，无阻塞问题。
Card 4: Codex fix loop — 跳过，因为审查通过。但卡片在跳过时仍然重要。它显示 Hermes 能建模条件工作。如果 Claude Code 阻塞了，Hermes 会把发现交回给 Codex 作为新 /goal。
Card 5: Claude Code final verification — 同样跳过。
Card 6: Hermes final summary — 工作 app 在本地路径，UI 和 API 都在 mock 模式下验证。Codex 用 /goal 构建。Claude Code 用 /goal 审查并返回 PASS。
所有这些都来自一条消息。 三个不同工具做了实际工作，但作者只和 Hermes 对话。
#Verifier：从 Promise 到 Contract
Hermes 从不信任 Codex 的自报告。Codex 标记构建完成后，Hermes 自己运行命令：
npm test # 17 tests passed
npm run build # vite build passed
Verifier 是让 /goal 成为 contract 而非 promise 的东西。 不要信任 worker 的自报告作为最终结论。信任 verifier。
Coding agent 很自信。它们会告诉你构建通过了，但构建根本没运行。会告诉你测试通过了，但测试从未执行。Verifier 关闭了这个 gap。
没有 verification，/goal 只是更 fancy 的 prompt。有了 verification，它变成 contract。
#并行与边界
可以并行运行多个 /goal，但不能让多个 coding worker 指向同一文件而不先思考。
作者的默认是每个 repo 一个主 builder 。想要并行时，在清晰边界上添加：不同 repo、不同分支、git worktree、分离的 package、docs vs code、tests vs implementation。任何两个 worker 不会踩到对方的地方。
坏模式：三个 worker 在同一 repo 的同一文件上编辑。你会得到冲突、部分覆盖、一个 worker 默默 undo 另一个的工作。
更好模式：任何给定文件一次只有一个 writer。Builder 写，reviewer 只读，fix goal 限定在修复范围内。或者在三个 worktree 上跑三个 builder 做三种竞争方案，让 orchestrator 选最优。
Board 让这变得实用。没有它，并行后台 worker 变成终端混乱。
#核心洞察
有用的 framing 不是"我可以在后台运行 Agent"。
而是一条消息变成跨三个不同 coding 工具的 pipeline，作者看着整个东西在一张 board 上移动。
你不再坐在终端等一个 Agent 完成，而是开始管理一个有可见状态的工作队列。
如果 Codex 和 Claude Code 各自发明了自己的 job-handoff 格式，没有 orchestrator 能在它们之间路由。Board 令人印象深刻，但原语让 board 更有用。
Worker 可以变，但原语保持不变。 下一个采用 /goal 的 coding 工具将无需作者改变任何东西就加入这个 pipeline。作者只需把工作路由给它。
这就是好原语的作用。