内在的路由器:从冻结 LLM 中引出原生技能路由

TL;DR Gavel 从冻结 LLM 的前向传播中直接读取技能路由信号，仅训练两个线性映射即可在无技能文本入上下文的情况下完成选择，性能超越携带 1.2B-16B 外部参数的检索重排管道。

问题

问题背景

LLM agent 的能力边界正从参数化知识扩展到外部技能调用（skills / tools）。路由决策——即从技能库中选出与当前任务最匹配的一项——直接决定 agent 能否真正从技能扩展中获益。

现有方法局限

当前部署的两类主流路由范式各有硬伤：

• 上下文预载元数据：把全部技能的 description / schema 塞进上下文，让模型在推理时一并选择。但上下文长度有限，技能库规模被硬性封顶；同时大量无关元数据会分散注意力，降低后续推理质量。
• 外部检索管线：用 embedding 相似度等外部方式召回候选技能，把选择步骤移出模型上下文。虽然缓解了上下文压力，但选择权也随之移出了 agent 自身的判断能力，模型无法根据当前对话状态或隐含意图做细粒度决策。

为什么这个问题难 / 重要

难点在于：既要保持路由精度，又要避免上下文膨胀和外部检索引入的偏差，同时不能引入大量额外参数或微调模型。业界对可扩展技能库、零样本迁移和低延迟路由的需求强烈，但现有方案往往在“模型原生的决策能力”与“系统可扩展性”之间二选一。

行业类比

类似代码助手在长会话中动态调用工具（如读写文件、执行测试）：如果每次把上百个工具描述塞进上下文，模型可能选错或遗忘关键信息；而纯向量检索又无法理解“需要临时切换工具”的语境。

核心洞察

• 路由信号无需显式文本表征，可直接从冻结 LLM 内部状态线性读出。已有方法要么把所有技能元数据塞进上下文（progressive disclosure），要么用外部检索模型（retrieve-and-rerank）；两者分别牺牲注意力或引入大量额外参数。Gavel 表明两个轻量线性映射即可从 task 和 skill 中层状态提取匹配分数，且只在安装时对每个技能构建一次 compact bank，训练参数极少，避免上下文膨胀和检索延迟。这改变了技能路由的范式：从“外置选择器”转向“内置信道”。
• 两阶段 glance-verdict 分离了粗筛与精判，并用 product of experts 融合两种原生信号。Glance 用 token-level 投影快速扫描全库；verdict 对短名单技能恢复完整前向，读取模型自身似然和 yes/no 判断。这种融合利用了模型不同的隐式知识表达，而非单一分数。与只使用嵌入相似度或重排序器相比，Gavel 在 zero-shot 转移和 mid-rollout 触发技能上显著超越，且能随 backbone 能力提升而改进路由精度。

方法

输入与安装

给定任务 query 与技能库，每项技能在安装时通过 frozen LLM 做一次前向，取其中间层 hidden states，并用 ε-cover 压缩为紧凑的 per-skill bank。

Glance：线性投影快速筛选

Gavel 只训练两个线性映射——一个投影任务状态，一个投影技能 bank 状态，映射到同一匹配空间。对全库技能计算匹配分数并选出短名单，无需将技能文本放入上下文。

Verdict：原生判断

对短名单技能，分别将技能描述与任务组合后继续前向，读取模型自身的 likelihood 与显式 yes/no 判断，作为第二路证据。

Ruling：专家乘积融合

Glance 分数与 Verdict 分数通过 product of experts 融合，输出最终路由概率。

与原作论断一致：frozen LLM 的前向过程已携带路由信号，两个线性映射即可读出，不依赖外部检索器。

与 retrieve-and-rerank 或 progressive disclosure 的差异：参数增量仅为两个线性映射，路由阶段不预载全库元数据，避免注意力分散和库大小受限。

实验

实验设计

