AI Agent 5 種設計選型：什麼時候該用哪個、什麼時候別用（拆解微軟官方課程 L3 / L4 / L7 / L8 / L9）
微軟 AI Agents 18 課裡有 5 個章節是「怎麼蓋一個 agent」的設計層教材——Design Principles、Tool Use、Planning、Multi-Agent、Metacognition。比起把它們一課一課讀，更值得的是擺在一起對照：每個 pattern 的失敗模式、什麼時候別用、跟其他 pattern 怎麼配。這篇就做這件事。
為什麼這 5 課要一起讀
單看每個 pattern，你會學會「怎麼用 function calling 寫 tool」、「怎麼用 Pydantic 做 structured planning」、「怎麼設計 multi-agent hand-off」。但實戰上更貴的問題不是「怎麼做」、是「該不該做」。Tool use 的安全邊界要設多嚴？Planning 何時值得花 token 重規劃？Multi-agent 何時是過度設計？Metacognition 的反思到底有多深？這幾個判斷題沒有單一答案、只能在 5 個 pattern 互相對照中找出取捨原則。
所以這篇不是把官方課程翻成中文——是把 5 個 pattern 的「適用 / 不適用 / 失敗模式」做成一張選型表，並且指出微軟課程裡沒有明說的 trade-off。
5 種設計選型對照表
| 設計 | 核心問題 | 何時用 | 何時別用 | 主要失敗模式 |
|---|---|---|---|---|
| Design Principles（L3） | Agent 該如何跟人互動 | 每次設計 agent UX 都該套 | —（meta-frame、永遠適用） | 透明度不夠 → 用戶不信任 |
| Tool Use（L4） | 讓 LLM 跟外部系統互動 | 需要動態資料、執行程式、操作外部服務 | 純 reasoning / 文字轉換任務 | SQL injection、schema 描述不清 → LLM 選錯 tool |
| Planning（L7） | 把複雜目標拆成子任務 | 多步驟、子任務有依賴或需要 routing | 單步任務、子任務獨立可平行（直接 multi-agent 即可） | 分解粒度太細、re-plan token cost 失控 |
| Multi-Agent（L8） | 多個專業 agent 協作 | 大工作量、需要不同領域專長、需 fault tolerance | 單一 agent 即可勝任的簡單任務 | Coordination overhead、agent 之間 state 同步崩潰 |
| Metacognition（L9） | Agent 對自己決策反思 | 高代價決策、可獲得 feedback 的場景 | 低代價 / 一次性決策（反思成本 > 收益） | 「反思」只是策略二選一、不是真的重評估 |
Pattern 1 — Tool Use：安全邊界與框架抽象的選擇
Tool Use 的核心是把 function 的 schema 描述（名稱、用途、參數）丟給 LLM、讓它選擇要呼叫哪個 tool、回傳 tool name + arguments、由你的程式碼執行、再把結果丟回 LLM 生最終回答。這個迴圈手寫起來可以、但每次都要處理 message 拼接、tool_call_id 對應、error handling、state 累積——所以 Microsoft Agent Framework 用 @tool decorator 把這層抽掉、寫 Python function 就自動產生 schema 並接管整個迴圈。
課程裡最值得停下來的點是 Azure AI Agent Service 把 tool 分成兩類：Knowledge Tools（Bing Grounding、File Search、Azure AI Search）vs Action Tools（Function Calling、Code Interpreter、OpenAPI、Azure Functions）。這個分法不只是組織方便——它隱含一個設計判斷：「擴充知識邊界」跟「執行外部行動」的安全模型完全不同。Knowledge tool 即使被 LLM 誤用、頂多是回傳不相干的資料；Action tool 被誤用、可能是真的傳了一封 email 出去。設計時把 tool 預先分到這兩類、安全 review 的工作量會降一半。
官方明確點出的安全 trade-off：LLM 動態生成 SQL 有 injection 風險、但有效緩解就是把資料庫角色設成 read-only（PostgreSQL / Azure SQL 給 SELECT role）。這條紀律比想像中容易執行、卻很多團隊跳過——尤其是初期 prototype 階段「先讓它跑起來」的心態下。
什麼時候別用 Tool Use？純 reasoning 任務（例如把一段話分類成 5 類）、純文字轉換（翻譯、摘要）——這些不需要外部互動的任務、加 tool 反而徒增 schema 開銷跟 LLM 的選擇焦慮。Tool 是「agent 的手」、不是「agent 的腦」。
Pattern 2 — Planning：拆解與重規劃的成本
Planning 的核心是「把複雜目標拆成子任務」。官方 Travel Agent 範例拆成 FlightBooking / HotelBooking / CarRental / ActivitiesBooking / DestinationInfo 5 個子任務、每個 subtask 帶一個 assigned_agent 欄位、用 Pydantic BaseModel 強制 LLM 輸出 structured JSON、再 route 給對應 agent 執行。
這個範例的隱含設計決策是「structured output 換可靠性」——比起讓 LLM 自由生成「我建議先訂機票再訂飯店」這種自然語言、強制 JSON schema 讓下游 agent 可直接 parse、不必再做一輪 NLU。代價是 LLM 要記住 schema 結構、prompt 變長。在子任務數量穩定時這筆代價值得、在子任務動態變動時（每次都不同）就會卡。
更貴的判斷題是 Iterative Planning——當第一個子任務（例如訂機票）回傳的結果不如預期、要不要重新規劃整套？官方範例直接示範重新呼叫 planner 並把先前的 plan 當 context 傳入。但課程沒明說的是：每次 re-plan 都要重跑一次 planner LLM call、成本不便宜。實務上應該設定「re-plan trigger 條件」——例如只有當子任務失敗超過 N 次、或預算超出 X%、才觸發重規劃；否則固執走原 plan、結果好處理就好。
什麼時候別用 Planning？單步任務（一次 tool call 就解決）、子任務獨立且可平行（直接丟 multi-agent group chat 就好、不需要 planner）。Planning 的價值是「子任務之間有依賴或順序」——沒有依賴的工作流硬套 planner 是過度設計。
Pattern 3 — Multi-Agent：Coordination 機制決定成敗
Multi-Agent 的官方論述是 3 個好處：specialization（每個 agent 專做一件事、不會搞混）、scalability（要擴充加 agent 不必改既有）、fault tolerance（一個 agent 掛、其他繼續）。但課程裡更值得停下來看的是退款情境的 16 個 agent 列表——5 個專屬於退款流程的（Customer / Seller / Payment / Resolution / Compliance）+ 11 個跨流程通用的（Shipping / Feedback / Escalation / Notification / Analytics / Audit / Reporting / Knowledge / Security / Quality）。
這個列表的隱含訊息：真實 multi-agent 系統的 agent 數量比直覺想像多很多。第一次設計時容易只看到「核心 5 個」、漏掉跨流程通用的那 11 個——而那 11 個才是 multi-agent 真正的維護成本來源。
3 個常見 pattern：
- Group Chat：所有 agent 在同一 conversation 裡輪流發言、適合需要協商討論的場景（如 collaborative recommendation）。成本：對話冗長、token 高。
- Hand-off：agent 之間明確交棒、適合 workflow / customer support 這類有明確順序的場景。成本：交棒規則要清楚定義、否則卡住。
- Collaborative Filtering：多個專業 agent 各自評估、結果匯整給用戶。適合需要不同視角的決策（例如股票推薦結合產業 / 技術 / 基本面 3 種 agent）。
選哪個 pattern 的判斷準則：看資訊流。線性順序 → hand-off；發散討論 → group chat；獨立評估再匯整 → collaborative filtering。混用會讓 visibility 變極差——而 visibility 本身就是 multi-agent 的硬指標（官方明文要求 logging、monitoring、visualization、performance metrics 都要做）。
什麼時候別用 Multi-Agent？單一 agent + 多個 tool 就能解決時、別硬拆 multi-agent。增加 agent 的成本不只是寫 code、是 coordination overhead、state 同步、debugging 複雜度通通指數成長。
Pattern 4 — Metacognition：反思的真假
這課最容易被誤讀。乍看「agent 對自己的決策反思」聽起來很 sophisticated、但官方 HotelRecommendationAgent 範例的 reflect_on_choice 方法做的事情是：
- 用
cheapest策略推薦了一間飯店 - 檢查 user feedback（價格 < 100 或品質 < 7 → “bad”）
- 如果 bad、就把策略從
cheapest切換到highest_quality、重推一次
這算反思嗎？算——但是「2 個 hardcoded 策略之間二選一」這種反思。它不會產生新策略、不會質疑「為什麼只有這 2 個策略可選」、不會 reconsider 「品質 < 7」這條判定標準本身對不對。微軟原文也說了「simple form of metacognition」——「simple」這個詞值得圈起來。
真正深度的反思（自由生成新策略、質疑 meta 假設、重評估評估標準）每次都要重跑 LLM call、token cost 高。所以實務上的判斷不是「要不要做 metacognition」、是「反思要做到哪一層」：
- Layer 0：不反思 — 一次性決策、低代價場景
- Layer 1：策略二選一（如官方範例）— 中等決策、預定義策略池
- Layer 2：feedback 重排序（Corrective RAG）— 知識檢索場景、需要持續校正
- Layer 3：自由生成新策略 — 高代價決策、只在重要的少數場景用
什麼時候別用 Metacognition？低代價或一次性決策（反思的 token cost > 改善收益）、沒有可靠 feedback signal 的場景（沒辦法判斷「上次選得好不好」就無法反思）。
Design Principles 在 4 個 pattern 之上的角色
Lesson 3 的 Design Principles 不是第 5 個 pattern、是套在前面 4 個 pattern 上的 UX 約束。3 條 guideline：
- Transparency：告訴用戶這是 AI、它做了什麼、怎麼給 feedback
- Control：讓用戶可以自訂、刪除歷史、控制 agent 開關
- Consistency：跨裝置 / 模態的 UX 一致、用標準 icon、減低認知負荷
這 3 條對 4 個 pattern 的影響：Tool Use 要透明（讓用戶知道呼叫了哪些 API）；Planning 要 transparency（讓用戶看到拆解結果可以介入）；Multi-Agent 要 visibility（不只內部 debugging、用戶該知道哪個 agent 在跟他互動）；Metacognition 要 control（讓用戶能 override 或關掉反思迴圈）。
更核心的一條原則：「Embrace uncertainty but establish trust」——不確定性是 agent 的特徵、不是 bug；但要靠 transparency + user control 建立信任。這條原則對位的是「不要試圖把 agent 包裝成『100% 可靠』」、那個方向是死路（LLM 本質就是 probabilistic）；該做的是讓用戶清楚知道 agent 在做什麼、隨時能介入。
我的選型判斷框架
把 5 個 pattern 整合成一張判斷流程：
- 先問：這個任務真的需要 agent 嗎？ 純 reasoning / 文字轉換 → 直接 LLM call 即可、不需要 agent / tool。
- 需要 → Tool Use 是基礎。設計時先分 Knowledge tool vs Action tool、Action tool 走 read-only role / 嚴格 schema。
- 任務複雜（多步驟有依賴）→ 加 Planning。但 re-plan trigger 條件要明確定義、別讓 LLM 自由 re-plan 燒 token。
- 需要不同領域專長或大量平行工作 → 加 Multi-Agent。先用 hand-off / group chat / collaborative filtering 三個 pattern 對位資訊流型態、再決定。同時把 logging / monitoring 設計進來、不是事後補。
- 決策代價高且有 feedback signal → 加 Metacognition。但先 layer 1（策略二選一）、不要一上來就 layer 3。
- 全程套 Design Principles：transparency 讓用戶看見、control 讓用戶介入、consistency 讓用戶不必重學介面。
這個流程的反向應用更值得看：「我已經有 multi-agent + planner + metacognition、但 agent 還是不好用」很大機率是漏了 Step 1——任務根本不需要這套架構、直接 LLM call 就解。AI 領域最常見的 over-engineering 就是把不需要 agent 的任務硬塞 agent 框架。
常見問題
5 個 pattern 一定要全用嗎？
絕對不是。多數實務 agent 只需要 Tool Use（最基本）+ Design Principles（UX 約束）就夠。Planning / Multi-Agent / Metacognition 是進階——任務不複雜時加它們是過度設計。判斷準則：每加一個 pattern、能不能說出具體的「沒有它會壞掉」的場景？說不出來就不要加。
Microsoft Agent Framework 跟 Azure AI Agent Service 的分工是什麼？
MAF 是 SDK、給開發者快速 prototype 跟迭代用、含 @tool decorator 等抽象。Azure AI Agent Service 是 managed runtime、把 tool calling 迴圈、conversation state、安全模型 server-side 託管、適合 production 部署。對應的工作流是 MAF 開發 → Azure AI Agent Service 部署。如果只 prototype 不上 production、用 MAF 即可、不必開 Azure 訂閱。
這 5 個 pattern 跟 LangChain / CrewAI 的同名概念一致嗎？
概念層大致一致——LangChain 也有 tool use、planning、multi-agent；CrewAI 強在 multi-agent 編排。差異在實作層：微軟這套全程綁 Azure 棧、structured output 用 Pydantic + AzureAIProjectAgentProvider；LangChain 用 LangChain expression language；CrewAI 用 Role/Task/Crew 抽象。概念可遷移、code 不可遷移。
原文出處：Microsoft AI Agents for Beginners — Lesson 3、Lesson 4、Lesson 7、Lesson 8、Lesson 9
