A2A v1.0 协议基础

• 理解 A2A 的开放治理与 Linux Foundation 背景对供应商中立性的意义
• 理解标准中立性如何降低企业锁定风险并促进互操作生态
• 认识对工程团队在选型、合规与长期演进上的影响

A2A v1.0 由 Google 提出并捐赠给 Linux Foundation，由涵盖多家厂商与社区成员的多方治理组织（如 Linux Foundation 的 Agentic AI 项目）共同维护。这意味着协议没有被单一供应商所控制，标准版本、扩展点与兼容性决策由多方投票决定，因而具备真正的商业中立性。对企业而言，这显著降低了供应商锁定（vendor lock-in）风险——企业可以基于开放标准构建跨厂商的 Agent 互操作层，而不必担心单一云厂商关闭专有 API 或改变许可条款。同时，多方治理带来的稳定规格降低了采用风险，因为规格演进是公开、可预期、可回退的，社区也会提供兼容性测试与参考实现（如 conformance tooling）。这推动了企业大规模采用，因为采购方、合规团队和安全团队都能将对等协议作为一种可审核、可审计的行业标准来评估。

标准中立性不只是政治口号，它直接转化为工程可决策性：企业敢在底层协议上做长期投资，因为知道规格不会因单一厂商转向而废弃。Linux Foundation 治理还意味着存在可追踪的 issue 流程、发布节奏和兼容性测试矩阵，工程团队可以据此规划升级窗口。这也是为什么 A2A 与 MCP 一起被纳入多厂商互操作的主流叙事，因为两者都走开放治理路线。

• 掌握 Agent Card 的标准字段结构（identity、endpoints、capabilities、skills、authentication）
• 理解 .well-known 发现与 URL 归属校验
• 理解如何通过签名链、TLS 与来源校验提升可信性

Agent Card 是 A2A 中描述 Agent 的机器可读元数据，通常以 JSON 格式暴露在 /.well-known/agent.json 端点。核心字段包括：identity（Agent 的标识，如 DID、URL 或名称）、endpoints（task/send 的调用 URL 及支持的传输 binding）、capabilities（Streaming、PushNotifications、StatePropagation 等能力开关）、skills（Agent 可执行的能力列表，含 id、名称、描述、输入输出 schema）、authentication（支持的认证 scheme，如 OAuth2/Bearer/mTLS 及所需 scope）。客户端验证可信性的步骤包括：1) 确认卡片来自预期的 origin 并通过 HTTPS 获取，防止中间人；2) 校验端点 URL 与卡片来源 host 一致，避免跨域伪装；3) 若卡片带签名，用信任锚（如注册中心公钥或 DID 的验证方法）验证签名链；4) 检查技能的 schema 与自身调用能力是否匹配。可信性验证本质上是"来源 + 签名 + 传输安全"三者的叠加，不能只信任卡片内容本身。

Agent Card 增加了"自我描述"的灵活性，但也带来伪造面。A2A 规范把 Agent Card 设计为可被扩展的元数据，并用签名扩展把"声明"与"可验证"联结起来。客户端不应把卡片当作可信输入，而应始终做来源与签名的双重校验。

• 掌握 A2A Task 状态机中各个状态的定义与含义
• 理解合法状态转移规则与终态
• 理解 input-required 与 auth-required 作为中间态的特殊处理

A2A 的 Task 状态机定义了明确的生命周期。submitted 是任务被服务端接受后的初始状态；working 表示 Agent 正在处理；input-required 表示需要补充参数；auth-required 表示需要新的授权（如刷新 OAuth token）；completed、failed、canceled、rejected 是终态。合法转移大致为：submitted → working → completed/failed；working → input-required → working；working → auth-required → working；任一非终态可被 canceled 终止；rejected 表示服务端从一开始就拒绝接受任务。状态机应把"终态不可再转移"作为硬约束，并限制每个状态只能进入其允许的后继状态，避免例如 completed 又被改回 working、或直接由 submitted 跳到 completed 等非法路径。合法的中间态循环（input-required / auth-required ↔ working）是允许的，但应设置迭代上限防止死循环。

明确的终态语义让调用方可以安全地审计、清理和决定后续动作（如重试、退款）。把 auth-required 单独作为状态，是为了让客户端能区分"补参数"与"重新授权"这两种不同的恢复动作，避免混淆导致重复发送仍失败。

• 理解 A2A 与 MCP 在协议层上的分工差异
• 掌握 A2A 的 JSON-RPC 2.0 over HTTP/SSE 与 MCP 的 JSON-RPC over stdio/SSE
• 理解二者在"Agent 间"与"Agent-工具"边界的互补关系

