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

- 原文：https://processhacker.pro/blog/ai-tools-mcp-a2a/
- 作者：Kevin Wu（https://processhacker.pro/author/kevin/）
- 網站：流程駭客｜數位×管理×流程
- 發布：2026-11-12
- 系列：AI 知識導讀（https://processhacker.pro/docs/ai/）
- 標籤：AI 基礎知識、AI 人工智慧

> AI 是怎麼「動手」操作 Google 地圖、Gmail 這些工具的？用報修單的比喻，看懂 Function Calling、API、MCP 與 A2A 分別在解決什麼問題。

[上一篇](https://processhacker.pro/blog/what-is-ai-agent/)最後問了一個問題：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 範例：

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

![API 就像報修單：照格式填好，對方就能自動處理](https://processhacker.pro/content/images/blog/ai-tools-mcp-a2a/f913d02f4454.png)

## 用比喻理解：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 模型可以一致地理解每個工具的功能、格式與使用方法，就更容易使用工具。

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

| 元件                               | MCP 架構角色       | 說明                                              |
| -------------------------------- | -------------- | ----------------------------------------------- |
| **n8n、Claude、ChatGPT 等 AI 應用程式** | MCP Host 主機    | 你實際在操作的 AI 應用程式。裡面的大型語言模型（如 GPT）負責理解需求、決定要用哪個工具 |
| **Host 裡的連線元件**                  | MCP Client 客戶端 | 由 Host 自動建立，每一個 Client 負責和一個工具（Server）保持連線、傳遞請求 |
| **Google Maps**                  | MCP Server 伺服器 | 提供「查詢景點、路徑規劃…等」功能（Tools），接收請求並執行任務              |

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

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

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

💡

什麼是「本地部署」？\
不像雲端版 ChatGPT 必須將檔案上傳至雲端平台，n8n 可安裝在公司內部的伺服器或電腦上，並和下載到本地的語言模型結合。\
整個使用皆可在自己的網路系統、無網路環境完成，不經第三方伺服器，大幅降低資料外洩與隱私風險。\
當所有資源（資料、模型、處理邏輯）都掌握在本地，企業就能在內部控管與彈性調整間取得最佳平衡，也可根據需求選擇是否讓自己的系統與雲端資料互通。

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

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

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

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

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

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

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

![A2A：由需求方的 AI 代理人直接和專業方的 AI 代理人溝通](https://processhacker.pro/content/images/blog/ai-tools-mcp-a2a/6fa7568dad67.png)

**原本的工具使用概念是：**

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

**而 A2A 的邏輯是：**

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

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

| 模型             | 誰判斷要修什麼         | 誰執行             | 工具調用方式       |
| -------------- | --------------- | --------------- | ------------ |
| **AI - Tools** | 需求方 AI（A 公司窗口）  | 工具（B 公司）        | 直接調用         |
| **A2A**        | 接收方 AI（B 公司代理人） | 接收方 AI（B 公司代理人） | 由專業的接收方判斷後調用 |

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

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

💡

A2A 的後續發展\
Google 在 2025 年 4 月發表 A2A 時確實引起軒然大波，當時的架構細節，似乎還未達到理想中 Agent 之間的溝通樣貌，比較像是用和 Tool 溝通的方式去和 Agent 溝通。\
之後 A2A 交由 Linux 基金會維護，有更多公司加入一起發展，但普及程度目前仍不如 MCP。\
我相信 A2A 的方向仍然是正確的，也期待它的到來，同時也提醒我們，AI 在迭代的過程中，並不是一步到位的，仍然有很多試錯、摸索的過程。