AI 怎麼使用工具？Function Calling、MCP 與 A2A

上一篇最後問了一個問題：AI Agent 真的做得出來嗎？還是只會說不會做？這篇就來看看，怎麼讓 AI 更好的使用工具。

AI 是怎麼使用工具的？

要讓 AI 更有效地使用工具，我們得先理解它究竟如何使用。

以 ChatGPT 為例，它最初只能回答問題、執行內建的功能。它無法直接幫你更新資料庫、查閱電子郵件、回覆顧客訊息、打開 Google 地圖導航。過去的做法，是由 GPT 給出步驟說明，再由使用者手動執行。

那為什麼今天的 GPT 可以「直接提供一個 Google 地圖的規劃路線」？

關鍵在於它多了一項能力：調用外部工具。這在程式語言中稱為 Function Calling（函式呼叫）。

Function Calling 是什麼？舉個例子

以 Siri 為例：

當你對 Siri 說：「幫我導航到台北車站」，它的運作流程是：

1. 理解你的語意（目的地是台北車站）
2. 啟用 Google 地圖
3. 輸入目的地
4. 啟動導航功能

這一連串的操作工具行為，就是 Function Calling — Siri 呼叫 Google 地圖的功能來執行這些動作。

前提是：

• Siri 有權限呼叫 Google 地圖，
• Google 地圖也具備接收並處理這些指令的能力。

GPT 怎麼透過 n8n 使用工具？

雖然 GPT 不在手機裡，卻可以在 n8n 環境裡做到這件事。

自動化工作流程平台，可以讓 GPT 接入不同工具（例如 Google 地圖、Gmail、Notion 等），讓它下達指令並完成任務。

流程如下：

1. AI Agent 接收到「幫我導航到台北車站」的請求
2. GPT 透過 n8n 所設置的「Google Maps 節點」呼叫相應功能
3. n8n 將 GPT 的指令（例如「導航至台北車站」）轉換為具體指令
4. Google 地圖執行導航，並回傳結果給 GPT

以往的 Function Calling，大多是透過 API（Application Programming Interface，應用程式介面） 來實現。API 簡單來說，是不同系統之間交換指令的標準通道，而傳遞的內容通常採用 JSON 格式。

JSON 範例：

{
  "function": "googleMaps",
  "parameters": {
    "destination": "台北車站"
  }
}

用比喻理解：API 像報修單

想像 A 公司想請 B 公司幫忙修水管。

B 公司不需要接電話、也不管你用什麼語言說明，只要求你依照格式填寫「報修單」。

只要格式正確、資料齊全，B 公司就會依照內部流程自動處理。

API 就像這份報修單，你只要把資訊填對格式，對方就能理解你要什麼，並自動執行。

這種模式讓兩個系統之間即使完全不同（語言、系統、設備），也能透過 API 建立穩定互動。這就是 Function Calling 的底層邏輯。

但 AI 哪會操作這麼多工具？

即使大語言模型（LLM）語言理解能力再強，它也只擅長產生文字內容與語意理解，對於執行精準、格式嚴謹的操作仍有明顯限制。也就是它會把報修單填錯、忘記填寫某些欄位、填錯張表都有可能。

那我們該如何解決呢？

引入上下文與 MCP 接口的誕生

我們有兩種主要做法：

1. 人工補上下文：
   由需要使用工具的人，幫 AI 建立一份「使用說明書」，告訴 AI 該怎麼填、有哪些規則（Prompt Template 或 Tool Context）。
2. 由工具方提供標準格式說明：
   由產品工具的供應方，提供給 AI 格式一致、易於解析的「標準上下文說明」。

第二種方向當然是比較好的方向，畢竟自己寫自己產品的使用方法，會寫得更好、更正確，

但問題是：每間公司的工具、說明格式各自為政，又會導致 AI 難以適應多樣化的內容。

這時候，MCP（Model Context Protocol） 就應運而生。

