Goodfire 为 Kimi K3 和 GLM 5.3 训练并部署生产级网络安全监控器

引言

网络安全是监控 AI 智能体最困难的场景之一，因为良性行为与恶意行为往往看起来相似：审计代码库漏洞与利用漏洞所涉及的任务之间存在大量重叠。要区分二者，意味着需要在整个轨迹中追踪意图，而轨迹可能长达数百万个 token。

尽管存在这一困难，网络安全监控仍然至关重要，近期涉及智能体编码模型的事件就证明了这一点。

显而易见的解决方案是让 LLM 评判器读取每一轮对话，但这样做太慢、太昂贵，无法与智能体实时并行运行。因此在实际中，监控是异步的：等到有害轨迹被标记出来时，智能体早已采取了行动。

为解决这一问题，我们为 Kimi K3 和 GLM 5.3 构建了基于探针的网络监控器，并将其部署在生产推理栈上。正如我们在上一篇文章中所述，探针读取模型的内部激活，充当廉价的第一道过滤器。它只将可疑的交互发送给 LLM 评判器。与对每一轮都运行评判器相比，这种级联方案：

更准确：它在帕累托意义上优于评判器，并在我们的工作点上达到与其相当的召回率（召回率 93%，假阳性率 5.5%）。
成本降低约 50 倍，每百万次交互不到 200 美元。
速度更快得多，保持基线推理 token 吞吐量，且不增加延迟。
将通用越狱降至 0%，这是在独立评估者的静态红队攻击测试集上取得的结果。

这些结果使得实时监控智能体 rollout 变得切实可行，意味着有风险的网络操作可以在任何工具被调用之前就被阻止。在本文中，我们分享构建这些监控器的细节，以及我们对监控栈所做的一些推理优化，正是这些优化实现了如此高效的性能。

开放模型并不附带完整的安全栈；我们认为，这样的监控设置对于任何在智能体场景中提供开放模型服务的人来说，都是一个实用的默认选择。如果你提供或基于开放模型进行构建，并希望部署这样的监控器，请联系我们。

我们的监控方案

数据

智能体会话可能跨越数十万到数百万个 token，有害行为可能在任何时刻出现。为了对这类生产数据进行建模，我们在网络和非网络（例如 SWE、工具使用等）环境中模拟具有各种有害和良性目标的用户。为此，我们使用 Prime Intellect 的 verifiers、Prime Sandboxes 和 Tunnels 收集了一部分数据，使我们能够在无网络访问的情况下，以安全的方式在 Kimi K3 推理上运行网络攻击性任务以及良性任务。

为了明确我们的监控器应标记哪些行为，我们使用了一套精确的策略来描述不受欢迎的网络活动，采用具体因素来区分善意任务（例如有边界的漏洞复现）与恶意任务（例如漏洞利用）。模拟用户可以在会话过程中的任何时刻引入或升级有害意图，包括在最初是良性请求之后。例如，大多数任务一开始只有最低限度的良性探索（例如搜索文件目录），只有在经过一系列操作之后，有害活动才开始发生。这样就从相同的基础任务中产生了多样化的交互。

架构：监控级联

理想情况下，我们可以通过让另一个能力相当的 LLM 评判器按照滥用政策对每一轮进行分类，来监控目标智能体。然而，随着 rollout 变长，使用另一个模型会导致极高的成本和计算开销：根据 OpenRouter 的费率，使用 Opus 5 监控 Kimi K3 rollout 中的一百万轮将花费约 20 万美元，而通过 Kimi K3 自身则约为 3 万美元。

为了解决这个问题，我们利用了这样一个事实：在长时间运行的智能体会话中，即使预期目标是恶意的，智能体的大部分活动也是良性的——因此许多智能体轮次甚至无需由评判器处理。挑战在于如何知道哪些轮次值得被评判器查看。为此，与我们自己过去的工作以及他人近期的工作一致关于基于探针的监控的相关思路，参见先前工作：Building Production-Ready Probes for Gemini；Detecting High-Stakes Interactions with Activation Probes；Constitutional Classifiers++。其中，轮级分类过程已在 Constitutional Classifiers++ 中尝试过，但仅针对聚焦于 CBRN 威胁的短 rollout 任务；Gemini 的工作仅关注输入监控，因此忽略了上述针对完整输入-输出监控的技术挑战；而高风险检测论文则聚焦于较小的模型。，我们使用探针来分摊使用 LLM 评判器作为监控器的成本。