• 在三个公共基准与 SkillTraj（372 条模拟 agent 轨迹）上评估。
• 对比基线：progressive disclosure 与 retrieve-and-rerank（外部参数 1.2B–16B）。
• 测试场景：书面任务路由、rollout 中途技能需求、端到端 bash-agent 部署、backbone 缩放。

关键发现

• 仅训练 两个线性映射 的 Gavel 在 Qwen3-32B 上书面任务提升 13.4 分，mid-rollout 提升 21.9 分。
• 路由准确率随 backbone 能力提高而上升。
• 在 bash-agent harness 中，32B 参数模型比更大的 frontier 模型（运行于 Codex）更频繁触发正确技能。

深度解读

• 实验证明冻结模型前向传播中隐含足够的技能选择信号，线性投影即可读出，避免将全部技能元数据载入上下文导致的注意力分散与库规模限制。
• 相比外部检索，Gavel 将选择留在模型能力内，同时仅增加极少量可训练参数（两个线性映射），在性能与效率上形成优势。

行业影响

落地场景

Gavel 适用于需要从海量技能/工具中快速选路的 LLM agent 产品，如企业级智能客服、代码助手（bash 技能库）、RPA 流程自动化、多租户 SaaS 的插件生态。它无需把技能元数据塞进上下文，可支撑上万级技能库而不稀释注意力。

商业价值

• 降本：路由只需两个线性映射和一次前向的中间层状态，避免加载外部检索模型或额外 LLM 调用，单次选择成本远低于 retrieve-and-rerank 管线。
• 增收/体验：选对技能提升任务完成率，减少失败重试；在 Qwen3-32B 上比 1.2B–16B 外部参数的管线高出 13.4–21.9 分，直接转化为用户留存和自动化 ROI。
• 规模化：技能库扩容不增加上下文 token 成本，边际成本近零。

与现有产品/工作流的接口

可作为本地 routing sidecar 嵌入 agent harness：

1. 从 frozen LLM 的中间层导出隐藏状态；
2. 加载训练好的两个线性映射（仅几 MB）做 glance 打分；
3. 短名单再走 verdict 的 forward pass，最后交给原函数调用/工具选择逻辑。
   局限：需要模型隐藏状态访问权，适合自托管或开放中间层的推理服务。API-only 场景可改为对端侧轻量 LLM 做同样读出。

具体案例：

• 电商智能导购：数千个品牌/品类技能，Gavel 在不膨胀上下文的前提下实时选出退货、比价、库存查询技能。
• 企业级 DevOps 助手：接管 bash 技能库，在 rollout 中途触发正确命令，降低对超大前端模型的依赖。

局限

• - **依赖内部隐藏状态，无法用于黑盒 API 模型**：Gavel 需要直接读取冻结 LLM 的中间层 hidden states，这要求模型权重和架构完全开放。对于通过 API 提供的闭源模型（如 GPT-4、Claude 等），无法获取内部前向传播信息，因此该方法不适用于当前大量以 API 形式部署的 agent 场景。即使使用开源模型，部署时也需要额外存储和计算来缓存中间层状态，增加了系统复杂度和推理延迟。
• - **技能库动态更新成本较高**：glance 阶段需要为每个技能构建 compact per-skill banks，安装时对每个技能执行一次前向传播。当技能库频繁增删或更新时，必须重新计算 banks，并且两个线性映射可能也需要在分布变化较大时重新训练，而论文只展示了 trained once + 零样本迁移，并未提供持续学习或增量更新的机制。对于长期运行、技能不断演化的 agent 系统，维护成本可能成为瓶颈。
• - **线性读出假设可能限制复杂路由表达力**：方法核心是假设路由信号以线性方式存在于隐藏状态中，仅用两个 linear maps 即可读出。对于需要多步推理、上下文依赖强或技能定义模糊的任务，线性投影可能无法捕获足够的判别信息。虽然 verdict 阶段借助模型自身 likelihood 和 yes/no 判断进行融合，但整体仍以线性 readout 为主，与基于全上下文 attention 的检索或预加载方法相比，可能牺牲了在极端复杂场景下的表达力。