核心概念：两个 agent 如何彼此发现、对话，又互为黑盒

1.1为什么需要 A2A：M×N 与水平 vs 垂直

A2A 把 agent↔agent 的两两适配（M×N）收敛成对一份公共协议的适配（M+N），解决的是 agent 层的互操作，处在 agent↔agent 这条水平线上。

底层机制：M×N→M+N 省的是哪一类工作

把它说具体：M×N 里每一格"适配"包含三样东西——怎么发现对方能干什么、用什么线缆格式发请求、对方用什么数据结构回话。没有公共协议时，这三样每一对 agent 都要重新约定一遍，且是私有约定，换个对端全部作废。A2A 把这三样固定成规范：发现统一走 Agent Card（§1.2），线缆统一走 JSON-RPC / gRPC / REST 三选一加 SendMessage 方法，数据统一走 Task / Message / Artifact（§1.3）。于是每个调用方只需实现一次"说 A2A"，每个 agent 只需实现一次"听 A2A"，总工作量从 M×N 降到 M+N。

这里有一条容易被"M+N 省事"盖过去的代价：统一协议必然是各端的最小公约数。私有点对点协议能为某一对 agent 量身定制（比如塞进只有它俩懂的二进制字段），A2A 为了让任意两端都能对话，只能用通用的 HTTP + 文本载体，牺牲了专用协议的紧凑与效率。规范用"额外提供 gRPC、REST 两种绑定，由 Agent Card 的 preferredTransport 声明首选"来部分对冲这条代价——这条权衡 §2.3 会展开。

另一个关键区分：A2A 治的是水平方向（agent 和对等 agent 之间），而同样喊"M×N→M+N"的 MCP 治的是垂直方向（agent 和它脚下的工具之间）。同源的动机，发生在两个不同的层。把这两条线分清楚，是看懂整套 A2A 的第一步，也是 §1.5 判别口诀的根。

1.2Agent Card：能力声明与去中心发现

Agent Card 是一个 agent 公开发布的能力声明 JSON，固定位于 GET /.well-known/agent-card.json，让别的 agent 无需注册中心即可发现"它能干什么、怎么连、怎么认证"。

底层机制：它像 robots.txt——静态、可缓存、声明类型而非凭证

Agent Card 的几个设计点，比"一份能力 JSON"这句话深一层：

• 固定路径 = 去中心发现。路径写死成 /.well-known/agent-card.json（v1.0；v0.x 旧路径 agent.json 已弃用）。这和 robots.txt 同一个思路：约定一个人人皆知的位置，于是不需要中央注册中心来"查这个 agent 在哪"——知道域名就能拼出 Card 的 URL。代价是没有注册表那种"按能力检索全网 agent"的能力，发现是"已知道域名、去确认它能干什么",而非"去找谁能干这件事"。
• 静态、可缓存。Card 是一份静态文档，调用方可以缓存。代价：它声明的是静态快照，没有 MCP initialize 握手那种"每次会话现场协商能力"的动态性——能力是预先声明死的（认证后可通过 GetExtendedAgentCard 取到更详细的一份，这是 §2.2 的话题）。
• 声明能力类型，不携带凭证本身。Card 里的 securitySchemes 声明的是它采用 OAuth2 / API Key / mTLS 这类方案，而不包含任何实际的 token 或密钥。凭证由调用方带外另行获取，发请求时放进 HTTP 头——绝不出现在 Card 里，也不进 JSON-RPC 载荷。把"声明用哪种锁"和"递上哪把钥匙"分开，是 Card 能公开发布而不泄密的前提。

Card 的核心字段：url（A2A 服务端点）、skills（技能列表，每个含 id / 描述 / 输入输出模式）、capabilities（如 streaming、pushNotifications 这些可选能力开关）、securitySchemes（认证方案类型）、provider（提供方信息）。一个调用方读完这五样，就知道"调它走哪个地址、它会哪几手、怎么跟它认证、它归谁"。

场景走查

需求："一个差旅编排 agent 想把'订机票'这件事托付给某航司的远程 agent"。第一步，编排 agent 用域名拼出 https://air.example.com/.well-known/agent-card.json 并发 HTTP GET——这是Agent Card 发现。读到 skills 里有 book-flight、capabilities.streaming=true、securitySchemes 声明走 OAuth2、url 指向 https://air.example.com/a2a。于是编排 agent 知道：这个对端确实会订票、支持流式、得先按 OAuth2 带外拿到 token。注意此刻还没发任何任务，凭证也还没递——Card 只解决了"能不能、怎么连、用哪种锁"。下一步把订票请求真正发出去、对端建出一个有状态的工作单元来跟进，需要的是 §1.3 的数据模型。

1.3数据模型：Task / Message / Part / Artifact

A2A 的协作内容由四类对象承载：Task（有状态的工作单元）包住 history（Message[]）和 artifacts（Artifact[]）；Message 由 Part[] 组成（文本 / 文件 / 结构化数据）；Artifact 是任务的产出。

底层机制：Task 是有状态、长生命周期的工作单元，不是一次 request/response

这套对象的关键，不在字段多少，而在 Task 的有状态、长生命周期这一点——它正是 A2A 能撑起小时级、天级任务的原因：

