AI Agent 協議說明：MCP、A2A、ACP 與 AG-UI 到底解決什麼問題

技术架构AI 與 Web 協議（更新於 2026年7月15日）

快速結論

MCP、A2A、ACP 和 AG-UI 不是彼此的直接替代品。它們解決的是 Agent 系統裡不同邊界的通訊問題。

協議 主要問題 典型邊界
MCP AI 應用如何連接工具、資料、prompt 和上下文 Agent/宿主應用 到 工具/資源伺服器
A2A 一個 Agent 如何把任務委派給另一個 Agent Agent 到 Agent 的任務協作
ACP Agent 如何以互操作服務形式暴露能力 Agent 服務互操作
AG-UI Agent 如何把狀態和動作串流傳給使用者介面 Agent 後端 到前端 UI

生產系統裡，更好的問題不是「哪個協議會贏」，而是「我們要標準化哪一層邊界」。

為什麼 Agent 需要協議？

早期 Agent 系統通常把工具呼叫、UI 事件和多 Agent 委派都硬編碼在一個應用裡。原型階段可以跑起來，但當工具、團隊、供應商和前端越來越多時，這種方式會變得脆弱。

協議的價值是拆分職責：

  • 工具和資料來源可以獨立暴露，不必重寫 Agent。
  • Agent 可以委派任務，而不暴露內部實作。
  • 前端可以一致地渲染進度、工具呼叫和中間狀態。
  • 安全團隊可以在清晰邊界上做權限和稽核。

MCP：工具與上下文整合

MCP，即 Model Context Protocol，關注 AI 應用如何連接外部工具和上下文。它採用 client/server 模型，宿主應用可以發現和呼叫工具、讀取資源、使用 prompt 模板。

適合使用 MCP 的場景：

  • AI 應用需要查詢資料庫、檔案系統、API、程式碼庫或業務系統。
  • 你希望工具伺服器能被多個 Agent 客戶端重用。
  • 你需要標準化暴露資源和 prompt。
  • 你希望工具 schema 和權限邊界明確。

MCP 最強的邊界是「Agent 呼叫工具」。它不是完整的多 Agent 編排協議，也不定義前端如何渲染 Agent 狀態。

AI 應用 / Agent 宿主
  -> MCP client
  -> MCP server
  -> 資料庫、檔案系統、API、內部工具

A2A：Agent 到 Agent 的任務協作

A2A，即 Agent-to-Agent，關注 Agent 之間如何協作。核心思路是 Agent 可以宣告能力，並接收另一個 Agent 或編排器發來的任務。

適合使用 A2A 的場景：

  • 多個專業 Agent 需要協作。
  • 規劃 Agent 需要把任務委派給專家 Agent。
  • Agent 由不同團隊或服務擁有。
  • 長任務需要狀態、產物和進度更新。

A2A 最強的邊界是「Agent 把任務委派給另一個 Agent」。它不替代 MCP；A2A Agent 內部仍然可以使用 MCP 呼叫工具。

編排 Agent
  -> A2A 任務請求
  -> 專家 Agent
  -> 狀態更新和產物

ACP：可互操作的 Agent 服務

ACP 通常被理解為 Agent Communication Protocol 一類方案，目標是讓 Agent 以服務形式被發現和呼叫。不同生態和實作可能不同，但設計目標類似：暴露 Agent 能力，讓其他系統以可預測方式呼叫。

適合 ACP 風格方案的場景：

  • 希望 Agent 像網路服務一樣被呼叫。
  • 能力發現很重要。
  • 不同執行環境或供應商需要互操作。
  • 你需要服務邊界，而不是程序內函式庫呼叫。

ACP 和 A2A 在概念上可能有重疊。實際選型時，要評估具體實作：訊息格式、認證、任務生命週期、串流能力、SDK 成熟度和治理方式。

AG-UI：Agent 到使用者介面的事件流

AG-UI 關注前端邊界。它標準化 Agent 後端如何把訊息、工具呼叫、狀態變化、進度和 UI 相關事件串流傳給客戶端。

