Cursor Router 隐藏了模型选择，但发布证据不能一起消失

Cursor 现在可以按每一次请求选择模型，不再要求开发者在整段编程会话里固定使用同一个模型。界面上的变化看起来不大，系统边界却变了：一个分类器开始决定谁来接收请求；会话中途切换模型可能改变缓存表现；厂商发布新模型后，可选模型池也可能跟着变化。

Cursor 在 Router 发布说明中称，这套路由器使用超过 60 万条真实请求训练，并在数百万条路由请求上做过在线 A/B 测试。对于三个高流量早期客户，Cursor 把实际路由流量与“全部按照 Opus 4.8 API 价格计费”比较，观察到约 30%–50% 的成本下降；它还公布了 Balance 和 Intelligence 模式低于若干单模型对照的每次 commit 成本。

这些数字值得关注，但它们仍然是厂商在自有环境中的观察，不能直接成为你所在仓库的节省预期。Cursor 的满意度分类器、代码保留率、客户任务分布、模型池、prompt 和 agent harness，都属于 Cursor 的运行条件。支付集成、多语言 onboarding、合规后台所承受的错误代价并不相同。

小团队今天要做的，不是立刻“全面开启路由”，也不是一概禁用。更稳妥的改变是：在把 Auto 设为团队默认前，先做一次“验收通过的变更”审计。把一次工作从请求追踪到审查、合并和短期稳定，并保留足够的路由证据，以便回溯退化来自哪里。

本文给出一套 36 个任务、两个实验组的上线筛查方案，同时提供路由凭证和推广矩阵。Y Build 没有运行 Cursor Router，没有复现 Cursor 的数字，也没有比较文中提到的模型。后面的门槛都是供团队自行调整的起点，不是已经得到的实测结果。

Cursor 发布了什么，还有哪些关键未知项

Cursor Router 已面向 Teams 与 Enterprise 客户开放，覆盖桌面端、Web、iOS、CLI 和 SDK。它会综合 query、上下文、任务复杂度、领域，以及 Cursor 对各模型行为的了解，为每次请求分类。管理员可选择 Cost、Balance 或 Intelligence 模式，按小组启用路由，限制可用模式，并允许或阻止底层模型。发布日志还有一个对运维很重要的细节：被路由到的模型可以显示，也可以隐藏，而默认是隐藏。

Cursor 表示，其在线评估已经计入会话内切换模型造成的额外 cache miss 成本。质量信号包括用户接下来是继续做新功能还是纠正智能体，以及智能体生成的代码有多少在后续仍留在仓库里。Cursor 另一篇关于持续改进 agent harness的文章还提到代码保留率、从后续消息推断的满意度、延迟、token 效率、工具调用次数和缓存命中率。

不过，已经公开的仍是聚合后的厂商口径。发布文没有披露路由分类器、各任务类别样本量、置信区间、模型选择混淆矩阵、路由版本历史，也没有展开三个示例客户内部的结果分布。“质量没有下降”依赖 Cursor 自己的质量代理指标；“每次 commit 成本”也没有回答这次 commit 是否通过审查、是否需要后续修复、是否真正上线。

新团队开始试用时，还应把以下问题列为待验证项：

• 即便用户界面隐藏了模型，管理员能否导出每条路由请求实际选择的模型？
• 实验期间能否固定允许使用的模型池和 Router 模式？
• 一段会话中途换模型时，已积累的上下文会如何处理？
• 对敏感仓库阻止某个供应商、模型版本或地区后，实验对照条件会不会被无声改变？
• 能否把路由带来的效果与 agent harness 的其他更新区分开？

这些未知项不是指控。正确做法是把它们变成验收条件。

路由器是发布系统，不只是更便宜的模型选择器

单模型策略当然有局限，但它比较容易解释。团队知道计划使用的是哪个模型；只要快照仍可用，就能尝试复现同一请求；价格变化也较容易对应到公开费率或 prompt 变长。

请求级路由在意图与执行之间增加了一层策略。它可能让任务与模型更匹配，也可能同时改变三件事：

1. 能力： 常规修改可能交给便宜模型，复杂迁移则进入前沿模型。
2. 经济性： 最终账单由所选模型、prompt 大小、缓存状态、重跑和后续轮次共同决定。
3. 治理： 不同模型供应商的数据处理、地区、合同和内部审批条件可能不同。

