![开场图](https://developer.qcloudimg.com/http-save/yehe-9261324/6930e2b94813764541b097e01af1393d.png)

跨框架 Agent 协作常被简化成“互相调 HTTP 接口”。真到生产环境，问题立刻变成：对方是谁、能做什么、任务进行到哪、结果放在哪、失败后怎么补偿、跨租户谁负责审计。A2A 的价值不在于多一个端点，而在于把 Agent 之间的协作抽象成可发现、可跟踪、可交付的任务协议。

## 场景：订单 Agent 委派物流 Agent

假设订单 Agent 收到用户询问“我的包裹到哪了”。它不直接调用物流系统，而是把查询轨迹委派给物流 Agent，拿到结果后再交给客服 Agent 组织回复。三个 Agent 可能由不同团队、不同框架实现，彼此不共享记忆、工具和推理过程。

协作从能力发现开始。物流 Agent 作为 A2A Server 提供 Agent Card，声明身份、技能、接口和交互要求。订单 Agent 通过 well-known URI、Agent Registry 或预配置地址拿到卡片，判断对方是否支持轨迹查询、需要什么认证、是否支持流式。这里要克制：Agent Card 是能力与接口声明，不是安全背书，也不是商业信用证明。

## 一次任务的生命周期

订单 Agent 发送 Message 发起任务，消息里带订单号、查询意图和业务幂等键。物流 Agent 创建 Task，返回任务标识和状态。若需要补充信息，任务进入 INPUT_REQUIRED；若认证不足，返回 AUTH_REQUIRED。客户端可以轮询 Get Task，也可以订阅流式消息，或配置 Webhook 接收异步通知。

任务结果不应从 Message 里“捞”。Message 适合发起、补充输入、澄清和状态沟通；最终输出应通过 Task 关联的 Artifact 交付。Part 承载文本、文件或结构化数据，Artifact 承载结果。把 Message 当可靠结果存储，会在重试、流式分片和长任务中丢上下文。

订单 Agent 拿到 Artifact 后，再把结构化轨迹交给客服 Agent。客服 Agent 同样通过自己的 Agent Card 暴露能力，订单 Agent 只交换任务，不暴露内部工具和推理链。

## A2A 与 MCP 的边界

A2A 负责 Agent-to-Agent 的任务协作；MCP 负责 Agent 与工具、数据源之间的连接。两者不是替代关系。物流 Agent 内部可以用 MCP 查物流数据库，但对外仍通过 A2A 接收任务、返回 Artifact。把 A2A 当成工具调用协议，或把 MCP 当成跨组织任务协议，都会让边界失焦。

## 协议绑定与 SDK 验证

A2A 1.0 不应被简化为单一 JSON-RPC HTTP 端点。规范定义数据模型与操作，并支持 JSON-RPC、HTTP+JSON/REST、gRPC 等绑定；官方 Python SDK 1.0 支持这些绑定，并保留 0.3 兼容模式。以下为教学示例，运行条件为 Python 3.10+，并安装 `pip install "a2a-sdk[http-server]"`：

```python
from a2a.server.apps import A2AStarletteApplication
from a2a.server.request_handlers import DefaultRequestHandler
from a2a.server.tasks import InMemoryTaskStore
from a2a.types import AgentCard, AgentSkill

card = AgentCard(
    name="logistics-agent",
    description="查询物流轨迹",
    url="http://localhost:9999/",
    skills=[AgentSkill(id="track", name="轨迹查询")],
)

handler = DefaultRequestHandler(
    agent_executor=MyLogisticsExecutor(),
    task_store=InMemoryTaskStore(),
)
app = A2AStarletteApplication(agent_card=card, http_handler=handler).build()
```

启动远端 Agent 后，用 Client 拉取 Agent Card、发送 Message、轮询 Task 并读取 Artifact。官方 Hello World 样例适合验证这条链路，但不要把它当成生产模板：内存任务存储、无认证、无持久化都只适合本地验证。

## 可靠性：协议给的是接口，不是治理

Send Message 的幂等行为允许实现方利用 messageId 去重，但规范并未保证所有实现自动幂等。业务侧仍需设计幂等键、任务状态持久化、超时、取消、补偿与重试。重复投递可能来自客户端重试、Webhook 重放或网络超时，服务端要用业务键和任务状态机兜住。

AUTH_REQUIRED 和 INPUT_REQUIRED 是任务状态，不是异常噪音。前者要求客户端补认证，后者要求补输入；两者都应可恢复，而不是直接失败。取消和超时要落到任务状态机，并明确“取消后是否还能返回部分 Artifact”。跨租户场景还要在服务端做租户隔离和审计，Agent Card 里的认证方案只说明怎么认证，不自动等于组织级授权。

## 生产验收清单

我通常按这几项验收：Agent Card 是否准确描述能力和认证要求；任务状态是否持久化并可查询；Message 与 Artifact 是否职责分离；轮询、流式、Webhook 是否按任务时长选择；幂等键、超时、取消、补偿是否覆盖；跨租户授权和审计日志是否落在服务端；A2A 与 MCP 的边界是否清晰。

商业化上，这套协议会推动 Agent 目录、跨组织连接、SLA、任务计费和审计网络。但协议兼容不等于业务语义一致：两个 Agent 都能收发 Task，不代表它们对“轨迹查询”的字段、时效和失败定义相同。真正的协作，是协议化交换任务，同时把业务契约和治理留在各自边界内。

![结束图](https://developer.qcloudimg.com/http-save/yehe-9261324/caecfa94ad9c7c91f1a26160536f6318.png)

跨框架 Agent 协作常被简化成“互相调 HTTP 接口”。真到生产环境，问题立刻变成：对方是谁、能做什么、任务进行到哪、结果放在哪、失败后怎么补偿、跨租户谁负责审计。A2A 的价值不在于多一个端点，而在于把 Agent 之间的协作抽象成可发现、可跟踪、可交付的任务协议。

90:AAIF开源项目A2A研究实践-Agent 之间如何真正协作？

从订单、物流、客服场景出发，拆解 A2A 的能力发现、任务委派、状态跟踪与结果交付，并划清协议保证、SDK 能力与业务自建机制的边界。

架构师

人工智能

架构设计

后端

跨框架Agent协作不应简化为HTTP调用，而需通过A2A协议实现任务的可发现、可跟踪与可交付。AgentCard声明能力，Task生命周期管理状态，Artifact交付结果，区分于MCP工具连接。生产环境需关注幂等、补偿、租户隔离及协议与业务契约的边界。

结构化数据

代码解释

数据库

流数据

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

90:AAIF开源项目A2A研究实践-Agent 之间如何真正协作？-腾讯云开发者社区-腾讯云

90:AAIF开源项目A2A研究实践-Agent 之间如何真正协作？

90:AAIF开源项目A2A研究实践-Agent 之间如何真正协作？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