构建AI智能体应优先设计路由

大多数构建智能体的团队都是先选模型，再考虑架构。这是本末倒置。模型选择是最后一步决定，而不是第一步。

真正重要的是路由器，一小段代码，它决定每个请求由哪一层级的模型来处理。把路由器做对，70-80% 的流量就能跑在本地模型上——每次调用零成本——或者跑在异步模型¹上，从而将 AI 支出降低 90% 以上。

Brian Armstrong 上周也提出了同样的观点，谈到 Coinbase 如何在 token 用量增长的同时将 AI 支出减半²，他转述道：

如何在 token 用量指数级增长的同时保持 AI 支出持平：不是靠摩擦和支出告警，而是靠更好的默认设置、路由和缓存。工程师可以随意选择任何模型，但默认设置至关重要。

路由问题分为三层，每一层各司其职：

• 技能分类器将原始用户请求转化为具体操作。它回答的是任务是什么。起草回复、总结代码仓库、执行迁移。分类器就是意图识别。
• 路由器决定由哪一层级来执行已分类的操作。它回答的是哪个模型来运行它。路由器不读取提示词。它读取的是分类器的标签，外加几个特征：复杂度、上下文大小、历史成功率。
• 模型选择器会在满足置信度阈值的层级内挑选最便宜的模型。

分类器和路由器不是一回事。分类器是一个语言问题；路由器是一个调度问题。把两者混为一谈，会把模型选择埋进提示词里，并扼杀针对同一操作对不同模型进行 A/B 测试的能力。

本地算力几乎免费。异步批量推理的运行成本比实时推理低两个数量级¹。所以真正的问题更窄：有多大比例的工作需要实时回答？

一旦系统能够将工作排队，需要实时回答的比例会少得惊人。

排队正是这套机制奏效的原因。一份回复草稿、一份仓库摘要、一份尽职调查备忘录、一次夜间评估器运行：这些都不需要在一秒内返回。

我们把这一机制的第一版内置到了我们的智能体运行时中。路由器此前已经根据复杂度、上下文大小和本地记忆检索对任务进行评分。现在有两个反馈机制叠加在路由器之上，它们在不同的时间尺度上运作：

• 同步故障模式信号。一个预测器会为每条传入路由标注五个特征：缺失的仓库上下文、长依赖链、高风险迁移、安全敏感的提示词，以及高后果写入。
• 夜间闭环反馈。一个批量评估器在夜间对昨天的 trace 进行评分，并更新路由器的权重，运行在 Sail 上的异步推理之上，使评估成本接近于零。

同步预测器在已知的困难任务失败之前就将其捕获。夜间循环则发现预测器遗漏的新失败模式。

一旦技能蒸馏将操作集扁平化，70-80% 的智能体流量就可以在本地模型上运行³，适用于大多数非编码工作。

其含义是：围绕路由来设计你的系统，而不是围绕模型。最后再挑选你的模型。

1. 全面采用 Sail 进行异步推理——实时推理与异步批量推理之间的成本差异。↩︎ ↩︎

2. Brian Armstrong 在 X 上——Coinbase 通过更好的默认设置、路由和缓存，在 token 使用量增长的同时将 AI 支出削减了近一半。↩︎

3. 技能蒸馏、教本地模型像 Claude 一样调用工具，以及 AI 的迷你工厂。↩︎