本文最初发布于 2026 年 10 月 6 日，2026 年 10 月 7 日更新。
文中五张场景图基于我的房间照片用 AI 生成。人物、环境数值和提示界面用于展示理想体验，当前实现进度见后文。
我想要一个懂我的家，像管家一样照顾我#
有时坐在房间里，已经觉得有点闷了，我还在忙手里的事，没想起来开空调。我希望家里的终端能先注意到温度和湿度的变化，轻轻提醒一句：“房间有点闷，要不要帮你开一会儿空调？”
我说“好”，它就按我平时喜欢的设置去做。我说“先不用”，它就知道这次不用，过一会儿也不用反复提醒。
到了晚上，如果它能可靠地感知我已经睡着，而灯还亮着，就按我事先同意的习惯把灯关掉。这件事不需要再叫醒我确认，也不需要我睡前记得说一遍“关灯”。
我理想中的智能家居，是一个懂我的智能管家。很多时候，我只需要享受被照顾的过程。 它能结合家里的环境、我的生活状态和已经了解的偏好，主动发现哪些事值得做。拿不准时问我一句，约定好的日常小事就安静地完成。
“懂我”也包括知道什么时候不用服务。我正在专心做事，就少打扰；我刚拒绝了建议，就不用追着问；我临时改了空调设置，就尊重这次调整。哪些事可以自动做、哪些事需要问我，可以在使用中慢慢形成约定，也能随时改回来。
我主动开口时，它当然也应该听懂。“灯太亮了”“柔和一点”“空调别那么冷”，都可以是自然的表达。在电脑旁点网页、对房间里的终端说话、让自己的 Agent 操作，也应该用到同一套设备能力。
这里面需要连起来的，是感知环境和人的状态 → 理解需求 → 提出建议或按约定行动 → 确认设备响应。设备配网、账号授权和初期偏好设置仍然需要完成，但我希望随着使用，自己要操心的事情越来越少。
下面记录的是我朝这个方向走出的第一步。我买了 HomeLink 生态的设备，把手机里的控制能力接到了自己的后台和 ESP32。目前已经跑通了执行链路，主动提醒、睡眠感知和自动照顾还没有实现。
从买设备到配好，我实际走了哪些步骤#
这次用到的主要是 LinkJapan 的 eRemote 5+、接入 HomeLink 的智能灯，以及原有空调和一块 ESP32 语音终端。房间里的黑色落地灯分上下两个灯头，在控制目录里对应上方灯、下方灯。
买回来、装好之后，首先还是用厂商的手机 App 把设备配置好。我实际走过的路径是：
- 配好 eRemote 5+，在 HomeLink 里确认原有空调能接收红外控制。
- 把智能灯接入 HomeLink，确认上、下两路灯能分别操作。App 里可以调颜色、色温和亮度，空调也有温度和模式设置。
- 尝试 Siri 快捷指令。我仍然需要先添加动作、配置唤起方式，再考虑自己说的话能否对应到它。
- 在 Alexa 手机 App 里启用 HomeLink 技能、关联账号，再实际试一次家电控制。这一步成功后，才继续接自己的程序。
HomeLink 与 Alexa 的关联有厂商提供的官方路径：先在 HomeLink 配好设备，再启用技能并完成账号关联。我使用的就是这条路径。LinkJapan 官方连接说明
到这里，手机上已经可以操作家电。接下来我才遇到另一个问题：自己的网页、Agent 和 ESP32，要从哪里取得这些设备的控制能力？
如果重新走一遍选购，我会多问一句：除了能在 App 里使用，这台设备有没有可授权的程序接口？能不能读出支持的功能与状态？以后换一个控制入口，已有设备能否继续使用？这些问题会直接影响后面需要自己搭多少桥。
理想和现状的差距，出现在这些地方#
下面只比较我这次实际用到的设备和接入过程。
| 我期待的体验 | 这次遇到的现状 |
|---|---|
| 给自己的后台授权后，同步已绑定的设备及能力 | HomeLink 能官方关联 Alexa；我的后台还要另建 Alexa 会话，通过非官方库访问 |
| 根据温湿度和我的偏好主动建议开空调，我确认就好 | 目前先接通了控制，还没有做持续读取温湿度、主动建议和确认的流程 |
| 可靠感知我已经睡着后，按约定自动关灯 | 还没有接入可靠的睡眠状态，也没有实现这类自动服务 |
| 用自己的话说需求，不反复设置固定短语 | Siri 的这条路径需要先配置快捷指令；我后来通过小智和 MCP 接上了设备工具 |
| 已有房间和设备关系可以继续沿用 | 能从 Alexa 读到设备，但我的账号这次没有返回可用房间分组，需要自己新建房间 |
| 操作后知道家电是否真的响应 | 两路灯由我观察实物确认；空调的红外请求回报，不能直接当成空调实际收到指令 |
我也试过直接走局域网。电脑和 eRemote 在同一家庭网络，开源 Broadlink 库确实发现了设备，但认证没通过，没有拿到可用控制会话。我没有为了继续试验重置已经配好的设备。
HomeLink 里的“云联动设置”，我当时看到的是根据温度、湿度触发家电的配置。明确的条件和动作，本来就可以用这类规则完成。我想继续往前做的是：同样的温湿度变化，还能结合我是否在家、当前在做什么、之前有没有拒绝过建议，决定该提醒、该行动，还是暂时不打扰。这次没有从云联动页面取得能直接给自己的 Agent 使用的控制接口。
这些经历让我意识到，手机 App 能用、设备能被发现、自己的程序能控制，是三个需要分别验证的环节。先让 Agent 有实际能调用的动作，再逐步接入它判断需求所需的信息。只有执行能力，还做不到主动照顾我；只有一个会聊天的模型，也没法把判断落实到家电上。
我先自己补上了后台与终端之间的连接#
最终跑通的是：HomeLink 关联 Alexa，Home Hub 后台接入 Alexa，再把经过校验的家电能力交给网页和小智。ESP32 负责采集语音、播放回答。
这里有两次不同的连接。HomeLink 到 Alexa 使用官方技能；Home Hub 到 Alexa 使用非官方开源库 alexa-remote2，读取设备目录并发送控制请求。后者仍会受到 Amazon 接口、登录方式和会话变化的影响。alexa-remote 项目
首次登录时，我也以为浏览器已经登录 Amazon，后台就能直接用了。实际还需要给适配程序建立自己的 Alexa 会话。我通过只监听本机的登录代理，登录同一个日本 Amazon 账号、完成验证码。过程中遇到过登录后跳转“地址无效”，修正登录实现里的一个 OAuth 命名空间字段后，才继续读到设备。
授权材料由后台私下保存，没有放进固件或公开仓库。登录页面成功之后，我还继续读取目录、发送开灯指令并观察实物，才确认这一段真的可用。
接语音时，小智通过 MCP 获得两个工具：home_list_devices 用来查看设备与能力，home_control_device 用来对明确的设备执行动作。后台主动连接小智的云端 MCP 接入点，注册工具，再接收调用；这里没有把整个网页后台“导入”小智。小智 MCP 示例
这次没有为家电控制重刷 ESP32 固件。语音的识别、理解和回答仍走原来的小智通道，网页和 MCP 工具共用后台执行层。自己的其他 Agent 也可以复用这类工具和模块，但需要接好它自身的工具注册与授权。
我还给这套后台做了一个日常入口，叫作 Home Hub。界面主要分为“智能设备”和“智能家居”：前者管理 ESP32 的概览、屏幕、语音和更新，后者把灯和空调放到房间里。点房间中的设备标记可以发送开启指令，开关和高级调节也能在设备面板中操作。
房间图来自我自己拍的两张照片。我让 AI 保留床、桌子、苹果电脑、木色柜门、空调、黑色双头落地灯，还有窗台上一整排娃娃、床上的小熊和香蕉抱枕，把杂物简化掉。它是一张固定视角的效果图，设备标记单独绑定，并非实时画面或精确的三维扫描模型。
房间有数据时先尝试从 Alexa 同步，没有时可以自己新建、选择已有设备、上传照片、生成实景图并确认标记，也能删除和恢复。家电配网仍在厂商侧完成，Home Hub 负责组织入口。
现在后台已经部署为云端常驻服务，本机试验用的桥接已停止，日常使用不再要求我的 Mac 一直开着。整条链路仍依赖互联网、Alexa、HomeLink 和小智。
我已经做到哪一步#
最明确的一次实物验证来自这两句话：
| 我对 ESP32 说的话 | 后台执行 | 我看到的结果 |
|---|---|---|
| 关闭上方灯 | 上方灯，turn_off | 上方灯实际熄灭 |
| 打开下方灯 | 下方灯，turn_on | 下方灯实际亮起 |
这说明“我说话 → 智能体调用工具 → 后台操作真实设备”这条链路已经跑通。以后无论是我主动说一句，还是管家提出建议、我确认之后再执行，都需要这层基础。
其他进展需要分开看：
| 能力 | 当前进度 | 还需要做的事 |
|---|---|---|
| 网页控制、房间管理、云端常驻 | 页面与服务已上线，Alexa 和小智工具连接已验证 | 持续观察长期运行情况 |
| 灯光亮度、色温、颜色 | 按设备目录声明的能力接入了接口和控件 | 逐项观察实物响应，验证语音表达 |
| 空调开关、温度、模式 | 接入对应操作；当前目录开放制冷、制热 | 完整实机验收，保留红外结果未确认的反馈 |
| 用更多自然表达控制家电 | 已有小智工具调用基础，实测了上述明确指令 | 验证不同说法、上下文指代和模糊目标的追问 |
| 其他个人 Agent | 核心模块可复用 | 为具体 Agent 接入工具、授权并做实测 |
| 根据温湿度主动建议开空调 | 尚未实现；读到传感器条目，也不代表已接通持续的温湿度数据 | 验证环境读数与更新时间，加入个人偏好、建议和确认流程 |
| 感知入睡后自动关灯 | 尚未实现 | 接入可靠的睡眠状态来源，按事先约定执行并验证误判处理 |
| 偏好记忆、少打扰、多设备配合 | 后续目标 | 记住已确认的习惯和拒绝，允许临时覆盖与修改约定 |
后台也做了请求校验、重复请求检查、过期与取消处理，以及重启后不补发结果不明的动作。当前后台的 92 项测试与 2 项 AI SDK 模拟测试通过，发布与线上检查已完成；这些检查不能代替真实设备验收。
还有一个没有解决的问题：最初那轮语音操作后，ESP32 曾持续响声、失联，断电后恢复。后来接 USB 读到的日志没有故障现场的崩溃堆栈，原因还不明确，需要继续抓取现场、做连续语音测试。
所以，我现在完成的是一套能日常进入、能调用设备、已有灯光实物验证的控制台。它让 Agent 有了可以操作的家电。下一阶段才是让它有足够的信息，知道什么时候值得提议、什么时候可以按约定行动，逐渐从控制入口走向照顾人的管家。
哪些我能继续做，哪些需要官方支持#
我自己可以继续完善界面、工具调用、环境判断、偏好记忆和主动服务流程。更稳定、更容易让别人复用的底层接入，则需要厂商或平台提供相应能力。
| 环节 | 我自己可以做什么 | 希望官方提供什么 |
|---|---|---|
| 设备接入与授权 | 维护现有桥接、保管会话、展示连接状态 | 稳定、可撤销的官方程序授权，明确哪些设备和动作允许访问 |
| 设备能力 | 适配参数、校验范围、按能力显示控件 | 清楚的设备目录、亮度与色温范围、空调支持模式及兼容说明 |
| 环境与人的状态 | 接入可用的温湿度、在家或睡眠信号，处理过期数据和不确定性 | 支持这些能力的设备或平台开放可授权的读数、事件、更新时间与含义说明 |
| 操作与反馈 | 记录执行结果，区分成功、失败和未确认 | 稳定的控制接口、状态读取或事件通知，明确回报代表什么 |
| 房间与日常入口 | 自建房间、照片实景、设备标记和网页面板 | 在授权范围内开放已有房间与设备关系，减少重复整理 |
| 自然语言交互 | 接入模型，理解不同说法，追问不明确的目标，按已确认偏好组合动作 | 让设备能力可被程序调用，提供开发文档、示例和接口变更说明 |
| 主动服务与少打扰 | 设计建议、确认、自动执行的流程，记住偏好与拒绝，提供暂停和修改入口 | 提供前述可持续获取的状态与控制能力，让服务有可靠依据 |
例如，拿到持续更新的温湿度、空调能力和我的偏好后，我可以自己做“提出建议 → 等我确认 → 执行 → 反馈”的流程。想实现睡着后关灯，还要有可靠的睡眠状态来源；房间一时没动静，本身不足以说明人已经睡着。
如果红外空调没有实际状态回传，换一个更聪明的模型也不能凭请求成功证明空调已经响应。官方开放接口、状态和能力说明，会直接影响这样的管家能不能长期可靠地工作。
我希望用户授权之后，开发者能读到设备和环境信息、知道可用动作、发出操作并获得清楚反馈。怎么理解我的需要、什么时候提醒、怎样少打扰，可以由自己的 Agent 继续完善。这样，我可以把时间更多放在被照顾的体验上，也能少依赖非官方会话适配来维持基础连接。
比如，如果我已经确认读书时喜欢柔和的暖白光，管家以后就可以按这个偏好调整灯光。我临时改了亮度，它也能尊重当下的选择。这类体验需要把设备调节、场景判断和个人偏好连起来。
这类思路已有平台在实践。Home Assistant 的 Assist API 能把向助手开放的设备能力交给语言模型；Google Home 的 Home APIs 提供了由用户授权应用访问家中设备的机制。它们分别展示了能力调用和授权的做法，我希望自己的 HomeLink 接入以后也能有更稳定的官方路径。Home Assistant LLM API、Google Home Permissions API。
把跑通的核心开源，大家可以一起往前做#
关键桥接代码已经整理成独立的 MIT 开源仓库：homelink-xiaozhi-mcp。
里面提供日本 Amazon 登录、Alexa 设备目录与家电开关、小智 MCP 连接、命令行入口和测试。它使用全新的仓库历史，没有带入个人会话、接入点或私有后台配置。运行环境是 Node.js 22.13 及以上的 macOS/Linux；具体设置和已知限制请看 README 与安全说明。
公开出来的是授权、设备开关和 MCP 桥接核心。 完整 Home Hub 的空间界面、AI 实景图、房间管理和高级调节，还没有全部同步到这个独立仓库。按开源 README 运行，得到的是这条桥接链路。
如果想学习或复现，可以按下面的顺序：
- 先在 HomeLink 和 Alexa App 里分别确认自己的设备可用。
- 按 README 安装桥接器、登录自己的账号，读出真实设备列表。
- 选一个明确的灯具，先做一次开关，并观察实物结果。
- 再接入小智 MCP，用 ESP32 发出相同意图，核对工具调用和实物响应。
- 在读懂目录适配、请求校验和工具注册之后，再尝试接自己的 Agent，或扩展设备已经开放的能力。
我希望这个仓库能让大家看清楚：自然语言、工具调用和家电操作之间，具体怎样接起来。不同设备有什么能力，哪些步骤能复用，哪里仍需要厂商配合，都可以继续拿真实设备来验证、交流。
下一步，我会先把灯光亮度、色温、颜色，以及空调温度和模式逐项做完实机验收，确认执行基础可靠，再尝试接入持续的温湿度信息，从“主动建议、由我确认”这样的小场景开始。睡眠感知和自动关灯，则等可靠的状态来源与执行约定准备好，再继续做。
我希望有一天，忙起来时，家会先替我留意房间是不是闷了；睡着以后，它会把还亮着的灯关好。我仍然可以随时表达想法、改变决定，但很多日常小事已经有人替我想着。这是我想用 Agent 慢慢做出来的家的样子。
参考资料#
- LinkJapan：HomeLink 官方 FAQ——HomeLink 与 Alexa、Siri 等入口的关联方式。
- LinkJapan：Alexa 连接说明——先在 HomeLink 配好设备，再启用技能并关联账号。
- Apollon77：alexa-remote——本次后台采用的非官方 Alexa 适配库。
- Apollon77：alexa-cookie——Alexa 登录会话获取与续期实现。
- 小智：MCP 示例程序——外部工具与小智云端接入点之间的连接方式。
- Home Assistant：LLM API——通过意图和工具向语言模型开放家庭设备能力。
- Google Home：Permissions API——用户授权应用访问家中设备的机制。
设备接入与响应来自这次实践，不能据此推断所有 HomeLink 型号或所有自然语言表达都已验证。