# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

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

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

## 中文摘要

# 使用 Hermes 執行免費本地 Agentic 程式開發的終極指南

有了 Hermes 作為排程器，本地程式開發 Agent 終於能為我所用了。這並非因為模型變強了，而是因為我不再要求它們扮演 Claude Code 的角色。

現在，免費的本地模型負責處理瑣碎的工作，而我只在真正需要時才花錢呼叫 Claude 和 Codex 的 token。

如果你想透過 Hermes 執行免費的本地程式開發 Agent，這就是你的設定方式。

Hermes Agent 負責分配工作。Kanban 負責追蹤狀態。SmallCode 透過 Ollama 在 Mac Mini 上本地執行。Claude Code 和 Codex 則負責審核困難的部分。

這個本地程式開發 Agent 只有一個任務：完成卡片。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779637724683-iaHI8OdTlaAAEUhlIjpg.jpg)

## 錯誤的問題

人們預設會問的問題是：「這個本地 Agent 能取代 Claude Code 或 Codex 嗎？」

這就是陷阱所在。這個問題強迫你對一個沒有「是」或「否」答案的事物給出二分法的結論。一個運行在 7B 模型上的本地 Agent 並不是要成為 Claude Code。它做不到。它沒有背後的模型支援、推理深度或足夠的 context window。

但如果你不再要求它表現得像個資深工程師，它確實能完成相當多實際工作。更好的問題是：如果任務很小、context 很緊湊，且有更強大的 Agent 審核結果，那麼本地 Agent 可以可靠地完成哪些工作？

這個問題有真正的答案，而且比你想像的還要多。

## 每個 Agent 只做一件事

這與我經營 OpenClaw 團隊的原則相同。每個 Agent 都擅長做一件事，而 Hermes Agent 現在位於該團隊之上，以 Monica 分配內容工作的方式來分配程式開發工作。

本地 Agent 不是資深工程師。它是一個快速、便宜、隱私性高且擅長處理狹窄任務的初階開發者。一旦我開始這樣對待它，一切就都順理成章了。

## 技術堆疊

Hermes Agent 是排程器。它掌控對話、理解意圖，並將工作分解為卡片。

Hermes Kanban 是任務匯流排。每一項工作都存在於看板上，包含狀態、範圍、驗收標準和證據。

SmallCode 是本地程式開發 Agent。它在 Mac Mini 上運行，可以使用任何你透過 Ollama 提供的模型，無論是 7B 程式碼模型、14B 還是你的機器能負載的任何模型。它負責處理範圍明確的修補程式、測試修復、Lint 清理、文件撰寫和機械式的重構。

Claude Code 和 Codex 負責處理困難的部分。架構決策、模糊的 Bug、跨檔案推理以及最終審核。

上圖展示了實際運作的情況。當 Telegram 收到提示詞時，Hermes 會將其分解。簡單的卡片會分配給 Mac Mini 上的 SmallCode。困難的卡片則分配給 Claude Code 或 Codex。看板會追蹤一切，沒有任何資訊會消失在終端機的歷史紀錄中。

讓這一切變得有用的關鍵是看板，而不是本地 Agent 本身。

## 為什麼本地 Agent 通常會失敗

使用本地程式開發 Agent 的預設方式是打開終端機、執行它、給它一個提示詞，然後看看會發生什麼。

有時它會成功，但通常不會。Agent 在長對話中會丟失 context，編輯超出預期範圍的檔案，產生看起來合理但會導致測試失敗的修補程式，忘記對話早期的限制，甚至混淆「我執行了指令」與「指令執行成功」之間的差別。

部分原因是模型本身。與 Claude 或 GPT 相比，7B 程式碼模型確實有其極限：推理深度較淺、context window 較小、工具呼叫能力較弱。

但很大一部分原因是工作描述的問題。

要求一個小型模型端到端地負責一個模糊的功能，它肯定會失敗。但如果要求同一個模型在一個檔案中修復一個失敗的測試，並提供一個明確的測試指令，它很可能會完成。模型並沒有變聰明，只是工作變小了。

小工作、明確的驗收標準、容易驗證。

這就是它的生存之道。

## 我不執行工作流程，Hermes 才是

當人們聽到「Agent 排程」時，大多數人會忽略這一點。他們想像自己坐在鍵盤前，分配任務、檢查輸出、在欄位間移動卡片。這不是我的設定方式。

我透過 Telegram 發送提示詞給 Hermes，由 Hermes 決定要做什麼。

如果提示詞是「清理此儲存庫中的 email 輔助函式」，Hermes 會建立卡片、指派任務、觀察 Mac Mini 上的 SmallCode 執行情況、讀取結果、要求 Claude Code 進行審核。如果審核失敗，它會建立後續卡片。看板會記錄每次執行的完整歷史。

如果 SmallCode 連續三次嚴重失敗，斷路器就會觸發，卡片會移至「已封鎖」狀態，Hermes 會在 Telegram 上通知我。我不必隨時盯著它看。

如果工作本身對 SmallCode 來說太過模糊，Hermes 會直接將其分配給 Claude Code 或 Codex。決策是在接收階段做出的，而不是在嘗試失敗後才做出。

我不是調度員，我是定義目標的人。Hermes 則是確保目標達成的人。

## 將路由規則放入檔案中

路由邏輯不在我的腦海裡，而是存在於 Hermes 工作的每個儲存庫根目錄下的 `AGENTS.md` 檔案中。

