核心發現

  • 多代理系統相較單一代理可處理複雜度高出 3–5 倍的任務，同時透過平行化執行將總延遲壓低 40–60%
  • OpenClaw Agent Teams 支援三種協作模式：協調者模式（Orchestrator）、點對點模式（Peer-to-Peer）與階層式模式（Hierarchical），可依任務性質靈活組合
  • 子代理之間透過結構化訊息傳遞、共享記憶體與事件佇列三種機制協作，每種機制有其適用的任務類型與成本特性
  • 正確的角色分工設計與模型選配（以輕量模型執行路由、以高階模型執行推理）可降低整體 Token 成本達 35%
  • 與 AutoGen、CrewAI、LangGraph 相比，OpenClaw Agent Teams 以 YAML 宣告式設定為核心優勢，入門門檻最低，但在動態工作流程的靈活性上仍有改進空間

2026 年 2 月，OpenClaw 在六十天內從 9,000 顆 GitHub 星增長至 157,000 顆，成為開源 AI 代理領域最受矚目的專案之一。[10] 這波成長的背後，不僅是單一代理能力的突破，更是多代理協作架構（Multi-Agent Architecture）的成熟——讓開發者得以組建 AI 代理「團隊」，共同完成原本單一代理難以駕馭的複雜任務。[2]

本文是 OpenClaw 系列的第四篇，聚焦於 Agent Teams 的完整技術架構。我們將從單一代理的根本限制出發，逐步拆解 OpenClaw 多代理系統的設計邏輯、通訊協定與任務委派模式，並提供兩個可直接上手的實戰案例：研究團隊多代理協作系統，以及開發流水線中的代碼審查代理團隊。最後，我們將對比市面上主流多代理框架，協助讀者做出更明智的技術選型。

一、為什麼需要多代理系統

在深入 OpenClaw 的技術細節之前，有必要先釐清：什麼樣的任務真正需要多代理系統？並非所有問題都值得引入多代理的複雜度。

1.1 任務複雜度的本質差異

人類組建團隊，是因為某些問題本身就是多維度的——需要法律、財務、技術三種專業同時介入，而非依序排列。AI 代理面臨同樣的挑戰。當一項任務要求代理同時具備網路爬取、資料分析、自然語言生成與程式執行能力時，單一代理不論 context window 多大、模型多強，都會面臨認知超載的問題。

Gartner 2025 年報告指出，AI 代理生態系統（Agent Ecosystems）將是 2026 年最重要的策略技術趨勢之一，其核心驅動力正是多代理協作架構讓組織得以將複雜工作流程自動化的能力。[7]

1.2 可平行化的工作是關鍵訊號

判斷是否需要多代理系統，最簡單的問題是：「這個任務中，哪些子任務可以同時進行？」

舉例來說，撰寫一份競爭對手分析報告，需要：（A）爬取各競爭對手官網與新聞；（B）分析財務數據；（C）整理產品功能比較；（D）彙整用戶評論。這四項工作在邏輯上相互獨立，完全可以並行執行。若由單一代理依序完成，假設每項需 5 分鐘，總計需 20 分鐘；若由四個子代理同步執行，理論上僅需 5 分鐘，加上協調開銷約 6–7 分鐘，效率提升超過三倍。

1.3 專業化分工提升輸出品質

學術研究顯示，在多代理系統中為每個代理設定明確的角色定義（role specification），能顯著提升任務完成品質。MetaGPT 的研究發現，賦予代理「產品經理」、「工程師」、「測試員」等明確角色，並讓其依照對應的 SOP 運作，可以使代碼生成任務的品質媲美人類工程師團隊。[4]

OpenClaw Agent Teams 將這一洞見落實在架構層面：每個子代理（Subagent）不僅有獨立的系統提示（system prompt），還可以綁定特定的技能（Skills）集合與模型選擇，使「專業化」落地為可配置的技術參數。[1]

二、單一代理的瓶頸與擴展需求

理解多代理的價值，必須先誠實面對單一代理的天花板。

2.1 Context Window 的物理限制

即便是 Claude 3.5 Sonnet 或 GPT-4o 這樣的高階模型，context window 也有其上限（通常為 128K 至 200K tokens）。對於需要同時持有大量上下文的任務——例如分析十萬行代碼庫、整合三百份研究論文——單一代理在物理上無法將所有資訊納入單次推理。

