昨天談推理模型與測試期運算,重點是讓模型會「想」——在回答前多花算力去思考、檢查、修正;今天要談的是讓模型會「做」。一個只會輸出文字的模型,再會想也困在對話框裡:它查不到今天的股價、發不出郵件、跑不了程式。代理式 AI(Agentic AI)就是把「想」接上「做」的那條線——讓模型能呼叫外部工具、觀察結果、再決定下一步,把單次問答變成一連串自主行動的循環。這條路的技術骨架是工具呼叫(tool use / function calling)、ReAct 推理-行動循環、規劃與記憶、多代理協作,而 2024 年底 Anthropic 推出、2025 年爆紅的 Model Context Protocol(MCP),則把「模型怎麼接工具」這件事變成了跨廠商的統一標準。
📖 學
什麼是 AI agent:從「回答」到「行動」
先把名詞釐清。一個 LLM 本身只做一件事:給定文字,預測下一個 token。而 AI agent 是一套包住 LLM 的系統,讓它能感知環境、做決策、採取行動、觀察結果,再循環下去,直到任務完成。差別在「自主性」:傳統的問答是你問一句、它答一句,主導權在你;agent 則是你給一個目標(「幫我訂下週三飛東京最便宜的機票」),它自己拆解步驟、呼叫工具、判斷何時算完成,主導權部分交給了模型。
自主性有層級之分。最低階是「模型當路由器」:它只負責選一個預設好的動作,其餘由程式控制。中階是「工具呼叫迴圈」:模型在一個 while 迴圈裡反覆決定「下一步呼叫哪個工具、傳什麼參數」,直到它認為任務結束。最高階是「多代理自主系統」:模型能動態產生子任務、生成新的工具、甚至指揮其他 agent。層級越高,能力越強,但也越難預測、越難除錯——這組張力貫穿今天所有主題。
工具呼叫 / function calling 的運作原理
工具呼叫是 agent 的地基,原理比想像中樸素。你在請求裡附上一份「工具清單」,每個工具用 JSON Schema 描述:名字、用途說明、參數格式。例如 get_weather(city: string)。模型讀到使用者問「台北今天會下雨嗎」,判斷該用這個工具,於是不直接回答,而是輸出一段結構化的呼叫意圖:{"name": "get_weather", "arguments": {"city": "台北"}}。
關鍵要認清:模型本身不會執行任何程式。它只是「產生一段格式正確的呼叫請求」。真正去打氣象 API、拿回資料的,是你外層的程式碼。程式把結果(例如「降雨機率 80%」)再塞回對話,模型這才根據結果生成給人看的自然語言回答。所以 function calling 的本質,是讓模型的自然語言意圖與外部世界的結構化介面對接。模型負責「判斷要用什麼、傳什麼」,你的程式負責「安全地執行、把結果餵回去」。這個分工是後面一切的基礎:模型是大腦,工具是手腳,而執行環境是你必須守住的關卡。
ReAct:推理與行動交錯的循環
有了工具呼叫,怎麼串成多步驟?最有影響力的答案是 2022 年 Yao 等人提出的 ReAct(Reasoning + Acting)。核心洞見是:讓模型交錯產生「思考」(Thought)與「行動」(Action),並在每次行動後讀取「觀察」(Observation),形成 Thought → Action → Observation → Thought… 的循環。
舉例:問「某演員最新一部電影的導演還拍過什麼?」純推理容易憑記憶瞎猜、出現幻覺;純行動又缺乏規劃、亂查一通。ReAct 讓模型先想「我需要先查這位演員的最新電影」(Thought),接著呼叫搜尋工具(Action),讀到片名(Observation),再想「現在查這部片的導演」……一步步逼近答案。思考幫它規劃與修正、行動幫它抓取真實資料,兩者互補。ReAct 的意義在於,它把昨天談的「思維鏈」從純內心獨白,升級成能與外部世界互動的迴圈——這正是「會想」到「會做」的接點,也是今天幾乎所有 agent 框架的骨架。
規劃與記憶:讓 agent 走得更遠
多步驟任務一長,兩個問題浮現:走偏了怎麼辦、上下文塞不下怎麼辦。這催生了規劃(planning)與記憶(memory)兩塊。
規劃是讓 agent 先把大目標拆成子任務再逐一執行,而非走一步算一步。常見手法有:先產生完整計畫再執行(Plan-and-Execute)、把問題拆成樹狀子問題、或在卡關時反思並重新規劃(如 Reflexion,讓 agent 讀自己失敗的軌跡、寫下教訓再重試)。
記憶則分兩種。短期記憶就是當前的上下文視窗——但它有限,一長串工具輸出很快就塞爆。長期記憶則把重要資訊寫進外部儲存(常是向量資料庫),需要時再檢索回來,這其實就是把昨天以前談過的 RAG 用在 agent 身上。好的記憶設計讓 agent 能跨越單次對話累積經驗、記住使用者偏好、避免重犯同樣的錯,是 agent 從「玩具 demo」走向「可用助理」的分水嶺。
多代理協作:分工與編排
單一 agent 什麼都做,容易顧此失彼;於是有了多代理(multi-agent)架構——讓多個各有專長的 agent 分工協作。常見模式有兩種。一是階層式:一個「協調者」(orchestrator)負責拆任務、派工,底下數個「工作者」(worker)各自處理子任務、回報結果,協調者再彙整。Anthropic 的研究型 agent 就採這種:主 agent 開多個子 agent 並行搜尋不同面向,最後綜合。二是對等協作:多個 agent 像圓桌會議互相辯論、審查彼此的產出(例如一個寫程式、一個當審查員挑錯),藉討論提升品質。
多代理的好處是專業分工與並行,但代價很實在:token 消耗成倍增長、agent 之間的溝通可能失真、系統整體更難預測。實務上不是 agent 越多越好——多數任務,一個設計良好的單 agent 配好工具,反而更穩、更省。
MCP:讓模型接工具的通用標準
工具呼叫解決了「模型怎麼表達要用工具」,但沒解決「工具怎麼被接上來」。在 MCP 之前,每接一個資料源(GitHub、Slack、資料庫)都得為特定模型、特定框架寫一份客製整合,N 個模型乘 M 個工具就是 N×M 份膠水程式,碎裂又難維護。
Model Context Protocol 是 Anthropic 於 2024 年 11 月開源的標準,用一句常見的比喻:它是「AI 應用的 USB-C」。架構是主從式——AI 應用(host,如 Claude Desktop、IDE)內嵌 MCP client,透過標準化的 JSON-RPC 通道連到各個 MCP server;每個 server 是某個外部系統(GitHub、Postgres、檔案系統)的專屬轉接頭,對外暴露三類能力:工具(tools,可被模型呼叫的函式)、資源(resources,可讀取的資料)、提示(prompts,預設好的範本)。一旦某工具做成 MCP server,任何支援 MCP 的 AI 應用都能直接用,把 N×M 變成 N+M。
MCP 的爆發速度驚人。到 2025 年底,官方數字是每月超過 9700 萬次 SDK 下載、逾一萬個公開 server,ChatGPT、Gemini、Cursor、VS Code、Copilot 等主流平台都已支援。2025 年 12 月,Anthropic 更把 MCP 捐給 Linux 基金會旗下、與 Block、OpenAI 共同發起的 Agentic AI Foundation,讓它從單一公司的專案變成中立治理的產業標準——這對一個要成為「共通協議」的東西至關重要。
風險:錯誤累積、安全與可觀測性
能力越強,風險越尖銳。第一是錯誤累積:agent 是多步驟循環,每一步都有出錯機率,步數一多,誤差會連乘放大。單步 95% 正確,十步連對只剩約 60%,一步走錯還可能污染後面所有推理。第二是安全:agent 能真的執行動作——刪檔、付款、發訊息、跑指令,一旦被惡意提示注入(prompt injection)劫持,或誤解指令,後果是真實世界的傷害,不再只是一句錯話。尤其接了 MCP 之後,工具的權限邊界、憑證管理、對外部 server 的信任都成了新的攻擊面。第三是可觀測性:當 agent 自主跑了二十步,若中間出錯,你得能回放它每一步的思考、呼叫、觀察,才知道哪裡壞了。因此 agent tracing(如 OpenTelemetry 的 GenAI 慣例、各家的 trace 工具)已成生產環境的必備。負責任地用 agent,意味著給它明確的權限邊界、人類在關鍵動作前確認(human-in-the-loop)、以及完整的日誌與監控。
🧠 記
- agent = LLM + 循環 + 工具:把「會想」的模型接上「感知—決策—行動—觀察」的迴圈,才成為能自主完成任務的 agent;自主性有層級,越高越強也越難控。
- function calling 的本質是分工:模型只產生「要呼叫什麼、傳什麼參數」的結構化意圖,真正執行的是你的程式;模型是大腦,工具是手腳,執行環境是你要守的關卡。
- ReAct 是骨架:Thought → Action → Observation 交錯循環,讓思考負責規劃修正、行動負責抓真實資料,兩者互補,是幾乎所有 agent 框架的基礎。
- MCP 把 N×M 變 N+M:一次做成 MCP server,所有支援 MCP 的應用都能用,是 agent 生態的「USB-C」;2025 年已成跨廠商產業標準並交由中立基金會治理。
- 風險隨步數放大:錯誤會連乘累積、agent 能造成真實傷害、複雜循環難以除錯;明確權限、關鍵動作人類確認、完整 tracing 是生產必備。
✍️ 實踐
- 手寫一個最小工具循環:用任一支援 tool use 的 API,定義一個簡單工具(如查時間或算數),寫一個 while 迴圈:送訊息 → 若模型要求呼叫工具就執行並回傳結果 → 直到模型給出最終答案。親手跑一次,你會徹底搞懂 agent 的運作機制。
- 裝一個 MCP server 來用:在 Claude Desktop 或支援 MCP 的 IDE 裡,接一個現成的 MCP server(如檔案系統或 GitHub server),實際讓模型讀你的檔案或倉庫。體會「接工具」從客製整合變成隨插即用的差異。
- 為你的 agent 加一道安全閘:在任何會產生副作用的動作(刪除、送出、付款)前,加一個人類確認步驟,並把每一次工具呼叫的輸入輸出都記錄下來。先把可觀測性與煞車做好,再談放大自主性。
🔗 延伸學習
- Introducing the Model Context Protocol(Anthropic） — MCP 的官方發布文,說明它為何存在、架構如何,是理解「模型接工具標準」的第一手來源。
- ReAct: Synergizing Reasoning and Acting in Language Models(arXiv 2210.03629） — 提出推理-行動循環的原始論文,今天幾乎所有 agent 框架的思想源頭。
- Model Context Protocol（Wikipedia） — 對 MCP 的中立整理:歷史、架構、採用現況與安全爭議,適合快速建立全貌。
- Donating the Model Context Protocol and establishing the Agentic AI Foundation（Anthropic） — 2025 年底把 MCP 交給中立基金會的公告,看標準如何從一家公司走向產業共治。
💬 問 AI
想真正搞懂代理式 AI,別停在名詞。把下面這段貼給你常用的 AI 助理,請它用一個具體任務帶你走一遍完整循環:
我想徹底理解「代理式 AI(Agentic AI)」是怎麼運作的。請以「幫我查某城市明天天氣並決定要不要帶傘」這個具體任務為例,一步步展示一個 agent 的完整循環:
1. 模型收到目標後,如何用 function calling 產生一個工具呼叫(請給出實際的 JSON 格式)?
2. 外層程式執行工具、把結果回傳後,對話裡發生了什麼?
3. 用 ReAct 的 Thought / Action / Observation 標註出每一步。
4. 如果查天氣的工具失敗了,一個有「規劃與反思」能力的 agent 會怎麼處理?
5. 最後,請說明這個流程若改用 MCP 來接工具,和自己寫客製整合相比,差在哪裡。
請盡量具體,能附上模擬的訊息內容或虛擬碼更好。