大多数 Agent 路由器跳过的意图分类层

当你给 Agent 一份 50 个工具的列表，让 LLM 自行决定调用哪个时，准确率大约在 94% 左右。还算合理，可以上线。但当这份列表增长到 200 个工具——这比任何人预期的都要快——准确率就会跌至 64%。到 417 个工具时，命中率只剩 20%。到 741 个工具时，更是跌落至 13.6%，与随机猜测在统计上没有区别。

解决方案是一种大多数团队跳过的模式：在工具分发之前运行意图分类层。不是取代 LLM，而是在它之前。分类器缩小工具命名空间，让 LLM 只看到与用户实际意图相关的工具。LLM 的推理能力保持完整，只是在一个经过筛选的相关子集上工作，而不是在一个不断膨胀的大海捞针中。

本文解释为什么团队会跳过这一步、跳过后代价几何，以及如何正确构建这个层——包括让其随时间持续优化的反馈循环。

为何没人在"流血"之前添加这一层

工具分发阻力最小的路径是函数调用：给 LLM 所有工具 Schema，让它自己挑。OpenAI、Anthropic 和 Google 都原生支持这一方式，无需任何架构设计。在五到十个工具的原型阶段，效果很好，于是就上线了。

问题在于工具集会不断增长。一个最初只处理账单的 Agent，随后获得了日历排期功能，再是人力资源查询，再是技术支持工作流。当你有 50 个工具时，已经感受到摩擦；到 100 个时，问题已经很严重；到 200 个时，你已经处于危机模式。但此时架构决策早已固化。

反对先分类还有一个哲学层面的论点：LLM 函数调用很灵活。它能处理模糊查询、多步骤意图以及新颖组合，无需预定义分类体系。意图分类器要求你预先枚举类别，这感觉像是一种约束。这一论点在小规模下是成立的，但在大规模下站不住脚。

性能退化的结构性原因是研究人员所称的"上下文腐烂"（context rot）。Transformer 注意力机制与上下文长度呈二次方关系扩展。在 100K token 时，模型需要管理一百亿个两两关系。当 400 个工具 Schema 占据上下文中 80K token 时，列表中间的工具实际上变得不可见。对 18 个前沿模型的研究发现，每一个模型都会随输入长度增长而性能退化——位于上下文中点（50% 位置）的工具被准确选中的概率显著低于位于两端的工具，即便正确工具确实存在于上下文中。

"迷失在中间"效应不是模型的 bug，而是物理约束。你无法通过更精妙的提示词或升级模型版本来解决它。解决方法是：从一开始就不加载无关工具。

跳过分类的 Token 经济学代价

10 个工具、每个 500 token，每次请求加载 5,000 token 的开销，尚在可接受范围。

到 741 个工具时，在包含用户实际消息之前，每次请求的开销已达 127,315 token。有了将工具精确筛选到相关子集的分类层，这个数字降至 1,084 token——减少了 117 倍。按典型前沿模型定价，每月 100 万次请求，差价约为每年 379 万美元的 API 成本。

成本倍增器不只是 token 数量。Agent 会话会跨轮次累积上下文。你在第 1 轮包含的每一个 token，都会在随后的每一轮中被重新包含——在一个 30 轮对话中，等效于将其成本乘以 30。第 1 轮在无关工具 Schema 上浪费 1,000 token，整个会话就会多耗费 30,000 token。

错误的命名空间路由还会进一步放大这个问题。当一个账单查询被路由到充满日历和人力资源工具的上下文时，LLM 要么选错工具，要么返回"我无法帮助处理此事"——尽管它完全有能力——因为相关工具根本不可见。随后的重试循环又消耗额外的 token 和延迟。在 Agent 工作流中，单次错误路由可能级联扩展为五六次 API 往返才能恢复。

团队通常以惨痛方式发现这一点：一个用几个工具运转良好、花费 50 美元的概念验证，一旦用户量上来、工具集扩大，就变成每月 250 万美元的生产账单。经济学不是线性变化的，而是在越过某些工具数量阈值时出现悬崖式跳变。

三种分类方案及其适用场景

正确的分类方案取决于工具数量、流量规模以及意图分类体系的定义程度。

基于嵌入的路由是最快的选项。查询嵌入通过余弦相似度与每个意图类别的预编码示例话语进行比对。延迟在 16–100ms 之间。在有据可查的生产部署中，这种方案将端到端路由延迟从 5,000ms 降至 100ms，经迭代示例精化后达到 92–96% 的精确率。与基于 LLM 的分类每 10,000 次查询约 0.65 美元相比，其成本不到一分钱——大约便宜 65 倍。局限性在于：嵌入路由器对分布外查询和需要组合推理的意图处理能力较弱。当意图集固定且定义明确时，效果最佳。

微调小模型（SetFit、DistilBERT、ModernBERT）增加了训练开销，但在细微意图识别上精度更高。SetFit 的推理速度比前沿 LLM 快 56 倍，F1 分数与最佳 LLM 相差 8–10%，而成本只是其极小一部分。SetFit 模型可以在普通硬件上用 8 个标注样本在 30 秒内完成训练。IBM Research 为 vLLM 开发的语义路由器使用 ModernBERT 作为意图分类器，在 MMLU-Pro 上实现了 10.24 个百分点的准确率提升，同时延迟降低 47.1%。Google 研究团队的成果表明，两阶段方案——小模型汇总每次交互，再由微调小模型提取意图——可以匹配 Gemini Pro 的准确率，同时实现设备端的隐私保护分类。

基于 LLM 的分类是准确率最高但成本也最高的选项。使用主模型（或更便宜的小模型）作为专用分类器，会在工具分发前增加一次完整的模型调用。对于真正模糊、需要推理的意图，这是正确选择，但在规模化后，与基于嵌入的方案相比，延迟和成本都会翻倍。实际使用场景是作为分类级联底部的兜底层。