A2A 与 MCP 在协议层上互补而非竞争。A2A 面向 Agent 与 Agent 的高层任务协同，使用 JSON-RPC 2.0 作为消息格式，通过 HTTP 传输执行任务、通过 SSE 推送流式事件，聚焦于"任务生命周期、状态、artifact 与协商"。MCP 面向 Agent 与工具/资源/提示词的连接，同样使用 JSON-RPC 2.0，但运行在 stdio（本地进程）或 SSE（远程）之上，提供 tools、resources、prompts 等原语。A2A 的颗粒度是"一个任务、多步、多 artifact"，MCP 的颗粒度是"一次工具调用、一个结果"。二者在协议栈上可以共存：Agent 通过 A2A 找到并协作另一个 Agent，而那个 Agent 内部通过 MCP 调用具体工具。这种互补让开发者可以组合使用：A2A 负责编排与任务分发，MCP 负责把底层能力暴露为可调用的工具。

互补的关键在于"抽象层级"与"边界"不同。A2A 抽象的是异步长任务与状态机，MCP 抽象的是同步工具调用。二者都基于 JSON-RPC 2.0，但关注点正交，因此能被同一套调用链串联使用，这也是 A2A 与 MCP 被并称为 Agent 互操作双协议的原因。

• 理解 Agent Card 签名扩展的验证机制
• 理解来源校验、TLS 与信任锚的作用
• 理解恶意卡片注入的威胁面与缓解手段

防止恶意 Agent Card 注入需要组合来源校验与签名验证。来源校验上，客户端只从预期的 HTTPS origin 获取卡片，并检查卡片中端点 URL 的 host 与卡片来源一致，防止攻击者把卡片托管在可信域名却指向恶意端点。签名验证上，A2A 支持在卡片中附加签名（JWS 等），使用注册中心公钥或 DID 的验证方法作为信任锚来验证签名链（卡签名 → 注册中心签名 → 可选 DID 锚定）。若签名无效或信任锚不匹配，客户端应拒绝该卡片或降级处理，而不是静默信任。伪造的端点（指向恶意服务器）与伪造的能力（声明假 skills）都因无法通过签名链而失败。此外，客户端应校验 skills 的 schema 与声明，避免接收恶意 crafted 的输入契约。

威胁本质是"身份伪装"与"能力欺骗"。签名链把卡片声明与可信实体的公钥绑定，使攻击者无法在没有私钥的情况下伪造可信卡片。来源校验与传输安全（TLS）则阻断"合法卡片被劫持/替换"的路径。验证失败时优雅降级（拒绝调用、记录告警、回退到白名单）比静默信任更安全。

• 理解 streaming 事件中 task/status/artifact 的关联字段
• 理解事件顺序、增量与幂等键
• 理解断线重连后的状态恢复与事件补齐

在 A2A 的流式输出中，所有事件通过 taskId 关联到同一个 Task，事件携带 messageId/eventId 与 kind（如 status-update、artifact-update、partial-message）。客户端按 messageId 排序并去重，用幂等键记录已处理事件，避免重复消费。artifact 事件通过 artifact.parts 与 id 标识增量，支持部分传输与断点续传。断线恢复时，客户端重新调用 task/get 或 task/cancel 获取当前权威状态，再通过状态中的 artifacts 与 cursor 补齐缺失的增量事件；SSE 的 Last-Event-ID 或自定义游标可用于从断点续读。幂等性保证重复投递不产生重复副作用，例如客户端在恢复时对比已落库的 artifact 版本，跳过已完成的写操作。

流式任务天然是"乱序 + 重放 + 断线"的环境，因此必须把"事件标识"与"状态权威"分离：事件只负责增量推进，task/get 才是最终一致性的收敛点。幂等键 + 游标 + 终态收敛三件套是断线恢复的标准做法。

• 掌握 webhook 签名（HMAC/JWS）、timestamp、nonce 的反重放机制
• 理解重试与去重策略（幂等键、退避）
• 理解 SSRF 防护（回调地址白名单、来源校验）

Push Notification webhook 的安全设计包括：1) 签名验证——发送方用共享密钥对请求体做 HMAC 或 JWS 签名，接收方用预共享密钥验证，防伪造；2) 时间戳 + nonce 三元组——请求头携带 timestamp 与 nonce，接收方拒绝 timestamp 偏差超过窗口（如 ±5 分钟）的请求，并用 nonce 缓存去重，防重放；3) 重试——接收方返回 200 才算成功，否则发送方按指数退避重试，且重试携带相同幂等键；4) 去重——接收方按事件 ID/幂等键去重，保证重复投递不产生重复副作用；5) 过期——事件带过期时间或 TTL，过期后不再处理；6) SSRF 防护——客户端注册回调时校验回调 URL 为公网可达的合法地址（拒绝内网/保留 IP），webhook 接收端也校验来源 IP 或签名，防止攻击者诱导服务端访问内网。签名与时间戳解决"伪造与重放"，去重与幂等解决"重复副作用"，URL 沙箱解决"SSRF"。

webhook 是攻击者常打的点：伪造、重放、SSRF 都可能。A2A 推荐的三元组（签名+timestamp+nonce）把"内容可信""时效可信""一次有效"三个维度都覆盖了。SSRF 防护则从回调注册与投递两端同时收紧，因为它本质是"服务端发起的出站请求"。