多代理系統的解法是分散式記憶體：每個子代理只需維護其職責範圍內的上下文，由協調代理（Orchestrator）負責跨代理的知識整合。這樣，即便整體任務所需的上下文遠超任何單一模型的限制，系統仍能有效運作。

2.2 任務複雜度天花板

單一代理在處理高度複雜任務時，常見的失敗模式包括：

多代理架構透過「關注點分離」（Separation of Concerns）緩解這些問題：每個代理只需在有限的任務範圍內保持高品質輸出，錯誤的影響範圍也被限制在子任務層級，不會蔓延至整個工作流程。

2.3 延遲與成本的不對稱性

單一代理的執行延遲是所有子任務的總和；而多代理系統中，可平行化的子任務能夠同步執行，將延遲壓縮至最長子任務的時間加上協調開銷。

成本方面的邏輯則更為精妙：並非所有子任務都需要最昂貴的模型。若能為簡單的路由決策使用 GPT-4o-mini，為複雜的分析推理使用 Claude Opus，整體成本可降低 35–50%，同時維持關鍵任務的輸出品質。[5]

2.4 維護性與可擴展性

從工程角度看，單一代理的系統提示往往隨任務複雜度增長而膨脹，最終演變為難以維護的「提示義大利麵」（Prompt Spaghetti）。多代理架構強制要求開發者將能力模組化，每個代理的系統提示保持精簡聚焦，整體系統的可讀性、可測試性與可維護性大幅提升。

三、OpenClaw Agent Teams 架構設計

OpenClaw 的多代理系統建立在 Gateway 架構之上，以 YAML 宣告式配置為核心，支援三種基本的代理協作模式。[9]

3.1 基礎架構概覽

一個 OpenClaw Agent Team 由以下核心元件構成：

以下是一個基本的 Agent Team 配置結構：

# openclaw-team.yaml
name: research-team
version: "1.0"

agents:
  coordinator:
    model: claude-3-5-sonnet
    system: |
      你是研究協調代理，負責分解任務並委派給專業子代理。
      在收到研究請求後，分析所需的子任務並並行委派。
      收到所有子代理的回覆後，整合輸出一份連貫的報告。
    skills:
      - task-delegation
      - report-synthesis
    subagents:
      - web-scraper
      - data-analyst
      - report-writer

  web-scraper:
    model: gpt-4o-mini
    system: |
      你是網路資訊收集代理，專精於從網頁提取結構化資訊。
      接收搜尋指令後，返回格式化的原始資料，不進行分析。
    skills:
      - web-search
      - html-parser
    timeout: 30s

  data-analyst:
    model: claude-3-5-sonnet
    system: |
      你是資料分析代理，負責從原始資料中萃取洞見。
      只進行分析，不進行資料收集或報告撰寫。
    skills:
      - data-analysis
      - chart-generation

  report-writer:
    model: claude-3-opus
    system: |
      你是專業報告撰寫代理，負責將分析結果轉化為清晰的書面報告。
      保持客觀中立的語氣，每個論點必須有資料支撐。
    skills:
      - markdown-formatter
      - citation-manager

team:
  coordination_mode: orchestrator
  max_parallel_agents: 3
  timeout: 300s
  shared_memory: true

3.2 協調者模式（Orchestrator Pattern）

協調者模式是最常見的多代理架構，適合任務流程相對固定、需要中央控制的場景。

在此模式下，協調代理（Orchestrator Agent）扮演「專案經理」的角色：

  1. 接收使用者的高層次任務描述
  2. 將任務分解為可委派的子任務
  3. 依子任務性質選擇合適的子代理
  4. 監控各子代理的執行進度
  5. 整合所有子代理的輸出
  6. 將最終結果回傳給使用者

協調者模式的優勢在於邏輯清晰、易於調試。當任務失敗時，可以快速定位是哪個子代理出現問題。其劣勢是協調代理成為單點瓶頸：若協調代理的推理出現偏差，整個系統的輸出都會受影響。

3.3 點對點模式（Peer-to-Peer Pattern）

點對點模式中，各代理之間地位平等，可以直接相互通訊，不需要透過中央協調代理。這種模式適合需要多方協商達成共識的場景，例如多個評審代理對同一份方案進行獨立評估後投票決策。

