[ai] AI Agent 設計模式：從 ReAct 到 Multi-Agent 協作

cover

什麼是 AI Agent

一個 LLM 呼叫只是「輸入 → 輸出」，但 Agent 是一個迴圈：

flowchart LR
    Perceive["感知 Perceive\n接收輸入\n觀察環境"] --> Reason["推理 Reason\n分析情境\n決定策略"]
    Reason --> Act["行動 Act\n呼叫工具\n產生輸出"]
    Act --> Observe["觀察 Observe\n檢視結果\n更新狀態"]
    Observe --> Reason

Agent 與單次 LLM 呼叫的差異：

面向	單次 LLM 呼叫	Agent
執行模式	一進一出	迴圈，直到任務完成
工具使用	無	可呼叫外部工具
記憶	無跨回合記憶	維護對話與工作記憶
規劃	無	可分解任務、排定步驟
錯誤處理	無	可觀察失敗並重試

Agent 的本質是讓 LLM 具備自主性——它不只回答問題，還能決定「接下來該做什麼」。

核心設計模式

ReAct（Reasoning + Acting）

ReAct 是最基礎也最廣泛使用的 Agent 模式。核心思路：讓 LLM 交替進行推理（Thought）和行動（Action），每次行動後觀察結果，再決定下一步。

sequenceDiagram
    participant U as 使用者
    participant A as Agent
    participant T as 工具

    U->>A: 問題：台北今天天氣如何？
    Note over A: Thought: 我需要查詢天氣API
    A->>T: Action: weather_api("台北")
    T-->>A: Observation: 晴天，25°C
    Note over A: Thought: 我有答案了
    A->>U: 台北今天晴天，氣溫 25°C

ReAct 的強項：

推理過程透明，可以追蹤每一步的 Thought
結合工具呼叫，能處理需要外部資訊的任務
自然地處理錯誤——觀察到失敗就重新推理

ReAct 的弱點：

長任務容易「迷路」（context window 累積過多雜訊）
每一步都是獨立決策，缺乏全局規劃
成本較高——每一輪推理都消耗 token

適用場景：問答、資料查詢、簡單的多步驟任務。

Plan-and-Execute

當任務複雜度超過 ReAct 的能力範圍，你需要先規劃再執行：

flowchart TD
    Task["複雜任務"] --> Planner["Planner\n分解任務\n產生步驟清單"]
    Planner --> Plan["計劃\n1. 收集需求\n2. 設計架構\n3. 實作功能\n4. 撰寫測試"]

    Plan --> E1["Executor 1\n收集需求"]
    Plan --> E2["Executor 2\n設計架構"]

    E1 --> Re["Re-planner\n根據執行結果\n調整後續計劃"]
    E2 --> Re
    Re --> E3["Executor 3\n實作功能"]
    E3 --> Re2["Re-planner"]
    Re2 --> E4["Executor 4\n撰寫測試"]
    E4 --> Done["完成"]

兩階段分離的好處：

Planner 專注全局：看見整體任務結構，不會迷失在細節中
Executor 專注細節：每個步驟獨立執行，context 更乾淨
Re-planner 動態調整：執行過程中發現問題可以修改計劃

實務範例：Claude Code 的 Plan Mode

Claude Code 的 EnterPlanMode 就是 Plan-and-Execute 模式的實作：

使用者請求 → 進入 Plan Mode → 探索 codebase → 設計方案
→ 使用者審核計劃 → 退出 Plan Mode → 逐步實作

Plan Mode 中 Agent 只能讀取和搜尋（Read、Glob、Grep），不能編輯或寫入。等計劃通過審核後才開始實作。這個分離確保了：

不會在沒有全局觀的情況下就開始改 code
使用者可以在實作前介入調整方向

適用場景：大型重構、多檔案修改、需要架構決策的任務。

Reflexion

Reflexion 在 ReAct 的基礎上加入了自我反思：

flowchart TD
    Task["任務"] --> Attempt["嘗試執行"]
    Attempt --> Eval{"評估結果"}
    Eval -->|成功| Done["完成"]
    Eval -->|失敗| Reflect["反思\n為什麼失敗？\n哪裡可以改進？"]
    Reflect --> Memory["記錄反思\n加入記憶"]
    Memory --> Attempt

