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

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

For routing systems, stability is paramount — whether home or enterprise. But routing devices only sit at the user end; the internet portion's stability is beyond reach for conventional systems. Most of the time, we can only sigh at the network, powerless.

那么有没有什么方法可以解决吗？

So is there a solution?

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

After building this Linux router, I suddenly remembered the Bayesian topology analysis model I'd worked on before. By applying Bayesian topology analysis to network data, we can predict problems before they happen and avoid them — a qualitative leap beyond fixing issues after they occur.

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

With the rough idea in place, how to execute? I threw this at my multi-model orchestration system, and it produced a solution I hadn't considered: structure all network information as multiple 2D "point clouds." Under stable conditions these point clouds stay fixed. But before a problem appears, a point in the cloud drifts — that's the signal topology analysis can detect. Data includes: AP signals, connection counts, latency, link speed, etc.

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

Using topological mathematics to give the home network a "checkup."

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

In the last post, I wrote about having AI build my Linux router and proxy. After running for over a month, the system itself is solid — but one thing bothered me: I know when a proxy node is dead, but not when it's about to die.

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

My proxy setup: 6 VPS, each running multiple protocols (vless, hysteria2, tuic, across IPv4/IPv6), expanding to 26 nodes. The daed kernel auto-routes by latency. The mechanism works fine — lowest latency wins. But all monitoring is "after the fact": I know when a node dies, when latency spikes. Any warning signs before? Traditional approach: set thresholds — "alert if RTT exceeds 300ms." But some lines normally sit at 200ms; others start dropping packets at 140ms. Absolute values don't tell the full story.

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

I tried using LLMs for monitoring — good results but API costs added up, and every analysis just said "all normal" — buying peace of mind with tokens. I wanted something API-free that gets smarter with use. This reminded me of BPL/OA (Bayesian Persistent Landscape / Occupancy-Amplitude decomposition) from my earlier paper projects.

把 26 个节点变成星座

Turning 26 nodes into a constellation.

BPL/OA 的核心逻辑是：不看绝对值，看结构。想象有 26 个点散落在平面的不同位置。每个点的坐标不是经度纬度，而是这个节点的"行为特征"——平均延迟多少、延迟稳不稳定、存活率、趋势是上升还是下降。正常情况下，来自同一台 VPS 的不同协议节点在这些特征上高度相似，所以你会在图上看到几个紧密的小团——这就是节点们的"正常状态"。拓扑数据分析做的事，就是把这种空间结构的稳定性持续追踪下来。具体做法是：取这个点云，算每对点之间的距离。从一个很小的半径开始画圆，逐渐放大——两个点的圆相交了，它们就"连通"了，像泡泡在长大然后合并。这个过程形成一棵树，树枝的长度描述了聚类有多紧密。然后做 140 次重采样——每次结构是不是一样？哪些连接每次都在，哪些是不稳定的？

BPL/OA's core logic: don't look at absolute values — look at structure. Imagine 26 points scattered across a plane. Each point's coordinates aren't longitude/latitude but the node's "behavioral fingerprint" — average latency, latency stability, survival rate, trend direction. Normally, different protocol nodes from the same VPS are highly similar across these features, so you see tight clusters — the nodes' "normal state." Topological data analysis continuously tracks the stability of this spatial structure. The method: take the point cloud, compute pairwise distances. Draw circles starting from a tiny radius, gradually expanding — when two circles intersect, they "connect," like bubbles growing and merging. This process forms a tree; branch lengths describe clustering tightness. Then 140 bootstrap resamples — is the structure consistent each time? Which connections persist, which are unstable?

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

Finally, Repair Ladder diagnostics divides the entire landscape into three zones: active (stable, reliable structure), transitional (gray zone), inactive (no identifiable structure). Normally 96% is active — the number itself doesn't matter. What matters is the day it changes.

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

This is what I love most about this approach: no thresholds needed. Is 140 to 170ms latency abnormal? Absolute values can't tell you — but if this shift causes the node to leave its original cluster in the point cloud, that's a genuine anomaly. Structural change precedes and is more reliable than numerical change.

不只是节点——五层拓扑

Beyond nodes — five-layer topology.

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

As I worked, I realized more data could be included. I ended up with five independent point cloud layers, each building its own topology without cross-contamination:

Layer 1：节点拓扑层（26 个节点）。数据源是 daed 内核自己的健康检查——编译了一个定制版把延迟数据暴露出来。全部是读缓存，不发一个网络包。Layer 2：出口分布层（7 个出口）。看流量是怎么在各个出口之间分布的。如果某个出口的连接数开始往下掉——那说明 daed 自己已经开始"逃离"这个出口了，比延迟告警更早。Layer 3：设备有线行为层（20 台设备）。MAC 级别的连接指纹。Layer 4：无线射频层（12 个射频）。6 台 UniFi AP，每台 2 个 radio。直接读 AP 自己的信道利用率——刚分析第一轮就发现三楼和院子的 2.4G 在同一个信道冲突，调整后全部恢复正常。Layer 5：无线客户端层（30 台设备）。每台 WiFi 设备是一个点——信号强度、重试率、速率、连在哪个 AP。

