用贝叶斯拓扑分析把家庭网络做成一套"智能网络路由系统"

对于网络路由系统稳定是第一要位，无论是家庭网络还是企业级网络稳定一直是关键。但实际路由设备只是在我的用户端，至于涉及到互联网部分的稳定性对于常规系统来说是“鞭长莫及”的区域。很多时候只能是忘网兴叹，因为我们无能为力。

那么有没有神恶魔方法可以解决吗？

我在建立完这套linux-router之后，突然想到之前做过的“贝叶斯拓扑分析”的模型。可以通过“贝叶斯拓扑分析”对网络系统的数据进行分析，可以做到预先知道问题发生，提前规避。这要比知道网络出问题了再去修改有了质的变化。

大概的思路有了，怎么执行？

我把这个问题丢给我的多模型协同系统，结果给了我一个我自己都没想到的方案：把所有网络信息建立成多个二维“点云”结构。在稳定情况下这个“点云”结构是稳定的，但当网络出现问题前“点云”中的某个点会出现漂移，这就是拓扑层可以直接给出的信息。这里包括：无线AP信号、链接数量、网络延迟、链接速度等等。

用拓扑数学给家里网络做"体检"

上篇写到让 AI 帮我搭了家里的 Linux 路由和代理。跑了一个多月，这套系统本身很稳——但我一直有个不太满意的地方：我知道代理节点什么时候挂了，但不知道它什么时候快挂了。

我用的代理方案是 6 台 VPS，每台跑好几种协议（vless、hysteria2、tuic，加上 IPv4/IPv6），展开成 26 个节点，daed 内核根据延迟自动选路。这套机制本身没问题——哪个节点延迟低就走哪个。但所有的监控都是"事后"的：节点挂了我知道，节点延迟飙升我知道。至于它在挂之前有没有什么征兆？传统方法是设阈值——"RTT 超过 300ms 告警"。但有的线路日常就是 200ms，有的 140ms 就开始丢包了。绝对值说明不了问题。

之前试着用过 LLM 做监测——效果不错但 API 费用不低，而且每次分析都是"一切正常"——花 token 买安心。我想要一个不需要 API、越用越聪明的方案。这让我想起了之前在论文项目里研究过的 BPL/OA（贝叶斯持久景观 / 占用-振幅分解）。

把 26 个节点变成星座

BPL/OA 的核心逻辑是：不看绝对值，看结构。

想象有 26 个点散落在平面的不同位置。每个点的坐标不是经度纬度，而是这个节点的"行为特征"——平均延迟多少、延迟稳不稳定、存活率、趋势是上升还是下降。正常情况下，来自同一台 VPS 的不同协议节点（比如 NOSLA 的 vless、tuic、hy2）在这些特征上高度相似，所以你会在图上看到几个紧密的小团——这就是节点们的"正常状态"。

拓扑数据分析做的事，就是把这种空间结构的稳定性持续追踪下来。具体做法是：取这个点云，算每对点之间的距离。从一个很小的半径开始画圆，逐渐放大——两个点的圆相交了，它们就"连通"了，像泡泡在长大然后合并。这个过程形成一棵树，树枝的长度描述了聚类有多紧密。然后做 140 次重采样——每次结构是不是一样？哪些连接每次都在，哪些是不稳定的？

最后，Repair Ladder 诊断会把整个景观分成三个区域：活跃区（结构稳定可靠）、过渡区（灰色地带）、非活跃区（没有可辨识结构）。正常时 96% 的区域是活跃的——这个数字本身不重要，重要的是哪天它变了。

这就是这套方案最让我喜欢的地方：不需要设什么阈值。节点延迟从 140 涨到 170 算不算异常？看绝对值没法说——但如果这个变化导致这个节点在点云里离开了它原本的团，那才是真正的异常。结构的变化比数值的变化更早、也更可靠。

不只是节点——五层拓扑

