从两个 API 到一个 Smart API Router：规则、v29 与 Deep Analyze 共用一个端点

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

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

TL;DR

• POST /analyze 现在是一个 Smart API Router（SAR）：第 1 层确定性规则（<50 µs），第 2 层 v29 int8 神经模型（~15–18 ms），第 3 层 Deep Analyze（mmBERT v8，热启动 ~166 ms）处理模糊区间。
• /v30/analyze 仍可作为 兼容别名。产品路径 POST /prod/analyze 保持纯规则，供需要超低延迟网关的调用方使用。
• Router 是 fail-open：如果 Deep Analyze 超时（6 s 预算）或出错，你仍会拿到 v29 的判定。安全网关绝不能成为故障源。
• 各订阅现在都有 明确的 DeepAnalyze 配额，从 48 小时试用的 25 次/月到 Growth 的 30,000 次/月。
• 付费套餐零数据留存。 响应包含 tier、decided_by、latency_ms 和可审计的 evidence_id。

为什么两个 API 是错的形态

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

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

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

一个端点，三个大脑

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

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

判定融合刻意保持简单：Router 合并 v29 与 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 回退到 v29。

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

在最难的那一段上，Deep Analyze 更进一步。在内部探针上，它把对抗输入与正常文本分开到 0.9999999998，而看似可疑但清白的文本停在 1.35e-7。这不是营销概率，而是我们自己的网关在做决定时看到的数字，每次阻断都带有 evidence_id 记录。

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

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

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

订阅：更大的额度，明确的 DeepAnalyze 配额

旧套餐只有一个调用池，Deep Analyze 更像实验。新规范让每个层级在同一个地方拥有 标准配额和 DeepAnalyze 配额，并抬高了上限：

留存策略不变：付费套餐不存储任何输入。我们保留判定、层级和 Evidence Vault 所需的哈希，保留 90 天。Contributor 层级 —— 永久免费 —— 是唯一存储输入的层级，且经过匿名化，前提是你主动选择参与用于模型训练的社区遥测。如果你使用任何付费套餐，你的提示词不会进入我们的训练集。永远不会。

对你意味着什么

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

如果你想先在自己的流量上看到决策路径再决定是否信任它，48 小时免费试用就是为此准备的：一个 POST、一个 API 密钥，以及每次阻断的证据。