具体而言，我们设计了一种新颖的探针架构，专门用于捕获以局部化（即局部化到轮次或 rollout 中的特定片段）和分布式（即在整个轮次中持续存在）两种方式表示的行为，同时运行效率高，如下文所述。

该探针在监控级联中充当第一道高效、始终开启的检测器：它有助于判断输入、工具调用或输出是否高风险，如果探针读数超过校准阈值，则将该 rollout 升级到 LLM 评判器进行进一步评估。经过校准后，我们发现我们的探针在一组留出的智能体和聊天交互上实现了 0% FNR 和 95% TNR，确保 LLM 评判器仅被调用来处理有害活动。这也使我们能够通过使用更快但能力可能较弱的评判器来降低成本。

Flowchart: an incoming request goes to Kimi K3, whose internal activations feed the probes inside the monitor cascade. Below threshold, the interaction continues; above threshold, it goes to the judge, which either refuses the request or continues the interaction. — 图 1：我们的监控流水线的高层概览。我们的探针在推理服务器生成 token 时从目标智能体（此处为 Kimi K3）接收内部激活。探针决策根据阈值被标记给 LLM 评判器，评判器可以拒绝请求或继续交互。

推理优化

对探针运行一次前向传播远比 LLM 评判器便宜。然而，要确保它在生产推理服务器内运行时不会增加延迟，需要仔细的工程工作。像 SGLang 和 vLLM 这样的现代推理服务器通过一起处理许多请求、重用先前的前缀计算以及使用推测解码一次生成多个候选 token 来实现高吞吐量。监控器必须在保持这些吞吐量收益的同时，使分数与正确的 token 和会话保持一致。

在我们之前关于可解释性基础设施的文章中，我们描述了如何收集激活值以供分析。Goodfire，“前沿规模的可解释性基础设施：从万亿参数模型中采集激活值。”对于本文所述的实时监控，我们扩展了 SGLang，使其能够在服务引擎内部直接计算探针分数。

我们在运行探针的同时做了多项优化以保持推理吞吐量，包括为探针逻辑实现自定义内核。我们还通过基数树、DSpark 推测器和预填充-解码分离来维护探针分数，以避免额外的重复计算。在服务多个 Kimi K3 模型副本时，每个 worker 都会运行探针并为其活跃请求维护历史记录。我们扩展了 SMG 路由器，使其在请求转换过程中保留我们的监控配置，并将其传递给选定的 worker。监控事件随响应流一同返回，使下游消费者无论请求由哪个副本处理都能处理这些事件。

Table of throughput change with monitoring relative to serving without probes, median of three repeats. Output monitor / input plus output monitor: short workload +1.0% / −1.1%, medium +0.2% / −1.1%, shared prefix −0.6% / −1.4%, long −0.3% / −1.1%. — 图 2：在四种不同的推理工作负载下，推理期间运行我们的探针与默认 SGLang 相比的吞吐量差异。我们看到吞吐量下降不到 2%，这在我们吞吐量测试的噪声范围内。我们分别测量了仅输出 token 以及输入和输出 token 上启用探针时的吞吐量。

总体而言，我们发现在推理期间运行探针在多种不同工作负载下都不会增加额外开销。在四种推理工作负载中，与默认 SGLang 服务相比，启用探针后吞吐量保持在基准测试的噪声阈值之内。

Bar chart of mean added latency per turn: LLM judge with reasoning 2,750 ms (bar truncated), LLM judge 160 ms, our cascade 42 ms, and our cascade without reasoning 2 ms. — 图 3：监控为每个智能体轮次增加的平均时间。通过仅将标记的交互发送给评判模型，我们的级联方案与评判每一轮相比将这一延迟降低了 50 倍，并且相对于默认 SGLang 服务仅增加极少的延迟。

