01

總覽：三套協定、兩道邊界

MCP、A2A、ACP 常被混成「Agent 協定大雜燴」。本篇只做一件事：把它們放到同一張選型圖上，講清邊界與共存。

Model Context Protocol（MCP） 與 Agent-to-Agent Protocol（A2A） 已在 MCP 篇與 A2A 篇各自展開。實務訪談與架構討論裡，很快會冒出第三個名字：Agent Communication Protocol（ACP）——由 IBM Research／BeeAI 提出、同樣瞄準 Agent 之間互通。若你把三套協定都當成「能讓 Agent 說話的東西」，選型會立刻糊掉：到底該標準化工具插拔、跨團隊委派，還是整條編排管線？

正確切入點不是「哪一套比較新」，而是兩道邊界：

LAYER · TOOL BOUNDARY
MCP —— Agent／應用 ↔ 工具／資料
標準化 tools／resources／prompts 的發現與呼叫。單位是 tool call；不定義「把工作委派給另一個 Agent」。
LAYER · PEER BOUNDARY · 現行主流
A2A —— Agent ↔ Agent
標準化 Agent Card 發現、Task lifecycle、Message／Artifact。單位是可長跑的 Task；不規定對方內部用哪些工具。
LAYER · PEER BOUNDARY · 歷史路線 → 已併入 A2A
ACP —— Agent ↔ Agent／應用／人類（BeeAI 系）
同樣瞄準跨框架 Agent 互通，偏 REST／OpenAPI 風格與長任務狀態。2025-08 起正式與 A2A 在 Linux Foundation 下合併；新專案應以 A2A 為對等層標準。

記法：垂直方向是「接工具」（MCP）；水平方向是「對等委派」（A2A，含 ACP 貢獻）。兩層可同時出現在同一條業務流程。

視角本篇不重講單一協定細節

MCP 的 Host／Client／Server、A2A 的 Card／Task 狀態機，各自的專篇已寫過。這裡只保留選型需要的最小對照：各自解決什麼、訊息模型差在哪、何時該選哪一層、如何共存。ACP 則以「歷史定位＋合併後的實務含義」呈現——知道它是什麼、為何不再平行選型，比背另一套 API 更有價值。

陷阱不要把 ACP 當「比 A2A 更新的第三條路」

面試或架構評審若主張「我們改用 ACP 取代 A2A」，在 2025-08 合併宣告之後通常是過時資訊。正確敘事是：ACP 與 A2A 曾是同層競合；合併後資產與長任務／狀態化思維收斂進 A2A，BeeAI 生態提供遷移適配器。選型表上「對等層」應寫 A2A（含 ACP 貢獻），而不是並列三選一。

一句話答法MCP 管工具邊界；A2A 管 Agent 對等委派；ACP 曾是同層另一條開放路線，現已併入 A2A。選型先分「接工具還是委派 Agent」，再談共存——不是三套互斥的銀彈。
02

對照表：問題邊界、訊息模型、適用場景

把三套協定攤在同一張表上——比較「連誰、交換什麼、何時該用」，而不是比較誰的 JSON 欄位比較多。

MCP
Model Context Protocol · Anthropic 發起
把「模型怎麼發現並呼叫外部能力」標準化，讓工具生態可插拔。
  • 連線：Host／Client ↔ Server
  • 單位：tool／resource／prompt
  • 風格：JSON-RPC + stdio／HTTP+SSE
A2A
Agent-to-Agent · Google → LF
把「跨框架 Agent 如何發現彼此並委派長任務」標準化。
  • 連線：Client Agent ↔ Remote Agent
  • 單位：Task + Message + Artifact
  • 風格：Agent Card + JSON-RPC／串流
ACP
Agent Comm. Protocol · IBM／BeeAI → 併入 A2A
同樣解 Agent 互通，強調 REST 可觀測與長任務狀態；現為歷史路線＋遷移。
  • 連線：Agent ↔ Agent／App／Human
  • 單位：run／message（多模態）
  • 風格：REST／OpenAPI 取向
維度 MCP A2A ACP（歷史）
解決的痛 M 應用 × N 工具的客製爆炸 K Agent × K Agent 的委派契約爆炸 同層：跨框架／跨組織 Agent 溝通碎片化
邊界 工具／資料邊界 對等 Agent 邊界 對等 Agent（及應用／人類）邊界
訊息模型核心 tools.list／call、resources、prompts Agent Card、Task 狀態機、Parts／Artifact REST 資源、多模態 message、長任務 run
典型適用 接 DB、搜尋、票務 API、內部 gateway 跨團隊專責 Agent 委派、長任務追蹤 BeeAI 生態內互通；新專案應遷移 A2A
刻意不做 不定義 Agent↔Agent 委派語意 不規定內部用哪個 MCP tool 不取代 MCP；亦不應再與 A2A 平行選型
2026 實務狀態 工具層事實標準 對等層事實標準（含 ACP 貢獻） 停止平行演進；遷移至 A2A

