Agent 物联网：先把设备状态、规则引擎和受限执行串起来，再谈设备自治

很多关于 Agent + IoT 的文章，一开头就会说：

• •自然语言控制所有设备
• •情境感知自动联动
• •设备自主决策
• •边缘端智能自治

这些方向并不是不能做，但真实 IoT 项目里更难的问题通常是：

• •设备现在到底在线还是离线
• •这个设备拥有什么能力，权限属于谁
• •场景规则和人工下发的命令有没有冲突
• •指令发出去之后有没有真的被执行和确认

所以 IoT Agent 的第一目标，通常不是“让设备更会聊天”，而是先把设备状态、规则边界和执行确认串成一条稳定链路。

如果第一版目标写成“统一控制所有设备、自动优化全屋/全楼/全园区场景”，项目很快就会卡在能力建模、权限和安全边界上。

更现实的切入点通常是：

• •设备状态查询
• •异常告警解释
• •场景配置草稿
• •售后与运维工单协同

以“设备运维助手”为例，一个可交付的第一版通常已经很有价值：

• •解析用户或运维人员的自然语言诉求
• •拉取设备状态、固件、最近告警和能力模型
• •判断当前更像状态查询、场景变更还是维修跟进
• •生成受限动作草稿或工单摘要
• •高风险控制动作默认进入人工确认

这比一上来做“设备自治大脑”更容易落地。

1. 设备事实层

这一层至少要回答下面这些问题：

• •设备 ID 和型号是什么
• •在线状态、固件版本和最近心跳是什么
• •支持哪些命令和参数
• •归属哪个空间、账号或租户
• •是否存在只读、受限或禁用动作

没有设备事实层，后面的“智能”很容易建立在错误状态上。

2. 事件与规则层

IoT 项目真正复杂的地方，通常不是命令本身，而是上下文：

• •当前有没有告警
• •是否处在自动化场景里
• •有没有时间窗、能耗、安防等规则
• •是否受离线、弱网、电量等条件影响

Agent 在这里更适合做上下文整合，而不是绕过规则引擎。

3. 意图理解与编排层

这一层最适合模型承担：

• •把自然语言诉求转成结构化意图
• •解释为什么某个场景没有生效
• •生成场景规则草稿
• •把异常和设备状态整理成运维摘要

4. 网关执行与人工安全层

物理世界动作都应该有明确边界，尤其是：

• •门锁、门禁、摄像头
• •高功率设备
• •涉及安防和能耗的联动
• •会影响真实环境和人身安全的控制动作

这些动作不能只靠一段自然语言就无条件执行，必须经过策略校验、权限校验和必要的人为确认。

在 IoT 场景里，一个更稳的职责拆分通常是：

更适合模型处理的部分

• •理解用户或运维的口语化描述
• •解释设备异常和场景冲突
• •生成场景配置草稿
• •整理维修和售后跟进记录

更适合系统处理的部分

• •提供设备状态和能力模型
• •控制认证、授权和命令白名单
• •处理命令投递、重试、回执和幂等
• •执行规则引擎、离线队列和回滚机制

如果让模型直接承担“理解 + 决策 + 执行 + 成功判定”，最后最容易出问题的就是现实设备控制。

更稳的方式，是先把意图收敛成一份受限计划。

from typing import Literal
from pydantic import BaseModel, Field


class DevicePlan(BaseModel):
    lane: Literal["state_query", "scene_review", "maintenance_followup", "handoff"]
    device_ids: list[str] = Field(default_factory=list)
    requested_capabilities: list[str] = Field(default_factory=list)
    notes: list[str] = Field(default_factory=list)
    requires_confirmation: bool = True


def execute_device_plan(plan: DevicePlan, tools):
    twins = tools.load_device_twins(plan.device_ids)
    policy = tools.evaluate_device_policy(plan.requested_capabilities, twins)
    draft = tools.draft_scene_preview(plan.lane, twins, policy, plan.notes)

    if plan.requires_confirmation or policy.has_blockers:
        return tools.handoff_to_operator(draft=draft, policy=policy)

    return tools.dispatch_safe_commands(draft=draft, policy=policy)

这个模式的价值在于：

• •先区分当前是在查状态、改场景还是处理运维问题
• •设备能力和安全策略可以在系统里显式校验
• •高风险动作默认进入人工确认

很多 IoT 文章喜欢把“边缘智能”写成设备本地跑大模型，但真实系统更常见的拆分是：

• •云端模型负责理解、规划和复杂摘要
• •网关或边缘节点负责状态缓存、策略执行和断网兜底
• •设备本身继续保持受限能力和明确协议

也就是说，边缘更重要的往往不是“模型更大”，而是：

• •离线时仍能执行核心策略
• •命令链路更稳定
• •本地状态与云端会话可以同步

IoT Agent 的评估，更应该围绕这些问题：

• •意图识别是否准确
• •设备槽位和能力是否补全正确
• •指令下发后有没有真实回执
• •人工拦截最多发生在哪些场景
• •离线和弱网情况下有没有产生误判

这些指标比“回答是否更自然”更接近真实价值。

1. 让模型直接控制所有设备

没有能力白名单、权限和策略校验的设备控制，很容易把自然语言变成新的风险入口。

2. 设备状态不同步，就开始执行动作

在 IoT 场景里，基于过期状态发指令，通常比“什么都不做”更危险。

3. 没有执行确认和回滚机制

指令被接受、不等于设备真的执行成功；没有确认和回滚，系统就会误以为世界已经被改写。

IoT Agent 真正可交付的形态，不是一个“什么设备都能自治”的统一大脑，而是一条更稳的设备运营链路：

• •先把设备事实和能力模型建清楚
• •让模型承担意图理解和异常解释
• •把命令投递、权限校验和回执留给系统
• •用人工确认守住物理世界动作边界

只要把这些基础打稳，Agent 才有机会在 IoT 场景里真正提效，而不是制造新的控制风险。

• •OpenAI Function Calling
• •OpenAI Structured Outputs
• •OpenAI Conversation State
• •OpenAI Safety Best Practices
• •OpenAI Working with Evals