每次追 AI 工具的新聞，Multi-Agent 這個詞越來越常出現。但大多數的解釋不是太學術，就是一堆英文術語拼在一起，讀完還是不知道它在解決什麼問題。

這篇文章用一篇文帶你簡單理解：什麼是 AI agent、為什麼要用多個、LangGraph 框架又是什麼東西，以及什麼時候你才真的需要它。

我自己有一套用來自動化內容製作的 multi-agent 系統，整個流程從語音稿到排版上傳全部自動跑，那套系統就是典型的 Multi-agent 架構，文章裡會稍微帶到。

截至本文撰寫時（2026 年 4 月），LangGraph 1.0 已在 2025 年 10 月正式發布，是 Python 生態裡最主流的多agent框架之一。

什麼是「AI agent」？

Agent 這個詞聽起來很玄，但概念其實很直觀：它就是一個能自己決定下一步要做什麼的 AI。

一般的 AI 用法是你問問題、AI 回答、結束。這是單次問答，AI 本身不會主動採取任何行動。

Agent 不一樣。它有一個決策迴圈：收到任務、思考需要什麼工具、呼叫工具（搜尋、執行程式碼、讀取資料）、看結果、再決定下一步，直到任務完成。

舉個例子：你叫一個 agent「查一下今天比特幣價格，然後換算成台幣告訴我」。它會先呼叫搜尋工具查價格，再呼叫匯率 API 換算，最後整理成一句話給你。整個過程你不需要你告訴它，它會自己跑完。

最簡單的開始方法就是現在最流行的 Claude，還不知道 Claude 是什麼的可以先看 Claude 完整指南 這篇文章，Claude 本身就是一個很好的 Agent 起點。

為什麼需要多個 Agent 協作？

一個 agent 實際上會碰到幾個限制：

• Context window 有上限。 一個 AI 每次能處理的文字量是有限的。如果你把所有資訊、所有工具說明、所有任務背景全部塞進同一個 prompt，剩下讓它「思考」的空間就更少了，回答品質自然下降。

• 一個人很難什麼都精通。 你不會讓同一個人同時負責前端、後端、DevOps 和法律審查，AI 也是一樣。一個專門負責「搜尋最新論文」的 agent 和一個專門負責「把論文內容改寫成社群貼文」的 agent，用完全不同的 prompt 設定，效果會比兩件事都交給同一個通用 agent 好很多。

• 任務可以平行跑。 多個 agent 可以同時工作，不用等一個做完才開始另一個。

Multi-agent 架構的常見模式

LangGraph Multi-Agent 系統怎麼運作，有幾種常見的模式。

• Supervisor-Worker（主管加工人）是最普遍的一種。有一個「主管 agent」負責理解任務、決定交給哪個「工人 agent」、收集結果、再決定下一步。工人 agents 各有專職，不需要知道整體目標，只負責完成被交辦的任務：主管分派，工人執行，主管驗收。

• 階層式（Hierarchical）是 Supervisor-Worker 的延伸。主管底下有幾個「組長 agent」，每個組長底下再有幾個工人。適合系統規模很大、工作需要二層以上分工的情況。

• 平等協作（Peer-to-peer）是各個 agent 地位相等，可以互相溝通。適合需要多方討論或共識決策的場景，但協調起來比較複雜。

對大多數應用來說，Supervisor-Worker 是最好上手也最容易維護的選擇。

LangGraph 是什麼：State、Node、Edge 概念

LangGraph 是 LangChain 推出的框架，專門用來建構上面這類多 agent 系統。它把整個工作流程表達成一張有向圖，讓你明確定義每個 agent 做什麼、任務怎麼在它們之間流動。

理解 LangGraph 三個概念：

State（狀態）是整個系統的共享記憶體。所有 agent 都從這裡讀資料、把結果寫回來。你可以把它想成一張所有人都能看到、也都能在上面寫字的白板。用 Python 的 TypedDict 定義，你的 State 長什麼樣，系統的記憶就有多少。

Node（節點）是每個 agent 的工作單元。每個 node 是一個 Python function，接收當前的 State，執行它的任務，再回傳更新後的 State。Node 只負責自己的事，不需要知道前面或後面是誰。

Edge（邊）定義任務怎麼流動。最簡單的 edge 是固定的：A 做完就到 B。進階一點是「條件 edge」：根據 State 的內容決定下一步去 B 還是 C，或者重新回到 A 再跑一次。這個機制讓 LangGraph 能做到「如果驗證失敗就退回重做」，是它比簡單的線性流程強得多的地方。

用 LangGraph 建一個最小系統

先安裝：

pip install langgraph langchain-anthropic

一個最精簡的 LangGraph 系統長這樣：

from langgraph.graph import StateGraph, END
from typing import TypedDict

# 1. 定義 State
class MyState(TypedDict):
    user_input: str
    result: str

# 2. 定義 Node（工作單元）
def process_node(state: MyState) -> dict:
    processed = f”已處理：{state[’user_input’]}”
    return {”result”: processed}

def review_node(state: MyState) -> dict:
    reviewed = f”已審核：{state[’result’]}”
    return {”result”: reviewed}

# 3. 組裝
graph = StateGraph(MyState)
graph.add_node(”process”, process_node)
graph.add_node(”review”, review_node)
graph.add_edge(”process”, “review”)
graph.add_edge(”review”, END)
graph.set_entry_point(”process”)

app = graph.compile()

# 4. 執行
output = app.invoke({”user_input”: “測試一下”, “result”: “”})
print(output[”result”])  # 已審核：已處理：測試一下

