Cursor Router 解读：AI 编程开始进入自动选模型时代

导语

使用 AI 编程工具时，选模型正在变成一件越来越麻烦的事。

简单改个文案，要不要用最强模型？排查一个跨多个模块的偶发 Bug，便宜模型能不能扛住？今天刚找到一个顺手的“主力模型”，下周又有新模型发布，选择表很快就过期。

很多人的做法，是挑一个最信任的模型长期使用。Cursor 公布的数据也显示，大约 60% 的开发者会把单个模型当作日常主力。这样最省心，但代价很直接：整理类型、补测试、改 UI 和复杂重构，都按同一种能力和价格处理。

2026 年 7 月 22 日，Cursor 发布了 Cursor Router。它会在模型运行前分析每次请求，再从模型池中选择更适合当前任务的模型。简单工作交给更便宜的模型，UI 更新交给更擅长界面任务的模型，复杂、长链路的问题交给前沿推理模型。

Cursor 给出的结果很亮眼：在覆盖数百万请求的在线 A/B 测试中，Router 以大约低 60% 的成本达到前沿质量；早期企业客户的 Auto 请求成本，相比全部按 Opus 4.8 处理的估算，降低了 30%～50%。

不过，这次发布更值得关注的并不是“省 60%”。

Cursor Router 真正改变的，是模型选择的责任：过去由开发者在任务开始前押注一个模型，现在由系统在每次请求到来时动态决策。

这会影响 AI 编程产品的成本、评测、团队治理，也会改变模型厂商与应用层产品之间的关系。

一、它不是模型混合，而是请求级调度

“模型路由”容易和 MoE（Mixture of Experts，混合专家模型）混在一起。两者都叫路由，但发生的位置不同。

MoE 在一个模型内部，把 Token 分配给不同的专家网络；Cursor Router 位于模型外部，面对的是多个独立模型。它先读取用户请求和会话上下文，再决定这一次调用应该发给谁。

Cursor 官方披露的判断维度包括：

当前请求写了什么；
会话里已经有哪些上下文；
任务复杂度有多高；
任务属于哪个领域；
各个候选模型过去在类似任务上的表现。

可以把它理解成 AI 编程工作台里的“调度员”：

流程图

这里有两个容易忽略的细节。

第一，路由发生在每次请求，而不是只在新建对话时选一次。Cursor 特别强调，真实路由要解决的不只是“这段对话用哪个模型”，还包括“什么时候切换模型”。同一段会话里，需求澄清、代码搜索、方案设计、修改和报错修复，完全可能适合不同模型。

第二，Cursor 描述的是“先分类，再选择模型”，不是让便宜模型先回答、答不好再升级。后者通常被称为模型级联（cascade）。两种方案都在解决成本与质量的矛盾，但 Cursor Router 的公开说明更接近请求级分类器。

早在 2023 年的 FrugalGPT、2024 年的 RouteLLM 等研究中，模型级联和基于偏好数据的路由就已经证明了潜力。Cursor 的推进在于，它把这类思路放进了高频、长会话的真实编程工作流。

二、Router 最有价值的资产，不是分类器本身

Cursor 表示，Router 使用超过 60 万条真实请求训练，并在数百万条线上请求中进行 A/B 测试。训练目标不是复现某个公开代码榜单，而是提高用户满意度。

这说明 Cursor 的优势不只来自一个“判断题目难不难”的分类模型，更来自三类长期积累的数据。

1. 真实任务分布

公开编程评测常集中在修 Bug、补函数或解决终端题目。实际开发却混合了大量工作：读陌生代码、修改 UI、解释报错、补类型、重构、写测试、讨论方案、连续追问。

路由器只有看过足够多的真实请求，才知道“简单”和“困难”在产品里分别长什么样。

2. 同一套 Agent 环境下的模型表现

模型能力不只取决于基础模型本身，还受到 Agent Harness 的影响。Harness 可以理解为包在模型外面的运行系统，包括提示词、工具、上下文整理、代码检索、错误恢复和停止条件。

同一个模型放进不同 Harness，结果可能明显不同。Cursor 长期在同一产品环境里观察多个模型，能够积累“某个模型在这套工具和上下文里擅长什么”的经验。这比只看厂商发布的榜单，更接近一次真实调用的预期效果。

3. 请求之后发生了什么

Cursor 没把“模型说得像不像正确答案”当作唯一标准，而是使用了两类线上信号：

