# 策展 · X (Twitter) 🔥🔥🔥

> 作者：Shubham Saboo (@Saboo_Shubham_) · 平台：X (Twitter) · 日期：2026-05-15

> 原始來源：https://x.com/Saboo_Shubham_/status/2054988166541770782

## 中文摘要

# /goal 的終極指南

/goal 並不是一個功能，它是一個 primitive（基礎原語）。

HTTP 是一個 primitive，JSON 也是一個 primitive。而對於 Agentic 程式開發來說，/goal 正逐漸成為其中之一。

幾週前，OpenAI 的 Codex CLI 加入了 /goal，作為一種賦予程式開發 Agent 具備明確「完成狀態」任務的方式。本週，Claude Code 也加入了這項功能。

Hermes Agent 是我在 Mac Mini 上運行的 orchestrator，用於協調各個程式開發 Agent 之間的工作，它內建 /goal 已經有一段時間了。

因此，我現在擁有一個 builder（建構者）、一個 reviewer（審查者）和一個 orchestrator（協調者），儘管它們之間沒有共享任何東西，但它們都接受相同的指令格式。

如果你只把 /goal 當成一種更花俏的 Prompt，那你其實錯過了它所帶來的改變。

## /goal 的實際定義

一般的 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.
```

這個目標會保持啟用狀態，直到它被達成、暫停、阻擋、清除，或是預算耗盡為止。

這與在一般的單次指令中放入「goal」這個詞是不同的。如果你寫 `codex exec 'goal: build the app'`，那仍然只是一個帶有標籤的 Prompt。真正的 primitive 存在於互動式的 Agent 工作階段中。你啟動 CLI，提交 /goal，然後就可以離開了。

這種轉變是從「提示」（由你驅動）轉變為「指派」（由 Agent 朝著你定義的目標驅動）。

## 目前支援 /goal 的三種工具

這三種接受 /goal 的工具性質並不完全相同，因此有必要具體說明：

Codex 是 OpenAI 的程式開發 CLI。它在實作方面很強大，特別是在給予明確規格的情況下。/goal 就是你提供該規格的方式。

Claude Code 是 Anthropic 的程式開發 CLI。它擅長相反的工作：找出看起來沒問題的程式碼中隱藏的錯誤。例如規格合規性、安全性問題、錯誤狀態、安全漏洞等。/goal 就是你將它指向程式碼並要求進行審查的方式。

Hermes Agent 則是完全不同類型的工具。它不是程式開發 Agent，而是一個協調者，負責在上述那類程式開發 Agent 之間協調工作。/goal 是 Hermes 將任務移交給合適工具的方式，也是我告訴 Hermes 我想要什麼的方式。

重點不在於它們之中哪一個率先推出了 /goal，而在於三個不同的團隊都匯聚到了同一個 primitive 上，而這種匯聚正是實現它們相互組合的關鍵。

## 進行設定

當我第一次需要在運行 Hermes 的 Mac Mini 上使用 Codex 和 Claude Code 時，我並沒有手動安裝它們。我發送了一則訊息給 Hermes，要求它安裝這兩者並幫我登入。剩下的工作它都處理好了。

這就是現在的工作流程。你不需要輸入安裝指令，設定只是另一個目標（goal）而已。

如果你還沒有運行 orchestrator，Codex 和 Claude Code 的安裝頁面都很容易跟隨操作。但一旦你有了 orchestrator，就不應該再手動設定其他工具。擁有 orchestrator 的意義在於，機械性的工作不再需要由你來完成。

## Hermes 在 /goal 之上增加了什麼

單獨的 /goal 本身很有用，但它會讓你面臨協調問題。

如果 Codex 在一個終端機運行，而 Claude Code 在另一個終端機運行，你必須記住哪個程序在做什麼。你必須檢查日誌，還必須手動將審查結果從一個工具傳遞到另一個工具。

Hermes 將這些鬆散的運行轉化為一個工作流程：

1. 你傳送訊息給 Hermes（以我為例，是透過手機上的 Telegram）

1. Hermes 在 Kanban 看板上建立目標卡片

1. Hermes 為每張卡片挑選合適的 Agent

1. Agent 在背景運行該目標

1. 卡片儲存了程序 ID (PID)、儲存庫 (repo) 和完成標準

1. 當建構完成時，Hermes 將儲存庫交給審查者

1. 如果審查被阻擋，Hermes 會將發現的問題作為一個「修復目標」發送回去

1. Hermes 透過檢查檔案系統、測試、建構和 git 狀態來驗證最終輸出

當上方有 orchestrator 時，看板就是 /goal 的呈現形式。每個目標都有卡片，每張卡片都有狀態，每一次移交都會留下軌跡。你不需要在終端機之間來回搜尋，而是可以在手機上觀察工作在各個欄位間移動。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778806977681-iaHIQqlimawAAuWOjpng.png)

## 三種角色

工具會變，但角色不會。

Orchestrator（協調者）：擁有控制迴圈。負責任務分解、Agent 選擇、Kanban 卡片、背景程序、依賴關係、最終驗證以及使用者導向的摘要。在我的設定中，就是 Hermes。

Builder（建構者）：接收規格並產出可運行的程式碼。實作是此角色解決的瓶頸。Codex 在這方面通常很強。

Reviewer（審查者）：閱讀建構者產出的內容並找出其中的錯誤。正確性是此角色解決的瓶頸。Claude Code 在這方面通常很強。

## 實際的端到端運行範例

我給 Hermes Agent 設定了一個目標：

```
/goal Build a CLI tool that finds X mentions of me and pings me when 
something blows up.
```

Hermes 將請求拆解為六張卡片。

卡片 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 實用性、Bug 和安全問題。結果：通過 (PASS)，沒有阻礙性問題。

卡片 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 親自執行了指令：

```bash
npm test         # 17 tests passed
npm run build    # vite build passed
```

驗證者是讓 /goal 成為合約而非承諾的關鍵。不要將 Agent 的自我報告視為最終結果，要信任驗證者。

程式開發 Agent 充滿自信。它們會告訴你建構已通過，即使建構根本沒運行過；它們會告訴你測試已通過，即使它們寫的測試根本沒執行。驗證者填補了這個落差。

沒有驗證，/goal 只是更花俏的 Prompt；有了驗證，它就成為了一份合約。

## 運行多個目標

你可以並行運行多個 /goal，但在沒有經過深思熟慮的情況下，不能讓多個程式開發 Agent 指向相同的檔案。

我的預設是每個儲存庫一個主要的 Builder。如果我需要並行處理，我會透過明確的界線來增加。例如不同的儲存庫、不同的分支、git worktrees、獨立的套件、文件與程式碼分離、測試與實作分離。只要是兩個 Agent 不會互相干擾的地方都可以。

糟糕的模式是三個 Agent 在同一個儲存庫中編輯同一個檔案。這會導致衝突、部分覆寫，以及一個 Agent 在不知情的情況下撤銷了另一個 Agent 的工作。

更好的模式是任何給定檔案一次只有一個寫入者。Builder 負責寫入，Reviewer 只負責讀取，修復目標則保持在修復範圍內。或者，在三個不同的 worktrees 中運行三個 Builder，針對三種競爭方案進行開發，然後讓 orchestrator 選擇最好的一個。

看板是讓這一切變得實用的關鍵。沒有它，並行的背景 Agent 只會變成終端機裡的混亂。

## 對我的改變

這裡有用的框架並不是「我可以在背景運行 Agent」。

而是「一則訊息轉化為跨越三種不同程式開發工具的管線」，而我只需觀察整個過程在一個看板上移動。

你不再需要坐在終端機前等待 Agent 完成工作，而是開始管理一個具有可視化狀態的工作佇列。

如果 Codex 和 Claude Code 各自發明了自己的任務移交格式，就沒有 orchestrator 能夠在它們之間進行路由。看板固然令人印象深刻，但 primitive 讓看板變得更有用。

Agent 可以更換，但 primitive 保持不變。下一個採用 /goal 的程式開發工具將會加入這個管線，而我不需要改變任何東西。我只需要將工作路由給它即可。

這就是優秀 primitive 的作用。

---

想了解更多關於 Hermes、OpenClaw、Claude Code、Codex 和其他 24/7 Agent 團隊的酷炫技巧與有趣想法，請追蹤：

追蹤 → @Saboo_Shubham_

## 標籤

Agent, CLI, 功能更新, Claude Code, Codex, OpenAI, Anthropic, Claude