• 区分 Agent 身份认证与终端用户授权两个概念
• 理解权限逐跳收缩与最小权限原则
• 理解 OAuth Token Exchange / delegated scope 的衰减

认证（authentication）回答"Agent 是谁"，即验证 Agent 身份，通常用 mTLS、JWT 或 OAuth 客户端凭据；授权（authorization）回答"代表哪个终端用户、执行哪些操作"，即用户在特定 scope 内的授权。二者必须分开：Agent 身份合法不代表它有权替用户执行任意操作。Agent 间调用不能自动继承全部用户权限，因为：1) 用户只对原始 Agent 授权，未对被链式调用的下游 Agent 授权；2) 下游 Agent 可能信用等级更低、环境更不可控，继承全部权限会放大越权面；3) 权限的复制会脱离原始意图，无法追踪。因此应采用"逐跳收缩"策略：每跳根据任务需要重新委托一个更窄的 scope，例如用 OAuth Token Exchange（RFC 8693）把当前 token 换成受限的 delegated token，并对下游声明能力边界与数据范围。

现代 Agent 安全的核心教训是"权限不能随调用链自动扩散"。逐跳收缩把"用户授权"作为可衰减的票据逐级传递，每一跳都显式声明"我代表谁、能做什么、不能做什么"，从而控制攻击面并保留审计链。

• 理解 artifact 的版本化与内容寻址
• 理解签名（哈希、内容签名）与可验证传输
• 理解存储层的溯源与完整性校验

保证 artifact 可验证与不可篡改，可组合以下手段：1) 内容寻址——用 artifact 内容的哈希（如 SHA-256）作为 id 或校验字段，任何篡改都会导致哈希不匹配；2) 版本化——每个 artifact 有版本号，增量更新通过 artifact-update 事件携带 part 与版本，客户端可校验版本连续性；3) 数字签名——Agent 对 artifact 内容或其哈希签名，接收方用已知公钥验证签名，确认来源与完整性；4) 传输层完整性——通过 TLS 保证传输过程不被篡改；5) 存储溯源——把 artifact 哈希、签名与产生它的 Task/Agent 关联写进审计日志或不可变存储，形成可追溯链。不可篡改的本质是"内容哈希 + 签名 + 溯源记录"三者绑定，任何一环被破坏都能被检测到。

流水线中的 artifact 可能被多个 Agent 修改，若只存"最终值"则无法追溯谁改了什么。内容寻址 + 版本化 + 签名让每一个中间状态都可验证，审计时能定位到具体 Agent 与时间点。

• 理解 A2A 与 MCP 的抽象层级差异
• 理解"Agent 间"与"Agent-工具"两个正交维度
• 理解组合链路中如何划分职责边界

正交性源于二者的抽象对象不同。A2A 解决的是"Agent 之间如何发现、协商、执行并同步任务"，其粒度是异步长任务与状态机；MCP 解决的是"Agent 如何调用工具、访问资源与提示词"，其粒度是同步工具调用。一个 Agent 可以既是 A2A 的参与者（作为对等方被其他 Agent 调用），又是 MCP 的客户端（调用底层工具）。组合链路中划界的原则是：当能力是一个可独立完成任务、需要协商与状态管理的对等实体时，暴露为 A2A Agent；当能力是一次性、确定性、短平快的工具调用时，暴露为 MCP 工具。例如主 Agent 通过 A2A 委托研究 Agent 完成一个调研任务，而研究 Agent 内部通过 MCP 调用搜索工具与数据库工具。A2A 是"编排层"，MCP 是"能力层"，两者叠加构成完整调用链。

划界的关键是"任务 vs 工具"的语义。工具适合"确定性、原子、可快速返回"的操作；Agent 适合"需要推理、多步、状态化"的协作。把工具伪装成 Agent 或反之都会带来不匹配的抽象与过高的开销。

• 理解能力匹配（skills schema 与输入输出契约）
• 理解版本兼容（协议版本、binding 版本、扩展版本）
• 理解信任决策（白名单、签名、来源、风险分级）

面对未知 Agent Card，调用方应执行三步决策：1) 能力匹配——检查卡片声明的 skills 是否包含所需能力，校验输入/输出 schema 是否与调用契约匹配，避免把不兼容的参数传给对方；2) 版本兼容——核对协议版本（A2A v1.0）与 binding 类型（JSON-RPC/HTTP、gRPC、HTTP+JSON）是否受支持，检查扩展版本是否在兼容范围内，对不支持的版本降级或拒绝；3) 信任决策——对未知卡片先做风险分级：若卡片有有效签名且信任锚在可信集合内，可按其声明的能力调用；若签名缺失或来源不可信，则拒绝、或仅允许只读/低风险操作、或走人工审批。信任决策应默认"拒绝未知"，而非"接受未知"，除非有可验证的信任依据。

