Agent 小知识｜A2A 是什么：Agent 之间怎么通信

上一期我们聊了 Stateful Session：一次交互结束后，同一个 Agent 应用怎样保存状态，并在下一次调用时接着处理任务。但如果任务超出了它自己的能力，需要交给另一个独立 Agent，他们之间该如何“联络”呢？

假设一个发布协调 Agent 正在处理 payment-service 的升级。它能保存自己的任务状态，却不擅长分析上百项依赖之间的兼容关系。另一个团队恰好运行着专业的依赖兼容性 Agent，但双方不共享提示词、记忆、工具清单和内部工作流。这时，仅有服务地址还不够。协调 Agent 还要确认对方会做什么、请求怎样发送、工作是否已经开始，以及最终结果从哪里取得。

A2A 为这类协作提供了一套共同语言。一次交互中，发起请求的一方是请求方，接收请求并提供能力的一方是服务方。这两个角色随交互变化，同一个 Agent 可以在不同协作中切换角色。

一图概览 Agent 之间如何实现“联络”

图 1：取得能力卡 → 发送消息 → 直接收到回复或进入任务 → 接收状态更新 → 取得交付物。

从能力卡开始

两个 Agent 开始协作前，需要先确定对方的身份、能力和访问方式。服务方会发布一份机器可读的自描述文档，称为能力卡。公开 Agent 的标准发现地址是：

https://{domain}/.well-known/agent-card.json

（小字）注：本文按 2026 年 5 月发布的 A2A v1.0.1 规范说明这些对象；接口协商使用的协议版本仍写作 1.0。

依赖兼容性 Agent 的能力卡可以包含这样的信息：

{
  "name": "Dependency Compatibility Agent",
  "description": "提供依赖、运行时与目标版本之间的兼容性分析",
  "supportedInterfaces": [
    {
      "url": "https://compat.example.com/a2a",
      "protocolBinding": "HTTP+JSON",
      "protocolVersion": "1.0"
    }
  ],
  "version": "2.3.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json", "text/markdown"],
  "skills": [
    {
      "id": "dependency-compatibility-analysis",
      "name": "依赖兼容性分析",
      "description": "分析依赖、运行时与目标版本之间的潜在冲突",
      "tags": ["依赖分析", "兼容性"]
    }
  ]
}

协调 Agent 可以据此判断对方是否适合承接任务，以及应从哪个接口发起交互。其中，version 表示 Agent 自身实现或产品的版本，protocolVersion 表示该接口使用的 A2A 协议版本。

能力卡可以声明认证方式和安全要求，帮助请求方准备认证所需凭证，但不直接携带凭证。它提供能力与交互元数据：技能声明仍需验证，服务可用性仍需探测，调用权限仍需单独取得。

标准发现地址用于在已知域名下取得能力卡。在私有环境中，能力卡也可以通过直接配置或受控目录取得。大量 Agent 的注册、检索和选择属于 Agent 注册中心的范围。

消息与任务

确认远端能力后，协调 Agent 以请求方身份发送请求。A2A 使用不同对象分别承载通信内容、持续工作和正式结果。

内容单元可以承载文本、原始二进制、文件链接或结构化数据。每个内容单元只使用一种内容形式，因此协调 Agent 可以用文本说明目标，再用另一个结构化内容单元提交依赖清单。

请求可能直接返回消息，也可能进入需要持续跟踪的任务。例如，协调 Agent 先问：“你是否支持 npm 11 生成的锁文件？”远端 Agent 如果能立即回答，便可直接返回消息，这次交互随即结束。

接下来，协调 Agent 提出真正的分析请求：检查 payment-service 的依赖清单，评估升级到目标版本后的兼容性，并输出结构化风险报告。远端需要读取材料、检查依赖关系、确认运行时信息并生成结果，于是返回一个可跟踪的任务。

服务方根据请求和自身实现决定直接返回消息或建立任务，请求方无法仅凭“问题长不长”指定结果类型。

普通 SendMessage 默认会等待任务到达终态或中断态后再返回。请求方若想在任务建立后立即接管后续跟踪，可以设置 returnImmediately: true；若想从一开始持续接收更新，可以使用 SendStreamingMessage。

