本地AI巡检NAS：异常自动微信告警方案

NAS 或家里的小主机突然死机，往往要等到断网影响使用时才被发现。其实，不用购买昂贵的监控平台，让本地大模型配合一段轻量脚本就能实现主动告警。B 站 UP 主分享的方案核心只有两样东西：一个零依赖巡检脚本和一个微信通知机器人脚本。两者均用纯 Python 标准库编写，无需安装任何第三方包，低功耗机器也能轻松运行。当硬盘快满、内存爆满或核心容器挂掉时，脚本会第一时间抓取异常并主动推送通知，告别每天手动登录后台巡检的繁琐。

核心组件：零依赖巡检与微信通知

方案仅需两个脚本。巡检脚本负责检查系统关键指标，如硬盘使用率、内存占用和容器状态。它完全基于 Python 标准库，不引入外部依赖，因此对系统资源占用极低，适合在 NAS 或低功耗小主机上长期运行。微信通知机器人脚本则负责将告警信息打包成 Payload 并发送到微信。据 UP 主演示，核心代码只需几十行，当检测到预设阈值超标时，自动触发告警。

这种设计的好处在于轻量且可控。传统监控平台往往需要部署代理、配置数据库，甚至购买订阅服务，而该方案将复杂度降到最低，只需两个脚本文件即可覆盖最常见的异常场景。对于家庭用户来说，维护成本几乎为零。

微信机器人 Webhook 与 Payload

微信本身并没有面向个人用户的开放机器人 API，文中说的“微信通知机器人”通常指企业微信群机器人或第三方中转服务提供的 Webhook 地址。Webhook 本质上是一个预先分配好的 HTTPS 接口，只要向它 POST 一段 JSON（即 Payload），消息就会出现在对应的群聊里。Payload 中最关键的是 msgtype 字段（如 text、markdown、news），它决定消息以纯文本、Markdown 还是卡片形式渲染；卡片形式还能带标题、描述和跳转链接，视觉上更接近文中提到的“告警卡片”。这种方式的优点是服务端只做接收、无需长连接和鉴权握手，脚本侧只要 urllib.request 这一个标准库模块就能完成发送，正好契合“零依赖”的设计。需要注意 Webhook 地址等同于口令，泄露后任何人都能往群里发消息，因此建议放在环境变量或单独的配置文件中，不要硬编码进脚本。

检测机制：阈值触发与容器监控

巡检脚本的核心逻辑是阈值检测。例如，当硬盘使用率超过设定值、内存占用达到临界点，或者核心容器意外停止时，脚本会判定为异常。UP 主在视频中展示了检测到阈值超标后的处理流程：脚本自动打包告警数据，并通过微信机器人发送。

这种基于阈值的检测方式虽然简单，但非常有效。它不依赖复杂的监控系统，也不需要持续采集大量指标，只需关注最关键的健康信号。对于家庭 NAS 来说，硬盘满、内存耗尽和容器崩溃正是最常见的故障原因，抓住这几点就能覆盖大部分风险。

脚本还具备一定的灵活性，用户可以根据自己的设备情况调整阈值。例如，硬盘使用率可以设置为 90% 或更低，内存占用可根据总容量设定合理上限。这种可定制性让方案能适应不同配置的 NAS 和小主机。

容器状态的检测方式

脚本判断“核心容器挂了”并不需要接入重量级监控体系，常见做法有两类。第一类是读取容器运行时暴露的本地接口：Docker 默认在 /var/run/docker.sock 提供 Unix Socket，通过它可以列出容器、查询 State.Running 或 State.Status 字段；Podman 也有兼容接口。第二类是退而求其次，用 subprocess 调用 docker ps 并解析输出。前者更干净但需要脚本进程对 Socket 有读权限（通常意味着加入 docker 组，权限较高），后者实现简单、依赖外部命令存在。除了“是否在运行”，更严格的判断还会看重启次数（RestartCount）和健康检查状态（Health.Status），因为容器可能处于 running 但内部服务已经无响应。对家庭 NAS 场景来说，先监控“容器是否退出”已能覆盖大多数故障，再叠加健康检查即可进一步提升准确度。