這個例子有兩個 node：process 先處理輸入，review 再審核結果，最後結束。State 就是帶著 user_input 和 result 的字典，兩個 node 共用它。

真實的系統會在 node 裡面呼叫 LLM、加入條件 edge 決定要不要重試、或者加入人工確認步驟。但骨架跟上面一樣，就是 State → Nodes → Edges。

其他框架比較

除了 LangGraph，常見的選項還有 CrewAI、AutoGen 和 Anthropic 的 Claude Agent SDK。

CrewAI 上手最快，適合快速做 prototype 或五個 agent 以內的小系統。它用「角色」的概念組織 agent：每個 agent 有名字、目標、背景故事，讀起來很直觀。缺點是擴充性有限，超過一定規模就難以維護，自訂流程控制也比 LangGraph 弱很多。適合想快速建立 multi-agent 的人。→ CrewAI 文件

AutoGen（Microsoft） 適合「多方討論」的場景，agent 之間用對話形式互動，像在模擬一場會議。適合需要多輪 AI 辯論或協作撰寫的場景。但每多一個 agent 就多一倍的 LLM 呼叫，成本和速度都不理想；流程控制也比 LangGraph 難以預測。→ AutoGen GitHub

Claude Agent SDK 是 Anthropic 在 2025 年 9 月推出的，跟 Claude 模型整合最緊密，適合純 Claude 技術棧、工具導向的場景。它的設計重點是讓 Claude 直接使用工具（檔案讀寫、執行命令、呼叫 API），比較像是一個 Claude-native 的 agent 執行環境，而不是一個通用 multi-agent 框架。不支援跨模型，也沒有 LangGraph 那樣細緻的流程控制。

LangGraph 是這四個裡面學習曲線最陡、但彈性最高的。它在生產環境的設計重點是 checkpointing（中途存檔、斷點繼續）、time-travel debugging（回放任何時間點的狀態）和人工審核節點，這些對真正要上線的系統來說很實用。→ LangGraph GitHub

最簡單的選法是先試 CrewAI，等你覺得架構變複雜了，再換 LangGraph 也可以。

常見問題

Multi-agent 系統一定要用框架嗎？
不一定。用純 Python 自己寫 agent 迴圈完全可行，特別是簡單的系統。框架的好處是省掉重複造輪子的時間，以及提供狀態管理、錯誤處理、logging 這類基礎設施。

LangGraph 一定要搭配 LangChain 嗎？
不一定。LangGraph 可以獨立使用，你可以在 node 裡直接呼叫 Anthropic SDK 或 OpenAI SDK，不需要用 LangChain 的其他元件。

Multi-agent 系統比單一 LLM 一定比較好嗎？
不一定。多 agent 增加了系統複雜度和 LLM 呼叫次數（也就是費用）。如果你的任務用一個好的 prompt 就能解決，不需要用 agent。Multi-agent 的價值在於任務複雜、需要專門分工、或需要明確工作流程的情況。

LangGraph 支援 Claude 嗎？
支援。用 langchain-anthropic 套件就可以在 node 裡呼叫 Claude 模型，和使用 OpenAI 一樣簡單。

總結

LangGraph 多agent架構的核心概念很直觀：把一個複雜任務拆給多個各有專長的 AI 去分工，用一個協調機制（通常是主管 agent）讓整個流程跑起來。

LangGraph 提供了一個結構化的方式來表達這種工作流程，用 State 管理共享記憶、用 Node 定義每個 agent 的工作、用 Edge 決定任務怎麼流動。你可以直接複製我上面那兩個 node 的例子，加上你自己的 LLM 呼叫和工具試試看。

大多數人在嘗試 Multi-Agent 的第一步，做的事情其實是讓多個 AI 輪流對話。每個 Agent 用自然語言描述它的「角色」，然後把自由格式的回應傳給下一個。結果就是：系統跑了一半，某個 Agent 輸出了不對的格式，下一個 Agent 沒有報錯就直接繼續，到最後你根本不知道哪裡壞了。

要建立一套真正能跑的 Claude Code multi-agent 系統，你需要的不是更多 Agent，是更嚴格的合約規格。本篇從 Supervisor 設計開始，完整走過五個開發階段，說明每個 Agent 的輸入輸出規格、自動失敗規則，以及 Claude Code 的設置方式。

如果你對 Claude Code 的基本使用方式還不熟悉，可以先看 Claude Code 的相關介紹，再回來設計這套架構。

為什麼 Multi-Agent 常常跑不起來？

問題不在 Agent 數量，在於每個 Agent 只有描述，沒有明確的合約規格。

一個只有描述的 Agent 長這樣：

「你是市場分析師，負責分析競爭對手並給出建議。」

這樣的描述沒有告訴系統：

• 它接收什麼格式的輸入

• 它只能產出哪種格式的輸出( Output Contract )

• 它被允許做哪些操作。

一個有明確合約的 Agent，prompt 裡會定義這三件事，讓系統得以驗證每一次輸出是否符合預期，而不是只能靠「感覺」判斷 Agent 有沒有做對。

有明確合約規格的 Agent，當它輸出了錯誤格式，系統立刻知道要停下來。在沒有合約規格的情況下，錯誤會繼續傳遞，等你發現問題時，已經在第四個 Agent 跑完之後了。

這也是為什麼 Auto-Fail 機制缺失是最常被忽略的設計問題。沒有 schema 驗證，pipeline 就沒有可靠的失敗點，每一次錯誤都會在不知道的階段被忽略。

系統角色設計：Supervisor 和分享幾個我在用的 Agent

整套系統的核心是 Supervisor，但不要把它想成人類 PM。Supervisor 是編曲家 orchestrator，這是我自己給它的名稱，它的工作只有一件事：讀取全域狀態，寫出任務派發文件。

