腾讯云中间件

A2A over MQTT:腾讯云 TDMQ 创新 Agent 协作新模式

Image
Image

导语

随着 AI Agent 技术走向规模化应用,传统的点对点通信模式在分布式场景下面临着服务发现难、耦合度高、可靠性弱等挑战。为此,我们基于腾讯云消息队列 TDMQ MQTT 版,推出 A2A over MQTT 创新方案,旨在通过融合轻量、异步、松耦合的 MQTT 协议与标准化 Agent交互协议,为多智能体协同提供更灵活、可靠、易扩展的通信基础。

该方案已在多个真实场景中落地验证,并成功入选中国信通院 “AI Cloud 中间件助力大模型场景化和工程化落地”典型案例。接下来,我们将结合具体实践,深入解读 A2A over MQTT 如何突破传统限制,助力企业构建下一代分布式智能体平台。

Image

MQTT 协议简介

MQTT(Message Queuing Telemetry Transport)是一种轻量级的消息传输协议,专为低带宽、不可靠网络环境设计。它采用发布-订阅模式,允许设备通过主题进行消息交换。MQTT 具有开销低、易于实现和跨平台的特点,广泛应用于物联网、移动通信和实时数据传输等领域。

Image

Agent-to-Agent(A2A) 协议简介

为了应对 AI 代理的互操作性挑战,Agent-to-Agent(A2A)协议提供了一种标准化框架,使得来自不同供应商的 AI 代理能够以统一的方式进行通信与协作。每个使用 A2A 的代理都会公开标准化的元数据和一组通用的公共方法,使得任何其他代理都能与其交互,无论是委派任务、请求更新,还是协调工作流程。

A2A 协议的工作方式

我们以一个代码生成 Agent 为例,展示 A2A 协议的基本工作流程:

服务发现:找到一个 AI Agent

委派任务之前,首先需要发现并选择一个合适的 Agent。A2A 协议定义了描述 Agent 能力和特征的元数据格式,称为 AgentCard。AgentCard 是一个 JSON 文件,协议约定在 Agent 服务器的以下路径发布:

https://{agent-server-domain}/.well-known/agent-card.json

所以,使用者需要事先知道 Agent 服务器的地址,才能获取到 AgentCard。

执行任务:流式获取状态更新

一旦发现了合适的 Agent,使用者就可以通过 A2A 协议定义的标准方法与其交互。A2A 协议默认使用基于 HTTP 的 JSON-RPC 进行通信。

我们可以调用 sendMessage 方法,将任务请求发送给 Agent。Agent 会处理请求,并通过流式响应不断发送状态更新,直到任务完成。

以「将线程池改写成协程」这个任务为例,首先 Agent 会返回一个初始响应 Task,表示任务已被接受。

{  "id": "12345",  "final": false,  "status": {    "state": "submitted",    "message": "Task has been accepted and is being processed."  }
}

接下来,Agent 会规划代码生成任务执行的各个步骤,并通过 TaskArtifactUpdateEvent 事件返回任务清单和生成的代码:

{  "taskId": "12345",  "artifact": {    "id": "artifact-1",    "name": "TODO List",    "parts": [      {        "kind": "text",        "text": "1. Analyze the existing thread pool implementation.\n2. Design the coroutine-based equivalent.\n3. Implement the coroutine version step by step.\n4. Test the new implementation."      }    ]  }}

随着任务的推进,Agent 会使用 TaskStatusUpdateEvent 持续发送状态更新,直到任务完成:

{  "id": "12345",  "final": true,  "status": {    "state": "completed",    "message": "Task has been completed successfully."  }}

A2A 协议的局限

尽管 A2A 协议为 AI 代理的互操作性提供了一个标准化框架,但其主要着力于定义 Agent 交互流程,却忽略了复杂分布式应用场景下的诸多挑战。由于依赖 HTTP 或 gRPC,A2A 继承了点对点架构的所有限制。这在小型、孤立的系统中可能行得通,但要构建大型 Agent 服务平台则显得力不从心。

服务发现困难

A2A 允许代理通过 AgentCard 互相发现,但仅止于此。目前 A2A 协议仅定义了通过静态 URL 获取 AgentCard 的方式,缺乏动态服务发现机制。当需要委派任务时,必须事先知道所有需要的 Agent 的地址,这增加了调用方的使用门槛和维护复杂性。

上下游强耦合

A2A 协议假设调用方和被调用方之间存在直接的通信路径,这在分布式环境中并不总是可行的。网络分区、防火墙和 NAT 等问题可能阻碍直接通信,导致任务委派失败。

此外,A2A 通过直接的 HTTP 连接将互相通信的代理强耦合在一起。这不仅意味着每个 Agent 都需要配置系统中其他 Agent 的地址,还会导致单点故障。如果某个 Agent 无法访问,整个任务流程可能会中断,影响系统的可靠性和可用性。

状态管理缺失

A2A 协议没有内置状态管理机制,调用方需要自行跟踪任务的状态和进度。而且 HTTP 的无状态特性从根本上与状态管理的需求相冲突,增加了实现的复杂性。特别是在分布式系统中,一个 Agent 可能由多个后端节点提供服务,调用方配置的 URL 一般是负载均衡器地址,这使得任务状态的持续跟踪变得更加困难。