Layer 1: Node topology (26 nodes). Data from daed kernel health checks — compiled a custom build exposing latency data. All read from cache, zero network packets sent. Layer 2: Exit distribution (7 exits). Traffic distribution across exits. If one exit's connection count drops — daed is already "fleeing" that exit, earlier signal than latency alerts. Layer 3: Device wired behavior (20 devices). MAC-level connection fingerprints. Layer 4: Wireless RF (12 radios). 6 UniFi APs, 2 radios each. Reading AP channel utilization directly — first analysis round discovered 3F and yard 2.4GHz were on the same channel (ch=11), cumulative utilization hitting 52%. After redistributing, everything normalized. Layer 5: Wireless clients (30 devices). Each WiFi device is a point — signal strength, retry rate, speed, which AP it's connected to.

数据来源：daed 内核 GraphQL（只读缓存，零主动发包）、UniFi Controller API（6 台 AP + 30 客户端的实时射频数据）、Prometheus（出口分布、设备连接数）、AdGuard Home 双实例（DNS 查询行为）、内核 ss -tipn（TCP 连接粒度的 RTT/cwnd/重传）。这些数据全部汇总到路由器本地 SQLite 数据库。7 个 systemd timer，每 5 分钟跑一轮。每天约 9 MB，一个月不到 300 MB。BPL/OA 分析每 30 分钟自动触发一次，做景观诊断，结果写回数据库。

Data sources: daed kernel GraphQL (read-only cache, zero active probing), UniFi Controller API (real-time RF for 6 APs + 30 clients), Prometheus (exit distribution, device connections), dual AdGuard Home instances (DNS query behavior), kernel ss -tipn (TCP connection-level RTT/cwnd/retransmissions). All aggregated into a local SQLite database on the router. Seven systemd timers, running every 5 minutes. About 9 MB/day, under 300 MB/month. BPL/OA analysis auto-triggers every 30 minutes for landscape diagnostics, writing results back to the database.

诚实地说

To be honest:

数据跑了才不到半天。景观目前是稳定的——96% 活跃区，覆盖率 99%，0 硬化，0 过渡区。节点都挺好，结构没变化。这不是什么了不起的结论。但我之前用 LLM 做监测时，每次看到"一切正常"就心疼 token。现在同样的"一切正常"，不需要花一分钱，而且每次分析都在让模型更了解这 26 个节点的"正常"长什么样。

The data had only run for less than half a day. The landscape is currently stable — 96% active zone, 99% coverage, 0 hardening, 0 transitional. Nodes are fine, structure unchanged. Not a groundbreaking conclusion. But when I used LLMs for monitoring, every "all normal" report hurt in tokens. Now the same "all normal" costs nothing, and every analysis run helps the model better understand what "normal" looks like for these 26 nodes.

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

A noteworthy detail: across 4 analyses, M0 (normal-assumption model) once suddenly dropped to 0.22, while M5 (distribution-free OA model) held steady at 0.97. M0 crashing means that instant's network latency wasn't normally distributed — which is perfectly normal in networking. This event was recorded. If M0 crashes frequently in the future, or M5 starts dropping — that's a signal.

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

From "post-hoc diagnosis" to "early warning" — Bayesian posterior upgrade.

最初用的诊断模型叫 M0，本质上是频率派的做法——对 bootstrap 样本算正态近似区间。听起来挺科学，实际跑起来问题很大：一个 VPS 节点的 679ms 瞬时延迟尖峰就能把整个区间打崩，M0 的覆盖率在 0.15 和 1.0 之间剧烈摆动，几乎没有参考价值。问题的根因不是参数调得不好，而是模型族本身的表达能力不足。网络延迟分布有长尾，正态假设天生就会被打穿。

The initial diagnostic model, M0, was essentially frequentist — computing normal approximation intervals on bootstrap samples. Sounds scientific, but in practice: one 679ms latency spike on a VPS node would shatter the entire interval. M0's coverage oscillated violently between 0.15 and 1.0 — nearly useless. The root cause wasn't poor parameter tuning but insufficient expressiveness of the model family itself. Network latency distributions have long tails; normal assumptions are inherently doomed.

