Cursor Router 在替你决定什么：路由这一层的机制

先把问题问具体一点：在 Cursor 里选了 Auto，敲下回车，这一条 agent 请求最终落到哪个模型，是谁在决定？答案不是”你”，也不完全是”某个模型池”。官方文档《Cursor Router》页（cursor.com/docs/cursor-router）把这件事拆成了几层可核对的机制，每一层都能卡住上一层的结果。下面就沿着文档写明的路径走一遍，中途把关键的字段名和设置项标出来，方便你自己回官方文档翻。

最上面一层：这个能力在不在你的账号上

文档开头就写明了一句很硬的限制：Cursor Router 目前只在 Teams 与 Enterprise 套餐上可用。这一句决定了后面所有讨论的前提——不在这两类套餐里，下面的模式选择、团队后台开关都无从谈起。

即使在企业环境里，“有”也不等于”开着”。团队设置那一节写明，Enterprise 团队必须手动启用 Router，它默认是关闭的（off by default）。这一点和帮助中心《Cursor Router》页（cursor.com/help/models-and-usage/cursor-router）里那句”Balance 是新用户的默认模式”并不冲突，但两处的”默认”说的不是同一层：一处指路由器这个能力本身在企业团队里默认不开，另一处指路由器开着时新用户落在哪一档模式上。把这两句放在一起看，才不会在排查时把”我这里没有 Balance”误判成模式问题。

第二层：优化模式，是你唯一的方向盘

文档写明的操作路径是：打开模型选择器，选 Auto，然后在 Optimize For 下面挑一档模式。文档列出的模式一共三档：

模式	官方文档写明的语义
Cost	使用此前的 Auto 路由逻辑，优化 token 花销，保留原来打包的 Auto 计费方式
Balance	在智能、速度与成本之间做优化
Intelligence	面向更难的任务路由到能力更强的模型

帮助中心那一页补了三条同向的说明：Cost 等同于旧版 Auto 模式，Balance 是新用户的默认模式，Intelligence 推荐用于复杂的多步骤工作。文档还写明模式可以随时切换。

这里有个容易被忽略的设计：你能调的只有这个方向盘，调不了具体去哪辆车。文档明确写了路由是数据驱动、由 Cursor 管理的，你无法为某次请求手工指定由哪个模型处理（not configurable per request），而且模型池会随新模型上线而变化。换句话说，“这次我想让它用某某模型”这个诉求，在 Auto 这条路径上文档写明是不支持的；要固定模型就得走选具体模型的路径，而不是 Auto。

至于三档模式各自的费用差异，文档给了口径（Cost 走打包计费，Balance 与 Intelligence 按被路由到的那个模型的费率按请求计费），也提到 Balance 与 Intelligence 会更快地消耗你的用量额度。具体倍数与费率属于随时会变的商业条款，本文不抄，需要时以官方定价与用量说明页为准。

第三层：分类器按什么分

到了真正”决定”的那一步，两页文档的说法是一致的：每一次 agent 请求上都会跑一个分类器（帮助中心那页写的是机器学习分类器），按**任务类型（task type）与复杂度（complexity）**来路由。文档给出的取向是：简单请求走快而省的模型，复杂工作走能力更强的模型；目标是挑出”在这一次请求上仍能给出可比结果的、成本最低的那个模型”。

需要停在这里——文档就写到这个粒度为止。它没有公开分类器看的是什么特征、怎么给复杂度打分、阈值在哪里。Cursor 是闭源商业产品，我们没有源码，也没有做过任何实测，所以再往下的”它内部大概是怎么判断的”一律不写。你能据此做的推断只有一条：同一个提示词在两次请求里可能落到不同模型上——这一条不是我们猜的，SDK 文档里白纸黑字写着底层模型可能在请求之间变化，并建议需要可复现对比时改用固定的模型 id。

第四层：团队的模型访问控制，会反过来塑造路由池

这一层是企业环境里最容易出意外的地方。《Cursor Router》页写明：在 Enterprise 套餐上，Router 会遵守团队的模型访问控制；如果某个模型对你的团队是被禁用的，路由器会改路由到一个被允许的模型。帮助中心那页的说法一致——被禁的模型会被跳过，回退到允许清单里的替代项。

但文档紧接着给了一句提醒，这句才是真正的坑：禁用太多模型会降低路由质量，甚至可能让路由器不可用。文档还写明，为了做出成本节省，路由器需要有一款既有能力又成本可控的模型可用（在不调用其它前沿模型时用它），因此文档点名要求启用某一款具体模型，Router 才能工作——那一页给出了该模型的文档链接。模型池本身会随时间变化，这里不抄具体型号，以官方《Cursor Router》页最新内容为准。

模型访问控制本身的合并规则也值得一并核对。团队后台文档（cursor.com/docs/account/teams/dashboard）写明模型访问从 Team Settings → Models 配置，组织还可以按群组从 Organization → Groups → Models 放宽，团队与群组的模型访问按并集合并（most-permissive wins）；《Organization groups》页补了一句：群组无法收回团队（或该用户的另一个群组）已经允许的模型，建议在团队上设最严格的基线、再按群组放宽。

把这条和上一段接起来看：你在收紧模型访问时，收紧的不只是”谁能手动选哪个模型”，同时也在裁剪 Router 的可用池。这两件事在文档里是分开写的，却作用在同一份允许清单上。

团队后台上真正能拧的四个开关