未知即"不可信"是安全默认。能力/版本匹配解决"能不能调用"，信任决策解决"该不该调用"。三者结合，调用方才能在不熟悉的对等方面前既安全又可用。

• 理解权限继承的越权风险
• 理解最小权限与逐跳收缩
• 掌握 delegated token / scope 缩减的传递机制

终端用户授权不能自动继承上游，因为用户只对发起请求的 Agent 明确授权，下游 Agent 不属于用户授权范围；自动继承会导致权限随调用链指数级扩散，放大越权与数据泄露面，且无法追踪"谁在用什么权限访问了什么"。最小权限传递机制包括：1) 逐跳收缩 scope——每一跳把授权范围缩小到完成本跳所需的最小集合；2) 使用 OAuth Token Exchange（RFC 8693）把当前 token 换成受限的 delegated token，声明 subject、audience、scope 与不可再传递（delegation 限制）；3) 声明能力边界（capabilities）与数据范围（data scope），下游只能访问其任务所需的数据；4) 传递时携带调用链（call chain）与意图，供审计与治理。核心原则是"权限只减不增，且每跳显式声明"。

把授权当作可传递的票据，会让攻击者只需攻破链路末端信用最低的 Agent 就能获得上游权限。逐跳收缩把"权限衰减"变成协议的一部分，即使某跳被攻破，危害也被限制在局部。

• 理解 A2A 的任务级抽象与 MCP 的工具级抽象差异
• 理解选择依据：状态、时长、协商、信任何
• 理解二者组合使用的场景

选择依据是"调用的抽象需求"。使用 MCP 的场景：能力是确定性、原子、短时长的工具调用（如查询、写入、API 调用），返回即完成，无需状态机与协商，Agent 需要把工具暴露给 LLM 并发起同步调用。使用 A2A 的场景：能力是独立、异步、长时、多步、需要状态跟踪与协商的"任务"（如委托一个 Agent 完成调研、生成报告、处理流程），需要 artifact 与状态管理、可能跨组织。当一致性：工具调用用 MCP 提供，任务协作用 A2A 编排；一个 Agent 可以同时是 MCP 客户端（消费工具）和 A2A 端点（被当作对等任务）。判断口诀：短、确定、原子 → MCP；长、异步、需协商 → A2A。

用错边界会带来成本：把工具抽象成 Agent 会引入不必要的状态与协商开销；把 Agent 任务强制做成工具调用又会丢失异步与状态能力。正确划分让每个抽象都落在适合的粒度上。

• 理解安全默认与 fail-closed 原则
• 理解 TLS 与身份验证缺失的风险
• 掌握快速失败的落地策略

当无法建立 TLS（如证书无效、域名不匹配、协议被降级）或端点缺少身份验证时，调用方应遵循 fail-closed（快速失败）原则：在发起任何任务前就拒绝调用，并记录安全告警，而不是降级为明文或匿名调用。具体做法：1) 校验 TLS 证书链、hostname 与过期时间，不通过一律拒绝；2) 若卡片声明需要认证但端点不支持，拒绝调用；3) 对"强制 TLS/认证"的调用路径，不提供"降级到明文"的选项；4) 触发失败时记录原因（证书问题、缺失认证、版本不兼容）供审计。快速失败的意义在于，把安全故障暴露在调用最早期，避免在信任被破坏的基础上继续执行任务造成数据泄露或损坏。

"信任"是建立起来的，而不是默认的。fail-closed 意味着在安全前提不满足时宁可拒绝也不冒险，这比"勉强可用但不可信"更符合企业安全目标。快速失败同时加快了故障定位，因为错误发生在调用边界而非深层执行中。

• 理解超时（timeout）与取消（canceled）的概念区别
• 理解状态机中如何表达超时
• 理解二者对客户端后续动作的影响

"明确取消"是协作方主动发起取消，状态进入 canceled，语义是对方向 Agent 明确表示"不再需要此任务"，是一个被显式触发且可记录的终态。"超时未响应"是客户端在约定时间内未收到任何状态更新或终态，属于"对方未响应"的失败情况，协议中通常不直接映射为 canceled，而是由客户端本地检测超时并通过 task/cancel 主动取消，或标记为超时待处理。语义差异在于责任归属：canceled 是主动、协作、可预期；超时是被动、异常、可能由对方故障、网络或慢任务导致。因此客户端对超时可以先发 task/cancel 尝试优雅终止，再根据响应决定是重试、降级还是上报；而对明确取消则直接清理并记录，无需重试。

混淆二者会导致错误的重试或错误的责任判定。超时更像"不知道对方状态"，需要先探测（cancel）再决策；canceled 是"已明确终止"，不应再触发重试。区分二者的本质是"是否知道对方意图"。

• 理解 E2EE 在协议层与应用层强制的差异
• 理解密钥管理、性能与互操作性的取舍
• 理解合规与安全需求

