A2A 與 MCP 協議整合指南：AI Agent 互通架構

一、AI Agent 互通的核心挑戰：為什麼需要標準化協議

2025 年至 2026 年，Agentic AI 已從概念驗證階段進入企業級部署。Gartner 預測，到 2028 年全球將有超過 33% 的企業軟體交互透過 AI Agent 完成^[4]。然而，隨著企業部署的 agent 數量從個位數增長到數十甚至數百個，一個根本性的挑戰浮現：這些 agent 彼此之間無法高效溝通，也缺乏統一的方式連接外部工具與資料源。

McKinsey 的全球調查顯示，超過 72% 的企業 AI 專案在整合階段遭遇瓶頸^[9]。這並非因為單一 agent 的能力不足，而是因為每個 agent 使用不同的框架、不同的通訊格式、不同的工具接入方式。當一個用 LangGraph 建構的客服 agent 需要向一個用 CrewAI 建構的分析 agent 請求報告時，工程師必須撰寫大量的膠水代碼來橋接兩者——這正是碎片化的代價。

1.1 兩層碎片化：水平通訊與垂直連接

深入分析後，我們可以將 agent 系統的碎片化問題分為兩個層面：

水平碎片化（Agent-to-Agent）：不同 agent 之間缺乏標準化的通訊協議。A 團隊的 agent 使用 REST API，B 團隊的 agent 使用 gRPC，C 團隊的 agent 使用自定義的 WebSocket 協議。每一對 agent 的對接都需要客製化的適配層，形成 N×N 的整合複雜度。

垂直碎片化（Agent-to-Tool）：每個 agent 連接外部工具（資料庫、API、檔案系統）的方式各不相同。即使兩個 agent 都需要查詢同一個 CRM 系統，它們可能使用完全不同的接入邏輯——一個直接呼叫 REST API，另一個透過 SDK 封裝，第三個則透過 SQL 直連。

Agent 系統碎片化示意：

水平碎片化（Agent 間通訊）：
  Agent A ───[自定義 REST]──→ Agent B
  Agent A ───[gRPC 適配]────→ Agent C
  Agent B ───[WebSocket]────→ Agent C
  （每對 agent 需獨立適配）

垂直碎片化（Agent 與工具連接）：
  Agent A ──→ CRM（REST API v1）
  Agent B ──→ CRM（SDK 封裝）
  Agent C ──→ CRM（SQL 直連）
  （同一工具，三種接入方式）

Google 的 A2A 協議^[1]與 Anthropic 的 MCP 協議^[2]分別從這兩個層面切入，提出了標準化的解決方案。理解這兩個協議的定位差異與互補關係，是設計企業級 multi-agent 系統的基礎。

1.2 為什麼不能用一個協議解決所有問題

業界常見的一個誤解是：A2A 和 MCP 是競爭關係，最終只會有一個「贏家」。事實恰恰相反——它們解決的是不同維度的問題，正如 TCP/IP 解決網路傳輸而 HTTP 解決應用層通訊，兩者不僅不衝突，而且缺一不可。

Agent 與工具的交互（垂直連接）具有強結構化特徵：輸入參數有明確的 schema、回傳值有固定格式、操作是原子性的。這正是 MCP 擅長的領域。而 Agent 之間的通訊（水平連接）則更接近人類協作：需要協商任務分配、同步進度狀態、處理長時間運行的非同步任務、甚至串流中間結果。這些需求超出了 MCP 的設計範疇，正是 A2A 的核心能力。

二、A2A 協議深度剖析：Agent 間的通用語言

Google 於 2025 年 4 月公開發布 A2A（Agent-to-Agent）協議^[1]，並迅速獲得超過 50 家科技企業的支持，包括 Atlassian、Box、Cohere、Intuit、MongoDB、PayPal、Salesforce 與 SAP。A2A 的設計目標明確：為異質 agent 系統建立一個通用的通訊標準，使不同框架、不同廠商建構的 agent 能夠無縫協作。

2.1 核心概念：Agent Card、Task 與 Message

A2A 的架構圍繞三個核心概念展開：

