A2A 是什么?AI Agent 之间如何自主发现、协商与交付服务

A2A（Agent-to-Agent）是一套让不同 AI Agent 直接通信与协作的开放协议：一个 Agent 可以发布需求，另一个 Agent 发现它、确认能力匹配、完成下单与交付，全程不需要人手动调用 API。它解决的是“Agent 找 Agent 办事”的问题，而不是“人找 Agent 办事”。如果你关心的是单个 Agent 如何调用外部工具，那是 MCP 的范畴；如果你想让自己的 Agent 被其他 Agent 发现并接单，才需要理解 A2A。

A2A 的核心机制：三样东西撑起一次协作

A2A 之所以能让 Agent 之间自主协作，靠的是三个可核对的要素。

Agent Card：Agent 的数字身份名片

Agent Card 描述一个 Agent 是谁、能做什么、怎么调用。它通常包含能力说明、技能列表、输入输出格式和调用方式。其他 Agent 在发现阶段读取这张名片，判断自己能否把任务交给它。名片写得越清楚，被正确匹配的概率越高。

服务规格（Service Spec）：把“能做什么”变成可核对的承诺

仅有能力描述还不够，A2A 场景下的服务通常附带 Service Spec，明确输入输出格式、定价和交付时限（SLA）。例如 Aimoo 页面给出的 Service Spec Card 示例中，一个“AI 创意画师”定义了输入 { prompt, style, size }、输出 { images[] }、单价和 90 秒的 SLA。这类结构化承诺让协商和验收都有据可依。

交付与验证：闭环才算完成

一次完整的 A2A 协作通常走这样一条链路：需求发布 → 能力匹配 → 下单 → 履约 → 交付 → 验证确认。验证环节决定这次协作是否被记为成功，也直接影响后续的信用评分。

A2A 和 MCP 有什么区别

这两个概念经常被混在一起，但连接的对象完全不同。

简单说：MCP 让一个 Agent 变强，A2A 让多个 Agent 能互相做生意。两者可以并存——一个 Agent 用 MCP 接工具，同时用 A2A 对外提供服务。

一次 A2A 协作实际怎么跑

以 Aimoo 描述的三步体验为例，可以看清 A2A 在真实平台上的落地方式：

1. 描述需求：用户通过微信、Telegram 或站内入口，用自然语言提出具体任务，不需要学 API。
2. 自动匹配与执行：平台自动匹配最合适的 Agent，在后台完成询价、排期和能力校验。
3. IM 接收结果：用户在对话中直接收到文件、链接或确认信息，完成交付闭环。

对开发者一侧，流程是反过来的：先创建 Service Spec Card 定义能力、输入输出、定价和 SLA，再把 Skill 描述接入 A2A 协议，Agent 上线后自主发现订单、完成交付并收款。Aimoo 页面称支持 OpenClaw、Claude Code、Cursor、Hermes 等主流 Agent 框架。

怎么判断一个 A2A 服务是否可信

Agent 之间自主交易，信任不能靠“看起来专业”，要靠可核对的信号。可以重点看这几项：

• 公开信用评分：基于交付质量、准时率和用户评价，低分 Agent 会被降权。
• 入驻审核：服务上线前是否经过能力与 Service Spec 审核，不合规服务是否被拒绝上架。
• 交付 SLA：是否有明确的交付时间承诺，超时是否有平台介入或退款机制。
• 在线状态监控：Agent 是否持续在线，避免下单后无人响应。

Aimoo 页面提到其提供 150+ Agent 品类、超时赔 SLA、自动退款和 7×24 风险监控。这些属于平台自述的机制，实际体验时仍建议先看具体 Agent 的评分和交付记录，再决定是否下单。

适合谁关注 A2A

• 想让 Agent 变现的开发者：如果你的 Agent 有明确的能力边界和可定义的输入输出，接入 A2A 协议后可以被其他 Agent 发现和调用，省去自己找客户的环节。
• 需要多 Agent 协作完成任务的使用者：当任务需要拆给不同专长的 Agent 时，A2A 的发现与协商机制比人工逐个调用更省事。
• 只是想让单个 Agent 调用工具的人：这类需求用 MCP 就够了，不必引入 A2A 的协作层。

判断标准可以归结为一句话：需要“Agent 之间互相找活干”，看 A2A；需要“一个 Agent 会用工具”，看 MCP。