繁體中文（台灣）

A2A vs MCP：為新興代理生態系統而設的兩個互補協議

本文介紹了 A2A 和 MCP ── 這兩個影響 AI 代理系統未來的嶄新協議。文章解釋了它們如何運作、怎麼不同，為何對於開發者、設計師以及 AI 產品建立者來說，了解這種架構是如此重要。

Guamian

Product & Design

4/11/2025

不要在使用者認證上浪費數週時間

使用 Logto 更快地發布安全應用程式。幾分鐘內整合使用者認證，專注於您的核心產品。

立即開始

AI 代理的日漸普及── 自主或半自主軟體實體代表使用者進行推理和行動── 正在應用程序架構中產生新的一層。

在 2025 年初，有兩個不同的協議出現以應對這一挑戰── A2A（代理到代理） 和 MCP（模型上下文協議）。一個簡單的理解方式是：

A2A：代理如何互相合作

MCP：代理如何與工具或外部情境互動

參考來源：https://google.github.io/A2A/#/topics/a2a_and_mcp

它們應對了建設擁有多個代理、多個大型語言模型和多個情境來源的系統時所面臨的核心挑戰 ── 它們全部都需要合作。

一種角度是：「MCP 提供垂直整合（應用到模型），而 A2A 提供水平整合（代理到代理）

無論你是否是開發者，任何建立 AI 產品或代理系統的人都應該了解這基礎架構 ── 因為它形塑了我們設計產品、用戶交互、生態系統和長期增長的方式。

本文以簡單易懂的方式介紹了這兩種協議，並突出了對於開發者和 AI 產品建立者的重要要點。

什麼是 A2A（代理到代理）？

A2A（代理到代理） 是由谷歌及超過 50 個行業伙伴開發的開放協議。其目的是讓代理之間能夠互操作 ── 無論誰製造了它們，在哪裡託管或使用了什麼框架。

A2A 協議機制

A2A 使用 JSON-RPC 2.0 over HTTP(S) 作為通信機制，支持 Server-Sent Events (SSE) 來傳送更新信息。

A2A 通信模型

A2A 定義了兩個代理交互的結構模型。一個代理扮演**“客戶端”代理的角色，發起請求或任務，而另一個代理扮演“遠程”代理**，接收請求並嘗試完成它。客戶端代理首先可能會進行能力發現，找出哪個代理最適合進行某項工作。

這就涉及到一個問題，代理如何發現彼此。每個代理可以發布一個 Agent Card（一個 JSON 元數據文件，通常託管在像 /.well-known/agent.json 這樣的標準 URL 上），描述其能力、技能、API 端點和授權要求。

通過閱讀 Agent Card，客戶端代理可以為當前執行的任務識別合適的合作代理 ── 本質上是一個該代理所知或能做的事情的目錄。一旦選定目標代理，客戶端代理會組建一個任務對象以傳送過去。

參考來源：https://google.github.io/A2A/#/

任務管理

在 A2A 中的所有交互都圍繞執行任務進行。任務是一個結構化對象（由協議的模式定義），包括請求的詳情和跟踪其狀態。

在 A2A 中，每個代理扮演兩種角色中的一種：

客戶端代理：發起任務
遠程代理：接收並處理任務

任務可以包括任何工作形式：生成報告、檢索數據、啟動工作流。結果作為工件返回，並且代理可以在執行期間發送結構化的消息來進行協調或闡明。

協作和內容協商

A2A 支持的不僅是簡單的任務請求── 代理可以交換包含文本、JSON、圖像、視頻或互動內容的豐富多部分消息。這使得根據每個代理能夠處理或顯示的內容進行格式協商成為可能。

例如，遠程代理可以以原始數據或圖像的形式返回一個圖表，或者請求打開一個互動表單。這種設計支持靈活的、模態不可知的通信，而不要求代理共享內部工具或記憶。

用例範例

以下是一個真實世界範例，說明 A2A 如何用於企業場景：

一位新員工被大公司聘用。多個系統和部門參與了入職過程：

人力資源需要建立記錄並發送歡迎郵件
IT 需要提供給筆記本電腦和公司賬戶
設施需要準備桌子和通行證

傳統上，這些步驟通過人工或在內部系統之間進行緊密耦合的整合來處理。

而不需要在每個系統之間的自定義 API，每個部門都使用 A2A 協議暴露自己的代理：

代理	責任
hr-agent.company.com	創建員工記錄，發送檔案
it-agent.company.com	創建電子郵件帳戶，訂購筆記本電腦
facilities-agent.company.com	分配桌子，列印通行證

一個多代理系統── 我們稱之為 OnboardingPro（例如 onboarding-agent.company.com）── 協調整個入職工作流程。

