A2A 扩展协议与商业化生态

• 理解 AP2 与 Mandate 授权链
• 理解用户约束内的支付
• 理解应用层审计证据

AP2 是 Agent 之间进行支付交互的协议。Mandate（授权）是用户预先授予 Agent 的支付许可，用授权链（Mandate 链）表示"用户授权 Agent A，A 再授权下游 Agent B"，每一跳都带约束：授权范围（能买什么/什么用途）、金额上限（单笔/累计）、有效期、受益方与签署链。Agent 只能在这个约束内完成支付，超出即拒绝。应用层要保留的审计证据：1) 授权范围声明——用户授权允许的用途与限制；2) 金额上限——单笔与累计上限及执行情况；3) 签署链——每一个授权环节的签名（含用户签名、Agent 签名、时间戳），形成可验证的授权链条；4) 支付记录——每笔支付的金额、对象、时间、对应 task；5) 约束执行记录——是否在约束内、超限拒绝的日志。这些证据使"谁授权、授权什么、花了多少、有没有违规"都可审计，支撑对账与合规。

Mandate 授权链把"支付能力"与"用户约束"绑定，Agent 无法越权支付。审计证据的意义在于可追溯：授权链证明"合法性"，金额与范围记录证明"符合约束"，签署链证明"不可抵赖"。这对商业化与合规至关重要。

• 理解 DID/VC 身份与信任锚
• 理解证书轮换与吊销传播
• 理解信任运营体系

跨组织身份运营：用 DID 作为 Agent 的去中心化身份，用可验证凭证（VC）承载身份属性与信任锚，Agent Card 以 DID 为锚签名。运营要点：1) 信任锚——确定可信的根（如注册中心、DID 组织），Card 签名链最终锚定到可信根；2) 证书轮换——定期轮换签名密钥，轮换时发布新 DID 文档/Card 并更新版本，旧密钥保留一定宽限期以平滑过渡；3) 吊销——吊销时通过注册中心更新、DID 文档的验证方法移除、或发布吊销列表（CRL/status list），让调用方及时感知；4) 传播——调用方通过缓存 TTL + 条件请求 + 吊销检查及时获取最新状态，避免用过期的信誉。关键是"信任锚要稳定、轮换要平滑、吊销要即时可见"，调用方在验证时必须同时检查签名、有效期与吊销状态。

跨组织信任的关键是"身份可验证 + 状态可更新"。DID/VC 提供可验证身份，但信任会随证书轮换与吊销变化。运营上的核心是"让信任状态的变化及时到达调用方"，否则信任锚会失效。

• 理解 AG-UI 与 A2A 的职责差异
• 理解用户-交互与 Agent-间协作的分界
• 理解串联成完整链路

AG-UI（Agent-User Interaction）面向"Agent 与用户之间的交互"，定义交互控件、消息渲染、用户确认/输入采集等界面语义；A2A 面向"Agent 与 Agent 之间的任务协作"，定义任务、状态、artifact 等后端语义。职责边界：AG-UI 管"用户界面层"，A2A 管"Agent 间协作层"。二者串联成完整链路：用户通过 AG-UI 与前端 Agent 交互（发送意图、接收进度、确认授权），前端 Agent 通过 A2A 把任务分派给后端 Agent 协作，后端 Agent 的结果再经 AG-UI 呈现给用户。AG-UI 处理"人与 Agent 的交互呈现"，A2A 处理"Agent 间的任务流转"，两者互补，构成从用户到 Agent 再到 Agent 的完整链路。

AG-UI 与 A2A 是"两个侧面"：AG-UI 解决用户看得见、可交互的部分，A2A 解决 Agent 之间看不见的协作。分离职责让双方各自标准化，组合在一起构成完整的人机 Agent 协作链路。

• 理解任务协商的标准化
• 理解约束（能力、预算、截止时间）传递
• 理解失败降级

任务协商是把"意图 + 约束"标准化为可交换的契约：1) 意图——用结构化任务描述（目标、输入、期望输出）表达"要做什么"；2) 能力边界——声明 Agent 能做什么、不能做什么，协商时校验能力匹配；3) 预算——协商 token/费用预算，双方确认成本范围；4) 截止时间——协商 deadline，双方确认时间约束。标准化协商流程：发起方提出任务提案（含约束），被调方评估自身能力/资源后接受、拒绝或提出修改（如调整预算/时间），达成共识后执行。失败时优雅降级：1) 能力不匹配——拒绝或推荐替代 Agent；2) 预算超限——降级为简化方案或缩小范围；3) 时间不足——返回部分结果或延长协商；4) 协商失败——返回明确错误，交由调用方决定重试/换 Agent/人工。核心是"共识明确的约束 + 失败的显式降级路径"。

