Cursor Router：从真实流量学习「该用哪个模型」
--- Cursor 发布了一篇工程博客，公开了他们的模型路由系统怎么工作。核心主张：**模型选择应该从真实开发工作里学出来，不该靠 benchmark 分数推断。** 上线效果：Auto Intelligence 模式在比 Fable 低 68% 成本下达到更高满意度；Auto Balance 模式以低 41% 成本超过 Opus 4.8。 --- ## 一、两段式路由 每个决策用当前 turn 和近期会话状态做信号——任务类别、最近的工具调用、工作上下文。然后分两步： ```txt Compass 复杂度预测器 ├─ turn 足够简单？ → 发给价格高效模型（Grok） └─ 不够简单 → 分类学路由器 → 按任务标签选最强的前沿模型 ``` **Compass 判断「要不要升级」，分类学路由器判断「升级到谁」。** --- ## 二、Compass：用满意度预测复杂度 Compass 的训练信号很巧妙：**预测用户是否会对 Cursor 的回复满意**，把这个预测当作复杂度代理。 逻辑是：简单任务（比如提交代码）用户很少事后纠正；复杂任务用户大概率会追加要求。实测验证： - Compass 评分最高的 turn：96% 收到正向信号 - 评分最低的 turn：71% 收到正向信号 每个 turn 得到 0-1 的连续复杂度分，设一个阈值决定走哪条路。**阈值越低越省钱，越高越保质量**——这个阈值就是成本和质量的旋钮。 --- ## 三、训练数据：用户行为就是标签 数据集来自**数十万个真实 Cursor turn**，性能信号从用户行为推断： - **继续下一个任务** = 强正向信号 - **纠正 Agent** = 强负向信号 成本按 API 定价 + token 用量算。因为数据来自真实流量，它还捕捉了 benchmark 会漏掉的东西——比如**切换模型导致的缓存失效**。这是路由系统的隐藏成本：每次换模型，前缀缓存清零。 --- ## 四、任务分类学：没有模型全能 路由器把每个 turn 沿三个维度分类：**领域**（后端/数据库/frontend）、**任务**（修 bug/跑命令/写测试）、**修饰符**（有界编辑/产品问题/视觉密集）。 然后比较各模型在不同类别的表现。结论：**没有模型在所有工作类型上占优**： | 模型 | 强项 | |------|------| | Grok | 广泛常规工作、Git 命令、数据库操作 | | Sol | 规划、代码库理解 | | Opus | 执行密集、devops、数据库查询、性能优化 | | Fable | 调试、视觉实现 | 路由器按这些差异把每个 turn 配给最合适的模型。 --- ## 五、两条路由规则 分类学路由器的模型选择有两条硬规则： 1. **只在优势明确时才路由**：候选模型的观测表现必须比价格高效模型**高出 75% uplift 阈值**——大约意味着要有 75% 置信度认为提升是真实的 2. **预算内选最优组合**：从合格候选里选流量加权组合，预期性能增益最大，同时平均每 turn 成本在模式预算内 Compass 阈值 + 任务路由器的成本预算，共同定义每个模式在「成本-性能曲线」上的位置。Auto Balance 守住便宜路径、给路由器的预算小；Auto Intelligence 给更多空间选前沿模型。 --- ## 六、评估：离线筛候选，线上定真章 评估分两段： 1. **交叉验证**调阈值和预算，避免过拟合 2. **留出测试集**评估选出的策略 但博客明确说：离线分析无法完全捕捉生产行为，benchmark 同理——**真实开发流量才是最有代表性的测试**。离线评估只是筛出候选策略，最终要上线测。 --- ## 结语 模型路由正在成为 AI 产品的基础设施层。Cursor 的实践给出了一个可复制的模板：**用满意度信号训练复杂度预测器，用真实流量学习模型强项，用 75% 置信阈值和成本预算做决策约束。** 「换模型有隐藏成本（缓存失效）」这个细节尤其值得记住——路由系统的账，比 benchmark 表复杂得多。
