Cursor 不想只当编辑器了

5 月第一周，Cursor 连续推了四天更新。单看每条 changelog 都不算炸裂，但拼在一起，方向很清楚：Cursor 正在把自己从 AI 代码编辑器，改造成一个 coding agent 的运行平台。

最重要的更新：Build in Parallel

5 月 7 日，Cursor 3.3 上了 Build in Parallel from plans。

之前 Cursor 的 Agent 模式是串行的——拿到需求，生成计划，一步一步改文件，跑测试，再改。一条线跑到底。

现在 Cursor 会分析计划里的任务依赖关系。几个步骤之间互不影响，就派给多个 async subagent 并行跑；有依赖的部分仍然按顺序来。

听起来像”多开几个窗口”，但真正难的地方不在并发：

• • 怎么判断两个任务能不能并行？改同一个文件的两个任务同时跑，大概率冲突。
• • 多个 subagent 各自改完代码，怎么合并？
• • 合并之后怎么拆成可以 review 的 PR？

同一天还上了 Split changes into PRs。多任务执行完之后，可以把改动按逻辑切片拆成多个独立 PR，拆之前自动建 snapshot 备份，拆完让用户审批。

两个功能连起来看，补的不只是”并行写代码”，而是一条更完整的链路：并行执行 → 逻辑切片 → 备份 → PR 拆分 → 人工审批。

代码写出来只是开始，能被 review、能回滚、能追踪，才算工程化。

Agent 在变成任务调度器

同一天的更新里还藏了几个细节。

Cursor 允许单独控制 Explore subagent 用哪个模型——可以继承主 Agent 的模型，也可以指定别的，甚至直接禁用。这说明 Cursor 已经在做 subagent 级别的模型路由：主 Agent 管规划，Explore subagent 管代码库探索，各自配不同模型。再往下走，不同角色的 subagent 会有各自的 prompt、权限和上下文窗口。

另一个，/multitask 命令可以在编辑器里直接用了，多个请求通过 async subagent 并行处理，不排队。以前给 Agent 一个任务，得等它跑完才能下一个。现在更像在调度后台 worker：修登录 bug、更新测试、补文档、检查 breaking change，四件事同时跑。

这已经不是”AI 辅助编程”的交互方式了，更像 IDE 里长出了一个任务调度器。

上下文变成了可以 profile 的资源

5 月 6 日的更新没那么显眼，但可能更关键：Context Usage Breakdown。

这个功能把 Agent 每次请求的上下文消耗拆开给看——rules 占了多少 token，skills 占了多少，MCP 工具描述占了多少，subagent 上下文占了多少，真正的代码内容占了多少。

现在 coding agent 的瓶颈经常不是模型不够强，而是上下文被噪音淹没。规则塞太多，MCP schema 太长，历史对话太长，subagent 带入了无关内容。context window 看着大，有效信息密度低。

以前只能凭感觉调 rules 和 skills。现在能看到具体数字，就像传统工程里 profile CPU 和内存一样。下一步大概率走向自动优化：哪条 rule 太长建议精简，哪个 skill 应该按需加载，哪个 MCP schema 占比过高。

企业治理层开始补齐

5 月 4 日的更新面向企业管理员。

Cursor 允许管理员按模型和 provider 设置更细粒度的白名单和黑名单，可以限制长上下文模型、高成本模型的使用范围，也可以默认屏蔽新上线的 provider 或模型版本。

同一天上了 spend management 和 usage analytics：管理员设软性用量上限，50%、80%、100% 三个节点自动提醒；使用分析可以按客户端、Cloud Agents、自动化任务、Bugbot、安全审查等维度拆分。

这些功能回答的是企业真正在意的事：哪些模型可以接触公司代码？成本怎么控？谁用了多少 Cloud Agent 额度？各个功能面各花了多少？

到这一步，Cursor 的 Agent 已经不只是个人开发工具，而是在往企业可管控的 agent 平台走。

六层栈

把这周的更新和稍早发布的 Cursor SDK 放在一起看，Cursor 正在形成一套分层结构：

接口层——IDE、Web、CLI、SDK，四个入口共享同一套 runtime。

规划层——生成计划、拆解任务、分析依赖、决定并行还是串行。

执行层——async subagents、/multitask、Cloud Agents、本地 Agent。

上下文层——代码库索引、语义搜索、grep、Context Usage Breakdown。

工具层——MCP 接外部工具、skills 定义可复用能力、hooks 控制 Agent 行为、subagent 做角色分工。

治理层——模型白名单、provider 黑名单、用量控制、使用分析。

六层叠起来，已经不是”编辑器加了几个 AI 功能”能概括的。更准确的说法是 coding-agent runtime——一个专门跑代码类 Agent 的运行环境。

和通用 Agent 框架走的是两条路

LangChain、CrewAI 这类框架做通用 Agent 编排，开发者自己定义工具、上下文、流程。Cursor 直接嵌在软件工程的日常场景里。

通用框架需要自己接文件系统、代码检索、版本控制；Cursor 天然就在代码库里，知道 git 状态、知道 diff、知道 PR 结构。通用框架的输出是文本或工具调用结果；Cursor 的输出是代码改动、branch、PR、review comment。

优势不在开放性，在场景深度。通用框架适合从零搭 Agent，Cursor 适合在已有开发流程里直接嵌入 Agent 能力。

这一周的 Cursor 更新，单拎出来每个都不算大新闻。拼在一起，指向同一件事：coding agent 的竞争正在从”能不能写对代码”转向”能不能组织复杂工程变更”。Cursor 押的就是后者。