Agent Card（代理名片）：每個 agent 以 JSON 格式發布一張「名片」，描述自身的能力、支援的輸入/輸出格式、認證需求與服務端點。Agent Card 類似於微服務架構中的服務發現機制——當一個 agent 需要協助時，它可以查詢已註冊的 Agent Card 來找到適合的合作者。

Task（任務）：A2A 中的核心工作單位。一個 Task 代表一個 agent 委派給另一個 agent 的工作項目，具有明確的生命週期（submitted → working → input-required → completed / failed / canceled）。Task 設計支援長時間運行：agent 可以在數秒、數分鐘甚至數天的時間跨度內逐步完成任務，期間透過狀態更新保持與委派方的同步。

Message（訊息）：agent 之間交換資訊的載體。每則 Message 包含一或多個 Part（文字、檔案、結構化資料），支援多模態內容。Message 的設計讓 agent 可以像人類同事一樣進行多輪對話——提出問題、要求澄清、提供中間結果、回報最終產出。

A2A 協議核心架構：

┌─────────────────────────────────────────────┐
│                 Agent Card                   │
│  ┌─────────────────────────────────────────┐│
│  │ name: "market-research-agent"           ││
│  │ description: "市場分析與競品研究"         ││
│  │ capabilities: [research, report, chart] ││
│  │ endpoint: "https://agent.example/a2a"   ││
│  │ auth: {scheme: "bearer", ...}           ││
│  └─────────────────────────────────────────┘│
└─────────────────────────────────────────────┘

Client Agent                    Remote Agent
     │                               │
     │──── POST /tasks/send ────────→│  建立 Task
     │                               │
     │←── status: "working" ─────────│  回報進度
     │                               │
     │←── status: "input-required" ──│  需要額外資訊
     │──── 提供補充資料 ────────────→│
     │                               │
     │←── SSE: artifact (串流) ──────│  串流中間結果
     │                               │
     │←── status: "completed" ───────│  任務完成
     │    + final artifacts           │
     └───────────────────────────────┘

2.2 傳輸層設計：HTTP + JSON-RPC + SSE

A2A 的傳輸層基於三個成熟的 Web 標準組合。底層通訊採用 HTTP/HTTPS，確保企業防火牆友好與廣泛的基礎設施相容性。訊息格式遵循 JSON-RPC 2.0 規範，提供結構化的請求-回應模式。對於長時間運行的任務與串流中間結果，A2A 使用 Server-Sent Events（SSE），讓 remote agent 能夠即時推送狀態更新與階段性產出。

這個技術選擇的精妙之處在於：它完全依賴既有的 Web 基礎設施，不需要額外的消息佇列或專用傳輸層。任何能發送 HTTP 請求的環境——無論是雲端服務、本地部署還是邊緣設備——都能作為 A2A 的參與者。

2.3 五大設計原則

A2A 的官方文件^[1]明確揭示了五項設計原則，這些原則直接反映了其與 MCP 的定位差異：

• Agentic（代理原生）：A2A 為 agent 之間的協作而生——不是工具呼叫，不是函式執行，而是具備自主決策能力的 agent 之間的對等通訊
• Built on existing standards（基於現有標準）：不發明新的傳輸協議，而是組合 HTTP、JSON-RPC、SSE 等成熟技術
• Secure by default（預設安全）：支援 OAuth 2.0、API Key 等企業級認證機制，Agent Card 可聲明所需的認證方式
• Support for long-running tasks（支援長時間任務）：任務不限於同步的請求-回應，可跨越數分鐘到數天
• Modality agnostic（模態無關）：支援文字、圖像、音訊、影片與結構化資料的多模態交換

三、MCP 協議在 Agent 互通架構中的角色

如果說 A2A 是 agent 世界的「外交協議」，那麼 MCP 就是每個 agent 的「工具箱標準」。Anthropic 在 2024 年底開源的 Model Context Protocol^[2]，其核心使命是標準化 AI 模型（及其衍生的 agent）與外部工具、資料源之間的連接方式。

3.1 MCP 的三層架構回顧

MCP 採用 Host → Client → Server 的三層架構：