级联模式汇集了三者的优点：

1. 关键词过滤（亚毫秒级）——处理高频、无歧义意图
2. 嵌入路由器（16–100ms）——覆盖大多数查询
3. 微调分类器（50–200ms）——处理路由器范围内的模糊情况
4. LLM 兜底（1–5 秒）——处理级联无法自信分类的新颖或组合意图

升级级联层级的阈值是分类器置信度：预测置信度高于 0.8 则自动路由；0.5 到 0.8 之间则路由但标记待审；低于 0.5 则升级至下一层或人工介入。使用这种模式的混合实现，在分布内数据上可达到接近原生 LLM 准确率的 2% 以内，延迟减少约 50%。

实用经验法则：工具少于 15 个，LLM 函数调用完全够用；15–50 个工具，加一个嵌入路由器；超过 50 个工具，需要微调分类器；超过 100 个工具，分类层不可省略。

分类器究竟在把控什么

一个常见误解是分类器取代了 LLM 的推理能力。事实并非如此。分类器回答的是一个更窄的问题：哪个工具命名空间与此查询相关？LLM 随后仍然负责所有组合推理、参数提取和多步骤执行——只是在一个经过筛选的相关工具子集上进行。

分类器的输出大致如下：

{
  "intent": "billing_inquiry",
  "confidence": 0.92,
  "extracted_entities": [
    { "name": "time_period", "value": "last month" }
  ]
}

这个 intent 字段控制三件事：

• 工具命名空间过滤：只有账单工具被加载到 LLM 上下文中。即使 Agent 技术上可以访问日历和人力资源工具，它们也不会出现。
• 系统提示词选择：LLM 接收的是账单专家系统提示，而不是通用 Agent 提示。领域预热能提高领域特定推理的准确率。
• Agent 委派：在多 Agent 架构中，分类后的意图被路由到相应的专用子 Agent，每个子 Agent 都有自己的工具集、提示词和记忆范围。

这是 Microsoft Research 的 GeckOpt 模式，已在 Copilot 系统中 100 多个 GPT-4-Turbo 节点的真实生产部署中得到验证。离线阶段构建意图到工具子集的映射；在线阶段对每个请求进行分类并只加载相关子集。结果：token 减少 24.6%，准确率下降不足 1%。

分类器输出中的实体提取同样有价值。如果分类器能可靠地从账单查询中提取 time_period: "last month"，该结构化值可以直接传入工具调用，而无需再依赖 LLM 重新提取——进一步减少一个幻觉来源。

让分类成为护城河的反馈循环

一个基于枚举意图的规则分类器是静态产物。随着用户行为演进，它会产生偏移。那些构建持久分类基础设施的团队，从一开始就设计好了反馈循环。

飞轮运转方式如下：

1. 每次生产请求记录预测意图、置信度分数、实际调用的工具，以及这些工具调用是否成功或失败。
2. 失败的工具调用——调错 API、参数幻觉、空结果——作为候选误分类浮出水面。
3. 用户反馈（踩、纠正、重新表述的追问）提供额外信号，指出分类错误之处。
4. 低置信度预测（低于 0.7）进入人工审核队列。
5. 人工标注的纠正反流到微调分类器的训练集，或反流到基于 LLM 的分类器的少样本示例池。
6. 分类器在扩充后的数据集上重新训练——或者对于基于 LLM 的分类器，示例池通过语义检索在查询时动态更新。

复利效应显著。没有反馈循环时，多轮 Agent 在 20 轮对话后，因累积误分类导致上下文退化，错误率可能超过 80%。有了覆盖率达 80% 的用户纠正反馈循环，这一比率降至 40% 以下。

更重要的是，基于生产流量训练的微调分类器，会逐渐专精于你的用户真实词汇、你所在领域的边缘案例，以及你的工具集特有的失败模式。做零样本路由的 LLM 不会积累这种专业化能力。分类器每周都在变好；LLM 则停留在训练截止日期的状态。

实用起点：从第一天起就记录分类器置信度和工具调用结果。你不需要立即建立完整的标注流水线。即使只是来自工具调用成功率的被动信号，也能给你一个意图分类最薄弱环节的排名列表，精确告诉你应该在哪里投入人工审核。

系统层面的回报

意图分类是无聊的基础设施。它不会出现在 Demo 里，不会让你的 Agent 更聪明，但会让所有其他部分运转得更好。

当 LLM 只看到与当前查询相关的工具时，它犯的错误更少——不是因为它更强大，而是因为问题本身变简单了。正确的工具可见，干扰项消失，上下文短到让注意力机制能按设计工作。

在工具数量较少时，这无关紧要。但在生产规模——50 个以上的工具、每月数百万次请求、用户意图真实多样——这决定了一个系统是否有效，还是同时过慢、过贵、过于不可靠，令人无法信任。

分类层还在意图理解和工具执行之间创建了清晰的接口。这种分离有下游好处：你可以升级工具而无需重新训练路由器，可以替换 LLM 后端而无需改动分类，可以添加新的工具命名空间而不污染现有命名空间。

大多数团队在经历第一次生产危机后才添加这一层。那些提前添加的团队，从未遭遇那场危机。

---

关于这一点的数学已经有充分依据。没有分类时，417 个工具的工具选择准确率为 20%。有了分类门控，相关工具有 94% 以上的概率出现在前 3 个候选中。741 个工具场景下 token 开销减少 99%。混合分类器在延迟减半的同时，准确率与 LLM 相差不超过 2%。飞轮随时间复利改进。添加这一层的成本是几百行基础设施代码加一些标注示例。不添加它的代价，随你的流量线性增长。