Hugging Face 的 LOGO
返回文章列表

🦸🏻#17: 什麼是 A2A，以及為什麼它——仍然！——被低估了？

社群文章 釋出於 2025 年 5 月 7 日
贊
13
Ksenia Se's avatar
Ksenia Se
Kseniase

🔳 關於 Google 的 Agent2Agent 協議，你需要知道的一切（如果 Google 構建了世界上第一個代理目錄，A2A 將是它所使用的語言）

企業 AI 採用面臨的最大挑戰之一是如何讓基於不同框架和供應商的代理協同工作。

Google，關於代理互操作性的重要性

還記得我們希望 AI 代理能夠順暢完成的經典例子嗎？“下週末給我訂去紐約的旅行。首選直飛航班，週五下午出發，週日晚上返回。再找一個靠近好爵士酒吧的酒店。”這個問題（除了變成老生常談）是 AI 代理仍然難以理解你的全部意圖，跨多個步驟進行規劃，以及在各種工具上可靠地行動——所有這些都無需持續的人工干預。每個步驟（解析任務、尋找選項、權衡、預訂）單獨工作都還可以，但是將它們平穩安全地整合在一起呢？這仍然很脆弱，容易出錯。目前大多數代理都是孤立執行的，每個都侷限於自己的生態系統或供應商。因此，我們面臨著一個碎片化的局面，代理之間無法直接通訊，從而限制了它們在複雜的跨系統工作流中的作用。2025 年 4 月，Google 推出了 Agent2Agent (A2A) 作為一個開放協議，旨在打破這些孤島。它得到了由 50 多個合作伙伴（從 Atlassian 和 Salesforce 到 LangChain）組成的全明星陣容的支援。A2A 旨在成為一種“通用語言”，讓獨立的 AI 代理能夠跨應用程式無縫協作。

然而，儘管聲勢浩大地釋出，並有 50 家知名合作伙伴，但幾周後 A2A 仍然被低估。它並沒有像人們預期的那樣，掀起一陣狂潮。

image/png Reddit 上的受歡迎程度以及命名問題😳

目前，趨勢顯示增長放緩——為什麼這項可能成為關鍵基礎設施的技術，卻反應平平？

image/png 圖片來源：GitHub Star History

在本文中，我們將深入探討 A2A——它是什麼，為什麼存在，如何工作，人們如何看待它——並探討其採用滯後的原因（以及為什麼這種情況可能很快改變）。我們將介紹 A2A 的技術基礎，將其與 Anthropic 的 MCP 等協議進行比較，並解釋構建多代理系統所面臨的實際挑戰。在此過程中，我們還將探討 Google 推動代理互操作性可能帶來的更大影響——甚至可能為可搜尋的、網際網路規模的 AI 代理目錄奠定基礎。一如既往，這是一份很棒的入門指南，但對於那些已經嘗試過 A2A 並希望瞭解更多資訊的人也很有用。深入瞭解吧！

📨 點選關注！如果你想直接在收件箱中接收我們的文章，請在此訂閱

在 🎥 YouTube、Twitter 和 Hugging Face 🤗 上關注我們

在本期節目中，我們將討論

為什麼 A2A 尚未掀起波瀾（但很快就會）

谷歌釋出 A2A 協議的每一步都恰到好處：一個引人注目的跨代理協作願景、重量級合作伙伴、開原始碼，甚至與 Anthropic 的模型上下文協議（MCP）形成互補關係。理論上，時機完美。AI 世界正為“代理”框架而沸騰——但大多數第一代“AI 代理”堆疊都是單兵作戰，單個大型語言模型配備了工具箱外掛或 API。最近，我們看到 MCP 的巨大成功，它標準化了 AI 代理訪問工具和上下文的方式，充當了一種“AI 的 USB-C 埠”。A2A 從此基礎上接續：標準化多個自主代理如何通訊，使它們能夠在沒有自定義整合粘合的情況下交換任務和結果。

那麼，為什麼 A2A 沒有一夜爆紅呢？部分原因是炒作動態。Anthropic 在 2024 年底釋出 MCP 時，最初反響平平；直到幾個月後，它才作為遊戲規則改變者而受到關注。A2A 可能也正在經歷類似的認知延遲。它的價值乍一看有點抽象——企業代理互操作性不像新的最先進模型或編寫程式碼的聊天機器人那樣立竿見影。許多開發人員尚未感受到多代理協作的痛苦，因為他們仍在嘗試單代理應用程式。在較小規模的專案中，人們可能只是在一個指令碼中編排多個 API 呼叫，或者在內部使用 LangChain 這樣的框架，而不需要正式的協議。A2A 解決方案的真正緊迫性在更大、更復雜的環境中變得顯而易見——正是在大公司中——但這個故事仍在向更廣泛的社群傳播。