• Host（宿主）：AI 應用本身，如 Claude Desktop、Cursor、Windsurf 或企業自建的 agent 系統
• Client（客戶端）：協議層，負責與 MCP Server 建立連線、管理會話、處理安全授權
• Server（伺服端）：工具與資料的提供者。每個 Server 可暴露三類能力——Tools（可執行操作）、Resources（可讀取資料）、Prompts（可複用提示模板）

關鍵的設計差異在於：MCP 連接的對象是工具與資料，而非另一個具備決策能力的 agent。當你的 agent 需要查詢資料庫、讀取檔案、呼叫第三方 API 時，它透過 MCP 來做。但當你的 agent 需要委派一個子任務給另一個 agent、需要與另一個 agent 協商策略、或需要接收另一個 agent 的串流分析報告時，這些場景超出了 MCP 的設計範疇——這正是 A2A 的用武之地。

3.2 A2A vs MCP：定位差異全景對照

四、A2A + MCP 整合架構：從理論到實踐

理解了兩個協議的定位差異後，接下來的關鍵問題是：在實際的企業 multi-agent 系統中，A2A 和 MCP 如何協同運作？以下我們以一個完整的架構設計來說明。

4.1 參考架構：企業級 Multi-Agent 系統

企業 Multi-Agent 系統整合架構：

┌─────────────────────────────────────────────────────────────┐
│                    使用者介面 / API Gateway                    │
└──────────────────────────┬──────────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────────┐
│                  Orchestrator Agent（調度中心）                │
│               ┌─────────────────────────┐                    │
│               │  A2A Client（委派任務）  │                    │
│               └────┬───────────┬────────┘                    │
│                    │           │                              │
│  ┌─ MCP Client ──┐│           │┌── MCP Client ──┐           │
│  │ 知識庫 Server  ││           ││ CRM Server     │           │
│  │ 日誌 Server    ││           ││ 權限 Server    │           │
│  └────────────────┘│           │└────────────────┘           │
└────────────────────┼───────────┼─────────────────────────────┘
           A2A 協議  │           │  A2A 協議
┌────────────────────▼──┐  ┌────▼─────────────────────────────┐
│   Research Agent       │  │   Report Agent                    │
│  ┌── MCP Client ──┐   │  │  ┌── MCP Client ──┐              │
│  │ Web Search Srv  │   │  │  │ Chart Gen Srv   │              │
│  │ News API Srv    │   │  │  │ Template Srv    │              │
│  │ DB Query Srv    │   │  │  │ PDF Export Srv  │              │
│  └─────────────────┘   │  │  └─────────────────┘              │
└─────────────────────────┘  └──────────────────────────────────┘
           A2A 協議                      A2A 協議
                │                              │
┌───────────────▼──────────────────────────────▼───────────────┐
│                    Review Agent                                │
│  ┌── MCP Client ──┐                                          │
│  │ Compliance Srv  │  ← 合規檢查工具                          │
│  │ Email Srv       │  ← 通知寄送工具                          │
│  └─────────────────┘                                          │
└──────────────────────────────────────────────────────────────┘

在這個架構中，每個 agent 是一個獨立的服務，具備以下雙重能力：

• 向下：透過 MCP 連接所需的工具與資料源。Research Agent 透過 MCP 存取搜尋引擎、新聞 API、資料庫；Report Agent 透過 MCP 存取圖表生成器、模板引擎、PDF 匯出工具
• 向外：透過 A2A 與其他 agent 通訊。Orchestrator 透過 A2A 將「市場調研」任務委派給 Research Agent，將「報告生成」任務委派給 Report Agent，最終將「合規審查」任務委派給 Review Agent

4.2 任務流轉實例：從使用者請求到多 Agent 協作

以「產出一份台灣半導體市場分析報告」為例，完整的任務流轉如下：

步驟 1 — 使用者發起請求：使用者透過企業入口介面輸入需求。Orchestrator Agent 接收請求，進行意圖解析與任務分解。

步驟 2 — A2A 任務委派：Orchestrator 查詢已註冊的 Agent Card，找到 Research Agent（具備市場調研能力）和 Report Agent（具備報告生成能力）。透過 A2A 的 tasks/send 端點，向 Research Agent 發送調研任務。