適合使用 AG-UI 的場景：

  • 你正在構建 copilot 或 assistant UI。
  • 前端需要展示工具呼叫、中間步驟或即時進度。
  • 使用者需要在介面中審批動作。
  • Agent 狀態需要與 React、Vue 或其他 UI 框架同步。

AG-UI 最強的邊界是「Agent 後端與 UI 通訊」。它不定義 Agent 內部工作流，也不定義工具如何託管。

Agent 後端
  -> 事件流
  -> 前端 UI
  -> 使用者審批 / 輸入
  -> 後端恢復流程

它們如何組合？

這些協議通常是互補關係：

使用者介面
  <-> AG-UI 事件
Agent 應用 / 編排器
  <-> A2A 或 ACP 做 Agent 協作
專家 Agent
  <-> MCP 呼叫工具、資源和 prompt
業務系統

客服自動化系統可能用 AG-UI 展示進度並請求確認，用 A2A 把退款審核委派給財務 Agent，用 MCP 呼叫訂單、支付和工單工具。

開發助手可能用 AG-UI 處理編輯器事件，用 MCP 連接程式碼庫、終端、Issue 系統和文件，只有需要外部專家 Agent 時才使用 A2A 或 ACP。

對比矩陣

維度 MCP A2A ACP AG-UI
主要邊界 Agent 到工具/上下文 Agent 到 Agent Agent 服務互操作 Agent 到 UI
主要物件 Tool、Resource、Prompt Task、Message、Artifact Capability、Agent、Message Event、State、Tool action
最適合 工具整合 委派和協作 跨 Agent 服務契約 互動式前端
替代應用邏輯？ 否 否 否 否
能否組合使用 可以 可以 可以 可以
主要風險 工具權限過大 委派無邊界 實作分化或不成熟 UI 狀態/安全洩漏

選型建議

選擇 MCP，如果主要問題是讓 AI 應用連接工具或資料，並希望工具伺服器可重用、schema 明確。

選擇 A2A，如果一個 Agent 需要把任務委派給另一個 Agent，且任務狀態、進度和產物很重要。

選擇 ACP 風格方案，如果 Agent 需要作為服務端點暴露，能力發現和跨執行環境互操作是核心需求。

選擇 AG-UI，如果你正在構建互動式 Agent 前端，使用者需要看到進度、審批動作或查看中間步驟。

常見誤區

把協議當框架

協議定義通訊邊界，不替代編排、評測、安全、部署和產品設計。

簡單工具呼叫卻引入多 Agent 協議

如果 Agent 只需要查資料庫或呼叫 API，MCP 風格工具整合可能已經足夠。

暴露過大的工具能力

工具伺服器應提供窄操作。除非環境高度受控，不要暴露「執行任意 SQL」或「執行任意 shell 命令」。

不校驗 Agent 輸出

Agent 間通訊仍然需要校驗。返回產物應當作待檢查資料，而不是直接可信結果。

讓前端事件變成權限

前端審批事件只是互動信號，不是安全控制本身。權限必須由後端執行。

生產檢查表

領域 需要回答的問題
認證 誰可以呼叫協議端點？
授權 哪些工具、Agent、任務或 UI 動作被允許？
稽核 能否還原誰請求了什麼、發生了什麼？
逾時 Agent 或工具卡住時怎麼辦？
預算 模型呼叫、工具呼叫和任務深度是否有限制？
校驗 輸入輸出是否有 schema 檢查？
可觀測性 UI、Agent、工具和任務邊界的 trace 能否串起來？
版本管理 schema 變化時能否不破壞客戶端？

總結

MCP、A2A、ACP 和 AG-UI 更適合理解為邊界協議。MCP 標準化工具和上下文，A2A 標準化 Agent 任務協作，ACP 風格方案關注 Agent 服務互操作，AG-UI 標準化互動式前端事件。成熟的 Agent 系統可能同時使用多個協議，但每個協議都應該只在它能讓邊界更清晰、更安全時引入。

本站提供瀏覽器本地工具，免註冊即可試用 →

#MCP#A2A#ACP#AG-UI#AI Agent#协议#智能体