← M05 生成式 AI M05 生成式 AI iPAS L12202

M05.12|MCP 與 A2A 協議:AI 代理如何與世界溝通

MCP 是 AI 的手,A2A 是 AI 的嘴——一個操作工具,一個跟其他 AI 說話

L1-AI應用規劃-AI協議標準 L2-AI系統部署-AI互操作性
MCP A2A AI協議 Tool Use 代理通訊 開放標準 互操作性
📋

本講學習重點

MCP 解決了什麼問題?為什麼需要統一的工具連接標準?
MCP 的三層架構(Host → Client → Server)各扮演什麼角色?
A2A 和 MCP 是競爭關係還是互補關係?
Agent Card 在 A2A 協議中的作用是什麼?
2026 年 MCP 和 A2A 的產業採用狀況如何?

MCP (Model Context Protocol) 核心概念: - 由 Anthropic 於 2024 年 11 月提出的開放標準 - 解決的問題:每個 AI 要連接每個工具都要寫專用整合,N 個 AI × M 個工具 = N×M 個整合 - MCP 把這簡化為:每個 AI 實作 MCP Client,每個工具實作 MCP Server,只需 N+M 個整合 - 比喻:USB-C for AI — 一個統一介面連接所有工具和資料源 MCP 三層架構: 1. AI Host:使用者互動的 AI 應用(Claude Desktop, Cursor, VS Code) 2. MCP Client:Host 內建的 MCP 協議客戶端,負責與 Server 溝通 3. MCP Server:包裝工具/資料源的標準化服務(如 GitHub MCP Server、Slack MCP Server) MCP 提供三種能力: - Tools(工具):讓 AI 執行操作(如建立 GitHub Issue、發送訊息) - Resources(資源):讓 AI 讀取資料(如存取資料庫、讀取檔案) - Prompts(提示模板):預定義的互動模板 A2A (Agent-to-Agent Protocol) 核心概念: - 由 Google 於 2025 年 4 月提出 - 解決的問題:不同廠商的 Agent 之間如何溝通和協作 - Agent Card:一張 JSON 格式的「名片」,描述 Agent 的能力、輸入輸出格式、認證方式 - 比喻:如果 MCP 是 AI 的「手」(操作工具),A2A 是 AI 的「嘴」(跟其他 AI 溝通) 三層協議棧: 1. MCP(工具層):AI 連接工具和資料 2. A2A(代理層):Agent 之間的溝通和任務委派 3. WebMCP(網頁層):讓網站可以被 AI 直接操作(類似結構化的 robots.txt) 產業動態: - 2025/12:MCP 捐贈給 Linux Foundation AI & Data (AAIF) - 100+ 企業支持(包括 OpenAI, Google, Microsoft, Anthropic) - 2026 年:MCP 已成為事實標準,主流 IDE 和 AI 平台均支持

📌 MCP 和 A2A 是兩個互補的 AI 協議標準。 MCP 讓 AI 能標準化地連接外部工具和資料(AI 的「手」), A2A 讓不同的 AI Agent 之間能標準化地溝通和協作(AI 的「嘴」)。 兩者加上 WebMCP 組成完整的 AI 互操作協議棧, 正在讓 AI 從「孤立的聊天視窗」變成「能與整個數位世界互動的行動者」。
MCP 與 A2A 協議:AI 代理如何與世界溝通

🎙️ Podcast(中文)

0:00 / 0:00

一句話搞懂

MCP 是 AI 連接工具的「USB-C 標準」,讓任何 AI 都能用統一的方式操作任何工具;A2A 是 AI 代理之間的「通訊協議」,讓不同公司做的 AI Agent 能互相溝通和委派任務——兩者不是競爭,而是互補。


白話解說

沒有標準之前:N × M 的整合噩夢

在 MCP 出現之前,如果你要讓 AI 連接外部工具,你必須為每一對「AI + 工具」寫一套專用的整合程式碼。Claude 要用 GitHub?寫一套 Claude-GitHub 整合。GPT 要用 GitHub?再寫一套 GPT-GitHub 整合。Claude 要用 Slack?又一套。GPT 要用 Slack?又一套。

如果有 5 個 AI 平台和 20 個常用工具,就需要 5 × 20 = 100 套整合程式碼。每個工具的 API 格式不同、認證方式不同、錯誤處理方式不同,維護這些整合是一場噩夢。