步驟 3 — MCP 工具呼叫：Research Agent 收到任務後，透過 MCP 呼叫 Web Search Server 搜尋最新市場資料，呼叫 DB Query Server 查詢內部歷史數據，呼叫 News API Server 取得產業新聞。所有工具交互遵循 MCP 的標準化介面。

步驟 4 — A2A 串流回報：Research Agent 透過 A2A 的 SSE 通道，即時串流分析進度與中間結果給 Orchestrator。如需額外資訊，Research Agent 可將 Task 狀態設為 input-required，請求 Orchestrator 提供補充指示。

步驟 5 — 任務銜接：Research Agent 完成調研後，Orchestrator 透過 A2A 將調研結果作為輸入，發送報告生成任務給 Report Agent。Report Agent 透過 MCP 呼叫圖表生成工具、模板引擎與 PDF 匯出工具，產出最終報告。

步驟 6 — 合規審查：報告產出後，Orchestrator 將其委派給 Review Agent。Review Agent 透過 MCP 呼叫合規檢查工具掃描報告內容，確認無敏感資訊外洩風險後，透過 A2A 回報審查通過，並透過 MCP 的 Email Server 通知使用者報告已就緒。

4.3 協議邊界的實務判斷原則

在架構設計中，一個常見的實務問題是：「這個交互場景該用 A2A 還是 MCP？」以下是我們在多個企業專案中驗證的判斷原則：

五、與主流 Agent 框架的整合實務

A2A 和 MCP 是協議層標準，而 LangChain / LangGraph、CrewAI、AutoGen（AG2）則是開發框架。協議與框架的關係是「介面規範」與「實作引擎」的關係——框架需要實作協議才能參與互通生態。截至 2026 年初，三大框架對兩個協議的整合進度如下^[7][8]：

5.1 框架整合狀態總覽

5.2 LangGraph + A2A + MCP 整合範例

以下是一個將 LangGraph agent 同時接入 MCP（工具連接）與 A2A（agent 通訊）的概念架構：

# LangGraph Agent 整合 A2A + MCP 的概念架構

# 1. MCP 層：連接工具與資料源
MCP_SERVERS = {
  "database": MCPClient("stdio", "npx @mcp/postgres-server"),
  "search":   MCPClient("stdio", "npx @mcp/web-search-server"),
  "email":    MCPClient("http",  "https://mcp.internal/email"),
}

# 2. 將 MCP 工具轉為 LangChain Tool
tools = []
for name, client in MCP_SERVERS.items():
  mcp_tools = client.list_tools()      # MCP tools/list
  tools.extend(convert_to_langchain(mcp_tools))

# 3. 建構 LangGraph Agent
graph = StateGraph(AgentState)
graph.add_node("agent",    create_react_agent(llm, tools))
graph.add_node("tools",    ToolNode(tools))
graph.add_edge("agent",    "tools")
graph.add_edge("tools",    "agent")
agent = graph.compile()

# 4. A2A 層：將 LangGraph agent 暴露為 A2A 端點
a2a_server = A2AServer(
  agent_card=AgentCard(
    name="data-analyst",
    description="資料分析與報告生成",
    capabilities=["sql_query", "data_viz", "report"],
    endpoint="https://agent.company.com/a2a/data-analyst"
  ),
  task_handler=lambda task: agent.invoke(task.message)
)
a2a_server.start()  # 啟動 A2A HTTP Server

這個架構的關鍵在於分層清晰：LangGraph 作為 agent 的推理引擎，MCP 作為工具接入層，A2A 作為對外通訊層。三者各司其職，不存在職責重疊。

5.3 CrewAI 的多角色 Agent 與 A2A 整合

CrewAI 以角色扮演（role-playing）為核心設計理念^[8]，每個 agent 被賦予特定角色、目標與背景故事。CrewAI 內部的 agent 協作已有完善的機制（Crew 內部通訊），而 A2A 的價值在於讓不同 Crew 之間——甚至不同組織的 Crew 之間——也能標準化地通訊。

