用了一段时间 OpenClaw 之后上周突然想到家里本来就有两个萤石云摄像头一个在客厅看娃一个在阳台看猫为什么不把它们接到 OpenClaw 上。萤石云的开放平台 API 本身做得相当充分Token 管理、云台控制、实时抓拍这些能力都有现成的接口技术上应该是可行的。加上部署 OpenClaw的 Mac mini 24 小时在线本地跑模型的条件也具备。先说结论这套方案已经稳定跑了一周了整个过程还是做了 N 次工程迭代效果才稳定下来。从最初的帧差法运动检测频繁误报到引入 YOLO 小模型做语义预筛再到本地多模态大模型做场景理解甚至为了解决错失重要画面的问题重构了底层的时间轴中间经历了好几轮架构推翻和重建。交互方式也从单纯的指令查询逐步优化成了“后台静默巡视无事不报 异常即时推送”的双模式。每一步也都是在实际跑起来之后发现问题、解决问题、再优化的过程。这套方案虽然是从看娃看猫这个家居场景出发的但底层的技术逻辑其实具备通用性。办公室无人值守监控、独居老人看护、工厂或仓库的安防巡检只要有 IPC 摄像头 边缘算力 大模型推理能力都可以用类似的架构来实现。技术栈上涉及了 YOLO 目标检测轻量预筛、本地多模态视觉模型场景理解、解决录制延迟的工程组件ffmpeg以及 OpenClaw 的 Skill 封装和飞书群消息推送等。这篇试图说清楚萤石云 API 的对接踩坑与能力边界、从像素级帧差到 YOLO 语义检测的技术演进和实测数据、多模态大模型在端侧部署的性能权衡、YOLO 预筛 → VLM 推理 → 一票否决的级联架构、解决时效性盲区的投机式预录制、以及 OpenClaw Skill 封装和飞书交互的完整工程实现。以下enjoy:全文内容的概览图1、基础链路验证和硬件 API 打交道的坑实际动手之前我先快速了解了下萤石云开放平台的 API 能力。有一说一萤石云的文档在国产 IoT 厂商里算做得不错的核心接口Token 管理、设备列表、云台控制、抓拍、直播流地址获取都有而且走的是标准的 HTTPS POST 模式不需要逆向私有协议。相比之下TP-LINK 这类品牌的摄像头到现在都没有公开的开发者 API想接入只能走逆向抓包稳定性和合规性都是问题。https://open.ys7.com/cn/s/supportcenter进一步家里不同摄像头的能力差异也需要提前搞清楚。我放在客厅那台 CP1 是云台摄像头支持预置点巡航和方向控制阳台的 C2C 是固定机位只有抓拍和直播流功能没有云台。这意味着代码里必须做设备路由其中涉及云台操作preset/move、ptz/start的指令只能发给 CP1C2C 收到会直接报错。https://open.ys7.com/console/application.htmlAPI 能力搞清楚之后我开始逐个跑通基础链路。这个过程踩了几个坑问题都不大但如果不解决好对后续处理环节会有不小影响。1.1、云台预置点APP 上找不到入口第一个坑是预置点怎么设。客厅面积虽然不是很大但云台摄像头放在一个角落单个角度没办法很好的覆盖全部区域。所以我计划设置至少两个预置点让脚本控制摄像头在两个角度之间切换才能完成整个客厅的巡视覆盖。但在萤石云 APP 里翻了好几遍始终没有找到预置点的配置入口。后来发现其实完全不需要在 APP 里操作。萤石云的 API 本身就支持云台方向控制ptz/start、ptz/stop和预置点保存preset/add所以我干脆写了一个终端交互式的调试脚本preset_wizard.py。运行之后直接用键盘方向键控制摄像头转动按 P 抓拍预览当前角度图片会自动在 Mac 上弹出来满意了按 S 保存为预置点。还支持切换快速模式和精细模式来控制转动幅度整个体验像在用一个终端遥控器。# 键盘方向键映射终端原始模式下的 escape 序列 KEY_MAP { \x1b[A: up, # ↑ \x1b[B: down, # ↓ \x1b[D: left, # ← \x1b[C: right, # → } # 用户按方向键 → 调 API 转动云台 → 按 P 抓拍预览 → 按 S 保存预置点BTW这种先写一个小调试工具把硬件交互跑通再做正式业务开发的做法实测在涉及物理设备的项目里非常实用。调试时不用反复掏手机打开 APP 操作所有控制都在终端里完成效率高很多。1.2、云台转到位之前就抓拍一片模糊第二个坑比较隐蔽。调用preset/move让云台转向预置点后如果立刻调用抓拍接口拿到的图片是一片模糊。毕竟云台的物理转动需要时间还没停稳就拍了拍出来整张图都是运动拖影喂给后面的视觉模型分析纯属浪费算力。不过这点没什么好办法实测下来preset_move之后必须sleep4-6 秒等物理停稳。代码里我把这个等待时间抽成了环境变量MOVE_WAIT默认 4 秒实际部署时可以根据摄像头型号微调。1.3、抓拍频率限制同一设备 4 秒内返回旧图第三个坑是抓拍频率。萤石云的抓拍接口对同一设备有频率限制两次抓拍间隔低于 4 秒的话第二次返回的还是上一次的图片。这个在文档里没有写明是测试时发现 URL 完全相同才反应过来的。代码里的处理方式是在 capture() 函数内部做了节流维护一个 _last_capture 字典记录每个设备的上次抓拍时间调用时如果间隔不够就自动 sleep 补齐。def capture(device_serial): last _last_capture.get(device_serial, 0) elapsed time.time() - last if elapsed CAPTURE_INTERVAL: time.sleep(CAPTURE_INTERVAL - elapsed) data api(/api/lapp/device/capture, { deviceSerial: device_serial, channelNo: 1 }) _last_capture[device_serial] time.time() # ...1.4、Token 7 天过期的解法最后一个坑是最容易被忽略的也是影响最大的。萤石云的 AccessToken 有效期只有 7 天过期之后所有 API 调用会静默失败。不报错只是返回一个错误码10002或10014。如果不做处理系统跑了一周之后会突然挂掉而且看日志又没有 crash 的那种。解法是在 API 调用的最底层做错误码嗅探和自动续期。每次调萤石云接口如果返回码是 Token 过期相关的就自动清空旧 Token、重新申请、用新 Token 重试原来的请求。整个过程对上层业务完全透明。def api(endpoint, params): params[accessToken] get_token() r requests.post(f{EZVIZ_BASE}{endpoint}, dataparams, timeout15).json() if r.get(code) 200: return r.get(data, {}) # Token 过期 → 自动续期 → 重试 if r.get(code) in (10002, 10014): global _token _token None params[accessToken] get_token() r requests.post(f{EZVIZ_BASE}{endpoint}, dataparams, timeout15).json() if r.get(code) 200: return r.get(data, {}) return None这部分的设计原则是凡是有过期概念的凭证必须在最底层做自动续期而不是靠上层定时刷新。如果你在业务层写一个定时任务每 6 天刷一次 Token看起来能用但一旦定时任务漏跑或者服务重启了Token 一样会过期。把续期逻辑放在api()函数里等于给整个系统兜了底不管什么时候调用、不管 Token 现在是什么状态都能自愈。1.5、小结这个阶段的目标就是把整条基础链路跑通Token 认证 → 双设备信息查询 → 云台预置点控制 → 抓拍 → 图片下载。没有什么特别的技巧主要是跟硬件 API 的各种边界条件打交道。2、视觉模型选型从付费到免费基础链路跑通之后紧接着要解决的就是理解画面的问题。摄像头能抓拍了但后续的功能比如判断画面里是不是宝宝然后触发提醒或者汇总一天的活动记录生成日报都依赖一个多模态视觉模型来分析图片内容。选型上我先后测试了一个闭源 API 和开源本地部署两条路线。2.1、闭源方案OpenRouter Gemini Flash老规矩先调闭源旗舰模型的 API 跑通整条链路。做 to B 项目养成的习惯——第一天永远先测天花板而不是 baseline。确认效果上限在哪之后再去想成本优化和本地替代方案。这次用的是 OpenRouter 调google/gemini-3-flash-preview响应 2-3 秒结构化 JSON 返回很稳定效果没问题。但成本算下来不太行两个小时测试过程中就消耗了 $0.632。其中2 分钟调用一次的频率是综合测了几轮之后定下来的太快了 API 吃不消太慢了监控就聊胜于无。按这个频率算一天 720 次调用一天十几块一个月几百块就为了看看客厅有没有人。当然可以把频率调到半小时甚至一小时来省钱但那样监控的实际意义就大打折扣了。所以按量付费模式在高频监控这个场景下无论家居还是企业级都不太划算。另一个促使我考虑本地方案的因素是隐私。家庭监控的画面持续往云端发这件事本身就反直觉。而且现在多模态的开源小模型已经足够强了我的 OpenClaw 本身就部署在 Mac mini 上16GB 统一内存跑一个小几 G 的视觉模型完全没压力。对于看看画面里有没有人、猫在干啥这种不要求极低容错率的场景本地小模型的能力完全够用确实没必要持续依赖云端。2.2、本地 Ollama MiniCPM-V既然成本和隐私都指向本地部署接下来就是选模型了。Qwen3-VL-8B 我在之前做工业质检项目的时候用过Q4 量化版在 Mac 上跑起来整体效果还行。但这次想换一个试试。面壁智能的 MiniCPM-V 25 年 8 月份发布以来在开源社区里讨论很多号称是端侧视觉模型的小钢炮8B 尺寸在 Ollama 上量化后只有 5.5GB而且据说是行业首个具备高刷视频理解能力的多模态模型。正好趁这个项目实测一下。实测时用了几张真实的摄像头抓拍照片涵盖客厅和阳台两个场景。MiniCPM-V 能很好的识别出地上散落的玩具、老人抱着孩子这类常见画面也能判断阳台上有没有猫返回的结构化 JSON 格式稳定中文描述也比较自然。对于看看画面里大概有什么这个需求来说完全够用。性能数据也整体够用指标数值冷启动首次加载进内存~21 秒/张热推理模型常驻内存~5.5 秒/张模型体积5.5GB运行设备Mac mini M4, 16GB 统一内存在 Apple Silicon 的统一内存上跑起来完全没有卡顿。而且由于 Cron 任务每 2 分钟触发一次相当于持续给 Ollama 保活模型一直常驻在内存里不会被卸载Ollama 默认 5 分钟没有请求就会自动卸载模型释放内存下次调用又变成冷启动实际推理延迟稳定在 5.5 秒左右。顺道提一个选型时踩过的坑。在测 MiniCPM-V 之前我为了省内存先试过 Qwen3-VL 的 2B 版本结果三张图全部返回空字符串JSON 解析直接崩掉。翻了一圈 GitHub Issues 和 Reddit 才发现这不是个例。Qwen3 系列在 Ollama 上请求format: json时输出内容会写进内部的thinking字段导致 API 返回为空通过 Ollama API 发 base64 图片时也会偶发空返回而且 2B 这个参数量面对复杂 JSON Schema 中文 Prompt 图片的三重约束生成链路确实很容易崩。这些更多是小尺寸模型在工程管线中的不稳定性表现模型标称支持视觉和在实际项目里真正跑通是两回事选型一定要在真实场景中做端到端测试。3、YOLO 预筛从像素差到语义过滤多模态模型选好了但还有一个更前置的问题没解决。每 2 分钟抓一张图每张都直接丢给 MiniCPM-V 跑一遍的话5.5 秒一张大部分时间画面里什么都没发生纯属浪费算力。所以在 MiniCPM-V 之前还需要有一个轻量的前置判断也就是判断画面里到底有没有人或猫有才值得唤醒 MiniCPM-V 做进一步分析。3.1、像素差值法最直觉的方案也是最先崩的最开始的思路很简单粗暴直接用 OpenCV 做像素差值。先简单解释一下这个做法的原理就是把两张图片都转成灰度图每个像素只剩一个 0-255 的亮度值然后逐像素做减法得到一张差值图。差值图里亮的地方就是两张图不一样的区域统计亮像素的占比就能得到一个变化率。拍一张空房间的基准照片之后每次抓拍都和基准对比像素变化超过 15%拍脑袋定的就认为有异动唤醒多模态模型去进一步分析。但简单测试了下发现这个方案最直接的问题就是基线污染不可控。换句话说如果拍基准照片的时候角落里恰好放了个快递纸箱或者婴儿车那之后这个纸箱被拿走、婴儿车被推走后当前画面和基准的差异会一直存在。系统就会不停唤醒 MiniCPM-V 去看一个空房间。当然有一种更好的思路是换成动态基线也就是不跟固定基准图片比而是每次拿当前帧T和上一帧T-1对比。听起来似乎合理但实际还是不行主要有两个问题误报窗帘飘一下、电视画面切换、扫地机器人跑过去都是大面积像素变化全部触发告警;漏报如果宝宝在地垫上睡着了两分钟内一动不动T 和 T-1 的像素差为零。系统判定无变化直接跳过但实际这个场景也需要关注。说白了纯像素级的比对根本不理解画面内容分不清窗帘在飘和有个人进来了。要解决这个问题还是得从像素过滤升级到语义过滤。3.2、引入 YOLO0.03 秒判断有没有人YOLOYou Only Look Once是目标检测领域的标杆模型它能在一次前向推理中同时完成目标定位和分类。不看像素变了多少直接判断画面里有没有 person、有没有 cat。可能不是所有盆友都只是 YOLO 是啥这里再稍微介绍一下。YOLO 在工业视觉领域应用非常广泛比如工厂产线上的缺陷检测、交通场景的车牌识别、安防领域的危险物品检测等。但那些场景通常需要针对特定目标做大量的图片标注和模型训练门槛不低。但我这个家居场景比较凑巧YOLO 官方的预训练模型是基于 COCO 数据集Common Objects in Context微软发布的大规模目标检测基准数据集训练的开箱即用就能识别 80 个常见类别包括 person、cat、dog、car、bicycle、chair、couch、tv、cell phone、backpack 等等日常物体。所以要识别的人和猫恰好就在这 80 类里面完全不需要额外标注数据拿来直接用就行。所以引入 YOLO 之后预筛逻辑从“这张图和上张图有什么不同”变成了“这张图里有没有关心的对象”这是一个本质性的升级。还有个题外话其实 YOLO 系列经过多年迭代已经有非常多版本和分支了从最早的 YOLOv1 到现在最新的 YOLO262026 年初由 Ultralytics 发布专门针对边缘设备优化中间还有 YOLO11、YOLO12 等。这里不打算展开讲不同版本差异我直接选了业界用得最多也最成熟的 YOLOv8 系列。YOLOv8 提供了从小到大的多种尺寸体积从 6MB 到 130MB 不等。因为是本地跑所以策略就是从最小的开始往上试找到效果和体积的平衡点。一开始为了追求极致速度我用了最小的 YOLOv8nNano 版6MB。结果实测宝宝穿着白色连体衣缩在垫子上的时候Nano 模型把他识别成了teddy bear泰迪熊置信度只有 0.28。这是小模型压缩太狠导致的分类漂移姿态稍微奇特一点就认错。YOLOv8n识别效果于是我做了一轮全系压测在 Mac mini 上用同一张客厅复杂画面宝宝和老人都在跑了一遍模型体积推理耗时最高置信度漏报YOLOv8n (Nano)6MB~12ms0.28误识别有YOLOv8s (Small)21MB~36ms0.86无YOLOv8m (Medium)50MB~74ms0.89无YOLOv8l (Large)83MB~130ms0.90无YOLOv8s识别效果从 Small 到 Large推理时间翻了近 4 倍但置信度从 0.86 到 0.90 的提升在实际系统里毫无意义。只要超过 0.4 的阈值脚本就往下走纠结 0.86 和 0.90 没有任何价值。最终选了 YOLOv8s36 毫秒跑一次甚至比人眨一下眼睛还快并发看 4 路监控也毫无压力。3.3、大小模型级联YOLO 预筛 VLM 精判总结来说YOLO 是先解决了“有没有”的问题但它没有语言理解能力你没法给它写 Prompt。它只能告诉你“画面里有个 person”但分不清这个 person 是宝宝还是奶奶在扫地。所以最终的架构是两层级联第一层YOLO 语义预筛成本极低。 客厅摄像头的代码只认 person 标签看到猫、扫地机器人一律忽略阳台摄像头只认 cat 和 dog。这一层 36 毫秒就能完成过滤掉 90% 以上的空画面。第二层MiniCPM-V 精细判断成本较高但精准。只有通过 YOLO 预筛的图片才会送到 MiniCPM-V。大模型能理解复杂指令比如画面里是宝宝在独自玩耍还是有大人在旁边看着。如果 MiniCPM-V 判断这只是老人在扫地整条链路静默结束不推送任何消息。这套级联架构的核心思想是用几乎零成本的小模型过滤掉绝大多数无效请求只把真正需要理解的画面交给大模型。 在实际运行中YOLO 每天过滤掉大约 90% 的抓拍大模型的实际调用次数从每天 720 次降到了 60-70 次Mac mini 的负载也从持续高位变成了间歇性的低负荷。4、抓拍即录解决重要画面错过的问题上面的大小模型级联架构在逻辑上已经跑通了YOLO 预筛 → MiniCPM-V 判断 → 推送飞书群。但上线后很快发现一个诡异的问题。YOLO 明明检测到了人或猫MiniCPM-V 也确认了但发到飞书群里的 10 秒录像 GIF 里人和猫要么只剩个背影要么已经完全走出了画面。4.1、先说为什么是 GIF 而不是视频这里插一句为什么最终选择发 GIF 而不是视频。最开始我确实是用 ffmpeg 录 10 秒 MP4然后以文件链接的形式发到飞书群里。但飞书不认本地file://协议。我人在公司用电脑打开飞书根本打不开 Mac mini 上的本地路径。而且飞书机器人的 API 对直接发送视频文件有严格的大小和格式限制。后来换了个思路索性直接用 ffmpeg 把 10 秒视频压成动态 GIF-vf fps5,scale480:-1 -c:v gif。飞书原生支持 GIF 内联显示在聊天窗口里自动循环播放不用点击、不用下载体验比发视频文件好太多了。4.2、时间轴排查T8 秒的流水线延迟回到正题GIF 里看不到人第一反应是录像时间太短或者摄像头角度有问题。但反复检查之后发现摄像头角度没问题问题出在时间轴上。为了方便理解我把整条流水线按时间排一遍各位就清楚了第 0 秒Cron 定时任务触发调萤石云 API 抓拍一张静止照片。此刻宝宝正好在客厅中央。第 0.5 秒YOLO 跑完预筛36ms判定画面里有 person。第 1~6 秒图片送给 MiniCPM-V大模型花 5.5 秒做推理分析。第 7 秒MiniCPM-V 返回结果确认是宝宝。脚本这才开始启动 ffmpeg 拉直播流录像。第 8~9 秒ffmpeg 调萤石云 API 拿直播流地址~1 秒再建立 RTSP/HLS 连接握手~1-2 秒。第 10 秒ffmpeg 真正开始录制画面。也就是说从抓拍那一刻到 ffmpeg 真正开始录画面已经过去了将近 10 秒。小朋友 10 秒钟不知道爬到哪里去了。所以 GIF 里看不到人或者猫是完全正常的录的是事发 10 秒后的画面。4.3、第一次改进YOLO 判断有人就开始录发现问题之后第一个想法是不要等大模型出结论再录而是把录制动作前置到 YOLO 预筛之后。YOLO 只要 36 毫秒就能判断有没有人判断有人就立刻在后台拉起 ffmpeg 开始录同时大模型并行做推理。如果大模型最后判定是误报比如只是老人在扫地就悄悄杀掉 ffmpeg 进程、删掉临时 GIF不推送。代码上就是用subprocess.Popen无阻塞启动 ffmpeg大模型和录制并发执行。但上线一测GIF 里的画面还是有延迟。排查发现虽然我在 YOLO 出结果后约第 0.5 秒就发起了录制命令但 ffmpeg 内部还要走一遍“获取直播流地址 建立连接握手”的流程这个过程又吃掉了 2-3 秒。实际开始录制画面的时刻是 T3 秒甚至更晚宝宝和猫还是有可能已经走出画面了。4.4、终极方案抓拍的同时就开始录想明白之后其实很简单不应该在任何判断之后才启动录制而应该在抓拍照片的那一瞬间就同步启动 ffmpeg 建连。新的时间轴变成了第 0 秒Cron 触发抓拍静止照片 ← 同时后台 ffmpeg 开始调 API 拿直播流地址、建连握手第 0.5 秒YOLO 预筛完成36ms第 1~2 秒ffmpeg 完成握手开始真正录制画面。此时画面和刚才抓拍的照片高度一致第 1~6 秒MiniCPM-V 在并行做推理第 7 秒大模型出结论。此时 GIF 已经录了 5~6 秒的关键画面如果 YOLO 预筛判定画面里没有关心的目标空房间就立刻terminate()杀掉后台 ffmpeg 进程并删掉临时文件。投机成本就是一次 API 调用和几秒的 ffmpeg 进程占用几乎可以忽略不计。这个方案的核心思想是“启动代价低 可随时杀掉”的投机式预录制比“确认后再录”的保守策略好得多。 本质上就是用极少量的 CPU 和网络成本换取了画面的时效性。整个通知链路最终压缩到了约 8 秒5.5 秒 AI 分析 2.5 秒飞书投递GIF 里终于能看到完整的人和猫了。5、Skill 封装与飞书群交互技术链路全部跑通之后最后一步是把这些零散的脚本和能力统一封装起来接入 OpenClaw让它真正变成一个日常可用的工具。5.1、从测试脚本到 monitor.py回顾整个开发过程前面几章讲的每个环节萤石云 API 对接、预置点调试、YOLO 预筛、MiniCPM-V 分析、ffmpeg 抓拍即录在开发阶段其实都是独立的测试脚本。API 调试有api_test.py预置点有preset_wizard.pyYOLO 压测有yolo_bench.py各跑各的。最终我把所有能力收拢到了一个 600 多行的monitor.py文件里它封装了整个端到端开发过程中积累的十几个测试脚本的核心逻辑是整个系统的引擎接收指令 → 控制摄像头 → 抓拍 → YOLO 预筛 → VLM 分析 → 生成 GIF → 输出结果。一个脚本完成全链路。在 OpenClaw 的 Skill 体系里一个 Skill 本质上就是一个SKILL.md描述这个 Skill 能做什么、怎么调用加上实际的脚本文件。Agent 通过 SKILL.md 的描述来理解用户说了这句话应该调用哪个命令。比如我在飞书群里说帮我看看客厅现在什么情况Agent 就知道该调monitor.py的客厅巡视命令。不过要澄清一点搞了这一大套东西核心价值不是让人在飞书群里手动输入指令去查摄像头那还不如直接打开萤石云 APP 看实时画面来得快。真正有意义的是接下来要讲的定时任务系统在后台自动巡视、自动判断、自动推送人不需要做任何操作有情况了它会主动来找你。5.2、多摄像头路由一个反直觉的坑这里有个踩坑值得讲。家里两个摄像头职责不同客厅的看宝宝阳台的看猫。但一开始 SKILL.md 的描述写得太笼统导致 Agent 经常搞错。比如我问“八月今天吃了几次饭”八月是猫的名字Agent 却去查客厅摄像头然后回复客厅里没有看到猫。解法很暴力但有效在 SKILL.md 里用极其强烈的语气做路由绑定。客厅摄像头的描述写的是专门看宝宝千万不能用这个摄像头去找猫阳台摄像头写的是专门看猫。Agent 对这种强调语气的指令遵从度非常高改了之后再也没路由错过。5.3、定时任务实现自动化封装好 Skill 之后通过 OpenClaw 自带的 Cron 定时任务来实现自动化运行宝宝巡视每 2 分钟客厅摄像头自动抓拍 → YOLO 预筛 → 有人才唤醒 VLM → 确认是宝宝就推送 GIF猫咪巡视每 2 分钟阳台摄像头同理检测到猫就推送家庭日报每天 18:00汇总一天的巡视记录生成一份合并版日报推送到群里这几个场景的设计也是初步的测试抛砖引玉。宝宝巡视主要是我和老婆不在家的时候想知道她在客厅干什么、大致状态怎么样。系统检测到宝宝就会生成一段 GIF 发到群里没事的时候点开看一眼就行不用专门去翻监控回放。猫咪巡视主要是看它每天吃饭、喝水、上厕所的情况阳台摄像头正好覆盖了猫的食盆和猫砂盆。而每天 18:00 的家庭日报相当于一个整体汇总今天宝宝在客厅出现了几次、大致在做什么猫今天吃了几顿、活跃度怎么样都会总结在一份日报里推过来。这样不用每天回家翻视频记录扫一眼日报就对一天的情况有个大致了解。5.4、静默协议和推送控制还有一个细节问题是巡视任务大部分时间画面里什么都没有脚本不需要输出任何内容。但如果脚本什么都不输出Agent 反而会脑补一句一切安全~发到群里。一天几百条一切安全还不如不发。解法是在脚本里定义了一个[SILENT_SAFE_STATE]协议——无事发生时输出这个特殊标记在 Cron 的 message 里强制要求 Agent 看到这个标记就闭嘴不要做任何回复。这样 99% 的时间群里是完全静默的只有真正检测到目标才会推送一条 GIF。当然前提要选择个好用的模型指令遵循才靠谱。另外还做了推送冷却同一个事件比如宝宝在客厅1 小时内只推送一次避免宝宝在客厅玩一下午群里每 2 分钟来一条的轰炸。隐私方面也做了两个机制在飞书群里说“别拍了”脚本会调萤石云 API 让摄像头云台转向天花板物理层面确保不拍到任何画面晚上 6 点到早上 6 点家人都在家脚本里的_is_quiet_hour()会自动跳过所有巡视任务既不浪费算力也不会半夜突然推个消息出来。5.5、日常体验整套系统稳定跑起来之后日常体验大概是这样的飞书群我 老婆 openclaw机器人 ↕ OpenClaw Gateway (Mac mini) ├── Skill: ezviz-monitor │ ├── Ollama (MiniCPM-V) ← 本地 VLM零成本 │ ├── YOLOv8s ← 语义预筛36ms │ ├── 萤石云 API ← 摄像头控制 抓拍 直播流 │ └── ffmpeg ← 10 秒 GIF 动图抓拍即录 ├── Cron: baby-patrol (*/2) ← 客厅巡视 ├── Cron: cat-snapshot (*/2) ← 阳台巡视 └── Cron: daily-report (18:00) ← 家庭日报绝大部分时间群里是完全静默的。宝宝进客厅了来一段 10 秒 GIF然后沉默 1 小时。猫去阳台干饭了同样来一段 GIF然后沉默。每晚 18:00 一份合并版的家庭日报宝宝的巡视记录和猫的吃喝拉撒明细都在里面。当然还可以随时在群里主动查询实时调摄像头拍一张回来分析。整套方案的运行成本忽略不计API 费用 ¥0本地 Ollama硬件全是家里已有的Mac mini 两台萤石云摄像头月度成本如果要算就是一点电费。6、写在最后6.1、从看娃到看工厂这套思路能迁移到哪里回头看整个项目技术上其实没有用到什么前沿的东西。萤石云的开放 API、一个 8B 的开源视觉模型、一个 21MB 的 YOLO 目标检测模型、ffmpeg 录个 GIF。真正有价值的不是某个单点技术而是这套摄像头 小模型预筛 大模型精判 定时任务 消息推送的组合模式。这个模式的本质是把人盯屏幕变成AI 盯屏幕人盯通知。任何一个场景只要满足已经有摄像头和需要有人一直盯着这两个条件这套架构就能直接迁移过去。举个我之前在一个技术播客里听到的案例。一家饺子连锁店行业里判断饺子熟没熟的标准很简单饺子浮到水面上来就可以捞了。下饺子的员工当然会盯着锅但老板担心的是另一件事。忙的时候员工为了赶单没等饺子全浮上来就提前捞了夹生的饺子端上桌差评就多了。靠人盯人不现实老板不可能站在每口锅后面看。后来的做法是在锅上方架了一个摄像头部署一个端侧视觉模型。这里面工程上我具体了解了下有些讲究。锅上方全是水蒸气和气泡摄像头本身要防雾耐高温图像预处理要做滤波降噪去掉气泡产生的虚假边缘目标检测用的是轻量模型YOLO 或 MobileNet 级别训练阶段标注饺子在水中的三种状态——沉底、半浮、完全漂浮而且不能只看单帧还得结合持续漂浮时间来判定是否真正煮熟避免翻滚时的误判。但对老板来说模型最终回答的就是一个问题“这锅饺子全浮上来了没有”浮上来了就开始计时到了标准时间就提醒员工捞。这个案例和看娃项目的内核完全一致把复杂问题降维成是/否判断用最小的模型做最确定的事后台用规则兜底最后通过消息通道打通最后一公里。如果再套上 Agent 定时任务的框架老板就可以在钉钉群里问今天几锅饺子超时了每天自动收到生产效率日报多店还能统一汇报给区域经理。类似的场景还有很多家门口的访客/快递提醒、会议室占用检测、零售货架缺货巡检、工厂安全帽穿戴检查、危险区域入侵告警……底层逻辑都是一样的。6.2、跳出这个项目聊几句工程方法论这个项目虽然是从看娃看猫出发的但文章最后还是想分享一个核心判断大模型凭借泛化能力和推理能力解锁了大量之前技术路线做不了的应用场景。但在真实世界的 AI 落地里它只是拼图中的一块甚至不一定是最重要的那一块。 就拿这套看护系统来说真正用到大模型的环节只有场景理解承担最高频工作量的是 15 年就有的 YOLO串联一切的是 ffmpeg、Cron、环境变量这些老古董。大模型的价值不是取代这些东西而是和它们协同。这个规律在其他项目里同样成立我在之前介绍过的售前报价项目里数据治理用到了聚类算法做相似度归组结构化数据的编排靠的是规则引擎和经典 NLP大模型只在最后一步做自然语言生成和复杂推理兜底。最近在聊的一个节能减排项目也是类似的结构核心的能耗计算和异常检测是传统算法在做大模型负责的是报告生成和人机交互。真正能交付的系统往往是大模型、传统模型和经典算法各司其职的结果。所以归根到底还是那句老话以需求和场景为导向选择技术不要拿着锤子找钉子。 保持架构简单每一层职责清晰不迷信任何单一技术路线。能用 21MB 的 YOLO 解决的就不要动用 5.5GB 的视觉大模型能用 Cron 兜住的逻辑就不要交给 Agent 去推理。6.3、源码与课程这个项目的完整源码我已经封装成了 OpenClaw Skill 压缩包——包含SKILL.mdSkill 定义、monitor.py600 多行的核心脚本、.env.example密钥模板以及配套的图文教程。如果你家里也有萤石云摄像头和一台 Mac mini填好密钥解压到 Skills 目录下10 分钟就能跑起来。用其他品牌摄像头的话改一下 API 层就能适配。这套 Skill 的源码和完整教程已经放在了我的企业大模型应用从入门到进阶的视频课程和知识星球里。课程之除了 15 个完整企业级大模型应用落地案例拆解之外后续会继续不定期更新些最新一些工具包作为附赠资源。知识星球相对比较适合在一线参与项目实践的盆友有会员交流群提供日常免费答疑并会送书和这套视频课程。