Supervisor 有三個嚴格限制：不寫程式、不分析資料、不修改任何 Agent 的輸出。一旦 Supervisor 開始做這些事，它就從 orchestrator 變成了另一個普通 Agent，整個系統的控制層就消失了。

每一筆任務派發，Supervisor 必須明確指定四件事：

• 這個任務派給誰

• 它接收什麼格式的輸入

• 它必須產出什麼格式的輸出

• 以及如果輸出不符合預期，系統應該做什麼。

除了 Supervisor 外，還有其餘幾個 Agent，每個各有明確的職責邊界，設計多個 Agent 的執行順序時，先畫出資訊依賴圖，哪個 Agent 的輸出是另一個的輸入，這張圖決定了序列化的必要範圍：

• Competitor Analyst — 輸出競品結構化資料

• Market Analyst — 輸出目標族群與風險因子

• Domain Consultant — 驗證可行性，輸出 pass/fail

• Product Strategist — 輸出產品定義 JSON spec

• Designer — 輸出 design token 和 component 定義

• Frontend Engineer — 依規格實作前端程式碼

• Backend Engineer — 定義並實作 API、DB schema

• QA Engineer — 輸出測試計畫和 bug report

每個 Agent 在定義時都需要三個要素：

• input schema（接收什麼格式）

• output schema（輸出什麼格式）

• allowed actions（被允許做哪些操作）。

如果不知道如何定義輸出欄位，可以從「如果這個欄位空白，下一個 Agent 還能正確運作嗎？」來想，如果答案是「不能」，這個欄位就是必填。例如：通常市場分析師在做完競品分析後，一定得把市面上有哪些競品、優劣和SWOT等等，最後不管是產出表格還是報告都是一種輸出格式。

少了任何一個，pipeline 就無法可靠地自動驗證。

Phase 1：Discovery - 三個 Agent 依序跑

這邊因為這三個 Agent 有資訊依賴關係，我讓三個 Agent 依序執行：

這個設計的關鍵在於：Domain Consultant 是一個 validator，不是分析師。Validator Agent 的職責是做出二元判斷，不是提供更多分析，可以讓接下來的決策邏輯保持簡單：拿到 pass 就繼續，拿到 fail 就停止。

每個 pipeline 都需要至少一個這樣的 validator，沒有它，Supervisor 就要自己判斷「這份輸出算好還是不好」，又回到了不可驗證的狀態。

Discovery 階段是最一開始從發現痛點、定義問題的解段，參與這個階段的 agent 有：

• Competitor Analyst

• Market Analyst

• Domain Consultant

Competitor Analyst

Competitor Analyst 的核心問題只有一個：這個市場裡有哪些對手？他們各自的定價、優勢和弱點是什麼？輸出格式必須固定，且每筆競品記錄都要包含相同的欄位，因為 Market Analyst 要程式化地讀取這份資料，不是讓人類閱讀。設計這個 Agent 的輸出格式時，不是我們看不看得懂，而是「下游 Agent 需要讀取哪些欄位才能完成它的任務」。

Market Analyst

Market Analyst 的分析品質取決於 Competitor Analyst 給出的競品資料。

從這裡開始會有上下游關係，Market Analyst 接收前者的輸出（競品資料），加上原始的產品類別定義，然後產出三件事：目標客群是誰、市場上有哪些需求訊號、有哪些風險因子需要提前注意。這三件事必須同時存在於輸出中，缺一不可。

完成後會交給下一位繼續執行。

Domain Consultant

這裡我給了 Domain Consultant 一個明確的限制：如果要開始工作，得需要前面兩份分析結果，才能做出有依據的可行性判斷。

需要注意：平行化會讓下游 Agent 在資訊不完整的狀態下工作，得出的結論不可靠。

Domain Consultant 是這個階段最特別的 Agent，它不產出分析內容，只做一件事：讀取前兩份報告，回答一個 yes/no 問題：這個產品在市場上是否可行？

輸出只有兩個部分：結論（pass 或 fail）和具體理由列表。如果回傳 fail，Supervisor 讀到這份報告後，Discovery 階段整體標記為失敗，不進入 Phase 2。

Phase 2：Product Definition

Product Strategist 的輸出是整個 Claude Code multi-agent 系統的 唯一真相來源（source of truth）。

什麼叫做唯一真相來源？意思是後續所有 Agent：Designer、Backend、Frontend、QA，都必須引用這份文件作為依據，不能自己詮釋需求、不能假設沒寫到的細節。

這份文件的設計原則是：每一個欄位都是必填的，任何一個欄位缺失，pipeline 立即停止。

為什麼這麼嚴格？因為這份 spec 在後續每個階段都會被引用：Designer 依它設計 component，Backend 依它定義 endpoint，QA 依它寫測試案例。如果 feature 沒有驗收標準，QA 無法判斷測試通不通過；如果沒有 success_metrics，完成交付後也無從驗證價值。

設計「唯一真相來源」文件時，方法是列出所有下游 Agent 需要讀取的資訊，把它們全部設為必填欄位。

Phase 3：Design 的嚴格格式要求

Designer 不能只描述 UI，它的輸出必須是機器可讀的結構。因為 Frontend Engineer 在這個系統裡是 Agent 不是人類，沒有辦法閱讀「按鈕應該是藍色、帶有圓角、hover 時有陰影」這樣的自然語言描述，然後把它轉換成精確的實作。

Designer 必須輸出三個結構化文件：

• Design Tokens（定義顏色、間距、字體的具體數值）

