昨天談 RAG，把重點放在「怎麼讓模型接上它沒背過的外部知識」——檢索片段、塞進上下文、生成有依據的回答。結尾提到 2026 分岔出的 agentic RAG：不再一次檢索到底，而是讓模型自己決定要不要再查、查什麼、查幾輪。那個「自己決定要不要再做一件事」的念頭，正是今天的起點。RAG 讓模型會「查」，而 agent 讓模型會「做」——呼叫工具、看結果、根據結果再決定下一步。從「檢索知識」跨到「採取行動」，是這兩天要接起來的那道橋。
📖 學
什麼是 AI agent，跟一次 prompt 差在哪
一次 prompt 是一問一答：你丟問題，模型丟回一段文字，結束。它靠的是訓練時記住的東西，中間不能查資料、不能算數、不能改。agent 則是把模型放進一個迴圈裡：模型可以先想、決定呼叫某個工具、拿到工具回傳的結果、再想、再呼叫、直到它認為任務完成才收尾。差別不在模型變聰明，而在它多了「行動」跟「觀察行動結果」這兩件事，於是能處理需要多步、需要外部資訊、需要中途修正的任務。
用一個具體例子感受落差。問「台北到高雄的高鐵最早幾點、票價多少」，純模型只能憑記憶回答，而且很可能過期或編造。agent 版本會這樣跑：想「我需要即時班次」→ 呼叫查詢工具 search_train(from, to, date) → 拿到 JSON 結果 → 讀出最早班次與票價 → 用自然語言回覆你。中間那次工具呼叫，就是 agent 的核心動作。
工具使用 / 函式呼叫的機制
function calling（也叫 tool calling / tool use）的機制其實不神秘，關鍵是「模型不直接執行工具，它只輸出一段結構化的呼叫請求」。流程分四步。第一步，你在請求裡附上一份工具清單（每個工具有名稱、說明、參數的 JSON schema）。第二步，模型判斷這題需要某個工具時，不吐自然語言，而是吐一段結構化資料，例如 {"tool": "get_weather", "arguments": {"city": "Taipei"}}。第三步，這段呼叫由你的程式（不是模型）真正去執行——打 API、查資料庫、跑計算——拿到結果。第四步，你把結果當成一則新訊息餵回模型，模型讀完再決定是收尾回答，還是再呼叫下一個工具。
這裡有個常被誤解的重點：模型本身沒有連網、沒有執行權，它只是很會「填出正確格式的呼叫」。真正的安全邊界、真正的執行，都在你的程式手上。這也是為什麼工具的說明文字要寫得清楚——模型是靠那段說明和 schema 來決定「什麼時候該用它、參數怎麼填」，說明含糊，模型就會亂呼叫或呼叫錯。
ReAct 迴圈：把「想」跟「做」交錯起來
ReAct 是 Reasoning + Acting 的縮寫，是最經典的 agent 運作骨架。它的想法是讓模型在每一步都輪流做兩件事：先寫下一小段推理（Thought，我現在該幹嘛、為什麼），再產生一個動作（Action，呼叫哪個工具），然後系統把工具結果（Observation）回傳，模型讀完進入下一輪 Thought。Thought → Action → Observation 一圈一圈轉，直到模型輸出最終答案。
這個交錯設計解決了一個很實際的問題：如果讓模型一口氣把所有步驟想完再一次執行，中途只要有一步的假設錯了，後面全盤皆錯。ReAct 讓它每做一步就看一眼真實世界的回饋，再修正下一步的判斷。在此之上還有兩個常見加強件。planning 是讓模型先把任務拆成子步驟、排出順序，再一步步執行，適合步驟多、依賴關係複雜的任務。reflection 是讓模型在做完（或卡住）之後回頭審視自己的產出——「這個結果合理嗎？有沒有漏掉？」——發現不對就重做。planning 管「開頭規劃」，reflection 管「事後檢查」，中間靠 ReAct 迴圈推進。
agent 的記憶：短期上下文 vs 長期記憶
agent 的記憶分兩層，混淆這兩層是很多人設計 agent 時的第一個坑。短期記憶就是當前對話的上下文視窗——這一輪任務裡的所有 Thought、Action、Observation 都堆在裡面，模型每一步都看得到。它的好處是即時、完整，壞處是有長度上限，任務一長、工具結果一多，上下文就爆了，而且塞越多、推理越慢越貴。
長期記憶則是把該記住的東西存到外部——通常是向量資料庫（就是昨天 RAG 用的那套），需要時再檢索回來。使用者三週前說過的偏好、上一個任務累積的經驗、專案的背景知識，都適合放這裡。所以你會發現 agent 的長期記憶跟 RAG 本質上是同一個機制：把知識存在外面，用時檢索。差別只在 RAG 檢索的是靜態文件，而 agent 的長期記憶檢索的往往是它自己過去產生的內容。短期記憶負責「當下這件事」，長期記憶負責「跨會話的連續性」，兩者搭配才不會每次都從零開始。
多代理協作與 orchestration
當任務大到一個 agent 扛不動，常見做法是拆成多個各有專長的 agent 分工。典型結構是一個 orchestrator（協調者/主管 agent）負責把任務拆解、分派給下面的 worker agent，每個 worker 專注做一件事——一個負責搜尋、一個負責寫程式、一個負責審查——做完把結果交回 orchestrator 彙整。這種分工的好處是每個 agent 的上下文更乾淨、提示更聚焦，也更好測試與替換。
但多代理不是萬靈丹。agent 之間要靠訊息傳遞溝通，一旦某個環節的輸出有偏差，會沿著協作鏈一路放大；而且開的 agent 越多，token 成本和延遲也跟著疊上去。實務上的判斷準則很樸素：能用單一 agent 加好工具解決的，就別急著上多代理；真的遇到「不同子任務需要非常不同的能力或上下文」時，多代理才划算。
2025–2026 的協定與生態
這一年多最重要的變化，是工具接法從各家各寫走向標準化，主角是 MCP（Model Context Protocol）。它由 Anthropic 在 2024 年 11 月開源，用意是替「模型如何連到外部工具與資料」定一套共通介面——把它想成「AI 工具界的 USB-C」：工具方只要實作一個 MCP server，任何支援 MCP 的 agent 都能接上，不必為每個模型各寫一套整合。標準化的威力在 2025 年迅速顯現：OpenAI、Google DeepMind、Microsoft 都在數月內跟進支援。到了 2025 年 12 月，Anthropic 更把 MCP 捐給 Linux 基金會底下的 Agentic AI Foundation，讓它成為中立、由社群治理的標準；同月的生態更新顯示公開的 MCP server 已超過一萬個，SDK 月下載量破九千萬，2026 年更攀到每月上億次。
另一條主線是 computer use / 瀏覽器代理——讓 agent 不只呼叫 API，還能直接操作圖形介面：看螢幕截圖、移動滑鼠、點按鍵盤、填表單、在瀏覽器裡跑流程。到 2026 年這已是量產品類：Anthropic 的 Claude 能操作整個桌面、Claude for Chrome 在 2025 年 12 月開放到所有付費方案，OpenAI 有 Operator 與後來的背景 computer use，Google 用 Project Mariner 操作瀏覽器。但別被行銷詞誤導：即使用上最強的 Claude Opus 4.8，在 OSWorld 2.0 這類「真實、多步、要跑很久」的基準上，2026 年中的完成率也只有兩成上下。會操作介面，跟能穩定把長任務做完，是兩回事。
三種模式對照
放在一起看，這三種用法的差別會更清楚。
| 面向 | 單次 LLM | RAG | Agent |
|---|---|---|---|
| 資訊來源 | 訓練時的記憶 | 檢索到的外部文件 | 工具即時取得 + 檢索 |
| 能否行動 | 不能，只輸出文字 | 不能，只是多餵資料 | 能，呼叫工具改變世界 |
| 步數 | 一步 | 通常一步（檢索+生成） | 多步迴圈，會自我修正 |
| 適合場景 | 通識問答、寫作潤稿 | 需有依據的問答 | 多步任務、要動手做的事 |
| 主要風險 | 幻覺、過期 | 檢索不準、拼接生硬 | 迴圈打轉、錯誤累積、成本高 |
要注意這三者是層層包住的關係，不是互斥選項：agent 內部很可能包著 RAG（用檢索當它的一種工具），而 RAG 本身也還是靠一次次 LLM 呼叫在運作。選哪個，取決於任務要不要「行動」、要不要「多步」。
失敗模式與可靠性工程
agent 迷人，但也脆弱，它的失敗模式跟純模型很不一樣。最常見的幾種：幻覺式工具呼叫——模型自信地呼叫一個不存在的工具、或把參數填錯格式；迴圈打轉——在幾個動作間反覆橫跳、就是不收斂，白燒 token；錯誤累積——第一步的小偏差沒被發現，後面每一步都建在錯誤上，離正解越來越遠；還有成本與延遲——每多一輪迴圈就多一次模型呼叫，長任務的帳單和等待時間會很可觀。
對付這些，靠的不是換更大的模型，而是一整套可靠性工程。限制步數：給迴圈設上限，跑到 N 步還沒完成就中止並回報，避免無限打轉燒錢。human-in-the-loop（人在迴圈）：在會造成不可逆後果的動作前——刪資料、送出付款、寄信給客戶——停下來等人確認，把最高風險的決策權留給人。可觀測性與評估：把每一步的 Thought、Action、Observation 完整記錄下來，出錯時能回放追查是哪一步歪的；並且用一組固定任務定期跑評估，量化「成功率、平均步數、平均成本」，改動 prompt 或工具後才知道是變好還變壞。一句話總結這門工程的心法：agent 的可靠性不是求它永遠對，而是設計成「它出錯時，你攔得住、看得到、修得回」。
🧠 記
- agent = LLM + 工具 + 迴圈：比一次 prompt 多了「行動」與「觀察結果」，所以能做多步、要動手、要即時資訊的任務。
- function calling 四步：給工具清單 → 模型吐結構化呼叫 → 你的程式執行 → 結果餵回模型。模型只會「填呼叫」，不直接執行，安全邊界在你手上。
- ReAct = Thought → Action → Observation 迴圈；planning 管開頭拆解，reflection 管事後檢查。
- 兩層記憶：短期是上下文視窗（即時但有上限），長期是向量庫檢索（跨會話，本質同 RAG）。
- MCP 是 2025–2026 的工具標準（AI 界 USB-C），2025/12 捐給 Linux 基金會，公開 server 破萬。
- 可靠性靠工程不靠奇蹟：限步數、human-in-the-loop、可觀測性與評估——目標是「出錯時攔得住、看得到、修得回」。
✍️ 實踐
今天做一個小到能在半小時內跑完、但涵蓋 agent 完整迴圈的練習：手寫一個「單工具 agent」的流程，不寫程式也行，用紙筆或對話走一遍。
- 定一個需要外部資訊的任務，例如「幫我算這個月訂閱服務總共花多少」。純靠記憶答不了，正好逼出工具。
- 設計一個工具：寫下它的名稱、一句說明、參數 schema。例如
list_subscriptions() -> [{name, price}]。刻意把說明寫清楚，體會「說明含糊模型就會亂用」。 - 手動走一輪 ReAct：寫下 Thought（我需要先拿到訂閱清單）→ Action（呼叫
list_subscriptions）→ Observation（自己編一組假回傳資料）→ 下一個 Thought（把價格加總）→ 最終回答。感受「想—做—看—再想」的節奏。 - 故意製造一個失敗：把 Observation 改成一筆錯誤資料，看你的迴圈會不會把錯誤一路帶到最終答案，這就是「錯誤累積」的體感。
- 加一道防線：在流程裡插入一個「若某筆價格 > 5000 就停下來問人」的 human-in-the-loop 檢查點，體會可靠性工程是怎麼加上去的。
進階者可以真的用支援 function calling 的 API（Anthropic 或 OpenAI 都有）把上面這個 agent 寫成幾十行程式跑起來，並在每一步 print 出 Thought/Action/Observation，親眼看它轉圈。
🔗 延伸學習
- Model Context Protocol 官方文件 — MCP 是什麼、怎麼寫一個 server / client，理解 2025–2026 工具標準化最權威的入口。
- ReAct: Synergizing Reasoning and Acting in Language Models（原始論文） — Thought/Action/Observation 迴圈的出處，agent 骨架的源頭。
- Anthropic：Building effective agents — 實務導向，講清楚什麼時候該用 agent、什麼時候不該，以及常見的協作模式。
- Wikipedia: Large language model（含 tool use / agents 段落） — 想要中立、概觀式的背景補充時的好起點。
💬 問 AI
把下面這段丟給 AI，讓它幫你把今天的概念變成能動手的東西：
我剛學了 AI agent、function calling 和 ReAct 迴圈。請幫我：
1. 用一個「查天氣並建議穿搭」的例子，完整走一遍 ReAct 迴圈，
把每一步的 Thought / Action / Observation 都寫出來。
2. 幫我設計這個 agent 需要的 1~2 個工具，包含名稱、說明、參數 JSON schema。
3. 指出這個 agent 最可能出現的 2 個失敗模式，並各給一個具體的防範做法
（例如限制步數、human-in-the-loop、記錄可觀測性）。
4. 最後用三句話對比「單次 LLM / RAG / Agent」在這個天氣穿搭任務上會怎麼做、
各自的極限在哪。
請用繁體中文（台灣用語）、具體、可執行，不要空泛。