第一次做 AI Agent，先從一個 Agent、兩三個有明確輸入輸出的工具，以及一項可量化任務開始。 寄信、付款、刪除資料等高風險動作要設人工確認；流程需要中斷後續跑，再加持久化狀態。只有當不同子任務真的需要獨立指令、工具權限或上下文，才值得拆成 Multi-Agent。
這個順序能避開常見誤區：裝了框架便急著建立五個 Agent，結果成本增加、錯誤難追，連哪一步改善了業務結果都答不出來。想先理解 Agent 如何呼叫工具，可讀 AI Agent 原理；準備動手實作則參考 AI Agent 教學。
AI Agent 生態系有哪些層？
把 Agent 系統拆成六層，選型會比比較品牌清楚得多。
模型層負責理解、推理與產生內容，起步時用一個能穩定呼叫工具的模型即可。工具與資料層透過 function calling、API 或 MCP 查詢及改動外部系統。Agent 迴圈決定下一個動作與何時停止，所以要限制最大步數、逾時與可用工具。
當任務出現分支、重試、暫停或續跑，才進入編排與狀態層，常見元件包括 workflow、checkpoint 與持久化 store。執行環境層處理排程、併發、部署和祕密管理；可沿用既有後端、queue、serverless，或採用託管 runtime。最後的品質與治理層用 trace、eval、approval 與 audit log 管理成本、錯誤、權限及輸出品質。
框架通常只涵蓋其中幾層。OpenAI Agents SDK 提供 Agent、工具、handoff、guardrail、session 與 tracing；LangGraph偏向狀態與流程編排；MCP 則集中在工具和上下文交換。看到「一套包辦所有 Agent 問題」的產品描述時，先逐層檢查缺少的部分。
五個主流 Agent 框架怎麼選？
OpenAI Agents SDK：適合精簡的工具型 Agent。 TypeScript 與 Python SDK 都以少數基礎元件組合 Agent，支援工具、handoff、guardrail、session、人機協作、MCP 與 tracing。系統主要使用 OpenAI 模型，且流程不需要複雜圖狀狀態時，它能讓原型保持輕量。若你需要跨供應商模型治理或大量可恢復分支，還要自行補執行層或改用更強的編排工具。
LangGraph：適合長時間、可恢復且要精確控制的流程。 官方把它定位為低階 orchestration framework 與 runtime，核心能力包括 durable execution、persistence、human-in-the-loop 和記憶。它可以在同一張圖裡混合固定程式步驟與模型決策，代價是學習和維護成本較高。只有簡單問答加工具時，先用較高階的 agent abstraction 會更省工。
Google ADK：適合 Google Cloud 技術棧與多語言團隊。 ADK 是開源框架，支援 Python、TypeScript、Go、Java，能在本機執行，也能部署到 Agent Runtime、Cloud Run 或 GKE。它同時提供 workflow agent、動態路由、multi-agent、工具與評估能力。已使用 Gemini、Vertex AI 與 Google Cloud 權限管理的團隊，整合路徑最直接。
Microsoft Agent Framework：適合 Azure、.NET 與企業整合。 目前框架整合 Agent、Harness Agent、工作流與多種 provider，並提供 session state、middleware、MCP client、telemetry 等元件。官方明確稱它是 AutoGen 與 Semantic Kernel 的下一代主線；新專案不宜再只因舊文章多就預設從 AutoGen 起步。Go 版本仍有部分能力處於預覽，採用前要按語言確認功能差異。
CrewAI：適合用角色與任務表達協作。 CrewAI 將 Flows 用於狀態、事件與控制流程，Crews 用於讓多個專門 Agent 協作。研究、內容生產或內部流程原本就有清楚角色分工時，這種心智模型很好理解。若每一步其實都能寫成確定函式，直接放進 Flow 即可，沒有必要為每個步驟增加一個 Agent。
沒有永遠領先的框架。先做兩天內能完成的垂直切片，測試成功率、每件任務成本、人工介入率和 P95 延遲，再決定是否擴大採用。需要更細的編排比較，可接著看 Multi-Agent orchestration 實戰。
MCP 是 Agent 框架嗎？
MCP 不是 Agent 框架。 它定義 AI 應用如何透過 client-server 架構發現及使用 tools、resources、prompts 等能力。Host 會為每個 MCP server 建立對應 client，資料層使用 JSON-RPC；本機常見 stdio，遠端則使用 Streamable HTTP。
MCP 能降低每套 Agent 對每項資料源重寫連接器的負擔，但它不替應用決定工作流程，也不自動提供狀態保存、重試、排程、權限邊界或品質評估。接入第三方 MCP server 前，仍要檢查它能讀寫哪些資料、認證憑證放在哪裡、工具輸入是否受驗證，以及破壞性動作是否需批准。完整設定與風險可看 MCP 教學。
判斷方法很簡單：想讓 Agent 讀 GitHub issue 或呼叫 CRM，可考慮 MCP；想讓工作在失敗後從上一節點恢復，需要的是 workflow runtime 或持久化 queue；想限制退款金額，則要在工具層加入程式規則與人工審批。
單一 Agent 還是 Multi-Agent？
預設採用單一 Agent。它的 prompt、工具清單、trace 和成本都比較容易理解。當一個 Agent 被塞入過多互斥指令，或某些任務必須隔離資料與權限，才有充分理由拆分。
適合拆成多 Agent 的情況包括：
- 研究、分析、審核需要不同上下文和輸出標準。
- 子任務可真正平行執行，等待時間是主要瓶頸。
- 特定 Agent 只能存取特定資料或工具，權限需要隔離。
- 專家 Agent 要被多個入口重複呼叫，且有獨立評估集。
不適合拆分的訊號也很明確：每個角色只有一句人格設定、Agent 彼此反覆改寫同一段內容、錯誤發生後無法定位責任，或 token 成本翻倍卻沒有提高完成率。此時應合併角色，把可預測步驟改成函式，再以一個 manager 決定何時呼叫。更多常見設計可參考 AI 工作流規劃。
從原型走到 production 的最小路徑
- 鎖定一個任務與成功指標。 例如把客服單分類，目標是人工改標率低於 10%；「做一個萬用助理」無法有效評估。
- 先寫工具契約。 每個工具使用明確 schema、逾時與錯誤碼；寫入操作要有 idempotency key，避免重試造成重複寄信或扣款。
- 限制 Agent 邊界。 設最大回合、模型預算、允許工具與停止條件。資料查詢與資料修改分開授權。
- 保存可恢復狀態。 任務超過一次 HTTP request、需要等待人員核准或可能失敗重跑時，保存 checkpoint，不要只把完整對話塞回 prompt。
- 把高風險動作放入 approval gate。 金流、刪除、公開發布、帳號權限變更先顯示動作摘要與參數，由人確認後執行。
- 建立 trace 與回歸評估。 每次執行記錄模型、prompt 版本、工具參數、延遲、token 與結果。收集 30 至 50 個真實案例作為固定評估集，再比較改版。
框架選得普通，仍可透過清楚工具契約和評估逐步改善；缺少審批、觀測與失敗恢復時，再熱門的框架也很難成為可靠產品。
常見問題
第一次做 AI Agent，該選哪個框架？
主要使用 OpenAI 且流程短，可先試 OpenAI Agents SDK；需要長時間狀態、分支與中斷續跑，可評估 LangGraph；公司已深度使用 Google Cloud 或 Azure，優先比較 ADK 或 Microsoft Agent Framework 的權限、部署與觀測整合。先用同一組真實案例做小型驗證，再決定技術棧。
有 MCP 之後還需要 Function Calling 嗎？
需要。模型仍以結構化工具呼叫來提出動作；MCP 標準化的是 Host 與 Server 之間如何發現、描述和執行工具。應用內部少量且固定的工具可以直接使用 SDK 的 function tool，跨多個 Host 共用或由外部服務維護的工具更適合 MCP。
Multi-Agent 一定比單一 Agent 準嗎？
不一定。Multi-Agent 增加交接、上下文遺失、成本與除錯面積。它只有在角色分工、權限隔離或可平行子任務帶來可測量收益時才合理。先用單一 Agent 建立基準，才能知道拆分後是否真的改善。
AI Agent 上線前最少要測什麼？
至少測正常案例、工具逾時、回傳空值、無權限、模型拒絕、重試重複寫入、prompt injection 和人工拒絕執行。除了答案品質，也要記錄任務完成率、人工介入率、P95 延遲及每次成功任務成本。
參考來源
- OpenAI Agents SDK TypeScript 文件（查閱日期：2026-08-12）
- LangGraph overview（查閱日期：2026-08-12）
- Google Cloud：Agent Development Kit（更新日期：2026-08-07）
- Microsoft Agent Framework overview（更新日期：2026-08-10）
- CrewAI documentation：Introduction（查閱日期：2026-08-12）
- Model Context Protocol：Architecture overview（規格版本：2026-07-28；查閱日期：2026-08-12）