• Component Definitions（每個 UI 元件的 props、支援的 states、以及 error_state 的具體樣式）

• Layout Specs（各個頁面的元件排列邏輯）。

其中 error_state 是必填欄位，理由很簡單：Frontend 在處理 API 呼叫失敗、表單驗證錯誤、或資料載入失敗時，需要知道每個 component 在錯誤狀態下應該長什麼樣子。如果這個欄位缺失，Frontend 只能自行發明錯誤樣式，導致整個產品的錯誤狀態呈現不一致。

怎麼判斷哪些 Design 欄位是必填？跟前面一樣，「如果 Frontend Agent 拿到一份缺少這個欄位的 Design 輸出，它能產出正確的程式碼嗎？」不能，就是必填。

Phase 4：Engineering - 先定權限，再寫程式

Engineering 階段的核心原則只有一條：權限先行，也就是合約。

Backend Engineer 在寫任何一行程式碼之前，必須先完成三份文件：

• API Endpoints Spec

• DB Schema

• Security Rules

這三份文件不是給人看的參考文件，它們是 Frontend 和 QA 的操作依據，格式必須精確到機器可讀的程度。

API Endpoints Spec 的主要用途在每一個 endpoint 必須定義它的完整 request 格式和 response 格式、是否需要認證、以及 rate limiting 規則。不能用「接收使用者資料，回傳 token」這樣的自然語言描述，這讓 Frontend 必須猜測欄位名稱，猜錯就會造成後續的越來越多的 bug。

DB Schema 要定義每張資料表的欄位名稱、型別、是否 nullable、主鍵和外鍵關係。

Security Rules 要定義每個輸入欄位的 validation 規則、哪些 endpoint 需要 auth、rate limiting 設定。這兩份文件同樣不能用自然語言描述，必須是 Frontend 和 QA 可以直接引用的結構。

Frontend Engineer 只能讀取 Backend 已定義的合約規格。這個規則有兩個方向的強制：如果 Frontend 使用了一個 Backend spec 裡沒有的欄位，系統自動標記 fail；如果 Backend 定義了一個 Frontend 從未使用的 endpoint，系統 flag 它，要求說明原因（是設計多餘了，還是 Frontend 遺漏了？）。

這個雙向強制的作用是：讓每一個介面不匹配的問題，在寫程式之前就被發現，而不是在 integration testing 的時候才爆出來。

Phase 5：QA - 強制測試清單與 Do-Not-Ship 機制

QA Engineer 的輸出是兩份文件：Test Plan 和 Bug Report。

Test Plan 的設計原則是三類測試缺一不可：

• functional tests（正常流程能不能跑通）

• edge case tests（邊界情況有沒有處理）

• security tests（已知攻擊向量有沒有防禦）

這三類測試覆蓋不同的失敗模式，每個 feature 必須在這三類裡各有至少一個 test case，任何 feature 缺少任意類別，QA 階段整體 fail。

Bug Report 記錄每一個發現的問題：

• severity（嚴重程度）

• affected_feature（影響哪個功能）

• reproduction_steps（重現步驟）

沒有 reproduction_steps 的 bug report 視為無效，Engineering 無法修一個他們不能重現的 bug。

安全測試是強制項目，不是建議。QA Engineer 必須模擬兩類攻擊：SQL injection（所有有資料庫寫入的 endpoint）和 auth bypass（所有 auth_required: true 的 endpoint）。

任何一個攻擊成功，build 立即標記 do_not_ship，回傳 Supervisor，工程階段必須重新執行後才能再次進入 QA。

這個 do_not_ship 機制的設計邏輯是：安全問題沒有「允許帶著 bug 繼續跑」的空間，它是一個對錯機制，通了才能繼續，沒通就必須退回。設計 QA Agent 的輸出格式時，把 do_not_ship 設為一個明確的欄位，而不是藏在 severity 分類裡，這樣 Supervisor 讀到輸出時不需要解讀語義，只需要判斷這個欄位的值。

失敗與重啟：從哪個 Phase 壞掉，就從那裡重來

當某個 Phase 失敗，系統的重啟邏輯很重要，也很容易做錯。

常見的錯誤做法是從 Phase 1 重新開始。如果 QA 在 Phase 5 失敗，重跑 Discovery 是在浪費 token，因為競品分析的結果沒有改變。

另外，我讓 Supervisor 維護一份全域狀態文件，記錄每個 Phase 的最新輸出和狀態（pass/fail/pending）。Supervisor 在每次派發任務前先讀這份狀態，決定從哪裡開始。

Claude Code 設置：CLAUDE.md 和三個資料夾

知道架構怎麼設計之後，來看怎麼在 Claude Code 中實際建起來。

第一步：建立空的 CLAUDE.md

CLAUDE.md 是 Claude Code 讀取全域規則的入口。先建這個檔案，之後所有 Agent 的共用限制都寫在這裡，例如「所有 Agent 輸出必須是 valid JSON」、「Supervisor 不得產出 JSON 以外的任何內容」。

第二步：建立三個資料夾

your-project/
├── CLAUDE.md
├── rules/
│   ├── global-constraints.md
│   └── security-checklist.md
├── agents/
│   ├── supervisor/
│   │   ├── prompt.md
│   │   ├── input-schema.json
│   │   └── output-schema.json
│   ├── competitor-analyst/
│   │   ├── prompt.md
│   │   ├── input-schema.json
│   │   └── output-schema.json
│   └── ... (其他 Agent)
└── skills/
    ├── generate-api-spec.md
    ├── run-security-tests.md
    └── validate-json-schema.md

• rules/ 存放所有全域限制，所有 Agent 都必須遵守。