表上最後一列最重要：面試時若被問「MCP vs A2A vs ACP」，先答邊界，再補一句「ACP 已併入 A2A」——顯示你跟得上治理現實，不是背三份規格書。

一句話答法MCP＝工具插拔；A2A＝Agent 委派與 Task 生命週期；ACP＝同層歷史路線（BeeAI／REST 取向），現已收斂進 A2A。比較時比「邊界與單位」，不要比誰比較潮。
03

ACP 的歷史定位與合併含義

為什麼會同時出現 A2A 與 ACP？合併之後，架構師還需要記什麼？

2025 上半年，Agent 互通突然變成熱門缺口：一邊是 Google 提出的 A2A（Agent Card + Task 狀態機），一邊是 IBM Research 為 BeeAI Platform 打造的 ACP（偏 REST／OpenAPI、強調多模態訊息與長任務可觀測）。兩者目標重疊——都想讓「不同框架做出來的 Agent」用共同契約協作——但哲學與表面形態不同：A2A 更像「對等 Agent 的發現＋任務協定」，ACP 更像「把 Agent 當成可 HTTP 呼叫的一等公民」。

面向ACP 當時強調併入 A2A 後怎麼理解
傳輸與發現 REST／OpenAPI 易被閘道與觀測堆疊吃進去 對等層能力以 A2A 規格為準；適配器處理舊 ACP 客戶端
長任務／狀態 run 級狀態、非同步與企業工作流親和 貢獻到 A2A 的 Task／狀態與企業場景思維
生態入口 BeeAI 平台的發現、執行、分享 BeeAI 改以 A2A 支撐；提供 A2AServer／A2AAgent 遷移路徑
治理 隨 BeeAI 進入 Linux Foundation 與 A2A 同在 LF AI & Data 傘下合併，避免雙標準撕裂生態
關鍵合併改變的是「選型表」，不是「要不要互通」

問題本身沒消失：跨團隊 Agent 仍需要標準委派契約。改變的是答案收斂成一條對等層標準（A2A）。若你維護既有 ACP 服務，優先計畫是遷移或加適配器，而不是再寫一套平行 gateway。新綠地專案：對等層直接選 A2A，工具層選 MCP。

陷阱「協定合併」≠「你可以省略安全與信任」

無論走 A2A 還是殘留 ACP 路徑，發現端點可被偽造、委派可被濫用。信任鏈（TLS、簽章 Card／允許清單、身份、授權）仍是你的責任——這與 MCP「協定 ≠ 安全機制」、以及 Tool Gateway 篇的邊界提醒同一條線。

一句話答法ACP 是 BeeAI 系的 Agent 互通協定，曾與 A2A 同層競合；2025-08 起併入 A2A。實務上對等層選 A2A，既有 ACP 走遷移／適配，不要再開第三條平行標準。
04

選型決策：何時用哪一層

面試與設計評審最值錢的不是背規格，而是一條可執行的決策階梯。

Q1
你是在接「工具／資料」，還是在委派「另一個 Agent」？
前者 → MCP（或內部 function call，若工具永遠私有且不需生態）。後者 → 對等層（A2A）。若對方只是自家服務裡的一個函式，通常連 A2A 都不必上。
Q2
對等方是否跨團隊、跨框架、跨供應商？
是 → 用 A2A 換「發現＋Task 狀態＋Artifact」的共同契約。否、且永遠在同一個 process 內 → 內部 API／訊息佇列即可，協定稅太貴。
Q3
對方是「歷史 ACP／BeeAI」資產嗎？
是 → 遷移或適配到 A2A（A2AServer／A2AAgent 等），不要在新邊界再發明 ACP dialect。否 → 直接 A2A，別為懷舊開雙棧。
Q4
同一條流程能否兩層共存？
能，而且常見：編排 Agent 用 A2A 委派專責 Agent；專責 Agent 內部再用 MCP 打工具。邊界清楚時，換掉內部工具不會弄破對外 Task 契約。

階梯給的是直覺，直覺在評審桌上撐不了三輪。下面這台引擎把同一組判準換成可量化的分數：你回答八個問題，它用 12 條加權規則同時替四種做法算分，列出每條規則對勝出者的貢獻，並在你的答案互相矛盾時直接點名。

互動 · 選層評分引擎 回答八題 → 四種做法同時計分
正向貢獻 負向貢獻 矛盾答案組合

看零軸兩側的長度差，不要只看誰贏：條子幾乎貼齊（margin 小）代表這個邊界本來就模棱兩可，該回頭改需求而不是硬選協定。

