当用户向一个大模型发送请求时，最终回答他的，未必是他最初选择的那个模型。

2026 年 6 月，Anthropic 在发布 Claude Fable 5 时，引入了一套特殊的安全机制：当系统检测到请求涉及高风险网络安全、生物学或模型能力提取等领域时，会限制用户继续访问旗舰模型，并将符合条件的请求切换到 Claude Opus 4.8 等能力相对较弱的模型。

https://platform.claude.com/cookbook/fable-5-fallback-billing-guide

例如，一个普通用户可以正常使用 Fable 5 编写代码、分析文档，但当请求涉及某些高风险网络攻击技术时，安全分类器就可能阻止 Fable 5 继续处理，再由 Opus 模型接管。

Anthropic 将这种机制称为 Fallback（模型回退）。用户能够看到模型切换提示，也能知道实际回答来自哪个模型。这不是一种秘密诱捕，而是通过动态调整模型能力，控制高风险请求能够访问的资源。

这一实践背后其实存在一个值得关注的变化：过去，大模型安全护栏主要决定一条请求应该被允许还是拒绝；现在，安全系统还可以决定这条请求应该由哪个模型处理。

三个月后，2026 年 9 月，一篇名为《HoneyRoute: Honeypot-Model Routing for Adversarial LLM Serving》的论文，将这种思路向前推进了一步。

https://arxiv.org/pdf/2609.08306

研究者提出：既然能够识别高风险请求并动态切换模型，为什么不直接为攻击者准备一个专门的“替身模型”？当系统发现疑似攻击时，不再简单拒绝或者降级服务，而是把请求转发到一个伪装成生产模型的蜜罐，在保护真实模型的同时，观察攻击者后续的行为。

这套方案被称为 HoneyRoute，即蜜罐模型路由。

它把传统网络安全中的蜜罐技术引入大模型推理服务，并进一步结合风险检测、资源隔离、攻击指纹提取和持续反馈训练。

将 Anthropic 的产品实践与 HoneyRoute 放在一起，可以看到一个更完整的技术方向：大模型安全路由正在从风险拦截，扩展到模型能力调度，并进一步探索主动防御。

从 Anthropic 开始：为什么安全护栏需要决定由哪个模型回答？

传统大模型内容安全架构通常是在模型前后部署风险检测模块。输入内容经过检测后，正常请求放行，违规请求拦截；模型生成回答后，还可以再进行一次输出检测。

这种设计已经非常普遍，但它存在一个局限：对于不同能力、不同风险水平的模型，系统通常采用类似的处置方式。

假设一家企业同时提供多个大模型，其中一个具备非常强大的网络安全分析能力，能够发现复杂漏洞、生成高质量代码；另一个模型能力相对有限，但足以完成日常编程和一般安全知识问答。

当用户提出一个可能具有双重用途的技术问题时，直接拒绝可能误伤正常的安全研究，但完全放行又可能让高风险请求获得过强的模型能力。

Anthropic 的 Fallback 提供了第三种选择：保留合理的服务能力，但限制特定请求访问更强大的模型。

根据 Anthropic 在 2026 年 6 月 9 日发布的官方技术指南，Claude Fable 5 的安全分类器会检查进攻性网络安全技术、生物与生命科学、前沿模型开发以及模型推理内容提取等请求。对于符合条件的请求，系统可以回退至 Opus 4.8。

后续的 Fable 5.1 也延续了这一机制，并针对不同风险类别配置不同的回退模型。例如，部分网络安全请求可以转至 Opus 4.8，部分生物及生命科学请求则回退至 Opus 5。

这里有个重要细节：模型降级并不意味着绕过安全策略。接管请求的 Opus 模型仍然拥有自己的安全防护，遇到不允许处理的请求同样可以拒绝。

从工程架构看，安全分类器实际上参与了推理服务调度。

正常请求使用用户指定的模型，部分敏感请求切换到其他模型，不符合安全政策的请求则直接终止。不同的风险类型可以对应不同的处理路径。

而且这不只是一种产品界面上的切换。Anthropic 已经在 API 层提供服务端 Fallback 和 SDK 客户端 Fallback 的实现方式，允许开发者在接口返回特定安全拒绝信息后，自动重新调用备用模型。

安全检测的结果，开始直接影响模型的选择与推理服务的执行路径。

