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

隨著 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 協議，每個部門公開自己的代理：

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

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

整合所有內容#

現在讓我們用一個圖表看所有部分如何一起工作。

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 關於 在模型會話中注入結構化能力，讓 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 時代，集成往往是手動且固定不變的，這種模式允許 更多自動化工作流 和 服務之間的流動連接。以下是兩個例子：

1. 從文檔設計

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

2. 競爭對手研究，端到端

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

認證與授權邊界的挑戰#

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

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

1. 代理 vs SaaS 和網站應用
2. MCP 客戶端（代理）vs MCP 服務器
3. 用戶 vs 代理
4. 代理 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 建立什麼。