具體的整合模式是：將整個 Crew（而非單個 agent）包裝為一個 A2A 端點。外部的 A2A Client 看到的是一個「研究團隊 agent」，而非團隊內部的個別角色。這符合「封裝」原則——外部不需要知道 Crew 內部有幾個 agent、如何分工，只需要知道這個團隊的能力邊界與通訊介面。

5.4 AutoGen（AG2）的對話驅動模型

Microsoft 的 AutoGen^[7]（現更名為 AG2）在設計哲學上與 A2A 最為契合，因為兩者都以「agent 之間的對話」作為核心運作模式。AG2 的 ConversableAgent 本質上就是一個能與其他 agent 進行多輪對話的實體，這與 A2A 的 Task + Message 模型高度對齊。

AG2 在 v0.4 版本中原生支援 A2A Server 模式，可將任何 AG2 agent 或 agent group 直接暴露為 A2A 端點。MCP 的整合則透過社群開發的 adapter 進行，將 MCP Server 的工具映射為 AG2 的 FunctionTool。

六、Linux Foundation 標準化與產業趨勢

2025 年底，A2A 和 MCP 相繼加入 Linux Foundation 的開放標準治理體系^[3]。這是一個歷史性的里程碑——它意味著這兩個協議不再由單一公司主導演進，而是由整個產業共同塑造。

6.1 標準化治理架構

Linux Foundation 為 AI Agent 協議建立了專門的工作組，其治理架構包括：

• 技術指導委員會（TSC）：由 Google、Anthropic、Microsoft、Salesforce、SAP 等核心成員組成，負責協議的技術方向與版本規劃
• 互通工作組（Interop WG）：專注於 A2A 與 MCP 之間的銜接規範，確保兩個協議在實際部署中能無縫整合
• 安全工作組（Security WG）：制定 agent 通訊的安全最佳實踐，包括認證、授權、審計與資料隱私
• 合規工作組（Compliance WG）：與各國法規接軌（包括歐盟 AI Act、美國 NIST AI 標準^[6]），確保協議設計符合監管要求

6.2 預計時程與演進路線

根據 Linux Foundation 公開的路線圖^[3]，以下是關鍵的標準化時程：

• 2026 Q1：A2A v1.0 穩定版發布，MCP v2.0 增加 Streamable HTTP 傳輸與 OAuth 2.1 認證
• 2026 Q2：互通規範草案公開，定義 A2A-MCP 聯合使用的參考架構與最佳實踐
• 2026 Q3：首個聯合互通規範（Joint Interop Spec v1.0）正式發布，附帶參考實作與合規測試套件
• 2026 Q4：啟動認證計畫，廠商可提交產品進行互通合規認證

6.3 NIST AI Agent 標準化動態

在美國，NIST 同步推進 AI Agent 的安全與互通標準^[6]。NIST 的關注重點在於：agent 之間通訊的可審計性（auditability）、任務委派的授權鏈（delegation chain）、以及 agent 決策的可解釋性。這些要求將直接影響 A2A 協議的安全機制設計——例如，未來版本的 A2A 可能要求每個 Task 攜帶完整的授權鏈證書，記錄「誰授權了誰去做什麼」。

七、台灣企業導入 Agent 互通協議的實務路徑

對於多數台灣企業而言，Agent 互通協議的導入不是一個「要不要」的問題，而是「何時」與「如何」的問題。根據 Google Cloud 的 2026 年 AI Agent 趨勢報告^[5]，亞太地區的企業 AI Agent 部署量在 2025 年增長了 340%，其中台灣的增長率達到 280%——雖然尚未領先，但已明確進入加速軌道。

7.1 建議導入策略：MCP 先行、A2A 漸進

我們根據過去一年協助多家台灣企業部署 AI Agent 系統的經驗，建議以下三階段路徑：

第一階段：MCP 基礎建設（1-3 個月）

• 盤點企業內部現有的工具與資料源（CRM、ERP、知識庫、資料庫等）
• 為核心系統建構 MCP Server，標準化工具的接入介面
• 部署 1-2 個使用 MCP 的 AI Agent，驗證工具連接的穩定性與效能
• 建立內部的 MCP Server 開發與維運規範