• agents/ 裡每個 Agent 有獨立資料夾，包含它的 prompt、input schema 和 output schema。

• skills/ 存放可重用的函式定義，例如「生成 API spec」「執行安全測試」「驗證 JSON schema」。

最重要的一條規則

Agent 只能呼叫 skills，不能直接呼叫其他 Agent。所有 Agent 間的溝通都透過 Supervisor 的任務派發文件進行。這條規則確保整個系統的控制權始終在 Supervisor 手上，任何繞過 Supervisor 的直接通訊都是架構違規。Anthropic 在 Building effective agents 中也強調這個核心設計原則：orchestrator 和 subagent 職責分離是 multi-agent 系統可靠運行的基礎。

常見問題

Q：如果只有兩三個人的小團隊，這套架構是不是太複雜？

A：Agent 數量可以縮減。Discovery 的三個 Agent 可以合併成一個，Design Agent 可以跳過 token 定義只輸出 component。但 Supervisor 的結構化派發格式和 QA 的強制安全測試，無論團隊大小都不應該省略。

Q：Supervisor 的全域狀態文件要怎麼維護？

A：在 Claude Code 中，最簡單的做法是在專案根目錄建立一份 pipeline-state.json，記錄每個 Phase 的狀態和最新輸出路徑。Supervisor 每次執行前讀取這份文件，結束後更新它。

Q：Phase 4 的 DB schema 要寫多詳細？

A：至少包含每張表的欄位名稱、型別、是否 nullable、主鍵和外鍵關係。不需要是完整的 migration script，但 Frontend 和 QA 必須能從這份文件推斷出所有資料結構。

總結

Multi-Agent 系統難跑，大多數失敗都發生在角色是「描述」而不是「明確的合約規格」，這容易讓每個下游 Agent 都在對一個可能錯誤的輸入繼續工作。

Input schema、output schema、allowed actions，三個要素缺一不可。五個階段的流水線，每個階段都是一道閘，通不過就不往下走。

用這套架構在自己的 Claude Code 專案中建立第一個 CLAUDE.md 和 agents/ 資料夾，從 Supervisor 開始定義，把它的 output schema 鎖死。剩下的包含 agents, skills 都可以慢慢加，很快一個小型團隊就成形了！

如果你只把 Claude 當成一個「比較聰明的聊天機器人」，你大概只用到它能力的一小部分。

Claude 怎麼用，其實取決於你選的是哪一個功能， Anthropic 提供了四種截然不同的方式。這篇文章會一次說清楚：從零開始怎麼下載、免費版夠不夠用，以及 Chat、Code、Cowork、Dispatch 分別適合什麼人。

Claude 目前有四種使用方式：Chat（網頁對話）、Code（開發者編程工具）、Cowork（讓 AI 在你電腦上工作的桌面模式）、Dispatch（從手機遠端指派任務給電腦上的 Claude）。

免費版只能使用 Chat，Cowork 和 Dispatch 需要付費方案才能解鎖。

Claude 不只是一個聊天機器人

大多數人認識 Claude，是從 claude.ai 那個對話框開始的。你打字，它回答，很像在傳訊息。但 Claude 的開發公司 Anthropic 所打造的，是一個多入口平台，不只有聊天。

目前 Claude 有四種主要使用方式。

Chat 是最入門的版本，透過網頁或 App 對話。

Code 是給軟體工程師設計的編程工具，能讀懂整個程式碼庫。

Cowork 讓 Claude 實際操作你的電腦，幫你完成複雜的檔案整理、報告製作等工作。

Dispatch 是最新推出的功能，讓你從手機就能遠端指派任務給在桌電上執行的 Claude。

同一個 AI，四種截然不同的使用情境。選對入口，效率差距可以很大。

下載與開始：怎麼取得 Claude？

Claude 的取得方式比你想的更靈活，依使用情境可以選擇最適合的入口。

Web 版（最快開始）

直接在瀏覽器開啟 claude.ai，用 Email 或 Google、Apple 帳號登入就能用。不需要下載任何東西，也不需要先付費。這是試用 Claude 門檻最低的方法，大多數新手從這裡開始就對了。

桌面版（Cowork 與 Dispatch 必備）

如果你想使用 Cowork 或 Dispatch 功能，需要安裝桌面版 App。前往 官網 下載，Mac 和 Windows 都有支援，安裝方式和一般軟體相同。

行動版（隨身使用）

iOS 和 Android 都有官方應用程式，在 App Store 或 Google Play 搜尋「Claude」即可找到。行動 App 主要提供 Chat 功能，也是使用 Dispatch 傳送任務的管道之一。

Claude for Chrome（瀏覽器工作者適用）

在 Chrome 上安裝官方擴充功能，可以在任何網頁旁邊呼叫 Claude 輔助工作。這個功能需要付費方案才能使用。

免費版夠用嗎？Claude 各方案費用一次看懂

Claude 的計費分幾個層級，從完全免費到企業方案都有。以下是個人用戶最常碰到的四個選項：

免費版（Free）

• 費用：$0

• 可使用 Claude Sonnet 4.6，支援文字對話和圖片分析。每天的訊息次數有限制（Anthropic 未公開具體數字），尖峰時段可能更受限。日常問答、寫作輔助，免費版通常夠用。

Pro 方案

• 費用：每月 20 美元（約台幣 650 元，依當時匯率為準）

• 用量是免費版的 5 倍，尖峰時段有優先使用權，並解鎖 Cowork 等進階功能。這是大多數重度使用者選擇的起點。

Max 方案

• 費用：每月 100 美元（5 倍 Pro 用量）或 200 美元（20 倍 Pro 用量）