我们还评估了监控级联所增加的延迟，并将其与审查每一轮的 LLM 评判模型进行比较。在不使用评判推理的情况下，我们的级联方案将每轮平均增加的延迟从 160 毫秒降至 2 毫秒；在使用推理的情况下，将延迟从 2,750 毫秒降至 42 毫秒。与评判每一轮相比，两种配置都将平均监控延迟降低了 50 倍以上。

结果

评估我们的监控器

我们在一个内部数据集上评估我们的网络滥用监控器，该数据集包含 2.4K 个聊天和智能体会话，共计超过 60K 轮，并以 Claude Opus 5 的标签作为参考。为了生成逼真的交互，我们以两种方式对用户进行建模。我们使用 PetriAnthropic，“Petri：一个加速 AI 安全研究的开源审计工具。”——一个开源自动化红队测试库——来模拟对话和工具响应，并使用我们自己的用户模拟来与在改编自 ExploitBench 等基准的真实环境中运行的智能体进行交互。这使我们能够从相同的网络任务中收集有害和无害的 rollout。我们还纳入了来自 WildChat 网络特定子集的真实聊天交互，以及来自现成 SWE、Coding 和 DevOps 任务的无害智能体 rollout。

我们报告了所设计部署方案中的召回率和监控成本。检测比较使用 5.5% 的良性会话中断预算。成本和延迟比较使用能够达到至少 90% 召回率、同时最多中断 10% 良性会话的最廉价配置。如果监控器至少标记一次良性会话以供审查，则该良性会话计为被中断。

Recall versus benign sessions interrupted (0–10%) for LLM judge with and without reasoning and our cascade with and without reasoning; our curves sit at or above the judges', and both cascades reach 93% recall at 5.5% interruption. — 图 4：我们的级联方案可检测出约 93% 的有害会话，同时最多中断 5.5% 的良性会话，无论是否使用 judge reasoning。上：召回率与良性会话中断率的关系，将我们的级联方案与逐轮审查的 judge 进行比较。下：按基准细分后的相应召回率和假阳性率。

Grouped bar charts by benchmark. Recall: Petri cyber misuse about 90%, Petri policy adversarial 95–96%, ExploitBench 92%, WildChat cyber subset 97% for all four monitors. False-positive rate: mostly 3–8%, ExploitBench 13–18%, and 0% on benign SWE and coding agents. — 图 4：我们的级联方案可检测出约 93% 的有害会话，同时最多中断 5.5% 的良性会话，无论是否使用 judge reasoning。上：召回率与良性会话中断率的关系，将我们的级联方案与逐轮审查的 judge 进行比较。下：按基准细分后的相应召回率和假阳性率。

总体而言，我们发现我们的监控级联是对单独 LLM judge 的帕累托改进，即我们的监控在任何中断量下都优于仅使用 judge。在 5.5% 的良性会话中断率下，我们发现我们的监控在有和没有 judge reasoning 的情况下，对有害会话均达到约 93% 的召回率，并且对 0% 的非网络流量进行标记，使我们的监控可用于生产流量。我们还给出了结果的基准级分解，发现我们的监控流水线在 agentic 和聊天数据上均准确。我们发现，标准线性探针的召回率比我们的最终方案低约 5%，而非线性探针在我们的分布外评估集上损失高达 30% 的召回率。同时，n-gram 基线需要标记几乎所有的轮次才能达到这一召回率。

Bar chart of judge cost per million turns: LLM judge with reasoning $5,420, LLM judge $3,166, our cascade $185, our cascade without reasoning $65. — 图 5：每百万次交互的 judge 成本（左）和用于监控的总计算占比（右），将我们的探针加 judge 级联与逐轮审查的 judge 进行比较。与通过 API 调用 judge 相比，我们的监控成本要低得多。在固定的推理计算预算内，我们的监控将用于监控的占比最多降低 50 倍。

