跨框架 Agent 如何协作：理解 A2A 与 MCP

A2A 想解决的，是不同团队、不同框架开发的 AI Agent 如何协作：发现对方能做什么，把任务交出去，持续跟踪进度，必要时补充信息，最后取回结果。它把远程 Agent 当作黑盒，调用方不用了解对方的模型、提示词和工具。

原文最有用的判断是：执行一个明确动作，优先考虑 MCP；把一个需要自行规划的目标交给另一个系统，才更接近 A2A 的用途。但协议能统一通信格式，不代表权限、数据契约和生产可靠性也会自动解决。

A2A 和 MCP 的区别，在于你交出去什么

原文用人事 Agent 委托旅行 Agent 订票来解释 A2A。调用方提出出发地、目的地和日期，旅行 Agent 自己决定如何查询、处理缺失信息，再返回行程。

MCP 连接 Agent 与工具，A2A 连接 Agent 与其他 Agent。

MCP 暴露工具、资源和提示词，适合查询 SQL、读取文件、调用天气 API 等明确操作。A2A 面向目标委托，重点是任务状态、长时间执行、多轮交互，以及跨组织发现。

两者有灰色地带：可以把整个 Agent 包装成 MCP 工具。简单的一问一答能够这样实现；如果还要处理「缺信息暂停」「执行中更新」「断线后取回结果」，就需要额外设计任务管理机制。

原文给出的组合方式很直观：编排 Agent 通过 A2A 委托人事和旅行 Agent；后两者通过 MCP 调用日历、HRIS 和订票 API；确认时间和机票作为产物返回。

原文还称，MCP 由 Anthropic 于 2024 年末推出，采用 JSON-RPC 2.0，支持本地 stdio 和远程 HTTP；其 2026-07-28 修订移除了会话和初始化握手。这是具体版本断言，输入没有提供对应规范正文，不能据此直接修改现有 MCP 客户端。

一次委托如何从发现走到交付

第一步是读取 Agent Card。标准路径为 https://<domain>/.well-known/agent-card.json，采用 RFC 8615 约定；也可以通过内部目录或直接配置 URL 发现 Agent。

这张卡片相当于服务说明书：skills 声明能力，supportedInterfaces 声明接口，securitySchemes 和 security 描述认证要求。示例中的 Agent 自身版本为 1.2.0，接口的 protocolVersion 为 1.0，两者不能混为一谈。客户端先确认存在 book_flight，再选择接口并取得凭据。

认证信息放在 HTTP 请求头，例如 Authorization: Bearer …，不放进 A2A 消息正文。示例采用 OAuth2 client credentials，通过声明的 tokenUrl 获取具有 flights:write 权限的令牌。

接下来发送任务。下面这段请求体解决的是「提交目标后立即拿回任务，随后跟踪进度」：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "ROLE_USER",
      "parts": [
        {
          "text": "Book a direct Paris–Lyon flight on 12 November for employee 4432."
        }
      ]
    },
    "configuration": { "returnImmediately": true }
  }
}

要看的是 returnImmediately: true：按原文描述，v1.0 默认阻塞，该参数要求立即返回新建任务。任务标识由服务端生成；简单请求也可能直接返回 Message，因此客户端不能假定每次都得到 Task。

执行期间，可以轮询 GetTask、接收 SSE 流，或使用推送通知。原文流示例依次出现 TASK_STATE_SUBMITTED、TASK_STATE_WORKING、artifactUpdate 和 TASK_STATE_COMPLETED，到达终态后关闭流。

如果缺少舱位等信息，任务进入文中所称的 INPUT_REQUIRED。客户端再次调用 SendMessage，携带同一任务标识补充信息。最终交付物保存在 Artifact 中；错过流式更新后，可以通过 GetTask 获取任务历史和产物。

原文建议生产环境使用官方 Python、JavaScript、Java、Go、.NET SDK。示例 Python 客户端只读取一次状态，并不是完整的持续轮询实现。