另一個因素是“又來一個標準”的疲憊感。在過去的一年裡，許多擴充套件大型語言模型（LLM）的方法層出不窮：OpenAI 的函式呼叫、各種外掛系統、自定義 RPC 方案，更不用說特定於供應商的代理 API。開發人員可能會問：我們真的需要另一個協議嗎？目前，A2A 仍然非常新，很少有公開的成功案例——沒有令人瞠目結結舌的“代理與代理對話”的病毒式殺手級演示。如果沒有這種火花，A2A 仍將默默無聞，只對那些閱讀規範的人悄然有趣，但在日常 AI 開發人員的聊天中尚未成為流行語。（請記住，所有進一步學習的連結都包含在文章末尾。）

image/png

那麼，A2A 是什麼？它是如何工作的？

其核心是，Agent2Agent (A2A) 是一種通訊協議，允許獨立的 AI 代理以結構化、安全的方式相互交流。具體來說，它定義了一組基於 HTTP 的 JSON 訊息，供一個代理請求另一個代理執行任務，並獲取結果——如果需要，可能還需要來回的對話。它是一個開放標準（在 Apache 許可下開源），任何代理框架或供應商都可以實現，實現互操作性，就像 Web 瀏覽器和伺服器共享 HTTP/HTML 標準一樣。

image/png

讓我們分解 A2A 的關鍵元件：

A2A（代理間通訊）的核心是 代理卡（Agent Card）——一個公開的清單，通常託管在 /.well-known/agent.json，它描述了代理的能力、端點 URL 和身份驗證要求。可以把它想象成一個 OpenAPI 風格的配置檔案：客戶端代理可以獲取另一個代理的卡片，並立即檢視，例如，“這個代理可以處理 CRM 票證並生成報告”，然後才決定向它傳送任務。

A2A 定義了兩種靈活的角色：客戶端（請求代理）和伺服器（執行代理）。任何符合 A2A 規範的代理都可以靈活地切換角色，從而實現靈活的拓撲結構，如點對點網格或中心輻射模型。

協作的核心單位是任務（Task）。客戶端在請求遠端代理執行工作時建立任務，使用 tasks/send 請求。每個任務都有唯一的 ID，並經歷生命週期：提交、工作中、需要輸入、已完成或失敗。兩個代理共同跟蹤任務進度，支援更豐富、多步驟的互動，如澄清問題或部分交付。

訊息（Messages）及其部分（Parts）構建了對話。一條訊息可以是使用者請求、狀態更新或後續操作，每條訊息都由多個部分組成——這些內容塊可以是純文字、結構化 JSON 資料，也可以是影像或 PDF 等二進位制檔案。這種設計支援多模態通訊：例如，代理可以傳送表單（結構化資料）而不僅僅是文字，從而使互動更加動態。

當任務完成時，輸出將打包成一個工件（Artifact），它也由多個部分組成。工件是持久的、結構化的結果——PDF 報告、JSON 資料集、影像——其他代理可以在新任務中立即重用，而無需額外的解析。

A2A 還支援流式傳輸和通知。長時間執行的任務可以透過伺服器傳送事件（SSE）流式傳輸即時更新，讓客戶端代理訂閱任務進度。代理甚至可以直接將更新推送到客戶端的 Webhook，從而允許非同步架構進行乾淨整合。

在底層，A2A 完全建立在熟悉的 Web 標準之上：帶有 JSON-RPC 2.0 有效載荷的簡單 HTTP 請求、用於流式傳輸的 SSE，以及典型的 REST API 身份驗證方法，如 OAuth 2.0、雙向 TLS 或簽名 JWT。沒有異構傳輸層或自定義二進位制編碼——只是務實的選擇，使企業採用變得更加容易。

一個典型的 A2A 互動可能如下所示：代理 Alpha（客戶端）需要一張銷售圖表。它獲取代理 Beta（伺服器）的代理卡，並看到一個“create_chart”功能。Alpha 傳送一個任務：“生成第一季度按地區劃分的銷售條形圖。”Beta 確認任務並在工作時流式傳輸進度更新。如果 Beta 需要更多詳細資訊——例如，澄清哪些地區——它會發送一個需要輸入的訊息，Alpha 則回覆。當圖表準備好後，Beta 返回最終工件（影像檔案），Alpha 可以使用它或將其交給另一個代理。

