Agentic Research
首頁/學習/三層 Agent 協同框架:Hermes → OpenClaw → Claude Code 架構詳解

三層 Agent 協同框架:Hermes → OpenClaw → Claude Code 架構詳解

2026/05/096 分鐘Bryan Chan最後更新 2026/05/09
這篇屬於學習主題AgentArchitectureMulti-AgentHermes

先讀這些

這篇文章在學習路徑上假設你已經讀過下列內容。

什麼是三層 Agent 框架?

三層 Agent:通訊、編排、執行Agent 系統垂直分成三層,而分層的理由不是看起來整齊,是**三層的失敗模式與權限需求不同**。通訊層接收指令與回傳結果,它管的是「誰能跟我說話」,失敗模式是陌生人能下指令 —— 那一層的破口通常不是技術錯誤,而是允許名單沒設好。編排層理解任務、拆解、排程、分派,它管的是「誰去做這件事」,失敗模式是兩個 worker 改同一處而後寫的靜默蓋掉先寫的,或 lead 的上下文先爆掉。執行層真的動手:改檔案、跑指令、呼叫 API,它管的是「它能動到什麼」,失敗模式是不可逆的動作沒有閘門 —— 而這是唯一會真的弄壞東西的一層。混在一層時任何一個問題都會變成全部的問題,而且查不出是哪一層造成的;拆開之後每一層可以有自己的一道閘門:最上層是允許名單、中間是互斥的寫入範圍、最下層是權限模式。層與層之間傳下去的東西也應該被限定:從通訊層到編排層是一個已驗證身份的請求,從編排層到執行層是一個限定了範圍的任務。分三層,是因為三層的失敗模式與權限需求不同通訊層接收指令、回傳結果它管的是「誰能跟我說話」實例:飛書/Lark、WhatsApp、微信、Telegram、Slack 的接入與配對LAYER 1一個已驗證身份的請求編排層理解任務、拆解、排程、分派它管的是「誰去做這件事」實例:任務板、子 Agent 分派、技能與工具的選擇LAYER 2一個限定了範圍的任務執行層真的動手:改檔案、跑指令、呼叫 API它管的是「它能動到什麼」實例:程式碼生成與檔案編輯、shell 執行、Git 操作、沙箱LAYER 3通訊層失敗模式:陌生人能下指令。這一層的破口不是技術錯誤,是允許名單沒設好。1
1/5通訊層
它管「誰能跟我說話」
第 1 步,共 5 步 通訊層
圖:三層 Agent 架構。通訊層、編排層、執行層各負責什麼,以及一則訊息如何穿過三層。

當 AI Agent 的任務變得複雜時,單一 Agent 往往無法勝任。三層 Agent 框架將任務垂直分層,每一層專注不同的抽象級別:

┌─────────────────────────────────────────┐
│  Layer 1: Hermes Agent (通訊層)          │
│  ─ 管理所有外部通訊渠道                    │
│  ─ 飛書/Lark、WhatsApp、微信等             │
│  ─ 接收指令、分發任務、回傳結果             │
├─────────────────────────────────────────┤
│  Layer 2: OpenClaw (編排層)              │
│  ─ 任務理解、拆解、排程                    │
│  ─ 管理 Claude Code Bridge 技能           │
│  ─ Skills 與工具調用                      │
├─────────────────────────────────────────┤
│  Layer 3: Claude Code (執行層)           │
│  ─ 代碼生成、檔案編輯、Shell 執行           │
│  ─ Git 操作、專案管理                     │
│  ─ 由 ModelStudio / DeepSeek 驅動         │
└─────────────────────────────────────────┘

Layer 1:Hermes Agent(通訊層)

職責:作為系統的「耳朵和嘴巴」,管理所有對外通訊。

  • 接入飛書/Lark Bot,接收用戶的自然語言指令
  • 支援多渠道:WhatsApp、微信、Telegram 等
  • 將用戶意圖解析後傳遞給 OpenClaw
  • 把執行結果格式化回傳給用戶

為什麼需要獨立一層?

通訊邏輯(消息格式、Webhook、事件推送)和業務邏輯(任務執行)完全是兩種不同的關注點。分離後:

  • 換通訊平台不影響核心業務
  • Hermes 可以同時接入多個渠道
  • 用戶體驗統一,不管從哪個入口發指令,行為一致

Layer 2:OpenClaw(編排層)

職責:系統的「大腦」,負責理解任務、拆解步驟、協調資源。

  • 接收 Hermes 傳來的用戶意圖
  • 將複雜任務拆解為可執行的子任務
  • 管理 Skills(可復用的能力模塊)
  • 通過 Claude Code Bridge 調用 Claude Code 執行具體操作
  • 維護上下文記憶,跨任務關聯

關鍵技能:Claude Code Bridge

這是一個 OpenClaw 的插件/Skill,讓 OpenClaw 能夠直接操作 Claude Code:

User → Hermes → OpenClaw → [Claude Code Bridge] → Claude Code → 執行

橋接器封裝了 Claude Code 的 CLI 接口,讓 OpenClaw 能夠:

  • 啟動 Claude Code 會話
  • 傳遞任務描述
  • 讀取執行結果
  • 管理多個並行 Claude Code 實例

Layer 3:Claude Code(執行層)

職責:系統的「手」,實際操作文件系統、執行代碼。

  • 讀取和編輯代碼庫
  • 執行 Shell 命令
  • Git 操作(commit、branch、diff)
  • 由 LLM 驅動(ModelStudio / DeepSeek)

雙模型配置策略:

場景模型原因
日常編碼DeepSeek V3性價比高、推理強
複雜重構DeepSeek R1深度推理
長上下文ModelStudio (Qwen)阿里生態整合
備援兩者互為備份API 故障自動切換

通訊流程

一個完整的用戶請求流程:

  1. 用戶在飛書發送:「幫我檢查 OpenClaw 專案的最新 commit,看看有沒有 bug」
  2. Hermes Agent 接收消息,解析意圖 → "code review request for OpenClaw"
  3. Hermes 將任務傳給 OpenClaw
  4. OpenClaw 拆解為:
    • Step 1:通過 Claude Code Bridge 啟動 Claude Code
    • Step 2:git log 查看最近 commit
    • Step 3:git diff 檢查變更
    • Step 4:Claude Code 分析代碼
    • Step 5:生成 Review 報告
  5. OpenClaw 匯總結果,傳給 Hermes
  6. Hermes 格式化為飛書消息,回傳給用戶

設計原則

  1. 單一職責:每層只做一件事,做好一件事
  2. 鬆散耦合:層與層之間通過明確定義的接口通訊,可以獨立升級或替換
  3. 容錯隔離:某一層故障不影響其他層,例如 Claude Code API 限流時,OpenClaw 可以排隊重試
  4. 可觀測性:每層都有日誌輸出,方便排查問題

適用場景

  • 個人開發助手(自動化日常開發任務)
  • 團隊協作(多人通過飛書群組與 Agent 互動)
  • CI/CD 增強(Agent 參與代碼審查和部署決策)
  • 知識管理(Agent 自動整理文檔、生成報告)

在這條路徑上的下一步