安全性问题

A2A 协议仅设计了带外(out-of-band)鉴权,缺乏服务认证机制,更遑论流控、权限管理等功能。这些均需要 Agent 服务提供方自定义解决方案,增加了实现的复杂性和调用方对接的成本。

Image

A2A over MQTT 接入指南

为了克服 A2A 协议在分布式环境中的局限性,我们提出了 A2A over MQTT 的解决方案。通过将 A2A 协议与 MQTT 协议结合,可以实现更灵活、可靠和可扩展的 Agent 互操作模式。相比于传统的 A2A 协议,A2A over MQTT 具有以下优势:

  • 动态服务发现:利用 MQTT 的保留消息、遗嘱消息和 Request-Response 机制,Agent 可以动态注册和发现其他 Agent。相比于 HTTP 必须预先配置目标 URL,MQTT 允许 Agent 在上线时自动广播身份,下线时自动清理,极大简化了运维配置。

  • 服务端负载均衡:通过 MQTT 的共享订阅机制,可以轻松部署多个 Agent 实例组成集群。Broker 会自动将任务分发给空闲的 Agent,无需额外部署 Nginx 或 LVS 等负载均衡器,天然具备高可用能力。

  • 松耦合架构:通过 MQTT 的发布-订阅模式,调用方和执行方完全解耦,无需各个 Agent 之间进行点对点网状连接。Agent 可以部署在内网中,无需考虑网络打通,只要能连接到 MQTT Broker 即可对外服务。这样大大降低了部署复杂度,提高了系统的弹性和可扩展性。

  • 内置状态管理:利用 MQTT 的持久化消息和 QoS 机制,即使 Agent 暂时离线,消息也不会丢失。上线后可自动接收未处理的任务,实现断点续传。同时,Topic 的层级结构天然支持对任务状态的精细化回溯与追踪。

  • 增强的安全性:复用 MQTT 成熟的 TLS 加密、客户端证书认证和 ACL 权限控制体系。无需像 HTTP 那样在应用层重复造轮子实现鉴权,即可精确控制哪个 Agent 可以发布任务,哪个 Agent 可以接收指令。

Image

我们目前提供以下 SDK 以及示例,帮助开发者快速接入 A2A over MQTT:

  • Python SDK

  • Java SDK

  • Golang SDK

  • Dify 插件

下面以 Python SDK 为例,展示如何使用 A2A over MQTT 发送任务请求:

1. 发现 AgentCard

区别于需要预先知道 Agent 服务器地址的传统 A2A 协议,A2A over MQTT 允许我们通过 MQTT 服务动态发现 AgentCard:


# MQTT broker URLmqtt_broker_url = "mqtt://user0:[email protected]:1883/default-org"# Resolve agent card via agent nameresolver = AgentCardResolver(mqtt_broker_url)agent_card = await resolver.discover_agent("code-generator-agent")# Or fetch all registered agent cardsagent_card_list = await resolver.discover_agents()

2. 创建 A2A over MQTT 客户端并发送任务请求:

# Create client configconfig = ClientConfig()config.supported_transports = ['MQTT']# Create ClientFactory and register MQTT transportfactory = ClientFactory(config)factory.register('MQTT',                  lambda card, url, config, interceptors: MqttTransport(                      mqtt_broker_url,                      card,                  ))# Create A2A client using the factoryclient = factory.create(agent_card)# Send messagemessage = Message(            message_id=str(uuid.uuid4()),            role=Role.user,            parts=[TextPart(text="将线程池改写成协程")],        )response = client.send_message(message)

熟悉 A2A 协议的同学可以发现,以上步骤与开源 A2A SDK 的使用方式几乎一致。这是因为 A2A 协议本身支持对传输层进行变更,我们只需在创建客户端时指定 MQTT 的传输层(MqttTransport)即可。

Image

A2A over TDMQ MQTT 版实践案例

腾讯云消息队列 TDMQ MQTT 版已于 2025 年 1 月正式商业化,目前已服务近百家客户,涵盖出行、教育、金融等行业。

Image

基于 TDMQ MQTT 版产品,A2A over MQTT 方案也已在多个实际项目中得到应用并入围信通院 “AI Cloud 中间件助力大模型场景化和工程化落地” 典型案例,以下是其中的两个典型案例:

Image

服务单个 Agent:消息队列问题诊断助手

作为云上的消息队列服务提供商,我们希望将 AI 能力提供给运维人员,用于诊断和解决消息队列中的各种问题。通过 A2A over MQTT,我们可以构建一个消息队列排障 Agent,并融入到目前的监控告警、问题诊断流水线中。

Image

Agent 服务启动时会将自己的 AgentCard 作为保留消息发布到 Discovery Topic 中,这样运维流水线可以通过订阅 Discovery Topic 的方式实时获取到目前系统中最新的 AgentCard;同时 Agent 会设置遗嘱消息,确保在异常断开连接时,可以清除掉遗留的 AgentCard,这样其他组件能够及时获知 Agent 的不可用状态,重新触发服务发现。

