AI Agent 擅长理解遥测数据、制定计划并调用工具；设备网络面对的则是另一组问题：链路时断时续、终端资源有限、主题权限、投递语义，以及会真实影响物理世界的控制指令。
MQTT 很适合成为两者之间的边界。它为遥测与指令提供统一事件通道，同时把设备连接管理留在 Agent 运行时之外。但 MQTT 本身并不会让 Agent 自动变得安全，真正的安全来自 Broker 周围的策略、校验和审批层。
参考架构
一条生产级链路通常包含五部分：
- 设备与网关向 MQTT 主题发布遥测和状态。
- Broker 验证客户端身份，并执行发布、订阅权限。
- 接入服务校验载荷、补充上下文，再向 Agent 暴露收窄后的事件流。
- Agent 通过有类型约束的工具提出操作，不直接发布任意 MQTT 消息。
- 指令服务检查策略、审批状态、时效与设备能力，最后才发布指令。
这种分层可以阻止提示词内容直接变成 Broker 凭据或主题过滤器。
设备 -> MQTT Broker -> 已校验事件 -> Agent
Agent -> 类型化工具 -> 策略与审批 -> MQTT 指令 -> 设备
分开观察与控制权限
观察与控制应使用不同主题、身份和权限。
sites/{siteId}/devices/{deviceId}/telemetry
sites/{siteId}/devices/{deviceId}/state
sites/{siteId}/devices/{deviceId}/commands/request
sites/{siteId}/devices/{deviceId}/commands/result
向 Agent 提供上下文的服务可以订阅遥测，但不应顺带获得指令发布权限。指令执行器只应拥有最窄的发布范围，更不能修改自己的权限策略。
把指令变成类型化操作
不要给模型一个通用的 mqtt_publish(topic, payload) 工具。应围绕业务意图定义操作：
{
"operation": "set_temperature_target",
"deviceId": "chiller-07",
"targetCelsius": 6,
"reason": "将偏差降回已批准区间",
"requestId": "req_01J..."
}
指令服务负责解析目标主题、校验温度范围、确认设备能力并写入审计记录。Agent 不需要选择通配主题，也不会接触连接凭据。
按后果等级设置审批边界
并非所有操作都需要人工确认，但每种操作都必须有明确的后果等级。
| 等级 | 示例 | 控制方式 |
|---|---|---|
| 观察 | 读取最新温度 | 自动、只读 |
| 建议 | 建议维护时间 | 自动生成建议 |
| 可逆控制 | 在安全范围内调整非关键设定值 | 策略校验 |
| 高后果 | 停机或解锁门禁 | 明确审批与独立安全保护 |
物理设备必须保留本地安全上限。云端 Agent 不能成为阻止危险操作的唯一防线。
让每条指令都能过期
一条指令即使最初合理，也可能因延迟投递而变得危险。至少应包含：
- 唯一请求 ID；
- 签发时间与过期时间；
- 预期设备状态或版本；
- 发起主体；
- 策略判定与审批记录；
- 幂等键。
MQTT 5 的消息过期可以减少迟到投递，但设备端仍应拒绝已过期或乱序的指令。
把响应当作证据，而不是确定结果
MQTT 发布成功只说明 Broker 按选定 QoS 流程接收了消息，并不代表设备已经执行操作。
应通过独立结果主题和关联 ID 返回执行状态：
{
"requestId": "req_01J...",
"status": "applied",
"deviceStateVersion": 1843,
"observedAt": "2026-07-27T09:30:00Z"
}
这样工作流才能区分已接收、已投递、已执行、已拒绝、已过期和超时。
真正重要的运行控制
在 Agent 接入 MQTT 之前：
- 为每个服务签发独立身份并定期轮换；
- 按工具配置精确的主题白名单；
- 使用版本化 Schema 校验载荷；
- 限制单设备的指令速率和并发；
- 记录建议、审批、策略结果、发布动作与设备回执；
- 测试重复投递、重连、过期保留消息和部分失败；
- 在 Agent 链路之外保留紧急停止能力。
更稳妥的顺序是先接入只读遥测和离线建议；待审计链路与故障处理真正可观测后，再加入边界清晰的指令执行。
继续阅读 MQTT 安全指南了解身份与授权设计，阅读 MQTT 协议概览理解会话和投递行为；如果 Agent 同时需要持久事件回放，可参考 MQTT 与 Kafka 对比。