由於 Beta 的技能是公開可發現的，並且透過統一的 JSON 協議呼叫，整個互動避免了通常脆弱的 API 移交和自定義粘合程式碼。這就是 A2A 的承諾：使代理協作像呼叫 REST 端點一樣無縫。

我如何實際開始使用 A2A？（最基本的方式）

你需要什麼

  • 程式碼編輯器，例如 Visual Studio Code (VS Code)
  • 命令列提示符，例如 Terminal (Linux)、iTerm (Mac) 或 VS Code 中的 Terminal

怎麼做

  1. 克隆倉庫 git clone https://github.com/google/A2A && cd A2A —— 它包含規範、Python SDK 和可執行的演示代理。

  2. 啟動兩個示例代理

cd samples/python/agents/hello_world
python server.py --port 5001      # “remote” agent
cd ../cli
python main.py --task "say_hi"    # “client” agent

您將看到任務生命週期訊息完全按照規範的描述透過 HTTP 流動。

  1. 給你的代理一個身份 在你的服務旁邊放置一個名為 /.well-known/a2a.json 的檔案（代理卡）。它是一個單頁簡歷：名稱、描述、身份驗證方法，以及最重要的——宣示你可以處理哪些任務的能力陣列。
  2. 封裝你自己的邏輯 如果你已經有一個基於 LangChain、CrewAI 或純 Python 的代理，安裝小介面卡並暴露它。