E2EE 放在协议层强制能保证端到端加密成为默认行为，避免应用层遗忘或误用，安全一致性高，但会增加协议复杂度、密钥管理负担与性能开销，并可能阻碍第三方互操作（密钥交换、身份绑定复杂）。放在应用层选择则灵活，允许不同部署按需启用加密、叠加在协议之上，但容易因配置遗漏而出现明文传输，安全一致性弱。折中做法是：协议层面保证传输层安全（TLS in transit）为强制默认，而 E2EE 作为可选但推荐的能力，由应用层在敏感数据场景显式启用并统一封装。取舍依据是威胁模型与合规要求：涉及高敏感数据或跨组织边界时，应把 E2EE 提升为强制或半强制；对内部低敏感任务，可依赖 TLS + 应用层可选加密。

强制能给"安全默认"，可选能给"灵活契约"，没有绝对答案。关键是把决策显式化：协议规定底层默认安全，应用层按数据分级决定是否叠加 E2EE，并保证可审计、可配置。

• 理解注册中心的集中式治理与去中心化发现（DID/ENS）的差异
• 理解两者的适用场景与信任模型
• 理解两者可组合

注册中心是集中式目录，由运营方维护 Agent 列表、准入审核、能力核验与吊销，适合企业内网、受管生态或需要集中治理与 SLA 的场景——它提供强信任锚、易审计、可下架，但引入单点与准入依赖。去中心化发现（DID、ENS）依赖分布式账本或区块链域名，Agent 通过 DID 文档或 ENS 记录自证身份，无需中央目录，适合开放、跨组织、需要抗审查与自托管身份的生态，但发现与治理较弱、吊销传播有延迟。适用场景：注册中心适合"需要准入、审核、责任归属"的受控环境；去中心化发现适合"开放网络、无单一权威、强调自主权"的场景。二者可组合：注册中心维护可信清单，DID 作为 Agent 的可验证身份锚，卡片用 DID 锚定提升可信度。

选择取决于信任模型：你信"一个权威目录"还是信"多个自证身份"。注册中心把信任集中，去中心化把信任分散到密码学与账本。成熟企业生态常两者结合，用 DID 提供身份、用注册中心提供准入与治理。

• 掌握 task/send 方法的作用与参数
• 掌握 artifact 与 TaskState 的定义
• 理解三者构成任务生命周期

A2A v1.0 的核心对象是 Task：task/send 是客户端向 Agent 提交任务的方法，携带 message（含 role、content、contextId 等）并返回 Task 或 TaskStatusUpdate；TaskState 描述任务生命周期状态（submitted/working/input-required/auth-required/completed/failed/canceled/rejected），是任务当前阶段的权威表示；artifact 是任务产出物，可多版本、可带 part，通过 artifact 相关事件流式传递。三者协作：task/send 创建任务并初始化状态，随后状态经 status 事件推进，产出物经 artifact 事件逐步交付，客户端通过 task/get 或订阅事件观察状态与 artifact，最终收敛到终态。Task 是"生命周期 + 状态 + 产出的容器"，task/send 是入口，TaskState 是导航，artifact 是结果。

这三个概念构成 A2A 的"动词-名词"骨架：send 是动词（发起），TaskState 是名词（状态），artifact 是名词（产出）。理解它们的关系是理解 A2A 一切高层能力的基础。

• 理解跨 Agent 数据一致性与数据漂移问题
• 理解外部记忆存储作为权威事实源的角色
• 理解 contextId、artifact 与快照的协同

跨 Agent 数据漂移源于各 Agent 各自维护状态、缺乏统一事实源。A2A 通过 contextId 把同一逻辑会话的多个任务关联起来，客户端用 contextId 传递一致上下文；同时把任务相关数据以 artifact 形式存到外部记忆存储（如向量库、KV 存储、对象存储），作为共享的权威事实源。各 Agent 在需要时从记忆存储读取最新快照，而非依赖各自缓存，从而避免漂移。具体机制：任务提交时携带 contextId，服务端基于 contextId 历史决定是延续还是新建任务；产出物写回记忆存储并记录版本；Agent 读取前校验版本，避免使用过期数据。外部记忆存储充当"单一事实源"，A2A 只负责编排与传输，二者配合让跨 Agent 数据收敛且可追溯。

协议本身不解决"数据放哪"，它解决"如何关联与传输"。数据漂移的根治是把事实源外置，让所有 Agent 读同一份权威数据，A2A 的 contextId 与 artifact 保证关联与版本一致。

• 理解跨云迁移中版本一致性的风险
• 理解版本治理与兼容性测试机制
• 理解灰度回滚与契约基线

跨云迁移时，两个云环境的 A2A 实现版本可能不一致，回退到旧版本会引发兼容性回归。治理机制包括：1) 版本基线——把 A2A 协议版本、binding 版本与扩展版本作为契约基线固化，迁移前对齐；2) 契约测试——对 Agent Card、状态机与流事件做 conformance/契约测试，作为迁移前后的门禁；3) 灰度滚动——逐步迁移流量，迁移中同时保留新旧版本并做双跑对比，检测回归；4) 统一版本管理——用配置中心或发布管线统一各环境版本，避免漂移；5) 回滚预案——回滚时同步回退 Task 状态与 artifact 版本，避免半成品状态泄漏；6) 兼容性策略——明确"向后兼容字段只增不删"的扩展规则，使新版本可被旧版本容忍。治理的核心是把"版本"当作一等公民治理对象，而非放任各环境自动更新。