發現：它閱讀每個代理的 .well-known/agent.json 以了解功能和授權。
任務委派：
- 向人力資源代理發送 createEmployee 任務。
- 向 IT 代理發送 setupEmailAccount 和 orderHardware 任務。
- 向設施代理發送 assignDesk 並生成 generateBadge。
流式更新：代理使用服務端事件發送進展更新（例如“筆記本已發貨”、“桌子已分配”）。
工件收集：最終結果（例如 PDF 證件、確認電子郵件、賬戶憑證）作為 A2A 工件返回。
完成：OnboardingPro 在入職完成時通知招聘經理。

什麼是 MCP（模型上下文協議）？

MCP（模型上下文協議） 由 Anthropic 開發，解決了另一個問題：如何在運行時為以語言模型為基礎的代理提供結構化情境和工具。

而不是啟用代理之間的通信，MCP 專注於上下文窗口── 是 LLM 的工作記憶。其目標是：

動態注入相關的工具、文件、API 功能或用戶狀態到模型的推理會話中
讓模型能夠調用函數或獲取文檔，而無需硬編碼提示或邏輯

MCP 關鍵架構

要理解 MCP，你首先需要了解整個架構── 所有部分如何协同工作。

MCP 主機：「你所交談的 AI」

將 MCP 主機 視為 AI 應用程序本身── 如 Claude 桌面或你的編碼助手。

這是你正在使用的界面── 你輸入或對話的地方。

它想要引入工具和數據，以幫助模型給出更好的答案。

MCP 客戶端：「連接器」

MCP 客戶端 是將你的 AI 主機（如 Claude）連接到外部世界的軟體部分。它就像一個轉接台── 管理著與不同 MCP 伺服器的安全、一對一的連接。當 AI 需要訪問某些東西時，它通過客戶端。

考慮工具如 ChatGPT、Claude 聊天 或 Cursor IDE 作為MCP 主機── 它們提供你互動的界面。在後台，它們使用 MCP 客戶端 通過 MCP 伺服器連接到不同的工具和數據來源。

參考來源：https://modelcontextprotocol.io/introduction

MCP 伺服器：「工具供應者」

一個 MCP 伺服器 是一個小型而專注的程序，提供一個專門的工具或功能── 例如：

在你的電腦上搜尋文件
在本地資料庫中查詢數據
調用外部 API（如天氣、金融、日曆）

每個伺服器都遵循 MCP 協議，因此 AI 可以理解它能做什麼以及如何調用它。

本地數據來源：「你的文件和服務」

某些 MCP 伺服器連接到你自己的機器上的東西── 如：

文檔和文件夾
代碼項目
資料庫或本地應用程序

這使得 AI 可以進行搜索、檢索或計算，而無需將你的數據上傳到雲端。

遠程服務：「API 和在線工具」

其他 MCP 伺服器則連接到互聯網── 它們與以下內容通信：

API（如 Stripe、Notion、GitHub）
SaaS 工具
雲端公司數據庫

因此，AI 可以說，例如：「調用 GitHub 伺服器並獲取開放 PR 列表。」

現在 MCP 支持連接到遠程 MCP 伺服器。這意味著 MCP 客戶端可以獲得更強大的功能。理論上，

擁有合適的 MCP 伺服器組合，用戶可將每個 MCP 客戶端轉變為“萬能應用”。

參考來源：https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

綜合運作

現在我們用一個圖表來看所有部分如何協同工作。

你向 AI 提出複雜問題。
AI（主機）向客戶端請求幫助。
客戶端調用合適的 MCP 伺服器── 可能是檢查文件或調用 API 的伺服器。
伺服器發送回數據或執行某個功能。
結果流回模型，幫助它完成任務。

A2A vs MCP ── 比較

類別	A2A（代理到代理）	MCP（模型上下文協議）
主要目標	啟用代理間的任務交換	啟用 LLM 訪問外部工具或情境
設計用途	自主代理間的通信	增強單代理的推理能力
重點	多代理工作流程、協作、委派	動態工具使用、情境擴充
執行模型	代理發送/接收任務和工件	LLM 在推理過程中選擇和執行工具
安全性	OAuth 2.0、API 密鑰、聲明範圍	在應用程序集成層處理
開發者角色	構建代理，通過端點暴露任務和工件	定義模型可使用的結構化工具和情境
生態系統合作伙伴	谷歌、Salesforce、SAP、LangChain 等	Anthropic，並在工具化 LLM 用戶界面中逐漸被採用

它們如何協同工作

它們不是替代品，而是互補的 A2A 和 MCP 在很多系統中會一起使用。

範例工作流程

用戶在企業代理界面提交複雜請求。
協調代理使用 A2A 將子任務委派給專業代理（例如，分析、人力資源、金融）。
其中一個代理在內部使用 MCP 調用搜索功能、獲取文檔或利用模型進行計算。
結果作為工件通過 A2A 返回，實現終端到終端的代理協作和模塊式工具訪問。

這種架構將**代理間通信（A2A）與代理內功能調用（MCP）**分開── 使系統易於組合、擴展和安全。

結論

A2A 關於代理透過網絡彼此通信── 安全、異步和以任務為中心。

