A2A vs MCP 2026：AI Agent 協議大戰進入下一階段，JSON、Tools 與 Agents 怎麼分工？

協議大戰的誤解：互補，不是替代

把 MCP 與 A2A 當成「選一個贏家」，是 2026 年 Agent 架構裏最常見的誤判。MCP 的標準化對象是被動能力：MCP Server 暴露 tools、resources、prompts，Agent 客戶端發現後調用——對面是 API、數據庫、文件系統，沒有自己的模型與推理循環。A2A 的標準化對象是自主對等體：遠端 Agent 有自己的模型、工具、記憶與任務狀態，編排者只通過 Agent Card 知道「它能做什麼」，不窺探內部實現。

一個實用的記憶法：MCP 是 Agent 的「手」（向下拿工具）；A2A 是 Agent 的「同事對話」（橫向委託）。把整顆遠程 Agent 包裝成單個 MCP Tool 往往意味着把多輪推理壓成一次函數調用——任務變長、需要澄清或異步回調時，A2A 的 Task 生命週期更合適。反過來，用 A2A 去調一個純 REST 只讀 API，則多了一層不必要的 Agent 協商開銷。

2026 年 7 月 MCP 發佈 2026-07-28 無狀態版，Remote Server 可跑在普通 HTTP 負載均衡後面；A2A 則在 2026 年初達到 v1.0，Agent Card 支持加密簽名，150+ 組織在生產環境使用。兩者都在 AAIF 治理下演進，不是零和競爭。需要工具接入先上 MCP；需要跨團隊、跨廠商的多 Agent 編排再上 A2A——大多數生產系統最終是「Orchestrator Agent：向下 MCP、 sideways A2A」。

MCP：Agent 向下連 Tools 與數據

MCP 定義客戶端與 Server 之間如何發現工具、交換 JSON-RPC、返回結果。核心 JSON 面：