• 適合高頻率使用者或需要 Dispatch 功能的進階用戶，可優先體驗最新功能。費用較高，通常是長時間依賴 Claude 輔助工作的人才會考慮。

Team 方案

• 費用：每人每月 25 美元（年繳），適合 5 到 100 人的中小型團隊。

以上費用以美元計，請依實際匯率換算。Cowork 和 Dispatch 需要付費方案（Pro / Max / Team）才能使用。

Claude Chat：最熟悉的對話

Claude Chat 就是大多數人第一次碰到的 Claude，打開 claude.ai，輸入問題，等待回答。

它支援文字對話、圖片分析和網路搜尋。你可以用它來撰寫電子郵件、整理或摘要長文件、翻譯和改寫文章，或是把你的截圖丟給它分析。免費版就能使用，行動版 App 和網頁版功能大致相同，隨手可用。

如果你的需求是對話式的 AI 輔助，Chat 就夠了，不需要特別安裝其他東西或升級方案。

Claude Code：工程師的 AI 編程夥伴

Claude Code 是給軟體開發者設計的工具，和一般「問 AI 怎麼寫程式」有本質上的不同。

它能讀懂你的整個程式碼庫，而不只是你貼上去的那一段 code。這意味著它在理解完整上下文的情況下，可以幫你找 bug、重構程式碼，或直接寫出符合你專案架構的新功能。舉例來說，如果你的專案有多個模組互相依賴，Claude Code 不會只看你貼的那一段，它會理解整體結構再給出建議。

Claude Code 可以整合進 VS Code 和 JetBrains 這兩款主流 IDE，也可以在 Terminal 用指令操作，幾乎不需要切換工作流程。

非技術用戶通常不需要 Claude Code。如果你不寫程式，Chat 或 Cowork 會更適合你的使用情境。

Cowork：讓 Claude 在你電腦上幫你做事

Cowork 是目前最接近「真人助理」體驗的 Claude 功能。它不只是回答問題，而是會實際動手在你的電腦上完成工作。

Claude 在 Cowork 模式下能夠直接存取你的本地資料夾，讀取和寫入檔案，不需要上傳或下載。它也能截取螢幕畫面、點擊滑鼠、輸入文字，就像一個真的坐在你電腦前的人。你可以讓它整理大量的檔案、製作 Excel 試算表或 Word 文件，或是跨多個資料夾蒐集整合資訊。整個過程是透明的，你可以隨時看到它在做什麼，也可以隨時介入調整方向。

需要注意的是：Cowork 目前仍在 Research Preview（研究預覽）階段，功能還在持續開發中，可能有限制或調整。使用 Cowork 需要安裝桌面版 App，並且需要 Pro、Max 或 Team 方案。

Dispatch：用手機把任務丟給 Claude，它在電腦上幫你搞定

Dispatch 是 Cowork 的延伸功能，讓你的 Claude 不只綁在電腦旁邊，你可以從任何地方發號施令。

比如你在外出途中，突然想到今天需要整理一份客戶資料。以往你得回到電腦前才能處理。有了 Dispatch，你可以直接從手機傳送任務給桌電上執行的 Claude，它會在你的電腦上完成工作，完成後通知你。

Dispatch 也支援排程任務：你可以設定「每天早上 9 點幫我整理昨天的 Email 重點摘要」或「每週五下午產出本週工作報告」，讓 Claude 成為一個在電腦上自動值班的助理。

使用 Dispatch 需要幾個條件：電腦保持開機並啟動桌面版 App、Pro 或 Max 方案，且目前仍在 Research Preview 階段，功能持續演進中。Dispatch 和「電腦使用（Computer Use）」是不同的概念，Dispatch 是任務派送的介面，電腦使用是它底層運作的技術能力。對一般使用者來說，你只需要知道 Dispatch 讓你從遠端掌控 Claude 幹活就夠了。

Claude 怎麼用才對？四種入口一張表幫你選

新手建議從免費版的 Claude Chat 開始。用個幾天，找到你真正常用的場景，再評估是否需要升級。對大多數日常使用者來說，免費版其實夠用很長一段時間。

如果你對在本地端跑 AI 模型有興趣（不依賴雲端服務），也可以參考用 Ollama 跑本地模型的介紹，那是完全不同的一條路。

常見問題

Q：Claude 免費版和付費版的差別是什麼？

A：免費版可以使用 Claude Sonnet 4.6 進行對話，但每天有訊息次數限制。付費的 Pro 方案（每月 20 美元）提供 5 倍用量、尖峰時段優先權，並解鎖 Cowork 等進階功能。Cowork 和 Dispatch 這兩個功能只有付費方案才能使用。

Q：Cowork 和 Chat 有什麼不同？

A：Chat 是對話式互動，你問它答，對話完就結束。Cowork 讓 Claude 真正在你電腦上「動手做事」，包括存取你的本機資料夾、製作文件、整理檔案，整個過程不需要你逐步下指令，Claude 會自主規劃並執行。

Q：Dispatch 是什麼？

A：Dispatch 是 Cowork 的延伸功能，讓你從手機或任何地方傳送任務給桌電上運行的 Claude。它也支援定期排程，讓 Claude 自動執行固定任務。目前需要 Pro 或 Max 方案，且仍在 Research Preview 階段。

Q：Claude Code 非工程師能用嗎？

A：Claude Code 是針對軟體開發者設計的工具，需要程式設計背景才能有效使用。非技術用戶用 Chat 或 Cowork 會更適合，功能更貼近日常辦公需求。

Q：Claude 怎麼用最省錢？