做着做着发现，能放进来的数据不止节点延迟。最终搭了五层点云，每层各自独立建拓扑，互不污染：

Layer 1：节点拓扑层（26 个节点）。数据源是 daed 内核自己的健康检查——编译了一个定制版把延迟数据暴露出来。全部是读缓存，不发一个网络包，不存在之前主动探测被"墙"发现的问题。

Layer 2：出口分布层（7 个出口）。看流量是怎么在各个出口之间分布的。如果某个出口的连接数开始往下掉——那说明 daed 自己已经开始"逃离"这个出口了，比延迟告警更早。

Layer 3：设备有线行为层（20 台设备）。MAC 级别的连接指纹。哪台设备突然连接数异常——可能是软件问题，也可能是被攻了。

Layer 4：无线射频层（12 个射频）。6 台 UniFi AP，每台 2 个 radio。直接读 AP 自己的信道利用率——cu_total 是信道总占用，cu_self_rx + cu_self_tx 是你自己占用的。差值就是邻居 WiFi 在干扰你。刚分析第一轮就发现：三楼的 2.4G 和院子的 2.4G 在同一个信道（ch=11），累计利用率冲到 52%，三楼射频的满意度直接到了 -1。把院子改到 ch=1、阁楼和二楼拆开之后，全部恢复正常。

Layer 5：无线客户端层（30 台设备）。每台 WiFi 设备是一个点——信号强度、重试率、速率、连在哪个 AP。同一台设备，有线层正常、无线层也在它的团里——说明一切正常。有线层正常、但无线层它漂走了——可能就是微波炉开了，或者被人带到了信号不好的角落。

数据怎么来的、存在哪、占多少

数据来源：

• daed 内核健康检查（GraphQL，只读缓存，零主动发包）
• UniFi Controller API（6 台 AP + 30 个客户端的实时射频数据）
• Prometheus（出口分布、设备连接数、系统级指标）
• AdGuard Home 双实例（DNS 查询行为）
• 内核 ss -tipn（TCP 连接粒度的 RTT/cwnd/重传）

这些数据在以前分散在各处——daed 的内存、UniFi 的 API、Prometheus 的时序库——现在全部汇总到路由器本地的一套 SQLite 数据库里。7 个 systemd timer，每 5 分钟跑一轮。每天总共产出约 9 MB，跑一个月才不到 300 MB。路由器的磁盘还剩 11 GB，够用三年。BPL/OA 分析每 30 分钟自动触发一次，做景观诊断，结果写回数据库——随着数据积累，景观的演变历史本身就是最有价值的趋势。

诚实地说

数据跑了才不到半天。景观目前是稳定的——96% 活跃区，覆盖率 99%，0 硬化，0 过渡区。节点都挺好，结构没变化。

这不是什么了不起的结论。但我之前用 LLM 做监测时，每次看到"一切正常"就心疼 token。现在同样的"一切正常"，不需要花一分钱，而且每次分析都在让模型更了解这 26 个节点的"正常"长什么样。

有个小细节值得说：在 4 次分析中，有一次 M0（基于正态假设的模型）突然掉到了 0.22，而 M5（无分布假设的 OA 模型）稳在 0.97。M0 崩了说明那一瞬间的网络延迟不是正态分布——在网络这种环境里本来就正常。而这个事件被记录下来了。如果未来 M0 频繁崩塌，或者 M5 也开始掉——那就是信号。

更有趣的是跨层关联。之前用过的 LLM 能告诉你"一切正常"，但拓扑分析能告诉你更多——"节点正常、出口分布正常、AP 射频也正常，但你在三楼那台手机的 WiFi 信号正在持续衰减"。这靠单一指标做不到，靠阈值做不到，甚至靠 LLM 也不容易做到——但靠五层点云的独立漂移检测可以。

写这篇文章的时候数据才跑了不到半天。现在跑了一个多月，有些新发现值得记录。

