M05.11｜Agentic AI 與 AI 代理系統：從工具到自主行動者
以前 AI 是你問它才答，現在 AI 會自己想、自己做、自己檢查
本講學習重點
Agentic AI 的核心定義： AI 能自主地感知環境、制定計劃、執行多步驟任務、並根據結果調整策略， 不再只是「一問一答」的被動回應。 傳統 Chatbot vs Agentic AI： - Chatbot：使用者提問 → AI 回答，單輪或多輪對話，但本質是「被動回應」 - Agentic AI：使用者給目標 → AI 自主拆解任務、規劃步驟、呼叫工具、檢查結果、修正錯誤 Agent 核心循環（OODA 變體）： 1. 感知 (Perceive)：接收使用者指令、環境狀態、工具回傳結果 2. 規劃 (Plan)：將大目標拆解成子任務，決定執行順序和所需工具 3. 行動 (Act)：呼叫工具（Tool Calling）、執行程式碼、存取資料庫 4. 反思 (Reflect)：檢查行動結果是否符合預期，決定繼續或修正 多代理系統 (Multi-Agent System)： - 不同 Agent 扮演不同角色（研究員、程式設計師、審核者） - 框架：CrewAI（角色扮演式）、AutoGen（對話式協作）、LangGraph（圖狀工作流） - 優勢：專業分工、平行處理、互相審核 - 風險：溝通成本、錯誤連鎖、難以除錯 Solution Graph（解決方案圖譜）： Agent 在面對複雜問題時，會展開一棵決策樹，探索多條可能路徑， 評估每條路徑的成功率，選擇最佳方案。類似下棋時的搜尋樹。 安全與可靠性機制： - Heartbeat 心跳：Agent 定期回報「我還活著」，超時未回報則觸發告警 - Failover 容錯：主 Agent 失敗時，備用 Agent 接手 - 超時防護：設定任務最大執行時間，防止 Agent 陷入無限循環 - 人類監督：關鍵決策點需要人類確認（Human-in-the-Loop）
🎙️ Podcast（中文）
一句話搞懂
Agentic AI 是能「自己想、自己做、自己檢查」的 AI——你給它一個目標，它會自主規劃步驟、呼叫工具執行、檢查結果對不對，如果不對就自己修正，而不是每一步都等你下指令。
白話解說
從「問答機器」到「自主行動者」
2023 年你用 ChatGPT，你問一句它答一句，本質上是「人類主導、AI 輔助」。但到了 2025-2026 年，AI 的使用方式正在發生根本性的轉變——你不再逐步指揮 AI，而是給它一個目標，讓它自己搞定。
舉個具體例子。傳統 Chatbot 的互動方式是這樣的：你說「幫我查一下台積電昨天的收盤價」，AI 回答「台積電昨日收盤價為 980 元」。然後你說「幫我算一下如果我買 10 張，總成本多少」，AI 回答「9,800,000 元」。每一步都是你在驅動。
Agentic AI 的方式完全不同：你說「幫我分析台積電是否值得現在買入，給我一份完整的投資分析報告」。然後 AI 自己去做：先查詢即時股價和歷史走勢（呼叫股票 API）、再抓取最新財報數據（呼叫財報資料庫）、分析技術指標（執行計算程式）、查詢分析師評等（搜尋網路資料）、最後整合成一份結構化的投資分析報告。整個過程可能涉及十幾個步驟和五六個不同工具，AI 全程自主完成。
這就是 Agentic AI——AI 從「被動的回答者」變成「主動的行動者」。
Agent 的核心循環：感知→規劃→行動→反思
所有 AI Agent 的運作邏輯，都可以歸結為一個四步循環，這與軍事決策中的 OODA 循環（觀察→定向→決策→行動）異曲同工：
第一步：感知（Perceive）。Agent 接收所有可用的資訊——使用者的原始指令、環境的當前狀態、之前行動的結果、工具回傳的數據。這就像你走進一間陌生的辦公室，先環顧四周，搞清楚有什麼資源可以用。
第二步：規劃（Plan）。Agent 把大目標拆解成可執行的子任務，決定先做什麼、後做什麼、需要用什麼工具。比喻來說，這就像一個專案經理接到需求後，先列出工作分解結構（WBS），排好優先順序和依賴關係。好的 Agent 在這個階段會考慮多條可能的路徑，選擇最有效率的一條。
第三步：行動（Act）。Agent 開始執行計劃——呼叫 API 查詢資料、執行程式碼做計算、讀取檔案提取資訊、甚至操作網頁瀏覽器。這裡的關鍵技術是 Tool Calling（也叫 Function Calling）：AI 模型能判斷「現在需要用哪個工具」，組裝正確的參數，呼叫工具，然後理解工具回傳的結果。
第四步：反思（Reflect）。Agent 檢查行動的結果是否符合預期。如果查詢的資料格式不對，它會換一個查詢方式；如果計算結果不合理，它會回頭檢查輸入數據。這個自我修正的能力是 Agentic AI 最關鍵的特質——它不會盲目地一條路走到底，而是會不斷評估和調整。
這個循環會持續運轉，直到任務完成或達到設定的上限。
Tool Calling：Agent 的「手」
如果把 AI 模型比喻為「大腦」，Tool Calling 就是它的「手」。一個沒有 Tool Calling 的 LLM 就像一個被綁住手腳的天才——腦子很好但什麼都做不了，只能說話。
Tool Calling 的運作方式是：開發者事先定義一組「工具」（每個工具有名稱、描述、參數格式），告訴 AI 模型有哪些工具可以用。AI 在思考過程中，如果判斷需要某個工具，它會輸出一個結構化的「工具呼叫請求」（通常是 JSON 格式），系統接收到請求後實際執行該工具，把結果回傳給 AI，AI 再根據結果繼續思考。
舉例來說，你問 Agent「台北明天會下雨嗎？」，Agent 不是從訓練資料中猜測答案，而是判斷「我需要查即時天氣」→ 呼叫天氣 API → 拿到氣象資料 → 根據資料回答你。這讓 AI 的回答從「基於舊訓練資料的猜測」變成「基於即時資料的判斷」。
多代理系統：專家分工協作
當任務足夠複雜，一個 Agent 可能不夠用。多代理系統（Multi-Agent System）讓多個 Agent 扮演不同角色，分工合作完成任務。
想像你要開發一個軟體產品。在多代理系統中，可能有這樣的分工：產品經理 Agent 分析需求、寫規格書；架構師 Agent 設計系統架構；程式設計師 Agent 寫程式碼；測試 Agent 寫測試案例並執行；審核 Agent 做程式碼審查。這些 Agent 各自專注自己的角色，彼此傳遞成果，就像一個真實的軟體開發團隊。
目前主流的多代理框架包括：CrewAI（角色扮演式，每個 Agent 有明確的角色、目標和工具）、AutoGen（Microsoft 的對話式協作框架，Agent 之間透過對話交換資訊）、LangGraph（圖狀工作流，把 Agent 的協作定義成有向圖）。
多代理的優勢是專業分工和互相審核——一個 Agent 寫的程式碼，由另一個 Agent 審查，能抓到很多單一 Agent 會遺漏的問題。但風險也很明顯：Agent 之間的溝通可能出現誤解、一個 Agent 的錯誤輸出會像骨牌一樣影響後續所有 Agent、整個系統的行為難以預測和除錯。
Solution Graph：Agent 的決策樹
面對複雜問題，好的 Agent 不會只想到一種解法然後一頭衝進去。它會展開一個 Solution Graph（解決方案圖譜）——類似下棋時的搜尋樹，探索多條可能的路徑，評估每條路徑的可行性和預期效果，選擇最佳方案。
比如你讓 Agent「幫我把這個 Python 程式的效能提升 10 倍」，Agent 可能同時考慮：(A) 用 NumPy 向量化取代 for 迴圈、(B) 用多執行緒平行處理、(C) 用 Cython 編譯關鍵路徑、(D) 改用更高效的演算法。它會先快速評估每條路徑的可行性和預期效果，選擇最有潛力的 1-2 條深入嘗試。
安全機制：Agent 不能「自己跑掉」
讓 AI 自主行動聽起來強大，但也讓人擔心——如果 Agent 失控了怎麼辦？如果它陷入無限循環一直燒 API 額度怎麼辦？如果它做了不可逆的操作（比如刪除了重要檔案）怎麼辦？
這些擔憂是合理的，因此 Agentic AI 系統必須配備完善的安全機制：
Heartbeat 心跳機制：Agent 定期向管理系統回報「我還活著，目前在做 XX」。如果超過設定時間沒有心跳回報，系統就知道 Agent 可能卡住了、當機了，或者陷入了無限循環，會自動觸發告警或強制終止。
Failover 容錯轉移：如果主要的 Agent（或它依賴的 LLM API）發生故障，系統自動切換到備用的 Agent 或模型繼續執行任務，而不是整個任務失敗。
超時防護：每個任務和子任務都設定最大執行時間。如果 Agent 在寫程式碼時陷入了「寫→測試→失敗→重寫」的無限循環，超時機制會在預設時間後強制中斷，並回報當前狀態讓人類接手。
Human-in-the-Loop（人類監督）：對於高風險操作（刪除資料、發送郵件、執行支付），Agent 必須暫停執行並請求人類確認。這是目前業界公認的最佳實踐——AI 可以自主做低風險的事，但高風險的事需要人類批准。
應用場景
| 場景 | 傳統 Chatbot 做法 | Agentic AI 做法 | 效益提升 |
|---|---|---|---|
| 軟體開發 | 問 AI「這段程式碼怎麼修」，逐行討論 | Agent 自動讀取程式碼庫、定位 Bug、撰寫修復、執行測試、提交 PR | 從逐句指導到端對端自動化 |
| 市場研究 | 人工搜集資料後請 AI 整理 | Agent 自動搜尋網路、抓取報告、分析趨勢、生成結論 | 數小時的研究壓縮到十分鐘 |
| 客服工單 | AI 建議回覆草稿，人工修改發送 | Agent 自動分類工單、查詢知識庫、生成回覆、簡單問題直接回覆 | 80% 的常見問題自動解決 |
| 數據分析 | 人工寫 SQL 查詢，再請 AI 解讀 | Agent 理解業務問題、自動寫查詢、視覺化、生成分析報告 | 非技術人員也能做數據分析 |
| 旅行規劃 | 問 AI 推薦景點，自己整合行程 | Agent 查航班、比價格、排行程、預訂飯店，產出完整旅行計畫 | 真正的端對端規劃 |
常見誤區
誤區一：Agent 就是聊天機器人加上記憶
這是對 Agentic AI 最常見的誤解。記憶（Memory）只是 Agent 的一小部分能力。Agent 真正的核心是「自主性」——它能主動規劃任務、呼叫外部工具、根據結果調整策略。一個有記憶的 Chatbot 仍然是被動的（等你問才答），而 Agent 是主動的（你給目標它自己去完成）。兩者的差距就像「一個記性很好的接線生」和「一個能獨立工作的專案經理」的差距。
誤區二：Agent 可以完全自主不需要人
目前（2026 年）的技術水準下，完全自主的 AI Agent 仍然不可靠。Agent 在執行多步驟任務時，錯誤會累積——每一步有 5% 的錯誤率，連續 10 步之後正確率只剩 60%。因此，Human-in-the-Loop（人類監督）不是技術不成熟的暫時方案，而是負責任地使用 Agent 的長期最佳實踐。高風險操作必須有人類批准，關鍵決策點必須有人類審核，Agent 的自主範圍應該被明確界定和限制。
誤區三：多代理一定比單代理好
直覺上，更多 Agent 協作應該效果更好，但實際上多代理系統有顯著的額外成本：Agent 之間的溝通需要消耗 token（每次溝通都是一次 LLM 呼叫）、協調邏輯增加系統複雜度、一個 Agent 的錯誤輸出會傳染給所有下游 Agent。對於大多數任務，一個設計良好的單 Agent（搭配合適的工具）比一群設計粗糙的多 Agent 更有效率也更可靠。多代理系統適合的是那些確實需要不同專業視角互相審核的場景（如程式開發 + 測試 + 審查），而不是所有任務都應該用多代理。
小練習
練習一：判斷 Chatbot 還是 Agent
以下五個 AI 應用場景，請判斷它更接近「傳統 Chatbot」還是「Agentic AI」，並說明理由：
- (A) 使用者上傳一份 PDF 合約，AI 回答使用者關於合約內容的問題
- (B) 使用者說「幫我把這個 GitHub repo 的所有 TODO 找出來，建立 Issue，並指派給對應的團隊成員」
- (C) 使用者問「Python 的 list comprehension 怎麼寫」，AI 給出範例和解說
- (D) 使用者說「監控我的伺服器，如果 CPU 超過 90% 就自動擴容，並通知我」
- (E) 使用者上傳一張圖片，AI 描述圖片內容
點擊查看參考答案
練習一：Chatbot vs Agent 判斷
- **(A) Chatbot**：AI 在被動回答問題，沒有自主規劃和行動。雖然涉及文件理解，但本質仍是「問→答」模式。 - **(B) Agentic AI**：涉及多步驟自主行動——搜尋程式碼、解析 TODO、呼叫 GitHub API 建立 Issue、查詢團隊成員、分配任務。AI 需要自主規劃和執行整個流程。 - **(C) Chatbot**：典型的知識問答，單輪互動，無需工具呼叫或多步驟規劃。 - **(D) Agentic AI**：這是最典型的 Agent 場景——持續感知（監控 CPU）、自主判斷（是否超過閾值）、自主行動（觸發擴容）、通知人類。Agent 在沒有人類持續指揮的情況下自主運作。 - **(E) Chatbot**：單一輸入→單一輸出，沒有多步驟規劃或工具呼叫。 **關鍵判斷依據**：是否涉及「自主規劃多步驟」和「主動呼叫外部工具執行行動」。如果 AI 只是被動回答問題（不管多複雜），就是 Chatbot；如果 AI 需要自己決定做什麼、怎麼做、然後去做，就是 Agent。練習二：設計 Agent 的安全邊界
你正在為一家電商公司設計一個「訂單處理 Agent」，它能自動處理客戶的退貨、換貨、退款請求。請設計這個 Agent 的安全邊界：(1) 哪些操作 Agent 可以自主完成？(2) 哪些操作必須要人類批准？(3) 需要設定什麼樣的超時和限額防護？