协商把"说不清的任务"变成"有明确约束的契约"，避免执行中的歧义。失败降级保证了即使协商不成功，也有明确的后续路径，而不是无限重试或静默失败。

• 理解 well-known 端点与目录服务发现
• 理解能力校验
• 理解签名与吊销校验

Agent 发现机制：1) well-known 端点——客户端请求 /.well-known/agent.json 获取 Agent Card，直接获得能力、端点与认证信息；2) 目录服务——客户端从注册中心/目录查询 Agent 列表，按能力、SLA 筛选，再获取卡片。校验能力：检查卡片声明的 skills 是否匹配所需能力、schema 与版本是否兼容。校验签名：用信任锚（注册中心公钥 / DID 验证方法）验证卡片签名链，确认来源可信。校验吊销状态：检查 Agent 是否在吊销列表（CRL/status list）、注册中心是否已下架、证书是否在有效期内，防止使用已吊销的身份。发现 + 校验的完整流程：发现 → 获取卡片 → 校验来源与签名 → 校验吊销 → 校验能力 → 才可调用。核心是"发现之后必须校验能力、签名与吊销，不能只凭发现就信任"。

发现只是"找到"，校验才是"信任"。well-known/目录解决"能不能找到"，签名解决"是不是可信的"，吊销解决"是否仍有效"。三层合一，发现路径才可信。

• 理解多跳成本分摊
• 理解配额与对账
• 理解防止成本转嫁

多跳调用链上，成本会沿链累积，需明确分摊与对账：1) 成本归因——每跳记录 token/费用/配额消耗，关联到具体调用方与 task，形成成本链；2) 配额——每跳有独立配额（调用方对被调方设配额），避免上游 Agent 无限消耗己方资源；3) 预算预检——每跳在调用前校验预算，超限拒绝而非无条件执行；4) 对账——事后按调用链对账，核对每跳的消耗与费用，发现异常（超量、重复计费）即处理；5) 防止成本转嫁——上游 Agent 不能把成本转嫁给下游，通过"预算预检 + 配额 + 计费归属"约束，每跳成本由发起方承担或协商分摊，防止"上游用光下游配额"。核心是"每跳成本可归因、有配额、可对账、可拦截转嫁"。

多跳链的成本是"累积 + 可转嫁"的，风险是上游把成本推给下游。预算预检 + 独立配额 + 对账，让每跳成本清楚归属，异常可拦截，转嫁可检测。

• 理解市场/注册中心的治理流程
• 理解准入审核、能力核验、投诉下架
• 理解风险控制

市场/注册中心治理应覆盖 Agent 全生命周期：1) 准入审核——Agent 上架前审核身份（DID/签名）、资质、来源与安全声明，通过后才进入列表；2) 能力核验——核验 Agent 声明的能力是否真实（如运行测试用例、验证端点），防止虚假能力；3) 持续监控——运行期监控 Agent 的行为（成功率、异常、越权），发现异常即标记；4) 投诉下架——建立投诉机制，举报恶意/违规 Agent，核实后下架并吊销其信任；5) 撤销传播——下架/吊销后同步到吊销列表，让调用方不再信任。原则：默认不信任，上架需审核，行为需核验，违规可下架。核心是"把信任做成有门槛、可撤销的流程"，防止恶意 Agent 混入发现列表并长期伪装。

市场治理的难点是"恶意 Agent 会伪装成良性"。准入审核设门槛、能力核验拆穿虚假、持续监控与投诉下架提供撤销机制，让恶意 Agent 既难进入、也难长期存在。

• 理解预算预检
• 理解事后对账
• 理解防止意外账单

防止长任务意外账单：1) 预算预检——调用前根据 Agent 的定价/能力预估费用，与己方预算比对，超预算则拒绝或提示用户确认；2) 上调价上限——协商时约定单任务/单次调用的费用上限，超出即终止；3) 实时监控——执行中实时累计费用，接近阈值预警，超限熔断；4) 事后对账——任务完成后按实际用量（token、调用次数、时长）对账，核对账单与预估、拒绝异常收费；5) 限额——设置累计配额与通知，防止多个长任务叠加失控。长任务风险在于"执行时间长导致费用累积"超出预期，因此要"事前预算 + 事中熔断 + 事后对账"三管齐下。核心是"费用可预期、可监控、可对账，避免意外账单"。

