1 Month with Hermes: 重新定義 Builder 與 Operator

原始來源與檔名：1-Month-with-Hermes-重新定義Builder與Operator.md

來源：[[@0xJeff]] / X — 2026-04-28 原始檔名：2026-04-28T092517+0800-1 Month with Hermes - I’ve been using Hermes wrong all along.md

NAPKIN | 餐巾纸

餐巾紙公式

Agent 協作流 = Claude 作為 Builder (一次性建構) + Hermes 作為 Operator (持續性營運與記憶)

作者在使用 Hermes 一個月後領悟到：不要讓 Hermes 負責寫扣建置產品（那太慢且介面醜），應該讓 Claude 負責一次性的「建置 (Builder)」，而具備跨會話記憶和自我學習能力的 Hermes 則負責持續性的「營運與分析 (Operator)」。

一句話

讓聰明但健忘的 Claude 幫你蓋房子，讓記得住細節的 Hermes 幫你當管家。

餐巾紙草圖

[Human Orchestrator]
       |
       +---> (Builder) Claude: 快速生成 Dashboard / UI 代碼 (無狀態，高智商)
       |
       +---> (Operator) Hermes: 定期監控資料、產出報告、自我學習 (有狀態，強記憶)

ROUND 1: SKELETON | 骨架掃描

“這本書在說什麼”

章節骨架

  1. 一個月的 Hermes 除錯血淚史: 初期配置、任務指派、最終領悟。
  2. 角色重定義: Claude 是 Builder（適合一次性構建），Hermes 是 Operator（適合需要記憶的持續性任務）。
  3. PolyBond 案例: 個人預測市場儀表板。Claude 負責 10 倍速的 UI 建置，Hermes 負責每天的訊號掃描與摘要回報。
  4. 經驗總結: 人類必須主導方向（Steer the AI），用 AI 來增強學習，而非反客為主。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

異質 Agent 團隊的架構分工 (Architectural Deep Dive)

前言/背景

隨著多種 Agent 框架的湧現，使用者在實踐中發現了各框架的特性偏誤。這篇實踐反思明確指出了無狀態模型（Stateless, 如 Claude UI）與具備狀態/記憶模型（Stateful, 如 Hermes）在工程實踐中的職責劃分（Separation of Concerns）。

章節詳細總結

1. 架構師的反思：從「全能」到「職責分離」

作者初期試圖將所有任務（包括建置與營運）交給 Hermes，導致了極低的效率。核心洞見是：Hermes 的強項在於其「跨對話記憶（Persistent Memory）」與「自我學習迴圈（Self-learning loop）」，這使其在持續性的任務（Cron Jobs、日報生成）中表現優異。

2. Builder vs. Operator 模式

3. 系統整合實踐 (Integration Practice)

在實際專案中，人類擔任 Product Manager/System Architect。先呼叫 Claude 產出包含多資料源串接的 Dashboard，隨後配置 Hermes 讀取這些資料源，根據使用者的偏好（偏好已寫入 Hermes 的記憶中）產出高訊號低噪音的預測報告。

總結與結論