cursor router compass 怎么工作 官方两层路由
cursor router compass 怎么工作？按官方博文梳理 Compass 复杂度分、taxonomy 标签与 75% uplift 规则，并标明厂商自报成本数据。
你在 Auto 里点发送，背后可能是 Grok，也可能是 Sol、Opus 或 Fable，但界面往往不显示具体型号。查 cursor router compass 怎么工作，其实是在问：Cursor 凭什么在每一轮里决定「便宜够用」还是「换前线模型」。官方在 How Cursor Router chooses the right model 里把链路拆成 Compass 复杂度预测和 taxonomy 任务分类，再用 uplift 规则与预算优化收尾；下文按机制讲，不重复「该开 Intelligence 还是 Balance」那类选型问题（那部分见 Cursor Router 如何省成本）。
每一轮路由先做复杂度分流再做专长匹配
Cursor Router 不用公开 benchmark 榜定模型，而是用线上开发者对话学出来的策略。单次决策会读当前 turn 与近期会话状态：任务类别、最近 tool call、工作上下文等结构化特征。
流程固定为两步。第一步由 Compass 判断这一轮是否足够简单，能否留在低价路径。第二步若 Compass 认为复杂度够高，再用 taxonomy 给 turn 打标签，并在 Grok、Sol、Opus、Fable 等候选里挑观测表现最好的组合。厂商后续还把 Opus 5 纳入候选池，并继续改 Compass 的预测；具体数字以 Cursor 博文为准，会随模型迭代变。
下面这张表把三步决策压成一行链路，方便对照 release 或 help 文档时定位「卡在哪一层」。
| 阶段 | 依据什么 | 产出 |
|---|---|---|
| Compass | 预测用户是否会满意（作复杂度代理） | 0–1 分；低于阈值走 Grok 等低价模型，高于阈值进入 taxonomy |
| Taxonomy | 从真实流量学出的 domain / task / modifier | 例如 backend + fix bug + bounded edits |
| Task router | 该标签下各模型相对低价基线的观测表现 | 仅当 uplift 过 75% 置信门槛的候选可入选；再在模式预算内做流量加权优化 |
Auto Balance 与 Auto Intelligence 的差别，本质上是 Compass 阈值高低和 task router 预算松紧在成本–体验曲线上的两个预设点，不是两套无关系统。
Compass 如何把「会不会满意」变成 0 到 1 的分
Compass 的训练标签来自用户下一步行为：继续下一项任务视为正反馈，回头纠正 agent 视为负反馈。官方用它预测「这一轮回答后用户是否满意」，再把预测值当作复杂度的代理变量。逻辑是简单活（例如只做一次 commit）很少触发纠正，复杂 refactor 更容易引出追问。
线上评估里，Compass 判为「最可能成功」的 turn，正反馈约 96%；判为「最可能失败」的约 71%（均为 Cursor 博文自报）。实践中每个 turn 得到连续分数 0–1，团队再在区间内设阈值：阈值越低，越多流量留在低价模型；阈值越高，越频繁升级到前线模型。提高阈值会在官方图表里表现为成本上升、质量增益加大，这是调 Auto 两个档位时的底层旋钮，不是用户界面上的独立开关。
taxonomy 三维标签描述「什么活、在哪做、有什么修饰」
复杂 turn 进入第二层后，分类器用三类维度描述工作，数据同样来自真实 Cursor 流量。
Domains 表示工作落在哪：backend、database schema、frontend 等。Tasks 表示要干什么：修 bug、跑命令、写测试等。Modifiers 跨 domain 与 task，但会改变模型优劣，例如 bounded edits、产品问答、视觉改动较多等。
官方在博文里归纳了各模型在观测上的偏科（仍是厂商基于内部路由数据的总结，不是第三方复现）：Grok 推理成本低，适合 Git 命令、常规数据库操作等日常类任务；Sol 在规划与读 codebase 上更强，部分实现任务成本低于其他前线；Opus 偏执行与 devops、SQL、性能优化；Fable 在调试与视觉实现上质量溢价更明显。Router 的目标是在标签粒度上匹配「这一小类活」谁的历史表现最好，而不是全局钉死一个「最强模型」。
75% uplift 规则与模式预算如何一起定模型
当 Compass 把 turn 交给 taxonomy 路由器时，选型遵循两条规则。第一，只有观测表现相对低价基线「明确更好」的候选才 eligible：官方表述为在该 task label 上需通过 one-sided 75% uplift threshold，大致含义是要有约 75% 置信度认为提升真实存在，避免为噪声切换贵模型。第二，在 eligible 集合里，优化器按流量权重选期望收益最大的组合，同时把平均每 turn 成本压在当前模式（Auto Intelligence / Auto Balance）的预算内。
Compass 阈值与 task router 预算共同决定档位在曲线上的位置。Balance 更多留在 Compass 以下的低价路径，给 taxonomy 层的预算更紧；Intelligence 允许在预期收益够大时更频繁选前线模型。博文里关于 Auto 相对 Fable 级满意度、相对 Opus 4.8 的成本与满意度对比，均属 Cursor 自评的生产 A/B 结果：例如称 Auto Intelligence 在 Fable 级满意度之上成本约低 68%，且自 launch 后再降 18%；Auto Balance 相对 Opus 4.8 成本约低 41%（再降 8%）且满意度约 +3%。这些数字帮助理解设计目标，不应当成你账单上的保证。
训练集里 performance 与 cost 怎么进路由
路由策略离线阶段用 cross-validation 调 Compass 阈值与预算，再在 held-out 测试集上看期望成本与表现，最后上线做 live traffic 验证。数据来自数十万级 turn 采样，每条包含路由器可见信号，以及 performance、cost 两个结局。
Performance 仍是用户后续行为代理；cost 按 API 定价与当轮 token 计，并计入 live 流量里 benchmark 常忽略的 cache miss（换模型导致缓存失效）。因此 Router 在训练里会把「频繁换贵模型」和「 stuck 在便宜模型上被用户纠正」都折进目标函数，这也是它相对手动换模型声称能兼顾 cache 的原因。
和 Cloud Agent、手动选模型差在哪
Router 解决的是 Teams/Enterprise 场景下「同一 IDE 会话里每 turn 自动分档」。你在模型列表里手动钉 Opus，等于绕过 Compass 与 taxonomy；官方材料则强调 Auto 模式在平均成本与满意度上的折中。云端 VM 里长跑的 agent 还有另一套 token 与工具挂载问题，与本地 Composer 路由不是同一层，可对照 cursor 云端 agent 怎么省 token 看 cloud 侧约束。若你只关心「开哪个 Auto 档位更省钱」，仍应读选型向的 Cursor Router 如何省成本，本文只解释 Compass→taxonomy→uplift 机制。