按调用计费的长任务，账单一事后才到，若无预检与熔断，费用可能失控。预算预检 + 费用上限 + 实时熔断 + 事后对账，让费用在可控范围内，异常可申诉。

• 理解扩展协议版本兼容
• 理解向后兼容原则
• 理解旧客户端的新扩展容忍

扩展协议版本兼容遵循"向后兼容 + 引擎容忍"原则：1) 字段只增不删——新扩展新增字段/能力，不修改或删除旧字段，旧客户端能忽略未知字段继续工作；2) 语义向后兼容——新扩展不改变旧消息的语义，只是新增行为；3) 能力声明——通过能力协商（capabilities 字段）声明支持哪些扩展，双方按"对方是否声明支持"决定是否启用，而不是假定所有客户端支持；4) 优雅降级——旧客户端遇到新扩展字段时忽略并走旧路径，不因未知字段崩溃；5) 版本协商——用版本号协商，双方取最小公共版本或随能力字段降级。旧客户端不崩溃的关键是"解析器容忍未知字段 + 能力协商 + 默认降级"，把新扩展当作"可选增强"而非"必需依赖"。

扩展兼容的经典做法是"契约内聚性 + 未知容忍"。新扩展必须是增量、可选、向后兼容的，旧客户端通过忽略未知字段与能力协商优雅降级，从而在不同版本间平滑互操作。

• 理解 A2A 与 MCP 的通信对象
• 理解 Agent 间与 Agent-工具的分界
• 理解二者在架构中的角色

A2A 与 MCP 的通信对象不同：A2A 是"Agent 间通信"，连接两个对等 Agent，协商任务、交换状态与 artifact，粒度是任务级；MCP 是"Agent-工具通信"，连接 Agent 与工具/资源/提示词，粒度是工具调用级。在架构中：A2A 是水平协作层（Agent 找 Agent），MCP 是垂直能力层（Agent 找工具）。现实系统中，一个 Agent 通过 A2A 与另一个 Agent 协作，同时通过 MCP 调用底层工具。二者不冲突、可组合：A2A 负责"谁帮我完成这个任务"，MCP 负责"用什么能力完成这一步"。区分标准是"通信对象是另一个 Agent 还是工具"以及"是任务级还是调用级"。二者互补构成"Agent 间协作 + Agent-工具执行"的完整生态。

一句话区分：A2A"Agent 找 Agent"，MCP"Agent 找 Tool"。二者通信对象不同、粒度不同，因此互补而非替代。理解这个分界是架构设计的基础。

• 理解 SLO 定义（可用性、响应时间、成功率）
• 理解罚则设计
• 理解责任边界

商业化 Agent 的 SLO 需分层定义：1) 可用性——服务可用率（如 99.9%），衡量 Agent 端点可被调用；2) 响应时间——首次响应/完成时延（如 p95），衡量及时性；3) 任务成功率——端到端任务完成率与质量达标率，衡量有效性。定义时需明确测量口径（范围、时间窗、排除项）。罚则：按 SLA 违约程度设计（如可用性不达标按比例退款、响应超时补发配额、成功率不达标提供重试/退款），但罚则要"可验证、有上限、不惩罚不可控因素"。责任边界：区分"服务方责任"（可用性、合规、错误）与"调用方责任"（输入质量、前置条件、超限使用），以及"第三方/不可抗力"免责。SLA 要把"谁负责、测量什么、违约怎么罚"写清楚，避免争议。核心是"可测量的 SLO + 有边界的责任 + 可执行的罚则"。

商业化 SLA 的关键是"可观测、可归责、可执行"。SLO 要能量化测量，责任要清晰划分，罚则要能触发。模糊的 SLA 会让供需双方争议，明确的 SLA 才能支撑真实交易。

• 理解按结果付费的计费模式
• 理解质量不达标的处理（费用、重试）
• 理解责任边界