通信可以标准化，数据和信任仍要自己管

A2A v1.0 分三层：底层是 AgentCard、AgentSkill、Task、Message、Part、Artifact、Extension 数据模型，以 Protocol Buffers 和 JSON Schema 描述；中间是 SendMessage、SendStreamingMessage、GetTask、ListTasks、CancelTask、SubscribeToTask 等抽象操作；上层绑定 JSON-RPC 2.0 over HTTPS、gRPC 或 HTTP+JSON（REST）。

这样拆分，是为了切换传输方式时减少对 Agent 逻辑的影响。原文认为公开接口常用 JSON-RPC，内部低延迟通信适合考虑 gRPC，但没有提供性能对照。

真正接入时，还有三处缺口。

首先，声明接受 application/json，不等于定义了业务字段。订票究竟需要员工编号还是姓名、日期如何编码，仍须通过技能描述中的 JSON Schema，或卡片声明的 Extension 约定。

其次，凭据传递不等于权限收缩。高权限编排器委托下游时，原文建议用 OAuth 2.0 Token Exchange（RFC 8693）换取短时、窄权限令牌。协议也没有标准化中央注册目录，团队仍需自行维护可信 Agent 清单。

最后，发现信息自身也需要验证。原文建议对卡片规范化处理（RFC 8785），再使用 JWS（RFC 7515）签名，客户端负责验签；公开卡片可以只放最低限度信息，认证后再提供 Extended Agent Card。

生产传输按原文要求使用 HTTPS，最低 TLS 1.2；认证方案包括 OAuth 2.0、OpenID Connect、API key 和 mTLS。高安全要求下，可以组合 mTLS 与 OAuth2，或采用 DPoP（RFC 9449）约束令牌使用方。调用链则建议接入 OpenTelemetry，并传播 W3C Trace Context 的 traceparent。

远程 Agent 返回的内容应当作为数据处理，不能直接升级成指令。

验签解决卡片是否被篡改，不能替代对返回内容的信任判断，也不能消除提示词注入风险。

我的判断

我认同原文按「动作调用」和「目标委托」选择协议的思路。跨团队协作时，任务状态和补充信息如果各写一套，接入成本会不断累积；统一这些交互确实有价值。

但原文是一篇机制讲解，没有提供真实部署的吞吐、延迟、失败率或运维成本，也没有与自定义 REST API、任务队列加回调方案做对照。关于 gRPC 的选型属于经验建议，关于「已经适合生产」的判断也不能当成实测结论。作者提到 Linux Foundation 治理和主要平台采用，却没有展开证据。

对只有几个固定内部服务的团队，REST API 加任务状态表可能已经够用。是否引入 A2A，要看能否从跨框架互操作、多轮任务和统一生命周期中获得实际收益。

版本迁移尤其需要单独评估。原文列出从 0.x 到 1.0 的破坏性变化：message/send 改为 SendMessage，状态名增加前缀，移除 kind 和 final 字段。旧教程即便业务逻辑相似，请求格式也可能无法直接复用。卡片中技能、URL 或能力发生变化时，作者还建议同步提升版本。

能拿来做什么

• 为 Node 编排服务接入远程 Agent 前，先判断需求是否包含等待补充信息、持续进度和可恢复查询；只有一次调用一次返回时，先评估普通 API 或 MCP 工具。
• 前端展示任务时，区分提交成功、执行中、等待输入和最终完成，并保留服务端任务标识，让断线后的页面能够通过 GetTask 恢复状态。
• 在接口评审中同时检查 Agent Card 和业务 JSON Schema，明确输入字段、产物格式及版本变化规则，避免把 MIME 类型当成完整契约。
• 在日常 AI 编程中引用 A2A 示例时，先确认目标是 0.x 还是 1.0；生产接入再补齐网关认证、配额、日志、长连接处理与 OpenTelemetry 链路。