一、一个被反复验证的工程现实

多智能体系统发展到今天，暴露出一个很朴素的问题：

每个 Agent 单独能力都很强，但它们互相之间是聋哑的。

一个物流 Agent 没办法直接问库存 Agent 一个问题。一个客服 Agent 在对话中途，没办法把工作交接给退款 Agent。每个 Agent 都在自己的孤岛里把工作做到极致，但孤岛之间没有桥。

这不是模型能力的问题，是通信协议缺失的问题。

A2A（Agent2Agent Protocol）就是为了解决这个具体问题而设计的。

二、A2A 的来龙去脉

A2A 协议由 Google 开发，于 2025 年 4 月 9 日正式发布，是一个开放通信标准，让 AI Agent 能够跨不同平台和框架，发现彼此、完成身份验证，并互相委派任务。 TrueFoundry

发布之后的发展速度值得注意：

A2A 协议启动时有超过 50 家创始合作伙伴，发展到 2025 年中期已有 150 多家组织支持，协议治理权移交给了 Linux 基金会。 TrueFoundry

截至 2026 年中，包括 AWS、微软、Salesforce、SAP、IBM 和 ServiceNow 在内的 150 多个组织，已在生产环境中采用了 A2A。协议本身也在持续迭代——A2A 已于 2026 年初进入 v1.0 版本。 TokenMixTokenMix

这个增长曲线说明一件事：**多智能体系统正在从研究项目走向生产部署，Agent 之间怎么通信，已经不是一个理论问题，而是规模化构建时绕不开的工程问题。**根据 DataForSEO 关键词数据，2026 年 4 月"a2a protocol"搜索量环比增长 22%，季度环比增长 52%，"agent2agent protocol"季度环比增长高达 88%。 TrueFoundry

三、A2A 的核心架构：Agent Card 是什么

A2A 协议的设计核心，是让一个 Agent 能够：发现别的 Agent 有什么能力，然后把任务委派过去。

实现这件事的关键组件是 Agent Card。

Agent 通过部署在自己服务端点的元数据文件来宣告自己的能力，这个标准化的 JSON 格式文件被称为 AgentCard。 OpenRouter

可以把 Agent Card 理解成一个 Agent 的"数字名片"——它描述了这个 Agent 能做什么、怎么联系它、需要什么样的身份验证。

协议的整体架构是客户端-服务端模式：

协议定义了"客户端 Agent"和"服务端/远程 Agent"两个角色。远程 Agent 根据从客户端 Agent 收到的任务执行操作，并通过 A2A 协议返回结果。 OpenRouter

通信围绕任务这个核心概念展开：

通信围绕具有明确生命周期和输出的任务而构建，支持异步、多模态和经过身份验证的交互。 OpenRouter

用一个简化的流程图来描述这个交互过程：

客户端 Agent（发起委派）
    ↓ 1. 发现阶段
    ↓    请求目标 Agent 的 Agent Card
    ↓
远程 Agent 端点
    ↓ 2. 返回 Agent Card
    ↓    {能力描述, 认证方式, 接口规范}
    ↓
客户端 Agent
    ↓ 3. 创建任务，发起请求
    ↓    （携带身份验证凭证）
    ↓
远程 Agent
    ↓ 4. 执行任务
    ↓    （任务状态：created → in_progress → completed/failed）
    ↓
客户端 Agent
    ← 5. 接收结果（支持流式返回）

Agent 通过交换结构化消息、通过 Agent Card 宣告能力，并在多智能体工作流中跟踪任务生命周期状态，来实现协同。 Helicone

四、A2A 和 MCP：经常被混淆，但完全不是一回事

这是这个领域里最常见的认知错误，值得专门拆开讲。

MCP（Model Context Protocol）解决的问题：Agent 怎么连接工具和数据。

A2A 解决的问题：Agent 怎么和别的 Agent 协作。

和连接 Agent 与工具的 MCP 不同，A2A 连接的是 Agent 和 Agent。 TrueFoundry

更准确的技术定位：

MCP 专注于纵向集成（Agent 到工具的通信），采用客户端-服务端架构——就像给一个 Agent 配备多种工具的访问权限。A2A 专注于横向协调（Agent 到 Agent 的协作），采用点对点架构——就像组建一支专业化 Agent 团队。 Maxim Articles

实际的生产系统里，这两个协议不是二选一的关系，而是叠加使用的：

一个 Agent 使用 A2A 把工作委派给专精 Agent，这个专精 Agent 再用 MCP 调用它需要的工具。两个协议互不替代，生产级多智能体系统会同时用到两者。 TrueFoundry

一个具体的架构示意：

用户请求
    ↓
主 Orchestrator Agent
    ↓ (通过 A2A 发现并委派)
    ├── 专精 Agent A（如：库存查询）
    │       ↓ (通过 MCP 调用)
    │       └── 数据库工具 / API
    │
    ├── 专精 Agent B（如：物流追踪）
    │       ↓ (通过 MCP 调用)
    │       └── 物流系统 API
    │
    └── 专精 Agent C（如：客户通知）
            ↓ (通过 MCP 调用)
            └── 邮件/短信服务

A2A 层：负责"找谁、委派什么、怎么协调"
MCP 层：负责"每个 Agent 具体怎么干活"

最佳实践是两者协同使用：MCP 负责工具访问，A2A 负责协调。 Maxim Articles