這個問題在科技史上並不新鮮。在 USB 出現之前,印表機用並列埠、滑鼠用 PS/2 埠、手機充電器每個品牌都不一樣。USB 的出現把 N × M 的混亂簡化成了一個統一的介面——任何裝置只要符合 USB 標準,就能連接任何電腦。

MCP 要做的,就是 AI 世界的 USB。

MCP:AI 的統一工具介面

Model Context Protocol(MCP) 由 Anthropic 於 2024 年 11 月提出,是一個開放標準協議,定義了 AI 如何連接外部工具和資料源的統一方式。

MCP 的三層架構非常清晰:

AI Host:這是使用者直接互動的 AI 應用程式。比如 Claude Desktop、Cursor 編輯器、VS Code 中的 AI 助手。Host 負責接收使用者的指令,也是最終呈現結果的地方。

MCP Client:嵌入在 Host 中的協議客戶端。它知道如何用 MCP 協議和外部 Server 溝通。使用者通常看不到它,它在背後默默工作——就像你的瀏覽器內建了 HTTP 客戶端,你不需要知道它的存在,但它是瀏覽網頁的基礎。

MCP Server:把工具或資料源包裝成 MCP 標準格式的服務。比如「GitHub MCP Server」把 GitHub 的所有 API 包裝成 MCP 標準的 Tool,「Slack MCP Server」把 Slack 的功能包裝成 MCP 標準。每個 MCP Server 向外宣告自己提供哪些工具、需要什麼參數、會回傳什麼結果。

有了 MCP,整合的工作量從 N × M 降到 N + M——5 個 AI 平台各實作 1 個 MCP Client(共 5 個),20 個工具各實作 1 個 MCP Server(共 20 個),總共只需要 25 套程式碼,任何 AI 都能連接任何工具。

MCP 的三種能力

MCP Server 可以提供三種類型的能力給 AI:

Tools(工具):讓 AI 執行操作。比如「建立 GitHub Issue」、「發送 Slack 訊息」、「查詢資料庫」、「生成圖片」。每個 Tool 有名稱、描述(讓 AI 理解什麼時候該用它)、參數格式(JSON Schema)、回傳格式。AI 模型根據使用者的需求,自動判斷該呼叫哪個 Tool。

Resources(資源):讓 AI 讀取資料。比如「讀取 Google Drive 中的文件」、「存取公司內部知識庫」、「查看 Jira 上的任務列表」。Resources 是唯讀的,AI 不會修改資料,只是讀取和理解。

Prompts(提示模板):預定義的互動模板。比如一個「程式碼審查」模板,已經設計好了審查的步驟和格式,使用者選擇後 AI 會按照模板流程執行。

A2A:AI 代理之間的通訊標準

如果 MCP 解決了「AI 如何操作工具」的問題,那 A2A 解決的是「AI 如何和其他 AI 溝通」的問題。

Agent-to-Agent Protocol(A2A) 由 Google 於 2025 年 4 月提出。想像這個場景:你公司用的是一個「客服 Agent」(由 A 廠商做的),它發現客戶的問題涉及技術層面,需要把問題轉給「技術支援 Agent」(由 B 廠商做的)。這兩個 Agent 是不同公司用不同技術做的,它們怎麼溝通?

在沒有 A2A 之前,這幾乎不可能——每對 Agent 之間需要自訂的整合方式。A2A 定義了一套標準的 Agent 間通訊協議,讓任何符合 A2A 標準的 Agent 都能互相交流。

A2A 的核心概念是 Agent Card——每個 Agent 發布一張 JSON 格式的「名片」,描述自己的能力、接受什麼類型的任務、輸入輸出格式、認證方式。其他 Agent 讀取這張名片,就知道「這個 Agent 能做什麼、怎麼跟它合作」。

用人類世界類比:MCP 是「職場技能」——你會用 Excel、會寫程式、會操作機器(操作工具)。A2A 是「溝通能力」——你會開會、會寫信、會用共同語言和同事討論問題(跟其他人溝通)。兩者缺一不可。

三層協議棧:完整的 AI 互操作架構

把 MCP 和 A2A 結合起來,再加上正在發展中的 WebMCP,就構成了一個三層的 AI 互操作協議棧:

第一層:MCP(工具層)。AI 連接工具和資料的標準。就像 TCP/IP 是網路的基礎,MCP 是 AI 操作世界的基礎。

第二層:A2A(代理層)。Agent 之間溝通和協作的標準。就像 HTTP 定義了網頁之間的溝通方式,A2A 定義了 Agent 之間的溝通方式。

第三層:WebMCP(網頁層)。讓網站可以聲明「AI 可以怎麼操作我」——類似 robots.txt 告訴搜尋引擎「你可以爬什麼」,WebMCP 告訴 AI Agent「你可以在這個網站上做什麼操作」。這讓 AI 不再需要透過模擬滑鼠點擊來操作網頁,而是直接用結構化的方式和網站互動。

2026 年產業現況

MCP 在提出後的一年多裡,已經成為 AI 工具連接的事實標準。2025 年 12 月,Anthropic 將 MCP 捐贈給 Linux Foundation AI & Data Foundation(AAIF),使其成為一個由中立基金會管理的開放標準——這消除了「由單一公司控制」的疑慮,大幅加速了產業採用。

截至 2026 年初,超過 100 家企業加入支持 MCP 和 A2A 生態。OpenAI 的 GPT 系列支援 MCP、Google 的 Gemini 支援 MCP、Microsoft 的 Copilot 支援 MCP。幾乎所有主流的 AI 開發工具(Cursor、Windsurf、VS Code、JetBrains)都內建了 MCP Client。社群已經開發了數千個 MCP Server,涵蓋了從 GitHub、Slack、Notion、Google Drive 到各種資料庫和企業系統。

A2A 的採用相對較慢,因為多 Agent 協作的場景目前還在早期。但隨著 Agentic AI 應用的成熟,A2A 的重要性會越來越高。

這對開發者意味著什麼?

如果你是 AI 應用開發者,MCP 和 A2A 的意義是:你不再需要從零開始寫工具整合。想讓你的 AI 應用連接 GitHub?直接用現成的 GitHub MCP Server。想連接公司的資料庫?寫一個簡單的 MCP Server 把資料庫包裝起來即可,所有支援 MCP 的 AI 都能立即使用。

如果你是企業 IT 管理者,MCP 的意義是:你只需要為公司的內部系統(CRM、ERP、知識庫)各建立一個 MCP Server,就能讓所有 AI 工具統一存取這些系統,不需要為每個 AI 工具分別做整合。


應用場景

協議 應用場景 具體範例
MCP AI 連接開發工具 Claude Desktop 透過 GitHub MCP Server 建立 Issue、讀取程式碼、提交 PR
MCP AI 連接企業系統 Copilot 透過 Salesforce MCP Server 查詢客戶資料、更新銷售記錄
MCP AI 連接資料庫 AI 助手透過 PostgreSQL MCP Server 查詢並分析業務數據
A2A 跨廠商 Agent 協作 客服 Agent 把技術問題委派給技術支援 Agent,自動交接上下文
A2A 企業內部 Agent 串接 HR Agent 把新員工入職流程分派給 IT Agent(開帳號)和 Admin Agent(安排座位)
WebMCP AI 操作網頁服務 Agent 直接透過 WebMCP 在旅遊網站上搜尋航班、比價、預訂,不需要模擬瀏覽器操作

常見誤區

誤區一:MCP 和 A2A 是競爭關係

這是最常見的誤解,因為 MCP 由 Anthropic 提出、A2A 由 Google 提出,看起來像兩家公司在搶標準制定權。但事實上,兩者解決的是完全不同層次的問題:MCP 是「AI 如何操作工具」(AI-to-Tool),A2A 是「Agent 如何與 Agent 溝通」(Agent-to-Agent)。它們的關係更像是 USB(連接裝置)和 Wi-Fi(裝置間通訊)——不是競爭,而是互補。一個完整的 Agentic AI 系統同時需要 MCP(連接工具)和 A2A(Agent 協作)。Google 也支持 MCP,Anthropic 也歡迎 A2A,兩個標準的支持者高度重疊。

誤區二:MCP 只有 Claude 能用

MCP 是開放標準,任何人都可以實作。2025 年 12 月捐贈給 Linux Foundation 後,它已經是一個由中立基金會管理的產業標準,和 Anthropic 的商業利益脫鉤。OpenAI、Google、Microsoft、Meta 的 AI 產品都支援 MCP。社群開發的 MCP Server 可以被任何支援 MCP 的 AI 使用,不限於 Claude。

