前陣子看到 ThisWeb（Kun）寫的〈6 大 Agent 模式〉，把常見的 Agent 架構分成六種：Single Agent、Sequential、Parallel、Loop／Review and Critique、Coordinator／Router、Agent as a Tool。分法很好用，整理一下自己讀完的理解，並補幾個原文沒特別提的地方。
六種模式在解決什麼問題#
先看六種模式各自的形狀，這樣後面讀文字比較好對照：
Single Agent 最單純，一個 Agent 自己理解需求、自己決定步驟、自己選工具，適合簡單查詢或快速做概念驗證（POC）。問題是任務一複雜，系統提示（System Prompt）就得不斷疊規則，模型還是可能漏步驟、選錯工具——本質上是把所有壓力都放在一個模型身上。
Sequential 把任務拆成固定順序，前一個 Agent 的輸出變下一個的輸入，像研究、寫作、校對排隊做。好處是可預測、好測試；代價是彈性差，中間想插一步很難，而且前面出錯會一路拖累後面。這個模式讓我想到傳統的Pipeline，只是把每個階段換成一個 Agent。
Parallel 把彼此沒依賴的子任務同時丟出去，最後用一個 Agent 彙整。省時間是真的，但成本會疊加，而且多個 Agent 各自產出的東西常常要花額外力氣去對齊、去重——彙整的那個 Agent 反而變成新的瓶頸。
Loop／Review and Critique 是兩個 Agent 互相競爭：一個負責產出，另一個負責審查，沒過就退回修改，直到通過或碰到迭代次數上限。這個模式跟驗證關卡、回饋品質怎麼設計，在之前寫 Loop Engineering 那篇有比較深入聊過的東西，迴圈退出機制沒設好，系統會卡在裡面一直修下去出不來。
Coordinator／Router 比較像專案經理，負責理解需求、拆解任務、決定交給哪個子 Agent，子 Agent 接手後自己決定怎麼做。彈性很高，能應付類型多變的任務，但路由判斷一旦錯，任務就交給了不適合的 Agent，階層一多，追蹤除錯的難度會跳得很快。
Agent as a Tool 是主 Agent 全程保留控制權，子 Agent 只在被呼叫時處理一件事、把結果丟回去，跟 Coordinator 最大的差別在於「誰管流程」——Coordinator 是把控制權暫時交出去，Agent as a Tool 則是主 Agent 從頭管到尾，子 Agent 更像一支會被呼叫的函式。這兩個常被搞混，因為架構長得很像，都是一個主要角色加多個專業角色，但控制權歸屬完全不同。好處是狀態集中好管理、彼此的上下文也互相隔離；代價是主 Agent 自己會變成最難維護的部分，呼叫的子 Agent 一多，複雜度全部堆在它身上。
六種放在一起快速比較大概是這樣：
| 模式 | 核心邏輯 | 主要代價 | 適合場景 |
|---|---|---|---|
| Single Agent | 一個 Agent 自己決定並執行到底 | 任務一複雜就容易漏步驟、選錯工具 | 簡單查詢、快速做概念驗證 |
| Sequential | 固定順序，前一步輸出接下一步輸入 | 彈性差，中途想插步驟很難 | 研究、寫作、校對這類固定流程 |
| Parallel | 沒依賴的子任務同時做，最後彙整 | 成本疊加，彙整常變成新瓶頸 | 多來源資料同時蒐集、批次分析 |
| Loop／Critique | 產出跟審查反覆迭代直到通過 | 退出條件沒設好會一直卡住 | 有明確品質標準的產出 |
| Coordinator／Router | 專案經理角色，拆任務、分派給子 Agent | 路由判斷一旦錯，會拖累整條線 | 任務類型多變、範圍廣 |
| Agent as a Tool | 主 Agent 全程管控，子 Agent 當工具呼叫 | 複雜度全部堆在主 Agent 身上 | 需要保留完整控制權的系統 |
Anthropic 原文的結構，跟 ThisWeb 六種模式不是同一種東西#
ThisWeb 這篇列的參考來源之一是 Anthropic 的《Building Effective Agents》，我去查了原文，發現兩邊的分類邏輯不在相同層級上。
Anthropic 原文先定義一個基礎概念叫「增強型 LLM」（Augmented LLM）——裝了工具、記憶、檢索能力的模型，是後面所有東西的地基。在這個地基之上，文章分成兩條路：工作流程（Workflow），流程由工程師事先寫好，模型只負責執行；Agent，流程由模型自己在跑的過程中決定，不是預先規劃好的路徑。工作流程底下才細分五種具體模式：Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer。Agent 是跟工作流程平行的另一整條分支。
ThisWeb 的六種模式，是把這整套階層結構攤平成一串平行項目來講。其中四種可以直接對照過去，細節看下面這張圖：
比較特別的是剩下的兩種。Single Agent 表面上很像 Anthropic 講的 Agent，但兩者意思不太一樣——Anthropic 的 Agent 指的是「流程自主決定」這整個分支，不是「只有一個 Agent 在跑」的意思。一個 Agent 就算在執行過程中自己決定要動態呼叫好幾個 subagent，在 Anthropic 的定義裡仍然算 Agent，不會因為牽涉多個實例就變成工作流程。所以 Single Agent 跟 Agent 看起來像：一個在講「牽涉幾個 Agent」，一個在講「流程由誰決定」，這是為了不同目的整理出來的兩套分類，不是同一套東西換了個講法。至於 Agent as a Tool，Anthropic 原文沒有這一項，比較像是後來從 Claude 的 subagent 架構延伸出來的講法。
Claude Code、Codex 怎麼混用#
Single Agent 跟 Agent as a Tool 這兩件事並不衝突，Claude Code 剛好是個現成的例子——它平常自己讀程式碼、自己決定下一步，這是 Single Agent；但遇到複雜子任務，它會自己判斷要不要叫一個 subagent 來處理，這時候看起來又像 Agent as a Tool。兩個答案都對，因為真實產品本來就不會只套進某一個分類框裡。ThisWeb 原文最後整理了 Claude Code 跟 Codex 實際上怎麼組合這幾種模式，我覺得是全篇最實用的地方——前面都是抽象分類，這段對到真實產品在做什麼。
底層核心是 Single Agent 加上工具呼叫（Tool Calling）跟自主迴圈（Agent Loop）：讀程式碼、改檔案、跑指令、驗證結果，根據終端機回饋的新資訊決定下一步，直到任務完成。任務拆解跟資訊隔離靠的是 Agent as a Tool：遇到需要大量讀檔或極度複雜的子任務，Claude Code 會啟動 subagent，subagent 在完全獨立的上下文視窗（context window）裡執行，做完只把摘要結果丟回主 Agent，避免長時間工作把上下文塞爆。多環境並發則是 Parallel Agent：Codex App 可以同時開好幾個 Agent，各自在獨立的執行緒和 git worktree 裡工作，同時修不同的 bug。
一個產品同時用了三種模式，剛好說明六種分類不是拿來挑一種用、而是拿來組合的積木。
MCP 跟 A2A：讓 Agent 接得上外部世界跟彼此#
這兩個協定常常被放在一起講，容易搞混，但解決的其實是不同層次的問題。
MCP（Model Context Protocol）是 Anthropic 2024 年 11 月發布的開放標準，解決的是「一個 Agent 怎麼接上外部工具和資料」——連 Slack、GitHub、資料庫，過去每個工具都要自己寫一套工具呼叫（Tool Calling）邏輯，MCP 統一了這個接口。A2A（Agent2Agent Protocol）是 Google 2025 年 4 月發布的，解決的是「不同 Agent 之間怎麼互相溝通、協作」，讓不同廠商、不同架構做出來的 Agent 能夠找到彼此、傳遞任務。Google 自己在發布時就講得很明確：A2A 是 MCP 的互補，不是取代——MCP 負責 Agent 跟工具之間的垂直連結，A2A 負責 Agent 跟 Agent 之間的橫向協作。
放進前面六種模式的脈絡來看，MCP 影響的比較是 Single Agent 或 Agent as a Tool 裡那個主 Agent 怎麼接觸外部世界，A2A 則是讓 Coordinator／Router 這類需要跨系統協作的模式，可以不只在同一套程式碼裡處理，還能跨組織、跨廠商運作。
我的想法#
六種列出來，不是每種都要用。任務簡單就用 Single Agent，步驟固定用 Sequential，子任務彼此獨立用 Parallel，結果需要通過品質標準用 Loop／Critique，任務類型多變交給 Coordinator，主要 Agent 必須保留完整控制權就用 Agent as a Tool。
比較想講的是：Agent 數量一多，模型成本、等待時間、除錯難度都會往上疊，這跟挑哪種模式沒關係，是規模本身的代價。而且自主性跟 Agent 數量不是唯一要分開看的兩件事，結果要不要反覆驗證、子任務要不要隔離上下文，也是獨立的問題——一個系統可以同時是自主的、平行的、又設了驗證關卡，不會選了一個特徵就用不到別的。六種模式可以說是幾條可以同時存在的設計軸線：放給模型自己判斷還是用固定流程鎖住、要不要拆成多個 Agent、要不要驗證、要不要隔離上下文，每條軸線可以分開選，不是選了一種就排斥其他的。
參考文獻#
- ThisWeb（Kun）— 6 大 Agent 模式：打造 AI 系統必懂的架構設計
- Anthropic — Building Effective Agents
- OpenAI — A practical guide to building agents