值得指出的是，这个区别在实践中经常被搞混。截至 2026 年 4 月，根据 DataForSEO 的 ChatGPT 抓取查询数据，ChatGPT 在回答这两个协议相关问题时仍然给出事实性错误的答案，把 A2A 和通用的多智能体概念混为一谈。这说明即便协议已经相对成熟，准确理解它的架构边界仍然需要刻意学习，不能想当然。 TrueFoundry

五、安全风险：Agent Card 可以被伪造

这是这个领域里讨论较少、但工程上必须正视的问题。

A2A 协议依赖 Agent Card 的能力描述来做任务路由决策——也就是说，编排 Agent 信任 Agent Card 里写的内容。这个信任假设带来了一类新的攻击面：

Trustwave SpiderLabs 的研究人员在 2025 年演示了一类重大攻击：恶意 Agent 展示一个夸大的 Agent Card，其描述经过精心设计，用来操纵编排器基于 LLM 的选择逻辑。由于大多数编排器是通过对 Agent Card 描述进行推理来选择专精 Agent 的，向描述字段中注入有说服力的自然语言，就可以劫持任务路由。这是一种发生在基础设施层的提示注入。 TokenMix

这个攻击的本质，是把传统的"提示注入"攻击，从"用户对模型"的场景，转移到了"Agent 对编排器"的场景。攻击者不需要直接攻破某个 Agent，只需要让自己的 Agent Card 描述写得足够有说服力，就能让编排器把本该交给可信 Agent 的任务，错误地路由给恶意 Agent。

针对这个问题，业界已经有明确的防御建议：

应该对 Agent Card 进行密码学验证，而不只是语义层面的验证。 TokenMix

身份验证层面，目前生产环境中比较成熟的做法是：

Auth0 与 Google Cloud A2A 的集成方案展示了这种模式：为每个 Agent 身份签发 OAuth 2.0 机器对机器令牌，设置短有效期并自动轮换，作用域限定在特定的 A2A 端点。 TokenMix

对于做多智能体系统架构设计的工程师，这里有一个明确的工程结论：Agent Card 不能仅凭语义可信度做路由决策，必须叠加密码学层面的身份验证，且权限作用域要尽量收窄。

六、一个值得关注的延伸方向：Agent 之间的支付

多智能体协作走向生产化之后，一个自然延伸出的问题是：如果 Agent 之间要互相调用付费服务，怎么结算？

已经有研究在探索用账本锚定身份（ledger-anchored identities）和 x402 微支付方案来增强 A2A 协议，目标是支撑多智能体经济——让基于不同技术、由不同厂商构建的 Agent 能够无缝协作。 OpenRouter

这个方向目前还在早期研究阶段，但它指向一个值得关注的趋势：当 Agent 之间的协作从"免费协调"演化为"有偿服务调用"，身份认证和支付结算会成为协议栈里同等重要的部分。

七、案例：Aethir Claw 的 Agent 协作场景

回到一个更具体的工程问题：在实际的 Agent 托管平台里，A2A 这类协议的价值怎么体现？

以 Aethir Claw 为例，它的预装技能体系（50+ 技能，覆盖市场监控、链上分析、尽职调查等场景）天然存在多 Agent 协作的需求——比如前面讨论过的"入场前综合分析"工作流，本质上就是多个专精能力并行执行、再汇总结果的协作模式。

用户请求："分析 $XXX 的入场前情况"

任务委派模式（概念示意）：
主 Agent（Orchestrator）
    ↓ 委派子任务
    ├── 价格走势分析能力
    ├── 项目融资背景调查能力
    ├── 社交情绪分析能力
    └── 合约审计摘要能力
            ↓ 各自执行
    主 Agent 汇总结果，输出综合报告

这种模式在架构上和 A2A 协议描述的"客户端 Agent 委派任务给远程 Agent，再汇总结果"高度一致。需要说明的是，Aethir Claw 当前的多技能并行执行是平台内部的任务编排实现，并非公开声明遵循 A2A 协议规范——但它解决的工程问题，和 A2A 想要标准化的问题是同一类。

这也是观察这个领域的一个角度：A2A 协议要解决的，是让不同厂商、不同框架构建的 Agent 能够互相协作；而在单一平台内部，类似的任务编排逻辑早已存在，只是还没有标准化到协议层面。 随着 A2A 这类标准的成熟，跨平台、跨厂商的 Agent 协作会变得更加普遍，这对依赖多技能协同完成复杂任务的场景（比如加密领域的尽职调查、多维度市场分析）有直接的工程价值。

八、写在最后

A2A 协议解决的，是多智能体系统从"单点能力强"走向"系统能力强"必须跨过的一道坎。

它和 MCP 不是竞争关系，是互补关系——MCP 让单个 Agent 更有能力，A2A 让多个 Agent 能协作。生产级系统两者都需要。

安全层面，Agent Card 的伪造攻击提醒我们：任何基于自然语言描述做决策的系统组件，都天然存在被对抗性输入操纵的风险，这个教训从提示注入扩展到了多智能体架构层面，需要密码学验证而不是语义信任来兜底。

这个领域还在快速演化中，从协议本身的迭代（v1.0 刚发布不久），到支付结算这类延伸能力的探索，都说明多智能体协作的基础设施层，还有大量工程问题等待被解决。