誤區三:有了 MCP 就不需要寫 API 了

MCP 不是取代 API,而是站在 API 之上的一層標準化包裝。MCP Server 的內部實作通常還是呼叫底層的 REST API 或 GraphQL API。MCP 標準化的是「AI 和工具之間的溝通介面」,而不是「工具本身的介面」。如果你的系統已經有成熟的 API,建立 MCP Server 就是用一層薄薄的適配器把現有 API 包裝成 MCP 格式,底層的 API 繼續正常運作。


小練習

練習一:MCP 架構辨識

一家公司的 AI 助手需要連接以下三個系統:(1) 公司的 Jira 專案管理、(2) 公司的內部 Wiki 知識庫、(3) 公司的 Slack 頻道。請畫出 MCP 架構圖,標明 Host、Client、Server 各是什麼,以及資料流向。

點擊查看參考答案

練習一:MCP 架構圖

``` 使用者 │ ▼ ┌─────────────────────────────────┐ │ AI Host(公司 AI 助手應用) │ │ ┌───────────────────────────┐ │ │ │ MCP Client │ │ │ │ (內建在 Host 中) │ │ │ └─────┬────┬────┬───────────┘ │ └────────│────│────│──────────────┘ │ │ │ ┌────┘ │ └────┐ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ │ Jira │ │ Wiki │ │ Slack │ │ MCP │ │ MCP │ │ MCP │ │ Server │ │ Server │ │ Server │ └───┬────┘ └───┬────┘ └───┬────┘ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────┐ │ Jira │ │ Wiki │ │ Slack │ │ REST │ │ 資料庫 │ │ Web │ │ API │ │ │ │ API │ └────────┘ └────────┘ └────────┘ ``` **資料流範例**:使用者問「最近有哪些高優先級的 Bug 還沒修?」→ AI Host 接收問題 → MCP Client 呼叫 Jira MCP Server 的「搜尋 Issue」工具(參數:type=Bug, priority=High, status=Open)→ Jira MCP Server 呼叫 Jira REST API → 回傳結果 → AI 整理成自然語言回答使用者。 **關鍵認識**:MCP Client 只有一個(在 Host 中),但可以同時連接多個 MCP Server。新增工具只需要加一個 MCP Server,不需要修改 Host 或 Client。

練習二:MCP 還是 A2A?

以下四個場景,請判斷應該使用 MCP、A2A、或兩者都需要:

  • (A) 你的 AI 助手需要讀取 Google Calendar 中的行程
  • (B) 公司的「財務分析 Agent」需要把報告交給「合規審查 Agent」做最終檢查
  • (C) 一個旅行規劃 Agent 需要在航空公司網站上查詢航班
  • (D) 客服 Agent 處理退款時需要呼叫支付閘道 API,同時需要通知倉儲 Agent 攔截出貨
點擊查看參考答案

練習二:協議選擇判斷

- **(A) MCP**:AI 連接外部工具(Google Calendar),這是「AI 操作工具」的場景。透過 Google Calendar MCP Server 即可。 - **(B) A2A**:兩個獨立的 Agent 之間需要溝通和交接任務,這是「Agent 對 Agent」的場景。財務分析 Agent 透過 A2A 把報告和任務上下文交給合規審查 Agent。 - **(C) MCP 或 WebMCP**:Agent 需要操作外部服務(航空公司網站)。如果航空公司有 MCP Server,用 MCP;如果航空公司支援 WebMCP,用 WebMCP。 - **(D) MCP + A2A 都需要**:呼叫支付閘道 API 是 MCP(AI 操作工具),通知倉儲 Agent 是 A2A(Agent 對 Agent 溝通)。這個場景同時需要兩種協議。 **判斷規則**:操作工具/資料 → MCP;Agent 之間溝通 → A2A;複雜場景通常兩者兼需。

關鍵字自我檢核

✅ Model Context Protocol ✅ Agent-to-Agent Protocol ✅ MCP架構 ✅ A2A Agent Card ✅ 協議棧 ✅ Linux Foundation AAIF ✅ AI互操作性 ✅ MCP Server ✅ MCP Client ✅ WebMCP ✅ 工具連接標準 ✅ AI代理通訊