A：先從免費版的 claude.ai 開始。免費版已經包含 Claude Sonnet 4.6 和基本對話功能，對大多數日常需求而言夠用。當你頻繁遇到用量限制，或需要 Cowork 這類進階功能時，再考慮升級 Pro 方案是最合理的時機。

總結

Claude 怎麼用，沒有標準答案，但有個最簡單的起點：先從免費版的 claude.ai 開始，找到最適合你的工作流程後，再考慮是否升級付費方案。

一般用戶從 Chat 出發；如果你是工程師，值得試試 Claude Code；如果你想要 AI 真正「幫你做事而不只是回答問題」，Cowork 和 Dispatch 會讓你重新定義 AI 助理這個詞的意思。

最後提醒：Cowork 和 Dispatch 目前仍在 Research Preview 階段，部分功能可能持續調整。建議在 claude.com/pricing 確認最新方案與功能狀態再使用。

前幾天接上了 WordPress MCP，終於不用再一直上傳圖片、搞麻煩的 SEO 了，我直接請 Claude 幫我寫內容，然後直接把草稿存進我的 WordPress、上傳圖片到媒體庫然後設定 SEO 關鍵字，一條龍幫我搞定煩人的介面操作！這篇教學帶你從零開始，完成整個串接流程。

把 WordPress 串接到 Claude MCP 需要三個步驟：在 WordPress 安裝 mcp-adapter 和 Enable Abilities for MCP 兩個外掛、在 WordPress 後台產生應用程式密碼並編碼成 Base64 Token、最後把連線設定寫進 claude_desktop_config.json。截至本文撰寫時（2026 年 4 月），整個流程大約 10–15 分鐘就能完成。

什麼是 WordPress MCP，為什麼要串接？

MCP（Model Context Protocol）是一套讓 AI 工具連上外部系統的標準協定，由 Anthropic 推動。有了 MCP，Claude 就不只是一個對話視窗，而是能直接讀取和操作你連上的服務。

WordPress MCP 串接的核心是一個官方維護的 adapter 外掛，它在你的 WordPress 站台上建立一個 MCP endpoint。

Claude Desktop 透過這個 endpoint 發送指令，WordPress 執行後回傳結果。你在 Claude 裡問「最近有哪些草稿？」，Claude 就能真的去查你的 WordPress 後台，不是憑空回答。

串接完成後，Claude 可以做的事情包括：

• 建立文章草稿並自動填入標題、內文、分類

• 查詢已發布文章的列表和內容

• 把圖片從外部 URL 上傳到你的媒體庫

• 讀取和更新 Rank Math SEO 欄位

• 查詢留言、審核留言、回覆留言

事前準備：你需要什麼？

開始之前先確認幾個前提，避免中途卡關：

WordPress 站台：需要有外掛安裝權限的站台，自架 WordPress（self-hosted）才行。WordPress.com 免費方案不支援安裝自定義外掛。

Claude Desktop App：這篇教學以 Claude Desktop 為主，確認你已安裝最新版本。還沒用過 Claude 的可以先看 Claude 怎麼用完整指南。

Node.js：設定中會用到 npx mcp-remote 指令，npx 是 Node.js 內建的工具，建議安裝 v18 以上版本。macOS 用 Homebrew 可以執行：

brew install node

brew install node

還沒安裝 Homebrew 的可以參考 macOS 開發環境 Homebrew 設定教學。

會編輯 JSON 設定檔：後面需要手動修改 claude_desktop_config.json，任何文字編輯器（VS Code、Cursor、甚至記事本）都可以。

Step 1：安裝 WordPress MCP Adapter 外掛

這個步驟需要安裝兩個 WordPress 外掛：

第一個：WordPress MCP Adapter

前往 WordPress MCP adapter GitHub 下載 zip 檔。進入 repository 頁面後，點右上角綠色的 Code 按鈕，選 Download ZIP。

下載完成後，進入你的 WordPress 後台：

1. 左側選單點「外掛」→「安裝外掛」

2. 頁面頂端點「上傳外掛」

3. 選擇剛才下載的 zip 檔

4. 點「立即安裝」，安裝完成後點「啟用外掛」

第二個：Enable Abilities for MCP

mcp-adapter 建立了 MCP endpoint，但預設沒有開放任何操作。Enable Abilities for MCP 才是讓 Claude 能查文章、建草稿、上傳圖片的那把鑰匙，它提供一個控制台讓你切換要開放哪些能力。

同樣用上傳外掛的方式安裝並啟用，也可以在 WordPress 外掛目錄直接搜尋「Enable Abilities for MCP」安裝。

兩個外掛啟用後，你的 WordPress 就準備好接受 MCP 連線了。

Step 2：產生 WordPress 應用程式密碼與 Base64 Token

MCP 連線需要一組認證憑證，用 WordPress 的「應用程式密碼」功能來產生。

在 WordPress 後台產生應用程式密碼：

1. 後台左側選單點「使用者」→「個人資料」

2. 往下捲動到「應用程式密碼」區塊

3. 在「新增應用程式密碼」欄位輸入一個名稱（例如：Claude MCP）

4. 點「新增應用程式密碼」

5. 頁面會顯示產生的密碼，複製並保存，這組密碼只會顯示一次

應用程式密碼的格式通常是 xxxx xxxx xxxx xxxx xxxx xxxx，有空格是正常的。

把認證資訊編碼成 Base64：

Claude Desktop 的設定需要一組 Base64 編碼的字串，格式是 使用者名稱:應用程式密碼。

在終端機執行：

echo -n ‘your_username:xxxx xxxx xxxx xxxx xxxx xxxx’ | base64