从"事后诊断"到"事前预警"——贝叶斯后验升级

最初用的诊断模型叫 M0，本质上是频率派的做法——对 bootstrap 样本算正态近似区间。听起来挺科学，实际跑起来问题很大：一个 VPS 节点的 679ms 瞬时延迟尖峰就能把整个区间打崩，M0 的覆盖率在 0.15 和 1.0 之间剧烈摆动，几乎没有参考价值。

问题的根因不是参数调得不好，而是模型族本身的表达能力不足。网络延迟分布有长尾，正态假设天生就会被打穿。

后来从 eVoiceClaw 论文项目的代码里找到了一个叫 bpl_v1_posterior_band 的实现——完整的贝叶斯后验推断，共轭高斯更新 + sup-norm simultaneous credible band。和频率派的做法有三层本质区别：

1. 联合覆盖率有严格概率保证。频率派的逐点 95% 区间在 100 个网格点上联合覆盖率只有 0.6%。sup-norm band 在数学上严格等于 95%，不随网格点数量衰减。这对检测景观翻转（一个全局性的拓扑事件）至关重要。

2. 先验平滑来自 Matérn 核。不是简单的高斯平滑，而是通过持久景观过滤参数轴上的 GP 先验来正则化——先验告诉你"相邻网格点的景观值应该多相似"，强度由数据的实际方差决定。

3. 退化检测。当点云太紧密、没有任何拓扑特征时（λ_max ≈ 0），各种方法都会出数值问题。新 M0 自动检测这种场景，返回一个退化的窄带而不是 NaN 或无穷大。

迁移到路由器上后来回测了 38 次历史景观诊断（约 19 小时的数据），结论很明确：

• M0 的覆盖率稳定在 0.77，不再剧烈摆动
• 但这个 0.77 是高斯后验的表达力天花板，不是数据正常——真实分布是双峰的，高斯只能拟合其中一个峰
• 为此做了 P2 敏感性扫描，确认了最佳先验方差 ≥ 0.5，长度尺度 0.25 × t_max

M0 不当裁判，当影子——双决策层交叉验证

意识到 M0 有表达力天花板后，做了一个角色调整：M0 不参与门控决策，只作为 M5 的影子监控器。M5（OA 占用-振幅模型）仍然是唯一的主决策模型。

M0 监控的是它和 M5 之间的 gap——两者的覆盖率差值。正常情况下 gap 稳定在约 0.22。M0 定义了三类信号：

• gap_oscillation：gap 在短时间内剧烈振荡 → M0 模型不稳定，数据可能处于相变边界
• gap_narrowing：gap 突然缩小，同时 M0 异常上升 → M0 过度自信（翻转前兆）
• gap_widening：gap 持续扩大，同时 M0 下降 → 统计边界态，点云结构在漂移

用 38 次历史数据回测，两条翻转事件中，第二条被 gap_oscillation 提前 30 分钟预警，零误报。第一条没检测到是因为那时候旧 M0 已经失控了。

这恰好验证了双决策层架构的核心价值：M5 在扛，M0 在看。M5 说信号没问题，M0 说你的置信度在下降——这种不一致本身就是最有价值的诊断信息。

其实

这篇文章和上篇"AI 网管"是同一件事的两个侧面。

"AI 网管"说的是——让一个大模型帮你搭系统、查配置、改 Bug。而 BPL/OA 这个方向，是不靠大模型，靠数学——拓扑、贝叶斯、持久同调——这些几十年前就有的数学工具，在自己的路由器上静悄悄地观察这个网络。

两者不是替代关系。大模型负责"理解和创造"，数学负责"持续和累积"。前者帮你把摊子搭起来，后者帮你看住它。

我现在觉得，网络运维最贵的从来不是解决问题，而是发现问题。等你发现的时候，问题已经运行了一段时间了。如果能在结构刚开始变化的时候就感知到——这大概就是我想做的东西。