用户满意度：用模型分析用户后续回复。用户继续做下一个功能，通常是正向信号；用户立即纠错或贴出报错，通常是负向信号。
Keep Rate（代码留存率）：观察 Agent 生成的代码在一段时间后，还有多少保留在代码库中。

这两个指标都不完美，但比单纯统计“回答完成”更靠近工程结果。它们让系统有机会回答一个更实用的问题：

这次调用产生的代码，用户最后真的接受了吗？

因此，Cursor Router 的长期壁垒可能不是路由算法，而是“请求—模型—执行过程—用户反馈—代码留存”这条反馈链。

三、三档模式，本质是让用户选择风险预算

Cursor Router 提供三种优化模式：

模式	官方定位	更适合的使用倾向
Intelligence	尽量接近最昂贵、最强模型的质量	关键重构、复杂排障、长链路任务
Balance	接近日常主力前沿模型的质量	大多数团队的日常开发
Cost	在控制 Token 花费的同时尽量提高能力	批量、低风险、容易验证的任务

官方将它们描述为成本与智能之间的 Pareto Frontier（帕累托前沿）：想继续降低成本，往往就要接受一定质量风险；想继续提高质量，则通常要投入更多费用。不存在一个模式在所有任务上同时最便宜、最快、最好。

这里的产品设计很克制。Router 没有假装系统能替用户决定一切，而是把两个层次分开：

用户或管理员：决定总体更重视成本，还是能力。
路由器：在这个边界内，为每次请求选择模型。

对团队来说，这比给所有成员发一张“什么任务用什么模型”的表更可执行。管理员可以按团队或用户组开启 Router、限制可选模式、设置默认值，并对底层模型建立允许或阻止列表。更新日志还提到，可以软性提醒，也可以强制团队使用 Auto。

换句话说，模型路由开始从个人习惯变成组织策略。

四、“省 60%”值得看，但不能只看标题

Cursor 公布了几组结果：

Auto Intelligence 的用户满意度接近 Fable，团队成本约低 60%；
Auto Intelligence 在近似成本下，满意度比 Opus 4.8 高约 15%；
Auto Balance 的满意度高于 Opus 4.8，成本约低 36%；
三个高用量早期客户，相比全部按 Opus 4.8 API 价格计算，Auto 请求节省 30%～50%；
Cursor 观察到的单次 Commit 成本，Intelligence 为 6.76 美元，Balance 为 4.63 美元，Opus 4.8 为 7.34 美元，Fable 5 为 12.69 美元。

这些数字的积极之处，在于 Cursor 没只报告离线题库分数。它用数百万真实请求做在线 A/B 测试，还把切换模型造成的缓存未命中成本计入评估。

缓存问题很现实。长会话中，模型厂商通常能复用已经处理过的相同上下文，降低费用。切换模型或供应商后，这部分上下文可能需要重新计算。如果只比较单次 API 标价，会高估路由节省的成本。Cursor 主动把这项损耗放进评测，是这份发布中较扎实的一点。

但这些仍然是 Cursor 自己发布的产品数据。公开文章没有给出完整实验分组、任务构成、统计区间、路由到各模型的比例，也没有开放原始数据。早期客户的 30%～50% 节省，比较基线还是“将同一流量全部按 Opus 4.8 API 价格重新计价”，并不等于每家团队从现有混合用法切换后都能得到同样结果。

Keep Rate 也不能直接等同于代码正确率。代码留下来，可能因为它确实好，也可能因为问题尚未暴露；代码被删除，也可能是需求变化，而不是模型写错。用后续回复推断满意度，同样属于代理指标。

因此，更准确的结论是：

Cursor 已经提供了很强的生产数据，证明自动路由有机会显著降低单位交付成本；但“你的团队能省多少”，仍需要用自己的任务分布验证。

五、自动选模型也引入了新的工程问题

把模型选择交给 Router，并不会让复杂性消失，只是把复杂性从用户界面移到了系统内部。

1. 结果更难复现

同一条请求在不同时间，可能因为模型池、路由策略或模型版本变化，被发给不同模型。对普通使用者，这可能意味着系统持续变好；对需要复盘事故、做合规审计或稳定回归测试的团队，这会增加解释成本。

Cursor 更新日志显示，路由到的具体模型可以显示，也可以隐藏，而且默认隐藏。需要审计的团队至少应该保留请求时间、Router 模式、实际模型、模型版本、费用和关键工具调用。

2. 错误路由会形成新的失败类型