# peer-to-peer 配置範例
team:
  coordination_mode: peer-to-peer
  communication:
    broadcast: true      # 任一代理的訊息廣播給所有代理
    consensus_required: true
    consensus_threshold: 0.67  # 需要 2/3 代理同意

點對點模式的挑戰在於可能產生訊息風暴（Message Storm）——當代理數量增多時，廣播訊息的數量呈指數增長。因此，OpenClaw 建議點對點模式的代理數量不超過五個。

3.4 階層式模式（Hierarchical Pattern）

階層式模式結合了協調者模式與點對點模式的優點，適合大規模複雜任務。架構上形成樹狀結構：頂層協調代理（Root Orchestrator）管理多個中層協調代理（Sub-Orchestrators），每個中層協調代理再管理各自的執行代理（Worker Agents）。

# 階層式配置範例
team:
  coordination_mode: hierarchical
  hierarchy:
    root: project-manager
    level_1:
      - research-lead    # 管理 web-scraper, arxiv-searcher
      - dev-lead         # 管理 coder, tester, reviewer
      - content-lead     # 管理 writer, editor, translator

此模式適合企業級工作流程，但配置複雜度最高，調試難度也相對較大。建議只在確認單層協調者模式無法滿足需求時才考慮導入。

四、子代理通訊協定

多代理系統的效能與穩定性，很大程度取決於代理間的通訊機制設計。OpenClaw 提供三種通訊協定，各有其適用場景。[1]

4.1 結構化訊息傳遞（Structured Message Passing）

最基本的通訊方式：代理 A 完成任務後，將結果封裝為標準化的訊息物件，傳送給代理 B。OpenClaw 的訊息格式遵循以下結構：

{
  "message_id": "msg_abc123",
  "sender": "web-scraper",
  "receiver": "data-analyst",
  "task_id": "research_task_001",
  "message_type": "task_result",
  "payload": {
    "status": "success",
    "data": { ... },
    "metadata": {
      "tokens_used": 1240,
      "execution_time_ms": 3200,
      "sources": ["https://example.com/article"]
    }
  },
  "timestamp": "2026-02-22T10:30:00Z"
}

結構化訊息傳遞的優點是可追溯性強——每一筆訊息都有唯一 ID，便於事後審計與調試。缺點是對於需要頻繁小量交換資料的場景，訊息封裝的開銷可能佔據顯著比例。

4.2 共享記憶體（Shared Memory）

共享記憶體允許多個代理讀寫同一個記憶體命名空間，適合需要頻繁共享中間狀態的場景。OpenClaw 透過 Gateway 的 Memory Store 實現這一機制：

# 在代理配置中啟用共享記憶體
agents:
  coordinator:
    memory:
      shared_namespace: "research_project_001"
      read_access: ["web-scraper", "data-analyst", "report-writer"]
      write_access: ["coordinator", "data-analyst"]

  data-analyst:
    memory:
      shared_namespace: "research_project_001"
      # 從共享記憶體讀取爬蟲資料，寫入分析結果

使用共享記憶體時，需注意以下事項：

4.3 事件佇列（Event Queue）

事件佇列是最適合非同步工作流程的通訊機制。代理發布事件（Publish），其他代理訂閱（Subscribe）感興趣的事件類型，當事件觸發時自動啟動對應的代理。

# 事件佇列配置
team:
  event_bus:
    enabled: true
    events:
      - name: "scraping_completed"
        publisher: "web-scraper"
        subscribers: ["data-analyst"]
        trigger: "on_task_success"

      - name: "analysis_completed"
        publisher: "data-analyst"
        subscribers: ["report-writer", "coordinator"]
        trigger: "on_task_success"

      - name: "task_failed"
        publisher: "*"  # 任何代理都可以發布失敗事件
        subscribers: ["coordinator"]
        trigger: "on_error"

事件佇列與 OpenClaw 的 Hooks 系統深度整合：代理完成任務後觸發的 Hook，可以自動發布事件至佇列，啟動下游代理。這使得代理之間的協作可以完全解耦——每個代理只需關注「我何時完成」，而不需要知道「誰在等待我的結果」。

4.4 通訊協定選型指南