第二階段：內部 A2A 試點（3-6 個月）

• 在已穩定運行的 MCP 基礎上，選擇 2-3 個跨部門的業務流程進行 A2A 試點
• 為每個 agent 建立 Agent Card，定義能力邊界與通訊介面
• 實作 Orchestrator Agent 進行任務分配與流程編排
• 建立 agent 通訊的監控、日誌與審計機制

第三階段：生態擴展（6-12 個月）

• 將 A2A 端點向外部合作夥伴開放，建立跨組織的 agent 協作
• 參與 Linux Foundation 的互通認證計畫
• 建立企業級的 Agent Registry（代理註冊中心），集中管理所有 Agent Card
• 導入 NIST 安全標準，確保 agent 通訊的合規性

7.2 技術選型建議

針對不同規模與技術成熟度的台灣企業，我們的框架選型建議如下：

中小企業（50-200 人）：以 CrewAI + MCP 為核心。CrewAI 的學習曲線較低，適合團隊快速上手；MCP 提供標準化的工具連接。A2A 在此階段可暫緩，因為 agent 數量有限，Crew 內部的通訊機制已足夠。

中大型企業（200-1000 人）：以 LangGraph + MCP + A2A 為核心。LangGraph 提供生產級的流程控制能力；MCP 連接內部工具生態；A2A 實現跨部門 agent 的標準化通訊。建議配置專職的 AI 平台團隊負責協議層的維運。

大型企業 / 集團（1000+ 人）：以 Google ADK 或自建框架 + MCP + A2A 為核心。大型企業通常有多個事業部門各自建構 agent 系統，A2A 在此場景中的價值最為顯著——它確保了不同部門、不同技術棧的 agent 能夠在統一的協議上通訊。

7.3 常見挑戰與對策

根據資策會 MIC 的觀測^[10]以及我們的實務經驗，台灣企業在導入 agent 互通協議時常遇到以下挑戰：

挑戰一：既有系統缺乏 API 化。許多台灣企業的核心系統（尤其是 ERP 與 legacy 系統）缺乏完善的 API 層，難以直接建構 MCP Server。對策：先建置一個 API 中間層（例如使用 Node.js 或 Python FastAPI），將既有系統的功能以 REST API 暴露，再基於這些 API 建構 MCP Server。

挑戰二：資安與合規疑慮。當 agent 可以自主呼叫工具、委派任務時，企業資安團隊往往擔心失控風險。對策：在 A2A 層實作嚴格的授權機制（OAuth 2.0 + scope 限制），在 MCP 層實作「人機迴圈」（human-in-the-loop）機制——高風險操作必須經人工確認。建立完整的 agent 操作審計日誌。

挑戰三：人才缺口。同時熟悉 A2A、MCP 與 agent 框架的工程師在台灣市場仍然稀缺。對策：先培養核心團隊（2-3 人），從 MCP Server 開發切入（學習曲線相對平緩），再逐步擴展到 A2A 整合。善用外部顧問資源加速初期知識轉移。

八、安全架構設計：企業級 Agent 互通的信任基礎

在多 agent 系統中，安全不是附加功能，而是架構的基石。當 agent 可以代表人類做決策、存取資料、呼叫外部服務時，任何安全漏洞都可能造成嚴重的業務影響。以下是我們在企業級 agent 互通系統中實踐的安全架構設計。

8.1 分層安全模型

Agent 互通安全架構：

