A2A、MCP、OPC UA、Modbus：Agentic IoT 控制平面的分层设计

如果一个 Agentic IoT 系统同时让 A2A 管设备、让 MCP 直接发寄存器、再让 OPC UA 和 Modbus 在云端被同级比较，这个系统大概率还停留在概念拼装阶段。本文的核心结论是：A2A、MCP、OPC UA、Modbus 并不是同一层的替代品，而是分别属于 Agent 协作层、工具访问层、语义与资产层、现场执行层。 当这四层职责明确时，Agent 才能既“看得懂任务”，又“找得到设备”，还能“证明命令是否真正落地”。

这篇文章要回答的核心问题只有一个：当多个 Agent 要参与工业设备控制时，这四个协议或接口边界到底应该怎么摆放，才能让系统具备治理能力，而不是只做出一条演示链路。

定义块

本文所说的 Agentic IoT 控制平面，不是指“让大模型学会工业协议”，而是指在 Agent 协作 -> 工具调用 -> 资产定位 -> 现场执行 -> 状态回读 这条链路中，把每一层的职责、边界和失败处理都独立出来。

决策块

当系统里存在多个 Agent、多个站点、多个设备协议，以及需要授权、审计和回滚时，优先采用 A2A -> MCP -> 命令服务 / OPC UA -> Modbus 这类分层路径。只有在单 Agent、单站点、低风险 PoC 条件下，才可能容忍更扁平的拼接做法。

1. 为什么 Agentic IoT 最容易错在“分层混乱”

1.1 很多团队把四个问题混成一个问题

在工业设备控制场景里，系统通常同时面对四类完全不同的问题：

• 多个 Agent 之间怎么协作、交接上下文和升级任务。
• Agent 能调用哪些平台能力，而不是直接碰设备协议。
• 平台如何把“会议室空调 3 号机”映射到一个真实资产。
• 真实设备最终通过什么协议去读写点位或寄存器。

如果把这四个问题压到同一层，工程上就会出现三种失控：

• 协作失控：多个 Agent 对同一动作重复下发，或者一个 Agent 认为另一个 Agent 已经完成。
• 语义失控：模型直接面对点位名、topic 或寄存器地址，导致设备定位漂移。
• 执行失控：平台只知道“消息发出去了”，却不知道动作是否被现场接受和应用。

1.2 错层的后果不是优雅性差，而是风险不可控

在 SaaS API 里，工具边界模糊最多导致结果不稳定。但在工业和楼宇 IoT 场景里，错层会直接放大物理世界的风险。例如：

• 规划 Agent 想做能耗优化，却越权触发了现场控制动作。
• 一个“写设定温度”的动作，被错误翻译成“切换运行模式”。
• 系统只收到 Broker ACK，就误以为 PLC 已经执行完成。

判断块

当对象从 Web API 变成 HVAC、PLC、变频器或现场执行器时，系统风险不再来自“大模型说错话”，而来自“错误的控制链路被包装成了看似合理的自动化”。分层设计的首要价值，是把风险隔离回正确的责任边界。

2. 四层分别解决什么问题

2.1 A2A 层解决“哪个 Agent 该做决定”

A2A 更适合处理的是 Agent 之间的任务协作，而不是设备控制本身。它的职责通常包括：

• 把用户目标拆成分析、计划、执行、审批等子任务。
• 在不同 Agent 之间传递上下文、约束和任务状态。
• 决定何时转人工、何时升级到高权限执行路径。

对于 IoT 控制平面来说，A2A 的价值不在于“连接设备”，而在于确保不会让每个 Agent 都直接面对现场控制接口。

2.2 MCP 层解决“Agent 如何受控地访问平台能力”

MCP 更适合作为 Agent 的工具访问边界。一个生产级 Agentic IoT 系统，更合适暴露给 Agent 的通常是这类工具：

• resolve_asset(site, zone, alias)
• request_action(asset_id, action, parameters)
• get_command_status(command_id)
• request_human_approval(change_request_id)

这意味着 MCP 负责把自然语言意图约束成结构化请求，而不是把 Modbus write、OPC UA node write、MQTT publish 直接给模型。

2.3 OPC UA 或统一资产层解决“控制对象到底是谁”

当系统需要稳定地表达设备、点位、状态、质量位、所属区域和能力边界时，就需要一层比现场寄存器更稳定的对象语义。OPC UA 在这类问题上很有现实价值，因为它擅长：

• 用节点、属性和层级组织设备对象。
• 把不同厂商点位抽象成相对稳定的资产视图。
• 在边缘侧承接质量状态、可浏览结构和统一命名。

即使底层最终不一定只用 OPC UA，这一层也必须存在。否则 Agent 和平台看到的永远只是易漂移的别名和寄存器号。

2.4 Modbus 层解决“现场最终怎么执行”

Modbus RTU/TCP 的强项仍然是现场设备访问，尤其是 PLC、仪表、冷机、变频器和各类控制器。它适合留在执行层，承担：

• 寄存器读取
• 约束写入
• 有节制的轮询
• 设备侧能力差异的最后一跳适配

它不适合直接暴露给 Agent 的原因也很明确：

• 寄存器语义弱，厂商差异大。
• 写入前常常需要条件校验、联锁判断和时间窗口限制。
• 如果跨租户或跨站点直接暴露寄存器地址，审计和权限几乎无法收口。