場景特徵 建議協定 原因
線性管道，步驟明確 結構化訊息傳遞 可追溯性高，調試方便
多代理頻繁共享狀態 共享記憶體 減少訊息序列化開銷
事件驅動，觸發條件多樣 事件佇列 解耦代理，支援動態工作流
複雜混合場景 混合使用 依子任務性質選擇最適合的協定

五、任務委派與角色分工設計模式

多代理系統的效能，很大程度取決於任務是否被委派給「對的代理」。OpenClaw 提供了多種任務委派策略。

5.1 角色定義的三要素

一個設計良好的子代理角色應包含三個核心要素：

  1. 能力邊界（Capability Boundary）：明確定義代理「能做什麼」和「不做什麼」。邊界不清晰的代理容易在接收到超出範圍的任務時產生幻覺（Hallucination）或不必要的越界行為。
  2. 輸入/輸出契約（I/O Contract）：規範代理接收的輸入格式與回傳的輸出結構。嚴格的 I/O 契約使代理可以像 API 一樣被其他代理呼叫，提升系統的可組合性。
  3. 失敗行為（Failure Behavior）：定義當代理無法完成任務時應如何回應——是靜默失敗、返回錯誤碼、還是請求人類介入？
# 角色定義範例：具備完整三要素
agents:
  data-analyst:
    system: |
      【能力邊界】
      你專門負責資料分析與統計洞見萃取。
      你不進行資料收集、不撰寫報告、不執行程式碼。

      【輸入格式】
      接收 JSON 格式的結構化資料，包含 "raw_data" 和 "analysis_goal" 欄位。

      【輸出格式】
      返回包含以下欄位的 JSON：
      - "key_findings": 字串陣列，每項不超過 50 字
      - "statistics": 關鍵數值統計
      - "confidence": 分析結論的信心程度（high/medium/low）

      【失敗行為】
      若資料品質不足以支撐分析，返回 {"status": "insufficient_data", "reason": "..."}

5.2 技能路由（Skill-Based Routing）

OpenClaw 的技能系統（Skills）與多代理架構深度整合：協調代理可以根據子任務所需的技能，自動將任務路由至持有對應技能的子代理。

# 技能路由配置
agents:
  coordinator:
    routing_strategy: skill-based
    routing_rules:
      - skill: "web-search"
        route_to: "web-scraper"
      - skill: "data-analysis"
        route_to: "data-analyst"
      - skill: "code-execution"
        route_to: "code-runner"
      - skill: "*"  # 預設路由
        route_to: "general-assistant"

5.3 負載均衡（Load Balancing）

當多個子代理具備相同能力時（例如三個「網路爬取代理」），OpenClaw 支援基於以下策略的負載均衡：

team:
  load_balancing:
    strategy: shortest-queue
    agent_pool:
      - web-scraper-1
      - web-scraper-2
      - web-scraper-3
    health_check:
      enabled: true
      interval: 30s
      failure_threshold: 3  # 連續失敗 3 次後從池中移除

5.4 備援策略（Fallback Strategy）

在生產環境中，子代理可能因各種原因失敗——API 限速、模型服務不可用、任務超時。設計完善的備援策略是多代理系統穩定運行的關鍵：

agents:
  primary-analyst:
    model: claude-3-5-sonnet
    fallback:
      on_timeout:
        action: retry
        max_retries: 2
        backoff: exponential
      on_api_error:
        action: delegate
        fallback_agent: backup-analyst
      on_capability_mismatch:
        action: escalate
        escalate_to: coordinator

六、實戰案例一：研究團隊多代理協作

本案例展示如何用 OpenClaw Agent Teams 構建一個能夠自動完成學術競爭情報研究的多代理系統。

6.1 系統需求與角色設計

目標：給定一個研究主題（例如「多模態大型語言模型的醫療應用」），在 15 分鐘內輸出一份包含最新論文摘要、競爭格局分析與技術趨勢預測的報告。

角色設計如下：

6.2 完整配置檔

# research-team.yaml
name: research-intelligence-team
version: "1.0"

