相信現在大家平常都會使用 Claude Code、Codex 提高生產力，但你知道這些工具背後用到哪些 Agent 設計方式嗎？
這篇文章會快速介紹 6 種常見的 AI Agent 設計模式，讓你了解 Agent 如何安排工作、分配任務與檢查結果。
這 6 分別為：
- Single Agent
- Sequential Agent
- Parallel Agent
- Loop／Review and Critique
- Coordinator／Router
- Agent as a Tool
Single Agent
Single Agent 是最單純的方式，它由一個 Agent 完成所有工作，Agent 會自行理解需求、決定步驟並選擇工具。
例如請它修正 Bug，它可能會依照以下步驟執行：
讀取程式碼 → 找出問題 → 修改檔案 → 執行測試
在這個過程中，所有任務都是一個 Agent 完成的。
Single Agent 優點
System Prompt 與程式架構簡單、彈性高，很適合快速建立原型。
Single Agent 缺點
但是當任務愈來越複雜時，就需要添加更多的 System Prompt 與規則。
而模型不一定每次都能遵守完整步驟，也可能漏掉步驟或選錯工具。
Single Agent 適合場景
簡單查詢、個人助理、工具較少的應用，以及流程不長、可以讓模型自行決定步驟的多步驟任務。
Sequential Agent
Sequential Agent 則是多個 Agents，按照固定順序執行任務。
系統會將任務拆成多個階段，前一個 Agent 的輸出會成為下一個 Agent 的輸入。
例如製作一篇文章，可以依照以下流程執行：
研究 Agent → 寫作 Agent → 校對 Agent
每個 Agent 會各自完成自己的任務。
Sequential Agent 優點
執行順序固定，具有較高的控制力與可靠性。各個 Agent 也可以透過共用的資訊來傳遞中間結果，流程也容易測試，執行結果也比較容易預測。
Sequential Agent 缺點
但是固定的結構難以因應動態需求，比如有時候在研究 Agent 階段發現資料包含大量數據，需要臨時加入資料分析 Agent 進行計算與解讀時，就無法調整。
而前面階段發生錯誤時，會影響後續結果；其中一個步驟改變時，也可能需要調整整條流程。
除此之外，花費的時間也會比 Single Agent 長。
Sequential Agent 適合場景
文件處理、內容發布、資料清理，以及高度結構化、需要重複執行，而且每一步存在依賴關係的流程。
Parallel Agent
Parallel Agent 則是讓多個 Agent 同時處理不同任務。
當子任務彼此沒有依賴關係時，就能交給多個 Agent 平行執行，縮短整體等待時間。
例如進行競品研究，我們就可以依照以下方式分工：
產品 Agent、價格 Agent、行銷 Agent 同時搜尋 → 彙整 Agent 整合結果
Parallel Agent 優點
能縮短等待時間，適合處理大量研究與分析工作。
Parallel Agent 缺點
同時使用多個 Agent 會提高模型成本，也可能產生重複或互相衝突的結果。
多數任務還需要額外的 Agent 彙整各個結果，增加架構與 System Prompt 的複雜度。
Parallel Agent 適合場景
多來源研究、批次文件分析、方案比較與多市場分析。這些任務可以拆成彼此獨立的部分，最後再統一彙整結果。
Loop／Review and Critique
Loop Agent 顧名思義，會反覆檢查並修改結果，通常會 2 個 Agent： Generator Agent 和 Critique Agent 共同完成任務。
Generator Agent 負責產生結果，Critique Agent 負責檢查結果是否符合要求。
審查沒有通過時，Critique Agent 會將意見交回 Generator 修改，直到結果符合條件或達到迭代上限。
例如修改一段程式碼，可以依照以下流程執行：
Generator 修改程式碼 → Critique Agent 審查 → Generator 根據意見修改
Loop Agent 優點
透過反覆審查與修改，可以提高結果品質，並檢查結果是否符合明確、不可省略的條件。
Loop Agent 缺點
多次迭代會增加成本與等待時間。
開發者還要設計通過條件、失敗處理與最大迭代次數，避免系統持續修改而無法結束。
Loop Agent 適合場景
程式碼審查、文章編輯、規範檢查，以及具有明確驗收標準、初次輸出可能需要多次修正的任務。
Coordinator／Router
Coordinator Agent 則是類似一個指揮家，會根據需求，將任務分配給合適的專業 Agent。
它負責理解問題、拆解任務與選擇 Agent，就像一位專案經理一樣。
任務分配完成後，子 Agent 會接手一段完整工作，並自行決定內部的執行方式。
子 Agent 也可以包含自己的 Sequential、Parallel 或 Loop 流程。
Router 通常只負責判斷需求類型，再將請求導向既有流程；Coordinator 還可能把大型任務拆成多個部分、安排執行順序並整合結果。兩者經常被放在一起討論，但 Coordinator 負責的範圍通常更廣。
例如收到不同類型的開發需求時，可以依照以下方式分配：
程式問題 → Coding Agent
資安問題 → Security Agent
測試問題 → Testing Agent
Coordinator Agent 優點
分工方式有彈性，可以動態拆解大型任務，再交給使用不同工作流的專業 Agent，適合處理類型多變的複雜問題。
Coordinator Agent 缺點
Coordinator 需要呼叫模型分析與分配任務，因此會增加成本與等待時間。
此外它也有可能會判斷錯誤，將任務交給不適合的 Agent。當分工、階層與執行流程變多時，系統會更難追蹤與除錯。
Coordinator Agent 適合場景
企業助理、客服平台、研究系統與大型開發任務，尤其適合需求會持續變化，需要根據當下要求選擇不同專業 Agent 的系統。
Agent as a Tool
Agent as a Tool 會把專業 Agent 當成主要 Agent 可以呼叫的工具。
主要 Agent 會保留任務的控制權與整體狀態，只在需要時呼叫專業 Agent 處理局部工作。
專業 Agent 每次接收明確的輸入，完成指定工作後回傳結果，再由主要 Agent 決定下一步。
Coordinator Agent 和 Agent as a Tool 差在哪裡？
Agent as a Tool 和 Coordinator Agent 有點類似，兩者的架構看起來很接近，都有一個主要 Agent 和多個專業 Agent。
主要差異在於工作交出去之後，誰負責控制流程與管理狀態，下面是一個表格用來表示他們的差異：
| 比較項目 | Coordinator Agent | Agent as a Tool |
|---|---|---|
| 主要 Agent 的工作 | 分析需求並決定由誰接手 | 規劃完整流程並呼叫需要的能力 |
| 子 Agent 的工作 | 接手一段完整任務 | 完成一項範圍明確的工作 |
| 控制權 | 執行責任暫時交給子 Agent | 始終由主要 Agent 掌握 |
| 狀態管理 | 子 Agent 可以管理自己的流程與狀態 | 主要 Agent 管理整體狀態 |
| 使用方式 | 像把工作交給團隊成員 | 像呼叫函式或工具 |
假設系統要檢查登入功能的安全性，Coordinator 可以把整段安全審查交給 Security Agent，由它讀取程式碼、找出風險並產出報告。
Agent as a Tool 則由主要 Agent 直接呼叫 Security Agent 取得檢查結果，後續的程式修改、測試與完成判斷仍由主要 Agent 負責。
這兩個概念不是互斥的架構，他們可能同時出現在一套系統裡，根據不同情況選擇合適的方式。
Agent as a Tool 優點
控制權集中、任務狀態清楚，可以由主要 Agent 統一管理對話與回覆，而且專業 Agent 可以重複使用。
Agent as a Tool 缺點
主要 Agent 需要負責規劃流程、管理狀態與整合結果。
呼叫的專業 Agent 愈多，主要 Agent 的工作就愈複雜，也可能成為整套系統最難維護的部分。
Agent as a Tool 適合場景
需要嚴格控制權限、統一對外回應、保留完整上下文，或需要整合多種局部專業能力的系統。
Claude Code 與 Codex 使用哪一種模式？
Claude Code 和 Codex 並非使用單一模式，而是混合使用多種 Agent 模式來應對複雜的軟體工程任務。
核心架構可以總結為以下三個層次：
-
基礎核心：Single Agent + Tool Calling + Agent Loop (模式 1 + 4) 這是最底層的運作邏輯。Agent 會不斷循環執行「讀取程式碼 -> 修改檔案 -> 執行指令 -> 驗證結果」的 ReAct 流程，並根據終端機反饋的新資訊動態調整下一步，直到任務完成。
-
任務拆解與上下文隔離：Agent as a Tool (模式 6) 當遇到需要大量讀取檔案或極度複雜的子任務時，Claude Code 會啟動 Subagents。
底層實現：這裡嚴格使用的是 Agent as a Tool (模式 6)，而非共享對話歷史的 Handoff (模式 5)。 核心目的：主 Agent 將子任務作為一個「工具」來呼叫，Subagent 會在完全獨立的 Context Window 中執行。完成後，它只將「摘要結果」返回給主 Agent。這完美解決了讀取大量程式碼導致的 Context 爆炸（上下文污染）問題。
-
多環境並發：Parallel Agent (模式 3) 在 Codex App 中，系統可以同時啟動多個 Agent，讓它們在獨立的 Thread 和 Git Worktree 中平行工作（例如同時修復三個不同的 Bug 或開發不同功能）。
如何選擇 Agent 模式？
| 模式 | 任務怎麼分配 | 主要優點 | 主要代價 | 適合的任務 |
|---|---|---|---|---|
| Single Agent | 一個 Agent 處理完整任務 | 架構簡單、彈性高 | 複雜任務容易漏掉步驟 | 簡單查詢、個人助理 |
| Sequential Agent | 按照固定順序逐步執行 | 流程穩定、容易測試 | 前一步錯誤會影響後續結果 | 文件處理、固定審核流程 |
| Parallel Agent | 多個 Agent 同時處理獨立子任務 | 能縮短等待時間 | 成本較高、結果可能衝突 | 多來源研究、批次分析 |
| Loop／Review and Critique | 產生、審查、修改並重複執行 | 能持續改善結果 | 需要控制成本與停止條件 | 程式碼審查、文章編輯 |
| Coordinator／Router | 根據需求分配給不同 Agent | 能處理類型多變的任務 | 分配錯誤時較難除錯 | 客服平台、大型開發任務 |
| Agent as a Tool | 主要 Agent 視需要呼叫專業 Agent | 控制權集中、能力可重複使用 | 主要 Agent 的整合負擔較高 | 權限明確的多能力系統 |
任務簡單而且需要快速開發時，可以使用 Single Agent。執行步驟固定時，適合使用 Sequential Agent。子任務彼此獨立時，可以使用 Parallel Agent。結果需要通過品質標準時，可以使用 Loop／Critique。任務類型複雜而且變化較大時，可以交給 Coordinator 分配。如果主要 Agent 必須保留完整控制權，則適合使用 Agent as a Tool。
Agent 數量增加時，模型成本、等待時間、狀態管理與除錯難度也會跟著提高，因此，我們可以在需要彈性的地方交給模型判斷，在需要穩定性的地方則使用明確的流程控制。
理解這 6 種設計模式後，就能進一步判斷各種 AI 工具的運作方式，並根據任務需求選擇合適的 Agent 架構。
參考來源：