不过，Anthropic 的主要目标仍然是限制高风险能力访问，并尽可能保留正常用户的服务体验。它不会刻意让用户误认为自己还在访问原来的模型，也没有公开证据表明其 Fallback 就是一套用于诱捕攻击者的蜜罐。

而 HoneyRoute 的出发点有所不同。

从能力降级到蜜罐诱捕：HoneyRoute 想解决什么问题？

在传统网络安全领域，蜜罐是一种已经使用多年的防御技术。

安全人员可以部署一台模拟真实业务系统的服务器，主动暴露一些看起来有价值的服务接口。当攻击者尝试入侵时，实际上进入的是一个受到严格控制的模拟环境。

这样既能避免真实业务受到影响，也能观察攻击者使用了什么工具、尝试了什么方法，以及如何一步步推进攻击。

HoneyRoute 将这一思想移植到了大模型 API 服务入口。

假设一家企业对外提供一个高能力大模型，攻击者可能使用大量提示词尝试套取 System Prompt、绕过安全限制，或者通过密集请求消耗推理资源。

传统做法是识别并拒绝这些请求。但拒绝也意味着交互很快结束，安全系统通常只能获取当前请求的内容，很难继续观察攻击者的下一步行为。

HoneyRoute 则尝试改变这种局面。

系统首先通过一个轻量级检测器判断请求风险。如果属于正常流量，就继续转发给真实生产模型；如果被判定为疑似攻击，则把请求转发给专门部署的蜜罐模型。

对于攻击者来说，访问的 API 地址可以保持不变，交互方式也尽可能保持一致，但实际提供服务的已经不是生产模型。

攻击者可能继续修改提示词、调整采样参数、尝试新的攻击策略，而这些交互都会被蜜罐记录下来。

因此，HoneyRoute 希望同时实现三个目标：一是让可疑请求尽量不消耗真实模型的计算资源；二是通过相似的模型行为维持交互，让攻击者继续暴露策略；三是将采集到的攻击信息反馈给安全检测器，改善后续防护。

相比 Anthropic 的 Fallback，两者都采用了风险驱动的模型路由，但目的和交互方式不同。

Anthropic 的做法是让高风险请求使用受到限制但仍然具有正常服务能力的模型，并明确告知用户。HoneyRoute 则将攻击流量转移到专门的欺骗环境，主要目标是保护生产资源、分析攻击行为。

因此，HoneyRoute 的创新并不是首次提出根据风险切换模型，而是尝试把模型路由本身变成一种主动防御手段。

HoneyRoute 的技术架构：检测器、双蜜罐与持续反馈

HoneyRoute 的整体架构并不复杂。它不要求修改生产模型内部结构，而是在 API 网关与真实推理服务之间增加一个路由层。

论文将系统拆分成三个核心模块。

1. 轻量级风险路由器：快速判断请求应该去哪里

如果每条请求都需要先调用一个大型 Guard LLM 才能决定是否进入蜜罐，网关本身就可能成为性能瓶颈。因此，HoneyRoute 选择了一个相对轻量的检测架构。

研究者使用约 0.8B 参数的 Embedding 模型，将用户请求编码为 1024 维语义向量。Embedding 主干被冻结，不随日常检测训练而改变。

在此基础上，针对不同攻击领域训练独立的 MLP 分类头，每个分类头只有约 7 万个参数，负责判断一种风险。

例如，系统可以分别判断提示注入、恶意代码、敏感信息窃取、危险操作或者推理资源滥用等风险。

当任意一个领域的风险分数达到相应阈值时，路由器就可以触发分流。

这种架构的优势在于可扩展性。当出现新的攻击类型时，不一定需要重新微调整个模型，而是可以尝试增加对应的风险分类头。

当然，这也有一个前提：原始 Embedding 必须已经能够表达新攻击类型的关键特征。如果一种新的攻击机制无法在既有语义空间中得到有效区分，仅增加分类头未必能够解决问题。

2. 双蜜罐设计：并不是所有攻击都需要大模型接待

HoneyRoute 提供了两种不同的蜜罐实现。

第一种是 代码式蜜罐（Code-Implemented Honeypot）。

这种蜜罐不需要独立运行生成式大模型，而是通过规则、回复模板和缓存内容模拟真实服务。它还可以根据需要加入诱饵信息，用于观察攻击者是否对这些信息产生进一步操作。

例如，攻击者不断发送长上下文请求，试图占满生产模型的推理资源。此时系统未必需要真正调用一个大模型回答每条请求，只需要让一个轻量级服务接管这些流量，就可能明显降低生产服务受到的影响。