交互体验：向本地助手询问状态

除了自动告警，该方案还支持交互式查询。用户只需问本地助手一句“家里 NAS 现在状态如何”，助手便会调用工具执行巡检脚本，并立即汇报当前状态。这相当于为 NAS 增加了一个自然语言接口，让状态查询变得像聊天一样简单。

据 UP 主介绍，本地大模型在这里扮演了调度角色。它理解用户意图，调用预先定义的工具函数，并整理结果返回给用户。整个过程在本地完成，不依赖云端服务，既保护隐私又减少延迟。

工具调用（Function Calling）

让本地大模型“执行脚本”靠的是工具调用机制，而非模型本身能运行代码。具体做法是：在请求模型时附带一份工具描述（函数名、用途、参数 JSON Schema），模型根据用户问句判断是否需要调用、调用哪个函数、传什么参数，并返回一个结构化的调用意图；宿主程序解析后真正去执行巡检脚本，再把脚本输出作为工具结果回传给模型，由模型组织成自然语言回答。因此模型只负责“理解意图”和“组织措辞”，权限与执行始终掌握在本地程序手里。本地部署的开源模型（如通过 Ollama 运行的 Qwen、Llama 系列）大多已支持这一能力，但小参数量模型在参数格式上容易出错，通常需要在解析层做容错。整条链路完全离线，用户数据不出本机，这也是相比云端助手的主要优势。

实测效果：三秒内精准送达

UP 主进行了实测：无论是拔掉网线模拟断网，还是模拟硬盘满载，微信都能在三秒钟内精准收到告警卡片。这种实时性意味着故障发生后几乎立刻就能知晓，而不是等到影响使用才被动发现。

从被动挨打到主动防御，区别显而易见。传统方式下，用户往往要等到断网或服务不可用才去排查，而本地 AI 实时巡检能在异常发生的第一时间发出通知，让用户提前干预，避免数据丢失或服务中断。

为何要模拟“拔网线”

断网是 NAS 最典型也最隐蔽的故障之一：设备本身仍在运行、硬盘灯照常闪烁，但远程访问、同步和影音服务全部不可用，用户往往要等到想用时才发现。拔网线测试的意义在于验证监控链路是否能覆盖“网络层面”的异常，而不只是进程层面的崩溃。需要注意的是，如果巡检脚本就跑在被监控的同一台机器上，机器整体宕机或彻底离线时脚本自身也无法发出告警。更稳妥的做法是加一层“心跳”机制：脚本定时向外部端点上报存活，由外部侧在超时未收到心跳时反向告警；或者干脆把巡检脚本部署在另一台常开设备上，通过 SSH 或 HTTP 检查目标主机。这样“机器完全挂掉”这一类最严重的场景才不会被漏掉。

方案优势与适用场景

该方案的最大优势是零依赖、轻量、低成本。纯 Python 标准库编写意味着不需要 pip 安装任何包，避免了环境冲突和依赖管理的麻烦。低功耗机器也能流畅运行，不会对 NAS 本身造成负担。微信通知则覆盖了最常用的即时通讯工具，无需额外安装 App。

适用场景包括家庭 NAS、小型服务器、树莓派等低功耗设备。对于个人用户和小型团队来说，这是一种高性价比的监控告警方案。UP 主透露完整告警代码在视频简介第一行，并预告下期将介绍一键搭建本地知识库检索。

总结

本地 AI 巡检 NAS 的方案用极简的脚本实现了实用的告警功能。它不追求大而全的监控平台，而是聚焦于最常见的故障场景，通过阈值检测和微信通知，让用户第一时间获知异常。对于追求轻量和自主可控的用户来说，这是一个值得尝试的思路。