便宜模型把简单任务做好，确实能省钱；但如果路由器把困难任务误判为简单，节省的 Token 可能会变成重试、人工接管和返工。

所以评估 Router 不能只看平均每次请求成本，还要同时看：

任务一次通过率
平均重试次数
人工纠正率
完成耗时
单次有效交付的总成本

真正应该优化的是最后一项，而不是某次模型调用有多便宜。

3. 团队需要知道何时不要用 Auto

自动路由适合任务量大、类型多、结果可以从后续行为中验证的工作流。以下场景则更适合固定模型或至少固定路由范围：

正在做可重复的模型评测；
需要严格复现某次结果；
安全或合规规则只允许特定供应商；
已知某个任务只能由特定模型稳定处理；
希望对提示词与模型行为做精确调试。

管理员的模型允许列表和模式限制，正是用来处理这些边界，而不是可有可无的企业功能。

六、Cursor Router 对 Agent 产品的真正启发

如果只把 Cursor Router 理解成一个模型下拉框升级，就低估了这次发布。

过去，很多 Agent 产品把模型名称直接暴露给用户：你选 GPT、Claude 或 Gemini，系统负责调用。这样实现简单，但也把一项需要持续评测的基础设施决策交给了用户。

当模型数量继续增加、更新越来越快，Agent 产品会逐渐形成三层：

流程图

第一层决定用户要什么，以及组织愿意承担多少成本和风险。

第二层根据任务、上下文和历史表现选择模型。

第三层才是模型真正推理，并通过工具完成工作。

Cursor Router 说明，应用层公司正在掌握越来越大的模型分配权。对基础模型厂商来说，竞争不只是谁能成为用户唯一的“主力模型”，还包括谁能在特定任务上成为路由器最愿意选择的模型。一个更便宜、更快、在某类任务上足够可靠的模型，即使不是综合榜单第一，也可能获得大量真实流量。

对自己开发 Agent 的团队来说，也不必一开始就训练复杂路由器。可以先做一个可验证的最小版本：

从日志里选出三到五类高频任务。
让候选模型在同一套 Harness 中完成这些任务。
记录通过率、耗时、总 Token、重试和人工接管。
为明显稳定的任务建立确定性规则。
只有规则开始覆盖不了真实差异时，再训练分类器。

例如，格式化、补文档、简单测试生成可以先固定到性价比模型；跨模块设计、复杂 Bug 和高风险迁移进入能力更强的模型；模型不确定或工具连续失败时，再升级处理。

完成后，不要只检查“路由成功”：

同一批任务的通过率是否保持？
单次有效交付成本是否下降？
困难任务的误路由是否可被发现？
切换模型后的缓存和延迟是否计入？
每次决策是否留下可审计记录？

这些问题有答案，路由才从省钱技巧变成可靠的 Agent 基础设施。

结语

Cursor Router 表面上是在替用户选模型，背后做的却是更重要的一件事：把模型能力、价格与真实工程结果连接起来。

它的核心逻辑并不神秘：

识别任务
→ 选择满足当前目标的模型
→ 观察用户是否接受结果
→ 继续更新对模型的认识

难点在于，这条链路需要大量真实请求、统一的 Agent 环境、可信的结果信号，以及对缓存、重试和人工返工的完整计费。Cursor 恰好同时拥有这些条件。

因此，这次发布最值得记住的不是“以后不用手动选模型了”，而是：

AI 编程工具的下一阶段，竞争单位可能不再是单个模型，而是“任务识别、模型路由、Agent Harness 与线上反馈”组成的完整系统。

对个人开发者，Auto 会减少选择负担。对团队，Router 是一套成本与能力治理机制。对 Agent 开发者，它则提供了一个更长期的方向：不要问哪个模型永远最好，而要建立一套系统，持续判断哪个模型更适合眼前这一步。

参考资料

Cursor：Introducing Cursor Router
https://cursor.com/en-US/blog/router
Cursor：Cursor Router Changelog
https://cursor.com/changelog/router
Cursor：Cursor Router Docs
https://cursor.com/docs/cursor-router
Cursor：How We Compare Model Quality in Cursor
https://cursor.com/blog/cursorbench
Cursor：Continually Improving Our Agent Harness
https://cursor.com/blog/continually-improving-agent-harness
RouteLLM：Learning to Route LLMs with Preference Data
https://arxiv.org/abs/2406.18665
FrugalGPT：How to Use Large Language Models While Reducing Cost and Improving Performance
https://arxiv.org/abs/2305.05176