按结果付费下，质量不达标需明确处理：1) 质量判定——定义客观的质量标准（自动化评测/验收标准），不达标即触发处理；2) 费用——不达标时按约定处理：不收费、部分退款、或免费重试一定次数，避免"为失败买单"；3) 重试——允许有限次重试（如 1-2 次），重试不达标则升级人工或终止并退款；4) 责任边界——区分"Agent 责任"（输出质量差、工具错误）与"调用方责任"（输入不完整、需求矛盾、前置条件错），只有 Agent 责任才触发费用减免；5) 争议处理——质量判定有争议时提供证据与仲裁。核心是"质量标准可量化 + 费用与质量挂钩 + 重试与退款有边界"，让"按结果付费"真实落地。

按结果付费的前提是"结果可判定"。质量不达标时，费用、重试、责任要清晰联动：质量差→不收费/退费/重试，且只对 Agent 责任负责。这样既保护调用方，也避免责任模糊。

• 理解任务终态与结算的关联
• 理解退款与争议处理
• 理解状态驱动的结算

结算应由任务状态驱动：1) 状态与结算映射——completed 才计费；failed 不收费或按部分退款；canceled 按已发生成本结算或退款；2) 退款联动——任务 failed/canceled 时自动触发退款流程，按已完成比例或全额退款，并记录原因；3) 争议处理——客户端对账单有异议时，依据任务状态、trace 与审计记录核实，确认责任后调整；4) 幂等——退款与结算用幂等键，避免重复扣款/退款；5) 审计——把"任务状态 → 结算 → 退款 → 争议"的完整链路留痕，供对账与合规。核心是"以任务状态为单一事实源驱动结算与退款"，避免"任务失败但账单照收"的争议。

结算与任务状态联动是"按结果计费"的落地。failed/canceled 触发退款与争议流程，状态 + trace + 审计提供核实依据，让结算公平、可追溯、可争议。

• 理解 A2A 标准扩展点
• 理解标准化程度
• 理解私有扩展的风险

A2A 的核心协议（task/send、状态机、artifact、Agent Card）已标准化，但技能发现、任务协商、结果共享等扩展点标准化程度不一：基础的 well-known 发现与能力声明已标准化，而高级协商语义、结果共享格式、私有元数据可能由各自实现。私有扩展带来互操作风险：1) 绑定——私有字段/格式让调用方依赖特定厂商，跨厂商无法协作；2) 兼容断裂——私有扩展间不兼容，A Agent 调 B Agent 时语义错位；3) 锁定——深度使用私有扩展后难以迁移；4) 安全——私有扩展未经标准化审核，可能引入安全缺陷。缓解：优先使用标准扩展点，私有扩展用"向外兼容"方式（不影响标准字段），并声明能力协商，避免把私有扩展当作必需。核心是"标准扩展打底、私有扩展可选，避免破坏互操作"。

标准化程度决定"跨厂商能否协作"。私有扩展虽灵活，却破坏互操作并引入锁定。正确做法是标准扩展点为主、私有扩展向后兼容且可选，从而兼顾创新与互操作。

• 理解计费口径设计
• 理解退款与争议
• 理解责任边界

支撑真实交易需设计三个层面：1) 计费口径——明确按什么计费（任务数、token、调用次数、结果质量），定义清晰、可计量、可核对的口径，避免歧义；2) 退款——定义完成/失败/取消/质量不达标时的收费与退款规则，与任务状态联动，用幂等保证对账准确；3) 责任边界——划分服务方与调用方责任、定义 SLA 与罚则、明确不可抗力与争议处理，让每笔交易的责任归属清晰。此外：4) 市场治理——Agent 市场做准入审核、能力核验与投诉下架，保障交易环境可信；5) 审计——完整的计费、退款、SLA 记录供对账与合规。核心是"计费可计量、退款有规则、责任有边界、市场有治理"，这样商业交易才可落地、可争议、可审计。

商业化要"可交易、可追责、可对账"。计费口径解决"怎么算钱"，退款规则与状态联动解决"不公平怎么办"，责任边界解决"出错谁负责"，市场治理解决"谁可信"。四者齐备才支撑真实交易。

• 理解身份认证、任务授权、数据最小化
• 理解防止权限提升
• 理解安全落地

