EMQX 6.2 新特性：A2A over MQTT 智能体发现与协作

标准的 A2A 协议以 HTTP 作为传输层，在云端环境中运行良好，却难以适配资源受限的边缘设备，而这恰恰是 MQTT 的强项。

EMQX 6.2 引入了 A2A over MQTT，一种 Broker 中立的传输扩展方案，无需额外基础设施，即可将符合 A2A 规范的智能体发现与协作能力延伸至边缘场景。

智能体将结构化 Agent Card 作为保留消息发布到标准发现主题：

$a2a/v1/discovery/{org_id}/{unit_id}/{agent_id}

 来完成注册。

订阅者连接后立刻获取全量已注册节点信息，并在智能体上下线时实时收到更新。无需轮询，也无需独立的注册服务。

• 事件驱动的发现机制：智能体发布一次 Agent Card 就立即可被发现，上下线变化实时推送。

• 内置在线状态感知：EMQX 在发现消息中附加 a2a-status
 用户属性（
online
  、offline
  、lwt
  ），将发现与存活检测整合到单一的订阅流中。

• 灵活的交互模式：智能体通过 MQTT v5 的「响应主题」和「关联数据」属性进行通信，支持请求/响应、流式响应、多轮对话、负载均衡池调度以及智能体实例间的任务移交。

• Schema 校验：Agent Card 在注册时可依据 A2A 规范进行校验，不合规的 Agent Card 在进入注册表前即被拒绝。

• Dashboard 界面与 CLI：运维人员可通过 EMQX Dashboard 或 emqx ctl a2a-registry
   命令管理 Agent Card。

• 机器可读的 API 规范：新增/api-spec.md
   和 /api-spec.html
 端点，对外暴露 EMQX HTTP API 的精简视图，Claude Code、Codex 等工具可直接调用这些端点与 EMQX 交互。
  

A2A Registry 遵循不断演进中的 A2A 协议规范，并将作为即将推出的各类基于 Agent 的产品的底层基础——其中就包括 EMQ 的 Device Agent，目前该产品已开放早期体验。

在某工厂自动化系统中，边缘网关上的监控智能体检测到 7 号电机生产线出现异常振动。

• 监控智能体通过订阅 $a2a/v1/discovery/com.example/factory-a/+
   发现了一个维修智能体，收到 Broker 推送的 Agent Card 后发起任务请求。

• 维修智能体流式推送状态更新——「正在分析振动特征」、「检测到轴承磨损」；监控智能体据此触发维修工单。

整个协作过程中，两个智能体互不知晓对方的网络地址，EMQX 的认证与授权对所有智能体通信统一生效。

了解更多关于 A2A over MQTT 的内容：

https://docs.emqx.com/zh/emqx/latest/emqx-ai/a2a-over-mqtt/overview.html

sensor/+/temperature?location=roomA&value>25

EMQX 6.2 新增了在运行时动态调整客户端 Keep Alive 间隔，无需断开重连。

客户端可通过向 $SETOPTS/mqtt/keepalive
 发布消息来更新自身的 Keep Alive 设置；后端系统则可通过 $SETOPTS/mqtt/keepalive-bulk
 批量更新设备集群，多个会话应用可以同步变更。

某电动汽车制造商管理着逾 10 万辆联网车辆。

车辆进入低功耗停车状态时，通过 $SETOPTS/mqtt/keepalive-bulk
 延长 Keep Alive 间隔，降低空闲网络流量和电池消耗；车辆重新点火后，原始间隔自动恢复——全程无需重连，会话不中断，在途消息不受影响。

了解更多关于动态 Keep Alive 调整的内容：

EMQX 6.2 新增两个集成目标，并增强了现有 GCP 连接器的安全性。

• Azure Event Grid

实现 EMQX 与 Azure 全托管事件路由服务之间的双向 MQTT 桥接。EMQX 以 MQTT 客户端身份接入，通过 TLS 和客户端证书认证建立连接，支持 Sink 与 Source 双向数据流。数据进入 Azure Event Grid 后，可自然流转至 Azure Functions、Event Hubs、Storage 等 Azure 服务。

• QuasarDB

将 MQTT 数据直接写入 QuasarDB——一款高性能列式时序数据库。消息经由规则引擎通过 ODBC 批量写入 QuasarDB，非常适合需要在大时间窗口上进行快速范围查询的高频工业遥测场景。

• GCP 工作负载身份联合（Workload Identity Federation）

GCP 连接器（Pub/Sub 生产者、Pub/Sub 消费者、BigQuery）现已支持通过服务账户模拟（Service Account Impersonation）进行 WIF 认证。

EMQX 从外部身份提供商（如 Azure Entra ID）获取短效 OIDC 令牌，换取临时 GCP 凭证，彻底消除了长期服务账户密钥文件的存储与轮换负担。

EMQX 的 NATS 网关允许 NATS 客户端连接到 EMQX，并与 MQTT 双向互通消息。在 6.2 版本中，该网关新增了 Token、NKey 和 JWT 三种内部认证方式，填补了与原生 NATS Server 之间的主要能力差距。

• Token 认证：基于共享密钥的轻量认证，适用于开发环境或简单部署场景。

• NKey 认证：基于 Ed25519 密钥对的加密身份认证，是 NATS 生产环境的标准机制。

• JWT 认证：完整的 NATS JWT 凭证链校验，支持运营商/账户/用户的层级体系。

将 NATS 工作负载迁移至 EMQX 的团队无需修改任何客户端侧认证配置，NATS 客户端对 EMQX 的认证体验与面对原生 NATS Server 完全一致。

了解更多关于配置 NATS 网关内部认证的内容：

EMQX 6.2 引入了 UNS 治理插件 emqx_unsgov
 ，在 ACL 检查阶段强制执行统一命名空间（UNS）主题结构，并可在发布处理环节进行可选的 Payload Schema 校验。

在大规模物联网部署中，随着团队扩张和固件迭代，主题结构往往会发生漂移。缺乏 Broker 级别的强制管控，格式有误的数据就会静默地流入管道，直到被下游系统发现才能察觉。UNS 治理采用快速失败（fail-fast）策略：不合规的发布在源头即被拦截，确保下游系统的数据清洁。

插件以模型为核心，每个模型是一份 JSON 文档，定义主题树结构、可变段的约束条件以及各端点节点的可选 Payload Schema。

主题与激活的模型在 ACL 检查阶段进行匹配；若匹配失败，对 QoS 1/2 消息返回Not Authorized，对 QoS 0 消息静默丢弃。

Payload 校验在发布处理环节单独执行，不合规的 Payload 直接丢弃，不触发认证拒绝。如果没有任何模型处于启用状态，所有未豁免的主题默认拒绝（fail-closed）。

某制造业运营商定义了一个模型：

要求有效主题遵循 sdefault/{site_id}/Lines/{line_id}/LineControl
  格式，
site_id
 和 line_id
 须匹配正则约束，LineControl
 端点要求 Payload 包含 Status
 和 Mode
 字段。

某设备向格式错误主题发布消息，在 ACL 检查时将直接收到 Not Authorized
；向合法主题发布消息但 Payload 不合规，消息在发布处理环节将被丢弃。无论哪种情况，违规信息都会立即出现在 recent_drops
 中，在不合规数据到达任何下游系统之前就将其拦截。

了解更多关于 UNS 治理的内容：