A2A v1.0 正式加入 AAIF 基金会:Agent 互操作协议标准化迈出关键一步
Google 主导的 Agent-to-Agent(A2A)协议 v1.0 正式加入 AI Agent 互操作性基金会(AAIF),标志着跨厂商 Agent 通信标准从"各自定义的 JSON"走向统一协议层。本文拆解 A2A v1.0 的核心机制、与 MCP 的协作关系,以及这一变化对开发者意味着什么:你的 Agent 未来可能不再需要为每个平台写一套适配层。
A2A v1.0 加入 AAIF 意味着什么
A2A(Agent-to-Agent)协议从 Google 的单方面推动,变成了一个由基金会治理的开放标准。AAIF(AI Agent Interoperability Foundation)在 8 月 21 日正式接纳 A2A v1.0,Google、Microsoft、Salesforce、SAP 等多家企业参与了标准制定。
A2A 的协议草案已经存在了几个月,技术本身不是新闻。真正重要的是治理权的转移:从一家公司的实验性协议,变成多方治理的行业标准。这意味着 API 的稳定性、向后兼容性承诺、以及更广泛的生态支持都有了保障。
A2A 协议核心机制拆解
A2A v1.0 定义了 Agent 之间通信的四个核心组件。
| 组件 | 作用 | 对应协议层 |
|---|---|---|
| Agent Card | Agent 的能力声明文件,类似 OpenAPI Spec | 发现层 |
| Task | 跨 Agent 的任务单元,包含状态、优先级、回调 | 执行层 |
| Message | Agent 间的消息格式,支持多模态(文本+结构化数据+文件引用) | 通信层 |
| Artifact | 任务产出物(代码、文档、分析结果),附带版本和签名 | 持久层 |
一个典型的 A2A 交互流程:Agent A 通过 Agent Card 发现 Agent B 的能力,创建一个 Task 发送给 B,B 处理过程中通过 Message 更新状态,完成后通过 Artifact 返回结果。A 在收到 Artifact 后进行验证和签名校验。
下面是一个精简的 Agent Card 定义示例:
# 本代码仅概念演示,不可直接投入生产环境,仅供学习参考
{
"agentCard": {
"name": "code-review-agent",
"version": "1.0.0",
"capabilities": ["code_review", "security_scan"],
"endpoint": "https://agent.example.com/a2a",
"auth": {
"type": "oauth2",
"scopes": ["a2a.task.read", "a2a.task.write"]
},
"rateLimit": {
"maxRequestsPerMinute": 60,
"maxConcurrentTasks": 5
}
},
"supportedTasks": [
{
"type": "code_review",
"inputSchema": { "language": "string", "code": "string" },
"outputSchema": { "issues": "array", "score": "number" },
"estimatedLatency": "30s-120s"
}
]
}
这个 Agent Card 告诉其他 Agent:我能做代码审查和安全扫描,通过 OAuth2 认证,每分钟最多 60 个请求,最多同时处理 5 个任务。其他 Agent 不需要知道这个 Agent 内部是用什么模型、什么框架实现的,只需要知道它的能力声明和调用方式。
A2A 与 MCP:互补还是竞争
这是开发者问得最多的问题。
| 维度 | A2A(Agent-to-Agent) | MCP(Model Context Protocol) |
|---|---|---|
| 通信对象 | Agent ↔ Agent | Agent ↔ 工具/数据源 |
| 核心问题 | Agent 之间如何协作 | Agent 如何调用外部资源 |
| 协议层级 | 应用层(任务调度、状态管理) | 传输层(上下文注入、工具调用) |
| 治理 | AAIF 基金会 | Anthropic 主导 |
| 典型场景 | 多 Agent 协作完成复杂任务 | 单个 Agent 连接数据库、API、文件系统 |
A2A 和 MCP 不是竞争关系,而是解决不同层级的问题。MCP 让一个 Agent 能"看到"和"操作"外部世界,A2A 让多个 Agent 能"对话"和"协作"。在 Sophnet 的 Sophclaw 平台上,我们同时支持两种协议:Agent 通过 MCP 接入工具链,通过 A2A 实现 Agent 间编排。
一个实际的场景:一个软件开发 Agent 通过 MCP 连接 GitHub API 获取代码,通过 A2A 把代码发给另一个 Code Review Agent 做审查,审查结果再通过 A2A 返回。两个协议各司其职。
开发者视角:协议统一对技术栈的影响
协议标准化带来的直接好处是减少了适配层的工作量。目前如果你想让一个 Agent 同时对接多个平台(比如 LangChain 的 Agent 和 CrewAI 的 Agent),你需要为每个平台写一套消息格式转换。A2A 标准化后,理论上任何实现了 A2A 协议的 Agent 都可以直接通信。
但实际落地还需要时间。A2A v1.0 刚刚加入 AAIF,各框架的适配需要几个月。目前 LangChain、CrewAI、AutoGen 都已经宣布了 A2A 适配计划,但都处于"开发中"状态。
对于在企业中部署 Agent 的团队,我的建议是:现在可以开始关注 A2A 的协议细节,但不要立即在生产环境中大规模迁移。更好的做法是在新项目中预留 A2A 适配接口,等框架适配成熟后再切换。
适用场景与限制
A2A v1.0 适合以下场景:
- 多 Agent 协作(如开发 Agent + 审查 Agent + 部署 Agent 的流水线)
- 跨平台 Agent 编排(不同团队用不同框架,但需要 Agent 间通信)
- Agent 市场/生态(通过标准化的 Agent Card 发现和调用第三方 Agent)
当前版本的限制:
- 不支持流式通信(v1.0 是请求-响应模式,v1.1 计划加入 WebSocket 支持)
- Artifact 的版本管理比较基础(只有 hash 校验,没有语义版本控制)
- 安全模型依赖 OAuth2,对于企业内部 Agent 间的零信任通信需要额外配置
- 各框架的适配进度不一致,短期内仍需维护兼容层
协议统一是 Agent 生态走向成熟的关键一步。A2A 加入 AAIF 意味着这个方向已经从"会不会有标准"变成了"标准什么时候落地"。对于开发者来说,现在是最好的学习窗口。协议细节已经公开,但生态还没有固化,有足够的时间理解、实验和准备。
更多推荐


所有评论(0)