3. 一条更稳的 Agentic IoT 分层路径

flowchart LR

U["用户目标 / 业务策略"] --> A["协作 Agent 组<br/>A2A 任务编排"]
A --> M["受控工具层<br/>MCP"]
M --> C["命令服务 / 策略引擎"]
C --> O["资产与语义层<br/>OPC UA / Digital Twin"]
O --> G["边缘网关 / 协议适配"]
G --> D["现场设备<br/>Modbus / PLC / Controller"]
D --> F["状态回读 / ACK / 告警"]
F --> C
C --> T["审计追踪 / 人工接管"]

linkStyle default stroke:#6B7C93,stroke-width:1.6px;

这条路径的关键不是“用了几种新协议”，而是每一层都只处理自己该处理的问题：

• A2A 决定谁来做什么，不决定怎么写寄存器。
• MCP 约束 Agent 能提什么请求，不决定现场协议细节。
• 命令服务 / 策略引擎 决定能不能做、何时做、失败后怎么办。
• OPC UA / 资产层 决定目标对象、能力模型和状态语义。
• Modbus 只负责到设备的最后执行。

对比块

A2A 和 MCP 面向的是智能体系统边界，OPC UA 和 Modbus 面向的是工业设备边界。前两层解决“AI 系统如何协作与调用”，后两层解决“工业对象如何表达与执行”。把这两类问题放在同一维度上比较，本身就是架构误判。

4. 命令服务为什么是这条链路里最不能省的一层

即使 A2A、MCP、OPC UA 和 Modbus 的职责都分清了，如果中间没有命令服务，系统仍然不可靠。因为控制动作必须有统一的生命周期，而不是只依赖“工具调用成功”。

一个最小可用的命令服务通常至少需要维护：

• command_id
• trace_id
• asset_id
• requested_action
• policy_decision
• timeout_window
• rollback_hint
• current_state

更关键的是，它需要统一状态机，例如：

Created -> Approved -> Resolved -> Dispatched -> DeviceAcked -> Applied

以及这些终态：

Rejected / TimedOut / Failed / Cancelled / RolledBack

4.1 为什么不能只看 Broker ACK

对很多团队来说，最危险的误判是把“消息已经送到网关”当成“动作已经完成”。但在工业现场，下面任何一步都可能失败：

• 资产映射正确，但设备处于联锁或维护锁定。
• 网关收到消息，但寄存器写入被设备拒绝。
• 设备返回 ACK，但状态没有真正切换。
• 写入成功，但很快被本地控制逻辑覆盖。

flowchart LR

A["Agent 请求"] --> B["策略审批"]
B --> C["资产解析"]
C --> D["协议下发"]
D --> E["设备 ACK"]
E --> F["状态回读确认"]
D --> X["超时 / 无回执"]
E --> Y["ACK 但未生效"]
F --> Z["完成 / 回滚 / 转人工"]

linkStyle default stroke:#6B7C93,stroke-width:1.6px;

判断块

在存在现场控制逻辑、网关缓存和设备安全联锁的系统里，只有“状态回读确认”才能算完成。只看工具成功或 Broker ACK，会把平台误导成一个没有闭环的伪控制系统。

5. 什么时候应该优先补哪一层

这张表的重点不是让团队“都补一遍”，而是先识别当前风险最集中在哪一层。如果平台已经有较强资产模型，但命令没有状态机，那么优先级就不该放在再加一个协议，而该放在命令治理。

6. 哪些场景不适合让 Agent 直接走到现场控制

不是所有工业系统都适合做 Agentic IoT 闭环控制。下面这些场景，更适合让 Agent 停留在分析和建议层：

• 高安全等级对象，例如紧急停机、联锁回路、高压设备。
• 资产身份本来就不稳定，仍然依赖人工口头别名。
• 设备无法提供可靠状态回读，只能做“盲写”。
• 组织上没有 7x24 值守或失败接管能力。
• 仍处于 PoC 早期，站点、租户、权限和运维边界都没收稳。

6.1 更现实的放权顺序

对多数团队，更稳妥的路线不是一步到位，而是：

1. 先让 Agent 读状态、解释异常、生成建议。
2. 再开放低风险参数调整。
3. 中风险动作增加审批或时间窗口约束。
4. 只有在 ACK、回滚、人工接管成熟后，才放开更高等级动作。

这条路径的价值，在于把“模型能力增长”转化为“控制权渐进委托”，而不是把实验环境里的成功误判成生产成熟度。

7. 真正可落地的结论是什么

如果今天要设计一套能接工业设备的 Agentic IoT 控制平面，最重要的不是去问“这四个里谁最先进”，而是先确认你是不是把它们放到了正确层级：

• A2A 负责多 Agent 协作和任务接力。
• MCP 负责受控工具访问和结构化动作请求。
• OPC UA 或统一资产层负责设备身份、能力模型和状态语义。
• Modbus 负责现场最后执行。
• 中间用命令服务把审批、下发、ACK、回滚和审计收成一条闭环。

最终判断

当系统同时面对多 Agent 协作、跨站点资产、工业协议异构和高成本失控风险时，A2A -> MCP -> 命令服务 / OPC UA -> Modbus 不是“更复杂的理想图”，而是比扁平拼接更容易担责、更容易审计、也更容易逐步放权的现实路径。