跨云迁移的回归常来自隐性版本漂移，而非显式缺陷。把版本契约化、测试化、灰度化，能在迁移过程中及早检出并控制回退风险。

• 理解注册中心提供可信目录
• 理解心跳保活提供活性检测
• 理解 mTLS 提供双向身份认证

三者分别覆盖发现路径的不同环节：注册中心提供可信的 Agent 目录与能力清单，保证"发现到的是可信实体"；心跳保活（heartbeat/health check）让注册中心与客户端持续感知 Agent 存活状态，剔除失效或降级的条目，保证"发现到的路径可用"；TLS 双向认证（mTLS）在建立连接时双向验证身份，保证"发现的实体确实拥有对应证书"，防止中间人与身份伪装。三者叠加，形成"目录可信 + 存活可靠 + 身份可验"的完整发现路径，且互相制约：即使目录被污染，mTLS 也能阻止伪造身份；即使证书存在，心跳也能发现服务不可用。抗降级体现在任一层失效时调用方应 fail-closed 而非降级信任。

发现路径的完整性 = 可信目录（发现）+ 活性检测（存活）+ 身份认证（连接）。缺一环都会被攻击者利用：目录可信但服务已死、身份可信但目录被污染、连接安全但身份伪造。三者协同才能抗降级。

• 理解回滚时状态与数据的一致性
• 理解 Task 状态与 artifact 版本的事务性回退
• 理解半成品状态泄漏的风险

灰度回滚时，若只回退代码而不同步回退 Task 状态与 artifact 版本，会出现"新版本已写入的 artifact + 旧版本状态机"的不一致，造成半成品状态泄漏。解决方案：1) 版本化 + 原子提交——把 Task 状态与 artifact 版本放入同一事务单元，回退时按版本快照整体还原，避免状态与数据分离；2) 状态快照——定期对 Task 状态与 artifact 版本建立快照，回滚时恢复到最后一致点；3) 回滚标记——回滚后对受影响 Task 打标记，使其进入 canceled/failed 而非停留在半成品状态，并清理尚未提交的 artifact 增量；4) 拒绝不一致——在状态机与 artifact 版本不匹配时拒绝继续执行，触发重试或回滚。核心是"状态与数据必须同生共死"，回退要作为一个原子操作，否则客户端会读到"状态说完成但 artifact 缺失"的矛盾。

半成品泄漏的根源是状态与数据分属不同生命周期。把二者纳入同一版本与事务，回滚即整体回退，就消除了"状态与内容不一致"的读窗口。

• 掌握三类传输 binding 的差异
• 理解流式 artifact 与 message/stream 的关系
• 理解 gRPC 的适用场景

流式 artifact 投递需要持续推送增量，最适合使用支持双向流或 SSE 的 binding。JSON-RPC 2.0 over HTTP 配合 SSE 可以推送流式事件（status/artifact 增量），是 A2A 默认的流式路径；若需要高吞吐、双向流、强类型与低延迟，则使用 gRPC 的 server-streaming/bidi-streaming。message/stream 是 A2A 面向消息的抽象（Message、Part、Stream），而 binding 是底层传输实现；SSE 直接把 message/stream 的增量事件编码为事件流，gRPC 则把 Part 映射为 protobuf 消息流。必须使用 gRPC 的场景包括：需要双向流式交互（Agent 与 Agent 同时持续收发）、高吞吐二进制数据、强类型契约（protobuf schema）、低延迟实时协作，以及企业已有 gRPC 基础设施。对简单一问一答或单向推送，JSON-RPC/SSE 更轻量。

binding 是"怎么传"，message/stream 是"传什么"。流式 artifact 需要持续推送，SSE 提供单向推送、gRPC 提供双向流与二进制高效。选型取决于吞吐、双向性与类型需求。

• 掌握 .well-known/agent.json 发现机制
• 理解多层签名链的验证顺序
• 理解验证失败时的降级策略

客户端通过 /.well-known/agent.json 获取 Agent Card，然后按签名链自下而上验证：1) 卡签名——用 Agent 的公钥验证卡片内容签名，确保证书未被篡改；2) 注册中心签名——若卡片被受信注册中心背书，用注册中心公钥验证其签名，确认卡片经过了可信者准入；3) 可选 DID 锚定——若卡片有 DID 身份，用 DID 文档的验证方法锚定公钥，确认身份与加密密钥绑定。验证失败时的优雅降级策略：不静默信任，而是按信任级别降级——签名无效则拒绝调用；注册中心签名缺失则标记为"未背书"而仅允许低风险/只读操作；DID 锚定失败则降级为"不验证身份"但继续依赖传输安全并告警。降级应显式告警、记录决策、并限制能力范围，绝不能当成可信卡片直接使用。