Bar chart of share of compute spent on monitoring: LLM judge with reasoning 20.5%, LLM judge 12.0%, our cascade 0.70%, our cascade without reasoning 0.24%. — 图 5：每百万次交互的 judge 成本（左）和用于监控的总计算占比（右），将我们的探针加 judge 级联与逐轮审查的 judge 进行比较。与通过 API 调用 judge 相比，我们的监控成本要低得多。在固定的推理计算预算内，我们的监控将用于监控的占比最多降低 50 倍。

为了进一步具体说明上述成本优势，我们报告了我们为定义级联流水线而优化的 LLM judge 的成本，以及在 LLM judge 之前运行探针的总体成本。基于 OpenRouter 上为我们评估套件记录的推理成本，我们的监控级联在无 judge reasoning 时每百万 agent 轮次花费 65 美元，在有 reasoning 时花费 185 美元。相对于使用相应 LLM judge 审查每一轮，我们的监控在有 reasoning 时将 judge 成本降低约 29 倍，在无 reasoning 时降低 49 倍。

在实践中，人们不会通过第三方 API 提供监控，而是使用本地 judge 作为推理计算的一部分，同时监控目标模型的多个副本。我们的结果表明，在有限的计算量下，我们的监控允许我们将超过 99% 的计算用于服务目标模型（Kimi K3），而仅使用不到 1% 的计算运行监控，且不损失可监控性；同时，若单独运行 LLM judge，则需要分配高达 20% 的计算用于监控，才能监控目标模型产生的每一轮。

有趣的是，我们发现我们的流水线也可以仅通过离策略数据来构建监控器。具体而言，我们使用最初为 Kimi K3 开发的数据，为 GLM 5.3 设计了一个监控流水线，发现在 Kimi 的 rollout 上评估时，我们得到了一个能力大致相当的 GLM 监控器，而针对使用 GLM 设计的在策略评估数据集，监控器仅略差一些。图表见附录。

比较不同的监控系统

一个有用的监控器需要在阻止有害活动的同时，允许合法工作继续进行。我们运行了完整轮次的智能体和聊天会话，将带有和不带有我们监控器的 Kimi K3 和 GLM 5.3 与几个前沿模型系统进行了比较。

加入我们的监控器后，Kimi K3 的有害会话阻止率从大约 29% 提升到 96%，同时其无害会话中断率从约 5% 增加到 9%。对于 GLM 5.3，有害会话阻止率从大约 36% 上升到 91%，而无害会话中断率从约 10% 增加到 15%。两个受监控的模型都接近我们所评估的前沿系统中最高的有害会话阻止率，同时中断的无害会话要少得多。

Scatter plot of harmful versus harmless block/refusal rate. Arrows move Kimi K3 from about 29% to 96% harmful blocking and GLM 5.3 from about 36% to 91% when our monitor is added, both at low harmless block rates; frontier models with their monitors sit further right, at higher harmless block rates. — 图 6：有害和无害会话的阻止或拒绝率。箭头显示了向 Kimi K3 和 GLM 5.3 添加我们的监控器后的效果。越靠近左上角的点，阻止的有害活动越多，同时允许更多无害活动继续进行。

我们还与Jev进行了比较，这是一个可以作为廉价评判者的决策模型。在固定的 5.5% 良性会话中断率下，Jev 达到 86% 的召回率，而我们的非推理级联为 93%，推理级联为 93%。也就是说，单独运行时，Jev 的召回率更差。此外，我们的非推理级联每百万轮次使用约 65 美元的评判计算成本，每轮增加 2 毫秒延迟，而 Jev 为 600 美元和 200 毫秒。

Three bar charts comparing Jev with our cascades without and with reasoning: recall at 5.5% benign sessions interrupted (86%, 93%, 93%), judge cost per million exchanges ($600, $65, $185), and mean added latency per turn (200 ms, 2 ms, 42 ms). — 图 7：我们的级联比 Jev 捕获更多有害会话，同时评判成本更低、附加延迟更小。左：在 5.5% 良性会话中断预算下的召回率。中：每百万次交互的评判成本。右：每轮平均附加延迟。对于成本和延迟比较，我们选择每个级联中最便宜的配置，该配置在中断至多 10% 良性会话的同时达到至少 90% 的召回率。