• Task：一次托付对应一个 Task，有自己的 id 和 contextId，并带一个 status（含 state 与时间戳）。它持续存在——调用方可以隔一段时间用 GetTask 再来查它现在到哪一步了。这与"发一个 HTTP 请求、等一个响应、连接关掉就结束"的模型根本不同：Task 在服务端有生命周期，跨越多次交互。它内部包两样东西——history（迄今的 Message 列表）和 artifacts（已产出的 Artifact 列表）。
• Message：一条消息，带 role（user 或 agent）和一个 parts 数组。注意一条 Message 可以同时含多个 Part——这是它能表达多模态的原因。
• Part：消息的内容单元，靠 kind 字段区分类型——text（TextPart，纯文本）、file（FilePart，文件，可内联或给 URI）、data（DataPart，结构化 JSON 数据）。模态无关的设计让同一条 Message 能混装文字、文件、结构化数据。
• Artifact：任务的产出，有 artifactId，内容同样是 Part[]。它和 Message 的区别在语义：Message 是"对话过程中的往来",Artifact 是"任务最终或阶段性的成果"。

这套有状态设计的代价：服务端必须存储并管理 Task 的生命周期（建、改状态、留 history、存 artifacts），不能像无状态 HTTP 端点那样处理完即忘。这份存储与状态管理的复杂度，是换取"长任务、可重查、可中断续接"的成本——Task 在哪些状态之间转移、怎么转，是 §2.5 的生命周期状态机。

1.4不透明 agent 原则（opaque）

远程 agent 对调用方是黑盒：它不暴露内部提示词、记忆、工具或推理过程，只暴露 Agent Card 声明的能力 + 显式交换的 Message / Task。

底层机制：动机是 IP 保护 + 安全面收缩 + 解耦，代价是无法深度自省

"黑盒"不是含糊其辞，它对应三条具体动机和一条具体代价：

• IP 保护：agent 的竞争力常常就在它的提示词、工具编排、私有数据上。不透明让供应商能对外提供能力，而不泄露这些核心资产。
• 安全面收缩：对方能触达的只有 Agent Card 声明的接口 + 消息通道，内部状态、工具、记忆都不在攻击面上。暴露得越少，可被利用的入口越少。
• 解耦：双方各自换实现、换模型、换内部架构，只要 Agent Card 声明的契约不变，对端无感。这正是 §1.1 那套 M+N 互操作能成立的微观保证。
• 代价：调用方无法深度自省或细粒度协调对端——看不到它的中间推理，不能干预它内部用哪个工具，只能在"发消息 / 查 Task 状态"这个粒度上交互。要更细的协同？不透明原则就堵死了。

场景走查

接 §1.2 那个差旅例子。编排 agent 把"订一张明早飞上海的票"发给航司 agent（Message 跨过边界，§1.3），航司 agent 建出一个 Task 开始处理。整个过程里，编排 agent 看不到航司 agent 内部用了哪个订座系统、用什么提示词解析需求、查了哪些库存——这些都在虚线框里，是不透明的。它能依据的，只有航司 agent Agent Card 当初声明的 book-flight 技能，以及对端通过 Message / Task 状态显式回传的内容。若编排 agent 想"接管航司 agent 内部、改它选座逻辑"，不透明原则直接堵死——跨信任边界的协作，本就只允许在声明的能力这个粒度上发生。这份"看不见内部"既是 IP 与安全的保护，也是协调粒度的天花板。

1.5A2A ⊥ MCP：正交，不是竞争

A2A 与 MCP 正交：MCP 垂直（agent→工具，wire 上是 tools/call），A2A 水平（agent→对等 agent，wire 上是 SendMessage + Task）；同一个 agent 常对外用 A2A、对内用 MCP。

底层机制：被调对象的性质决定了用哪个协议

两者的分界不在口号，而在线缆上搬的是什么、对端是什么东西：

• MCP（垂直）：线缆上搬的是 tools/call、resources/read 这类调用，对端是一个无状态原语——一个工具或数据源，给输入、回结构化输出，调用方完全掌控。方向是"往下"伸手够能力。
• A2A（水平）：线缆上搬的是 SendMessage + Task 对象，对端是一个有状态、不透明、自治的对等 agent——它会推理、能多轮、可能反问、任务往往很长（§1.3 的 Task + §1.4 的 opaque）。方向是"横向"托付给一个平级的智能体。

两者组合使用是常态，也是 2026 年企业级的默认栈：一个 agent 对外用 A2A 暴露成对等体，供别的 agent 托付；对内用 MCP 调自己的工具去完成那次托付。它们不在同一条线上抢位置，所以是正交（⊥）。

场景走查 · repair-shop

用修车行串起来：顾客 → 修车行——顾客（一个 agent）把"我的车有异响"托付给修车行（另一个 agent），对端是个会诊断、会追问、要花时间的自治体，这是 A2A。修车行内部，修车行 → 技师——前台把活分派给某个技师 agent，技师同样是个自治对等体，仍是 A2A（agent↔agent，无论跨不跨公司）。而 技师 → 诊断仪——技师拿起诊断仪读取故障码，诊断仪是个无状态工具，给输入回数据，这是 MCP。三跳里前两跳水平、第三跳垂直，A2A 与 MCP 在同一个系统里各管一段，正交共存。