/goal 不是一个功能，它是一个原语。
HTTP 是一个原语。JSON 是一个原语。/goal 正在成为编码 Agent 的一个原语。
几周前，OpenAI 的 Codex CLI 增加了 /goal，用来给编码工作者分配一个带有明确完成状态的任务。Claude Code 本周也增加了它。
Hermes Agent（我在一台 Mac Mini 上运行的一个编排器，用于协调多个编码工作者之间的工作）早已内置了 /goal。
所以现在我有一个构建者、一个审查者，以及一个编排器，它们都接受相同的指令格式，尽管它们在其他方面毫无共同之处。
如果你只见过 /goal 被当作一个更花哨的提示词来用，那你还没有看到它带来的真正改变。
/goal 到底是什么
一个普通的提示词要求 Agent 给出下一个回复。你阅读返回的内容，判断是否正确，然后推动 Agent 进入下一步。你在每一个回合中掌舵。
/goal 则颠覆了这一点。你写清楚“完成”是什么样子，提交一次，然后 Agent 朝着这个目标一直工作，直到达成。这是一个真实的例子：
1/goal 构建 SPEC.md 中描述的应用。完成标准：测试通过，2构建通过，README 准确无误，git status 只显示3相关的项目文件。
这个目标会一直保持活跃，直到它被达成、暂停、阻塞、清除，或者预算耗尽。
这与在普通的单次命令中放入“goal”这个词不同。如果你写 codex exec 'goal: build the app'，那仍然只是一个带标签的提示词。真正的原语存在于一个交互式的工作会话中。你启动 CLI，提交 /goal，然后走开。
关键在于从“提示”（你驾驶）转变为“指派”（Agent 朝向你定义的目标自主驾驶）。
GIF
目前支持 /goal 的三个工具
这三个接受 /goal 的工具并不都是同一类事物，所以有必要具体说明一下。
Codex 是 OpenAI 的编码 CLI。它在实现方面很强，尤其是当给定一个清晰的规格时。/goal 就是你给它这个规格的方式。
Claude Code 是 Anthropic 的编码 CLI。它在相反的方向上很强：找出看起来正确的代码中存在的问题。规格符合性、安全问题、错误状态、安全漏洞。/goal 就是你用它指向代码并要求审查的方式。
Hermes Agent 则完全是一个不同类型的工具。它不是编码工作者，而是一个编排器，用于协调像上面两个那样的编码工作者之间的工作。/goal 是 Hermes 将任务交给合适工具的方式，也是我首先告诉 Hermes 我想要什么的方式。
重要的不是它们中的某一个推出了 /goal，而是三个不同的团队收敛到了同一个原语上，而这种收敛使得将它们组合起来成为可能。
GIF
环境设置
我第一次需要在运行 Hermes 的 Mac Mini 上安装 Codex 和 Claude Code 时，并没有手动安装。我向 Hermes 发送了一条消息，要求它安装两者并登录。它处理了剩下的步骤。
现在的工作流程就是这样。你不需要输入安装命令。设置只是另一个目标。
如果你还没有运行编排器，Codex 和 Claude Code 的安装页面很容易按照说明操作。但一旦你有了编排器，你就不应该再手动设置另一个工具了。拥有编排器的意义在于，机械性的工作不再属于你。
Hermes 在 /goal 之上增加了什么
裸的 /goal 本身就很有用。但它会给你留下一个协调问题。
如果 Codex 在一个终端中运行，而 Claude Code 在另一个终端中运行，你必须记住哪个进程在做什么。你必须检查日志。你必须手动将一个工具的审查结果传递给另一个工具。
Hermes 将这些松散运行变成了一个工作流：
- 你给 Hermes 发消息（在我的情况下，是通过手机上的 Telegram）
- Hermes 在一个 Kanban 项目上创建目标卡片
- Hermes 为每张卡片选择合适的工作者
- 工作者在后台运行目标
- 卡片存储了进程 ID、PID、仓库和完成标准
- 当构建准备好时，Hermes 将仓库交给审查者
- 如果审查阻塞，Hermes 将发现的问题作为修复目标发回
- Hermes 通过检查文件系统、测试、构建和 git 状态来验证最终输出
项目就是当 /goal 上面有一个编排器时所变成的样子。每个目标都有一张卡片，每张卡片都有一个状态，每次交接都留下一条轨迹。你不再需要在终端之间寻找，而是可以在手机上看着工作在各个列之间移动。
三个角色
工具会变化。但角色不会。
编排器。 控制循环的所有者。任务分解、工作者选择、Kanban 卡片、后台进程、依赖关系、最终验证、面向用户的摘要。在我的设置中，就是 Hermes。
构建者。 接收规格并产出可工作的代码。实现是这个角色要解决的瓶颈。Codex 在这方面往往很强。
审查者。 阅读构建者的产出并找出其中的问题。正确性是瓶颈。Claude Code 在这方面往往很强。
一个真实的运行过程，端到端
我给了 Hermes Agent 一个目标来做这件事：
1/goal 构建一个 CLI 工具，它能找到提及我的 X 内容，并在出现问题时通知我。
Hermes 将这个请求分解成了六张卡片。
Shubham Saboo
@Saboo_Shubham_
·
Codex /goal 构建它。
Claude Code /goal 审查并优化它。
Hermes /goal 管理编排和交接。
全部在一个单一的 Kanban 项目上跟踪，Agent 持续循环运行。
58
61
852
卡片 1：规格。 Hermes 自己编写了 SPEC.md，包含了技术栈、仓库路径、只读约束、模拟模式要求、测试和验证命令。由 PM 角色负责。
卡片 2：Codex 构建。 Codex 针对 SPEC.md 运行了 /goal。它创建了项目文件，实现了 UI 和后端，添加了测试，并使应用达到了通过状态。大约 15 分钟。完成后，npm test 通过，npm run build 通过，git status 只显示了相关的新文件。
卡片 3：Claude Code 审查。 Claude Code 运行 /goal 来审查 Codex 构建的内容。检查了规格符合性、只读安全、API 密钥处理、错误状态、测试、UI 实用性、漏洞和安全问题。结果：通过，无阻塞问题。
卡片 4：Codex 修复循环。 跳过，因为审查通过了。即使跳过，这张卡片仍然有意义。它表明 Hermes 可以模拟条件性工作。如果 Claude Code 阻塞了，Hermes 会将发现的问题作为新的 /goal 交回给 Codex。
卡片 5：Claude Code 最终验证。 同样原因跳过。
卡片 6：Hermes 最终摘要。 工作应用位于本地路径，UI 和 API 均在模拟模式下验证通过。Codex 使用 /goal 构建了它。Claude Code 使用 /goal 审查了它并返回了“通过”。
所有这一切都来自一条消息。三个不同的工具完成了实际工作，但我只与 Hermes 交流过。
验证规则
Hermes 从不信任 Codex 的自我报告。在 Codex 标记构建完成之后，Hermes 自己运行了命令：
1npm test # 17 个测试通过2npm run build # vite 构建通过
验证器才是将 /goal 从承诺转变为合约的关键。不要将工作者的自我报告当作最终结果。要信任验证器。
编码 Agent 很有自信。它们会告诉你构建通过了，即使构建从未运行过。它们会告诉你测试通过了，即使它们编写的测试从未执行过。验证器弥合了那个差距。
没有验证，/goal 只是一个更花哨的提示词。有了验证，它就成为了一个合约。
GIF
运行多个目标
你可以并行运行多个 /goal，但在没有仔细思考之前，不能将多个编码工作者指向同一个文件。
我的默认设置是每个仓库一个主要构建者。如果我想要并行，我会在清晰的边界上添加它。不同的仓库、不同的分支、git worktrees、独立的包、文档与代码、测试与实现。任何两个工作者不会相互踩踏的地方。
糟糕的模式是三个工作者都在同一个仓库中编辑同一个文件。你会遇到冲突、部分覆盖，以及一个工作者悄悄地撤销另一个工作者的工作。
更好的模式是任何给定文件一次只有一个写入者。构建者写入，审查者只读取，修复目标仅限于修复范围。或者让三个构建者在三个 worktrees 中分别针对三种竞争方案运行，然后让编排器选择最好的一个。
项目使得这一切变得实用。没有它，并行的后台工作者会变成终端的混乱。
对我来说改变了什么
这里有用的框架不是“我可以在后台运行 Agent”。
而是：一条消息变成了跨越三个不同编码工具的管道，而我看着整个过程在一个项目上移动。
你不再坐在终端前等待一个 Agent 完成，而是开始管理一个具有可见状态的工作队列。
如果 Codex 和 Claude Code 各自发明了自己的任务交接格式，那么没有任何编排器能够在它们之间路由。项目令人印象深刻，但原语使项目更加有用。
工作者可以改变，但原语保持不变。下一个采用 /goal 的编码工具将无需我做任何改动就能加入这个管道。我只需要将工作路由给它。
这就是好的原语的作用。
想要更多关于 Hermes、OpenClaw、Claude Code、Codex 及其他 24/7 Agent 团队的酷炫技巧和有趣想法吗？
关注 → @Saboo_Shubham_