1. tools/list：Server 返回 Tool 數組，每個 Tool 含 name、description、inputSchema（JSON Schema 子集）。
2. tools/call：客戶端發 params.name + params.arguments 對象，Server 執行業務並返回 result.content。
3. resources/* 與 prompts/*：只讀上下文與模板，同樣走 JSON-RPC。
4. 2026-07-28 起每個請求可在 _meta 裏帶協議版本，Session 從協議層移除，適合水平擴展。

MCP 不替 Server 校驗 arguments——inputSchema 是聲明，執行層必須 JSON.parse + Schema 校驗。這與模型 Tool Calling 是兩條 hop：模型吐出的 arguments 字符串，要先 parse，再組裝成 tools/call。詳見MCP 與 JSON Schema 解析與Stateless MCP 解析。

無狀態 MCP 下 tools/call 請求體示例：

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "searchInvoices",
    "arguments": {
      "startDate": "2026-01-01",
      "endDate": "2026-01-31",
      "status": "paid"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28"
    }
  }
}

A2A：Agent 橫向連 Agent

A2A 標準化 Agent 之間的發現、任務委託與結果回傳。每個 A2A Agent 在 well-known URL 發佈 Agent Card（常見路徑 /.well-known/agent-card.json），JSON 描述名稱、技能（skills）、端點 URL、認證方式與 streaming 能力。編排 Agent 拉取 Card 後，通過 JSON-RPC（HTTP + SSE）發送 message/send 或管理 Task 生命週期——子 Agent 可以提問澄清、流式返回、甚至運行數小時後再 push 通知。

與 MCP 的關鍵差異：A2A 對面是不透明 Agent，不是可調用的函數表。你不應假設能直接映射成 tools/list 裏的單個 Tool——除非遠端明確把某個 skill 暴露爲確定性 RPC。Task 有 id、status（submitted / working / completed / failed 等）、artifacts 與 history；JSON 載荷描述消息 parts（text、file、data），而不是固定的 arguments Schema。

Agent Card 片段（發現層 JSON）：

{
  "name": "Invoice Specialist Agent",
  "description": "Finds, validates, and summarizes invoices for finance workflows",
  "url": "https://agents.example.com/invoice",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "id": "search-invoices",
      "name": "Search invoices",
      "description": "Query invoices by date range and status",
      "inputSchema": {
        "type": "object",
        "properties": {
          "startDate": { "type": "string", "format": "date" },
          "endDate": { "type": "string", "format": "date" },
          "status": { "type": "string", "enum": ["draft", "sent", "paid"] }
        },
        "required": ["startDate", "endDate"]
      }
    }
  ],
  "authentication": {
    "schemes": ["bearer"]
  }
}

編排 Agent 向 Invoice Specialist 委託任務時，message/send 請求體大致如下：

{
  "jsonrpc": "2.0",
  "id": "req-001",
  "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [
        {
          "type": "text",
          "text": "Summarize all paid invoices between 2026-01-01 and 2026-01-31"
        }
      ]
    },
    "metadata": {
      "correlationId": "orch-42"
    }
  }
}

Google ADK 的 RemoteA2aAgent 每輪路由到一個遠端 Agent；跨多個 Specialist 並行詢價時，可直接用 a2a-sdk。Salesforce、SAP、Atlassian 等 50+ _launch 夥伴在 2025–2026 年接入 A2A 作爲跨組織 Agent 互操作層。

JSON 在三層協議裏的分工

把 JSON 在 Agent 棧裏的角色按 hop 拆開，避免「一個 Schema 走天下」：

工程上常見三類 JSON 文件：schemas/tools/*.schema.json（MCP + 模型 tools 共用）、schemas/agents/*.card.json（A2A 發現，或由 Card 生成器輸出）、schemas/output/*.schema.json（Structured Output）。改 Tool 字段時只 bump tools Schema；改 Agent 能力描述時更新 Card 版本；三者不要混在一個文件裏。

聯調時把三份 JSON 並排：模型吐出的 tool arguments、MCP tools/call params.arguments、A2A Task 最終 artifact 裏的 JSON。形狀不一致時，問題幾乎總在適配層——而不是「協議選錯了」。站內AI 生成 JSON 錯誤指南的四層 taxonomy 同樣適用於跨協議流水線。

2026 對照：MCP vs A2A vs 模型 Tool Calling

粗粒度對照表（細節以各規範爲準）：

選型建議：只有一個 Agent、只需連內部 API 和數據庫 → MCP 足夠，不必爲了「架構先進」硬上多 Agent A2A。需要跨 BU、跨 SaaS、跨雲廠商委託 specialist → 在 Orchestrator 上加 A2A 客戶端，每個 specialist 內部仍可用 MCP 接自己的工具。模型 Tool Calling 是第三條線——不管走 MCP 還是 A2A，Orchestrator 內的 LLM 仍通過 function/tools 選動作；arguments 的 JSON Schema 應與 MCP inputSchema 同源，見MCP JSON Schema 文。

組合架構與 JSONVue 實操

推薦的最小生產拓撲：

1. Orchestrator Agent（LLM + 策略）：模型 Tool Calling 決定「調 MCP 還是委託 A2A」。
2. MCP 層：GitHub、Postgres、Slack 等 Tool Server；canonical Schema 生成 inputSchema 與 OpenAI tools[]。
3. A2A 層：Invoice、Compliance、Pricing 等遠端 Agent；啓動時拉 Agent Card 緩存，Task 完成後 parse artifact JSON。
4. 校驗鏈：每 hop parse → JSON Schema → 業務規則；A2A artifact 與 MCP result 同樣不應 blind trust。

調試清單：① Agent Card JSON 是否 valid、skills 是否與文檔一致；② tools/list 與模型 tools[] 是否同源 Schema；③ A2A Task history 與 MCP tools/call 日誌用 correlationId 關聯。瀏覽器裏：JSON 格式化看 parse；JSON Schema 校驗對 arguments 與 Card 內 inputSchema；JSON Diff對比模型 arguments 與 MCP params.arguments。

延伸閱讀：MCP 與 JSON Schema、Stateless MCP、AI Structured Output、Apple AI Agent 與 JSON。

常見問題 FAQ

總結與下一步

2026 年的「協議大戰」其實是分層分工：MCP 向下（Tools/JSON-RPC/inputSchema），A2A 橫向（Agent Card/Task/message），模型 Tool Calling 管 Orchestrator 內 LLM 的 arguments JSON。JSON Schema 是跨層契約 glue，但 Structured Output、Tool arguments、Agent artifact 應分文件維護。

下一步：畫一張你的 Agent 拓撲——哪些 hop 走 MCP、哪些走 A2A；把 tools/list 與 Agent Card 的 JSON 貼進 JSONVue 校驗。先 MCP 接通主工具，再按需加 A2A specialist，比一開始堆多 Agent 更易調試。