繁體中文（香港）

A2A vs MCP: 兩個互補的協議為新興代理生態系統助力

本文介紹了 A2A 和 MCP 這兩個塑造 AI 代理系統未來的新興協議。它解釋了這些協議如何運作，它們之間的差異，為什麼了解這種架構對開發者、設計師和 AI 產品建立者很重要。

Guamian

Product & Design

4/11/2025

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

隨著 AI 代理的日益採用——在用戶名義下執行推理和行動的自動或半自動軟件實體——應用架構中出現了一個新層。在 2025 年初，為了解決此問題，出現了兩個不同的協議：A2A (Agent-to-Agent) 和 MCP (Model Context Protocol)。一個簡單的理解方式是：

A2A：代理如何相互通信

MCP：代理如何與工具或外部環境進行交互

參考資料：https://google.github.io/A2A/#/topics/a2a_and_mcp

它們解決了建構系統的核心挑戰：多代理、多 LLM 和多源環境——所有這些都需要協作。

一種表述方式是：“MCP 提供垂直集成（應用到模型），而 A2A 提供水平集成（代理到代理）

無論你是否是開發者，任何建立 AI 產品或代理系統的人都應該理解這一基礎架構——因為它影響我們如何設計產品、用戶互動、整體生態系統以及長期的增長。

本文以簡單、易於理解的方式介紹了這兩個協議，並強調了開發者和 AI 產品建立者的關鍵要點。

什麼是 A2A (Agent-to-Agent)?

A2A (Agent-to-Agent) 是由 Google 和超過 50 個行業合作夥伴共同開發的開放協議。其目的是實現 代理之間的互操作性——無論是誰開發它們，在哪裡託管的，或使用什麼框架。

A2A 協議機制

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

A2A 通信模型

A2A 定義了一個兩個代理如何交互的結構化模型。一個代理擔任 “客戶端”代理的角色，發起請求或任務，而另一個代理則作為 “遠端”代理，接收請求並試圖履行。客戶端代理可能會首先進行 能力發現 以確定哪個代理最適合某個工作。

問題來了，代理如何發現彼此。每個代理可以發布一個 代理卡（一個 JSON 元數據文檔，通常託管在標準 URL 如 /.well-known/agent.json）來描述其能力、技能、API 端點和身份驗證要求。

通過閱讀代理卡，客戶端代理可以識別一個適合當前任務的合作代理——基本上是一個該代理知道或可以做什麼的目錄。一旦選擇了目標代理，客戶端代理會形成一個任務對象發送過去。

參考資料：https://google.github.io/A2A/#/

任務管理

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

在 A2A 中，每個代理扮演以下兩個角色之一：

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

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

協作和內容協商

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

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

使用案例範例

以下是一個現實世界的例子，展示了 A2A 如何在企業場景中應用：

一名新員工被聘用於一家大型公司。入職涉及多個系統和部門：

人力資源需要創建記錄並發送歡迎電子郵件
IT 需要配備筆記本電腦和公司賬號
設施需要準備桌子和訪問證

傳統上，這些步驟是手動處理的，或通過內部系統之間緊密耦合的集成來實現。

而使用 A2A 協議，每個部門公開自己的代理：

代理	職責
hr-agent.company.com	創建員工記錄，發送文件
it-agent.company.com	創建電子郵件賬戶，訂購筆記本電腦
facilities-agent.company.com	指派桌子，打印訪問證

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

發現：它會閱讀每個代理的 .well-known/agent.json 以了解能力和身份驗證。
任務分配：
- 發送 createEmployee 任務給 HR 代理。
- 發送 setupEmailAccount 和 orderHardware 任務給 IT 代理。
- 發送 assignDesk 和 generateBadge 給設施代理。
流媒體更新：代理使用 Server-Sent Events 流回進度（例如，“筆記本電腦已發貨”，“桌子已分配”）。
工件收集：最終結果（如 PDF 證件、確認電子郵件、賬戶憑據）作為 A2A 工件返回。
完成：OnboardingPro 在入職完成後通知招聘經理。

什麼是 MCP (Model Context Protocol)?

MCP (Model Context Protocol)，由 Anthropic 開發，解決了另一個問題：如何在運行時為基於語言模型的代理提供 結構化的上下文和工具。

與其說是促進代理間的通信，MCP 更關注於 上下文窗口——LLM 的工作記憶。其目標是：

動態地注入相關的工具、文件、API 函數或用戶狀態到模型的推理階段
讓模型在不對提示或邏輯硬編碼的情況下調用函數或檢索文件

MCP 主要架構

要理解 MCP，首先需要了解整體架構——所有部件如何一起運作。

MCP 主機：“你正在交談的 AI”

把 MCP 主機 想像成 AI 應用程序本身——如 Claude Desktop 或你的編碼助手。

它是你使用的界面——你打字或談話的地方。

它想要 引入工具和數據 來幫助模型提供更好的答案。

MCP 客戶端：“連接器”

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

可以將工具如 ChatGPT、Claude chat 或 Cursor IDE 視為 MCP host—它們提供你互動的界面。在後台，它們使用 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 (Agent-to-Agent)	MCP (Model Context Protocol)
主要目標	實現代理之間的任務交換	讓 LLMs 能夠訪問外部工具或上下文
設計對象	自主代理之間的通信	增強單一代理在推理期間的能力
重點	多代理工作流、協作、分配	動態工具使用、上下文增強
執行模型	代理發送/接收任務和工件	LLM 在推理過程中選擇和執行工具
安全性	OAuth 2.0、API 密鑰、聲明範圍	在應用集成層處理
開發者角色	構建通過端點暴露任務和工件的代理	定義模型可以使用的結構化工具和上下文
生態系統合作夥伴	Google, Salesforce, SAP, LangChain 等	Anthropic, 正在工具化 LLM 界面中的採用中

