从两个 API 到一个 Smart API Router：规则、神经门控与 Deep Analyze 共用一个端点

2026-10-17 更新：标注为历史文章并指向当前架构；删除了不再成立的套餐额度和数字。

历史文章。 本文描述的是 2026-09-12 时的 Router：神经模型、Deep Analyze 层以及当时的套餐额度。自 2026 年 10 月 12 日起，云端检测使用 Galvanize 2（阈值 0.662），Router 的层级为 rules、advanced 和 deep。当前套餐和额度请见定价。

直到本周，zn 还提供 两个 API。每次请求你都要选一个，套餐额度也分散在两者之间。这是每次集成都要付出的设计代价：选错会带来虚假的安全感，选对则要求你比本应需要的更深入地了解我们的内部实现。

现在只有一个端点。POST /analyze 让每个请求依次经过三层递进式判断 —— 确定性规则、神经门、Deep Analyze —— 并告诉你最终是哪一层做出的决定。

TL;DR

• POST /analyze 现在是一个 Smart API Router（SAR）：第 1 层确定性规则（<50 µs），第 2 层 int8 神经模型（~15–18 ms），第 3 层 Deep Analyze（mmBERT v8，热启动 ~166 ms）处理模糊区间。
• /v30/analyze 仍可作为 兼容别名。产品路径 POST /prod/analyze 保持纯规则，供需要超低延迟网关的调用方使用。
• Router 是 fail-open：如果 Deep Analyze 超时（6 s 预算）或出错，你仍会拿到 神经模型的判定。安全网关绝不能自己变成一次宕机。
• 套餐额度在本文之后已有变化，当前额度见定价页。
• 除非你主动开启 Contributor 模式，否则我们在任何套餐下都不保存你发送的文本。 我们保存证据元数据（包括输入的 SHA-256 指纹），保留 90 天。 响应包含 tier、decided_by、latency_ms 和可审计的 evidence_id。

为什么两个 API 是错的形态

第一个端点 POST /analyze 是确定性规则引擎：归一化加上注入模式库（pi-direct 之类）。它在微秒级返回，审计简单，规则命中时几乎不会错。但规则只能捕获你见过的攻击。

第二个端点 POST /v30/analyze 运行 神经门：一个多语言 Transformer，导出为 ONNX 并量化为 int8，对原始文本打分并在校准阈值之上阻断（多语言加固后 τ = 0.950）。这是另一种取舍：CPU 上 p50 约 15–18 ms，覆盖率高得多，但仍然远低于基于 LLM 的 guard 的成本与延迟。

两者都是诚实的产品。放在一起却是糟糕的接口。客户必须知道自己在哪个威胁模型里，才能为每次调用选择端点；额度被拆分；两条路径的证据也无法直接比较。实践中，人们会默认用快的那条，悄悄丢掉了自己付费购买的神经覆盖能力。

一个端点，三个大脑

Router 对每个请求做决定，且完全透明：

1. 第 1 层 —— 规则。 归一化，匹配确定性模式。命中即返回。成本：微秒级。
2. 第 2 层 —— 神经模型。 规则无法定论时，用 int8 模型打分。明显清白或明显攻击的请求在这里结束。
3. 第 3 层 —— Deep Analyze。 只有当 神经分数落在 不确定区间（0.50–0.935）时，请求才会进入 Deep Analyze —— mmBERT v8 正是为此而生：对小模型而言像是清白、但值得二次判断的文本。

判定融合刻意保持简单：Router 合并神经分数与 Deep Analyze 的分数，达到 0.935 即阻断。每个响应现在都带有 tier（rules、advanced、deep）、decided_by、latency_ms 和 evidence_id，方便你按决策路径统计自己的流量。

Deep Analyze：必须证明自己配得上这一层的模型

Deep Analyze 是我们多语言的 mmBERT v8 检测器，导出为 ONNX int8，运行在容器 Lambda 中（3 GB 内存、4 GB 临时存储、120 s 上限）。热启动约 166 ms 返回。冷启动需要约 24 s，因此它绝不会放在未受保护路径的同步入口上：只在模糊区间运行，受 Router 6 s 硬预算限制，超时则由 Router 回退到神经判定。

要让一个模型好到配得上这个位置，比 Router 本身花的时间更长。之前的文章完整讲过这个故事：悄悄欺骗我们的数据集 和 十七次失败的训练 —— 模型对所有输入都给出 0.498–0.509，因为损失函数从未看到标签。修复很普通：端到端监督训练、冻结划分、停止在测试集上调参。结果是一个在冻结测试划分上可以正常工作的拦截门。

在不破坏生产的前提下上线

在每个请求前面放一个 Router，是令人紧张的部署。我们分三步走：先是 影子模式，线上路径与 Router 同时决策，只做对比 —— Deep Analyze 在一旁打分，不触碰生产判定。然后是在别名后 50% 灰度，并接入 CloudWatch 告警（Lambda 错误、Deep fail-open、p99 延迟）到 SNS。最后 100%。

无聊的保证才是重点：回滚就是切换别名版本；Router 有 39/39 单元测试，包括一套等价性测试，证明被路由的路径与直接调用产生相同判定；fail-open 路径在测试中被真实执行，而不是寄希望于它。

订阅

本文发布时描述的套餐额度已经变化。当前套餐和配额请见定价。

留存策略不变：仅在 Contributor 模式下保存输入。我们保留判定、层级和 Evidence Vault 所需的哈希，保留 90 天。Contributor 模式为可选开启，是唯一会存储输入的情况，且经过匿名化，前提是你主动选择参与用于模型训练的社区遥测。如果你不开启 Contributor 模式，我们不会用你的提示词进行训练。（2026 年 10 月 15 日修改。）

对你意味着什么

如果你在调用 /v30/analyze，一切照旧：相同路径、相同响应结构，现在多了 tier 和 decided_by 告诉你每个判定的来源。如果你调用 /analyze 是为了纯规则，请迁移到 /prod/analyze 走确定性路径 —— 或者留下，用同样的价格获得完整的 Router。一个密钥，一个端点，三个大脑。

如果你想先在自己的流量上看到决策路径再决定是否信任它，Free 套餐（每月 10,000 次调用）正是为此准备的：一个 POST、一个 API 密钥，以及每次阻断的证据。

2026 年 10 月 14 日更新：数据处理的表述已修改，以描述软件包和 API 当前的实际行为。