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

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 協議暴露自己的代理：

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

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

綜合運作#

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

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

A2A vs MCP ── 比較#

它們如何協同工作#

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

範例工作流程#

1. 用戶在企業代理界面提交複雜請求。
2. 協調代理使用 A2A 將子任務委派給專業代理（例如，分析、人力資源、金融）。
3. 其中一個代理在內部使用 MCP 調用搜索功能、獲取文檔或利用模型進行計算。
4. 結果作為工件通過 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 時代，整合通常是手動且嚴格的，這種模型使得更自主的流程和服務之間更靈活的連接成為可能。這裡有兩個例子：

1. 從文檔設計

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

2. 全方位競爭對手研究

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

認證和授權邊界的挑戰#

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

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

1. 代理 vs SaaS 和網站應用
2. MCP 客戶端（代理）vs MCP 伺服器
3. 用戶 vs 代理
4. 代理 vs 代理

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

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

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

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

有任何問題？

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