Articles

IoT Agent 化：从设备能力到 Physical World Runtime

IoT Agent 化的终点可能不是“每个设备内置一个 Agent”，而是让 IoT 从 Device-centric Architecture 演进为 Environment-centric Architecture：设备提供能力，IoT Core 提供可观察的物理世界，Agent Runtime 负责围绕目标持续行动。

思路 2026-09-29发表 2026-09-29作者 chengguruchunAgent IoT Capability Agent Module IoT Core SaaS PaaS Physical World Runtime

先说结论

我的核心判断：IoT Agent 化不是给传统设备简单加一个 LLM，而是重新定义 IoT 的应用层。设备仍然负责感知、执行和连接；Agent Runtime 负责目标、规划、闭环与治理；IoT Core 则逐渐从“设备连接平台”升级为“可被 Agent 操作的 Physical World Interface”。

如果这个方向成立，那么产业链也会发生变化：设备厂商提供物理能力，Agent Module/SDK 负责把设备接入 Agent 世界，IoT Core 把能力、状态和事件标准化，Runtime 负责自主执行，上层 SaaS/PaaS 再围绕家庭、制造、能源等领域构建具体场景。

1. 从 Device-centric 到 Environment-centric

传统 IoT 的核心范式是“设备控制”。用户发出指令，App 或规则引擎调用设备 API，设备完成动作。大量产品价值被预先打包成按钮、场景和 Workflow。

传统 IoT
User → App → Rule / Workflow → Device → MQTT / Protocol

Agentic IoT
User Goal
    ↓
Agent Runtime
    ↓
Plan → Action → Observation → Verification
    ↓
IoT Environment
    ↺

变化的关键不是 MQTT 会不会消失，而是控制范式从“调用一个设备动作”转向“让物理环境逐渐逼近目标状态”。例如“帮我准备一个适合睡觉的环境”，目标不再是某一个 API，而是温度、灯光、窗帘、空气质量和安全状态的组合。

2. IoT Agent 和 Code Agent，其实是同一种闭环

Code Agent 在电脑环境中工作：修改代码、运行测试、观察错误、修复，再次验证。IoT Agent 在物理环境中工作：控制设备、观察传感器、验证状态、处理异常，再次行动。

Code Agent
Goal → Plan → Edit → Run → Test → Observe → Fix ↺

IoT Agent
Goal → Plan → Control → Observe → Verify → Correct ↺

共同抽象
Goal → Action → Environment → Observation → Verification → Re-plan

因此 IoT Agent 的核心不是“聊天”，而是闭环。API 调用成功不等于任务成功：设备可能执行失败、状态没有达到预期、环境发生变化，或者多个设备之间产生冲突。

3. 设备指令：标准化，但不要把设备做成一样

如果每个厂商都定义自己的 API，Agent 会重新面对 IoT 长期存在的碎片化问题；但如果把所有设备都压缩到一套最低公分母指令，又会抹掉厂商创新。

更合理的方式是：标准化语义与基础 Capability，保留 Vendor Extension。

AirConditioner
├── Standard Capability
│   ├── power
│   ├── temperature
│   ├── mode
│   └── fan_speed
│
├── Optional Capability
│   ├── humidity
│   └── air_quality
│
└── Vendor Extension
    ├── sleep_curve
    ├── AI_comfort
    └── energy_optimizer

因此标准化的对象不应该只是 Command，而应该逐渐覆盖：

Identity：设备是谁、型号、固件和身份凭证；
Capability：设备能做什么；
State：设备当前是什么状态；
Action：允许执行哪些动作；
Event：发生了什么；
Telemetry：持续产生什么观测数据；
Constraint / Permission / Risk：在什么条件下可以执行。

这比简单定义一个“unlock()”或“set_temperature()”更接近 Agent 真正需要的设备模型。

4. Agent Module：设备进入 Agent 世界的“网卡”

大量存量 IoT 设备不会因为 Agent 出现就重新设计 MCU、固件和整套通信栈。真正可能推动规模化的产品形态，是一个薄的 Agent Module / SDK。

┌─────────────────────┐
│     Agent Module    │
│                     │
│ Device Adapter      │
│ Capability Model    │
│ State / Event       │
│ Identity / Security │
│ MCP / API Adapter   │
│ OTA / Lifecycle     │
└──────────┬──────────┘
           │
        Device / MCU

它更像“Agent 网卡”，而不是“大模型模组”。第一代 Agent Module 甚至可以完全没有 LLM：它只负责把传统设备的能力、状态、事件和安全边界暴露成 Agent 可理解的接口。

这样，设备厂商只需要实现 Device Adapter；复杂的 Planning、Harness、Memory 和大模型推理仍然放在云端或边缘 Runtime。

5. MQTT 只是连接层，Agent 真正需要的是设备语义

MQTT 很重要，但它解决的是消息传输。Agent 要解决的问题更高一层：我控制的是谁？它有什么能力？当前状态是什么？这个动作有什么风险？动作完成以后如何验证？

Agent
  ↓
Agent Runtime
  ↓
Capability / Tool Interface
  ↓
Agent Module / Gateway
  ↓
