概述

在過去短短兩年裡，大型語言模型（LLM）應用經歷了一場驚人的蛻變。我們從驚嘆於 ChatGPT 能寫詩作對、回答知識性問題的「聊天機器人」時代，迅速躍遷到一個 AI 能為我們規劃異國行程、分析複雜財報，甚至直接預訂機票的「行動助理」時代。

這種轉變並非偶然，它代表著一個根本性的典範轉移。如果你的團隊還在討論如何優化 Prompt 來讓模型「說」得更好，那麼你可能忽略了更關鍵的問題：你的應用，還停留在單純的 Model-based（模型驅動） 階段，還是已經進化到了 Agent-based（智能代理驅動） 的新世代？

這個問題的答案，將決定你的應用是一個知識淵博的「瓶中精靈」，還是一個能感知世界、動手解決問題的「全能夥伴」。

Model 與 Agent 的根本區別

讓我們用一個具體的例子來思考：開發一個「AI 旅遊規劃師」。

• Model-based 的作法： 應用程式的核心是一個 LLM。當你問「我想去東京玩五天，有什麼建議？」，模型會動用它在訓練資料中學到的知識（比如截至 2023 年的資訊），給你一份籠統的、靜態的旅遊攻略。它就像一本離線的旅遊指南，知識豐富，但無法與當下真實的世界互動。
• Agent-based 的作法： 應用程式的核心是一個智能代理。當你提出同樣的需求時，它會開始一連串的行動：即時查詢下週從台北到東京的航班價格、在訂房網站上尋找符合你預算的飯店、查看目的地的天氣預報，甚至在你做出選擇後，直接呼叫 API 完成預訂，並將行程同步到你的行事曆。

正如 Google 在其發布的《Agents》白皮書中所闡述的，兩者最根本的區別就在於：是否擁有與外部世界互動的「工具（Tools）」。

https://drive.google.com/file/d/1W8EnoPXRLTQesfjvb-b3Zj-dnBf1f--n/view

一個 Model-based 應用是一個封閉的「大腦」，它的能力被訓練資料的邊界所禁錮。而一個 Agent-based 應用，則是在這個大腦的基礎上，賦予了它與世界連結的「手腳」和「感官」，使其能夠感知、思考、並行動。

Agent 的運作原理：工具與神經中樞

那麼，智能代理是如何使用這些「工具」來完成複雜任務的呢？這需要兩個核心組件的協同運作：工具集（The Toolset） 和 編排層（The Orchestration Layer）。

工具調用（Tool Invocation）

LLM 本身只是一個生成式推理引擎，但要具備「行動力」，就必須能夠調用外部工具（Tools）。所謂工具，其實就是一個被結構化描述的函式，讓 LLM 在理解自然語言需求後，可以轉譯成正確的輸入格式，交由工具執行，再把結果回傳給使用者。

從自然語言到工具輸入

假設使用者輸入問題：「What is 2 times 3?」

LLM 並不直接計算，而是識別出「乘法」這個意圖，並生成一個結構化的 payload：

https://langchain-ai.github.io/langgraph/concepts/agentic_concepts/#tool-calling-agent

這個 payload 與具體的工具綁定之後，就能完成真正的運算。

工具定義

工具的定義看起來就像一般函式，只是透過裝飾器或註解進行註冊：

@tool
def multiply(a: int, b: int) -> int:
    return a * b

這裡的 @tool 告訴 Agent，multiply 是一個可供調用的工具，並且清楚標示輸入與輸出的結構。

綁定與推理

Agent 的關鍵能力在於「推理 + 綁定」：

1. 推理：從自然語言中抽取出目標行為與參數。
2. 綁定：將抽取出的參數對應到工具定義，生成正確的調用格式。
3. 執行：調用工具獲取結果，再進一步加工或回覆。

換句話說，LLM 不需要知道「怎麼計算乘法」，它只需要知道「誰會計算」，然後正確地把參數交出去。

工具（Tools）：智能代理連結真實世界的手腳