agents:
  research-coordinator:
    model: claude-3-5-sonnet
    system: |
      你是研究協調代理。收到研究主題後，立即執行以下步驟：
      1. 同時委派論文搜尋任務給 paper-searcher 和 web-scraper
      2. 收到兩者結果後，委派分析任務給 data-analyst
      3. 收到分析結果後，委派報告撰寫任務給 report-writer
      4. 向使用者回傳最終報告

      委派任務時，使用以下格式：
      {"delegate_to": "agent_name", "task": "...", "deadline": "Xs"}
    skills:
      - task-delegation
      - progress-monitoring
    subagents:
      - paper-searcher
      - web-scraper
      - data-analyst
      - report-writer

  paper-searcher:
    model: gpt-4o-mini
    system: |
      你是學術論文搜尋代理。
      使用 web-search 技能搜尋 arXiv 和 Google Scholar。
      返回格式：{"papers": [{"title": "", "authors": [], "year": 0, "citations": 0, "abstract": ""}]}
      每次最多返回 10 篇最相關論文。
    skills:
      - web-search
      - arxiv-api
    timeout: 60s
    max_retries: 2

  web-scraper:
    model: gpt-4o-mini
    system: |
      你是網頁資訊收集代理。
      搜尋並提取新聞報導、技術部落格與行業分析。
      返回格式：{"sources": [{"url": "", "title": "", "date": "", "summary": "", "key_points": []}]}
      只返回 6 個月內的內容，每次最多 8 個來源。
    skills:
      - web-search
      - content-extractor
    timeout: 60s

  data-analyst:
    model: claude-3-5-sonnet
    system: |
      你是資料分析代理。
      接收論文清單和網頁資料後，分析：
      1. 發表趨勢（按年份、機構分布）
      2. 核心技術方向與關鍵詞聚類
      3. 主要研究機構與競爭格局
      4. 技術成熟度評估（TRL 1-9）
      返回結構化的分析結果 JSON。
    skills:
      - data-analysis
      - trend-detection
    timeout: 90s

  report-writer:
    model: claude-3-opus
    system: |
      你是專業報告撰寫代理。
      將分析資料轉化為具備以下結構的 Markdown 報告：
      ## 執行摘要（200 字以內）
      ## 研究現況（含統計數據）
      ## 技術趨勢分析
      ## 競爭格局
      ## 結論與建議
      ## 參考資料
      語氣客觀，每個論斷必須有數據支撐。
    skills:
      - markdown-writer
      - citation-formatter
    timeout: 120s

team:
  coordination_mode: orchestrator
  orchestrator: research-coordinator
  max_parallel_agents: 3
  global_timeout: 900s  # 15 分鐘
  shared_memory:
    enabled: true
    namespace: "research_session"
  event_bus:
    enabled: true
  logging:
    level: info
    include_agent_messages: true

6.3 執行流程解析

當使用者輸入研究主題後，系統按以下流程運作：

  1. T+0s：研究協調代理接收主題，分析任務結構
  2. T+2s：同時委派搜尋任務給 paper-searcher 和 web-scraper（並行執行）
  3. T+60s：兩個搜尋代理完成，透過事件佇列通知協調代理
  4. T+62s：協調代理將搜尋結果寫入共享記憶體，啟動 data-analyst
  5. T+130s：資料分析完成，啟動 report-writer
  6. T+250s：報告完成，協調代理整合並回傳給使用者

整個流程約 4 分鐘，而若由單一代理依序完成相同任務，預計需要 12–15 分鐘。

6.4 效能與成本分析

以一次典型的研究任務為例（主題：多模態 LLM 醫療應用）：

代理 模型 Token 用量 執行時間 估算成本
研究協調代理 Claude 3.5 Sonnet 3,200 8s $0.005
論文搜尋代理 GPT-4o-mini 8,500 52s $0.004
網頁爬取代理 GPT-4o-mini 6,200 48s $0.003
資料分析代理 Claude 3.5 Sonnet 12,000 68s $0.018
報告撰寫代理 Claude Opus 9,800 115s $0.147
合計 — 39,700 ~250s $0.177

若所有任務均使用 Claude Opus，相同的 Token 用量估算成本約 $0.596，多代理混合模型策略節省了約 70% 的成本。

七、實戰案例二：開發團隊代碼審查流水線

本案例展示如何構建一個 CI/CD 流水線中的多代理代碼審查系統，在開發者提交 Pull Request 後自動完成多維度審查。

7.1 系統需求與角色設計

