A2A 是什麼？Agent2Agent 協定運作方式、和 MCP 的差別與導入時機

舉個例子。一家做鋁合金外殼的工廠，業務收到一張詢價：5,000 件，三週內交貨。要回這張單，業務得先問生產排程排不排得進去，再問財務這個客戶的信用額度還剩多少。

這家工廠這一年陸續買了三套系統，每一套都附了自己的 AI agent：CRM 廠商的業務 agent、MES 廠商的排程 agent、ERP 廠商的財務 agent。三個 agent 都很能幹，但各做各的。業務 agent 想知道產能，還是得靠人打開 MES 問一次，再把答案貼回來。

A2A 要解決的就是這一段：讓業務 agent 直接把「這張單排得進去嗎」交給排程 agent，等它回報結果，中間不用人轉手。不過我先說結論：多數公司現在還用不到 A2A，後面會說明怎麼判斷。

A2A 是什麼：讓不同廠商的 agent 能互相委派工作

A2A 這個縮寫在其他領域也有別的意思，這篇講的是 AI 的 Agent2Agent 協定。官方的定義是：讓 AI agent 之間溝通與協作的開放標準，不同框架做出來的 agent，不必分享內部邏輯或工具，也能互相合作。

它的來歷可以用四個時間點記：

時間	事件
2025 年 4 月	Google 發表 A2A，發表時有 50 多家技術夥伴支持，包括 Salesforce、SAP、ServiceNow、Atlassian 等
2025 年 6 月	Google 把 A2A 交給 Linux Foundation，成為中立的開源專案；當時支持的公司已超過 100 家
2025 年 8 月	IBM 的 Agent Communication Protocol（ACP）併入 A2A，ACP 停止開發
2026 年 3 月	A2A 推出 1.0 版，官方稱為第一個穩定、可用於正式環境的版本

現在負責技術方向的指導委員會，成員來自 AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNow 八家公司。幾家大型軟體商都在同一張桌子上，這是 A2A 值得注意的原因：你公司用的 CRM、ERP、工作流程平台，未來內建的 agent 很可能都講這套語言。

A2A 把兩個 agent 分成委派的一方和接手的一方：

A2A client（委派方）：代表使用者發出請求的 agent 或應用程式。開頭例子裡的業務 agent 就是這個角色。
A2A server（接手方，也叫遠端 agent）：提供 HTTP 端點、接收任務並回報結果的 agent。例子裡的排程 agent。

規格特別強調，對委派方來說，遠端 agent 是一個「黑盒子」，它用什麼模型、接了哪些工具、記憶裡有什麼，都不會公開。業務 agent 只知道排程 agent 會排產能，看不到 MES 裡的資料表。這個設計讓不同公司的 agent 能合作，又不用把自己的系統打開給對方看。

A2A 和 MCP 差在哪：一個接工具，一個接同事

A2A 最常被拿來和 MCP 比。兩者都是讓 agent 和外界連接的協定，方向不同。

A2A 官方用「垂直」和「水平」來分：MCP 是垂直的，讓一個 agent 變得更深，每接一個 MCP server，它就多一個工具或一份資料可用；A2A 是水平的，讓 agent 跨出自己的邊界，去找另一個團隊、另一個部門，甚至另一家公司的 agent 合作。

用開頭的工廠來說：

排程 agent 要查 MES 裡的機台負荷，用 MCP 接 MES 的工具，這是 agent 在用自己的工具。
業務 agent 要問排程 agent「這張單排得進去嗎」，這是兩個 agent 之間交辦事情，走 A2A。

項目	MCP	A2A
連接的對象	agent 和工具、資料	agent 和 agent
對方是什麼	輸入輸出固定的功能，例如查詢、計算	會自己推理、規劃、用工具的 agent
互動方式	呼叫一次、拿回結果	可以來回多輪，任務可能跑很久
對方透明嗎	工具的參數和說明都攤開給 agent 看	對方內部不公開，只公開它能做什麼
開頭例子	排程 agent 查 MES 的機台負荷	業務 agent 請排程 agent 評估產能