此外,由于该诊断 Agent 运行在生产环境的私有网络中,通常无法被外部流水线直接访问。借助 MQTT 的长连接特性,Agent 只需单向连接 Broker 即可接收来自外部流水线的指令,极大地降低了部署门槛。

Agent 注册 AgentCard 后,会订阅自己的 Task Topic,等待接收任务请求。运维流水线通过 AgentCard 获取到 Agent 的 Task Topic,然后将诊断任务发布到该 Topic 上。Agent 接收到任务请求后,开始执行诊断逻辑,并通过 MQTT 流式返回诊断结果和状态更新。

诊断任务通常耗时较长,传统的 HTTP 请求容易面临超时断连的问题。MQTT 的异步通信机制天然契合此类场景,流水线发布任务后即可挂起,待 Agent 处理完毕后通过回调接收结果,无需维持同步等待,极大提升了系统的稳定性和资源利用率。

分布式 Agent 平台:Cloud Mate AI Agent 平台

智能运维专家 Cloud Mate 是腾讯云打造的智能运维场景的 AI Agent 平台,以精准诊断为核心能力,实现从基础设施到业务系统的全链路覆盖,构建了从问题发现到修复的完整运维闭环。Cloud Mate 平台对外提供的 Agent 服务选用了 A2A 协议,相比于提供数个固定的 Agent 服务,Cloud Mate 具有以下特点:

  1. Agent 数量和每个 Agent 的能力可以动态扩展,用户可以根据需要随时添加、修改或移除 Agent。

  2. Cloud Mate 后端节点是若干台服务器组成的分布式服务,每个节点均能服务任意 Agent,需要负载均衡和高可用能力。

Image

对于服务发现阶段,我们除了支持 AgentCard 注册外,还利用了 MQTT 的共享订阅功能,实现多个后端节点对同一 Agent 的负载均衡:每个 Cloud Mate 节点在启动时,都会使用共享订阅的方式订阅 Discovery Topic。当有新的用户尝试获取某个 Agent 的 AgentCard 时,MQTT 服务会将请求路由到其中一个节点。这样响应请求的节点就会将该 Agent 的 AgentCard 返回给用户。后续的任务请求会按照 AgentCard 中的 Task Topic 发送到该节点,实现请求的粘性路由。

这种架构极大地简化了系统设计。传统的微服务架构通常需要引入 Etcd/Consul 做服务注册发现,引入 Nginx/Gateway 做网关路由。而在 A2A over MQTT 方案中,一个 MQTT Broker 就同时承担了服务注册、负载均衡、消息路由和通信通道的角色,显著降低了基础设施的维护成本和系统复杂度。

每个 Cloud Mate 节点都可以处理任意 Agent 的任务请求,而系统中的 Agent 数量非常多。为了避免每个节点都订阅所有 Agent 的 Task Topic,我们利用 MQTT 的主题通配符功能。这样每个 Server 只需订阅一个通配符 Task Topic 即可服务所有的 Agent,相比于原生 A2A 协议每个 Agent 都要提供一个 HTTP Endpoint 有很大优势。

此外,得益于 MQTT 的 QoS 机制和持久化会话能力,即使在发布过程中出现网络抖动或后端服务重启,任务消息也不会丢失,而是暂存在 Broker 中,待服务恢复后自动投递。这种开箱即用的可靠性保障,使得我们无需在应用层实现复杂的重试和补偿逻辑,就能构建出高可靠的分布式 Agent 系统。

Image

未来展望

A2A over MQTT 通过结合 A2A 协议和 MQTT 协议的优势,提供了一种灵活、可靠和可扩展的 Agent 互操作新模式。未来,我们计划继续完善 A2A over MQTT 的功能,进一步提升其在分布式环境中的表现:

  1. 大文件传输优化:针对多模态 Agent 交互中常见的图片、音频传输场景,探索结合对象存储与 MQTT 的混合传输模式,提升传输效率。

  2. 可观测性增强:构建基于 MQTT 消息链路的分布式追踪系统,可视化 Agent 间的调用拓扑和耗时,帮助开发者快速定位性能瓶颈。

  3. 生态融合:推动 A2A over MQTT 成为 LangChain、AutoGen 等主流 Agent 框架的标准传输层适配器,降低开发者的接入成本。

未来我们将推动 MQTT Transport 成为 A2A 标准协议的一部分,方便更大范围的推广和落地。还将探索更多的应用场景,以推动 AI Agent 技术的发展和普及。

往期

推荐

《腾讯云 RocketMQ 5.x:如何兼容 Remoting 全系列客户端》

《Kafka 集群上云新突破:腾讯云 CKafka 联邦迁移方案》

《TDMQ RabbitMQ Serverless 版限时特惠:新用户免费体验,全员尊享最低6折起购!》

《CKafka 连接器:一站式搭建高效的数据流转通道》

Image

扫描下方二维码关注本公众号,

了解更多微服务、消息队列的相关信息!

解锁超多鹅厂周边!

Image
图片 戳原文,查看消息队列 MQTT 版的信息!
图片

点个在看你最好看