Multi-Agent 編排實戰：我怎麼讓 Claude Code、OpenClaw 與 n8n 協作

這是「Agentic Engineering 實戰手冊」系列的第十篇。上一篇：MCP 與 A2A 協議實戰

理論上是一支 AI 團隊，實際上是兩個 Agent 加一套自動化

我的日常有兩個 AI agent 在跑：Claude Code 負責寫 code，OpenClaw 負責每日 briefing 和調研；另外用 n8n 串接確定性的 workflow。n8n 可以在節點裡呼叫模型，但我這套流程主要把它當 automation engine，不把每個「當 X 發生就做 Y」都叫 agent。

實際上？Claude Code 不知道 OpenClaw 今天早上幫我整理了什麼重點。OpenClaw 不知道昨天 coding session 做到哪了。n8n 觸發的 automation 偶爾會跟 Claude Code 正在做的事情衝突。

三個很強的 agent，各自為政。

Multi-agent orchestration 不是把工具數量加起來，而是講清楚誰負責判斷、誰負責執行、狀態怎麼交接，以及出錯時誰停手。

我的兩個 Agent + Automation 架構

Agent 1：Claude Code — 核心開發者

職責：寫 code、修 bug、review PR、重構、寫測試 運行環境：本地 terminal + IDE integration 記憶方式：CLAUDE.md + memory system + conversation history 工作時間：我開電腦的時候（~8-10 小時/天）

Claude Code 是主力。我 80% 的生產力來自它。它有完整的 codebase access、MCP 工具、和一年累積的 CLAUDE.md 設定。

Agent 2：OpenClaw — 研究分析師

職責：每日 briefing（技術新聞、產業動態）、深度研究（競品分析、技術選型）、內容策劃 運行環境：雲端，每天 6:00 AM 自動執行 記憶方式：Notion database + 結構化輸出 工作時間：每天自動跑一次 + 我手動觸發研究任務

OpenClaw 是我的「情報官」。它每天早上自動整理我追蹤的領域的最新動態，讓我不需要花時間刷 Twitter 和 Hacker News。

Automation：n8n — 自動化管家

職責：workflow automation——GitHub webhook 處理、Notion 同步、定時任務、跨系統串接 運行環境：self-hosted n8n instance 記憶方式：workflow 狀態 + execution logs 工作時間：24/7 always-on

n8n 不做「思考」的工作。它做的是「當 X 發生時，執行 Y」的 deterministic automation。GitHub 有新 PR → 自動通知 Slack。Blog post 更新 → 自動觸發 build。

為什麼是這三個

這個組合不是隨便選的。核心設計原則是 non-overlapping responsibilities：

              ┌─────────────────┐
              │   Human (我)     │
              │ 決策、Review、方向 │
              └────┬───┬───┬────┘
                   │   │   │
     ┌─────────────┤   │   ├─────────────┐
     │             │   │   │             │
┌────▼────┐  ┌─────▼───▼──┐  ┌──────────▼┐
│ OpenClaw │  │ Claude Code │  │    n8n     │
│ Research │  │   Coding    │  │ Automation │
│ Morning  │  │ On-demand   │  │  24/7      │
└──────────┘  └─────────────┘  └────────────┘

每個 agent 有明確的「地盤」。沒有兩個 agent 負責同一件事。當兩個 agent 的職責重疊時，問題就來了。

職責重疊的慘案

有一次我同時讓 Claude Code 寫一個新的 API endpoint，又讓 n8n 的自動化在同一個 repo 上跑 auto-format。結果 n8n 的 formatter 在 Claude Code 還在寫的時候就 commit 了一個格式修正，造成 Claude Code 的 working directory 突然有了 unexpected changes。

Agent 非常不擅長處理「有人在我背後改了東西」的情況。它不知道那些 changes 是 n8n 做的 auto-format，以為是自己剛才寫的 code 的一部分，然後在上面繼續 build——結果是一團混亂。

