Google A2A Protocol: Analysis of Adoption and Technical Challenges

Google 開發的 A2A (Agent-to-Agent) 協定是一個框架，旨在讓獨立開發的 AI agent 可以互相發現並進行通訊。雖然它為 agent 提出了「微服務架構」，但目前的開發者情緒顯示，與 Model Context Protocol (MCP) 等新興標準相比，它面臨著巨大的採用障礙。

The Core Value Proposition of A2A

A2A 旨在解決自主 agent 之間的互操作性問題。透過提供一種標準化的方式讓 agent 進行互動，它允許團隊獨立開發專業化的 agent，然後透過將任務委派給最相關的 agent 來協調處理複雜的查詢。

Key implementation paths include:

  • Google Ecosystem Integration: gemini-cli 可以連接到遠端 A2A agent，且自定義的 Google ADK "agent" 可以透過 A2A 以極小的配置進行公開。
  • Organizational Layering: 一些開發者使用 A2A 來分層構建 agent，模仿組織結構，其中主 agent 協調與子 agent 的互動。
  • Independent Development: 它允許一種解耦的架構，只要 agent 遵循 A2A 標準，agent 就可以在不破壞整個系統的情況下進行更新或更換。

Primary Technical and Conceptual Criticisms

儘管其目標明確，但許多技術從業者發現 A2A 協定被過度設計，或者在關於 agent identity 的假設上存在根本性的缺陷。

The Identity Paradox

一個重大的批評是，A2A 假設透過 agent cards 擁有一個定義明確且持久的 "agent identity"。批評者認為 agent 缺乏內在的身份感，且 agent 與另一個實體通訊，與 agent 與其未來的版本通訊之間，通常沒有功能上的差異。

Implementation Overhead

開發者提到了關於該協定技術棧的幾個摩擦點：

  • gRPC Complexity: 使用 gRPC 被描述為增加了一層間接性和模糊性，使得實作變得痛苦。
  • Resource Inefficiency: 一些使用者聲稱該協定在設計時沒有充分考慮 prompt caching、延遲或 token 成本。
  • Over-Engineering: 多位開發者建議，對於 agent-to-agent 通訊，使用基於 Markdown 的規範的簡單 API 比正式的協定更有效率。

A2A vs. MCP and Other Alternatives

目前存在一種強烈的開發者遷移從 A2A 到 Model Context Protocol (MCP) 或開發專有解決方案的趨勢。

The Rise of MCP

許多開發者報告從 MCP 遷移到 A2A，然後又回到了 MCP。Model Context Protocol 被認為具有更高的動能，因為它被用於 Claude 和 OpenAI 等主要參與者進行原生整合。目前，構建 MCP server 相比於構建 A2A server 的誘因被認為更高。

Emerging Competitors

除了 MCP，其他協定也在興起，旨在解決特定領域的需求。例如，VS Code 團隊正在使用 Agent Host Protocol (AHP) 重建 agent 基礎設施，該協定專注於與多個 agent 和 harness 的主機進行通訊的通用協定。

Summary of Developer Perspectives

社群的見解突顯了標準化 agent 網絡的理論效用與實作的實際現實之間的差距：

"A2A 解決了獨立開發的 agent 互相通訊的問題。更大的問題是 '如何我信任你的 agent 運作良好？'... 否則一個 Agent Directory 和 agent 的自動派遣，幾乎是毫無用處的。"

"我認為隨著一切趨於成熟，A2A 或類似的東西會成為一件大事。只是對我們的使用案例來說，感覺過於複雜。"

最終，雖然 A2A 為去中心化的 agent 生態系統提供了藍圖，但其目前的複雜度以及缺乏一個強大的 "Agent Eval" 系統來驗證 agent 的可靠性，阻礙了其廣泛採用。

Sources