兩者常一起用：A2A 串起 agent 和 agent，每個 agent 內部再用 MCP 接自己的工具。MCP 的架構和導入前的檢查，在 MCP 是什麼有完整說明，這裡不重複。

A2A 怎麼運作：名片、任務單、交付物

A2A 的核心概念不多，拿公司之間的委外來想最好懂：先看對方的名片，再開一張任務單，最後收交付物。

Agent Card：agent 的名片

Agent Card 是一份 JSON 文件，寫著這個 agent 叫什麼、能做哪些事（官方稱為 skills）、服務網址在哪裡、要用什麼方式驗證身分。委派方先讀名片，判斷這個 agent 適不適合這件工作，以及該怎麼跟它溝通。

名片通常放在固定的位置，也就是網域底下的 /.well-known/agent-card.json，其他 agent 照這個慣例就找得到。只想給特定對象看的內容，可以放在要驗證身分後才能讀的延伸版名片裡。1.0 版另外加入了名片簽章，接收方可以驗證這張名片確實出自對方，而不是有人冒名放上去的。

Task、Message、Artifact：任務單、對話、交付物

Message（訊息）：一來一往的對話，例如「你們接不接急單？」這種不需要追蹤的簡單問答，對方直接回一則訊息就結束。
Task（任務）：需要時間處理、要追蹤進度的工作，有自己的編號和狀態。任務可能停在「需要補資料」或「需要授權」等對方回應，最後以完成、取消、拒絕或失敗其中一種狀態結束。結束的任務不會重開，要修改就開一張新任務。
Artifact（交付物）：任務做出來的具體成果，例如一份產能評估、一張圖或一段結構化資料。
Part（內容片段）：訊息和交付物裡實際裝的東西，可以是文字、檔案或結構化資料。

桌上三個木托盤排成一列，各放不同的工具，托盤之間用黃銅夾沿著細線傳遞一張空白卡片

套回詢價單，一次完整的委派大概是這樣：

步驟	發生什麼事	對應的 A2A 概念
1	業務 agent 讀排程 agent 的名片，確認它有「評估產能」這項能力	Agent Card、skills
2	業務 agent 送出「5,000 件、三週交期，排得進去嗎」	Message，排程 agent 回應時開立 Task
3	排程 agent 發現圖面沒寫表面處理，回頭詢問	Task 狀態停在需要補資料
4	業務 agent 補上「陽極處理」，排程 agent 繼續評估	同一個 Task 繼續進行
5	排程 agent 交回產能評估：第三週可交 3,000 件，其餘順延一週	Artifact，Task 完成

進度怎麼回報，A2A 給了三種方式：委派方定期來問（polling）、保持連線即時推送（streaming），或任務有進展時由接手方呼叫委派方提供的網址通知（push notification）。跑好幾個小時、甚至要等人確認好幾天的任務，通常用最後一種。

技術上，A2A 走的是一般的 HTTPS，1.0 版支援 JSON-RPC、gRPC 與 HTTP＋JSON 三種傳輸格式。公司原本的 API 閘道、監控、身分驗證工具，大多能直接沿用。

同一個流程的兩種做法：一個 agent 加工具，或多個 agent 分工

回到詢價單。同一件事，其實有兩種做法。

做法一：只做一個業務 agent，用 MCP 接上 MES 和 ERP 的查詢工具，自己查產能、自己查信用額度。

做法二：業務、排程、財務各有自己的 agent，業務 agent 透過 A2A 把問題分別交給另外兩個。

比較項目	一個 agent＋MCP 工具	多個 agent 透過 A2A 分工
誰負責整件事	一個 agent、一個負責人	每個 agent 各有負責的部門，主責的是發起的業務 agent
權限放在哪	集中在這個 agent：它能查 MES、ERP 的哪些資料，一張表寫清楚	分散在各 agent：業務 agent 看不到 MES 資料表，只拿得到排程 agent 願意給的結論
出錯時怎麼追	看一份操作紀錄：它呼叫了哪個工具、帶了什麼參數	要把好幾個 agent 的紀錄串起來看，靠任務編號與追蹤代碼對應
要維護什麼	一個 agent 的提示詞、工具與測試案例	每個 agent 各自的設定，加上彼此的名片、驗證與版本相容
誰來做	一個團隊就能完成	每個 agent 背後都要有人維護；常常是不同廠商
適合	系統都在公司內、同一個團隊能管的流程	agent 分屬不同廠商或部門，彼此不能、也不該看到對方內部