┌──────────────────────────────────────────────────┐
│  Layer 4: 業務策略層                               │
│  ── Agent 行為政策、風險閾值、升級規則              │
├──────────────────────────────────────────────────┤
│  Layer 3: A2A 通訊安全層                           │
│  ── OAuth 2.0 / mTLS 認證                         │
│  ── Task 授權鏈（誰授權誰做什麼）                   │
│  ── Agent Card 簽章驗證                            │
│  ── 通訊加密（TLS 1.3）                            │
├──────────────────────────────────────────────────┤
│  Layer 2: MCP 工具安全層                           │
│  ── 工具操作範圍限制（scope）                       │
│  ── 人機迴圈（高風險操作需人工確認）                 │
│  ── 輸入驗證與 sanitization                        │
│  ── 速率限制與異常偵測                              │
├──────────────────────────────────────────────────┤
│  Layer 1: 基礎設施安全層                           │
│  ── 網路隔離（VPC / Private Link）                 │
│  ── 日誌審計與 SIEM 整合                            │
│  ── 密鑰管理（KMS / Vault）                        │
│  ── 容器安全（image scanning / runtime protection） │
└──────────────────────────────────────────────────┘

8.2 授權鏈設計

在多 agent 系統中，「授權」不再是簡單的使用者-系統二元關係，而是可能形成多層級的委派鏈。例如：使用者授權 Orchestrator Agent 執行報告任務 → Orchestrator 委派 Research Agent 進行調研 → Research Agent 需要存取資料庫。在這條鏈路上，每一跳都需要明確的授權記錄。

A2A 的 Task 物件天然適合攜帶授權鏈資訊。建議在 Task 的 metadata 中嵌入授權 token，使用 JWT（JSON Web Token）格式攜帶原始授權者資訊、授權範圍與時間限制。MCP 端的工具操作則根據授權鏈中的 scope 進行權限過濾——如果授權鏈中沒有「資料庫寫入」的 scope，即使 agent 嘗試呼叫寫入操作，MCP Server 也應拒絕執行。

8.3 審計與可觀測性

企業級 agent 系統必須具備完整的審計能力。每一次 A2A 的 Task 建立、狀態變更、Message 交換，以及每一次 MCP 的工具呼叫、資源存取，都應記錄在統一的審計日誌中。建議整合至企業既有的 SIEM（安全資訊與事件管理）系統，以便安全團隊在單一面板中監控所有 agent 的行為。

NIST 的 AI Agent 安全框架^[6]特別強調「可解釋性」：當一個 agent 做出特定決策時，審計日誌應能重建其完整的決策脈絡——包括它參考了哪些資料（MCP 層記錄）、與哪些 agent 交換了什麼資訊（A2A 層記錄）、以及最終推理的過程（agent 框架層記錄）。

九、展望：Agent 互通協議的未來演進

A2A 與 MCP 的出現，標誌著 AI Agent 生態從「各自為政」邁向「標準化互通」的關鍵轉折點。展望 2026 年下半年至 2027 年，我們預期以下趨勢將加速落地^[4][5]：

Agent Marketplace 的興起：標準化的 Agent Card 使得 agent 能力的發布、發現與採購變得可行。企業可以像採購 SaaS 服務一樣，從 marketplace 中選擇並整合第三方 agent，大幅降低自建成本。Google Cloud 與 Salesforce 已在籌備各自的 Agent Marketplace。

跨組織 Agent 聯邦：A2A 的 HTTP 傳輸特性使得跨組織的 agent 協作在技術上完全可行。例如，一家品牌商的庫存管理 agent 可以直接與供應鏈夥伴的物流 agent 通訊，實現即時的供需協調——而不需要兩家公司建構點對點的系統整合。

協議融合與簡化：隨著 Linux Foundation 互通工作組的推進^[3]，A2A 與 MCP 在某些功能上可能出現融合。例如，MCP 的 Streamable HTTP 傳輸與 A2A 的 HTTP + SSE 傳輸可能統一為一種標準；或者出現一個「MCP over A2A」的封裝模式，讓遠端 MCP Server 可以透過 A2A 通道存取。

監管合規成為硬性要求：隨著各國 AI 法規的落地，agent 通訊的安全性、可審計性與可解釋性將從「最佳實踐」升級為「法規要求」。提前建構符合標準的 agent 互通架構，是規避未來合規風險的策略性投資。

AI Agent 互通協議的標準化，不僅是技術演進，更是產業格局的重塑。那些率先掌握 A2A + MCP 整合架構的企業，將在即將到來的 Agentic AI 時代中佔據先機——無論是在內部營運效率、跨組織協作能力，還是在參與 Agent 生態經濟的能力上。