AIoT：当智能体接管物联网

传统物联网平台的天花板很明确：设备管得越多，人越累。菜单层层点进去看一台设备的状态、大屏盯不动几百路曲线、告警规则写得比业务代码还多。而大模型智能体恰好补的就是这块——让「人找数据、人写规则、人做判断」变成「人直接说话，智能体去干」。这篇文章讲物联网和智能体怎么真正接起来，不是概念拼接，是可落地的架构。

一、传统物联网平台的三个痛点

痛点	现状	智能体能给的
查个状态要点八下	树形菜单 → 区域 → 网关 → 设备 → 实时数据	「3 号仓库温度多少」一句话
告警规则僵硬	阈值规则提前写死，漏报误报两头堵	结合语境研判，理解「这个异常在当下场景正不正常」
故障处置靠人跑	告警 → 值班 → 查日志 → 远程重启 → 复查	智能体闭环：研判 → 处置 → 验证 → 记录

二、总体架构：设备层之上加一层「能力暴露」

┌──────────────────────────────────────────────┐
│  用户 / 值班工程师 / 上游系统                    │
│      "把3号仓库的除湿机打开"                     │
├──────────────────────────────────────────────┤
│  智能体层（LLM + 工具编排）                     │
│  意图理解 → 设备定位 → 参数校验 → 调用工具        │
├──────────────────────────────────────────────┤
│  MCP 工具层（把物联网能力标准化暴露）             │
│  list_devices / get_status / control_device    │
│  query_timeseries / get_alerts                 │
├──────────────────────────────────────────────┤
│  物联网平台层（设备接入 · 影子 · 规则引擎）        │
├──────────────────────────────────────────────┤
│  设备层（传感器 · 继电器 · 网关 · 边缘节点）       │
└──────────────────────────────────────────────┘

关键设计判断：智能体不直连设备，只连物联网平台的 API。设备接入的复杂性（协议、弱网、状态同步——前两篇讲的所有问题）继续由物联网平台层消化，智能体层只消费干净的语义化接口。这样两侧都能独立演进。

三、MCP 工具层实战：把设备能力暴露成智能体的手和眼

用 MCP（Model Context Protocol）把平台能力封装成标准工具，智能体就能「看见」设备和「操作」设备：

python

# MCP Server：物联网设备控制工具集
from mcp.server import Server

server = Server("iot-platform")

@server.tool("list_devices")
async def list_devices(area: str = None, type: str = None) -> str:
    """列出设备。area: 区域名(如'3号仓库'), type: 设备类型(如'除湿机')"""
    devices = await iot_api.query(area=area, type=type)
    return json.dumps([{
        "id": d.id, "name": d.name, "area": d.area,
        "type": d.type, "online": d.online, "status": d.status
    } for d in devices], ensure_ascii=False)

@server.tool("control_device")
async def control_device(device_id: str, action: str, params: dict = None) -> str:
    """控制设备。action: open/close/restart/set_param"""
    # 安全校验：白名单 + 权限 + 危险操作标记
    check_permission(device_id, action)
    result = await iot_api.send_command(device_id, action, params)
    return json.dumps(result, ensure_ascii=False)

@server.tool("query_timeseries")
async def query_timeseries(device_id: str, metric: str,
                           start: str, end: str) -> str:
    """查询设备指标历史曲线，返回聚合后的时间序列"""
    data = await tsdb.query(device_id, metric, start, end)
    return json.dumps(downsample(data), ensure_ascii=False)

工具设计的几条实战原则：

粒度对齐人的意图：不要暴露 mqtt_publish(topic, payload) 这种裸接口，暴露 control_device("除湿机-3号仓库", "open")——智能体负责语义，工具负责安全
返回值要「可读可算」：返回结构化 JSON 同时附带摘要（如「近1小时温度 24.1→26.3℃，上升 2.2℃」），帮模型少一次推理
时序查询必须聚合：原始曲线几万个点会撑爆上下文，工具层先降采样

四、自然语言控制的完整链路

「把 3 号仓库的除湿机打开」这句话的落点：

用户: 把3号仓库的除湿机打开
  │
  ▼ 智能体推理
tool call: list_devices(area="3号仓库", type="除湿机")
  │ ← [{id:"DEV_088", name:"除湿机-3号仓", online:true, status:"off"}]
  ▼
tool call: control_device(device_id="DEV_088", action="open")
  │ ← {"success":true, "shadow_desired":{"power":"on"},"version":42}
  ▼