第二种是 模型式蜜罐（Trained Honeypot Model）。

这种方案部署一个与生产模型具有相似行为的独立模型，尽可能保持回复质量、交互格式和对话体验的一致性。

论文实验使用 SingGuard-8B 作为生产模型，SingGuard-NSFA-9B 作为蜜罐副本，并使用相同的 Chat Template。

这类蜜罐更适合需要持续交互的攻击，例如多轮越狱、模型行为探测等。它可以记录完整交互历史，不需要每次都在回复中显式添加诱饵。

两种方案实际上体现了一个工程权衡：代码式蜜罐计算成本低，但容易暴露与真实模型之间的行为差异；模型式蜜罐更容易维持交互真实性，却仍然需要消耗推理资源。

HoneyRoute 可以根据攻击类型选择不同的蜜罐，而不是对所有风险流量采用同一种处置方式。

3. 攻击情报反馈：让蜜罐不只是接收流量

第三个模块是持续分析与反馈训练。

进入蜜罐的请求不会只作为普通日志保存。HoneyRoute 还会从交互中提取攻击策略、攻击目标以及请求行为特征。

例如，攻击者采用什么类型的提示词变形，试图获取什么信息，请求节奏是否发生变化，不同请求之间是否具有相似的语义表示。

这些信息被组织成攻击者指纹（Attacker Fingerprint），用于关联相似攻击活动，并成为检测器后续更新的参考材料。

这样，HoneyRoute 就形成了一个闭环：风险识别、模型分流、蜜罐交互、行为分析，再反馈到风险识别。

但需要注意，这种闭环并不等于系统已经具备自动发现所有未知攻击的能力。只有进入蜜罐的请求，才会自然成为蜜罐分析的数据来源。真正绕过检测器、直接进入生产模型的攻击，并不会自动出现在这条反馈链路中。

实验结果：蜜罐到底能发挥多大作用？

论文围绕风险检测、蜜罐拟真度、推理性能、反馈学习、攻击指纹和多轮攻击检测开展了七组实验。其中，有几组数据值得重点分析。

首先是检测性能。

在最初包含 103 条样本的留出测试集上，HoneyRoute 的 F1 达到 0.911，路由中位延迟为 38 毫秒。

论文同时测试了一种基于大型 Guard LLM 的两级级联检测方案，其 F1 为 0.948，中位延迟约 14.6 秒。

从这组数据看，HoneyRoute 以略低的检测 F1，换取了约 385 倍的延迟优势。对于必须处理高并发请求的 API 网关来说，这样的差异很有吸引力。

不过，这个数字也需要结合基线理解。

在后续扩大到 1,103 条样本的测试中，HoneyRoute 的 F1 为 0.893、中位延迟 48 毫秒；作为对照的 Llama Guard 4 12B 则取得了 0.944 的 F1、中位延迟 68 毫秒。

这说明 HoneyRoute 并不是检测准确率最高的方案，和更有代表性的公开护栏模型相比，其延迟优势也没有达到数百倍。

它更适合承担高召回、低延迟的第一层风险分流，而不是被简单理解成可以全面取代 Guard LLM。

第二组实验关注蜜罐拟真度。

研究者让正常请求分别进入生产模型和蜜罐，再由第三方模型判断两者回答是否在语义上等价。

模型式蜜罐取得了 92.9% 的语义一致率。

相比之下，当系统无条件向回复中添加诱饵信息时，一致率只有 7.6%。研究者改为只在出现特定风险信号时加入诱饵，并尽可能让其自然融入回复后，一致率上升到 88.9%。

这说明蜜罐不仅要考虑如何记录攻击者行为，还需要控制诱饵对正常回答的影响。

不过，92.9% 并不意味着蜜罐有 92.9% 的概率能够骗过攻击者。实验测量的是正常请求的语义一致性，而不是攻击者通过主动探测识别蜜罐的成功率。

另外，代码式蜜罐的拟真度实验使用了模型副本回复加诱饵的模拟方式，主要衡量诱饵策略造成的失真，并没有独立验证纯规则模板蜜罐的实际回复质量。

第三组实验则具有很强的工程意义。

研究者构建了一个包含 250 条请求的并发压力测试，其中 150 条属于资源消耗型攻击流量，另外 100 条为正常请求。

如果所有请求直接进入生产模型，生产模型消耗了 708,077 个 Token；采用 HoneyRoute 后，生产模型只消耗了 15,351 个 Token。