后来从 eVoiceClaw 论文项目的代码里找到了一个叫 bpl_v1_posterior_band 的实现——完整的贝叶斯后验推断，共轭高斯更新 + sup-norm simultaneous credible band。和频率派的做法有三层本质区别：1. 联合覆盖率有严格概率保证。频率派的逐点 95% 区间在 100 个网格点上联合覆盖率只有 0.6%。sup-norm band 在数学上严格等于 95%，不随网格点数量衰减。2. 先验平滑来自 Matérn 核。通过持久景观过滤参数轴上的 GP 先验来正则化。3. 退化检测。当点云太紧密、没有任何拓扑特征时，新 M0 自动检测这种场景，返回一个退化的窄带而不是 NaN。

Later, I found a bpl_v1_posterior_band implementation from the eVoiceClaw paper project — full Bayesian posterior inference, conjugate Gaussian updates + sup-norm simultaneous credible band. Three fundamental differences from the frequentist approach: 1. Joint coverage has rigorous probabilistic guarantees. Frequentist pointwise 95% intervals on 100 grid points achieve only 0.6% joint coverage. The sup-norm band is mathematically exactly 95%, regardless of grid size. 2. Prior smoothing from Matérn kernel. Regularized through a GP prior on the persistence landscape filtration axis. 3. Degeneracy detection. When the point cloud is too tight with no topological features, the new M0 auto-detects this and returns a degenerate narrow band instead of NaN.

迁移到路由器上后来回测了 38 次历史景观诊断（约 19 小时的数据），结论很明确：M0 的覆盖率稳定在 0.77，不再剧烈摆动。但这个 0.77 是高斯后验的表达力天花板，不是数据正常——真实分布是双峰的，高斯只能拟合其中一个峰。

After migrating to the router and backtesting 38 historical landscape diagnostics (roughly 19 hours of data), conclusions were clear: M0's coverage stabilized at 0.77, no longer swinging wildly. But this 0.77 is the Gaussian posterior's expressiveness ceiling, not normal data — the true distribution is bimodal; Gaussian can only fit one peak.

M0 不当裁判，当影子——双决策层交叉验证。意识到 M0 有表达力天花板后，做了一个角色调整：M0 不参与门控决策，只作为 M5 的影子监控器。M5（OA 占用-振幅模型）仍然是唯一的主决策模型。M0 监控的是它和 M5 之间的 gap——两者的覆盖率差值。正常情况下 gap 稳定在约 0.22。M0 定义了三类信号：gap_oscillation（gap 短时间内剧烈振荡）、gap_narrowing（gap 突然缩小同时 M0 异常上升→翻转前兆）、gap_widening（gap 持续扩大同时 M0 下降→统计边界态）。用 38 次历史数据回测，两条翻转事件中，第二条被 gap_oscillation 提前 30 分钟预警，零误报。

M0 is not the judge, but the shadow — dual decision-layer cross-validation. Recognizing M0's expressiveness ceiling, I shifted its role: M0 no longer participates in gating decisions; it only serves as M5's shadow monitor. M5 (OA occupancy-amplitude model) remains the sole primary decision model. M0 monitors the gap between itself and M5 — their coverage difference. Normally the gap is stable at ~0.22. M0 defines three signal types: gap_oscillation (violent short-term gap swings), gap_narrowing (sudden narrowing with M0 anomalous rise → flip precursor), gap_widening (sustained widening with M0 decline → statistical boundary state). Backtesting against 38 historical datasets: of two flip events, the second was warned 30 minutes in advance by gap_oscillation, with zero false alarms.

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

This perfectly validates the dual-layer architecture's core value: M5 bears the load, M0 watches. M5 says everything's fine; M0 says your confidence is dropping — this very inconsistency is the most valuable diagnostic information.

其实，这篇文章和上篇"AI 网管"是同一件事的两个侧面。"AI 网管"说的是——让一个大模型帮你搭系统、查配置、改 Bug。而 BPL/OA 这个方向，是不靠大模型，靠数学——拓扑、贝叶斯、持久同调——这些几十年前就有的数学工具，在自己的路由器上静悄悄地观察这个网络。两者不是替代关系。大模型负责"理解和创造"，数学负责"持续和累积"。前者帮你把摊子搭起来，后者帮你看住它。

This article and the previous "AI network admin" are two sides of the same coin. "AI network admin" is about having a large model build systems, check configs, fix bugs. BPL/OA is about not relying on large models, but on mathematics — topology, Bayesian inference, persistent homology — mathematical tools decades old, quietly observing this network from inside the router. They're not substitutes. Large models handle "understanding and creating"; mathematics handles "continuity and accumulation." The former helps you set things up; the latter helps you keep watch over them.

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

I now believe the most expensive part of network operations is never solving problems — it's discovering them. By the time you notice, the problem has already been running for a while. If you can sense it the moment the structure begins to shift — that's probably what I've been trying to build.