先说清楚我这边的网络有多少台设备。

我在几个不同地点各有一张局域网，互相连不通，每一张都要自己维护。设备加起来 86 台（这是 MiBee Steward 扫出来的数字，文里的截图都是它自己的界面），其中 13 台当时处于离线状态。

然后我打开自己的 Excel 表格准备核对——那张表是我半年前手打的。

半年前我按记忆记了一版，之后就没再更新。里面有三个 IP 早就换了设备，有两台机器我拆了搬走，还有一台 NAS 现在接在完全不同的网段上。也就是说这张表里至少 6 条记录是错的，而且我完全不知道是哪 6 条。

这不是懒的问题。是「靠人脑维护一份会过期的清单」这件事本身不成立——设备会变，而你不会在每次变化之后记得去改表。

哪怕你只有十几台设备，这件事也一样成立。手机换个 MAC、NAS 换个网段、路由器重启后 DHCP 重新分配，每一次变化都在让清单过期。

所以我写了 MiBee Steward：扫网络、认出设备、把状态持续跟踪下去。它今天刚发了 v0.7.0，这篇文章把它讲清楚。

## 扫到什么

![图片](https://developer.qcloudimg.com/http-save/yehe-1102153/1cb20348e4f2d3bb17de3dc276636a03.jpg)

设备列表。左上角四个数字：总数 86、在线 73、离线 13、未知 0——标题里那个 86 就是这里来的。每行带类型徽章，能按状态、类型、网络筛选，也能导出 CSV。

识别效果直接看名字：viomi-waterheater-e13 认成小米的热水器，Z4S-2PSE 认成极空间的 NAS，orangepi-zero3 认成香橙派的板子。这些名字都是设备自己在 DHCP 主机名、SSDP 里报出来的，Steward 从里面把品牌和型号抠出来。

![图片](https://developer.qcloudimg.com/http-save/yehe-1102153/dc4533ca866a117c24913ef76a0cdd10.jpg)

仪表盘。顶部横幅「需要关注：13 台离线」，右上环形图是心跳成功率 85%——有设备掉线它直接摆在脸上，而不是等你哪天想起来去 ping 一下。

对一张网络资产表来说，第一件事不是「好看」，是「数字对不对」。我第一次扫完跟那张 Excel 对，差出来十几条。

![图片](https://developer.qcloudimg.com/http-save/yehe-1102153/0774a52bac59ce2663e8bf16dda0e0f5.jpg)

拓扑视图是我做出来之后自己用得最多的。中心橙色节点是网关（我这里是 GL.iNet），一圈节点按网关/核心/接入层/终端四类着色，也能按这四类筛选。哪台交换机下挂了哪台机器、哪条链路通到哪个网段，看一眼就知道——比翻列表快得多。

## 它认设备靠的是指纹，不是你填表

自动发现这件事本身不新鲜，nmap 早就能扫出 IP 了。真正难的是「这台 IP 后面是什么设备」——网段里哪个是摄像头、哪个是交换机、哪个是 NAS。

MiBee Steward 的做法是插件化的扫描管线，五层：探测 → 分类 → 处理 → 持久化 → 编排。探测层拿到设备吐出来的 banner、HTTP 响应、RTSP/ONVIF 握手内容、SNMP 的 sysDescr；分类层拿这些证据去比对 YAML 写的指纹规则库，匹配上就推出类型、品牌、型号。

指纹库是能贡献的。你发现某个设备没被认出来，把它的 banner 抓下来写一条规则提 PR，识别能力就长一分。v0.7 里这个库刷新了两轮（recog 部分从 Rapid7 Recog 重新导入，2534 → 2548 条），OUI 厂商表也补上了小米生态的 13 个前缀——之前表里一个小米的 MAC 段都没有。

有两处设计我认为是这个项目真正区别于普通扫描器的地方：

一是被动发现优先。设备不一定要能被主动探测到才认出来。DHCP 租约里的主机名、旁听到的 mDNS/SSDP 公告、conntrack 里正在建立的连接、hostapd 的 STA 列表——这些信息设备自己是交出来的，不需要你发一个包过去。我在 R68S 路由器上实测过，主动 mDNS 查询 100% 无应答，但被动旁听能拿到很丰富的信息。这就是「能认出不回应的设备」和「只能认出肯回应的设备」的区别。

二是识别准确度需要积累。做两台设备的时候指纹库可能几百条就够，但真实网络里米家设备、摄像头、各种嵌入式设备千奇百怪，这个库是按实测不断长的。这是投入方向，不是能一步到位的功能。

## 相比同类，它的位置在哪

我把 MiBee Steward 和几个常见选项对了一遍，说下我的实际判断。

LibreNMS / Zabbix 是网络监控工具，做的是设备已经在网管系统里之后的持续监控。它们的模型假设是你已经知道有哪些设备；MiBee Steward 是去发现「那里到底有什么」。这两件事序列不同，所以不是替代关系。

NetBox / Snipe-IT 是 CMDB，模型是对的（资产登记、记录变更），但它们的手工录入是你的起点，你得先把设备一条条填进去。

nmap 是扫描器，它连管理界面都没有，更没有身份识别和持续登记。

MiBee Steward 占的格子是：自动发现（nmap 级）+ 身份识别（基于指纹）+ 登记/管理（CMDB-lite）+ 单二进制部署。这四个组合在一起的事，我没有见到第二个工具在同样的轻量级上做。

## v0.7.0 改了什么

需要说明一下，v0.7.0 是一次有 Breaking Change 的版本，我自己的环境也在这轮重装了。

### Go 版采集器退役，只剩 Rust 版

这一条影响最大。分布式采集器之前有两个实现：Go 版和 Rust 版，现在只保留 Rust 版。

退役的实测数据在 docs/zh/agent-rs.md，我把几个关键数字放这里：二进制小 4.2 倍，同一块 ARMv7 板上中位常驻内存从 54.1MB 降到 11.9MB（4.5 倍），/24 扫描快约 1.7 倍。分类器做了全语料差分测试，字节级一致。

为什么换：54MB 常驻内存在路由器上是要命的，很多路由器的可用内存就一百来兆。

好消息是 agent.yaml 配置不用改，键名兼容，直接跑。Go 版采集器本地那个 agent.db 不会带过来——它本来是个影子账本，中心的资产库才是正本，扫一次就回来了。

### 指纹语料开始可以在线更新

这一条是从 0.6 的「内置语料」走向「可运营」的关键一步。

现在可以在 Web 界面（设置 → 指纹）里：上传语料包、回滚到上一版、检查上游有没有更新并看新增/减少的规则差异、一键应用。每条路径都要过规则引擎自己的加载器校验——坏掉的语料会被引擎的错误拒绝，线上那份继续跑。应用后热重载，中心不用重启，语料版本号往前推，开了同步的采集器下次轮询就跟上。

对多站点部署来说，这条比听起来有用：我的机房里采集器分布在不同地方，语料更新以前得重新打包分发，现在中心改一次，各处自己跟上。

### 采集器扫的网络不再是拓扑盲区

之前有个别扭的限制：采集器扫回来的数据里其实有 LLDP/CDP 这类二层邻居信息，但上报格式没带这些字段，拓扑视图对采集器扫的网络是瞎的。v0.7 把邻居数组加进了上报格式，中心用和本地扫描同一条管道入库——采集器覆盖的远端网段现在也出现在拓扑里。对我这种中心在一个地方、采集器在另外几个地方的部署，这条等于把拓扑图补全了。

### 型号识别补完了最后一环

之前米家设备能认出品牌，认不出型号。v0.7 加了一条 hostname → model 的完整管线：从 viomi-waterheater-e13\_miap5E55 这种名字里把型号 token（e13）抠出来，一路写进资产库的 model 列和上报格式。实测用 10 个真实主机名验证过，米家设备的型号覆盖从 0% 变成扫一次全带上（只填空，不覆盖你手改过的值）。

### 惰性正则编译，采集器常驻内存减半

指纹规则里的正则原来在启动时全部编译进内存，是一笔固定开销。现在改成惰性编译——规则被实际用到才编译。实测数据：语料加载的堆占用从约 50MB 降到约 4MB，稳态 RSS 从约 110MB 降到 45–55MB。对路由器这种内存紧张的设备，这条比任何性能优化都实在。

### 两个识别准确性的修复

一是 TLS 证书的 CN、NetBIOS 主机名现在也能作为识别证据；二是随机 MAC 的处理逻辑改了。之前一个手机拿随机 MAC 抢了个空闲 IoT 设备的 DHCP 租约，会把真设备的行强行覆盖掉、把一批设备标成离线、还留下重复 MAC 的行——我在 lan-62 上真见过一个隐私 MAC 连续顶掉三台设备。现在这种情况只清空 IP 占用、不动身份和历史，真设备回来自己会重新认领。厂商真实 MAC 的行为不变。

另外还有多宿主 IP 稳定性、语料资产漂移守卫、CI 加了 cargo 测试门禁这些工程侧的东西。

## 现在还做不到什么

这一节比上面所有功能都重要，如果你正在考虑用它，先读这段。

-   v0.7 升级必须重建数据库。 schema 不再原地迁移，旧库启动时直接拒绝。这不是偷懒，是把并行 DDL 那一类 bug 彻底除掉（[#328](javascript:;)/[#431](javascript:;)/[#437](javascript:;)）。升级流程是：备份数据目录 → 用新目录启动 → 扫描自动回填资产。资产会回来，但本地扫描历史和本地 SNMPv3 凭据库不带回来。如果你不想折腾，继续用 v0.6.0，v0.6 还是可用的稳定版本。
    
-   v0.7.0 的 release 安装包我还没传。 今天刚打的 tag，写这篇时 Releases 页最新可下载的是 v0.6.0。不急着装的话，等包传上去再说。
    
-   Rust 版采集器的路由器 `.ipk`/`.apk` 包还没进 release，这是 tracked follow-up。tarball + procd init 路径是文档里写的安装方式（`agent-rs/deploy/openwrt/mibee-agent.init`），能用，但不是三种形态齐备。
    
-   指纹认不出的设备还是会有。 指纹库几千条覆盖了常见厂商，但真实网络里总有奇怪的东西。我的处理方式是把这类设备的识别数据做成贡献循环，但这依赖有人愿意提 PR，不是一句话能解决的。
    
-   告警和可视化它不做，是有意的。`/metrics` 和 `/sd` 端点把数据交给 Prometheus 生态，告警什么、怎么告警是 Alertmanager 的事，可视化是 Grafana 的事。要用这些就一起部署，它们原生消费它的输出。别指望在它的界面上做告警。
    
-   主机深度监控（CPU/内存/磁盘）也不做，node\_exporter / Netdata 是那边的事。它只做发现、识别、登记、心跳。
    
-   eBPF 被动观测是可选组件，默认构建不包含。想要得自己带构建标签编译。默认的容器镜像是 non-privileged 变体，LLDP/CDP 原始帧和 eBPF 都是 no-op stub，特权变体要本地构建。
    
-   它是单人项目。GitHub 上 485 次提交全部出自我一个人。功能边界很清楚，但响应速度取决于我一个人的时间和状态。有问题可以提 issue，不保证当天回。
    
-   路由器形态要求 arm64。32 位 ARM 路由器要在本地 `make build-linux-arm` 构建，不在 release 里。
    
-   指纹语料的准确率我没有大规模实测过。我自己的环境里识别得挺准，但「在我这儿准」和「在你的网络里准」是两件事。这条我得说清楚。
    

## 怎么跑起来

从 GitHub Releases 下载对应架构的二进制（amd64/arm64），加执行权限直接跑——它是 CGO-free 的纯 Go 二进制，目标机不需要 C 工具链：

```bash
chmod +x mibee-steward
./mibee-steward --config config.yaml  
```

最小配置里有三个必填：监听地址、要扫的网段（network.cidr）、两个认证项（auth.jwt\_secret 至少 32 字符；auth.initial\_admin\_password 不设的话服务直接退出）。

容器镜像在 ghcr.io/mi-bee-studio/mibeesteward（amd64 + arm64）。注意扫描依赖 NET\_RAW/NET\_ADMIN 能力，容器要用 host 网络模式——默认 bridge 在 NAT 后面，ICMP 和 ARP 探测全失效，不能用于真实盘点。

OpenWrt/iStoreOS 有 tarball / .ipk / .apk 三种形态（arm64）。

装完先跑一次 doctor 子命令，它会做一次体检（ICMP 权限、数据库状态、配置合理性），有问题它自己会说。

## 项目地址

仓库（AGPL-3.0）：https://github.com/Mi-Bee-Studio/MiBeeSteward

项目门户（部署文档、截图都在这）：https://www.mickeyzzc.tech/projects/mibeesteward

中文文档：https://github.com/Mi-Bee-Studio/MiBeeSteward/tree/main/docs/zh

产品边界文档（这篇「现在还做不到什么」的完整版，写得比我细）：https://github.com/Mi-Bee-Studio/MiBeeSteward/blob/main/docs/zh/product-scope.md

如果你也在维护一堆分散在几个地方的网络，这套东西可能对你有用。star 一下我这边能收到反馈，也是我继续写的动力——尤其是「哪些设备认不出来」这类信息，对指纹库的贡献最直接。

---

我在「蓝宝石的傻话」写一个人维护几张异地局域网的实战：自托管、网络、开源项目的开发和踩坑。下一篇写 Rust 采集器在 OpenWrt 路由器上的部署实测，感兴趣可以关注。

![](https://developer.qcloudimg.com/http-save/yehe-1102153/58e44939a41245dfd63953305ee4d293.png)

我在几个不同地点各有一张局域网，互相连不通，每一张都要自己维护。设备加起来 86 台（这是 MiBee Steward 扫出来的数字，文里的截图都是它自己的界面），其中 13 台当时处于离线状态。

86 台设备，我手写的清单里至少 6 条是错的

人工智能

MiBeeSteward v0.7.0发布：自动发现并识别86台网络设备，解决手动清单过期问题。基于指纹识别品牌型号，支持被动发现、拓扑视图、多站点采集。相比nmap、LibreNMS，它轻量集成发现+识别+登记，适合维护分散局域网的场景。

代码解释

数据库

TLS证书

路由器

路由

GitHub

容器

Linux

Agent

CIDR

ICMP

DHCP

eBPF

2026上云采购 | AI焕新·智启新局

tcmg

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

86 台设备，我手写的清单里至少 6 条是错的-腾讯云开发者社区-腾讯云

86 台设备，我手写的清单里至少 6 条是错的

86 台设备，我手写的清单里至少 6 条是错的

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