mq9 SDK：完整 Agent 异步通信解决方案
最近，mq9 支持了 Agent 注册中心的能力。闭环了 Agent 从注册、发现、到通信的全流程。为了使用方便，准备给 mq9 加个 SDK。在我们当前的设想中，SDK 主要包含会解决两个问题：
- 让 mq9 的协议在各个语言上使用更加方便（当然，也可以支持 Nats SDK 直接使用）。
- 让 A2A 很简单方便的运行在 mq9 上
我们最开始一直避免自己开发维护 SDK，认为用户会排斥使用新的SDK，所以最开始的设想是推荐使用原生的 Nats SDK。但是我们逐渐发现，如果我们支持MQ9 SDK（实际是对Nats SDK的封装，在Nats 协议上运行Mq9协议），那么用户（Agent）的使用将会很便捷（后面用代码来说明）。
另一方面从技术上看，mq9 SDK 基于成熟的 Nats SDK 开发，工作量并不大，稳定性可控。
所以我们认为：一个完整的Agent 异步通信方案是：Broker + SDK。broker 符合把 Agent 异步通信做好用，SDK 负责把 broker 的能力用最少代码暴露给用户。同时SDK 包装 a2a-sdk 提供轻量 facade，业务方 15 行代码就能写一个 A2A Agent 跑在 mq9 上。
Broker 和 SDK 各自的作用是：
| 维度 | broker | SDK |
|---|---|---|
| 解决的问题 | Agent 之间怎么可靠通信 | 用户怎么用得更好 |
| 角色 | 通信能力的来源 | 通信能力的释放 |
| 单独存在的局限 | 用户够不到 | 没有 broker 只是又一个 wrapper |
| 组合后的效果 | 业务方 15 行代码完成可靠 Agent 通信 |
Broker 和 SDk 合在一起，mq9 同时解决了 Agent 通信的两个核心痛点：
Agent 注册和发现：我的 Agent 在哪、对方 Agent 在哪、谁有能力做我需要的事。mq9 broker 内置 AGENT.REGISTER 和 AGENT.DISCOVER，支持文本检索、语义检索、tag 过滤，开箱即用。
Agent 之间的可靠通信：消息怎么不丢、怎么按优先级处理、怎么 N-to-N 协作、长任务怎么恢复、双方不在线怎么办。mq9 mailbox 模型为这些场景设计，配合 SDK 让业务方 15 行代码就能用上。
这两个痛点是 Agent 通信场景天然存在的。当前生态里没有任何一个项目同时把这两个痛点解决到"开箱即用"的程度。要么只做注册（AWS Registry），要么只做传输的小修小补（A2A 默认 HTTP），要么做全家桶（Bindu/Aira/Inai）把核心痛点淹没在十几个功能里。
mq9 希望把这两件事做扎实，让 Agent 的可靠通信变得非常简单。这就是"Agent 异步通信完整方案"的具体含义：业务方面对 mq9 看到的是"我的 Agent 怎么和别的 Agent 通信"这个完整问题的答案，不需要再去拼凑底层组件。
从这点看，mq9 不能只是看作是"消息队列"，它从消息队列出发，为了解决Agent 通信问题不断演进，从而让产品定位慢慢不同。来看一下对比
| 维度 | 传统消息队列（Kafka/RabbitMQ） | mq9 |
|---|---|---|
| 抽象单元 | topic / queue | mailbox（Agent 地址语义） |
| 服务对象 | 通用消息流 | 专为 Agent 通信场景设计 |
| 发现能力 | 无 | 内置注册中心 + 语义检索 |
| 协议无关性 | 通用字节流 | 通用字节流 + 主流 Agent 协议封装 |
| 接入复杂度 | 业务方写胶水代码 | 业务方 15 行代码 |
| 长期方向 | 通用 throughput 和 retention | Agent 场景的安全、审计、可观测 |
比如 Kafka 就不会内置 "agent.translator.inbox" 这种 Agent 地址语义，因为它的定位是通用消息基础设施。mq9 的定位是 Agent 通信场景，所有设计都围绕这个场景展开。两者是不同场景的专门工具，不是替代关系。一个公司在数据团队用 Kafka、在 Agent 平台用 mq9，是合理的并存。
往后看，mq9 可能会做一些事情，都是为 Agent 通信场景专门增强的能力，不是消息队列传统关心的方向。比如
安全：Agent 之间通信涉及业务系统、用户数据、决策权限。一个能调用核心交易系统的 Agent 和一个翻译 Agent 不能用同样的访问控制。mq9 可以做 Agent 级别的认证授权，不只是 topic ACL。
审计：Agent 做了什么决策、调用了什么 Agent、传递了什么消息，需要可审计、可追溯，特别是金融、医疗、法律等高风险场景。broker 的消息持久化天然适合做审计基础，加 SDK 层的轨迹采集就是完整审计能力。
可观测：Agent 协作经常涉及多个 Agent 串联，出问题时谁慢、谁失败、消息卡在哪。broker 上的消息天然可以承载 OpenTelemetry trace context。
合规：Agent 通信进入金融、医疗等强监管行业是大概率的事。消息保留期、数据脱敏、跨境传输管控这些都是合规要求。架构上提前想好比事后改容易。
接下来我们会分享 A2A over mq9 上的相关 Demo，看 mq9 是如何承载 Agent 异步通信的。其实 mq9 也是在慢慢摸索中～。