生产模型的 Token 消耗降低了 97.8%。

同时，正常请求的中位延迟从 21.4 秒增加到 22.7 秒。

这个结果说明，风险路由能够在特定攻击负载下有效隔离生产模型的计算资源，避免恶意流量直接占满正常用户需要的推理能力。

但这里降低的是生产模型的 Token 消耗，而不是整个系统的总成本。如果攻击被转发到另一个 9B 模型，蜜罐本身仍然需要消耗 GPU 算力；网关、检测器和日志分析同样会产生额外开销。

因此，97.8% 不能被直接理解成企业的推理成本节省比例。实际经济收益取决于攻击流量规模、蜜罐类型、请求长度以及系统资源调度方式。

比单次检测更值得关注的，是攻击行为的持续分析

除了资源隔离，HoneyRoute 还研究了一个比较有意思的问题：能不能通过多轮会话的风险变化，识别逐渐推进的攻击？

传统护栏往往独立分析每一条请求。

例如，某个用户连续发送五条消息，每条消息的风险分数都没有超过拦截阈值，系统就可能始终认为这段交互是安全的。

但如果将五条消息放在一起观察，情况可能完全不同。

攻击者可能先提出正常问题，再逐渐加入敏感内容，通过上下文累积将模型引导到原本不应该处理的任务。

HoneyRoute 为此加入了会话级风险跟踪机制，不只关注单条请求的风险分数，还分析风险水平随对话轮次的变化趋势。

研究者在一组多轮攻击实验中发现，攻击会话的风险分数通常逐渐上升，而正常会话的分数相对稳定。

在论文构建的样本中，攻击会话的平均风险斜率为 0.155，正常会话只有 0.012。

这里的斜率，可以简单理解为风险分数随着对话推进而上升的速度。

研究者据此设计了一套趋势检测规则，当风险分数持续上升且达到一定水平时，即使某些单轮内容并不特别危险，系统也可以提前触发进一步检查或分流。

在扩展后的留出测试集中，组合检测规则识别出了全部 35 个攻击会话，正常会话误报率为 8%。对于另外 43 条专门尝试规避检测的多轮脚本，检测成功率达到 97.7%。

当然，这些数字仍然来自有限规模、包含模型生成会话的测试集，不能直接代表真实开放环境中的多轮攻击检测水平。

但论文揭示的方向值得关注：会话的风险不仅取决于某一轮说了什么，还可能取决于整个对话的风险演化方式。

另一个值得关注的方向是攻击活动关联。

HoneyRoute 尝试结合语义向量、文本风格和风险分类概率，判断不同请求是否可能来自同一攻击活动。

在由 30 个攻击活动组成的封闭候选集中，系统能够以 56.7% 的 Top-1 准确率找到来源活动，Top-5 准确率达到 80.7%。

不过，当候选集合扩大、攻击表达越来越接近时，准确率也会下降。实验中的成对身份关联精确率只有 10.2%，说明它距离可靠的真实攻击者归因仍有明显差距。

因此，这项能力更适合辅助安全分析人员检索相似攻击、发现重复模式，而不适合单独作为封禁或身份认定依据。

从 HoneyRoute 回到产业：安全路由还需要跨过哪些门槛？

2026 年 10 月 12 日，Anthropic 又发布了一篇关于反蒸馏防御的研究报告，介绍其如何通过两级分类器、推理内容访问限制、持续红队测试及账号级管控，减少攻击者提取 Claude 内部推理内容的机会。

https://www.anthropic.com/research/distillation-defenses

Anthropic 报告称，在其监测范围内，新防御措施使蒸馏者能够获取的推理 Token 数量下降了约 90%—99%。

这里的指标与 HoneyRoute 的生产 Token 节省完全不同，不能直接比较。但两者都体现出一个现实：针对高能力模型的恶意使用，仅靠一次性内容分类和拒答，已经难以覆盖完整的安全需求。

模型服务提供方开始关注请求身份、历史行为、推理能力访问边界，以及多次尝试之间的关联关系。

不过，从 HoneyRoute 的研究原型走向企业级服务，还有几个问题需要解决。

首先是误判。

HoneyRoute 在扩展多语言测试中出现了 43 条中文正常技术问题的误报。这意味着它可能把真正从事安全研究、漏洞分析或者防御开发的用户识别为攻击者。