学术研究说明了路由的潜在价值，但不能替 Cursor 的具体实现背书。RouteLLM利用偏好数据学习在强模型与弱模型间做选择，并在公开 benchmark 上报告成本与质量的取舍。FrugalGPT研究了 prompt 调整、模型近似和级联方案。两者都说明，在预算约束下，异构模型组合可能优于“所有任务只用一个模型”。但它们都不能证明某个编程智能体路由器会保住你的合并质量或数据边界。

因此，真正要发布和验收的单位不是分类器本身，而是整个路由系统：分类器、可用模型池、模型快照、harness、缓存行为、管理员策略和人工审查。任何一项改变，实验版本都应随之改变。

先定义“验收通过的变更”，再计算节省

一次请求不是产品结果，一段回答也不是。即便已经生成 commit，也只是中间产物。

在这套审计里，验收通过的变更是指最终 diff 同时满足：

• 通过预先写好的任务专属验收检查；
• 通过仓库中的确定性检查；
• 通过人工审查，且不需要一级严重修正；
• 已合并，或明确被纳入候选发布版本；
• 在审计观察窗口内没有被回退。

观察窗口要与发布节奏匹配：每天发布的产品可以先看 48 小时，周发布产品可以看七天。目的不是无限期等待，而是捕捉最常见的情况——智能体修改看似完成，上线前后却立刻制造修复工作。

随后计算每个验收变更的完全成本：

(智能体用量成本
 + 重跑成本
 + 审查分钟数 × 约定内部费率
 + 作者修正分钟数 × 约定内部费率
 + 回滚或事故处理分钟数 × 约定内部费率)
÷ 验收通过的变更数

这不是会计准则，而是一把比较尺。两个实验组必须使用相同的内部费率与计时规则。订阅席位成本应单独列出，除非路由实验本身会改变所需席位数量。

Cursor 的每次 commit 成本仍然有参考价值，因为它比 token 单价更接近交付。这里再向前走一步：如果一份低价 commit 被拒绝、大幅重写或回退，对小团队而言，它就不构成真正的节省。

用任务牌组暴露“路由错了”的情况

随机生产流量最真实，却很难解释；通用编程 benchmark 比较方便，却未必代表你实际发布的工作。更合适的做法是从近期已经完成的任务中制作固定牌组，再在隔离分支或一次性仓库副本中重放。

先准备 36 个任务，分成六类：

每类六个任务，而且每一类内部都要同时包含简单与困难任务。否则，路由器只要把整个“编程”类别都送往最强模型，也会显得很聪明。EACL 2026 论文 How Robust Are Router-LLMs?发现，被研究的部分路由器会做出粗糙的类别级选择，例如把所有编程和数学问题都送给最强模型，即便较弱模型足以处理其中一些任务；论文也观察到与安全有关的类别错误。它研究的不是 Cursor Router，但足以说明为什么同一类别内部也要做难度分层。

冻结任务描述、起始 commit、可用工具、仓库规则、时间上限和验收命令。去掉密钥与客户数据，也不要为了方便，把尚未解决的生产漏洞直接拿来当实验 fixture。

两个实验组要可比较，也要承认环境会变化

第一轮只比较一个 Router 模式和一个有意选择的单模型基线。对多数团队来说，Balance 对比当前日常主力模型，是最清晰的起点。如果同时测 Cost、Balance、Intelligence 和多个单模型，36 个任务会被摊得过薄，事后很容易挑选对自己有利的解释。

把 36 个任务视为一次发布筛查，而不是足以证明普遍优越性的统计实验。它的任务是：在扩大使用人群前，发现本地退化、修正成本与证据缺口，而不是生成一个可以对外泛化的百分比。

在每个任务类别内部随机分配运行：

• A 组： 选定模式的 Cursor Router。
• B 组： 团队当前使用的单模型默认项。

预算允许时，每个任务都跑两个组，共计 72 次。预算有限时，可以按难度配对后交替分组，再把两组结论不一致的任务各跑一次。审查者在记录是否验收和修正严重度前，不应知道任务属于哪一组。若开发者知道某份 diff 来自“便宜组”，很可能无意识地提高审查标准。

尽量固定可以控制的条件：同一仓库状态、相同规则文件、相同工具、相同时间上限、相同验收命令，以及初始请求后不再给予人工提示。无法控制的条件也要记录：服务事故、模型下线、harness 发布、路由模型池变化。目的不是制造完美实验室，而是在接近生产的环境里作出诚实判断。

观察窗口至少要覆盖正常时段与高峰时段。若路由器也根据可用性优化，供应商退化期间的行为可能不同。遇到故障时，不要把“杂乱数据”删掉；应把它标为单独分层，查看决策是否只在正常时段成立。