多层签名链把"卡片内容"与"可信实体"绑定起来。验证失败时，降级不是"当作成功"，而是"降低信任等级并限制能力"，同时保留审计痕迹。这样既不失可用性，也不放松安全。

• 理解 SSE 事件流中任务的顺序与终止条件
• 理解增量 artifact 的渲染与进度
• 理解客户端如何收敛最终状态

SSE 事件流中，事件按发生顺序推送，包括 status-update 与 artifact-update 等 kind。客户端按 messageId 排序并去重，跟踪状态推进；终止条件为收到终态事件（completed/failed/canceled/rejected）或 stream 关闭且有状态收敛。进度渲染上，客户端订阅事件流，把 status 变化显示为进度条/阶段，把 artifact 增量（part 或追加内容）渐进渲染到 UI，用 messageId 保证顺序。流结束前客户端应调用 task/get 或等终态事件确认最终状态，避免以中间态收尾。客户端还应处理断线重连，用 Last-Event-ID 或游标补齐，并在终态后停止渲染更新。

流式渲染的核心是"增量推进 + 终态收敛"。SSE 提供顺序推送，但客户端仍需处理乱序、重放与断线，因此以 messageId 归序、以终态为准。进度是状态驱动的，内容来自 artifact 增量。

• 理解 auth-required 与 input-required 的语义差异
• 理解两种恢复流程的本质区别
• 理解避免混淆死循环的方法

auth-required 表明"授权不足或过期"，客户端应重新发起 scoped OAuth 授权流程（如 OAuth2 授权码或对现有 token 做 token exchange 获取新 scope），换取新的访问令牌后重发任务；input-required 表明"参数不完整"，客户端应补全缺失参数（如补充上下文、字段）后重发。本质差异：auth-required 是"身份/权限问题"，input-required 是"数据/参数问题"，恢复动作完全不同——一个是换 token，一个是补参数。避免混淆导致死循环：1) 客户端严格按状态分类处理，auth-required 绝不当作"补参数"重发（否则会反复触发同一状态）；2) 对每种状态设置重试上限，超过则失败并上报；3) 跟踪重试轮次与状态转移，检测"在同一状态反复往返"的循环；4) 用任务上下文区分是否需要用户介入（如重新登录）还是程序化补全。

混淆二者的危害是死循环：客户端把 auth-required 当作 input-required，反复补参数重发，却永远拿不到 token，任务卡死。正确做法是按状态语义匹配恢复动作，并对循环设置熔断。

• 理解 contextId 与 taskId 的语义差异
• 理解创建新任务与延续任务的判断条件
• 理解服务端基于 contextId 历史的决策逻辑

taskId 标识一次具体任务，contextId 标识一组相互关联的任务（同一会话/业务上下文）。同一 contextId 下，若后续 message/send 携带相同 taskId，则延续该任务（同一任务追加输入/继续执行）；若携带新的 taskId（contextId 相同但 taskId 不同），则创建新任务，但共享该 contextId 的上下文历史。服务端决策：根据 contextId 查询历史任务序列，若存在未完成且匹配的任务则延续，否则新建；同时结合请求中的 taskId 判断——客户端显式复用 taskId 表示延续，换新 taskId 表示新一轮。延续用于"同一任务的迭代/补充"，新建用于"同一会话下的新任务"。服务端应基于 contextId 历史的一致性（如任务序列、上下文版本）决定是否允许延续，避免跨会话混用。

contextId 是"会话"，taskId 是"任务"。"延续"与"新建"通过 taskId 是否复用区分，contextId 提供共享上下文。服务端用 contextId 历史来校准"这个新任务是否属于同一关联组"。

• 理解 timestamp + nonce 反重放机制
• 理解拒绝窗口的选取与权衡
• 理解签名验证与窗口的关系

A2A 推荐用"签名 + timestamp + nonce"三元组防重放：请求头携带签名（HMAC/JWS）、timestamp 与 nonce；回调端先验证签名，再检查 timestamp 与当前时间偏差是否在允许窗口内（规范建议如 ±5 分钟），并用 nonce 作幂等去重（同一 nonce 只接受一次）。窗口大小是权衡：窗口过大增加重放攻击窗口，窗口过小会因时钟偏差/网络延迟误拒合法请求。±5 分钟是常见平衡，适合多数云环境（NTP 同步后时钟偏差小）。对高安全场景可收紧到 ±1 分钟，对容忍时钟偏差的跨互联网场景可放宽但配合 nonce 一次性使用来兜底。窗口内再叠加 nonce 去重，即使重放落在窗口内也会被 nonce 拦截。

timestamp 限制"时效"，nonce 保证"一次性"，签名保证"内容可信"。拒绝窗口是"时效边界"，配合 nonce 即使攻击者在窗口内重放也会失败。窗口大小应结合时钟同步与安全要求设定。

