岩风：【深度测评】我扒了小米Miloco的源码，发现离“贾维斯”还有点距离

岩风：【深度测评】我扒了小米Miloco的源码，发现离“贾维斯”还有点距离 岩风：【深度测评】我扒了小米Miloco的源码，发现离“贾维斯”还有点距离 Modified November 21, 2025 Miloco提示词 Bash 行动 (Action)：如果思考后确定需要与外部世界交互（查询状态、控制设备等），则生成一个或多个符合OpenAI Tool Calling格式的工具调用。 观察 (Observation)：你会接收到调用工具后返回的结果。你必须基于这个新的信息，回到第1步（思考（Think）），判断是需要继续调用其他工具，还是已经可以提供最终答案。 输出格式与严格约束 (Strictly Enforced) Markdown格式: 所有输出必须使用Markdown格式。 思考标签: 思考过程必须且只能被包裹在 <reflect 和 </reflect 标签内。 最终答案标签: 当你确信已收集到所有必要信息，能够完整回答用户问题时，在最后的 <reflect </reflect 之后，必须使用 <final answer 和 </final answer 标签包裹最终的、面向用户的回复。因为收集的信息可能会有冗余，你需要根据用户的需求，对结果优化后再输出。 工具调用格式: 工具调用必须严格遵循OpenAI的Tool Calling格式，并且不能出现在<reflect 和 </reflect 标签内部。 禁止捏造: 绝对禁止编造任何工具的返回结果或设备状态。 简洁性: 你的思考过程应尽可能简洁、切中要害。 示例 (One Shot Demonstration) 用户请求: "帮我打开客厅的灯" 你的输出: <reflect 我需要分两步操作： 首先，我需要调用工具查询客厅灯的当前状态。 然后，根据返回的状态决定是否需要调用工具来开灯。 现在执行第一步。 </reflect (行动(Action)：调用工具查询客厅灯的当前状态) (观察 (Observation): 系统返回客厅灯的当前状态) 你的输出: <reflect 我观察到客厅灯的状态是 熄灭。我现在需要执行第二步，即调用工具打开客厅灯。 </reflect (行动(Action)：调用工具打开客厅灯) (观察 (Observation): 系统返回开灯操作的结果) 你的输出: <reflect 我已经成功执行了开灯操作。任务已经完成，现在可以向用户报告最终结果了。 </reflect <final answer 客厅的灯刚才没有开，现在已经为您打开了。 </final answer 总结来说，目前的 Miloco 更像是一个处于 Alpha 阶段的“大型玩具”。 经过实测，除了“人来灯亮”这种 Hello World 级别的基础指令，面对真实生活中稍微复杂一点的需求，它都显得捉襟见肘。想要作为日常工具使用，目前还为时过早。 优化建议：假如我是产品经理 抛开槽点，回归产品本源。 基于对代码逻辑的梳理和实际场景的体验，为了让 Miloco 能真正从“玩具”变成“工具”，我提出以下几点硬核建议： 1. 拒绝 Token 浪费，启用“批量推理” 目前的逻辑是：如果你有3个规则（看有没有人读书？有没有人摔倒？有没有人睡觉？），系统会把同一张照片分别发给 AI 问3次。 这就好比你去超市买3样东西，却跑了3趟，既费腿（延迟高）又费钱（Token贵）。 建议优化方案： 设计一个“条件合并器”。检测到多个规则共用一个摄像头时，把问题打包成：“请帮我看看画面里是不是有人读书，或者摔倒，或者睡觉？” 效果：AI 调用次数从 3 次降为 1 次，Token 消耗和网络开销直接节省 60% 以上。 优化前： 优化后： 2. 与 HA 的关系：做“超级传感器”，而非“简陋控制器” Miloco目前接入 HA 的方式有些“鸡肋”：它试图通过 API 去触发 HA 的自动化。 想法我是理解的，希望通过接入HA，实现“Miloco作为大脑判断，其他品牌电器执行指令”的效果。可是由于Miloco 目前的能力远不及 HA 的灵活，因此玩家们不太可能从HA转向Miloco。 建议：参考开源项目 Frigate 的思路，将 Miloco 定位为 HA 的“超级视觉传感器”。不要试图去接管自动化流程，而是专注于输出高质量的结构化数据（如：谁？在哪？干什么？）。把决策权交还给 HA，让用户能在 HA 强大的自动化引擎中调用这些“视觉参数”，这才是高阶玩家真正想要的。 3. 内部定位：专注做“眼睛”，别抢“手脚”的活 对于规则引擎，我的建议是：切忌从零开始造轮子。 Miloco 的核心护城河应该是是视觉感知，而不是逻辑编排。现阶段另起炉灶去写一套简陋的规则系统毫无必要。建议团队尽快将视觉能力模块化，封装成独立的逻辑组件嵌入米家现有的自动化体系。 理想形态是：让 Miloco 专心做极其敏锐的“眼睛”，让米家自动化专心做执行有力的“手脚”。两者分工明确，体验才能质变。 总结 虽然挑了不少刺，但我依然对 Xiaomi Miloco 充满期待。它就像是一个刚刚学会睁眼看世界的婴儿，虽然动作笨拙，但底子极好。它标志着智能家居终于开始从“让用户适应规则”向“让 AI 适应用户”迈进。我一直期待拥有一位像《钢铁侠》里“贾维斯”那样的 AI 管家，很高兴看到小米正走在这条路上。 一起交流 我是岩风，一位AI路上的探索者，期待与大家的交流～ 如果你对这篇文章有意见/建议，或者有更多好玩的AI+智能家居的点子，欢迎来找我！ 总结来说，目前的 Miloco 更像是一个处于 Alpha 阶段的“大型玩具”。 经过实测，除了“人来灯亮”这种 Hello World 级别的基础指令，面对真实生活中稍微复杂一点的需求，它都显得捉襟见肘。想要作为日常工具使用，目前还为时过早。 优化建议：假如我是产品经理 抛开槽点，回归产品本源。 基于对代码逻辑的梳理和实际场景的体验，为了让 Miloco 能真正从“玩具”变成“工具”，我提出以下几点硬核建议： 1. 拒绝 Token 浪费，启用“批量推理” 目前的逻辑是：如果你有3个规则（看有没有人读书？有没有人摔倒？有没有人睡觉？），系统会把同一张照片分别发给 AI 问3次。 这就好比你去超市买3样东西，却跑了3趟，既费腿（延迟高）又费钱（Token贵）。 建议优化方案： 设计一个“条件合并器”。检测到多个规则共用一个摄像头时，把问题打包成：“请帮我看看画面里是不是有人读书，或者摔倒，或者睡觉？” 效果：AI 调用次数从 3 次降为 1 次，Token 消耗和网络开销直接节省 60% 以上。 优化前： 优化后： 2. 与 HA 的关系：做“超级传感器”，而非“简陋控制器” Miloco目前接入 HA 的方式有些“鸡肋”：它试图通过 API 去触发 HA 的自动化。 想法我是理解的，希望通过接入HA，实现“Miloco作为大脑判断，其他品牌电器执行指令”的效果。可是由于Miloco 目前的能力远不及 HA 的灵活，因此玩家们不太可能从HA转向Miloco。 建议：参考开源项目 Frigate 的思路，将 Miloco 定位为 HA 的“超级视觉传感器”。不要试图去接管自动化流程，而是专注于输出高质量的结构化数据（如：谁？在哪？干什么？）。把决策权交还给 HA，让用户能在 HA 强大的自动化引擎中调用这些“视觉参数”，这才是高阶玩家真正想要的。 3. 内部定位：专注做“眼睛”，别抢“手脚”的活 对于规则引擎，我的建议是：切忌从零开始造轮子。 Miloco 的核心护城河应该是是视觉感知，而不是逻辑编排。现阶段另起炉灶去写一套简陋的规则系统毫无必要。建议团队尽快将视觉能力模块化，封装成独立的逻辑组件嵌入米家现有的自动化体系。 理想形态是：让 Miloco 专心做极其敏锐的“眼睛”，让米家自动化专心做执行有力的“手脚”。两者分工明确，体验才能质变。 总结 虽然挑了不少刺，但我依然对 Xiaomi Miloco 充满期待。它就像是一个刚刚学会睁眼看世界的婴儿，虽然动作笨拙，但底子极好。它标志着智能家居终于开始从“让用户适应规则”向“让 AI 适应用户”迈进。我一直期待拥有一位像《钢铁侠》里“贾维斯”那样的 AI 管家，很高兴看到小米正走在这条路上。 一起交流 我是岩风，一位AI路上的探索者，期待与大家的交流～ 如果你对这篇文章有意见/建议，或者有更多好玩的AI+智能家居的点子，欢迎来找我！ 背景 上周一个平凡的周五下午，小米公众号突然发布了一篇名为《Xiaomi Miloco 智能家居未来探索方案》的文章 (https://mp.weixin.qq.com/s/lBGWgAFOK9AIA1YT1aQBng)。作为一名智能家居玩家，我第一反应自然是好奇，但点进去仔细看完后，我愣住了。 这思路，和我半个多月前写的两篇文章简直如出一辙！ 我给AI装上了“眼睛”，它成了我的“专属啦啦队”，每天坐到工位就准时加油！ 我给AI装上了“眼睛”，它成了我的“专属啦啦队”，每天坐到工位就准时加油！ 我给台灯装上“AI之眼”，它学会了“察言观色”，比小爱同学还贴心！ 我给台灯装上“AI之眼”，它学会了“察言观色”，比小爱同学还贴心！ 还好小米仍然做不到 岩风：硬核DIY：不到400元，我给85岁外婆造了个AI管家 的全部功能，我一不小心居然走在了小米的前面。 岩风：硬核DIY：不到400元，我给85岁外婆造了个AI管家 哈哈哈，开个玩笑。小米这次是从底层搭建了一整套系统，而我当时只是站在 Home Assistant（HA）这位巨人的肩膀上 DIY 。既然大厂也认可这个方向，作为智能家居探索者，我必须得好好测评一番。 为了这次测评，我不惜斥巨资 107.5元，从闲鱼淘了一台二手的小米摄像头，收货后立马开干！ 产品体验情况 小米官方宣传的核心优势主要有四点：超简单、超聪明、超安全、超开放。 其中“超安全”提到的端侧模型部署，由于本人囊中羞涩，买不起高配显卡（无法运行本地大模型），只能调用云端模型，所以本次测评主要聚焦于“AI视觉”和“创建规则”功能。 1. AI 视觉识别：从“盲人摸象”到“睁眼看世界” 这项功能是 Miloco 的核心，也是我认为最具划时代意义的变革。相比于传统的红外 PIR 或毫米波雷达，AI 视觉让智能家居从底层的“条件感知”进化到了高阶的“语义理解”。 • 传统传感器只能告诉你：“这里有人（1）”或者“这里没人（0）”。 • AI 视觉能告诉你：“谁在这里？他在干什么？甚至他的情绪怎么样？” 这让原本呆板的自动化变得有“人情味”了： • 场景A（安防）：看到陌生人，系统不仅不开灯，还会锁门并报警。 • 场景B（贴心）：看到你双手拎着购物袋，不仅开灯，还自动帮你拉窗帘，因为它知道你腾不出手 。 • 场景C（懂你）：看到你戴着耳机神情疲惫，它会调暗灯光并保持静音，而不是大声喊欢迎词。 此外，它还补齐了视觉交互这块短板： • 当AI识别到你的眼神正看着智能音箱时，它自动进入“聆听模式”。你只需要直接说“关灯”，无需喊唤醒词。 • 你可以在不说话（怕吵醒家人）也不按开关的情况下，对着摄像头比一个“嘘”的手势让音响静音，让交互更加自然和人性化。 代码级的深度解析 为了搞清楚Miloco是如何实现的，我找到github仓库扒了它的源码。目前Miloco的AI视觉主要有两种用法：一是通过自然语言问“我的猫在哪”，这相对简单；二是创建规则后的循环判断（如：监测到有人读书就开灯） 通过分析代码，我梳理出了它的监测运行逻辑： 这套逻辑中有几个非常精妙的设计： 1. 2秒心跳机制：系统每隔2秒采集一次画面，既保证了实时性，又不会过度消耗资源。 2. DHash 算法“守门”：这是最聪明的一点。在调用昂贵的 AI 大模型之前，系统会先用计算量极小的 DHash 算法对比图片变化。如果画面静止，直接跳过，不麻烦 AI。这极大地节省了算力和 Token 费用。 3. 防重复触发逻辑：代码中设置了触发间隔判断，避免了因为动作连续变化导致指令重复发送（比如灯光疯狂开关）。 这也印证了我之前的 DIY 思路，确实是英雄所见略同。实测下来这套逻辑还挺稳定可靠，但是我发现Miloco当前AI条件判断只能判断是/否，这会产生很大资源的浪费，具体参见“拒绝 Token 浪费，启用“批量推理”。 “拒绝 Token 浪费，启用“批量推理” 2. 创建规则：一句话定义自动化 这个功能听起来很像现在的语音助手，其实现在的小米手机和音箱已经可以实现了，不是什么特别新鲜的东西。 我实测了一个指令：“当有人阅读时，打开台灯”。系统成功生成了规则卡片，体验确实流畅。 幕后的“管家”：Actor 模型 通过代码分析，我发现 Miloco 为了处理这种复杂交互，引入了 Actor 模型。这就像雇了一个不知疲倦的管家，流程如下： 简单来说，当你发出指令后，系统会生成一个独立的Actor模型。它会去查设备、写草稿，然后把预览发给你。最关键的是，它会挂起等待（Wait） 你的确认，最多等600秒，这期间它不占系统资源。这种异步确认机制，比米家 App 直接生效多了一步“安全锁”，有效防止了 AI 听错话导致乱操作。 翻车实录：理想很丰满，现实全是Bug 正当我以为这是米家自动化的“终极形态”时，深入体验后，我开始频频翻车。目前的版本离“可用”还有很大距离。 1. 多任务处理“失忆” 当我试图创建一个稍微复杂的规则：“当我走进房间，打开台灯并用音箱播报”。 结果，系统大概率只记住了后半句，把“打开台灯”给漏了。 2. 无法理解“时间” 我尝试设置：“进房间开灯，2分钟后关闭”、“每天晚上8点打开台灯”， AI 两手一摊：臣妾做不到。因为目前的条件触发逻辑仅限于摄像头对画面的“即时状态”判断，缺乏对时间维度的定时和延时处理能力。 3. 效率堪忧 虽然 Miloco 使用了先进的 ReAct 工作流（思考 行动 观察），但用在简单控制上简直是“大炮打蚊子”。 关个灯，它要先查设备列表、再查属性、再发送指令……如果不开启“缓存指令”，这一套下来至少半分钟。这造成一些需要几秒内反应的实时决策动作，比如根据用户在桌前的状态（阅读、用电脑、玩手机）调整台灯亮度和色温，几乎是不可用的状态。