想象一下这个场景：朋友要来家里了，你对智能系统说：“帮我把灯都开一下，然后调到晚上适合的颜色。”——这句话里没有指明具体开哪盏灯，没有提供亮度或色温数值，甚至“晚上适合的颜色”本身就是一个需要揣摩的目标。对传统语音助手来说，这大概率会触发一次模糊匹配失败；但在七牛云软件开发工程师张之阳的家里，这句话已经被一个 Agent 成功解析，并完整地走了真实系统里的执行闭环。

AI 的能力正在快速进化，但站在开发者的角度来看，问题的关键已经不是 AI 能不能回答问题，而是它能不能在边界清晰的前提下接入真实系统，完成一个可验证、可闭环的任务。

这次，我们和张之阳聊了聊他基于 OpenClaw 和 Home Assistant 的智能家居 Agent 实践——从对话到执行，这个 Agent 如何接入真实设备，如何把一句模糊的指令翻译成具体的 API 调用，如何在执行后做状态回查，又如何在权限、安全和任务边界上保持克制。

访谈对象：张之阳，七牛云软件开发工程师
项目方向：OpenClaw + Home Assistant 智能家居 Agent 实践

懒人版

本期访谈的核心话题其实只有一个：当 AI 的能力越来越强，我们该怎么让它真正接入真实系统，并转化为安全、可控的生产力？

内容要点：

• 生产力转化的关键：传统语音助手擅长“开灯”这类明确指令；Agent 的价值在于理解“待客灯光”这类模糊目标，并自行补足上下文、推断参数。
• 架构的解耦哲学：别让 Agent 直接去对接底层物理协议，通过 Home Assistant 把设备能力统一 API 化，这才是正确的做法。
• 从执行到闭环：真实系统里的 Agent 不能“POST 请求发出去就结束了”，它还需要做状态回查，主动确认任务是否产生了预期的结果。
• 任务边界：定时、强时序、低容错、需要极速响应的联动，交给传统程序；目标模糊、多步推理、临时分析与轻交付任务，才交给 Agent 运行时。
• 安全准则：AI 越接近真实系统，权限越要管得住。内网部署、Docker 容器隔离、最小权限原则、独立仓库和人在回路，都是必须划定的安全边界。

一句话总结：这是一位一线开发者如何让 Agent 进入真实系统、并承担真实任务的工程复盘。

从明确指令到模糊目标：为什么传统语音助手不够用了？

小七：先从一个具体的场景聊起。你现在在家里给这个 Agent 发一句话，它最常帮你完成什么任务？

之阳：现在用得比较多的场景是，当我在外面，或者手边不方便操作设备时，让它去完成一些不是“点几个按钮就能解决”的任务。比如调整一个适合的灯光氛围——看电影或者朋友来家里，我不需要明确告诉它哪盏灯、什么亮度，而是直接说一个比较泛化的需求，让它自己理解和执行。它更像一个个人助理。

小七：最早是出于什么想法，决定把 OpenClaw 接入 Home Assistant 和智能家居系统？

之阳：起因是当时刚好在搬新家，我发现传统语音助手对语义的理解经常有偏差。传统语音助手为了追求低时延，本质上是在一个固定的能力集合里做指令匹配，做不了更深层次的推理。选择 OpenClaw，主要是因为当时它已经完成了 QQ、微信等多种 IM 接口的适配，省掉了自己对接 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 这层中间层，设备的私有协议由它来适配。对个人开发者来说，原本依赖手机 App 点按的控制流，就被转换成了统一、稳定、可调用的标准 RESTful API，比如：

POST /api/services/switch/turn_on

Agent 就应该面对这样一个统一的接口层。

小七：OpenClaw 是怎么知道该调用哪些接口、使用哪些 Token、访问哪些服务的？

之阳：首先，大模型对 Home Assistant 这种主流开源软件，在训练过程中已经学到了大量先验知识，接口的形式不需要我从零教起。其次，具体使用哪些 Token、URL 和服务地址，我会写在 TOOLS.md 配置文件里。Agent 每次循环运行时，就会从这里加载信息，从而知道如何去完成鉴权和调用。

从执行到闭环：为什么“状态回查”是真实系统里的关键一步？

理解目标 → 查询状态 → 选择设备 → 推断参数 → 调用接口 → 回查结果 → 反馈用户

小七：我们来拆解一下“晚上适合的灯光”这个例子。用户只说了一个模糊目标，系统实际做了哪些判断和动作？

之阳：这个过程和我们平时写代码时，AI 干的活类似：AI 先制定目标，执行代码，拿到结果后进行下一步推理、执行，直到模型判断任务已经完成。它先根据 TOOLS.md 理解目标；然后自主完成第一步——调用获取设备参数的接口，查询家里有哪些灯；接着从返回的 JSON 数据中筛选设备、推断参数，比如 3000K 暖白光、75% 亮度；随后组织请求调用接口完成控制；最后回查设备状态，并反馈给用户。