表上看得出來，多 agent 的做法把權限切得比較乾淨：財務的信用額度只由財務 agent 判斷，業務 agent 拿到的是「可以接」或「需要主管核准」，看不到客戶完整的帳款紀錄。代價是多了好幾個要維護、要驗收的東西，出事時也要多花力氣把前後串起來。

各家官方的建議很一致。OpenAI 建置 agent 的指南建議先把單一 agent 的能力用到極限，工具多到讓模型頻繁選錯、指示複雜到寫不下去，才拆成多個 agent。Microsoft 在 Copilot Studio 的多 agent 指引也寫：從一個 agent 開始，確實需要模組化，或出現一個 agent 不該跨過的邊界時，才拆開。

如果你的系統都在公司內、同一個團隊管得動，先做一個 agent 加 MCP 工具就好。開頭那家工廠，如果 MES 和 ERP 都能提供查詢介面，我會建議先做做法一，把權限表和測試案例顧好，等真的遇到拆不開的邊界再談 A2A。

什麼情況才需要 A2A

參考 Microsoft 對「什麼時候該拆出獨立 agent」的判斷，再加上 A2A 本身的用途，我整理成四個情況。符合其中一項，A2A 才開始值得評估：

agent 來自不同廠商，而且你改不了它的內部。例如 CRM 內建的業務 agent 要和 ERP 廠商的財務 agent 合作。你拿不到對方的程式，只能透過標準協定交辦工作。
某段工作需要獨立的權限或治理規則。財務的信用判斷不該讓其他 agent 直接碰到資料，只交回結論。
同一個 agent 要服務很多地方。例如一個「報價計算 agent」同時給業務、客服、經銷商入口用，做成可以被委派的服務，比每處各寫一份好維護。
要和公司外面的 agent 往來。客戶的採購 agent 來問你的報價 agent 交期，或你的 agent 要向供應商的 agent 訂料。跨公司的往來最需要共同的規格。

第四種目前還在很早的階段，但方向很清楚。A2A 官方的例子就是一間汽車修理廠：客戶的助理 agent 找修理廠的經理 agent 描述問題，技師 agent 用 MCP 操作診斷工具，缺零件時再用 A2A 向供應商的 agent 下單。

常聽到的多 agent（multi-agent）系統，不一定要用 A2A。同一個平台裡的多個 agent，平台通常有自己的分工機制，例如 OpenAI Agents SDK 的交接（handoff）、Copilot Studio 的子 agent。A2A 的價值在跨平台、跨組織；全部都在同一個平台裡，用平台內建的方式就夠。

哪些平台已經支援 A2A

下面是目前官方文件寫到的情況，這部分變化很快。

平台	支援方式	文件裡特別提醒的事
Microsoft Copilot Studio	在 agent 裡加入 A2A agent，填入對方的服務網址；有標準位置的名片時會自動帶入名稱與說明	驗證方式可選無、API key 或 OAuth 2.0；連接外部 agent 時，資料流向、權限與人工監督由使用者自行負責
Google（ADK、Agent Engine）	官方 codelab 示範用 ADK 做委派方，呼叫部署在 Cloud Run 上、用不同框架做的 agent	教學用例子，正式環境仍要自行設計驗證
Salesforce、SAP、ServiceNow	Linux Foundation 成立 A2A 專案時公開表態參與；Salesforce 提到要讓 Agentforce 透過 A2A 協調其他系統的 agent	實際開放範圍以各家產品文件為準

換句話說，你不一定要自己寫 A2A。比較可能的情況是：你正在用的平台開始支援它，某天在設定頁看到「加入 A2A agent」的選項。那時候要做的判斷，就是前一節的四個情況，加上下一節的安全檢查。平台怎麼選，可以看企業 AI agent 自建、平台或委外。

