在正式配置之前，我想先把这条链路再讲清楚一点。因为第二篇最核心的，不是安装步骤，而是让你脑子里先有一张完整的图。这条链路大概是这样的。第一步，家属输入一句话。比如：明天早上 8 点提醒我吃降压药第二步，OpenClaw 接住这句话。它要做的不是单纯复述，而是把这句话理解成一条任务。比如：提醒类型：吃药提醒时间：明天早上 8 点对象：本人内容：降压药第三步，这条任务被写入系统。也就是说，这件事不能只是“聊过去了”，而是要被记录下来，后面系统才能在真正到点的时候继续处理。第四步，到时间后，系统触发执行。OpenClaw 调用 Home Assistant，让家里的设备做动作。比如：让小爱音箱播报“该吃早上的药了”让卧室灯或者客厅灯亮起来第五步，系统等待反馈。如果预设时间内没有进一步响应，就走下一步。第六步，继续提醒或者升级通知。比如再次播报，或者直接把消息发给另一个家属。你会发现，这和普通 AI 最大的区别就在这里。普通 AI 到第二步基本就结束了。它回答完，就没了。但 OpenClaw 要做的是：接住一句话，然后把后面整件事继续跑下去。
六、为什么这里一定要引入 Home Assistant
很多人会问：提醒这件事，直接用微信、日历或者手机闹钟不行吗？当然可以。但如果你只用这些工具，你得到的只是“单点提醒”。它可以响一下。也可以弹一条消息。但它很难真正进入家庭环境里去做动作。而 Home Assistant 的价值就在这里。它不是用来“显得高级”的。而是用来把家里的实体设备真正接进系统。有了它以后，提醒这件事才不再只是手机上的一个通知。它会变成：音箱播报灯光联动设备状态变化自动化触发通知回传也就是说，Home Assistant 不是可有可无的一层。它是把“AI 理解出来的意图”，真正落到现实设备上的那一层。没有这一层，系统还是停留在屏幕里。
后面你肯定会接更多设备。小爱音箱、灯光、插座、传感器、摄像头，这些都可以慢慢往里加。但第二篇最不推荐的做法，就是一开始全接。因为接得越多，排错越复杂。最推荐的做法是：先接一个最容易验证动作的设备。比如卧室灯。比如客厅灯。比如一个插座。接入完成之后，你只检查两件事。第一，在 Home Assistant 里已经能看到它的实体。比如：light.bedroomlight.living_roomswitch.bedroom_socket第二，你在 Home Assistant 后台里手动点它，设备真的会动。如果这一步已经成立，后面 OpenClaw 去调它，才有意义。
九、给 Home Assistant 创建 Token，让 OpenClaw 具备调用能力
接下来这一小步非常关键。因为前面只是“设备接进来了”，还不等于 OpenClaw 能控制它。真正让两边打通的，是 Home Assistant 的 API Token。你可以在 Home Assistant 的个人资料页面里，创建一个 Long-Lived Access Token。后面你至少要记住两个东西：一个是 Home Assistant 的地址。一个是这个 Token。比如：HA_URL=http://192.168.1.10:8123以及对应的 HA_TOKEN然后把它们放进 OpenClaw 的环境变量里。这里我很建议你从一开始就养成好习惯：Token 不要发群里。不要写进公开文档。不要明文进日志。因为从这一刻开始，这套系统已经不再只是“聊天”了，它已经具备控制家里设备的能力。
十、真正让系统开始运转的，是一个最小 Skill
前面的 Home Assistant 和设备接入，都只是底层准备。真正让这套系统第一次“做事”的，其实是 OpenClaw 里负责设备调用的那个 Skill。你可以把它理解成：系统获得执行能力的第一块模块。这个 Skill 不需要一开始就特别复杂。它最小只需要做三件事：接收一个设备相关请求调用 Home Assistant 的接口把结果回传回来目录可以先这样放：/skills/ha-control/SKILL.md这一步不要试图把所有场景都写进去。先只支持最基本的几类动作就够了。比如：开灯关灯查状态触发一个简单场景这已经足够支撑第二篇要讲的“第一个闭环”。
十一、为什么设备映射表必须先做
很多人做这一步的时候，最容易高估 AI 的“猜测能力”。觉得用户说“客厅灯”，系统自己猜就行了。用户说“把门口那个灯开一下”，系统大概也能猜到。但这里有一个很现实的问题：家庭设备一旦进入执行层，最怕的不是“不够聪明”，而是“猜错了还执行了”。所以我建议你从一开始就做一个设备映射表。比如在工作区里放一个：data/device_map.json内容像这样：{"客厅灯": "light.living_room","卧室灯": "light.bedroom","卧室插座": "switch.bedroom_socket","玄关灯": "light.entry"}有了这层映射之后，系统先识别“人说的是哪个设备”，再去找到对应的实体。这样做有两个好处。第一，执行更稳。第二，后面你扩展设备时，只需要改这张表，上层很多逻辑都不用动。对于这种家庭系统来说，“明确”比“自由发挥”更重要。
十二、先跑通哪三种能力，就算闭环成立了
第二篇不要把目标放得太散。只要下面这三种能力跑通，这套系统的第一条闭环就算成立了。第一，能查状态。也就是用户说一句：看看卧室灯现在是不是开着系统能查到设备当前状态，再把结果回回来。第二，能执行明确动作。比如：开客厅灯关卧室插座系统能调 Home Assistant，让设备真的动起来。第三，能把结果回传。也就是说，执行完之后，群里不是沉默的，而是会明确告诉你：执行成功了没有调的是哪个设备当前状态是什么这是很多人很容易漏掉的一步。但实际上，只有“有结果回传”，闭环才算真正成立。因为一旦没有回传，家属就不知道系统到底有没有做事。
十三、消息入口最好先保留两套方式
这一点很重要。第二篇刚开始落地时，我不建议你完全依赖自然语言。最稳的做法，其实是同时保留两套输入方式。第一套，是口令式。比如：/device on 客厅灯/device off 卧室灯/device status 玄关灯这种方式的好处，是基本不容易误判。很适合系统刚启动的时候用。第二套，是自然语言式。比如：帮我开一下客厅灯查一下玄关灯状态明天早上 8 点提醒我吃降压药这种方式更自然，也更符合家庭成员的使用习惯。但它一定要建立在你前面那套映射、规则和约束之上。不是让系统自由猜测一切，而是在可控范围内理解自然语言。这样系统才既顺滑，又不失控。
十四、把“提醒吃药”这件事第一次跑起来
我们回到这一篇最关键的示例。如果你想验证这套家庭健康照护系统是不是开始活起来了，最推荐你先做的，就是跑通“提醒吃药”这个场景。比如在微信里发一句：明天早上 8 点提醒我吃降压药这时候系统理想中的处理过程应该是这样的。第一步，OpenClaw 识别出：这是一个提醒任务，不是一个即时设备控制命令。第二步，它把这条任务写入系统。比如写进提醒目录，或者你专门做的任务文件里。第三步，到第二天早上 8 点，系统开始触发执行。它去调用 Home Assistant，让小爱音箱播报提醒，或者先亮灯，再播报。第四步，如果预设时间内没有响应，它继续执行第二次提醒。第五步，如果还没有反应，它通知指定家属。这一整条链路一旦第一次真的发生，你就会很明显地感觉到：这已经不是“我给自己设了一个闹钟”。而是家里真的开始有一套东西在帮你持续盯着这件事。这就是第二篇最想完成的转折。
夜雨聆风