pip install python-a2a
from python_a2a.langchain import to_a2a_server
a2a_server = to_a2a_server(my_langchain_agent)
a2a_server.run(port=5000)
``` :contentReference[oaicite:3]{index=3}

此後的一切——安全性、登錄檔、可觀測性——都只是正常的微服務衛生，只是現在您的“微服務”以任務和工件而非 REST 動詞進行通訊。

A2A 之前：孤立代理的碎片化世界

在 A2A 之前，大多數 AI 工作流都圍繞著一個“超級代理”來編排一系列工具——因此 MCP 崛起——所以真正的代理到代理的交接是罕見的。多代理協作的嘗試都是臨時性的：脆弱的自然語言聊天或供應商鎖定的框架，它們無法在沒有大量粘合程式碼的情況下混合 Microsoft、Google 和開源代理。由於沒有通用方法來發現對等體、傳遞任務或引用工件，每個握手都是定製的——碎片化很快就成為擴充套件的噩夢。（20 世紀 90 年代，像 KQML 和 FIPA-ACL 這樣的學術協議曾試圖解決這個問題，但它們從未進入當今的 LLM 世界。）

image/png

A2A 是 AI 協作的靈丹妙藥嗎？+ 挑戰

有如此多的前景，重要的是要問：A2A 能解決所有問題嗎？當然不能。就像 MCP 或任何新技術一樣，A2A 也有其自身的一系列挑戰，並非多代理系統的萬靈藥。最好將 A2A 視為一個強大的賦能者——一個可以使以前不可能的工作流變得可行的整合層——但它本身並不能保證成功。

一個重要的限制是：A2A 並不能讓代理更智慧——它只是讓它們更容易交流。如果你連線兩個平庸的代理，你不會得到卓越；你只會冒著任務傳遞無休止卻毫無進展的風險。有效的協作仍然需要仔細設計：決定誰處理什麼，確保共享目標，處理故障。簡而言之，A2A 並不能消除對編排智慧的需求；它只是將編排中的通訊標準化。

採用 A2A 還會帶來額外的運營開銷。每個代理都成為一個服務（帶有 HTTP 端點或嵌入式伺服器），這意味著要管理一個代理網格：Workday 上的 HR、Salesforce 上的銷售、自定義 Python 分析——所有這些都需要發現、身份驗證、監控和彈性。這又是微服務的老一套。對於小型工作流，簡單的指令碼可能更容易。就像 MCP 一樣，只有當你擁有許多工具和上下文時才能發揮作用，A2A 只有在你將許多具有不同功能的代理連線在一起時才能發揮作用。

A2A 的規範是全新的（技術上仍是草案），並且很可能會不斷發展。實施者應該預期到可能出現重大更改、邊緣情況錯誤和不斷變化的目標。與任何新協議一樣，早期採用者也扮演著測試者的角色。如果您不準備積極參與社群，這可能會成為一個障礙。

相容性是另一個障礙。A2A 得到越多代理和供應商的支援，其價值就越大。如果沒有達到臨界質量，您可能最好使用原生 API。Google 已經召集了一批令人印象深刻的企業合作伙伴，但 OpenAI 和 Microsoft 等主要參與者尚未公開認可 A2A（Microsoft 的 Semantic Kernel 部落格展示了一個實驗性的 A2A 介面卡，但這只是 SDK 團隊的實驗——並非正式認可）。Anthropic 的 MCP 是互補的，但並非相同。如果我們最終陷入協議戰爭——A2A vs. MCP vs. 其他——開發人員可能會陷入構建介面卡或退回到脆弱整合的困境。

安全是另一個前沿。A2A 包含了令牌認證和 TLS，但實際策略、憑據和審計則留給使用者。企業可能需要“代理閘道器”——相當於 API 閘道器——來管理代理之間的信任。

所有這些都不是阻礙。這只是新基礎設施的樣子。微服務需要數年才能成熟。A2A 也會如此。它不是萬靈藥——它是一種協議粘合劑。但有了正確的期望和試點專案，它可以解決多代理系統中的通訊問題。其餘的仍然取決於良好的設計、周到的實施以及一個願意推動其發展的社群。

MCP 和 A2A 會成為競爭對手嗎？

簡短的回答是不會。儘管有些人認為，如果 A2A 開始吸收傳統上由 MCP 涵蓋的功能——特別是如果公司開始主要將資料和服務建模為獨立代理而不是簡單的工具或資源——那麼競爭可能會出現，但我認為這種情況極不可能。

工具和資源將始終是代理系統中獨特且必不可少的基礎構建塊，它們的整合空間足以輕鬆容納這兩種協議。MCP 擅長標準化 LLM 與外部資料來源或工具之間的互動，而 A2A 則解決安全、有狀態的代理間通訊。鑑於它們互補的優勢和代理生態系統的龐大規模，MCP 和 A2A 將共存，各自找到其明確定義且有價值的角色。

A2A 在代理編排中的應用及其在 AI 堆疊中的地位

A2A 在新興的 AI 基礎設施堆疊中佔據怎樣的位置？要回答這個問題，請想象將原始 AI 模型轉化為有用自主代理所涉及的各個層級。在之前的討論中，我們已經分解了代理系統的組成部分——例如記憶體、推理和工具使用。A2A 並不試圖解決所有這些問題；它作為一個通訊和協調層插入其中。

首先，考慮單個代理。它通常由一個核心模型（如大型語言模型）、行為邏輯（透過提示或規劃）以及與外部世界（工具、API）互動的機制組成。像 LangChain、Semantic Kernel 和 Google 的 Agent Development Kit (ADK) 這樣的框架有助於管理這些部分。MCP，正如我們之前介紹的，標準化了代理如何連線到外部工具。

A2A 位於更高一層：代理到代理。如果 MCP 和工具 API 使代理能夠對世界採取行動，那麼 A2A 則使代理能夠相互作用。它們是互補的，而不是競爭對手。事實上，它們經常結合使用。一個代理的 A2A 卡可以宣傳其內部由 MCP 提供支援的功能——例如，“發票處理代理”可以提供提取發票欄位（透過 A2A），同時在後臺使用 OCR 工具（透過 MCP）。A2A 編排多代理工作流，而將內部工具管理留給每個代理。

堆疊起來

  • 大型語言模型（LLM）和推理——核心智慧和決策邏輯。
  • 工具/上下文介面（MCP，外掛）——讓代理使用外部工具和資料。
  • 代理框架/執行時——管理代理迴圈、記憶體和任務拆分。
  • 代理間協議（A2A）——允許代理跨系統協調和委託。
  • 編排器/管理器——（可選）決定何時呼叫其他代理的監督邏輯。

重要的是，A2A 不會取代 LangChain、Semantic Kernel 或其他框架——它允許它們互操作。A2A GitHub 倉庫已經包含了 LangChain、LlamaIndex、Marvin、Semantic Kernel 等的介面卡。現在，一個 LangChain 代理和一個 Semantic Kernel 代理可以無需自定義粘合程式碼即可協作。

這是一個熟悉的模式：在早期網路開發中，應用程式無法通訊，直到 REST 等協議標準化了通訊方式。現在，A2A 試圖為 AI 代理做同樣的事情。

最後，雖然 OpenAI 的函式呼叫允許代理內部工具使用，但 A2A 實現了代理間的協作。它們服務於不同的範圍，很可能會在複雜的系統中共存。

如果成功，A2A 將成為多代理工作流的通用語言——一個不起眼但至關重要的 AI 基礎設施下一階段的推動者。

image/png

A2A 開啟的新可能性

由於 A2A 尚未引起主流關注，許多人低估了它所能實現的工作流和協作型別。讓我們來看幾個例子。

  • 專家代理協同工作：A2A 允許專業代理團隊動態協作，而不是構建一個巨大的代理來處理所有事情。例如，在客戶支援中，技術故障排除代理、財務代理和促銷代理可以在一個會話中無縫地移交任務，這就像人類團隊的運作方式一樣。使用者只與一個前端互動，而代理在後臺協作。
  • 跨企業工作流：企業執行在許多平臺上——Salesforce 用於 CRM，ServiceNow 用於 IT，Workday 用於 HR。有了 A2A，HR 代理可以請求 IT 配置一臺筆記型電腦，而無需手動 IT 工單或脆弱的 API 粘合程式碼。每個代理在其各自領域保持卓越，但可以透過協議插入更大的、跨公司的工作流。
  • 動態代理切換和升級： A2A 標準化了功能，為模組化打開了大門。你可以用一個商業總結代理替換一個開源總結代理，而無需改變其呼叫方式。隨著時間的推移，這可能會導致一個可互操作代理的市場——僱傭一個法律分析代理、一個翻譯代理、一個市場研究員——所有這些代理都使用 A2A 進行通訊。
  • 人機協同監督：並非所有代理都必須是 AI。人類也可以透過 A2A 客戶端參與——批准或修改 AI 建議的任務，或監控代理之間敏感的互動。透過標準化的工件和任務狀態，這種正式的交接和監督變得更加容易。
  • 跨組織聯合代理： 從長遠來看，A2A 可以讓不同公司的代理安全地協作，跨組織邊界交換任務。供應鏈代理協商庫存、跨公司研發團隊——一旦信任層和協議到位，所有這些都成為可能。

在 A2A 出現之前，許多這些設定要麼不可行，要麼成本極高。諷刺的是，當 AI 世界追求更大的模型和更花哨的提示時，像 A2A 這樣不起眼的“管道”卻可能解鎖質的新能力。透過使代理協作模組化、安全和即插即用，A2A 降低了創新的門檻——我們才剛剛開始看到它的可能性。

總結思考——Google 能否將 A2A 變成一個像 Google 搜尋一樣的公共代理索引？

技術上，是的。該規範已經要求每個相容的代理在 /.well-known/agent.json 釋出一個機器可讀的代理卡片。這是爬蟲的完美鉤子：只需跟隨 URL，獲取卡片，然後將元資料放入 Bigtable——這正是 Google 將 robots.txt + sitemap.xml 轉化為 Web 索引的方式。今天，這個發現步驟是點對點的，但沒有什麼能阻止 Googlebot-for-Agents 在網際網路規模上做同樣的工作。

Google Cloud 內部的早期訊號顯示了這種需求。Agentspace 的 Agent Gallery 已經是一個受限的、可搜尋的企業客戶目錄；它列出了 Google 構建的、合作伙伴和內部代理，並利用 Cloud Marketplace 進行分發。這是一個迷你的代理應用商店——只是缺少公共爬蟲。

image/png

A2A 鋪設了管道；至於 Google 是否會將這些管道變成世界的總機，這仍然是一個懸而未決的問題。不過，A2A 仍處於早期階段。它今天不為人知的地位，讓人想起容器、Kubernetes 和 REST API 最初的竊竊私語——在生態系統發生轉變後，這些技術才爆發式增長。如果山景城真的推出了一個公共代理索引，它可能會成為自主軟體的 DNS——強大、有利可圖，且具有政治敏感性。在這個未來明朗之前，請試用 A2A，跟蹤競爭對手的規範，並保持敏捷。基礎設施的成功，與其說是靠才華，不如說是靠信任、激勵和成千上萬個默默無聞的整合故事。關注這些故事吧。

作者：Ksenia Se

深入瞭解的資源：

來自 Turing Post 的資料

📨 如果您想直接在收件箱中收到我們的文章，請在此訂閱

社群

註冊或登入以評論

贊
13
© . This site is unofficial and not affiliated with Hugging Face, Inc.