最大的差异出现在长上下文或对抗性框架的上下文中：当有害提示嵌入在良性框架中时，Jev 仅捕获 12%，同时在其 32K token 窗口之外，还会越来越多地中断良性 bug 复现会话。我们的监控器在这些情况下表现更好，并且在大多数会话长度下保持接近零中断。

Left: share of benign-framed harmful prompts caught: Jev 12%, our cascade without reasoning 52%, with reasoning 100%. Right: benign bug-reproduction sessions interrupted versus median session length from 30K to 150K tokens; Jev rises from 0% to about 22% past its 32K-token window, while ours stays at 0% (the no-reasoning variant reaches about 5% at the longest length). — 图 8：检测嵌入在良性框架中的有害提示（左）以及随着会话长度增加而被中断的良性 bug 复现会话（右）。虚线标记了 Jev 的 32k token 上下文窗口。Jev 对对抗性提示的鲁棒性较差，并且随着上下文增加表现更差。

外部红队测试结果

为了在内部评估之外测试监控器，我们请FAR.AI对部署的系统进行红队测试。他们的评估对带有和不带有我们监控器的 Kimi K3 应用了一组固定的越狱策略，评估了可在许多交互中迁移的通用攻击以及在单个提示上成功的非通用攻击。用 FAR.AI 的话来说：

“FAR.AI 在两天时间内对 Goodfire 的 Kimi K3 监控器进行了初步测试，在聊天场景中应用了一组非自适应的静态越狱攻击组合，用于进攻性网络滥用。从最初 1500 个候选越狱中，测试选出了 140 个在我们没有监控器的情况下对基础模型另一版本有效的越狱。将这 140 个越狱分别在对应不同攻击者目标的 8 个单独交互上进行测试后，Goodfire 的监控器将引发的漏洞从 66 个通用越狱和 700 个总越狱交互减少到 0 个通用越狱和 18 个越狱交互。”

也就是说，在没有我们的监控器时，通用越狱攻击成功率在不同推理努力设置下为 12% 到 53%。启用监控器后，140 个策略中没有一个成功产生通用越狱。监控器还将 1,120 个非通用交互上的单个提示成功率从至少 9–40% 降低到 0.1–1.6%，具体取决于推理努力。因此，虽然确实存在一些成功的越狱交互，但监控器在很大程度上能够抵御这一广泛、静态的攻击组合。

我们计划继续与 FAR.AI 合作，对我们的监控器进行进一步测试和强化。

Two bar charts of attack success rate by reasoning effort (None, Low, High, Max), without and with our monitor. (a) Universal jailbreaks over 140 strategies: 53%, 39%, 47%, and 12% without the monitor, 0% in every setting with it. (b) Non-universal jailbreaks over 1,120 interactions: at least 40%, 29%, 35%, and 9% without the monitor, versus 0.5%, 0.2%, 1.6%, and 0.1% with it. — 图 9：FAR.AI 在不同推理努力设置下进行的独立红队测试。(a) 我们的监控器在 140 个测试策略上将通用越狱成功率降至零。(b) 在 1,120 个非通用交互中，攻击成功率降至 0.1–1.6%。柱状图比较了启用和未启用监控时的攻击成功率；受监控的攻击只有在交互有害且监控器未标记它时才算成功。

结论

我们为 Kimi K3 和 GLM 5.3 设计的探针加评判器级联监控器，在我们测试的每一种中断预算下，都优于每一轮都运行 LLM 评判器。它的成本约低 50 倍，对推理吞吐量没有可测量的影响，并且在 FAR.AI 的红队测试中，它将通用越狱降至零。

由于它如此便宜，因此可以同步运行：风险操作会在智能体调用工具之前被捕获，而不是事后才被发现。该方案还仅使用在 Kimi K3 上收集的数据就迁移到了 GLM 5.3，因此你不需要为每个模型都建立新的数据管道。

开放模型并不附带完整的安全栈。我们认为，对于任何在智能体环境中提供这些模型的人来说，这样的监控设置是一个实用的默认选择。如果你提供或基于开放模型进行构建，并希望部署这样的监控器，请联系我们。