“朋友要来家里了，帮我把灯都开一下，然后调到晚上适合的颜色。”
这不是一句标准化的智能家居指令。它没有说明开哪几盏灯，也没有给出亮度、色温的具体参数。对传统语音助手来说，这很容易变成一次失败的模糊匹配；但在七牛云软件开发工程师张之阳的家里，这句话已经可以被一个 Agent 接住，并完成一条真实系统里的执行闭环。
AI 能力越来越强，但对开发者来说，更关键的问题不是它能不能回答问题，而是能不能在边界清晰的前提下接入真实系统，完成可验证的任务。
这次，我们和之阳聊了聊他基于 OpenClaw + Home Assistant 的智能家居 Agent 实践：从对话到执行：如何用 OpenClaw + Home Assistant “重构”智能家居。它如何接入真实设备，如何把一句模糊指令变成具体 API 调用，如何做状态回查，又如何在权限、安全和任务边界上保持克制。
访谈对象：张之阳，七牛云软件开发工程师
- 张之阳的 GitHub 地址：github.com/luoliwoshang
项目方向：OpenClaw + Home Assistant 智能家居 Agent 实践
懒人版
本期访谈聚焦 AI 落地中一个核心问题：
当 AI 的能力越来越强，我们该如何让它真正接入真实系统，并转化为安全、可控的生产力？
内容要点：
生产力转化的关键：传统语音助手适合“开灯”这类明确指令；Agent 的价值在于理解“待客灯光”这类模糊目标，并补足上下文、推断参数。
架构的**解耦**哲学：不要让 Agent 直接对接底层物理协议，而是通过 Home Assistant 把设备能力统一 API 化。
从执行到闭环：真实系统里的 Agent 不能“POST 请求发出去就结束”，还需要尽量做状态回查，确认任务是否产生预期结果。
任务边界：定时、强时序、低容错、需要极速响应的联动交给传统程序；目标模糊、多步推理、临时分析与轻交付任务，才交给 Agent 运行时。
安全准则：AI 越接近真实系统，权限越要被管住。内网部署、Docker 容器隔离、最小权限、独立仓库和人在回路，都是必要的安全边界。
一句话总结：这是一个一线开发者如何让 Agent 进入真实系统、承担真实任务的工程复盘。
从明确指令到模糊目标，传统语音助手为什么不够用？
小七：先从一个具体场景开始吧。现在你在家里给这个 Agent 发一句话，它最常帮你完成什么任务？
之阳：现在比较常用的场景，是当我在外面，或者不方便直接操作设备时，让它完成一些不是“点几个按钮就能解决”的任务。
比如调整一个适合的灯光氛围。看电影或者朋友来家里，我不需要明确告诉它哪盏灯、什么亮度，而是直接说一个比较泛化的需求，让它自己去理解和执行。它更像是一个个人助理。
小七：最早为什么想到把 OpenClaw 接入 Home Assistant 和**智能家居系统**？
之阳：一开始是因为我正好在搬新家，发现传统语音助手对我的语义理解会有偏差。传统语音助手为了低时延，更多是在固定的能力集合里做指令匹配，不能做更深层次的推理。
选择 OpenClaw 的原因，主要是它当时已经完成了很多 IM 接口的适配，包括 QQ、微信等，省掉了我自己接 IM、调试和试错的成本。
小七：如果用一句话概括，你觉得这个项目真正想验证的是什么？
之阳：我更倾向于说，它验证的是 AI Agent 能不能在真实的系统场景里完成任务。不是单纯验证“AI 能不能控制家电”，而是验证 Agent 能不能落到生活场景里，把一个任务完整执行下来。它要能接收指令、理解目标、访问真实系统、调用接口、确认结果，再反馈给用户。
固定流程归传统程序，模糊目标归 Agent
小七：传统语音助手已经可以开灯、关灯，为什么还需要 Agent？
之阳：传统语音助手适合短、平、快、明确的指令。类似“打开客厅灯”这种，它的语义理解已经足够准确。但普通语音助手本质上是在一个有限集合里操作。Agent 更适合有一定复杂度、可以接受一定时延、需要多步推理的任务。
小七：如果把传统语音助手、Home Assistant 自动化规则和 Agent 放在一起看，它们分别适合什么任务？
之阳：传统语音助手适合明确、简单、低时延的指令。Home Assistant 自动化规则适合固定流程。比如开窗户后，里面的窗帘必须马上自动拉开，避免被风吹脏。这种场景需要非常稳定、快速、确定的响应，不需要大模型推理。Agent 适合的则是模糊目标、多步骤判断和临时分析类任务。
小七：之前提到的那个例子：“朋友要来家里了，帮我把灯都开一下，然后调到晚上适合的颜色”，为什么这类任务更适合 Agent？
之阳：这句话里缺少很多明确参数。它没有说家里到底有哪些灯，也没有说明应该用哪个 API，甚至“晚上适合的颜色”也需要它基于灯具支持的无级调光色温范围，也就是 2700K 到 6300K，自己去推理。
它不只是执行“开灯”动作，而是要补足设备信息、接口信息、参数范围和场景理解。
不要让 AI 直接去对接底层设备协议
IM 软件 → OpenClaw → Home Assistant → 米家网关 → 设备层
小七：这套系统的整体链路可以怎么理解？为什么选择 Home Assistant 作为中间层，而不是让 Agent 直接控制设备？
之阳：核心在于不要引入不必要的噪音。如果让 Agent 直接控制米家设备，要解决复杂的私有协议、蓝牙或 Wi-Fi 通信细节，这不应该是 Agent 关心的问题。
通过 Home Assistant 这层中间层，设备的私有协议由它来适配。对于个人开发者或者 Agent 来说，原本依赖手机 App 点按的控制流，就被转成了统一、稳定、可调用的标准 RESTful API，比如：
POST /api/services/switch/turn_on
Agent 更应该面对这样一个统一的接口层。
小七：OpenClaw 是怎么知道该调用哪些接口、使用哪些 Token、访问哪些服务的？
之阳：首先，大模型对 Home Assistant 这种主流开源软件，在训练过程中已经学到了大量先验知识，接口形式不需要我从零教起。
其次，具体使用哪些 Token、URL 和服务地址，我会写在 TOOLS.md 配置文件里。Agent 每次 loop 的时候，就会从这里加载信息，知道如何去完成鉴权与调用。
从执行到闭环：为什么“状态回查”是真实系统里的关键一步？
理解目标 → 查询状态 → 选择设备 → 推断参数 → 调用接口 → 回查结果 → 反馈用户
小七：我们拆一下“晚上适合的灯光”这个例子。用户只说了一个模糊目标，系统实际做了哪些判断和动作？
之阳：这个过程和我们平时写代码时，AI 干的活时类似，AI 先制定目标，执行代码，拿到结果后进行下一步的推理，执行，直到模型判断任务已经完成。
它先根据 TOOLS.md 理解目标；接着自主完成第一步：调用获取设备参数的接口，查询家里有哪些灯；然后在返回的 JSON 数据中筛选设备、推断出参数，比如 3000K 暖白光和 75% 亮度；随后组织请求调用接口完成控制；最后回查设备状态，并反馈给用户。
小七：执行过程中，最容易出错的是哪一步？你现在怎么判断一次任务算真正完成？
之阳：本地 HTTP 通信相对稳定。最早容易出问题的地方，一个是模型选择。便宜或免费的模型响应慢、容易断联，建议选择 Flash 这类高响应模型。
另一个优化点是设备信息。如果它每次执行任务都重新查设备，会消耗大量推理 step。
在工程实操上，可以把家庭设备列表，及可用功能固化到日常工作上下文或 TOOLS.md 中。这样 Agent 就不需要每次任务都进行批量遍历查询，能大幅节省大模型的 Context 长度与推理 Token 开销。
对于任务完成的判断，除了看 Home Assistant 返回的 status，更重要的是尽量做状态回查：继续读取设备状态，确认任务是否产生了预期结果，再把结果反馈给用户。
在 QQ 里指挥 AI 修 Bug 是一种什么体验？
小七：除了控制灯光，你还提到让 Agent 统计最近 7 天开窗情况，并生成图表页面。这个任务当时是怎么来的？
之阳：当时搬完新家后，需要经常通风排甲醛，我其实想知道“一整天累计通风多久”。这个数据如果自己看设备日志计算也行，但是比较麻烦。但 Home Assistant 里有历史数据，Agent 可以读取门窗传感器的历史状态，进行按天统计、组织数据结构，并自动生成一个 ECharts HTML 网页图表文件发回给我。
这种数据分析和轻编码交付，比单纯控制灯光更能体现 Agent 作为生产力工具的定制化价值。
小七：还有一个代码排障案例：你通过 QQ 让 Agent 查看代码、修改、重编译、**重启**服务。这个过程能不能复盘一下？
之阳：我用 Go 写了一套开门后的迎宾流程程序，后来发现视频播放失败后会阻塞主流程事件。当时我手边没电脑，就直接在 QQ 上跟 OpenClaw 说，让它去查这段代码有什么错误并帮我修。
最终它定位到了阻塞风险，完成了修改、重编译和后台进程重启，并提交了相关代码变更。这其实也能说明，Agent 已经从家居控制延伸到了个人系统运维、软件工程执行助理的边界。
当 Agent 接入系统，怎样设计一条安全红线？
📌 真实系统里的 Agent 任务拆解标准
传统程序 / 自动化规则：负责固定流程、强时序、低容错、极速响应的任务，比如开窗后立刻拉开窗帘。
Agent 运行时：负责模糊目标、多步骤判断、临时分析与轻编码交付的任务，比如根据场景调整灯光氛围、生成通风报表。
人在回路（HITL）：负责高风险、不可逆、涉及核心隐私的操作，比如代码合并、核心服务重启、限制高权限硬件控制。
小七：当 Agent 真正接进真实系统之后，你什么时候开始意识到“这个东西必须被管住”？你现在主要用哪些方式限制它？
之阳：这种安全意识在接 OpenClaw 之前就有了。日常用 AI 写代码时，我就遇到过因为模糊指令导致文件被误删的情况。所以当 Agent 触达物理设备和本地服务时，边界设计比“能做什么”更重要。
目前，我主要通过四个层级来管住它：
最小权限原则：控制家居的 Go 代码虽然托管在 GitHub 上，但配置的密钥只允许对控制家居的特定仓库进行 push，绝不允许删除。
Token 消耗限制：设置日消耗量上限，避免任务因陷入死循环而失控。
容器隔离：部署在 NAS 上的 OpenClaw 这类 Agent 被严格限定在 Docker 沙箱环境中，隔离照片、文件等其他敏感个人数据。
内网部署：只在局域网内运行，不暴露到公网，将外部攻击面降到最低。
小七：哪些操作你一定不会直接交给 Agent？
之阳：门锁可以读取状态，但不开放执行开锁的能力；对于可用的视频资源开放读的权限，不开放写和删的权限。
Agent 越是具备本地系统执行能力，我们越要保持清醒。与其先问它还能做什么，不如先定义它不能做什么。
从 IM 到语音入口，个人 Agent 还可以继续完善
这套系统后续还会继续迭代。
之阳提到，他更关注 Agent 执行侧，也就是 Harness 运行时的能力。这里的 Harness，可以简单理解成模型之外，负责组织上下文、工具调用和执行流程的一整套运行机制。即使用同一个大模型，经过不同的 Harness 框架，其组织和执行效果也可能有差异。
接下来，他希望让小爱同学成为语音输入 / 输出接口，与现有 QQ、微信 IM 共享同一个底座、上下文和记忆；也希望沉淀家庭物品位置等长期记忆，让它更接近一个家居管家；同时继续把电视、投影仪等家庭影音系统封装成标准 API，暴露给 Agent 调用。
对 Agent 来说，现在很多软件都在 CLI 化或接口化，本质上也是在变成 Agent-native 的形态。想让 Agent 承担更多生产力工作，关键在于定义好有限接口，暴露给 AI，让它去执行。
尾声
到这里，和之阳的交流就告一段落。这次聊下来，这个项目提供了一个很具体的样本：
当 Agent 接入真实系统之后，我们真正要解决的问题，不只是让它“听懂一句话”，而是还要让它知道去哪查、怎么调、如何确认结果、失败后怎么反馈，以及明确哪些事情绝对不能做。
这也是 AI 从“能聊天”走向“能执行”、真正转化为生产力之前，人类必须亲手补上的工程环节。
参考资料
- Home Assistant https://www.home-assistant.io/
