简而言之：优先考虑路由，而非模型选择。大多数 AI 工作都运行在廉价的本地模型上。
大多数构建智能体的团队都是先选模型，再定架构。这顺序是反的。模型选择应该是最后一步，而不是第一步。
真正重要的是路由器——一小段代码，用来决定每个请求由哪个层级的模型处理。只要路由器设计得当，70-80% 的流量就可以运行在每次调用零成本的本地模型上，或者运行在异步模型上，从而将 AI 支出降低 90% 以上。
Brian Armstrong 上周也提到了同样的观点，讲述了 Coinbase 如何在 token 用量增长的情况下将 AI 支出减半，大意如下：
如何在 token 用量指数级增长的同时保持 AI 支出不变：不是靠设置摩擦和支出警报，而是靠更好的默认设置、路由和缓存。工程师可以选择任何他们想要的模型，但默认设置至关重要。
路由问题分为三个层次，每一层都有不同的职责：
- 技能分类器将原始用户请求转化为具体操作。它回答“任务是什么”这个问题——比如起草回复、总结代码库、运行迁移。分类器本质上就是意图识别。
- 路由器决定由哪个层级来执行分类后的操作。它回答“由哪个模型运行”这个问题。路由器不读取提示词，它读取的是分类器的标签以及一些特征：复杂度、上下文大小、历史成功率。
- 模型选择器在满足置信度阈值的前提下，从某个层级中挑选最便宜的模型。
分类器和路由器不是一回事。分类器是语言问题，路由器是调度问题。将两者混为一谈，会把模型选择埋没在提示词里，从而丧失对同一操作进行不同模型 A/B 测试的能力。
本地计算几乎免费。异步批量推理的运行成本比实时推理低两个数量级。因此，真正的问题范围更窄：有多少工作比例需要实时响应？
令人惊讶的是，一旦系统能够对工作进行排队，需要实时响应的比例其实非常小。
排队机制正是这一切奏效的原因。起草回复、总结代码库、撰写尽职调查备忘录、运行夜间评估——这些都不需要在一秒内返回结果。
我们将该功能的首个版本集成到了智能体运行时中。路由器已能根据任务复杂度、上下文窗口大小及本地记忆检索对任务进行评分。现在，路由器之上新增了两套反馈机制，它们以不同的时间尺度运行：
- 同步故障模式信号。一个预测器会为每条传入的路由标注五个特征：缺失的仓库上下文、长依赖链、高风险迁移、涉及安全敏感的提示词，以及高后果写入操作。
- 夜间闭环反馈。一个批量评估器会在夜间对昨天的执行轨迹进行评分，并更新路由器的权重。该评估器在 Sail 上通过异步推理运行，使评估成本趋近于零。
同步预测器能在已知的困难任务失败前将其捕获。夜间循环则能发现预测器遗漏的新故障模式。
一旦技能蒸馏将操作集扁平化，对于大多数非编码工作，70-80% 的智能体流量可以在本地模型上运行。
其启示是：围绕路由来设计你的系统，而不是围绕模型。最后再选择你的模型。
异步推理上的完整 Sail 方案——实时推理与异步批量推理之间的成本差异。↩︎↩︎
Brian Armstrong 在 X 上表示——Coinbase 通过优化默认设置、路由和缓存，在 token 使用量增长的同时，将 AI 支出削减了近一半。↩︎
技能蒸馏：教会本地模型像 Claude 一样调用工具，以及 AI 的微型工厂。↩︎