echo -n ‘your_username:xxxx xxxx xxxx xxxx xxxx xxxx’ | base64

把 your_username 換成你的 WordPress 登入帳號，xxxx xxxx xxxx xxxx xxxx xxxx 換成剛才複製的應用程式密碼。執行後會輸出一串 Base64 字串，複製起來備用。

安全提醒：這組 Base64 Token 等同於你的 WordPress 登入憑證，不要貼進公開的設定檔或上傳到 Git 版本控制。

Step 3：設定 claude_desktop_config.json

找到 Claude Desktop 的設定檔，路徑依作業系統而不同：

• macOS：~/Library/Application Support/Claude/claude_desktop_config.json

• Windows：%APPDATA%Claudeclaude_desktop_config.json

用文字編輯器開啟這個檔案。如果檔案是空的，先建立一個基本的 JSON 結構再加進去：

{
  “mcpServers”: {
    “wordpress”: {
      “command”: “npx”,
      “args”: [
        “mcp-remote”,
        “https://your-domain.com/wp-json/mcp/mcp-adapter-default-server”,
        “--header”,
        “Authorization: Basic 你的Base64Token”
      ]
    }
  }
}

{
  “mcpServers”: {
    “wordpress”: {
      “command”: “npx”,
      “args”: [
        “mcp-remote”,
        “https://your-domain.com/wp-json/mcp/mcp-adapter-default-server”,
        “--header”,
        “Authorization: Basic 你的Base64Token”
      ]
    }
  }
}

把 your-domain.com 換成你的 WordPress 網域，你的 Base64Token 換成上一步產生的 Base64 字串。

如果設定檔裡已經有其他 MCP server 設定，在 mcpServers 物件裡新增 wordpress 這個區塊就好，不要覆蓋掉原有的設定。

儲存檔案後，完全關閉並重新啟動 Claude Desktop。

重啟後，在 Claude 的對話介面應該會看到工具圖示，點開確認 WordPress 相關能力已出現，代表串接成功。

串接後 Claude 能做什麼：MCP 可用方法一覽

WordPress MCP 串接完成後，Model Context Protocol 官方文件 說明了 MCP 能力的標準架構，而 Enable Abilities for MCP 外掛開放了以下這些操作：

文章管理
- ewpa/get-posts — 查詢文章列表，可以依狀態（草稿、已發布）篩選
- ewpa/get-post — 取得單篇文章的完整內容和 metadata
- ewpa/create-post — 建立新文章，預設存成草稿
- ewpa/update-post — 更新現有文章的任意欄位
- ewpa/delete-post — 把文章移到垃圾桶或永久刪除

頁面與自訂文章類型
- ewpa/get-pages / ewpa/create-page — 查詢和建立頁面
- ewpa/get-cpt-items / ewpa/create-cpt-item 等 — 完整管理自訂文章類型

媒體管理
- ewpa/get-media — 查詢媒體庫
- ewpa/upload-image — 從外部 URL 下載圖片並上傳到媒體庫，可同時設為文章的精選圖片

留言管理
- ewpa/get-comments — 查詢留言
- ewpa/moderate-comment — 核准、標為垃圾或移到垃圾桶
- ewpa/reply-comment — 以目前認證使用者身份回覆留言

SEO 設定（需安裝 Rank Math）
- ewpa/get-rankmath / ewpa/update-rankmath — 讀取和更新 Rank Math SEO 的所有欄位，包含 focus keyword、meta description、OG title

站台資訊與工具
- core/get-site-info — 取得站台基本資訊
- ewpa/site-stats — 查詢文章數、頁面數、留言數等統計
- ewpa/search-replace — 搜尋特定文章內容並取代

延伸應用場景

串接後可以讓 Claude 替你做這些事：

• 「列出最近五篇草稿，幫我整理標題建議」

• 「把這篇文章草稿存到 WordPress，分類設定為教學，標籤加 MCP 和 Claude」

• 「查一下 ID 為 123 的文章，Rank Math 的 focus keyword 是什麼？幫我更新成更準確的版本」

• 「幫我回覆所有待審核的留言，統一用繁體中文回覆謝謝支持」

這些操作從 Claude 的對話介面直接完成，不需要自己開 WordPress 後台。Claude Desktop 下載可以在 Anthropic 官方頁面取得最新版本。

常見問題

WordPress MCP 串接需要 Node.js 嗎？
是的，設定中使用 npx mcp-remote 指令，npx 是 Node.js 內建的工具，所以需要先安裝 Node.js（建議 v18 以上）。

應用程式密碼和一般 WordPress 登入密碼一樣嗎？
不一樣。應用程式密碼是 WordPress 5.6 之後引入的獨立憑證，只用於 API 認證，不影響你的後台登入密碼，可以隨時撤銷。

串接後 Claude 可以直接發布文章嗎？
可以建立草稿，但實際發布建議由人工在 WordPress 後台確認後再執行，避免未經審核的內容直接上線。

claude_desktop_config.json 在 Windows 的路徑在哪？
Windows 的設定檔路徑為：%APPDATA%Claudeclaude_desktop_config.json，通常在 C:Users{使用者名稱}AppDataRoamingClaude 資料夾內。

總結

WordPress MCP 串接的完整流程：安裝 mcp-adapter 和 Enable Abilities for MCP 兩個外掛、在 WordPress 後台產生應用程式密碼並編碼成 Base64 Token、把連線設定寫進 claude_desktop_config.json，重啟 Claude Desktop 就完成了。

去你的 WordPress 後台裝好外掛，花十分鐘完成設定，然後在 Claude 裡問一句「列出最近五篇文章」試試看。