别再把 /goal 当高级提示词：它正在变成 Agent 的通用任务协议

这两天看到一篇讲 /goal 的文章，我的第一反应不是“又多了一个新命令”。

而是：Agent 这套东西，开始有自己的通用原语了。

HTTP 是 Web 世界的原语。

JSON 是系统交换数据的原语。

而 /goal，很可能正在变成 Coding Agent 世界里的那个东西。

很多人第一次看到 /goal，会把它理解成“更高级的 prompt”。

这种理解不算错。

但如果只停在这里，就会低估它。

因为 /goal 真正改变的，不是你怎么写指令。

而是你和 Agent 的关系。

一、普通 prompt 和 /goal，差的不是格式

普通 prompt 的工作方式很熟悉：

你问一句。

Agent 回一句。

你判断对不对。

如果不对，你再推它一轮。

它再继续。

整个过程里，方向盘一直在你手里。

/goal 不一样。

它不是让你告诉 Agent“下一句该做什么”。

而是让你一次性告诉它：

这件事做完，应该是什么状态。

也就是 done state。

你写下目标、边界、约束和验收条件。

然后 Agent 持续朝着这个状态推进。

直到完成、暂停、阻塞、清除，或者耗尽预算。

这个变化听起来像小调整。

其实不是。

它把协作逻辑从“逐轮 prompting”，变成了“任务委派”。

以前你像在驾驶。

现在你更像在派活。

二、/goal 最重要的，不是谁先支持

文章里提到，已经开始接受 /goal 的，至少有三种工具：

• Codex
• Claude Code
• Hermes Agent

这三者不是一类东西。

Codex 更像 Builder。

它的优势是把规格变成代码，把东西做出来。

Claude Code 更像 Reviewer。

它更擅长找“看起来没问题，但其实有问题”的地方，比如规格偏差、异常分支、安全细节、边界条件。

Hermes Agent 则更像 Orchestrator。

它不是直接负责写代码，而是协调 Builder 和 Reviewer，把一个大任务拆开、分发、回收、再做最后验证。

这三个角色放在一起看，你会发现一个非常关键的事：

它们虽然不是同一类工具，却开始接受同一种任务表达方式。

这才是 /goal 真正值得重视的地方。

如果每个 Agent 都有自己的一套任务格式，那工具之间就很难真正协作。

但如果 Builder 能接 /goal，

Reviewer 也能接 /goal，

Orchestrator 还能把 /goal 在不同角色之间传递，

那就意味着 Agent 之间开始有了“共通语言”。

三、真正成熟的 Agent 工作流，一定是三角色闭环

这篇文章里有个判断我非常认同：

工具可以变，角色不会变。

一个成熟的 Agent 工作系统，至少有三种角色。

1. Orchestrator：总控者

负责拆任务、分配角色、记录状态、处理依赖、最后给用户汇报。

2. Builder：建设者

负责按 spec 把东西做出来。

3. Reviewer：审查者

负责看 Builder 交出来的结果到底靠不靠谱。

很多人现在用 Agent 的最大问题，是把这三种角色全塞在一个窗口里。

让同一个 Agent：

• 自己理解需求
• 自己动手实现
• 自己判断对不对
• 自己宣布完成

这当然很省事。

但风险也最大。

因为 Coding Agent 最大的问题，往往不是不会做。

而是它太容易自信地说自己做完了。

你让它写测试，它可能写了，但没跑。

你让它修 bug，它可能改了，但漏了异常路径。

你让它验收，它可能说“构建通过”，但实际上根本没执行构建命令。

所以，真正有用的不是“一个万能 Agent”。

而是 Builder、Reviewer、Orchestrator 三个角色，能围绕同一个目标形成闭环。

四、没有验证，/goal 只是更长一点的 prompt

这篇文章里我最想划重点的一句话，是这句：

不要相信 Worker 的自我汇报，要相信 Verifier。

这句话几乎可以当成 Agent 工作流里的铁律。

为什么？

因为 Agent 会非常自然地给出“像完成了”的答案。

它会说：

• 构建已经通过
• 测试已经通过
• 功能已经完成
• 规格已经满足

但很多时候，这些话只是叙述，不是证据。

真正让 /goal 从“好看的命令”变成“可靠的合同”的，不是它能长期运行。

而是它有没有独立验证。

也就是说：

• 构建要真的跑一遍
• 测试要真的执行
• 文件系统要真的检查
• Git 状态要真的确认
• 最终输出要真的验收

只有这样，/goal 才不是一句“我觉得做完了”。

而是一份“我能证明它做完了”的交付。

五、为什么说 /goal 更像原语，而不是功能

功能通常只在某个产品里有意义。

原语不一样。

原语的价值，是它能被不同系统同时采用，然后自然拼装起来。

/goal 正在往这个方向走。

因为它解决的不是“怎么提问更优雅”。

它解决的是：

如何用统一格式，把任务交给不同 Agent，并让它们围绕完成状态持续协作。

今天它能给 Codex。

明天它能给 Claude Code。

后天它能给 Hermes 这种编排器。

再往后，任何新的 Coding Agent，只要也支持 /goal，就可以被接进同一条流水线。

Worker 可以换。

Reviewer 可以换。

Orchestrator 也可以换。

但任务表达方式不需要换。

这就是原语真正厉害的地方：

系统会变，接口会留下来。

六、对普通用户来说，最该学的不是命令，而是任务表达

如果你只把 /goal 当作一个新语法，那你学到的是表面。

它真正逼你提升的，是另一件事：

你得开始学会怎么定义任务。

比如：

• done 到底是什么
• 边界写不写清
• 哪些动作能自动执行
• 哪些动作必须人工确认
• 验证方式是不是先定义好
• 任务交接有没有记录

这时候，Agent 的使用方式就会发生变化。

你不再是坐在终端前，一轮轮盯着它写。

你会开始像管理一个工作流：

你发出目标。

Builder 去做。

Reviewer 去看。

Orchestrator 去调度。

Verifier 去确认。

你只在关键节点介入。

这时，Agent 才真的从“会聊天”变成“会工作”。

最后

我越来越觉得，下一代 Agent 真正的竞争点，未必只是模型谁更聪明。

更重要的是：

谁先形成稳定的任务协议，谁先把 Builder、Reviewer、Orchestrator、Verifier 这些角色接成闭环。

/goal 现在看起来只是一个命令。

但再过一段时间，你可能会发现：

它不是命令。

它是 Agent 协作世界里的通用任务协议。

到那时候，你和 Agent 的关系，也会从“我在提示它”，变成“我在给它派活”。

这不是小修小补。

这是整个使用范式在换挡。