目標：在 PR 提交後 5 分鐘內，完成安全漏洞掃描、程式品質審查、測試覆蓋率分析與文件完整性檢查，並生成可直接張貼至 GitHub 的審查評論。

角色設計：

7.2 完整配置檔

# code-review-team.yaml
name: code-review-pipeline
version: "1.0"

agents:
  review-coordinator:
    model: claude-3-5-sonnet
    system: |
      你是代碼審查協調代理。
      接收 PR diff 後，同時委派以下四項審查任務：
      - 安全審查 → security-reviewer
      - 代碼品質 → code-quality-agent
      - 測試分析 → test-agent
      - 文件檢查 → doc-agent

      收到所有審查結果後，生成符合以下格式的 GitHub PR 評論：
      ### 🔍 自動化代碼審查報告
      **整體評分**：X/10
      #### 安全性 | 代碼品質 | 測試覆蓋 | 文件完整性
      每項列出具體問題與改善建議。
    skills:
      - file-reader
      - git-diff-parser
    subagents:
      - security-reviewer
      - code-quality-agent
      - test-agent
      - doc-agent

  security-reviewer:
    model: claude-3-5-sonnet
    system: |
      你是資安審查代理，專精於代碼安全漏洞識別。
      審查範圍：OWASP Top 10、硬編碼密鑰與憑證、SQL/命令注入、
      XSS 漏洞、不安全的依賴套件版本。

      對每個問題，返回：
      {"severity": "critical|high|medium|low", "location": "file:line", "description": "", "recommendation": ""}

      severity 為 critical 時必須包含修正代碼範例。
    skills:
      - code-analyzer
      - vulnerability-scanner
    timeout: 60s

  code-quality-agent:
    model: gpt-4o
    system: |
      你是代碼品質審查代理。
      評估維度：
      1. 命名規範（變數、函數、類別命名是否清晰）
      2. 函數複雜度（McCabe 複雜度是否超過 10）
      3. 重複代碼（DRY 原則違反）
      4. SOLID 原則合規性
      5. 錯誤處理完整性

      返回每個維度的評分（1-10）和具體問題清單。
    skills:
      - code-analyzer
      - complexity-calculator
    timeout: 60s

  test-agent:
    model: gpt-4o-mini
    system: |
      你是測試分析代理。
      分析代碼變更並：
      1. 識別未被現有測試覆蓋的新增代碼路徑
      2. 建議需要新增的單元測試和整合測試
      3. 評估邊界條件和異常路徑的測試完整性

      返回測試覆蓋率估算和建議測試案例清單。
    skills:
      - code-analyzer
      - test-pattern-detector
    timeout: 45s

  doc-agent:
    model: gpt-4o-mini
    system: |
      你是文件審查代理。
      檢查：
      1. 新增/修改的公開函數是否有完整的 JSDoc/docstring
      2. README 是否需要更新（新增 API、環境變數、依賴項）
      3. CHANGELOG 是否已記錄本次變更
      4. 複雜邏輯是否有行內注釋

      返回文件缺失清單和優先級評估。
    skills:
      - file-reader
      - doc-parser
    timeout: 30s

team:
  coordination_mode: orchestrator
  orchestrator: review-coordinator
  max_parallel_agents: 4  # 四個審查代理全部並行
  global_timeout: 300s
  hooks:
    on_complete:
      - action: post-github-comment
        target: "{{pr.url}}/reviews"
    on_critical_security:
      - action: slack-alert
        channel: "#security-alerts"
        message: "Critical security issue found in PR {{pr.number}}"

7.3 與 CI/CD 系統整合

以 GitHub Actions 為例，將代碼審查代理團隊整合至 PR 工作流程：

