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 更易调试。