工具是智能代理能力的無限延伸，它們是連接 LLM 核心大腦與外部世界的橋樑，而這些工具的形式遠比我們想像的要豐富。

外部 Extension 呼叫（Extension Calling）

https://drive.google.com/file/d/1W8EnoPXRLTQesfjvb-b3Zj-dnBf1f--n/view

平台（如 OpenAI, Germeni）提供 Extension 做為代理與外部服務之間的橋樑；代理把結構化請求交給 Extension，由 Extension 處理認證、配額、錯誤轉譯，再去打第三方 API（如 Google Flights）。

這樣一來，我們可以快速調用平台現成的穩定工具並且避免金鑰外漏以及額外的為運成本。但將來可能會受限於特定供應商平台支援。

內部 Tool / Function 呼叫（Function Calling）

https://drive.google.com/file/d/1W8EnoPXRLTQesfjvb-b3Zj-dnBf1f--n/view

有時，我們不希望或不能讓智能代理直接執行最終操作（可能出於安全、成本或流程複雜度的考量）。這時，「函式呼叫」就成了一種更優雅的模式。

它的核心是職責分離：

1. 智能代理的職責： 進行「決策」。它分析使用者的需求，判斷應該執行哪個內部函式，並生成一個包含函式名稱和所需參數的結構化指令（通常是 JSON 格式）。
2. 應用程式的職責： 負責「執行」。我們的後端程式碼接收到這個指令後，再安全地執行對應的函式。

例如，當使用者說「幫我訂一張去東京的機票」，智能代理不會直接去訂票，而是回傳一個指令：

{
  "name": "book_flight",
  "arguments": {
    "destination": "NRT",
    "date": "2025-12-20"
  }
}

我們的應用程式拿到這個指令後，再去執行 book_flight 這個函式內部的訂票邏輯。這確保了核心業務邏輯的執行權仍然掌握在我們自己手中。

智能代理作為工具（Agent as a Tool）

這是智能代理架構中最具擴展性的概念。一個工具不必是簡單的 API 或函式，它甚至可以是另一個更專業的智能代理。

一個複雜的任務可以被拆解，委派給不同的專家智能代理去處理：

• 一個「首席旅遊規劃 Agent」在規劃行程時，當涉及到預算問題，它不需要自己去處理匯率計算，而是可以將「將 10 萬台幣換算成日圓」這個子任務，交給它工具箱裡的「即時匯率換算 Agent」。
• 一個「公司財報分析 Agent」可以將數據清理的任務交給「數據清洗 Agent」，將圖表繪製的任務交給「視覺化 Agent」。

這種模式允許我們建構模組化、可擴展且高度專業化的智能代理系統，就像一個由各領域專家組成的虛擬團隊。

模型上下文協定（Model Context Protocol, MCP）

MCP 是由 Anthropic 推動的一項開放標準，目的是為大型語言模型提供一個統一且標準化的介面，讓它們可以與外部世界中的資料來源與工具進行互動。

透過 MCP Tools，我們可以將多種不同型態的工具無論是 Function、Extension，甚至是其他 Agent 集中掛載在一個 MCP 工具伺服器上，並以一致的結構描述格式公開給模型。這讓代理在執行任務時，不需要逐一註冊或硬編碼工具清單，而是能動態地「查詢出目前有哪些能力可以使用」，並自動完成資源的選擇與調用。

這樣的模式具備兩個面向的優點。它像 Function 一樣，讓開發者可以自己決定哪些工具要提供、怎麼管理存取權限與資安邊界；另一方面，它也保有 Extension 的便利性，提供模型一個統一的調用介面與行為格式。唯一的差別是：MCP Tools 通常不由平台托管，而是由開發者自行部署與維運。

整體而言，MCP 的設計讓工具的管理變得更集中、更動態、更有彈性。你可以在一個入口點中完成權限設定、配額限制、審計記錄與觀測追蹤，也能隨時擴充新的工具，無需重新訓練模型或變動原有結構。它是一種更現代、更模組化的智能代理基礎建設方式。