# .github/workflows/ai-code-review.yml
name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Generate PR Diff
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > pr.diff

      - name: Run OpenClaw Review Team
        env:
          OPENCLAW_API_KEY: ${{ secrets.OPENCLAW_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          openclaw run \
            --config .openclaw/code-review-team.yaml \
            --input "$(cat pr.diff)" \
            --context "pr_number=${{ github.event.pull_request.number }}" \
            --context "pr_url=${{ github.event.pull_request.html_url }}"

7.4 審查品質評估

在實際部署中，多代理代碼審查系統展現出以下效果：

八、效能與成本優化

多代理系統引入了額外的協調開銷，若不加以優化，可能抵消並行化帶來的效益。以下是關鍵的優化策略。

8.1 Token 用量優化

系統提示壓縮：每次代理啟動都會消費系統提示的 Token。對於頻繁啟動的代理，應將系統提示保持在 500 tokens 以內，去除冗餘描述。

中間結果截斷：子代理的輸出若直接傳入下一個代理，容易造成 Token 膨脹。協調代理應在傳遞之前進行摘要壓縮：

agents:
  coordinator:
    inter_agent_compression:
      enabled: true
      strategy: extractive-summary
      max_tokens_per_result: 2000  # 每個子代理結果最多 2000 tokens

8.2 並行 vs. 序列執行的決策框架

並非所有子任務都適合並行執行。錯誤的並行化會增加協調複雜度，反而降低整體效能。

判斷是否可以並行執行的標準：

team:
  execution_plan:
    # 第一批：可完全並行
    parallel_batch_1:
      - paper-searcher
      - web-scraper
    # 第二批：依賴第一批結果
    parallel_batch_2:
      - data-analyst   # 需要第一批的全部結果
    # 第三批：依賴第二批
    sequential:
      - report-writer  # 需要 data-analyst 的完整輸出

8.3 快取策略（Caching）

在多輪對話或重複任務場景中，子代理的中間結果可以被快取，避免重複執行相同的昂貴操作：

agents:
  paper-searcher:
    cache:
      enabled: true
      ttl: 3600s   # 搜尋結果快取 1 小時
      key_template: "search_{query_hash}"
      storage: redis  # 支援 memory, redis, disk

快取命中率對成本影響顯著：在研究類任務中，相同或相似主題的搜尋結果快取命中率可達 40–60%，有效降低重複 API 調用成本。

8.4 模型選配策略（Model Selection）

為每個代理選配最合適的模型，是降低成本的最有效手段。建議原則：

代理類型 任務特徵 建議模型 理由
協調代理 邏輯推理、任務分解 Claude 3.5 Sonnet 強推理能力，成本適中
資料收集代理 資訊提取、格式轉換 GPT-4o-mini 速度快，成本低，足夠勝任
分析代理 複雜分析、模式識別 Claude 3.5 Sonnet 分析能力強，性價比高
創作輸出代理 高品質文字生成 Claude Opus 輸出品質最高，用於最終交付
路由/分類代理 簡單分類、關鍵字提取 DeepSeek-V3 / Ollama 超低成本，延遲極短

九、與其他多代理框架的比較

在選型 OpenClaw Agent Teams 之前，有必要與市面上的主要競品進行客觀比較。[3][8]

9.1 四大框架對比

維度 OpenClaw Agent Teams AutoGen CrewAI LangGraph
配置方式 YAML 宣告式 Python 程式碼 Python 程式碼 Python 程式碼
入門難度 低 中 中 高
工作流靈活性 中 高 中 最高
內建 GUI 有（OpenClaw UI） 有（AutoGen Studio） 無 有（LangSmith）
多 LLM 支援 Claude/GPT/DeepSeek/Ollama 廣泛 廣泛 廣泛
監控與可觀測性 基本 中等 基本 完整（LangSmith）
社群活躍度 快速成長 成熟 成熟 成熟
適合場景 快速原型、標準流程 研究實驗 角色扮演協作 複雜動態工作流

9.2 OpenClaw Agent Teams 的核心優勢

YAML 優先的配置哲學：對於非 Python 開發者（例如後端工程師或產品經理）而言，YAML 配置的入門門檻遠低於需要撰寫 Python 類別定義的 AutoGen 或 CrewAI。這使得非技術背景的業務人員也能參與代理系統的設計過程。

與 OpenClaw 生態系統的深度整合：若團隊已在使用 OpenClaw 的單一代理功能，遷移至 Agent Teams 幾乎沒有學習成本。Skills 系統、Hooks 系統、Gateway 架構全部無縫延伸至多代理場景。[6]

9.3 OpenClaw Agent Teams 的現有限制

客觀而言，OpenClaw Agent Teams 在以下方面仍落後於成熟框架：

建議：若任務流程相對固定（例如本文案例中的研究報告生成與代碼審查），選擇 OpenClaw Agent Teams；若需要複雜的條件分支與動態路由，考慮 LangGraph；若團隊以研究為主，AutoGen 的靈活性更適合實驗性場景。

十、常見問題與最佳實踐

10.1 調試多代理系統

多代理系統的調試難度顯著高於單一代理，原因在於問題可能源自：代理配置錯誤、訊息格式不一致、計時問題（Race Condition）、或代理間的錯誤傳播。

建議的調試工作流：

  1. 隔離測試：先單獨測試每個子代理，確認其在標準輸入下能輸出正確結果
  2. 啟用詳細日誌：在開發環境設定 logging.level: debug，記錄所有代理間的訊息
  3. 固定隨機種子：在測試中固定模型的隨機種子，確保結果可復現
  4. 從簡單場景開始：先用最簡單的輸入驗證整體流程，再測試邊界條件
# 調試模式配置
team:
  debug:
    enabled: true
    save_agent_messages: true
    save_intermediate_results: true
    output_dir: "./debug-logs"
    replay_mode: false  # 設為 true 可重放失敗的訊息序列

10.2 監控與可觀測性

在生產環境中，多代理系統需要持續監控以確保穩定運行：

team:
  monitoring:
    metrics:
      - agent_execution_time
      - token_usage_per_agent
      - task_success_rate
      - inter_agent_message_count
    alerts:
      - condition: "task_success_rate < 0.95"
        action: slack-notify
        channel: "#ops-alerts"
      - condition: "agent_execution_time > timeout * 0.8"
        action: log-warning

10.3 錯誤處理最佳實踐

在多代理系統中，單一代理的失敗不應導致整個工作流崩潰。以下是三層錯誤處理策略：

10.4 安全性考量

多代理系統引入了新的安全攻擊面，特別是提示注入攻擊（Prompt Injection）：惡意輸入可能透過子代理的輸出傳播至其他代理，進而影響整個系統的行為。

防護措施：

10.5 刪除與管理子代理

在 OpenClaw 的 Agent Teams 配置中，刪除（delete）一個子代理需要同時處理以下面向，以避免殘留的訊息路由引發錯誤：

# 安全刪除子代理的步驟

# 步驟 1：從 subagents 清單中移除目標代理
agents:
  coordinator:
    subagents:
      # - web-scraper  <-- 移除這行
      - data-analyst
      - report-writer

# 步驟 2：移除相關的路由規則
    routing_rules:
      # - skill: "web-search"
      #   route_to: "web-scraper"  <-- 移除這段

# 步驟 3：移除事件訂閱
team:
  event_bus:
    events:
      # - name: "scraping_completed"  <-- 移除整個事件定義
      #   publisher: "web-scraper"
      #   subscribers: ["data-analyst"]

# 步驟 4：移除代理定義本身
# 刪除 agents.web-scraper 的完整區塊

建議在刪除代理前，先將其設定為 disabled: true 並觀察系統行為一段時間，確認無其他代理依賴其輸出，再執行完整刪除。

10.6 技能（Skills）的跨代理管理

當多個代理共用同一技能時，需要集中管理技能版本，避免不同代理使用不相容的技能版本：

# 全域技能版本鎖定
team:
  skill_registry:
    web-search: "2.1.0"    # 所有使用 web-search 的代理強制使用此版本
    code-analyzer: "1.5.2"
    file-reader: "3.0.0"

結語

多代理系統架構代表著 AI 代理發展的重要里程碑——從「一個 AI 助理」演進為「一支 AI 團隊」。OpenClaw Agent Teams 以 YAML 宣告式配置降低了多代理系統的入門門檻，使更多開發者和業務人員得以參與設計和部署複雜的自動化工作流程。[9]

本文展示的兩個實戰案例——研究情報系統與代碼審查流水線——都已在實際環境中驗證了多代理架構的效能優勢與成本效益。隨著 OpenClaw 社群的持續成長，我們預期 Agent Teams 的功能將持續完善，特別是在動態工作流支援與監控工具方面。[10]

對於正在評估多代理系統的團隊，建議從最小可行案例（MVP）開始：選取一個現有工作流中最耗時且最可平行化的任務，構建一個包含 2–3 個代理的小型團隊，在驗證效果後再逐步擴展。多代理系統的複雜度應該隨著需求的確認而增長，而非一開始就追求完整的架構設計。