多數人這一兩年多少聽過 MCP（Model Context Protocol），知道它讓 AI 能接資料庫、串工具，把外面的資源餵給模型用。但這裡有一個少被問到的問題：如果你公司有一個專門處理訂單的 AI、供應商那邊也養了一個自己的 AI，這兩個「各自都很會用工具」的 AI，要怎麼互相講話、互相交辦事情？
MCP 解決的是「AI 怎麼接工具」，它從來沒有處理「AI 跟另一個 AI 怎麼對話」這件事。這正是 Google 在 2025 年主推的 A2A 協定（Agent2Agent Protocol） 想補上的空缺。A2A 是一套開放標準，讓不同框架、不同供應商打造出來的 AI agent 能彼此發現、溝通、交辦任務，不必為每一組對接都寫一次客製程式。
所以真正的問題，其實不是「A2A 是不是又一個新名詞」，而是它跟你已經聽過的 MCP 到底是不是在搶同一塊地盤。先從它想解決的那個困境講起，再一路拆到它跟 MCP 各自顧的是什麼。
A2A 是什麼？先搞懂它想解決的問題
要理解 A2A，先看看沒有它的世界長什麼樣子。這一兩年 AI agent 冒出得很快，一家公司裡可能同時有負責回覆客訴的客服 agent、有專門查內部資料的 agent，往來的供應商那邊也各自有自己的 agent。問題在於，這些 agent 往往來自不同的開發框架、不同的供應商，彼此語言不通，沒辦法直接協作。每一個都很聰明，卻像被關在各自的房間裡，形成一座座「智慧孤島」。
這種困境有個常見的說法，叫「M×N 問題」。假設你這邊有 M 個 agent，要對接外面 N 個對象，在沒有共同標準的情況下，每一組配對都得單獨客製一次串接，也就是 M 乘上 N 條線，每一條都要有人寫、有人維護。agent 愈多、要對接的對象愈多，這張網就愈亂，整合成本也跟著往上疊。
這件事在企業級場景特別痛。個人隨手用一個 AI 助理，頂多就是它自己接幾個工具；但在真實的商業流程裡，一筆訂單、一次退款、一個入職案件，經常要橫跨好幾套系統、好幾個部門，背後就是好幾個 agent 得接力完成。少了共同語言，這些接力棒只能靠人工在中間搬，或是逐一寫死的客製 API 硬串。A2A 要處理的，就是這個「agent 之間沒有共同語言」的根本問題。
A2A 正式定義：Agent 對 Agent 的共同語言
把背景鋪清楚了，正式的定義就好懂多了。A2A 是一套開放標準，讓用不同框架、不同供應商技術打造出來的 AI agent，能夠互相發現彼此、溝通、交換資訊、協調行動，而且過程中不需要暴露各自內部的邏輯、工具或專屬實作。換句話說，兩個原本互不相識的 agent，只要都遵循這套協定，就能直接對話，不必事先為對方量身訂做一套對接。
它的來歷也值得說清楚。A2A 是 2025 年 4 月由 Google 發起的，但它並不是 Google 的專屬產品。這套協定後來已經捐給 Linux Foundation 這個中立的開源基金會來治理，由一個技術指導委員會負責推進，成員橫跨 AWS、Cisco、Google、IBM、Microsoft、Salesforce、SAP、ServiceNow 等多家公司。這一點很關鍵，它是一套由多方共同維護的中立開放協定，而不是綁在某一家雲端廠商身上的封閉規格。這也是它能被當成「共同語言」來期待的前提。
A2A 怎麼運作？從「名片」到「任務」的協作流程
知道 A2A 想幹嘛，接著看它實際上怎麼讓兩個 agent 合作辦成一件事。這裡不用把它當規格書來背，只要順著「一方提需求、一方去執行」的畫面走一遍就懂了。
先看角色分工。A2A 裡有兩種角色：一個是 client agent（發起端），也就是提出需求、把工作交出去的一方；另一個是 remote agent（執行端），負責接下這份工作、把它做完再把結果回傳。同一個 agent 在不同情境裡可以扮演不同角色。這次它是發需求的一方，下次換別人來找它幫忙，它就成了執行端。
那兩個素未謀面的 agent 怎麼知道對方會做什麼、該怎麼連上？答案是 Agent Card（能力名片）。你可以把它想成一張機器讀得懂的數位名片，是一份公開的 JSON 檔，放在每個 agent 伺服器上一個固定、好猜的位置（慣例是 /.well-known/agent.json 這個路徑）。這張名片上寫著這個 agent 會做哪些事、服務的網址在哪裡、要怎麼連上它、需要哪種身分驗證。發起端只要去讀對方的 Agent Card，就能判斷「這個 agent 能不能幫我這個忙」，等於還沒開口就先交換過名片。
真正的工作則是靠 Task（任務） 來承載。每個 Task 都有一套明確的生命週期，會在幾個狀態之間流轉：剛提交（submitted）、處理中（working）、需要更多資訊（input-required）、完成（completed），或是失敗。這套狀態管理的好處，是連那種要跑很久、中途甚至需要人插手確認的工作，都能被清楚追蹤。你隨時查得到這件事現在卡在哪一關，而不是把需求丟出去就石沉大海。過程中，兩個 agent 靠 Message（訊息） 來回傳遞內容與指令，而一個 Task 最後產出的成果，則被稱為 Artifact（產出物）。
它底下的技術地基同樣值得看一眼。A2A 不是另起爐灶發明一套全新的通訊方式，而是直接架在既有的網路標準上：用 HTTP 當傳輸層、用 JSON-RPC 2.0 當訊息格式、用 Server-Sent Events（SSE）處理即時的狀態更新。這代表工程師手上熟悉的那套網路工具幾乎都能沿用，導入的門檻因此低了一大截。
A2A 跟 MCP 有什麼差異？兩者是互補，不是二選一
A2A 和 MCP 處理的，是不同層次的問題，它們不是在搶同一塊市場。
差別可以用一句話抓住。MCP 標準化的是「一個 agent 怎麼接工具、接資料、接各種資源」，方向是 agent 對工具（agent-to-tool）；A2A 標準化的則是「一個 agent 怎麼跟另一個 agent 對話、把任務交辦出去」，方向是 agent 對 agent（agent-to-agent）。一個往下接資源，一個往橫向連同儕，接的東西根本不一樣。
官方自己愛用一個比喻，拿來想像很清楚。MCP 像是給一位技師一把「標準規格的扳手」，有了統一規格，這位技師就能操作各式各樣的設備，不必每換一台機器就重學一套工具；而 A2A 則是讓「兩位技師之間可以互相對話、互相請對方幫忙」，好比一個負責電路、一個負責機械，遇到跨領域的工作，他們能直接開口協調，而不是各修各的。扳手解決的是「人怎麼用工具」，對話解決的是「人怎麼跟人合作」，兩件事顯然缺一不可。
實務上，這兩者也經常是疊在一起用的。想像一個 agent，它對內用 MCP 去接自己的資料庫、呼叫自己的 API，把該查的資料查齊、該算的算好；對外，它再用 A2A 跟其他 agent 溝通、把協調的結果交辦出去。同一個 agent 身上，一邊是 MCP 管它跟工具的關係，一邊是 A2A 管它跟別的 agent 的關係，兩條線各司其職、互不打架。
所以官方文件講得很直白，A2A 跟 MCP 是「高度互補」的，A2A 並不是要來取代 MCP。與其把它們想成二選一，不如說 A2A 幫 MCP 補上了它一直沒碰的那一塊。當每個 agent 都靠 MCP 把自己的工具接好之後，agent 跟 agent 之間該怎麼講話，就交給 A2A。
這種 Agent 協作，實際上能用在哪些場景？
協定講再多都還是抽象，落到具體情境才看得出它有沒有用。這裡不點名任何特定產品，只用幾個常見的商業畫面來想像。
先看客服跟財務的協作。假設一家做電商的中小企業，客服 agent 遇到一筆退款爭議，客人堅稱付了款卻沒收到訂單。在過去，客服人員得自己登入金流系統、翻交易紀錄、再切回訂單系統核對，兩邊複製貼上對半天。有了 A2A，客服 agent 可以直接跟財務系統那端的 agent 對話，請它確認這筆交易的紀錄與狀態，答案回來了再往下處理。人不用在兩套系統之間來回切換，agent 之間自己就把資訊對齊了。
再看人資的入職流程。一位新人報到，牽動的不只是人資一個部門：IT 要準備設備與帳號、行政要安排座位與門禁。這時入職 agent 可以透過 A2A，分別跟 IT 設備 agent、辦公室行政 agent 交辦各自該做的事，並且靠前面提到的 Task 生命週期，一路追蹤每一項辦到哪了、有沒有卡住。原本要靠一封封信、一個個口頭提醒串起來的跨部門流程，變成幾個 agent 之間可以直接協調追蹤的協作。
這兩個畫面真正的重點，其實不在情境本身有多炫，而在於這些跨系統、跨部門的串接，過去要嘛靠人工兩頭搬，要嘛得為每一組對接寫一套客製 API；現在有了一套共同協定，agent 之間可以直接對話，把那筆重複又難維護的客製整合成本壓下來。A2A 真正省下來的，是這些看不見的串接工，而不是多添一個花俏的功能。
A2A 現在發展到哪了？2026 年最新進展
不少人心裡會納悶，這協定聽起來很美，是不是還停在紙上談兵？回到目前看，它的進展其實比很多人想的實在。
最指標性的一步，是 2026 年 4 月，A2A 在推出滿一週年時，發布了 1.0 正式規格。這是它第一個穩定版本，代表協定本身已經定型到可以放心拿去建產品，而不再是隨時可能大改的實驗品。與此同時，支持它的組織數量，也從最初 2025 年 4 月的 50 多家，成長到超過 150 家。
落地的證據也具體了起來。微軟已經把 A2A 整合進 Azure AI Foundry 與 Copilot Studio，AWS 則透過 Amazon Bedrock AgentCore Runtime 提供支援。兩大雲端平台都把它接了進去，這對想導入的企業來說是很實際的信號，你未來要用的雲端服務，很可能原生就吃這套協定。開發資源這一面也擴張了，官方的 SDK 從最初只有 Python 一種實作，擴充到 Python、JavaScript、Java、Go、.NET 五種正式可用的語言，等於把不同技術棧的工程師都納了進來。
它治理上的走向也是一個關鍵轉折。A2A 由 Google 發起後捐給 Linux Foundation 這個中立基金會統籌，讓它不再是單一廠商說了算的東西，而是產業共同維護的開放標準。放大一點看，A2A 和 MCP 這兩套協定，如今被愈來愈多人視為同一套「多代理系統基礎建設」裡的上下兩層：一層管 agent 怎麼接工具，一層管 agent 怎麼互相講話，而不是各自為政、互相角力的兩個陣營。
AI agent 的世界，正在從「一個無所不能的超強模型」，慢慢走向「一堆各有專長的 agent 互相協作」。A2A 要做的，就是讓這些 agent 學會彼此對話的那套共同語言：MCP 顧的是 agent 跟工具的關係，A2A 顧的是 agent 跟 agent 的關係，兩者疊在一起，才拼得出一套完整的多代理協作基礎建設。往後在評估要不要導入某項 AI 時，除了照慣例問一句「這個工具能不能接上我的資料」，或許也可以開始多問一句：「這個 agent，能不能跟別的 agent 對話」。