編排層（Orchestration Layer）：智能代理的神經中樞

https://www.zhihu.com/question/665012664/answer/1897954744963675108

光有強大的工具箱還不夠，智能代理需要一個「神經中樞」來指揮這一切。這個角色由「編排層」扮演。它是一個持續運行的循環，最經典的框架就是 ReAct（Reasoning + Acting），我們可以將其簡化為以下步驟：

1. 思考（Thought）： 智能代理分析當前任務和已有資訊，進行內部推理。「使用者想訂機票，但我還不知道日期，我需要先詢問日期。」
2. 行動（Action）： 根據思考結果，決定是向使用者提問，還是使用某個工具。「我將使用 ask_user 工具，問題是『請問您希望在哪一天出發？』」
3. 觀察（Observation）： 獲取行動的結果。「使用者回答『下週五』。」
4. 重複： 智能代理將新的觀察結果（下週五）納入考量，開始新一輪的「思考 -> 行動 -> 觀察」循環，直到最終任務完成。

這個循環機制，賦予了智能代理規劃、執行、反思和修正的能力，使其能夠應對多步驟的複雜任務。

實踐的最後一哩路：用框架指揮 Agent

https://langchain-ai.github.io/langgraph/concepts/multi_agent/

當我們理解了代理可以調用工具、組合專家、建立上下游關係，下一步的挑戰就不再是「能不能實現」，而是「如何以工程化的方式優雅且穩定地實現這一切」。

這正是如 LangChain、LlamaIndex 等框架存在的核心價值。它們不是模型，而是專為構建智能代理系統而設計的 Agent Development Kits（智能代理開發工具包）。這些框架的關鍵作用在於：把原本鬆散的 Agent 編排邏輯標準化、模組化，並形成可觀測、可測試、可治理的實作流程。

藉由這些框架，開發者可以：

• 明確定義代理可使用的工具集合（API、函式、子代理等）。
• 串接提示、工具與記憶，構建完整的 「思考 → 行動 → 觀察 → 再思考」循環。
• 運用抽象語法（如 chains、agents、executors、tools registry 等）快速建構各種常見架構：單一代理、多代理協作、指揮控制型系統（supervisor）、層級式任務拆解等。

就如上圖所示，從最基本的 Single Agent，到 Network、Supervisor、再到支援複雜拓樸的 Hierarchical 或 Custom Orchestration，這些框架為我們提供了一整套「如何組織、連結、調度代理」的策略。它們的價值不在於模型更聰明，而在於讓我們能更清晰地定義每一個代理的角色、責任與邊界。

有了框架，我們不再是零散寫出一堆 prompt + 函式，而是有結構、有治理地構建出一整座多智能體系統（multi-agent system）。

總結

大型語言模型的強大能力，只有在結合工具之後才能真正落地。從單純的函式呼叫（Function Calling），到平台提供的封裝（Extension Calling），再到將代理視為工具進行組合（Agent as a Tool），以及 MCP 工具協定所帶來的集中與標準化，每一種接入模式都是幫助我們讓「LLM + 行動力」成為現實的具體手段。

而真正讓這些模式得以實踐與擴展的關鍵，是框架的出現。像 LangChain、LlamaIndex 等 Agent Framework，讓我們能夠不只是「做出一個代理」，而是用標準化、工程化的方法編排整個代理系統，無論是單點工具調用、多代理協作，還是層級式、網狀、甚至自訂拓樸的智能體架構。

這是一條從 prompt 工程走向系統設計的路，從單模型互動走向多智能體的組織協作。當我們擁有一套穩定的工具呼叫協定、一個能管理多代理互動的框架，以及一組明確的治理與可觀測機制，我們就不只是使用 AI，而是在真正地建構一套具備行動力的 AI 系統基礎設施。

References：

• https://www.zhihu.com/question/665012664/answer/1897954744963675108
• https://drive.google.com/file/d/1W8EnoPXRLTQesfjvb-b3Zj-dnBf1f--n/view