如果系统只是增加一道人工复核，误判可能主要影响服务效率；但如果直接将用户送入一个伪装成真实服务的蜜罐，问题就严重得多。用户可能在不知情的情况下获得与真实业务不一致的回答，进而影响正常工作。

因此，我认为企业级安全路由不应该把所有可疑请求都直接送入蜜罐。

对于风险不确定的请求，更合理的选择可能是调用更强的护栏、限制工具权限或者进入受控执行环境；只有明确符合诱捕策略的高风险探测流量，才进入蜜罐。

其次是未知攻击。

HoneyRoute 的持续反馈确实展现了一定效果。研究者利用新增样本训练了一个针对正常安全研究请求的修正分类头，将对应测试集上的误路由率从 30% 降至 3.3%。

但这一改善主要发生在误报侧。对于全新的攻击类型，如果检测器一开始就无法发现，它们仍然可能直接进入生产模型，而不是被蜜罐收集。

所以，蜜罐能够积累攻击情报，却不能独立保证未知攻击的全面发现。企业仍然需要外部红队评测、异常监控、流量抽样和持续的安全数据更新。

最后是成本和架构复杂度。

如果一家企业已经部署了内容安全护栏、API 网关和多个推理模型，那么新增安全路由并不一定意味着要重新建设一套完整平台。

更现实的方向，是在现有网关上扩展风险驱动的处置能力。

低风险请求正常进入生产模型；不确定风险请求进入二次审查或受限执行；明确违规请求拒绝或限流；符合诱捕条件的探测请求则进入独立蜜罐环境。

对于带有工具调用能力的 Agent，还需要进一步隔离数据库、文件系统、浏览器和外部服务访问权限。一个替身模型可以模拟语言回答，但不能因此获得真实业务系统的操作权限。

同时，系统需要处理多轮会话状态、模型切换前后的上下文一致性、蜜罐资源配额以及日志数据的合规管理。

这些因素往往比训练一个风险分类器更加复杂。

大模型安全路由的下一步：从内容过滤走向推理资源治理

如果将 Anthropic 的 Fallback 与 HoneyRoute 放到同一张技术地图中，可以把安全路由的能力归纳为三个层次。

第一层是风险拦截，核心问题是“这条请求是否应该被允许”。这是目前绝大多数内容安全护栏已经具备的能力。

第二层是能力调度，核心问题是“这条请求可以使用哪些模型能力”。Anthropic 的 Fallback 属于这类实践，它允许系统根据风险限制对特定高能力模型的访问，同时在一定程度上保留正常服务。

第三层是主动防御，核心问题进一步变成“面对疑似攻击，系统应该如何隔离风险，并从后续交互中获得安全情报”。HoneyRoute 对这一方向进行了比较系统的探索。

需要强调，这三个层次不是严格的技术发展时间线，也不意味着蜜罐一定比模型降级更先进。它们面向的安全目标不同，在实际系统中往往需要同时存在。

对于企业来说，最有价值的变化，是内容安全护栏开始与推理网关、模型调度和运行时安全控制结合。

过去，安全系统可能只是模型前面的一道检测接口；未来，它还可能决定请求进入哪个模型、能够获得多少推理资源、可以调用哪些工具，以及是否需要进入隔离环境。

从这个角度看，HoneyRoute 的意义并不只是提出了一种新的蜜罐实现，而是展示了安全能力如何进一步深入大模型推理服务层。

不过，论文目前仍是一项预印本研究。它在生产资源隔离、蜜罐拟真以及会话趋势检测方面提供了有价值的初步实验，但对于真实攻击者能否识破蜜罐、未知攻击如何被持续发现，以及整个系统的实际部署成本，还有不少问题需要验证。

因此，与其把 HoneyRoute 看成一套已经成熟的主动防御产品，不如将其视为一种值得探索的架构方向。

Anthropic 的实践说明，安全策略已经可以决定由哪个模型回答；HoneyRoute 则进一步提出，当系统识别到攻击行为时，也可以决定让攻击者进入怎样的交互环境。

当大模型逐渐成为企业软件和 Agent 系统的基础设施，安全防护的对象也将不再只是输入输出的文本内容，而是整个推理服务过程中的能力、资源与行为。

这或许才是大模型安全路由最值得关注的演进方向。

声明：本文来自模安局，稿件和图片版权均归原作者所有。所涉观点不代表东方安全立场，转载目的在于传递更多信息。如有侵权，请联系rhliu@skdlabs.com，我们将及时按原作者或权利人的意愿予以更正。