• 理解 authentication 与 authorization 的区分
• 理解逐跳权限收缩与链式授权
• 掌握 OAuth Token Exchange（RFC 8693）的衰减模式

B 不应反向继承 A 的全部权限。authentication 只证明"A 是谁"，authorization 才界定"代表哪个用户、能做什么"。A → B 的链式调用中，用户只对 A 授权，B 是在 A 的授权范围内被委托，应只获得 A 权限的一个子集（衰减）。衰减模式基于 OAuth Token Exchange（RFC 8693）：A 用现有 token 调用 token exchange，请求生成一个受限的 delegated token，其中 subject 仍指向原用户、audience 指向 B、scope 收缩到 B 完成本跳所需的最小集合，并可通过自定义声明（如 delegation 限制、max_ttl、call_chain）规定"不可再委托他人"或"只能用于特定资源"。这样 B 只看到和使用一个窄 scope 的 token，无法访问 A 的其他权限。逐跳都执行同样的衰减，授权随调用链逐级收缩，越深权限越窄。

RFC 8693 的 token exchange 提供"把现有 token 换成受限 token"的标准机制，正是逐跳衰减的载体。核心约束是"只减不增 + 不可无限再委托"，从机制上防止低信任 Agent 借上游身份越权。

• 理解 ETag/Last-Modified 与 TTL 的缓存机制
• 理解密钥轮换时的缓存失效
• 理解防止过期 skills 与认证方案的方法

基础缓存用 ETag/Last-Modified 做条件请求（304 校验），配合 5–15 分钟 TTL 减少拉取。但密钥轮换会破坏缓存有效性：若卡片中的公钥/签名已换，缓存里仍是旧卡。主动失效策略：1) 轮换时发布新卡片并更新版本号/ETag，客户端用条件请求立即发现内容变化；2) 客户端对卡片中的签名密钥做校验，若验证失败且签名算法/密钥与缓存不匹配，则强制重新拉取；3) 缩短 TTL 或对高信任场景做"变更观察"（订阅变更通知）；4) 校验 skills 与 authentication.schemes 的版本，使用过期方案时拒绝并刷新；5) 缓存失效时先验证新卡签名再替换，防止用旧密钥验新卡。原则是"缓存用于性能，验证用于安全"，密钥相关变化必须即时反映。

缓存过期与安全失效是两回事。签名密钥轮换涉及信任，必须能在 TTL 内被主动发现。条件请求 + 版本号 + 签名校验组合，让缓存既高效又不陈旧。

• 理解 canceled 与 rejected 的语义差异
• 理解审计日志应保留的字段
• 理解 GDPR/PIPL 数据主体权利（删除、访问、更正）审计要求

canceled 与 rejected 虽都是终态，但责任与触发不同：canceled 是协作方主动中断（可能在任何阶段），rejected 是服务端明示拒收（通常发生在提交时）。审计日志为满足 GDPR/PIPL 数据主体权利（访问、更正、删除、可携带），应分别保留：通用字段——taskId、contextId、发起方与接收方身份、认证主体（subject）、发生时间、前状态、触发方（谁取消/谁拒收）、原因代码、相关消息与 artifact 引用、数据保留策略与删除标记。对 canceled 额外记录"取消时机、取消前已产生的数据范围、是否已删除中间数据"；对 rejected 额外记录"拒收原因、是否包含个人数据、是否立即删除"。关键是要能按数据主体（subject）检索所有相关任务，并支持对已删除/已保留的数据做出响应。审计日志本身也应遵循最小化与保留期限，不保留无关正文。

GDPR/PIPL 要求能按数据主体检索并响应权利请求。canceled/rejected 的审计字段要能证明"谁在何时出于什么原因终止"，同时能定位到该主体涉及的所有数据以便删除或提供。区分记录触发方与原因，是合规审计的关键。

• 理解推送与轮询的取舍
• 理解断线恢复机制
• 理解重复投递去重

webhook 推送：服务端在任务完成/状态变化时主动回调，实时性好、延迟低、省资源，但需要可公开访问的回调端点、处理签名验证、重试与 SSRF 防护。客户端轮询：客户端按周期调用 task/get 查询状态，实现简单、无需开放回调端口、防火墙友好，但延迟取决于轮询间隔、浪费资源、可能错过瞬时状态。取舍：实时性与低延迟选推送，简单性与防火墙友好选轮询；或用混合模式（状态变化推送 + 定期兜底轮询）。断线恢复：推送失败时发送方重试（指数退避、携带幂等键），客户端也可用 task/get 兜底拉取最新状态；轮询天然无断线问题，只需保证最终收敛。重复投递去重：推送可重试导致重复，客户端用事件 ID/幂等键去重，按 taskId 收敛最终状态，避免重复副作用。

推送与轮询是延迟与复杂度的权衡。断线恢复的关键是"最终一致性收敛"——无论推送还是轮询，最终都要通过 task/get 拿到权威状态。去重则用幂等键保证重复投递不产生重复副作用。