MCP 則關於將結構化功能注入進模型會話，使 LLM 能夠在情境中推理工具和數據。

兩者結合使用時，支持可組合的多代理系統，既可擴展又可互操作。

MCP + A2A 基礎設施如何形塑代理產品市場的未來

最後，我想談談這個核心技術基礎如何形塑 AI 市場的未來── 對於建立 AI 產品的人意味著什麼。

人機交互的變革

這次轉變的明顯例子是開發者和服務工作流程。由於 MCP 伺服器現在集成到 IDE 和編碼代理中，開發者與工具的交互方式正在發生根本性改變。

以前，典型工作流程涉及尋找合適的服務，設置託管，閱讀文檔，手動整合 API，在 IDE 中編寫代碼，並通過低代碼儀表板配置功能。這是一種碎片化的體驗，在每個步驟都需要切換上下文和技術負擔。

現在，隨著 MCP 連接的編碼代理，很多複雜性可以被抽象掉。開發者可以通過對話提示更自然地發現和使用工具。API 集成成為編碼流程的一部分── 通常不需要單獨的用戶界面或手動設置。(想想 AWS 或微軟所提供的儀表板有多複雜)。交互變得更流暢── 更多關於引導行為而不是組裝功能。

在此模型中，用戶或開發者的交互從配置功能轉變為協作行為。這也改變了產品設計的角色。

不再是使用用戶界面「修補」技術挑戰（例如，“這個太難編寫代碼，我們做一個配置面板”），我們現在需要：

思考端到端體驗
設計如何以及何時 AI + 用戶交互應該結合
讓 AI 處理邏輯，引導用戶通過意圖和流程

挑戰在於確定何時以及如何將 AI 和用戶輸入結合起來，讓 AI 處理邏輯，引導用戶通過意圖和流程，並在合適的時機插入合適的交互。

我用開發者服務和 API 產品作為例子來展示用戶交互可能的改變── 但同樣適用於商務軟件。長期以來，商務工具一直很複雜且難以使用。自然語言交互有潛力簡化許多工作流程。

代理產品範式及其對 SaaS 的影響

我們開始看到越來越多的 MCP 伺服器 出現。想像 Airbnb 提供一個 預訂 MCP 伺服器，或谷歌地圖公開一個 地圖 MCP 伺服器。一個代理（作為 MCP 客戶端）可以同時連接到許多這樣的伺服器── 開啟以前需要自定義整合或緊密綁定應用程序的工作流程。

相比於 SaaS 時代，整合通常是手動且嚴格的，這種模型使得更自主的流程和服務之間更靈活的連接成為可能。這裡有兩個例子：

從文檔設計

你在 Notion 中寫了一份 PRD。Figma 代理閱讀文檔並自動創建一個線框圖，沒有手動交接。
全方位競爭對手研究

你要求進行競爭對手分析。一群代理在網上搜集信息，代表你註冊相關服務（使用安全授權），收集結果並交付整理在 Notion 工作區的工件。

認證和授權邊界的挑戰

隨著代理到代理連接、MCP 客戶端到 MCP 伺服器連接的興起，涉及認證和授權的基本需求很多，因為代理將代表人類和用戶行動，因此憑證必須在這一流程中得到安全保護。

到目前為止，針對新的代理到代理和 MCP 的興起，有些特定場景：

代理 vs SaaS 和網站應用
MCP 客戶端（代理）vs MCP 伺服器
用戶 vs 代理
代理 vs 代理

另一個有趣的用例是多身份聯合 Google 提到：

例如，用戶 U 與代理 A 工作需要 A 系統的標識。如果代理 A 後來依賴於需要 B 系統標識的工具 B 或代理 B，用戶可能需要在單個請求中為 A 系統和 B 系統提供身份標識。（假設 A 系統是企業 LDAP 身份，而 B 系統是 SaaS 提供商采用的身份）。

Logto 是一個合適的 OIDC 和 OAuth 提供商，十分適合未來 AI 整合。

得益於其靈活的基礎設施，我們正在積極擴展其能力，並發布了一系列教程幫助開發人員快速入門。

有任何問題？

聯繫我們 ── 或探索你可以用 Logto 構建的內容。

免費試用 Logto Cloud

什麼是 A2A（代理到代理）？#

A2A 協議機制#

A2A 通信模型#

任務管理#

協作和內容協商#

用例範例#

什麼是 MCP（模型上下文協議）？#

MCP 關鍵架構#

MCP 主機：「你所交談的 AI」#

MCP 客戶端：「連接器」#

MCP 伺服器：「工具供應者」#

本地數據來源：「你的文件和服務」#

遠程服務：「API 和在線工具」#

綜合運作#

A2A vs MCP ── 比較#

它們如何協同工作#

範例工作流程#

結論#

MCP + A2A 基礎設施如何形塑代理產品市場的未來#

人機交互的變革#

代理產品範式及其對 SaaS 的影響#

認證和授權邊界的挑戰#