Agent 实践
Google A2A 首发复盘：Agent 互操作之后，身份、长任务与责任如何落地
以 2025 年 4 月 9 日至 11 日的一手资料为边界，拆解 A2A 的 Agent Card、任务生命周期、消息与制品模型，并设计跨组织 Agent 的身份传播、授权、恢复、评测和商业验收。
时间与证据
本文研究的是 Google 在 2025 年 4 月 9 日发布 Agent2Agent（A2A）开放协议草案的事件，同期信息截止到 4 月 11 日。文章发布日期与更新日期见页首。这个时间标注很重要：首发博客明确把仓库称为 draft specification，并表示正与合作伙伴争取在当年晚些时候推出 production-ready 版本。因此，本文只讨论当时已经公开的草案、示例与设计原则，不把后来组织归属、规范版本、传输变化或生产成熟度倒填到首发日。
主要证据是 Google 的 A2A 首发页、2025 年 4 月 10 日保存的 T+1 原始快照，以及发布日仓库完整 commit 0ad9630e044d72c22428f129165fe4c0de385902。当前官方页会被持续修改，涉及首发定位、合作范围、设计原则和未来计划时以 T+1 快照为准；协议对象、RPC 方法和任务状态则以固定 commit 中的 JSON Schema、README 与样例类型为准。
三条证据共同支持的首发边界是：A2A 试图让不同厂商、不同框架构建的 Agent 发现能力、交换消息并围绕一个长任务协作；协议建立在 HTTP、Server-Sent Events（SSE）与 JSON-RPC 等已有标准上；主要对象包括 Agent Card、Task、Message、Part 和 Artifact；草案提供同步请求、流式更新、任务查询、取消、重新订阅与推送通知等机制。它们证明了互操作设计已经公开，不证明任意两家企业的 Agent 当时已经安全互通，更不证明业务结果、授权和合规责任已被协议自动解决。
本文证据等级为 sourced。我核对了固定网页和代码快照，但 没有在 2025 年首发版本上部署两个 A2A Server，没有抓取 JSON-RPC/SSE 流量，也没有复现跨厂商或跨组织任务。下文的供应链案例、身份架构、状态表、评测门槛和成本公式均是待验证的工程方案，不是本站实验结果。固定仓库本身也处于高频变动期，某个样例能运行不能替代规范一致性、互操作测试或安全审计。
当时发生了什么
A2A 解决的是 Agent 之间的协作接口
首发博客把问题描述为：企业已经在不同数据系统与应用中建设 Agent，但不同供应商、框架和平台之间缺少共同协作语言。一个采购 Agent 可能需要供应商 Agent 提供可替代商品，一个客服 Agent 可能需要物流 Agent 确认异常，一个研究 Agent 可能需要另一个专业 Agent 执行长时间分析。若每一对 Agent 都定义专有 API，连接数量和语义适配会迅速增长。
A2A 的目标不是让远端 Agent 暴露内部模型、记忆、工具或 Prompt。相反，首发强调 Agent 可以保持 opaque，通过公开能力和任务接口协作。客户端 Agent 负责形成和发送任务，远端 Agent 负责尝试完成任务或采取动作。这个边界允许远端实现继续使用自己的模型、框架与内部工具，也意味着调用方不能依赖远端的内部推理，只能验收协议响应和最终业务结果。
这也是 A2A 与 MCP 最容易混淆、又必须分清的地方。按首发页的定位，MCP 的主要责任是 Agent-to-tool / Agent-to-data：Agent 取得工具与上下文；A2A 的主要责任是 Agent-to-Agent：两个拥有各自能力、状态和执行边界的 Agent 围绕任务协作。一个远端供应链 Agent 内部完全可能通过 MCP 调用库存工具，再通过 A2A 把任务状态与 Artifact 返回给采购 Agent。两者互补，不是互相替代，也都不会自动提供企业业务授权。
Agent Card 是发现入口，不是信任证明
固定仓库把 Agent Card 描述为通常位于 /.well-known/agent.json 的公开 JSON 元数据。它可以声明 Agent 名称、服务 URL、版本、能力、输入输出模式、技能，以及认证相关信息。客户端可以先读取 Card，再判断远端是否支持流式、推送通知或某项技能。
一张最小化 Card 可以表达类似信息：
{
"name": "Supplier Exception Agent",
"url": "https://supplier.example/a2a",
"version": "2025-04-draft",
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"authentication": {
"schemes": ["Bearer"]
},
"defaultInputModes": ["text", "data"],
"defaultOutputModes": ["data", "file"],
"skills": [
{ "id": "resolve-delay", "name": "Resolve shipment delay" }
]
}
这是基于首发字段写出的应用示意，不是声称存在名为 2025-04-draft 的官方版本。更重要的是，Card 只说明“对方声称自己是谁、支持什么”，不能证明域名所有者、实现版本、技能质量或当前调用者权限。Card 可能过期、被劫持或夸大能力。生产发现还需要受信目录、域名与证书校验、组织准入、版本缓存策略和下线机制。
首发证据里还存在值得保留的草案信号：JSON Schema 已有 authentication、schemes 与可选 credentials 字段，博客宣称设计支持企业级认证与授权；同一 commit 的 README 又把进一步正式化 Agent Card 中的授权方案与可选凭据列为未来工作。正确结论不是“首发完全没有认证”，也不是“认证已经定型”，而是草案提供了表达位置与设计目标，细节仍在演进。密钥更不应直接发布在公共 Card 中。
Task 把一次问答扩展为可跟踪工作
A2A 的中心对象是 Task。固定 schema 中，Task 有唯一 id、可选 sessionId、当前 status、可选 Artifact 与 metadata。首发任务状态包括：
submitted -> working -> input-required
-> completed | failed | canceled | unknown
input-required 允许远端在信息不足时请求用户或客户端补充材料；unknown 承认状态可能无法判断。这个建模比“调用成功/失败”更适合小时或天级工作，但 Task 状态仍只是远端协议视角。远端返回 completed 不能单独证明订单已经正确修改、退款已经到账或合规审查已经通过；调用者仍要向权威业务系统核验。
Message 表示客户端和远端 Agent 的交流回合，角色是 user 或 agent；Message 由一个或多个 Part 组成。首发 Part 可以承载文本、文件或结构化数据。Artifact 则表示任务产生的输出，也由 Part 组成，并可通过 index、append、lastChunk 等字段分片更新。这样，任务既可以返回说明文字，也可以交付报价表、表单、文件或结构化候选方案，而不必把所有内容压成一段自然语言。
但对象结构不会自动统一业务语义。两家 Agent 都接受 DataPart，不代表它们对“可用库存”“预计到达”或“批准”有相同定义。跨组织协作仍需版本化业务 schema、币种与时区规则、字段必填条件、错误代码、证据要求和语义回归测试。
JSON-RPC、HTTP 与 SSE 组合长任务通道
固定 schema 提供 tasks/send、tasks/sendSubscribe、tasks/get、tasks/cancel、tasks/pushNotification/set、tasks/pushNotification/get 与重新订阅相关方法。普通请求使用 JSON-RPC 2.0 发送；支持 streaming 的 Agent 可通过 tasks/sendSubscribe 在 SSE 上返回 TaskStatusUpdateEvent 或 TaskArtifactUpdateEvent。长任务连接中断后，客户端可以查询任务或重新订阅；离线时间更长时，还可配置回调接收推送通知。
一个发起供应异常协商的请求可能是：
POST /a2a HTTP/1.1
Host: supplier.example
Authorization: Bearer <audience-bound-token>
Content-Type: application/json
Accept: text/event-stream
{
"jsonrpc": "2.0",
"id": "rpc-91",
"method": "tasks/sendSubscribe",
"params": {
"id": "task-01JV...",
"message": {
"role": "user",
"parts": [{
"type": "data",
"data": {
"purchaseOrder": "PO-1842",
"requestedAction": "propose-alternatives"
}
}]
},
"metadata": { "traceparent": "00-..." }
}
}
协议可承载这些字段，不代表远端应相信消息里的订单号、请求动作或 metadata 身份。Authorization 所代表的主体与委托范围必须由网关验证，远端再从自己的订单系统加载对象并做资源级授权。JSON-RPC 的 id 用于关联请求响应，Task id 用于关联工作；它们都不能天然替代业务幂等键或事务 ID。
任务判断
具体案例：跨企业供应延迟处置
假设一家连锁零售商的 120 家门店依赖多个供应商补充标签纸和包装材料。采购单 PO-1842 的某批货延迟，零售商的采购 Agent 要与供应商履约 Agent、第三方物流 Agent 协作，在 24 小时内形成处理方案：确认延迟范围，查询可替代 SKU，比较价格与到货日，预留但不提交替代货源，最后把变更草稿交给采购经理审批。
输入不是一句“帮我处理延迟”，而是一份受控任务包：采购单引用、允许暴露的行项目、目标门店区域、最晚到货日、最高价差、可接受替代规则、证据要求和有效期。输出也不是聊天结论，而是结构化 Artifact：每个候选 SKU、数量、币种、含税与运费价格、预计到货区间、库存证据、报价有效期、不可满足约束，以及需要人确认的问题。
这类场景适合 A2A 的原因是：参与方属于不同组织，内部实现和工具不应互相暴露；任务可能等待仓库或人工确认；中间需要状态与多轮补充；最终交付包含表格和文件。它比把一个远端 Agent 伪装成 getQuote() 工具更能表达协商过程，也比每个供应商建立一套专有异步 API 更有复用潜力。
首个试点必须收窄为 读取、询价和创建可撤销草稿。零售商 Agent 可以请求候选方案，供应商 Agent 可以返回报价 Artifact，物流 Agent 可以返回到达区间；任何预留库存、修改采购单、确认运输或产生付款的动作都不由自然语言消息直接触发。采购经理批准后，独立执行服务根据规范化方案、金额、采购单版本和审批 nonce 执行，再向 ERP 与供应商系统核验。
决策表：协议能做什么，业务还要做什么
| 问题 | A2A 首发草案提供的骨架 | 业务系统仍需负责 |
|---|---|---|
| 找到对方 | Agent Card、技能与能力声明 | 受信目录、供应商准入、域名与证书绑定、Card 过期与撤销 |
| 发起协作 | JSON-RPC Task 与 Message | 调用者身份、委托链、订单资源授权、字段语义与输入验证 |
| 交换内容 | Text/File/Data Part 与 Artifact | 文件扫描、URI 白名单、PII 最小化、证据与业务 schema 验证 |
| 等待长任务 | SSE、状态更新、查询、重新订阅与推送 | 事件去重、断线恢复、超时预算、队列、补偿和最终状态对账 |
| 表示完成 | completed、failed、canceled、unknown |
ERP/物流权威状态、幂等副作用、人工接管与责任归属 |
| 支持认证 | Card 中的认证表达位置与安全设计目标 | 凭据签发、token audience/scope、组织映射、资源级授权和审计 |
只有协议互通还不能通过试点。一次合格处理必须同时满足：没有向供应商泄露其他供应商报价；所有候选来自批准的组织；价格可按币种、税和运费回算；到达时间有来源与有效期；未批准前没有外部副作用；审批后 ERP、供应商与物流状态一致；连接中断后没有重复预留或重复采购。
测试集应包含至少 150 个历史或合成异常单，覆盖正常延迟、部分缺货、报价过期、币种不一致、同名 SKU、跨租户订单、Agent Card 变更、流式断线、重复事件、推送乱序、文件 URI 越域、恶意 Message/Artifact 指令、远端 completed 但 ERP 未变、提交后响应丢失，以及人工迟迟不批准。每个样本保存允许读取的对象、可接受候选集合、禁止动作和权威终态。
工程影响
协议任务和业务事务必须分层
我会分别保存 A2A 任务状态与采购业务状态，禁止用一个枚举同时承担两种含义：
A2A task:
submitted -> working -> input-required
-> completed | failed | canceled | unknown
business case:
accepted -> collecting -> negotiating -> awaiting_approval
-> amendment_pending -> verifying
-> resolved | rejected | reconciliation | escalated
映射只能由显式规则完成。例如 A2A completed 只表示远端认为报价任务完成，业务状态最多进入 awaiting_approval；执行服务提交采购变更并读回 ERP 新版本后，才能进入 resolved。A2A failed 可能只影响一个供应商候选，不一定终止整个业务 case。A2A unknown 则进入 reconciliation，先调用 tasks/get 与远端业务查询，再决定恢复、重试还是人工接管。
数据表至少保存 case_id、remote_org、Agent Card 内容 hash、协议版本、task_id、JSON-RPC 请求 ID、调用者与委托者、输入 schema 版本、业务对象版本、最后观察状态、Artifact hash、审批引用和权威结果引用。完整 Prompt 或跨企业原始文件不应默认进入通用日志；审计保留受控引用、必要摘要和不可变状态迁移。
Task ID 只能帮助远端识别工作，不能假设每个实现都对重复 tasks/send 做相同幂等处理。任何有副作用的业务请求另带 operation_id 与幂等键，绑定组织、订单、规范化动作、金额、版本和有效期。超时后先按幂等键查权威状态，不让客户端 Agent 自行改写 Task ID 重试。
身份必须传播，权限不能传播成一段文字
跨组织调用至少涉及四个角色：发起操作的人、零售商客户端 Agent、零售商 A2A 网关、供应商远端 Agent。若只向远端发送一个服务账号，供应商无法区分谁发起；若把 userId 放在 Message 或 metadata，远端又无法证明它没有被模型伪造。
建议由零售商身份系统签发短时、限定 audience 的服务凭据，并在受信 token claim 或独立委托凭证中携带 actor、subject、组织、允许 action、资源范围、目的、过期时间与唯一 nonce。A2A 网关校验员工会话和内部 RBAC 后才签发；供应商网关验证签名、issuer、audience、时间、撤销状态和双方合同映射，再把外部 scope 映射到本地权限。远端 Agent 只接收验证后的 principal，不从自然语言内容恢复身份。
这套委托凭证是本站提出的生产架构，不是 A2A 首发已经规定的 token 格式。首发认证字段可以帮助发现双方支持何种方案，却不能表达完整的“员工代表零售商、仅对 PO-1842、仅可询价、15 分钟有效”语义。跨组织授权最终还需要合同、资源映射和本地策略。
审批同样不能通过 Agent 发一句“用户同意了”传播。批准对象应绑定：发起人、批准人、组织、远端 Agent、采购单、候选 Artifact hash、金额、币种、业务版本、具体动作、有效期和一次性 nonce。任何字段变化都要求重新批准。如此才能防止把低价候选的批准复用到高价候选，或把一个供应商的授权重放给另一个供应商。
Agent Card 要进入供应链治理
生产客户端不能每次从任意 URL 读取 Card 后立即调用。受信目录应记录组织法律主体、Card URL、TLS 域名、允许的 endpoint、审核版本、技能清单、认证方式、数据处理区域、联系人和撤销状态。Card 更新先进入隔离验证，比较 endpoint、认证、技能和输入输出模式变化，再由策略决定自动接受还是人工复核。
客户端不能让远端 Card 的描述文字直接改变系统策略。技能名称、description、examples、文件链接和 endpoint 都是不可信输入；必须限制长度、协议、域名、重定向与私网地址，防止 SSRF 和发现阶段 Prompt Injection。公共 Card 只能发布非敏感元数据，不放 API key、可复用 token 或内部网络地址。
SSE、推送和恢复不是同一件事
SSE 适合在线观察进度，推送适合客户端离线时通知，tasks/get 适合读取当前快照，重新订阅适合连接恢复。它们组合起来仍不自动形成 exactly-once 事件系统。固定 schema 的状态与 Artifact 事件没有足以承担企业全局顺序的统一业务版本，因此客户端要容忍重复、乱序、缺失和最终事件先到。
处理器应以 remote_org + task_id 分区，验证状态迁移，对 Artifact 按 index 和内容 hash 去重；发现无法解释的倒退或分片缺口时重新读取 Task 快照。网络断开不会直接把业务标成失败。一个运行 8 小时的任务要有总 deadline、阶段超时、最大静默时间和人工升级点，不能因为 SSE 还连着就无限占用资源。
推送回调又引入反向调用边界。客户端提供的 webhook URL 可能被用来扫描内网，远端回调也可能被伪造或重放。网关应只允许预登记 HTTPS endpoint，隔离出站网络，验证回调签名或双向身份，绑定 task 与 nonce，限制 body、重定向和频率。回调只触发“重新查询任务”，不要直接凭一条推送执行采购动作。
Message、Part 与 Artifact 都是不可信数据
远端 Agent 返回的自然语言可能包含“忽略采购规则”，文件可能携带恶意内容，URI 可能指向内网或超大对象，DataPart 也可能在合法 JSON 中提交越权订单号。接收端先做 MIME、大小、病毒、解压深度、URI、schema 与字段范围检查，再按来源组织和任务权限决定是否进入模型上下文。
结构化并不等于正确。报价 Artifact 至少要验证币种、精度、税率、时间区间、数量单位、SKU 映射、证据 URL、有效期和签发组织；所有金额由确定性代码重算。自然语言理由可以辅助人阅读，不能覆盖确定性规则。需要进入下游 Agent 的内容以引用方式传递，保留来源与 hash，避免复制过程中丢失责任链。
评测从“连得上”扩大到“任务可收敛”
测试分为四层。协议层检查 Card 解析、JSON-RPC 方法、状态、SSE 分片与错误；语义层检查两家实现对业务 schema 的理解；安全层检查身份、跨组织资源、注入、回调与审批；业务层检查最终 ERP、供应商和物流记录。只有四层都通过，才可称这条 A2A 链路可用。
核心指标建议包括：
- 互操作通过率：固定客户端对每个远端版本的契约用例通过比例。
- 经验证任务完成率：只有权威业务状态与输入约束全部满足才计成功。
- 身份归因完整率：每个请求与副作用能否还原发起人、委托 Agent 和远端执行者，门槛为 100%。
- 未授权副作用率与跨组织泄露率：两者发布门槛均为 0。
- 终态收敛率：超时、断线、重复和
unknown是否在目标时间内正确对账。 - 重复放大率：一次业务意图产生多少 Task、RPC、回调与上游写入。
- Artifact 合格率：结构、证据、币种、有效期和业务规则是否同时通过。
- P50/P95 完成时间、人工接管分钟与每个经验证任务成本。
观测系统应把协议 trace、业务事件和安全审计分开。Trace 记录 endpoint 版本、方法、延迟、状态和 payload hash；业务事件记录采购单与最终变更；安全审计记录身份、策略、审批和拒绝原因。不要把 bearer token、完整报价、个人信息或文件内容写入通用 trace。
商业价值
A2A 的商业价值首先不是“多放几个 Agent”，而是降低跨产品、跨供应商长任务的接入与替换成本。可能付费的客户包括供应链、采购、旅行运营、保险理赔、企业 IT 服务和客户支持团队：它们已经需要多个组织或 SaaS 系统协作，任务又包含等待、补充材料和结构化交付。
对平台方，机会是提供受信 Agent 目录、身份与委托网关、策略映射、协议兼容测试、任务控制台、审计和 SLA；对解决方案商，机会是把某个行业的业务 schema、失败样本和验收规则产品化。真正的护城河不是实现 tasks/send，而是积累“哪些组织可发现、谁能代表谁、什么任务可执行、什么 Artifact 算合格、失败如何收敛”的运营资产。
供应延迟案例的收益来自减少邮件往返、手工抄录和跨门户查询，缩短从异常发现到可批准方案的时间；成本则包括 Agent 推理、远端服务计费、网络与队列、数据映射、目录维护、身份联邦、人工审批、异常对账和错误损失。单位经济性应按最终合格结果计算：
每个经验证异常单成本
=（客户端与远端 Agent 计算费用
+ API、网络、队列、存储和观测
+ 目录、身份、协议适配与版本维护摊销
+ 人工补充、审批、接管和对账分钟 × 人工单价
+ 预期泄露、重复采购与错误交付损失）
/ 经 ERP、供应商和物流权威状态共同验证的完成数
失败、取消、转人工和 unknown 都进入分子，不能只统计成功 Task。协议消息更少也不等于成本更低：若 Artifact语义不一致导致采购员重新核对，互操作收益会被人工修订吃掉。
建议进行 12 周试点。第 1 至 4 周在冻结数据上做两个组织、两个框架的契约与攻击测试；第 5 至 8 周影子运行，只生成候选方案；第 9 至 12 周允许一个供应商创建可撤销预留草稿。扩量前预先约定：身份归因 100%，未授权副作用与跨组织泄露为 0，所有 unknown 在 30 分钟内收敛或升级，Artifact 合格率不低于 98%，人工处理分钟较基线下降至少 25%，每个经验证异常单成本低于节省的人工与延迟损失。这些是可证伪门槛，不是本站已取得的数据。
不适用场景
若双方只有一个稳定、同步、结构化 API，直接 API 通常比引入 Agent 协商更简单。任务必须毫秒级响应、结果可由规则完全决定、没有长任务或多轮输入时，也不应为了“多 Agent”增加协议层。
不可逆高额支付、未经人工签署的招聘/医疗/法律决定、无法查询权威终态的外部动作，以及不能建立跨组织身份与责任合同的协作，不适合直接使用 A2A 自动执行。参与方不愿暴露最小可验证证据、数据驻留要求无法协调、远端能力频繁变化却没有兼容门禁时，先维持人工或专有受控集成更合理。
同一企业内两个模块若共享代码、身份和数据库，进程内接口、队列或工作流引擎可能更便宜。A2A 的优势在独立 Agent 和边界明显的系统间；把每个函数都包装成远端 Agent 会增加延迟、非确定性和故障面。
局限与风险
第一，本文没有运行 A2A 首发实现，无法声明不同语言样例真正互通，也没有本站延迟、丢事件、恢复率或成本数据。固定 commit 提供的是草案 schema 和样例，不是生产认证。
第二，首发博客是发布方材料。“secure by default”“enterprise-grade”属于设计目标与产品表述，不能替代威胁模型、独立审计和组织自己的控制验证。认证方案能证明某个凭据，不必然证明最终用户委托、订单资源权限或动作合法。
第三，Agent Card 增加可发现性，也扩大供应链攻击面。恶意或过期 Card 可以引导客户端访问错误 endpoint、接受不支持的模式或把描述注入模型。发现必须与信任、版本和撤销分开。
第四，自然语言协作保留了 Agent 能力，却弱化了确定语义。两个 Agent 都“理解”延迟并不代表对库存保留、工作日、时区和罚则理解一致。Message 适合协商，合同字段和最终副作用仍应结构化、版本化和验证。
第五，长任务会放大分布式系统问题：连接断开、事件重复、回调乱序、任务超时、远端升级与部分成功。SSE 和 push 是传输工具，不是事务。没有本地状态机、幂等、补偿和权威对账，任务越长越容易留下悬挂状态。
第六，Agent 间内容存在跨边界 Prompt Injection。一个供应商 Artifact 可能诱导采购 Agent 访问其他工具或泄露竞品报价。所有远端内容都要带来源进入低信任区，工具调用由外部策略限制，敏感上下文不因“来自另一个 Agent”而自动共享。
第七，首发 Card 认证字段、README 未来计划和博客承诺之间仍有草案期差异。本文将其解释为“已有表达位置、尚未完全定型”，不选择其中一句放大为完整安全方案。
最后，本文明确不使用后来事件证明 4 月 9 日草案成功。后续版本即使解决某些问题，也只能作为另一篇带新事件日期和证据边界的研究；不能修改这篇首发复盘的同期结论。
面试表达
30 秒结论： 2025 年 4 月 9 日的 A2A 草案用 Agent Card 做能力发现，用 JSON-RPC over HTTP 发任务，用 SSE、查询、重新订阅和推送支持长任务，并用 Task、Message、Part、Artifact 统一协作对象。它与 MCP 分工：MCP 主要连接 Agent 与工具/数据，A2A 连接独立 Agent。但协议互通不等于业务可信，我会外置身份委托、资源授权、审批、幂等和权威终态验证。
3 分钟架构： 我会以跨企业供应延迟为试点。零售商先从受信目录获取审核过的 Agent Card，A2A 网关用短时 audience-bound 凭据调用供应商，只允许读取和询价。协议 Task 状态与采购业务状态分表；SSE 只提供进度，断线后用 Task 查询和 ERP/供应商状态对账。Message、Part 与 Artifact 都按不可信输入处理，结构化报价由代码重算。采购变更需要一次性审批，绑定候选 hash、金额、订单版本和远端组织。评测同时看互操作、身份归因、泄露、副作用、终态收敛、人工分钟和单位合格成本。
若追问“Agent Card 声明了 authentication，为什么还要身份网关”，答案是 Card只描述远端接受哪些机制，不能证明当前员工能操作哪张采购单，也不能安全表达完整委托链；网关必须从可信会话建立主体和 scope。若追问“远端返回 completed 是否可以结束”，答案是否定的：它只结束协议任务，采购是否解决要以 ERP、供应商和物流权威记录为准。
若追问“A2A 与 MCP 是否二选一”，答案也是否定的：远端供应 Agent 可在内部使用 MCP 访问库存工具，对外通过 A2A 接受协作任务。MCP 降低工具连接成本，A2A 降低独立 Agent 协作成本，业务控制面覆盖两者。
复盘
站在 2026 年回看，首发最重要的信号不是“多 Agent 已经成熟”，而是行业开始把 Agent 互操作从框架内部 handoff 提升为跨产品协议问题。Agent Card、显式 Task、长任务状态与多模态 Part 说明评价单位正在从一次模型输出扩大到一个可跟踪交付过程。
当时最容易高估的是“采用已有标准”带来的成熟度。HTTP、JSON-RPC 与 SSE 降低网络接入成本，却不会统一业务语义、身份联邦和责任合同。另一个误区是把远端 Agent 当成能力更强的函数：函数通常有确定 schema 和短生命周期，Agent 任务可能协商、等待、产生多份 Artifact 并要求人工输入，必须按分布式工作流治理。
这次复盘也给出一个可复用检查法。看到新的 Agent 协议时，先问六件事：如何发现、如何建立信任、谁代表谁、任务如何恢复、什么算最终完成、失败由谁承担。只回答“能发消息”最多证明连接；六个问题都有可测试答案，才接近商业系统。
下一步可复现实验应固定首发 commit，在本地搭建 TypeScript 客户端与 Python 远端 Agent，记录 Card、JSON-RPC、SSE 断线、input-required、Artifact 分片、取消与 unknown 的原始轨迹，再增加身份网关和模拟 ERP 对账。实验必须公开版本、场景、失败样本和成本；完成之前本文继续保持 sourced，不升级为 reproduced。
方法披露
本文使用 AI 工具辅助抽取首发页结构、比对固定 commit 的 schema/README、组织案例和检查文章契约；事件日期、T+1 archive、完整 commit、首发草案边界、A2A/MCP 分工和最终工程判断由作者逐项复核。本文没有部署 A2A，没有访问真实供应链数据，没有执行跨组织授权，也没有取得任何试点指标。
文中的 Card、JSON-RPC 请求、状态映射、委托凭证、评测门槛与成本公式均为解释或实验设计；它们不冒充首发规范的强制实现。涉及“应当”“建议”的内容代表本站工程判断，涉及“首发提供”“固定 schema 包含”的内容才是同期事实。
修订记录
2025-04-12：初版发布；固定 2025-04-09 至 04-11 的首发页、T+1 快照与仓库 commit，区分 A2A Agent-to-Agent 和 MCP Agent-to-tool，补充 Agent Card 信任、跨组织身份委托、长任务恢复、Artifact 验证、商业成本与可证伪试点条件。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
讨论