跨組織委派的安全：對方的 agent 要當外人看

A2A 讓 agent 能把工作交給別人，也代表別人的 agent 能影響你的流程。規格在身分驗證上沿用一般的網路標準，其他部分仍要自己把關。

身分：確認對方是誰。 A2A 本身的訊息內容不帶身分資訊，驗證放在 HTTP 這一層，用 OAuth 2.0、OpenID Connect 或 API key。對方需要什麼驗證方式，寫在它的名片上；每一個請求都要驗證。跨公司往來時，名片簽章可以多一層確認。

權限：只開這件事需要的範圍。 規格要求遠端 agent 依呼叫者的身分決定能做什麼，可以細到每一項 skill 分別授權。Microsoft 在 Copilot Studio 的指引提醒一個容易漏掉的狀況：被委派的 agent 可能擁有委派方沒有的權限。假設主 agent 不能刪資料，被委派的 agent 卻可以，主 agent 就不該在沒有核准的情況下把可能刪資料的工作交出去。委派一次，要當成一次高權限動作來看。

內容：對方交回來的東西，當成外部輸入。 遠端 agent 交回的訊息和交付物，對你的 agent 來說就是別人寫的內容，裡面可能夾帶想改變你 agent 行為的指令。這類攻擊叫 prompt injection，防護的順序在 Prompt Injection 是什麼整理過。接外部 agent 之前，先確認它交回的內容不會直接觸發寄信、付款這類動作，中間要經過規則檢查或人工確認。

紀錄：要串得起來。 一件事經過三個 agent，出錯時要能從頭追到尾。規格建議用分散式追蹤（例如 OpenTelemetry）把追蹤代碼帶在請求裡，並記錄任務編號與狀態變化。權限怎麼分級、哪些動作要停下來給人確認，可以對照 AI agent 的權限與人工確認怎麼設。

我們能協助的部分

我們的企業 AI 營運方案會派工程團隊到現場，從需求診斷開始梳理作業細節，打通既有軟體、資料庫與 API，在真實業務中驗證後上線，之後持續維護與調整。權限管理與人機審核會一起設計，關鍵環節由真人確認後放行。

像開頭那張詢價單，要先用一個 agent 接工具，還是讓不同系統的 agent 分工，會在需求診斷時依系統現況和權限邊界一起判斷。

常見問題

公司目前只有一個 AI agent，需要支援 A2A 嗎？

暫時不需要。A2A 處理的是 agent 和 agent 之間的交辦，只有一個 agent 時沒有對象可以委派。先把這個 agent 的工具、權限和驗收做好；之後要接其他廠商的 agent，或要讓外部 agent 呼叫你的服務，再評估 A2A。

A2A 和 n8n、Zapier 這類自動化流程差在哪？

自動化流程是事先畫好的路徑，每一步做什麼都寫死；A2A 交出去的是一件「任務」，接手的 agent 自己決定怎麼完成，過程中還可能回頭追問。步驟固定的串接用自動化流程就好，需要對方判斷、而且對方是別人維護的 agent，才用得上 A2A。兩者的差別也可以參考 AI agent 和聊天機器人、RPA、自動化流程差在哪。

把工作委派給外部廠商的 agent，資料會被對方拿去用嗎？

A2A 只規定 agent 之間怎麼溝通，資料送出去之後怎麼保存、會不會被拿去做別的用途，要看你和對方的合約與隱私條款。規格建議只傳這件工作需要的資料。我建議在串接前把「會送出哪些欄位、對方保存多久」寫進合約附件。

Agent Card 放在公開網址，會不會洩漏公司資訊？

名片寫什麼由你決定。公開版只寫對外提供的能力和驗證方式；內部流程、更細的能力清單，可以放在要驗證身分後才讀得到的延伸版名片。上線前把名片當成對外文件審一次，確認裡面沒有內部系統名稱或不該公開的網址。

參考來源

以下依官方文件整理，規格版本與各平台支援範圍以官方頁面當下為準。

A2A 是什麼？AI agent 之間怎麼互相委派工作，和 MCP 差在哪