IoT Protocols
  ├── MQTT
  ├── Matter
  ├── BLE
  ├── Thread
  ├── Wi-Fi
  └── 其他设备协议
  ↓
Physical Device

因此 MCP 更像 Agent 与能力之间的接口层，而不是 IoT 设备标准本身。IoT 仍然需要自己的 Capability / State / Event 语义模型。

6. IoT Core 的交付物会发生变化

传统 IoT Core 最重要的能力是“把设备连上来、管起来、采集数据”。Agent 时代，我认为它应该进一步成为“物理世界的能力底座”。

IoT Core
├── Device Identity
├── Capability
├── State
├── Event
├── Telemetry
├── Digital Twin
├── Permission / Policy
├── Device Lifecycle / OTA
└── Agent Interface

换句话说，IoT Core 不只是 Device Cloud，而开始成为一个可被软件和 Agent 消费的 Physical World API。

7. 在 IoT Core 之上构建 SaaS / PaaS

当设备能力被标准化以后，上层就不需要重复解决“怎么连接空调、怎么读取设备状态”。开发者可以直接围绕行业目标构建 PaaS 和 SaaS。

Industry SaaS
             ┌────────┼────────┐
             ↓        ↓        ↓
          Home      Factory   Energy
          Agent      Agent     Agent
             └────────┼────────┘
                      ↓
              Agent Runtime / Skill Hub
                      ↓
                   IoT Core
                      ↓
           Devices / Sensors / Actuators

例如制造场景，IoT Core 提供机器温度、振动、功率、状态和报警等能力；Manufacturing Agent 在上面进一步组合生产、质量、维护和能源能力。这样，底层能力可以复用，而上层业务模型可以完全不同。

这也意味着 IoT 平台可能从“卖设备连接”逐渐走向“卖 Capability / Skill / Agent Runtime”。

8. SaaS 也会从 Workflow 走向 Goal

传统工业 SaaS 更像：用户进入页面，创建计划，执行 Workflow，再查看结果。Agentic SaaS 则可以让用户直接表达目标：“今天产线延迟了，尽量追回交付时间。”

Goal
 ↓
Domain Agent
 ↓
查询订单 / 产能 / 设备状态
 ↓
发现瓶颈
 ↓
调整计划
 ↓
调用 IoT Capability
 ↓
持续观察
 ↓
重新规划

因此 IoT Core 提供的是“世界”，Agent Runtime 提供的是“行动”，SaaS/PaaS 提供的是“领域目标”。

9. 但物理世界让 Runtime 比软件 Agent 更重要

Agent 在物理世界里行动，安全边界会比普通软件任务严格得多。“调灯光”和“开门”显然不是同一种风险；“关闭报警器”和“读取温度”也不能拥有相同权限。

Action
  ↓
Risk Assessment
  ↓
Policy / Permission
  ↓
Human Gate / Execute / Reject
  ↓
Physical Feedback
  ↓
Verification

所以 IoT Agent Runtime 需要把 Policy、Risk、Permission、Verification 和 Audit 变成一等能力。Agent 越自主，Runtime 越不能只是一个 Tool Caller。

10. 最终架构：Agentic IoT 的五层

┌──────────────────────────────────────┐
│           Industry SaaS              │
│ MES / Energy / Smart Home / Retail   │
└──────────────────┬───────────────────┘
                   │
┌──────────────────▼───────────────────┐
│           Domain Agent               │
│ Planning / Reasoning / Goal          │
└──────────────────┬───────────────────┘
                   │
┌──────────────────▼───────────────────┐
│       Agent Runtime / Skill Hub      │
│ Harness / Memory / Policy / Eval     │
└──────────────────┬───────────────────┘
                   │
┌──────────────────▼───────────────────┐
│              IoT Core                │
│ Device / Capability / State / Event  │
│ Telemetry / Digital Twin / Identity │
└──────────────────┬───────────────────┘
                   │
┌──────────────────▼───────────────────┐
│       Agent Module / Edge / Device   │
│ MQTT / Matter / BLE / Sensors / MCU  │
└──────────────────────────────────────┘

11. 最值得继续追问的问题

如果这个架构成立，真正值得研究的就不再是“给 IoT 加不加一个 Agent 功能”，而是三个更底层的问题：

设备标准：什么应该成为跨厂商的 Capability / State / Event 标准，什么必须保留差异化？
Agent Module：它会不会像今天的 Wi-Fi、Bluetooth 或其他设备 SDK 一样，成为设备进入 Agent 生态的标准基础组件？
IoT Core：它最终还是 Device Cloud，还是会升级成一个真正的 Physical World Runtime / Control Plane？

我的当前判断：Agent 不会消灭 IoT 的底层连接、设备协议和数字孪生；真正发生变化的是应用层的控制方式。过去 IoT 把物理能力预先打包成 App、规则和 Workflow，未来这些“打包物”可能逐渐被解包成 Capability、State、Event 和 Skill，由 Agent Runtime 在目标驱动下动态组合。

如果这条路线最终成立，那么 IoT Agent 化就不是“智能音箱再加一个聊天机器人”，而是一次从 Device → Capability → Environment → Goal 的架构迁移。