《Cursor Router》页的 Team settings 一节列出了管理员可配置的项，一共四项，逐条抄一下语义：

• Enable Cursor Router：路由的总开关。开启后，团队成员使用 Auto 时由 Cursor Router 路由。Enterprise 团队必须手动启用。在 Enterprise 套餐上，Router 还可以按 organization group 分别配置。
• Routing preferences：选择成员能从 Auto 里挑哪些优化模式。官方文档写明最多可以禁用其中 2 档——也就是说，至少要给成员留一档。
• Underlying model：在每次回复开头显示 Auto 实际路由到了哪个模型，或者保持隐藏。文档写明默认且推荐是隐藏，理由是文档自述的：“让结果按自身表现被评判，而不是按模型名字。“该项适用于 Balance 与 Intelligence 模式。
• Impose Auto：把 Auto 设为全团队的默认模型。Soft 让每个新会话默认落在 Auto 上，成员仍可切换模型；Hard 把模型选择器锁死在 Auto。文档写明两者默认都是关闭的。

第三项对排查很关键：如果你的团队保持了默认的隐藏设置，那么”这次回复是哪个模型写的”在产品里就是不可见的。这不是你哪里没配好，是文档写明的默认行为。

同一条链在 SDK 里长什么样

如果你在写自动化脚本，Router 的这套机制在 SDK 里有一份更明确的契约。TypeScript SDK 与 Python SDK 的文档（cursor.com/docs/sdk/typescript、cursor.com/docs/sdk/python）写明：Router 就是模型 id auto-smart，配一个 optimize_for 参数。文档给出的产品标签与 SDK 取值对照表是：

产品里的标签	SDK 取值
Cost	cost
Balance	balanced
Intelligence	intelligence

注意中间那一行——产品文案里写 Balance，线上取值是 balanced。文档专门加了一句”Use Balance in product copy. Use balanced only as the SDK wire value.”。这种一字之差的口径不一致，是照着界面文案硬编码时最典型的翻车点。

TypeScript 侧文档给的写法是这样的：

import { Agent } from "@cursor/sdk";

await using agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: {
    id: "auto-smart",
    params: [{ id: "optimize_for", value: "balanced" }],
  },
  local: { cwd: process.cwd() },
});

Python 侧对应的是 ModelSelection(id="auto-smart", params=[ModelParameterValue(id="optimize_for", value="balanced")])。两边文档都强调：必须显式传 optimize_for，不要省略，也不要沿用旧的 default 值——文档写明省略或传 default 都不是受支持的 Router 契约。

文档给出的做法是先做发现，再硬编码：调用 Cursor.models.list() 拿到当前 API key 所属账号与团队可用的模型、参数定义与 preset 变体，确认 auto-smart 在结果里，再确认 optimize_for 的 values 里包含你想用的那一档。原因文档也写明了：团队管理员可以禁用 Router，也可以限制成员能选哪些优化模式——上一节那个 Routing preferences 开关，在 SDK 这一侧就体现为某个取值不在 values 里。

还有两处 SDK 专属的语义值得记：一是 agent.send() 上可以按次覆盖模型，但文档写明这种按次覆盖是”粘”的（sticky），后续不带覆盖的 send 会继续沿用新选择；二是 auto-smart、auto、default 三者不是一回事，文档给了对照表——{ id: "auto" } 是”目录里找不到指定模型时由服务端选择的 Auto 回退”，需要明确指定 Router 模式时应当用 auto-smart。

Router 在 SDK 里找不到时，文档给了一条 6 步的排查顺序：调 Cursor.models.list()、确认 auto-smart 在结果中、确认 optimize_for 含目标取值、确认该 API key 所属团队启用了 Router、若你属于多个团队确认 key 工作在预期的团队上下文里、最后检查团队的模型访问策略。这六步正好把前面四层从下往上倒着核了一遍。

最后一条边界要说清楚：文档明确写了 Cursor SDK 是 agent SDK，不是独立的模型推理或 chat-completions API，Router 挑的是跑 Cursor agent 的模型；Cursor 目前没有为任意模型调用公开一个 raw Router 端点。想把它当通用模型网关用的，文档在这里给的就是明确的”没有”。

端上的差异与几句限定

上面 SDK 示例里的 process.env.CURSOR_API_KEY / os.getcwd() 是跨平台的。需要注意的是环境变量本身怎么设：官方 CLI 认证文档（cursor.com/docs/cli/reference/authentication）给的是 POSIX shell 的写法 export CURSOR_API_KEY=your_api_key_here，没有给 Windows 侧的对应写法。在 Windows PowerShell 里当前会话设置环境变量用 $env:CURSOR_API_KEY = "<YOUR_API_KEY>"——这一句是通用做法，不是该产品官方文档的内容，写进 CI 或长期配置前请按自己环境核实。密钥不要硬编码进仓库。

以上代码为官方文档中原样给出的示例，我们没有做过实测，以官方文档与 API 的实际响应为准。该产品迭代频繁，文中涉及的设置项、参数取值与默认值随版本变动。

回到开头那个问题：一条 Auto 请求的去向，由套餐门槛、团队开关、你选的优化模式、分类器对任务类型与复杂度的判断，以及团队模型允许清单这几层共同决定。你能直接拧的只有优化模式一档，管理员能拧的是团队后台那四项，其余都在 Cursor 这边。知道这条链的形状，至少能让”为什么这次和上次不一样”有地方去查。

---

本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。 该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。 该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。 本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。