本例使用流式方法。流中的第一个响应是一个任务，后续更新继续围绕这个任务展开。

任务生命周期

任务是 A2A 对外提供的工作单元。它至少包含服务方生成的 id 和当前 status，还可以带有 contextId、历史消息、交付物和自定义元数据。

任务对象自身的标识字段叫 id；其他消息或事件需要指向它时，使用的字段叫 taskId。规范还定义了 TASK_STATE_UNSPECIFIED，用于表示状态未设置或无法识别，该状态不进入正常业务流程。其余任务状态可以按流程作用分为三类：

图 2：任务生命周期图

依赖兼容性 Agent 开始分析后，发现请求里没有说明目标 Node.js 版本。它需要明确的运行环境信息，于是把任务状态更新为 TASK_STATE_INPUT_REQUIRED，并附上一条消息，说明还需要哪项信息。

协调 Agent 随后补充“目标环境为 Node.js 24”。这条新消息同时带上原来的 taskId 和 contextId：

• taskId 指向这一次具体的依赖分析任务；

• contextId 关联同一发布目标下的多条消息和多个任务。

两者用途不同，contextId 只负责关联一组交互，不包含模型上下文、完整聊天记录、进程状态或第十三期所说的完整会话状态，也不能直接称为会话 ID。

收到补充信息后，远端 Agent 可以继续处理原来的非终态任务。兼容性报告生成后，结果作为交付物关联到这个任务，任务随即进入 TASK_STATE_COMPLETED。

终态任务不可重启，如果协调 Agent 又提出“请把修复建议按风险排序”，它需要发送一条新消息：沿用原来的 contextId，并可在这条消息的 referenceTaskIds 中引用旧任务。服务方再根据工作量返回新任务或直接回复消息。这样可以保留前后关联，同时避免改写已经结束的任务。

这些状态只描述协议边界上可以观察到的任务状态。远端 Agent 内部使用的模型、工具和执行步骤不会自动暴露给请求方。

长任务更新

任务状态发生变化后，请求方还需要及时取得更新。A2A 提供了几种更新方式，适合不同的连接条件。

本例的能力卡声明了 streaming: true，协调 Agent 又选择了 HTTP+JSON 绑定，因此 POST /message:stream 的响应使用服务器发送事件。卡片同时声明了 pushNotifications: false，本例不提供推送通知。

使用流式更新时，服务方会先返回任务，或者直接回复消息。进入任务后，服务方还会持续发送两类更新：

• TaskStatusUpdateEvent：任务状态发生变化；

• TaskArtifactUpdateEvent：产生新的交付物，或向已有交付物追加内容。

报告需要分批返回时，交付物更新可以使用 append 把当前内容追加到同一个交付物，并使用 lastChunk 标记最后一块。请求方据此重新组装结果，避免把每段内容当成一份新的报告。

在本例采用的 HTTP+JSON 绑定中，依赖分析进入 TASK_STATE_INPUT_REQUIRED 这样的中断态后，当前流会结束。协调 Agent 补充 Node.js 版本，再围绕同一非终态任务发起消息并接收新的更新。随后，它逐步收到兼容性报告的交付物增量，直到任务进入 TASK_STATE_COMPLETED。

服务器发送事件负责把远端变化及时送到请求方，任务状态和交付物负责描述变化内容。连接方式可以变化，任务语义保持一致。不同绑定承载相同的公共语义，流式传输方式有所区别：

推送通知使用 HTTP POST 将更新发送到回调地址，与服务器发送事件流分开。协议传输的是对外可见的任务、状态、消息和交付物更新，模型的隐藏推理过程不属于 A2A 传输内容。

协作边界

A2A 约定协作时交换的能力、消息、任务状态和结果。双方仍可独立选择模型、提示词、记忆和工具框架。MCP 用于 Agent 接入工具、资源和提示模板；A2A 用于独立 Agent 系统之间的发现、任务委派、状态更新和结果交付。远端 Agent 可以在内部使用 MCP，内部工具无须向请求方公开。

下一期继续看：当 A2A 负责 Agent 间协作、MCP 负责 Agent 接入外部能力时，两者怎样在同一个系统里配合。