情境建議反模式
單一 Agent 呼叫內部 CRM API MCP server（或直接 SDK） 為了「看起來先進」硬包一層 A2A Task
客服 Agent 把爭議丟給帳務 Agent（不同團隊） A2A 委派 + 各自內部 MCP 在 A2A Message 裡塞滿對方的 MCP tool schema
既有 BeeAI／ACP Agent 要進公司網 適配器遷移到 A2A 同時維護 ACP gateway 與 A2A gateway 當永久架構
只想串本地腳本與檔案 MCP（stdio）通常就夠 上對等協定再加服務網格——協定稅大於收益

選型口訣：工具走 MCP，對等走 A2A，ACP 只當遷移項。

一句話答法先問「接工具還是委派 Agent」：工具→MCP；跨框架委派→A2A；遇到 ACP 遺產→遷移／適配。兩層常共存，但不要把 MCP payload 穿透塞進 A2A。
05

延伸：為你自己的流程逐 hop 標協定

單點選型會了，接下來看整條流程——層級切太碎、或工具呼叫穿越組織邊界，都是評審會當場抓住的地方。

把第 4 節那台選層評分引擎逐跳套用：你描述自己流程的每一跳「對端是什麼、落在哪個邊界」，它替每一跳算出該走的層、該付的協定稅，再彙總成三個整條流程才看得出來的指標——層級純度（切換越多越難維運）、正交破壞點（被標成 MCP 的工具呼叫卻跨組織）、以及可省下的協定稅（明明在同一個 process 卻硬上對等協定）。

互動 · 逐 hop 協定標註 改每一跳的屬性 → 標籤與稅即時重算
流程有幾跳 5
MCP 工具層 A2A 對等層 直接呼叫 正交破壞點

看每一列左緣的色條：同色連成一段就是同一層。標著「換層」的虛線越多，代表這條流程的邊界切得越碎——那通常不是架構精緻，而是抽象沒想清楚。

一句話答法整條流程的健康度看三件事：層級純度（別把邊界切碎）、正交破壞點（工具呼叫不該穿越組織邊界，該升成 A2A 委派）、協定稅（同 process 的跳別硬包 Task）。能把自己的流程逐跳標出來並解釋每一跳為什麼落在那一層，比背三份規格更像架構師。
06

共存架構與實務注意

兩層協定一起長在系統裡時，什麼該穿透、什麼絕對不該穿透？

健康的多 Agent 系統通常長這樣：外層是 A2A 對等網（誰能被發現、任務狀態怎麼回報），每個 Agent 內部是 MCP 工具扇出（資料庫、搜尋、票務、政策引擎）。中間再掛上你已有的 Tool Gateway、身份與觀測——協定負責語意契約，平台負責安全與運維。

做法為什麼好／壞
A2A 只傳業務意圖與產物 好：對方可自由替換內部 MCP tools，對外 Task 契約不變
MCP payload 穿透塞進 A2A Message 壞：兩層黏死；對方換 tool schema 就弄破委派契約
對等層同時永久跑 ACP + A2A 雙 gateway 壞：治理與觀測成本倍增；應遷移收斂
用適配器暫時吞舊 ACP 流量 好：給遷移窗口，但不把適配器當成最終產品邊界
把「編排狀態機」全部塞進協定 壞：協定管互通表示；重試、補償、人工審批仍屬 runtime／workflow
關鍵共存的單位是「邊界」，不是「把所有 JSON 揉在一起」

面試加分句：MCP 與 A2A 是正交的——一個管工具扇出，一個管對等委派。正交才能獨立演進；正交被破壞的第一個症狀，就是 Message 裡開始出現對方內部的 tool name。

一句話答法共存策略＝外 A2A、內 MCP、ACP 只做遷移；保持正交，禁止 MCP 細節穿透對等訊息，也不要把工作流引擎的責任推給協定。
07

面試考點與收束

把三套名字收成可秒答的判斷力——以及下一步該往哪裡學。

可能問法高分答法骨架
MCP、A2A、ACP 差在哪？ 先畫兩道邊界：工具 vs 對等。MCP＝前者；A2A＝後者現行標準；ACP＝同層歷史路線且已併入 A2A。
為什麼不全部用 MCP？ MCP 的單位是 tool call，不承載跨 Agent 的長任務狀態機、發現名片與 Artifact 交卷語意。
為什麼不全部用 A2A？ 對內部資料庫／搜尋用 A2A 等於把工具當 Agent，協定稅過高且喪失工具生態的插拔效率。
現在還要學 ACP 嗎？ 要懂定位與合併故事（選型與遷移）；新實作以 A2A＋MCP 為主，ACP 當遺產處理。

讀完本篇，你應能在白板上快速畫出「理賠／客服／研究」任一流程，並在每一跳旁邊標上 MCP 或 A2A——這比背欄位名更能通過 System Design 面試。若還要往下鑽：工具層回 MCP 篇、對等委派回 A2A 篇、權限與閘道回 Tool Gateway 篇。

一句話答法選型口訣：工具 MCP、對等 A2A、ACP 遷移項；同一流程可共存，但邊界必須正交。能畫出標註圖，就比背三份規格更像架構師。