與 ReAct 的差異：ReAct 看到錯誤會「再試一次」，Reflexion 會先分析「為什麼錯了」，然後用不同策略重試。

實務案例：

程式碼生成：跑測試 → 失敗 → 分析錯誤訊息 → 修改策略 → 重新生成
文章撰寫：初稿 → 自評品質 → 記錄改進點 → 修改

適用場景：有明確成功標準的任務（測試通過、品質分數達標）。

Tool Use 模式

Agent 的真正威力在於連接外部工具。工具設計決定了 Agent 的能力邊界。

flowchart LR
    Agent["AI Agent"] --> Tools

    subgraph Tools["工具集"]
        direction TB
        Search["搜尋\nWeb / DB"]
        Code["程式碼\n執行 / 分析"]
        File["檔案\n讀取 / 寫入"]
        API["外部 API\nNotion / Gmail"]
        Browser["瀏覽器\n截圖 / 操作"]
    end

工具設計原則

好的工具設計讓 Agent 更容易成功：

原則	說明	反例
單一職責	一個工具做一件事	`do_everything(action, params)`
清晰命名	名字就是說明	`tool_1`, `helper`
強型別參數	減少 Agent 猜測	用字串傳 JSON
有意義的回傳	回傳 Agent 需要的資訊	只回傳 true/false
錯誤訊息可操作	告訴 Agent 可以怎麼修正	”Error occurred”

Function Calling vs MCP

面向	Function Calling	MCP
定義方	開發者在 prompt 中定義	MCP Server 自行暴露
標準化	各平台各自實作	統一標準協定
可組合性	低	高——可組合多個 MCP Server
動態發現	不支援	支援——Agent 可查詢可用工具

MCP 的優勢在於標準化和可組合性。你可以同時連接 Notion MCP、Gmail MCP、GitHub MCP，Agent 自動知道有哪些工具可用。

Multi-Agent 模式

當任務的複雜度超過單一 Agent 的處理能力，就需要多個 Agent 協作。

主從模式（Orchestrator-Worker）

flowchart TD
    User["使用者"] --> Lead["Team Lead\n任務分配 & 整合"]

    Lead --> R["Researcher\n搜尋 & 分析"]
    Lead --> C["Coder\n實作 & 除錯"]
    Lead --> T["Tester\n測試 & 驗證"]

    R --> Lead
    C --> Lead
    T --> Lead
    Lead --> User

Team Lead 負責：

分解任務為子任務
分配給適合的 Worker
整合結果，處理衝突
向使用者報告進度

Worker 負責：

執行分配的子任務
回報結果和問題
必要時向 Lead 請求協助

實務範例：Claude Code Agent Teams

TeamCreate → 建立團隊
TaskCreate → 定義任務清單
Task tool → 啟動 Worker Agents
SendMessage → Agent 間通訊
TaskUpdate → 回報進度

每個 Agent 有獨立的 context，透過 SendMessage 通訊。這個設計的好處是 context 不會互相污染，壞處是通訊成本較高。

辯論模式（Debate）

sequenceDiagram
    participant P as Proposer
    participant C as Critic
    participant J as Judge

    P->>J: 提出方案 A
    C->>J: 反駁：方案 A 的問題
    P->>J: 修改方案 A'
    C->>J: 補充意見
    J->>J: 綜合評估
    Note over J: 選擇最佳方案

適用於需要批判性思考的場景：

Code Review（一個 Agent 寫，一個 Agent 審）
技術選型（不同 Agent 各自代表一個方案）
風險評估（一個 Agent 樂觀分析，一個悲觀分析）

流水線模式（Pipeline）

flowchart LR
    A1["Agent 1\n資料收集"] --> A2["Agent 2\n資料清理"]
    A2 --> A3["Agent 3\n分析摘要"]
    A3 --> A4["Agent 4\n報告生成"]

每個 Agent 只處理一個階段，輸出傳給下一個 Agent。優點是每個 Agent 的 prompt 可以高度專業化，缺點是整體延遲較高。

適用場景：ETL 流程、內容生成 pipeline、多階段審核。

模式選擇指南

