/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 上找到提及我的內容，並在2出問題時通知我。
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_
