OpenClaw 控制你家的设备: AI Agent 智能家居架构设计

01从「App 遥控」到「说人话」

过去十年，智能家居的交互形态基本没变：打开 App → 找到设备 → 点开关。设备越多，这个动作越笨。客厅四盏灯、卧室两盏、书房一盏台灯，想一次性关掉，得点七次。

大模型出现后，第一反应是「直接让 AI 接设备」。听起来很顺：模型能理解「把客厅调暗一点」，那就让它调用设备 API 不就行了？

实际做下来，会撞上三堵墙。

第一堵是状态。模型是无状态的。你问它「灯现在是亮的吗」，它不知道 —— 除非每次都在提示词里塞进全屋状态。

第二堵是协议。灯走 Wi-Fi，传感器走 Zigbee，打印机走 IPP，空调走红外。每种协议一套 SDK、一套鉴权、一套重连逻辑。让 Agent 直接对接，等于把整个设备生态的脏活都塞进模型上下文。

第三堵是可靠性。「调亮一点」是个相对量，模型得先知道当前亮度，再加一个增量。如果它跳过读取、直接猜一个绝对值，结果可能正好相反 —— 你说调亮，它把灯调暗了。

02五层架构：每一层只做一件事

分层的原则很简单：谁擅长什么，就只做什么。

层间是双向的：指令往下走，状态往上走。这一条决定了后面所有设计。

第二层是主角。OpenClaw 是 AI Agent 运行时，它负责的是「把一句话翻译成一组动作」。注意它的职责边界 —— 它不做协议适配，也不维护设备状态。这两件事都推给第四层。

第三层 MCP Server 是把二者粘起来的地方。它对外暴露的不是「某个牌子的灯怎么开」，而是三个语义化的工具：

依次对应查询状态、下发指令、触发场景。这层存在的意义是收敛不确定性：模型看到的是三个稳定的工具，而不是几十个厂商 SDK。

03一条核心原则：Agent 负责意图，中枢负责确定性

这是整个方案里最重要的一句话。拆开看：

• 意图
  = 模糊的、有上下文的、需要理解的东西。比如「太亮了」「我睡了」「家里没人」。这是 Agent 的强项。
• 确定性
  = 精确的、可验证的、不能出错的东西。比如「亮度设为 160」「三分钟后关」「断线重连」。这是中枢的强项。

把这两件事混在一起，系统就会变得既不可靠也难以调试。

举个例子。用户说「我睡了」。Agent 需要判断这是「关灯」还是「关灯 + 关窗帘 + 空调调到睡眠模式」—— 这是意图层的工作。但一旦确定要关哪几盏灯，具体的 light.turn_off调用、失败重试、状态确认，就该由中枢接管。Agent 不应该关心 light.zhu_deng这个实体在不在线。

04四类指令，四套解法

指令不是一种东西。按确定性从高到低，可以分四类：

四类的风险不一样。绝对指令最安全，因为参数是明确的。相对指令最危险 —— 因为增量是相对的，基准值必须先读出来。

这张图是「先读后算」的完整链路：读当前亮度 120 → 加 40 得到 160 → 下发 → 回读验证。四个动作缺一不可。

最后一步「回读验证」经常被忽略。设备可能不响应、可能被限流、可能状态被其他规则覆盖。不回读，Agent 就只能假设成功 —— 而「假设成功」是智能家居里最危险的默认值。

05五个实现要点

06落地路径：不要一上来就接全屋

P0 阶段的验收标准值得强调：不是「能亮」，而是「能亮 + 能确认」。只有可验证的链路，才值得往上加东西。