教訓：一個任務只能有一個 owner。如果 Claude Code 在寫 code，n8n 的 auto-format workflow 就暫停。

Context 如何在 Agent 之間傳遞

這是 multi-agent 最難的部分。不是技術上難（你可以用 file、API、database），是設計上難——什麼資訊需要傳遞？傳遞多少？什麼時候傳遞？

Markdown as Shared Memory

我目前的做法是用 Markdown 文件作為 agent 之間的共享記憶：

~/.claude/projects/{project}/memory/
├── MEMORY.md          ← index：所有 memory 的目錄
├── user_role.md       ← 關於我的資訊
├── project_status.md  ← 專案進度
├── decisions.md       ← 重要決策紀錄
└── lessons.md         ← 學到的教訓

為什麼用 Markdown 而不是 Database？

Human-readable：我可以直接打開看，不需要 query tool
可以納入版控：前提是檔案放在 repo 或另一個有 git 的知識庫；~/.claude/ 本身不會自動被 git 追蹤
Agent-native：所有 LLM agent 都擅長讀寫 Markdown
Zero infrastructure：不需要額外的 database 或 API server

Hot / Warm / Cold 三層記憶

不是所有資訊都需要即時同步。我把 memory 分三層：

層級	內容	同步頻率	存放位置
Hot	當前 task 的 context、進行中的決策	即時	Conversation / Plan file
Warm	專案狀態、近期決策、常用 patterns	每 session	Memory files
Cold	歷史決策、舊的 lessons learned	不主動同步	Memory archive

Claude Code 開始新 session 時，自動載入 Warm 層的記憶（透過 MEMORY.md index）。Hot 層在 session 內即時產生。Cold 層只在明確需要時才去讀。

Agent 之間的接力棒

一天的流程看起來像這樣：

06:00  OpenClaw → 產出 daily briefing → 寫入 Notion
09:00  我 → 讀 briefing → 決定今天做什麼
09:05  Claude Code → 載入 memory + 今天的 task list → 開始工作
       ...（Claude Code 工作整天）...
18:00  Claude Code → session 結束 → 更新 memory/project_status.md
18:00  n8n → 偵測到 session 結束 → 觸發 daily summary workflow
21:00  我 → review daily summary → 調整明天的優先級

關鍵在 handoff 的時刻——每個 agent 結束工作時，要把「做了什麼、證據在哪、還有哪些風險、下一步建議」寫進共享記憶。所謂無縫不是完全不用重讀，而是不用靠猜測重建狀態。

為什麼我沒用 LangGraph / CrewAI

我試過的框架：

LangGraph

優點：最靈活。你可以定義任意複雜的 agent 互動圖。支援條件分支、循環、人工介入點。缺點：學習曲線陡。為了設定一個兩 agent 的 pipeline，我寫了 200 行 boilerplate code。而且 debug 困難——graph 一複雜，你很難追蹤「資料是從哪條路徑流過來的」。

我的結論：這次兩個 agent 的 pipeline 不值得引入它；若流程有分支、循環、持久狀態與人工介入點，哪怕只有兩個 agent，框架也可能有價值。重點是狀態機複雜度，不是 agent 數量。

CrewAI

優點：角色定義直觀（“you are a researcher”, “you are a coder”）。設定快。缺點：以我測試的版本來說，預設互動模式和我的 workflow 不合，客製化成本比手動串接高。這是版本與需求相關的觀察，不代表它現在仍綁死某個 provider。

結論：快速 prototype 很好用，但 production 使用的靈活度不夠。

Google ADK（Agent Development Kit）

優點：跟 Google 生態系（Gemini、Vertex AI）整合好。缺點：我的專案不在 Google Cloud／Gemini 主線上，為了這套整合遷移沒有明顯收益。

Microsoft Agent Framework

優點：企業級。跟 Azure、Microsoft 365 整合。缺點：Azure-heavy。如果你不在 Azure 生態系裡，很多功能用不上。

我的結論：手動編排就好

對於大部分個人開發者和小團隊來說，手動編排比框架更適合：

	手動編排	框架