如何協同運作

而不是成為替代選擇，A2A 和 MCP 是互補的。在許多系統中，兩者將一起使用。

示例工作流程

用戶在企業代理接口中提交複雜的請求。
協調代理使用 A2A 將子任務分配給專門的代理（如分析、人力資源、財務）。
其中一個代理使用 MCP 內部調用搜索功能、檢索文件或使用模型計算。
結果作為工件通過 A2A 返回，使端到端的代理協作具有模塊化工具訪問。

這種架構將 代理間通信 (A2A) 與 代理內部能力調用 (MCP) 分離——使系統更容易組合、擴展和保護。

結論

A2A 關於 代理經網絡相互通信——安全、異步和以任務為中心。

MCP 關於 在模型會話中注入結構化能力，讓 LLMs 在工具和數據上進行上下文推理。

合併使用時，它們支持 可組合的、多代理系統，既具可擴展性又具互操作性。

MCP + A2A 基礎結構如何塑造代理產品市場未來

最後，我想談一下這一核心技術基礎可能如何塑造 AI 市場的未來——以及它對 AI 產品建立者意味著什麼。

人機交互的變化

開發者和服務流的轉變是一個明確的例子。隨著 MCP 服務器現在整合到 IDE 和編碼代理中，開發者與工具互動的方式發生了根本性的變化。

以前的典型工作流程涉及搜索正確的服務、設置託管、閱讀文檔、手動集成 APIs、在 IDE 中編寫代碼，並通過低代碼儀表板配置功能。這是一個碎片化的體驗，每一步都需要上下文切換和技術開銷。

現在，隨著 MCP 連接的編碼代理，這種複雜性大部分可以被抽象掉。開發者可以通過對話提示更自然地發現和使用工具。API 集成成為編碼流程的一部分——通常不需要單獨的 UI 或手動設置。（想像一下 AWS 或 Microsoft 儀表板有多複雜）。交互變得更加順暢——更多地關於指導行為而不是組裝功能。

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

而不是使用 UI “補貼”技術挑戰（例如：“這太難編碼了，讓我們製作一個配置面板”），我們現在需要：

考慮 端到端的體驗
設計 AI 和用戶互動 何時何地應匯合
讓 AI 處理邏輯，並通過意圖和流程引導用戶

挑戰在於決定 AI 和用戶輸入應何時何地匯合，讓 AI 處理邏輯，並通過意圖和流程引導用戶，以及在正確的時間插入正確的交互。

我用了一個開發者服務和 API 產品作為例子來展示用戶互動怎麼可能改變——但這同樣適用於商業軟件。長期以來，商業工具一直複雜難用。自然語言互動有潛力簡化許多這些工作流。

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

我們開始看到越來越多的 MCP 服務器 出現。想像一下 Airbnb 提供 預訂 MCP 服務器，或者 Google 地圖公開 地圖 MCP 服務器。一個代理（作為 MCP 客戶端）可以同時連接到許多這些服務器——解鎖以前需要自定義集成或緊密綁定應用的工作流。

相比於 SaaS 時代，集成往往是手動且固定不變的，這種模式允許 更多自動化工作流 和 服務之間的流動連接。以下是兩個例子：

從文檔設計

你在 Notion 中撰寫了一個 PRD。Figma 代理閱讀該文檔，自動創建一個概念草圖——不需要手動交接。
競爭對手研究，端到端

你要求進行競爭分析。一組代理在網上搜索，代表你註冊相關服務（具有安全驗證），收集結果，並返回經過整理的工件——已經在你的 Notion 工作區內。

認證與授權邊界的挑戰

隨著代理與代理連接、MCP 客戶端到 MCP 服務器連接的增長，出現了許多關於認證和授權的基礎需求，因為代理將代表人類行動，並且憑據必須在此過程中加以保護。

目前有幾個針對新興的代理到代理和 MCP 的場景。

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

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

例如，使用者 U 與需要 A-system 标识符的代理 A 合作。如果代理 A 依賴於需要 B-system 标识符的工具 B 或代理 B，使用者可能需要在單一請求中同時提供 A-system 和 B-system 的身份标识。（假設 A-system 是企業 LDAP 身份，而 B-system 是 SaaS 提供者身份）。

Logto 是一個 OIDC 和 OAuth 提供者，適合 AI 集成的未來。

憑藉其靈活的基礎結構，我們正在積極擴展其功能，並發布了一系列教程，幫助開發者快速入門。

有問題嗎？

聯繫我們 ——或立即親自探索你能用 Logto 建立什麼。

免費試用 Logto Cloud

什麼是 A2A (Agent-to-Agent)?#

A2A 協議機制#

A2A 通信模型#

任務管理#

協作和內容協商#

使用案例範例#

什麼是 MCP (Model Context Protocol)?#

MCP 主要架構#

MCP 主機：“你正在交談的 AI”#

MCP 客戶端：“連接器”#

MCP 服務器：“工具提供者”#

本地數據來源：“你的文件和服務”#

遠程服務：“API 和在線工具”#

整合所有內容#

A2A vs MCP — 比較#

如何協同運作#

示例工作流程#

結論#

MCP + A2A 基礎結構如何塑造代理產品市場未來#

人機交互的變化#

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

認證與授權邊界的挑戰#