A2A
為什麼重要
深度解析
A2A 要處理的問題很容易說明：隨著組織部署愈來愈多代理，這些代理必須彼此轉交工作，而目前每一組配對都需要專門整合。A2A 為這種交接定義共同模式：一個代理擔任用戶端並提出任務，另一個遠端代理則執行任務。雙方透過一般 Web 基礎設施交換上下文、指示與結果——傳輸格式是以 HTTP 傳送的 JSON-RPC 2.0，即時更新則採用 Server-Sent Events——因此導入時不需要新的傳輸層，也不必共用執行環境。關鍵在於，代理彼此仍不透明：它們透過已宣告的能力與任務狀態協調，而不分享記憶體、權重或內部推理。
代理卡與能力探索
A2A 透過代理卡進行探索：這是一份小型 JSON 文件，通常發布於代理網域下的標準路徑，例如 /.well-known/agent.json，其中說明代理由誰營運、提供哪些技能、接受哪些輸入與輸出格式，以及需要何種身分驗證。用戶端代理在傳送任何實際工作前會先取得這張卡，以便透過程式或 LLM 規劃器判斷該遠端代理是否適合執行任務。實務上，卡片會以兩種方式出現：若工作流程已知道合作代理的 URL，便直接存取；或者透過企業為核准的智能體維護的精選登錄庫取得。卡片模型讓 A2A 不只是訊息傳遞慣例，而成為真正的探索層；它也呼應自主代理看待其他資源的方式：閱讀說明、比對目標，然後採取行動。
任務、訊息與成果物
A2A 的工作單位是任務，並有明確的生命週期：已提交、執行中、需要輸入、已完成、失敗或已取消。任務中的兩個代理會交換訊息，每則訊息都由數個部分組成，而不只是原始文字——自然語言放在文字部分，二進位內容放在檔案部分，表單與報價等結構化 JSON 酬載則放在資料部分。這種組成模型很重要，因為真實商業工作流程仰賴結構化資料；A2A 讓代理可以針對Structured Output（結構化輸出）協商，不必將所有內容強塞進對話文字。任務結束時，結果會以成果物交付：這些具名輸出也由數個部分構成，用戶端代理可自行使用，也可傳給更大型代理工作流程的下一個步驟。
生命週期狀態在長時間執行的工作中格外重要。需要數分鐘或數小時才能完成的任務，可透過 Server-Sent Events 將進度事件串流至用戶端；若用戶端無法持續保持連線，也能以推播通知將更新傳至 webhook，讓已中斷連線的使用端仍可運用Streaming（串流）。其中最微妙的是「需要輸入」狀態：遠端代理可以在任務途中暫停並提出釐清問題，使代理間的多輪協商不必打破任務抽象。
A2A 不會取代 MCP
對 A2A 最常見的誤解，是認為它與 MCP 競爭。並非如此——兩項協定在不同層次運作。MCP 將單一代理連接工具與資料來源的方式標準化，例如呼叫函式、讀取資源或執行查詢。A2A 則將兩個獨立代理協調的方式標準化，由一方把任務委派給可能隸屬完全不同團隊、供應商或信任網域的同儕。常見的簡要說法是，MCP 是縱向介面，也就是代理對工具；A2A 是橫向介面，也就是代理對代理。
實際的正式環境架構會在同一條呼叫鏈中同時使用兩者。編排代理可能用 MCP 完成工具使用——連接 CRM、搜尋索引或程式碼庫——再以 A2A 將工作外包給專業代理，例如由法務部門執行的合約審查代理，而該代理本身又在內部使用 MCP 與 Function Calling。兩項協定都不規定另一個代理內部如何運作，而這種不透明性是刻意的設計：組織能彼此協作，又不必揭露提示詞、記憶體或專有推理。
治理、生態系與未決問題
Google 於 2025 年將 A2A 以開放規格發布，並提供參考 SDK；推出時已有超過 50 個技術合作夥伴支援，涵蓋企業軟體供應商、LangChain 等框架，以及顧問公司。Google 隨後將專案捐贈給 Linux Foundation，避免任何單一供應商控制其發展。這項治理安排對普及十分重要：唯有競爭對手不必擔心規則隨時遭單方面改變，協定才能成為通用的底層設施。規格、SDK 與代理範例全都公開，設計也刻意沿用現有 Web 標準，而沒有另行發明新標準。
接下來真正棘手的問題，與其說是訊息格式，不如說是信任。代理卡會宣告所需的身分驗證，但協定本身無法告訴你是否該相信這張卡，因此跨組織 A2A 流量既是整合問題，也是AI 安全問題。提示注入就是一項具體風險：惡意或已遭入侵的遠端代理，可以將有害指示嵌入任務結果，而用戶端代理的模型會照樣讀取。現今，使用 A2A 建構多代理系統的團隊，通常會將探索範圍限制在精選登錄庫、在成果物送入模型前先加以驗證，並預設所有遠端代理均不可信任。