「再加一层分类器吧，多一层总没坏处。」这话我今年听过好几回，每次都没当场反驳，因为直觉上它确实像没坏处。两周前 arXiv 挂出来一篇讲 AI agent 防护系统风险建模的论文（arXiv:2611.00386，10 月 30 日提交），把这个直觉用数字打了一顿：八个场景里，按「各层互相独立」这个假设选出来的防护配置，有六个没达到安全要求。不是差一点，是没达到。
这篇笔记不复述论文，我只讲三件自己能带走的东西：为什么「多一层」的边际收益经常是负的、那个两阈值路由规则长什么样、以及我准备怎么在自己手上那条防护链上验一遍。论文里那些序关系的证明我没跟完，后面单独说。
一层没认出来，下一层大概率也认不出来
同一个 prompt 注入样本，第一层分类器放过它，通常不是因为它「平均意义上像正常请求」，而是因为它长得跟正常请求很像——措辞正常、意图藏在上下文里、没有任何显式的越权动词。第二层如果也是同一类模型、用相近语料训出来的，它看到的是同一个东西，认不出来的概率不是独立的。两层的错误在统计上正相关，这时候你拿 p₁×p₂ 去算漏放率，算出来的数字会比真实值小一个量级。
这个道理说出来谁都懂。但配置的时候——包括我自己——手上那张表里填的基本都是独立假设下的数字，因为独立假设好算，一个乘法就完事，而估相关性要联合标注数据，没人愿意去标。
论文把这类系统拆成两条线：
顺序分层筛查（sequential layered screening）
request → 第一层 → 放行 → 第二层 → 放行 → 服务
↘ 拒 ↘ 拒
选择性验证（selective verification）
request → 第一阶段打分 → 路由决策 → 直接放 / 送审查器 / 直接拒
成本结构完全不一样。分层筛查是每一层都要跑一遍， Selective 那一类只在中间那一段才付昂贵审查器的钱。这点差别在后面会变成关键——因为它决定了你不是在「堆安全」，而是在「分配审查预算」。
真正能直接抄走的是那条路由
分层筛查那部分，作者在 lower-orthant ordering 下比较了错误概率和调用成本。这句话我第一次读的时候划过去了，后来回头才想明白它绕开了什么：它不要求你把联合分布估出来，只要求你能判定「依赖变强」这个方向，就能给出随机意义下的比较结论。方向对了结论就成立，具体数值不用知道。
选择性验证那部分更实用。当第一阶段和审查器都固定住，作者证明最优路由是按第一阶段输出的似然比设两个阈值——低于下阈值直接放，高于上阈值直接拒，只有夹在中间那一段才送审查器：
# 伪代码，两个阈值要在你自己的留出集上标定，不要照搬论文里的数字
s = log_likelihood_ratio(stage1_output) # 第一阶段的对数似然比
if s < tau_low: allow() # 低风险，别浪费审查成本
elif s > tau_high: deny() # 高风险，直接拦，也别浪费
else: review() # 只有这一段付审查器的钱
这个结构本身不新鲜，两阈值分流在风控里用了几十年。新鲜的是后面那句：τ 的取值依赖你对层间相关性的估计。独立性假设下算出来的阈值偏乐观——你会把 tau_high 设得过高、tau_low 设得过低，中间那段被压窄，看起来省了审查成本，实际上是把风险放出去了。所以这套东西真正难的地方不在路由公式，在于你愿不愿意承认自己的两层不是独立的。
论文没说的那部分
超模序（supermodular ordering）下关于「依赖增强时哪些策略的错误概率和审查成本单调变化」的刻画，我只读到了结论层，证明过程跳了。这里老实说：那一段的数学我没有完全啃透，只知道结论的方向是「依赖性越强，独立假设带来的偏差越大，而且偏差方向可判」。你要是拿这个框架做实际决策，这一段值得自己推一遍，我只是把路标记下来。
数值实验那部分被引用最多的数字是留出集总成本降了 39.6%。但我认为更该被记住的是那个 6/8——39.6% 是在满足安全要求前提下的成本优化，单独拎出来看没有意义；6/8 才扎人，它说明独立性假设下的方案不是「稍微差一点」，是在多数场景里直接不合格。我一开始以为这篇在论证「叠加防护反而更危险」，读下去发现不是。它没说叠加没用，它说的是你叠的时候如果按独立算，你以为的安全边际是假的。
实证只用四种 LLM 防护机制、场景也只有八个，样本不算大，这是它的弱点。但方向上我不觉得有什么可争的。
三个我踩过、也大概率还会踩的坑
第一个坑是把「相关性」当成一个要去估的相关系数。真去估你就卡死了，因为你手上没有联合标注。可以走的路线是判方向：拿历史日志找出两层同时误判的样本占比，跟「如果独立，同时误判该是多少」比一下，方向就出来了，不需要精确值。
# 不用建模，先算这个比值
# P(两层同时放过) / (P(第一层放过) * P(第二层放过))
# 明显大于 1，说明你的独立假设已经在骗你了
第二个坑是拿通用 benchmark 的通过率当自己场景的安全率。论文用的是基准衍生的 agent 动作，那套动作分布跟你线上真实流量差得远。数字可以借来看趋势，不能借来填验收表。
第三个坑是优化顺序反了。先压成本再校安全，最后一定会得到一份「成本很漂亮、六个场景不达标」的配置。约束得先立住，成本在约束里优化。
我打算怎么验
不用等把论文跑通。拿现在手上这条链，把最近一段时间的拦截日志抽出来，标两个字段：第一层是否放过、第二层是否放过。然后算上面那个比值。
如果比值接近 1，说明这条链的独立性假设勉强成立，之前那张表还能用；如果明显大于 1，那我之前所有基于「两层叠加等于双重保险」的判断都得推翻重算——包括我在评审里说过的那几句。
划重点：第一，防护组件的错误是相关的，独立假设算出来的漏放率只是算术游戏；第二，最优路由是似然比上的两个阈值，中间那段才付审查成本，两端都不该浪费；第三，判断相关性不需要估出具体数值，先算同时误判的实际比例和独立假设下的期望之比，方向就够用了；第四，优化的顺序是先立安全约束，再谈成本，反过来做出来的配置经不起验收。这篇就记到这里，你可以照着自己项目的日志先算一下那个比值，算出来要是有意思，欢迎回来留言，我一起补一条。