回复: 已下发指令，除湿机-3号仓（在线）正在启动。
      要我 5 分钟后确认一下它是否真的运行了吗？

注意最后那句主动追问——指令下发成功 ≠ 设备执行成功（前一篇讲的影子机制），让智能体主动闭环验证，这才是把「消息可靠性」的经验延伸到了智能体交互层。

五、智能体自动巡检与故障自愈

比「人说话」更有价值的是无人值守闭环。值班场景的经典编排：

定时触发（每 30 分钟）
  │
  ├─ tool: get_alerts(severity="high", unresolved=true)   拉高风险告警
  ├─ tool: query_timeseries(...)                            拉相关曲线
  │
  ▼ LLM 研判（带设备档案、历史处置记录作为上下文）
  │   "电流持续超限 + 温度正常 + 昨天同类告警重启后恢复"
  │    → 判定: 疑似固件卡死，建议远程重启
  │
  ├─ 人在回路: 高危动作推送值班人确认（或低危直接执行）
  ├─ tool: control_device(action="restart")
  ├─ 等 3 分钟 → tool: get_status 验证恢复
  └─ 写入处置记录，未恢复升级告警

安全边界是这个编排能不能上生产的生死线：

动作白名单：智能体能做的动作枚举注册（查状态/开/关/重启），白名单外的一律拒绝——LLM 幻觉出「下发固件」这种动作，工具层直接挡死
分级授权：只读操作全自动，可逆操作（重启）可配置自动，不可逆操作（批量断电）必须人确认
审计日志：每次 tool call 记录「谁（哪个智能体）在什么上下文里做了什么」，出事可回溯
限速：单设备操作频次上限，防止智能体陷入重试循环把设备刷挂

六、LLM 时序研判：阈值 + 语义的组合拳

纯阈值告警的毛病是「不懂语境」：夏天仓库 30℃ 正常，冬天 30℃ 就是火灾前兆。LLM 研判的价值在把语境拉进来：

python

context = f"""
设备档案: {device.profile}          # 冷链仓库，温度应 2-8℃
当前告警: 温度 9.4℃，持续 18 分钟
历史曲线: 2小时前 5.2℃ → 1小时前 7.1℃ → 现在 9.4℃（持续爬升）
近7日同时段: 均值 4.8℃，波动 ±0.5℃
同类设备: 同仓另3台除湿机温度正常（4.5~5.1℃）
近期事件: 无开门记录，除湿机 DEV_088 昨日重启过1次
"""
# LLM 结论: 单设备温度爬升且除湿机近期异常 → 疑似该除湿机故障，
#           非库门开放（无开门事件、其他设备正常）→ 建议重启 DEV_088 并持续观察

关键认知：LLM 不做数值计算，做的是「多源信息的语义融合」。曲线趋势、设备档案、关联设备、历史事件——这些信息人类专家几分钟才能拼起来，LLM 一次就能融合，这正是告警降噪的正确打开方式。

七、演进路线

AIoT 不是一步到位的项目，建议的渐进路线：

阶段	做什么	价值
1. 问答	智能体查状态、查曲线（只读工具）	零风险，替代 80% 的「点菜单查数」
2. 研判	告警接入 LLM 语义分析，辅助值班决策	告警降噪，人的判断质量提升
3. 执行	白名单动作自动处置 + 验证闭环	夜间无人值守，故障自愈
4. 主动	智能体主动发现优化点（能耗、异常模式）	从「救火」到「预防」

每一步都建立在上一步的可信度上——先证明它看得对，再让它动手。

写在最后

物联网给了智能体一双看见物理世界的眼睛，智能体给了物联网一个会说人话的大脑。这个组合最迷人的地方在于：过去十年积累的物联网平台（接入、影子、消息可靠性）一行都不用重写，只需要在 API 之上加一层 MCP 工具封装，就全部变成了智能体的能力。平台越扎实，智能体越强。

AIoT：当智能体接管物联网 ​

一、传统物联网平台的三个痛点 ​

二、总体架构：设备层之上加一层「能力暴露」 ​

三、MCP 工具层实战：把设备能力暴露成智能体的手和眼 ​

四、自然语言控制的完整链路 ​

五、智能体自动巡检与故障自愈 ​

六、LLM 时序研判：阈值 + 语义的组合拳 ​

七、演进路线 ​

写在最后 ​