wire 上发生了什么，以及为什么这么设计

2.1整体：一次任务委托端到端

先把 01 章的七个静态抽象放进一条时间线，看它们在 wire 上依次怎么动。一个客户端 agent 要把一件事委托给一个远程对等 agent，从「不知道它在哪」到「拿回结果」，恰好走六步。本章后面每一节，都是在这条时间线的某一步上展开取舍——所以先盯住每一步在 wire 上传的是什么、凭证在哪一层、状态存在谁那里。

2.2发现机制的取舍

A2A 把发现做成「去固定 URL 取一份静态 JSON」——像 robots.txt 一样可缓存、无需注册中心，代价是能力只能静态声明，没有运行时协商。

底层机制：静态文件发现，谁也不用跑注册中心

/.well-known/ 是 IETF 为「众所周知的资源」预留的路径前缀，robots.txt 是同一族的老熟人。把 Agent Card 放在这里，意味着发现完全是去中心、可缓存的：没有一个中央注册中心要运维、要保证高可用、要成为单点故障；客户端可以像缓存任何静态资源一样缓存这份 Card。代价直接写在机制里——Card 是一份静态声明，agent 在写下它的那一刻就把能力固定了，客户端在连接前读到的是「这个 agent 一贯能做什么」，而不是「此刻、对你这个调用方，它能做什么」。

2.3线缆：SendMessage + 三传输绑定

委托一件事，wire 上发的是 SendMessage——同一个抽象方法有 JSON-RPC 2.0 / gRPC / HTTP+REST 三个对等绑定，agent 在 Card 里声明它支持哪些、首选哪个。

下面是一条真实的 SendMessage JSON-RPC 请求（spec 示例）。注意 params.message 就是 01 章的 Message 抽象：一个 role 加一个 parts 数组，数组里每个 Part 带自己的 kind 和内容——这就是 01 章模态无关 Part 的 wire 形态。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "user",
      "parts": [
        { "kind": "text", "text": "把这份季度财报里的风险段落抽出来" }
      ],
      "messageId": "9229e770-767c-417b-a0b0-f0741243c589"
    }
  }
}

method字面值就是 SendMessage，与抽象名一致（v1.0+）。 params.message即 01 章的 Message：role + parts[]。 parts[].kind标出这个 Part 的模态（此处 text，也可是 file / data）。

三个对等绑定：同一抽象，三种线缆

A2A 不绑死一种传输。同一组抽象操作，规范定义了三个对等的绑定（spec §5.3），agent 在 Agent Card 的 capabilities / preferredTransport 里声明它实现了哪些、首选哪个。下表是抽象操作到三种线缆的映射——同一行的三个写法，做的是同一件事。

REST 列里的 :verb 冒号语法是 Google AIP 风格的自定义方法。三种绑定语义对齐，差别只在线缆形态——选哪个取决于双方基础设施：JSON-RPC over HTTP 部署最省心，gRPC 适合内网高吞吐，REST 适合已有 RESTful 生态。

2.4三种交互模式

同一个委托，按任务时长和客户端形态有三种交互：请求/响应（短任务）、SSE 流（要实时进度）、webhook 推送（长任务 / 断线客户端）——三者箭头方向不同。

底层机制：三种模式的箭头方向不一样

• ① 请求/响应——客户端调 SendMessage，在同一个 HTTP 响应里直接拿回 Task（或已是 TASK_STATE_COMPLETED，或仍在 TASK_STATE_WORKING，客户端事后用 GetTask 回查）。适合秒级短任务。
• ② 流式（SSE）——客户端调 SendStreamingMessage，服务端回 Content-Type: text/event-stream，在一条长连接上依次推帧：先是 Task，然后是若干 TaskStatusUpdateEvent（状态变化）和 TaskArtifactUpdateEvent（产出分块，带 append / lastChunk 标志）。流在终态时关闭，断了可用 resubscribe 续。适合要实时看进度的中长任务。
• ③ 异步推送（webhook）——客户端先注册一个 PushNotificationConfig（webhook url + token + auth），然后可以断开连接；服务端在 Task 有重大状态变化时，主动 POST 到那个 webhook url。客户端随时可用 GetTask 主动回查。适合跑几小时的长任务、serverless / 移动端断线客户端。

2.5Task 生命周期状态机

Task 是有状态的：从 TASK_STATE_SUBMITTED 起步，经 WORKING，可在中途落到可中断的 INPUT_REQUIRED / AUTH_REQUIRED，最终收敛到四个终态之一。

2.6五个设计取舍 + opaque 的代价

把前五节的取舍并到一张表上看：每一条都是「拿了什么 / 放弃了什么」，而它们最终都收束到同一个灵魂——把对等体当不透明的黑盒。

代价收束在 opaque：黑盒换来的一切，都有同一笔账

不透明是这张表的中心行，也是全章每个取舍最终指向的地方。把远程对等体当黑盒——只暴露 Agent Card 上的能力声明，绝不暴露它的提示词、记忆、内部工具——直接换来三样东西：厂商能藏住自己的 IP，攻击面更小，双方解耦得彻底。但同一个「黑盒」属性，反过来就是代价：你看不进去。你不能像在自己掌控的多 agent 系统里那样，读对等体的中间状态、对它的推理过程做断点、把它的内部记忆当共享黑板来协调。

§跨概念综合：给一个长任务选型

把这一章的四个机制——发现、传输、交互模式、生命周期——串到一个具体场景上走一遍。这是本章每个零件第一次合在一起用。