防止跨 Agent 权限提升需三管齐下：1) 身份认证——用 mTLS、JWT、DID 验证调用方 Agent 身份，确保"谁在调用"可信；2) 任务授权——每跳用受限 scope（OAuth Token Exchange）授权，权限逐跳收缩、只减不增、限制不可再委托，防止低信任 Agent 借上游身份越权；3) 数据最小化——只传递完成任务所需的最小数据，不暴露无关数据，减少数据泄露面；4) 纵深防御——每跳独立验证声明、能力与上下文，配合审计与监控，发现越权即阻断。防止权限提升的关键是"身份与授权分离 + 逐跳收缩 + 最小数据"，让某一跳被攻破时无法获得全局权限。核心是"认证可信、授权最小、数据最少、审计可查"。

跨 Agent 权限提升的根因是"身份合法即被当作有全部权限"。把身份认证（是谁）与授权（能做什么）分离，并逐跳收缩 + 数据最小化，就限制了攻击者借身份越权的空间。

• 理解各框架对 A2A 的支持
• 理解成熟度评估维度
• 理解生态演进

评估主流框架对 A2A 的支持程度与成熟度，需看：1) 协议实现——是否实现了 A2A server/client（task/send、Agent Card、流式事件）；2) 集成深度——是否作为一等公民（如 ADK 原生支持 A2A、LangGraph/AutoGen 通过扩展/适配器支持）；3) 文档与工具——是否有官方文档、示例、conformance 测试；4) 社区活跃度——issue/pr、版本更新、采用案例；5) 生产就绪度——是否有生产部署、稳定性、生态工具。评估方法：对照 A2A conformance 测试跑各框架，验证哪些能力通过；用官方示例与 POC 验证真实可用性；关注官方对 A2A 的路线图承诺。现状：Google ADK 等原生支持 A2A，LangGraph/AutoGen/CrewAI 等通过适配器或扩展逐步接入，成熟度在演进中。核心是"用 conformance 测试 + 实际 POC 评估，而非仅看宣传"。

A2A 是新协议，框架支持度参差。评估要看"协议实现 + 集成深度 + 文档工具 + 生产就绪度"，用 conformance 与 POC 实证，避免因宣传误判成熟度。

• 理解数据处理角色（控制者/处理者）
• 理解记录义务与最小化
• 理解审计留痕

跨组织 Agent 链的数据合规需明确各参与方角色：GDPR 下，控制者（确定目的与方式）与处理者（按控制者指示处理）角色需在协议中明确；PIPL 类似区分处理者与受托人。落实：1) 角色界定——每跳数据流中明确谁是控制者、谁是处理者，数据流向与责任随之确定；2) 记录义务——处理者需记录处理活动（处理目的、数据类别、接收方、保留期），符合 GDPR 处理记录要求；3) 数据最小化——Agent 链只传递完成任务所需的最小数据，减少处理范围；4) 审计留痕——记录跨组织的数据传输、处理与删除，支持按数据主体检索、响应权利请求（访问/删除/更正）；5) 跨境传输——跨司法辖区传输需符合 GDPR/PIPL 的跨境机制（SCC、标准合同等）。核心是"角色定责、处理留痕、数据最小化、符合跨境规则"，让统计与审计覆盖整条 Agent 链。

跨组织链的合规难点是"数据经过多个组织，责任被撕裂"。明确各参与方的处理角色与记录义务，配合最小化与审计留痕，才能在 GDPR/PIPL 下让整条链可追责、可核查。

• 理解 conformance 测试矩阵
• 理解版本组合维护
• 理解避免私有扩展锁定

维护跨厂商互操作：1) conformance 测试矩阵——用官方 conformance 测试套件覆盖核心协议（task/send、状态机、Agent Card、流式事件），建立"实现 × 测试"矩阵，验证各厂商实现是否通过；2) 版本组合——维护不同协议版本、binding、扩展版本的组合矩阵，测试新旧版本间的互操作（如 v1.0 客户端 × 各厂商 server），确保向后兼容；3) 反锁定策略——要求实现通过标准 conformance，私有扩展必须以"向后兼容、可选"方式存在，不改变标准语义，避免绑定私有功能；4) 持续更新——随协议版本演进更新测试矩阵，纳入新扩展点的标准测试；5) 认证——通过 conformance 的实现在目录中标记，提供互操作保证。核心是"用 conformance 矩阵测试互操作，用版本组合保证兼容，用可选私有扩展避免锁定"。

互操作认证的本质是"标准可验证"。conformance 矩阵证明"实现符合标准"，版本组合证明"不同版本可互操作"，私有扩展可选原则防止"实现偏离标准"。三者共同维护健康的跨厂商生态。