为每个任务保留一份路由凭证

聚合 dashboard 能告诉你总支出下降，却解释不了一次高风险迁移为何失败，也无法确认被禁用的供应商是否实际收到请求。每个任务都需要一份凭证，把系统遥测与最终产物连接起来。

audit_id: router-2026-07-23-017
task_id: auth-session-rotation-04
bucket: risky-migration
arm: router-balance
router_mode: balance
router_version: unknown
eligible_models_policy: team-policy-2026-07-23
selected_models:
  visible_to_user: false
  exported_values: []
started_at: 2026-07-23T01:15:00Z
ended_at: null
usage:
  input_tokens: null
  cached_input_tokens: null
  output_tokens: null
  provider_cost_usd: null
workflow:
  follow_up_turns: 0
  reruns: 0
  tool_errors: 0
  human_correction_minutes: null
acceptance:
  deterministic_checks: pending
  reviewer_decision: pending
  severity_one_correction: false
  merged: false
  reverted_in_window: false
policy:
  provider_allowed: pending
  privacy_mode_enforced: pending
result: pending

null、unknown 和空数组都是有效结果。它们明确暴露观测缺口，而不是制造虚假的精度。若用户界面隐藏模型，管理员导出也看不到，就如实记录。对高风险仓库来说，无法调查一次路由本身就可能构成阻止推广的理由。

Cursor 的 Admin API 文档描述了较细的用量记录，包括模型、token 消耗和成本。实验前仍需确认：当前接口与团队套餐是否真的会为路由请求提供你需要的字段。文档列出某类字段，不等于每个 workspace 都能导出完整的 Router 信息。

分开衡量五类结果，不要压成一个总分

不要把审计压缩成单一“路由器得分”。只要权重设置得当，大幅节省就能掩盖少数严重失败。五类结果应分别报告。

验收差异与一级严重失败应当是硬门槛。只有硬门槛通过后，成本、时间和缓存才是可优化指标。既看中位数，也看尾部，因为一次高代价修复可能抵消许多简单任务的节省。

RouteJudge提出了面向路由器的记录方式，保存 query、路由决策、模型回答、偏好标签、成本、延迟与任务元数据。它的公开两两比较设计比本文的仓库审计更广，但记录结构传达了同一个原则：评估路由器需要逐次决策证据，不能只看模型排行榜。

主观审查与确定性验收也要分开。审查者可能更喜欢某个方案的写法，但测试会揭示迁移已损坏；相反，机械检查全部通过的 patch 也可能增加维护债。两种信号都重要，但不能让其中一个悄悄覆盖另一个。

专门测试缓存、会话切换与修正循环

请求级路由发生在会话内部，而编程任务往往依赖前几轮积累的上下文。即使用户看到的会话没有中断，换到另一供应商模型也可能失去原本的 cached input 优惠。Cursor 说其生产评估已计入 cache miss 成本，但你的仓库可能有更大的规则文件、更多附加文档和更长会话。

加入三组脚本化会话：

1. 稳定延续： 用四轮完成检查、修改、测试和解释同一功能。
2. 后段难度陡升： 先做局部修改，再暴露一个需要跨文件推理的失败。
3. 修正循环： 用固定测试失败拒绝第一版 patch，并要求完成一次修复。

每个 fixture 都记录模型选择是否可见、输入 token、缓存输入 token、后续轮数、总成本，以及最终变更是否通过验收。不要仅凭一次 cache miss 推断发生了模型切换；上下文裁剪、prompt 变化或供应商缓存行为也可能产生相同现象。

真正有用的问题不是“路由器换模型了吗”，而是：“整段会话是否以更低完全成本交付了验收通过的变更，同时没有制造调查盲区？”一次更昂贵的切换如果挽救了困难任务，可能很有价值；便宜的第一轮若引发三轮修正，未必省钱。

把供应商与隐私策略纳入质量定义

路由扩大了可能参与请求处理的模型供应商集合。这有利于可用性，但若请求违反仓库的供应商策略，即便生成代码十分优秀，也不能算验收通过。

Cursor 的数据使用说明称，开启 Privacy Mode 后，Cursor 与模型供应商不会使用客户数据训练模型，而且 Cursor 与供应商维持零数据保留协议。页面也说明了滥用检测相关的例外，并称非 ZDR 模型会被标记，或需要管理员主动开启。Cursor 2026 年 5 月的模型控制更新则表示，企业管理员可以按供应商或模型配置阻止访问，也能默认阻止新供应商和新版本。

把这些管理能力转化为本地策略测试：