```markdown
# Agent 路由規則

Hermes 是排程器。
使用 Kanban 追蹤程式開發工作。

使用 SmallCode 處理：
- 小型修補程式
- 測試修復
- Lint 清理
- 程式碼附近的文件
- 機械式重構
- 應用審核意見

使用 Claude Code 或 Codex 處理：
- 架構決策
- 模糊的 Bug
- 跨檔案推理
- 高風險變更
- SmallCode 輸出的最終審核

每張程式開發卡片必須包含：
- 目標
- 檔案或模組範圍
- 限制條件
- 測試指令
- 驗收標準
- 預期證據

在測試和審核通過之前，不要將 SmallCode 的輸出視為最終版本。
```

Hermes 每次對話都會讀取這個檔案。路由會自動發生。我不必每次打開 Telegram 時都重新解釋我的操作模式。

這與我在 OpenClaw 團隊中使用的模式相同：`SOUL.md` 定義身份，`AGENTS.md` 定義規則，記憶檔案確保連續性。Agent 啟動時就已經知道工作該如何推進。

## Kanban 看板是不可妥協的

沒有看板，Agent 的執行結果就會消失在終端機歷史中。有了看板，每個任務都有負責人、狀態、範圍、驗收標準、測試指令、執行歷史、審核筆記和最終證據。

看板為 Hermes 提供了持久的佇列。任務在重啟後依然存在，執行歷史在 context 重置後依然保留。當 SmallCode 在審核封鎖後重試一張卡片時，第二次嘗試會看到第一次嘗試的發現並直接解決它們，無需從頭開始。

這就是小型 Agent 有用的原因。它們不需要理解整個公司的路線圖，它們只需要完成一張卡片。

## 卡片越小越好

Hermes 將我的提示詞分解為卡片。分解的品質決定了 SmallCode 是否能完成工作。

糟糕的卡片看起來像：「清理儲存庫」。

好的卡片看起來像：「從 `src/utils/email.ts` 中移除未使用的輔助函式，不要更改公開行為，編輯後執行 `npm test`，並回傳差異摘要和測試結果。」

我不會寫第二個版本，Hermes 會寫。但 Hermes 只有在我的提示詞包含足夠 context 時才能寫出好的卡片。「清理 auth 模組中的 email 輔助函式」能讓 Hermes 產生四到五張範圍明確的卡片。「讓程式碼庫變得更好」則無法給 Hermes 任何有用的資訊，只會產生 SmallCode 無法處理的模糊卡片。

卡片就是規格書。為 Hermes 撰寫更好的提示詞，與為任何 Agent 撰寫更好的提示詞遵循相同的紀律。上游的工作決定了下游工作的成敗。

## 根據任務類型進行路由

問題不在於哪個 Agent 最聰明，而在於哪個工作者適合這張卡片。

當任務範圍狹窄、重複性高、風險低、易於驗證、主要是機械式且僅限於少數檔案時，就交給 SmallCode。

當任務模糊、涉及架構、高風險、跨儲存庫、依賴深度推理且難以自動驗證時，就交給 Claude Code 或 Codex。

Hermes 根據 `AGENTS.md` 規則和卡片的形態做出決定。如果卡片處於中間地帶，Hermes 會在 Telegram 上詢問我。決策發生在工作開始前，而不是在嘗試失敗後。

## 審核是強制性的

SmallCode 的輸出預設永遠不是最終版本。循環如下：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779637724688-diaHI8OymyaUAAfqOjpg.jpg)

Hermes 會在沒有我參與的情況下執行此循環。當 SmallCode 將卡片標記為完成時，審核卡片就會立即建立。如果審核通過，卡片就會移至「已完成」。如果審核封鎖，Hermes 會建立一個包含具體回饋的後續卡片，並將其路由回 SmallCode。重試時，它會在 context 中看到封鎖原因。

這就是將本地 Agent 從高風險的自主工作者轉變為受監督工作者的關鍵。

一個在監督下能完成 20% 到 30% 瑣碎儲存庫任務的本地 Agent 已經很有用了。特別是如果替代方案是這些任務永遠沒人做：沒人寫的測試覆蓋率、沒人移除的無用程式碼、沒人更新的文件。

SmallCode 不需要擊敗 Claude Code。它需要讓團隊成本更低、速度更快，並且不再被那些沒人想做的瑣碎工作所阻礙。

## 我最初犯的錯誤

要求 SmallCode 負責整個功能。它做不到。給它一個檔案、一個修補程式、一個測試指令。

跳過審核。SmallCode 的輸出是草稿，不是合併候選。Hermes 現在強制執行這一點。

在看板之外執行 Agent。如果工作沒有在 Kanban 上追蹤，它就不存在。看板是真相的唯一來源。

從高風險的生產環境工作開始。從測試、文件、清理、低風險修復開始。在提高賭注之前先建立直覺。

把 SmallCode 當作比較差的 Claude Code。它不是 Claude Code。它是一個工作者。工作不同，期望也不同。

## 轉變

本地程式開發 Agent 的未來不是由一個本地 Agent 取代 Claude Code。

而是編排（Orchestration）。Hermes 分配工作，Kanban 追蹤狀態，SmallCode 執行範圍明確的本地任務，Claude Code 和 Codex 審核困難的部分。在需要做出決策之前，我都不會介入。

當你不再期望它們成為資深工程師，而是開始將它們視為擁有狹窄工作描述的團隊成員時，本地 Agent 就變得有用了。

不是要一個更好的本地 Agent，而是要為本地 Agent 安排更好的工作。

從一個儲存庫、一個看板、一張小卡片開始。看看當你給予本地 Agent 它能完成的工作時，它到底能做些什麼。

## 標籤

Agent, 教學資源, 開源專案, LLM, Hermes, Claude, Codex, Ollama