MCP 是什麼？

模型上下文協議（MCP - Model Context Protocol）是一種讓 AI 連接外部工具的共通規則，透過結構化的上下文定義，協助模型更有效地：

• 理解工具的功能與用途（理解使用方法）
• 根據任務自動選擇並組合合適的 API／函數（選擇適合工具）
• 生成正確格式的請求（如 JSON），並傳入必要參數執行任務（使用工具）

MCP 由 Anthropic 在 2024 年底提出，到了 2025 年，OpenAI、Google 等大型 AI 平台也陸續支援，現在已經是 AI 連接外部工具最通用的做法。

就像螢幕、滑鼠、插座、鍵盤，如果每一種工具都使用不同的接頭（三孔、兩孔、HDMI、Type-C、USB-A），雖然都可以和電腦連接，但每種情況都需要設計專屬的轉接方式，整合起來極為複雜。

AI 工具整合也是類似情況。如果每個工具的使用說明、輸入格式、溝通邏輯都不同，AI 模型在調用這些工具的學習難度就會上升，增加錯誤與開發負擔。

而當更多公司都統一使用 MCP 的溝通方式，它就像為所有 AI 工具建立一個共同標準（很多人把它比喻成 AI 世界的 USB-C），讓 AI 模型可以一致地理解每個工具的功能、格式與使用方法，就更容易使用工具。

在這樣的結構底下，就會看到三種角色的互動：

這樣的架構下，當 n8n 和 Google 地圖都支援 MCP 的溝通方式時，就能實現以下場景：

使用者在 n8n 的環境下跟 GPT 對話，讓 GPT 判斷需要查找景點，再透過 n8n 將請求轉發給 Google Maps，讓 Google Maps 執行路線規劃。

雖然，透過有支援 MCP 的 AI 應用程式（如：Claude、ChatGPT、Cursor）一樣可以直接連接工具，但流程自動化工具的核心優勢，在於能夠進行多方串聯、流程設計，打造出流暢且模組化的自動化流程。甚至 n8n 還支援本地部署（self-hosted），這對資料安全要求較高的組織格外重要。

除了 n8n 這類萬用型流程工具，市面上也出現了如 Dify 這樣的專用型平台，它不只整合語言模型，也內建了如向量資料庫、自定義知識庫、回應記錄管理等功能。

這些工具通常針對 AI 應用場景做了進一步優化，讓開發者與非工程師能更快上手，並實現細緻化控制與即時反應。

如果你希望 AI Agent 的行為邏輯不只「能執行任務」，還能進行細節調整、擴充與追蹤，除了串接式平台，也值得考慮已內建能力的專用型工具。

乾脆讓代理人一起工作：Agent to Agent（A2A）

起初，我們讓 AI Agent 透過操作各種工具，完成特定任務。

但就像人類一樣，學了很多工具也不一定會專精，那不如「找對的人幫忙」，任務可以完成得更好！

這就導入了新的模式：Agent to Agent Protocol（A2A）合作架構。

原本的工具使用概念是：

A 公司填寫一張標準化的報修單（MCP 格式），請 B 公司修水管。
雖然流程統一，但 A 公司只能根據自己的判斷請求「修水管」，即使真正的問題可能是馬達、水塔。

而 A2A 的邏輯是：

A 公司派出自己的 AI 代理人，直接與 B 公司的 AI 代理人溝通，由對方來判斷「該修什麼、用什麼工具」，甚至安排整個修復流程。

本質差異在於：誰負責判斷問題、選擇工具。

透過 A2A 架構，每個 AI Agent 不只會調用指定工具，甚至還能根據任務需求，判斷是否應該自己處理，或交由其他 Agent 處理，讓 AI Agent 互通，變成類似人類的分工協作流程。

這使得 AI 的任務執行邏輯從「單一工具操作」提升到「具備分工、協作能力的工作網路」。