小七：执行过程中，最容易出错的是哪一步？你现在怎么判断一次任务算真正完成了？

之阳：本地 HTTP 通信相对比较稳定。早期最容易出问题的地方，一个是模型选择——便宜或免费的模型响应慢、容易断联，建议选择 Flash 这类高响应模型。另一个优化点在于设备信息。如果它每次执行任务都重新查一遍设备，会消耗大量推理步骤。在工程实操上，可以把家庭设备列表和可用功能固化到日常工作上下文或 TOOLS.md 中。这样 Agent 就不需要每次任务都进行批量遍历查询，能大幅节省大模型的上下文长度与推理 Token 开销。至于任务是否完成，除了看 Home Assistant 返回的 status，更重要的是尽量做状态回查——继续读取设备状态，确认任务是否产生了预期结果，再把结果反馈给用户。

在 QQ 里指挥 AI 修 Bug 是一种什么体验？

小七：除了控制灯光，你还提到让 Agent 统计最近 7 天开窗情况并生成图表页面。这个任务是怎么来的？

之阳：当时搬完新家后需要经常通风排甲醛，我其实想知道“一整天累计通风了多久”。这个数据如果自己看设备日志去算也行，但比较麻烦。而 Home Assistant 里有历史数据，Agent 可以读取门窗传感器的历史状态，进行按天统计、组织数据结构，并自动生成一个 ECharts HTML 网页图表文件发回给我。这种数据分析和轻编码交付的能力，比单纯控制灯光更能体现 Agent 作为一种生产力工具的定制化价值。

小七：还有一个代码排障的案例——你通过 QQ 让 Agent 查看代码、修改、重新编译、重启服务。这个过程能复盘一下吗？

之阳：我用 Go 写了一套开门后的迎宾流程程序，后来发现视频播放失败后会阻塞主流程事件。当时手边没电脑，就在 QQ 上跟 OpenClaw 说，让它去查这段代码有什么错误并帮我修正。最终它定位到了阻塞风险，完成了修改、重编译、后台进程重启，并提交了相关的代码变更。这其实也说明，Agent 已经从家居控制延伸到了个人系统运维和软件工程执行助理的边界。

当 Agent 接入系统，怎样设计一条安全红线？

小七：当 Agent 真正接进真实系统之后，你是什么时候开始意识到“这个东西必须被管住”的？现在主要用哪些方式来限制它？

之阳：这种安全意识在接 OpenClaw 之前就有了。日常用 AI 写代码时，我就遇到过因为模糊指令导致文件被误删的情况。所以当 Agent 触达物理设备和本地服务时，边界设计比“能做什么”更重要。目前主要通过四个层级来管住它：

• 最小权限原则：控制家居的 Go 代码虽然托管在 GitHub 上，但配置的密钥只允许对控制家居的特定仓库进行 push，绝不允许删除。
• Token 消耗限制：设置日消耗量上限，避免任务因陷入死循环而失控。
• 容器隔离：部署在 NAS 上的 OpenClaw 这类 Agent 被严格限定在 Docker 沙箱环境中，隔离照片、文件等其他敏感个人数据。
• 内网部署：只在局域网内运行，不暴露到公网，将外部攻击面降到最低。

小七：哪些操作你一定不会直接交给 Agent？

之阳：门锁可以读取状态，但不开放执行开锁的能力；对于可用的视频资源，开放读取权限，但不开放写入和删除权限。

从 IM 到语音入口，个人 Agent 还可以继续完善

这套系统后续还会继续迭代。之阳提到，他更关注 Agent 的执行侧，也就是 Harness 运行时的能力。这里的 Harness，可以简单理解成模型之外，负责组织上下文、工具调用和执行流程的一整套运行机制——即使用同一个大模型，经过不同的 Harness 框架，其组织和执行效果也可能有差异。

接下来的计划是：希望让小爱同学成为语音输入和输出接口，与现有的 QQ、微信 IM 共享同一个底座、上下文和记忆；也希望沉淀家庭物品位置等长期记忆，让它更接近一个家居管家；同时继续把电视、投影仪等家庭影音系统封装成标准 API，暴露给 Agent 调用。

其实对 Agent 来说，现在很多软件都在逐步 CLI 化或接口化，本质上也是在变成一种 Agent-native 的形态。想让 Agent 承担更多生产力工作，关键在于定义好有限接口，然后把它暴露给 AI，让它去执行。

尾声

到这里，和张之阳的交流就告一段落了。这次聊下来，这个项目提供了一个很具体的样本：当 Agent 接入真实系统之后，我们真正要解决的问题，不只是让它“听懂一句话”，而是还要让它知道去哪里查、怎么调、如何确认结果、失败后怎么反馈，以及明确哪些事情绝对不能做。

这，也是 AI 从“能聊天”走向“能执行”、真正转化为生产力之前，人类必须亲手补上的工程环节。