透明度	流程短時容易追蹤	多一層框架抽象，debug 要搭配 tracing
靈活度	小流程可直接調整	受框架提供的 primitives 影響
學習成本	仍要設計交接與失敗處理	另外要學框架概念與 API
維護成本	規模變大後容易散落	要跟進框架版本，但集中管理能力較好
適合場景	線性、低狀態、容易人工追蹤	有分支／循環、持久狀態、重試與觀測需求

手動編排的意思是：我自己決定哪個 agent 做什麼、怎麼傳遞 context、怎麼處理衝突。不用框架，用 files + webhooks + 少量 script。

什麼時候該用框架？

互動有多個分支、循環或長時間持久狀態
你需要 deterministic orchestration（金融、醫療等合規要求）
你的團隊有多人需要共同維護 agent pipeline
你需要 observability 和 audit trail

如果以上都不符合，從手動開始。需要框架的時候你會知道的。

Error Handling：當 Agent 們意見不一致

衝突類型 1：搶資源

兩個 agent 同時修改同一個 worktree → git conflict 或互相覆蓋尚未提交的變更。

解法：single-writer 原則，加上獨立 worktree／branch。不要只靠「某檔案歸誰」的口頭約定；讓每個執行者有隔離的工作目錄，最後透過 diff、PR 或明確 handoff 合併。

衝突類型 2：不同建議

OpenClaw 的 research 說「應該用 Library A」，Claude Code 在實作時發現 Library A 有 bug，改用了 Library B。隔天 OpenClaw 又建議 Library A。

解法：決策一旦做出就記錄到 shared memory（decisions.md），所有 agent 都要先讀決策紀錄再給建議。

衝突類型 3：Automation 時機不對

n8n 在 Claude Code 正在做 interactive rebase 的時候觸發了 auto-lint → 搞亂了 git 狀態。

解法：n8n 的 automation 都加了「check if coding session active」的前置條件。如果有 coding session 在跑，non-critical automation 排隊等候。

核心原則：Human as Final Arbiter

高風險衝突的最終責任仍在人。Meta-agent 可以幫忙排序、彙整或依既定規則處理低風險衝突，但它本身也要有停止條件、audit trail 與人工升級路徑。

我的預設流程是：agent 發現無法依既定規則解決的衝突 → 暫停 → 附上兩邊證據通知人類 → 人類決策 → agent 繼續。

給想開始的人的建議

Phase 1：先把一個 Agent 用到極致

不要一開始就想搞 multi-agent。先把 Claude Code（或你的主力 coding agent）的潛力完全發揮——好的 CLAUDE.md、完善的 spec workflow、可靠的 QA 流程。

Phase 2：加第二個 Agent 做非 coding 的事

當你覺得主力 coding agent 已經穩定，但仍花很多時間在 research 或 admin 上，可以加第二個 agent。職責可以接壤，但寫入權、交付格式與最後 owner 必須明確，否則「完全不重疊」反而會留下沒人負責的縫隙。

Phase 3：用 Automation 串接

n8n（或 Zapier / Make）作為黏合劑，把兩個 agent 的 output 串接起來。不需要它們直接對話，只需要它們共享結果。

Phase 4：需要的時候再加框架

很多個人流程在 Phase 2–3 就夠用。如果你開始自己重做 state machine、重試、checkpoint、trace 與人工介入，這才是評估 LangGraph 等框架的明確訊號。

Takeaway

Multi-agent 的價值在分工與交接，不在數量——先定義誰負責、誰能寫入、產出如何驗收，再決定要不要多一個 agent。
Context sharing 是最難的部分——Markdown 是我目前最簡單的方案；放進 git repo 才有版本歷史。Hot / Warm / Cold 是個人分類，不是唯一正解。
從能看懂的最小流程開始——是否需要框架，看分支、持久狀態、重試、觀測與合規需求，不看 agent 是否超過五個。

上一篇：MCP 與 A2A 協議實戰 下一篇：Token 經濟學進階