flowchart TD
    Start["任務性質"] --> Q1{"需要多少步驟？"}
    Q1 -->|"1-3 步"| ReAct["ReAct\n簡單工具呼叫"]
    Q1 -->|"多步驟"| Q2{"需要全局規劃？"}
    Q2 -->|否| ReAct
    Q2 -->|是| Q3{"需要多個角色？"}
    Q3 -->|否| PaE["Plan-and-Execute\n單 Agent + 規劃"]
    Q3 -->|是| Q4{"角色間需要互動？"}
    Q4 -->|"順序處理"| Pipeline["Pipeline\n流水線"]
    Q4 -->|"需要協調"| Orchestrator["Orchestrator-Worker\n主從協作"]
    Q4 -->|"需要對抗"| Debate["Debate\n辯論模式"]

模式	複雜度	成本	適用場景
ReAct	低	低	簡單查詢、工具呼叫
Plan-and-Execute	中	中	多檔案修改、重構
Reflexion	中	中	需要自我修正的任務
Pipeline	中	中	固定流程、內容生成
Orchestrator-Worker	高	高	大型專案、多角色任務
Debate	高	高	需要批判思考、風險評估

記憶管理

Agent 的記憶分為三層：

flowchart TD
    subgraph Short["短期記憶（Context Window）"]
        CW["當前對話內容\n工具呼叫結果\n錯誤訊息"]
    end

    subgraph Mid["工作記憶（Session）"]
        TODO["任務清單\n進度追蹤\n中間結果"]
    end

    subgraph Long["長期記憶（Persistent）"]
        MEM["MEMORY.md\n專案慣例\n踩坑紀錄"]
    end

    Short --> Mid --> Long

記憶層	生命週期	載體	範例
短期記憶	單次對話	Context window	當前的 Thought/Action 歷史
工作記憶	單次任務	檔案 / TODO	任務進度、中間檔案
長期記憶	跨對話	MEMORY.md / DB	專案架構、踩坑經驗

記憶管理的挑戰

Context Window 壓力：Agent 每次工具呼叫的結果都會累積在 context 中。一個複雜任務可能產生數十次工具呼叫，導致 context 爆滿。

解決策略：

摘要壓縮：定期將歷史對話壓縮為摘要
選擇性保留：只保留與當前任務相關的工具結果
外部儲存：大量資料寫入檔案，只在 context 中保留路徑引用

跨對話遺忘：Agent 在新對話中不記得上次做了什麼。

解決策略：

MEMORY.md：自動記錄關鍵經驗和踩坑紀錄
Progress files：任務進度持久化（如 sync-progress.json）
TODO 系統：跨對話的任務追蹤

錯誤處理模式

Agent 的錯誤處理與傳統程式不同——它需要「理解」錯誤並決定如何應對。

重試策略

flowchart TD
    Action["執行動作"] --> Result{"結果"}
    Result -->|成功| Done["繼續下一步"]
    Result -->|暫時性錯誤| Wait["等待 + 重試\nRate limit\n網路超時"]
    Result -->|永久性錯誤| Analyze["分析原因"]
    Analyze --> Alt["嘗試替代方案"]
    Alt --> Action
    Wait --> Action

    Result -->|未知錯誤| Escalate["上報使用者\n請求指引"]

常見 Agent 失敗模式

失敗模式	症狀	預防策略
無限迴圈	重複同樣的動作	設定最大迭代次數
幻覺行動	呼叫不存在的工具	嚴格的工具清單
目標漂移	偏離原始任務	定期對照原始目標
Context 溢出	回應品質下降	摘要壓縮、外部儲存
過度自信	不驗證就宣稱完成	強制驗證步驟

實務建議

從簡單開始

不要一開始就用 Multi-Agent。大多數任務用 ReAct + 好的工具設計就夠了。只有當你確定單一 Agent 無法處理時，才升級到更複雜的模式。

單次 LLM 呼叫 → ReAct → Plan-and-Execute → Multi-Agent
      ↑
  從這裡開始

可觀察性

Agent 是黑盒子嗎？不應該是。確保你能看見：

每一步的 Thought（為什麼做這個決定）
每次工具呼叫的輸入和輸出
總 token 消耗和延遲
任務是否在預期路徑上

安全邊界

Agent 有能力執行危險操作。建立安全邊界：

權限控制：限制 Agent 可用的工具和操作範圍
人工審核：高風險操作前要求使用者確認
沙箱執行：程式碼執行在隔離環境中
操作日誌：記錄所有 Agent 的行動以供事後審查

Terry Yao's Blog

分類

目錄