• 为不同仓库风险等级列出允许的供应商与模型类别；
• 需要时在组织层强制开启 Privacy Mode；
• 对敏感工作默认阻止新加入的供应商；
• 为每个策略等级准备一个合成 canary 任务；
• 用导出的实际路由核对策略，而不是只看设置页截图；
• 对必须披露供应商的仓库，只要所选模型未知，就停止实验。

这并不是在声称 Cursor 违反策略，而是在为一个动态依赖执行普通验收测试。配置截图证明团队的意图；路由凭证才是执行证据。

用明确门槛决定推广与回滚

在看到结果前先写门槛。下面的矩阵有意偏保守，团队应按照自身产品的失败成本调整。

推广决定必须写清范围：哪支团队、哪些仓库、哪种 Router 模式、哪份可用模型策略，以及下次复核日期。不要只留下“Router 已批准”这样没有边界的结论。

回滚也要演练。确认管理员可以停用 Router、恢复单模型默认、保留审计记录，并通知可能受影响的活跃会话用户。一个确实存在、但必须提交客服工单才能执行的开关，不能算即时回滚。

NIST AI RMF 的衡量指南建议监控生产行为，将生产表现与部署前测量比较，记录人工覆盖，并在模型或运行环境变化时重新评估指标。对路由器而言，这意味着批准必须有有效期：路由版本、可用模型池、重要模型、价格或仓库任务结构发生重大变化后，都应重跑一小组 sentinel 任务。

明确这套实验不适用于什么

这套协议面向正在决定是否在编程工作中标准化请求级路由的小团队。它不评估通用聊天、客服路由、医疗或法律决策系统，也不适用于完全无法观测的路由器。

36 个任务可以暴露明显的本地问题，但无法估计罕见失败率，也不能证明普遍优越性。人工审查会有波动；近期已完成任务可能让开发者过于熟悉；重放仓库缺少真实生产压力；完全成本依赖一项可能有争议的内部时间费率；单模型基线也可能在观察期间更新。

文中引用的路由研究使用不同模型池、任务、标签与约束。RouteLLM 和 FrugalGPT 不验证 Cursor Router；RouteJudge 是拟议中的评估平台，不代表 Cursor 必然导出相同字段；EACL 的鲁棒性结果揭示的是被测试路由器中的风险，并未证明 Cursor 存在同样缺陷。除非有人在可比较环境中独立复现，Cursor 的节省数字就仍然属于 Cursor 的结果。

不要使用真实密钥、未隔离的生产写操作或尚未解决的客户事故来跑这套审计。如果某个仓库不能容忍供应商不透明，就应在实验前要求披露路由，而不是出事后才尝试追查。

小团队可以在两天内完成的现场计划

第一天，确定一个基线模型和一个 Router 模式。从近期工作中挑选 36 个已脱敏任务，分成六类并标记难度；写好验收检查，冻结起始 commit，统一修正时间记录方式。配置供应商 allowlist 与 Privacy Mode。确认管理员导出是否包含计划审计的模型和用量字段；若字段缺失，就记录这一缺口，再判断低风险仓库是否仍可继续。

第二天，在隔离分支运行分组任务，审查者在作出判断前不知道实验组。每次运行保存一份路由凭证；重跑结论不一致的任务，并完成三组多轮会话 fixture。分别计算验收、修正、完全成本、交付时间和治理结果，先审查尾部失败，再看平均趋势。

最后形成一份签字决策记录，包含试用人群、仓库、Router 模式、基线模型、可用模型策略、观察窗口、失败任务、未解决问题、回滚负责人和到期日。若门槛没有通过，产出也不是一次“失败的 benchmark”，而是一个准确理由：为什么暂时不能把不可见的依赖设成默认。

Cursor Router 可能降低日常编程工作的价格。真正的发布问题是：节省能否通过审查、修正、策略与时间的考验。请按验收变更计数，保存路由证据，让路由器用结果证明它配得上进入你的发布系统。

参考资料

1. Cursor：Introducing Cursor Router
2. Cursor：Router changelog
3. Cursor：Continually improving our agent harness
4. Cursor：Admin API
5. Cursor：Data Use & Privacy Overview
6. Cursor：Model controls, spend management, and usage analytics
7. Ong 等：RouteLLM: Learning to Route LLMs with Preference Data
8. Chen、Zaharia 与 Zou：FrugalGPT
9. Lai、Hu 与 Ye：RouteJudge
10. Kassem、Schölkopf 与 Jin：How Robust Are Router-LLMs?
11. NIST：AI RMF Measure Playbook