Cursor 3：并行代理开启 AI 编码新纪元

Cursor 3 有哪些新变化？

3.0 版本在基础设施上的投入多于 UI 打磨。以下是实际改变之处。

统一的代理工作区

所有代理活动现在都集中在一个界面中。侧边栏显示当前在您机器或云端运行的每个代理，包括从 Slack、GitHub、Linear、移动端和网页触发的任务。一个视图全览。

该工作区从设计上就是多仓库的。一个代理可以更新前端组件，另一个同时修补后端库。在 Cursor 3 之前，这需要单独的 IDE 窗口和不停的上下文切换。

两个值得一提的新增项：代理标签页允许并排或网格查看多个代理对话。代理对话现在也是标准的编辑器标签页，因此分屏和键盘快捷键按预期工作。无需重新学习。设计模式在下文单设小节。

并行运行多个代理

/best-of-n 命令在 IDE 内的代理聊天中运行，而非在“代理窗口”。使用方法：打开一个 Git 仓库，在经典编辑器布局中打开代理聊天，并运行 /best-of-n，后接以逗号分隔的模型列表和您的任务。例如： /best-of-n sonnet, gpt, composer fix the flaky logout test。

Cursor 会为每个模型创建一个独立的 Git 工作树，以避免互相干扰。作业完成后，您可以审阅输出、在所选工作树中提交和推送，或运行 /apply-worktree 将更改带回主工作副本。您还可以通过 .cursor/worktrees.json 按项目自定义工作树设置。

Cursor 现在将多模型并行运行引导至 IDE 代理聊天中的 /best-of-n，而较旧的选择流程不再是推荐路径。

/worktree 命令遵循相同路径：IDE 代理聊天、需要 Git 仓库、每个代理使用隔离的工作树。

“最佳”选择反映的是 Cursor 的评估启发式，而不一定是您的判断。请自行阅读输出。

一个实用提示：每次模型运行都会按其正常的 token 费率独立计费，没有捆绑折扣。三种模型就意味着三笔单独收费。稍后我会更详细介绍积分体系。

本地与云端代理的接力

云端代理运行在隔离的 Ubuntu 虚拟机上。接力可以双向进行。

从云端切回本地，可访问您的文件系统、本地开发服务器和桌面测试工具。将会话推送到云端，则可以让长时间运行的任务在您合上笔记本后继续执行。代理完成后，结果会在“代理窗口”等待。云端代理还能生成演示和工作截图，您可在拉回本地前先行审核。

代理会话在本地与云端间双向流转。图片作者自制。

面向企业团队，自托管云端代理已于 2026 年 3 月 25 日推出。代码、工具执行和构建产物都保留在您自有基础设施内。一个 worker 进程通过 HTTPS 出站连接到 Cursor 云，无需入站端口或 VPN。自托管代理在 Enterprise 方案；标准云代理在 Pro 及以上可用。

您可以在仓库根目录用 .cursor/environment.json 定义云端环境。机密请存放在 Cursor 设置的 Secrets 标签页，而不是该文件中。

从提交到拉取请求的一体化流程

新的差异对比界面支持查看词级变更、暂存提交，并在不离开“代理窗口”的情况下发起拉取请求。3.0 中大文件差异渲染更快、更省内存。

当您在经典编辑器中使用 /worktree 时，每个代理在其各自的隔离工作树中进行修改，因此当您开始评审时，差异已经是干净分离的。无需解开重叠更改。

Cursor 还在 2025 年 12 月 18 日宣布签署收购拉取请求管理工具 Graphite 的最终协议。我本来差点不写这条，因为集成细节尚未确定，但一旦交易完成，这项收购可能会重塑该工作流。

设计模式与集成浏览器

用文字描述 UI 变化不如直接指给它看。设计模式解决了这个问题。

按 Cmd+Shift+D 可在集成浏览器上激活选择工具。使用 Shift+drag 选择区域，Cmd+L 将选中元素注入代理聊天，或用 Option+click 将其添加到输入框。代理会接收 HTML、应用后的 CSS，以及可视边界框。与其写一段话描述布局问题，不如选中元素然后说“收紧一下”。

该浏览器还集成了 Chrome DevTools。代理可以启动本地开发服务器、点击按钮、读取控制台日志，并验证更改是否真正生效。

Composer 2：Cursor 内置的编码模型

Composer 2 于 2026 年 3 月 19 日发布，比 Cursor 3 早两周。它是新工作区中驱动代理的模型。

它基于 Moonshot AI 的 Kimi K2.5 做持续预训练，并在其上进行了 4 倍规模的强化学习。Cursor 并未在发布时披露基座模型。第二天有用户在 API 头信息中发现了它。联合创始人Aman Sanger 承认了这一疏漏：“在博客一开始没有提及 Kimi 基座是我们的失误。下一个模型我们会改正。”

如果您对基准分数不感兴趣，简短结论是：Composer 2 比第三方替代品更快更便宜。可直接跳到下方价格表。

在 Cursor 自有的 CursorBench 上，Composer 2 得分 61.3，对比 Composer 1.5 的 44.2，约 39% 的提升。其生成速率超过每秒 200 个 token，部分得益于 Cursor 自研的 GPU 内核，而非完全依赖第三方推理栈。CursorBench 未经独立审计，解读这些数字需带着这一点。GPT-5.4 在更难的任务上更胜一筹，但在 CursorBench 的工作集（平均 8 个文件共 352 行）上，Composer 2 以大约低 90% 的每 token 成本优于 Claude Opus 4.6。成本差距更值得关注。

以下是价格细分n:

在个人付费方案中，Composer 2 有独立于手动选择前沿模型的积分池。它按消费计费，而不是按请求计费。完整的积分说明见下方定价部分。该模型有 200,000 token 的上下文窗口，并具备自我摘要：当上下文填满时，会压缩到约 1,000 token 后继续。

Composer 2 专为代理式编码而建。除此之外的用途，它帮不上忙。

将 Cursor 3 作为以代理为先的开发环境

Cursor CEO Michael Truell 将 AI 软件开发划分为三个阶段。首先是 Tab 自动补全，用于填充重复代码。然后是同步代理，逐步指挥模型。现在是云端代理在更长时间尺度上自主运行，开发者从写作者转为导演。

使用数据也反映了这种转变。如前所述，代理与 Tab 的比例在 2025 年初到 2026 年初之间翻转。

Truell 的表述是：“Cursor 不再主要是为了写代码。它是为了帮助开发者搭建生产他们软件的工厂。”这是一句愿景陈述，而非产品描述。现在大多数使用 Cursor 3 的开发者仍在不断审阅和修正代理输出。我还没见过哪个代码库能自己跑起这座“工厂”。但这个界面建立的前提是：那一天可能比听起来更近。

延续并改进的关键特性

早期版本的核心功能仍然在，并且基本未变。

文件与代码理解

完整的 LSP（语言服务器协议）支持仍然存在。转到定义、符号搜索、悬停文档和文件导航等功能与 VS Code 中一致。支持 @Files、@Folders 和 @Docs 等上下文引用。“代理窗口”并未移除文件级访问；它是在其之上增加了一层。

Cursor 市场与插件

Cursor 市场通过一键安装插件来扩展代理能力。插件打包了技能（代理可按需调用的提示）、子代理、MCP 服务器、钩子和规则的某种组合。完整说明见Cursor 文档。

可用插件覆盖广泛：AWS、Figma、Linear、Stripe、Vercel、Datadog、Snowflake 等。Teams 和 Enterprise 方案可设置私有团队市场。对 Enterprise，第三方插件导入默认关闭，需管理员开启。

一个本不该存在的缺口：目前没有内置 UI 来为市场插件的 MCP 服务器设置环境变量。变通方法是将服务器手动添加到 ~/.cursor/mcp.json 中，带上 env 字段，并在 Cursor 设置中禁用重复条目。虽然可行，但这是付费产品中不该需要的变通操作。

Automations（自动化）

Automations 于 2026 年 3 月 5 日发布，是由外部事件触发的常驻代理：计划任务、Slack 消息、Linear 问题、GitHub 事件和 PagerDuty 告警。代理会启动一个云端沙箱，并使用已配置的 MCP 和模型按指令执行。开启记忆后，代理可访问持久化记事本（如 MEMORIES.md 这类在运行间保留的小文本文件）。写什么由代理决定：进度、发现的模式、前次运行的上下文。下一次运行会读取这些笔记并从此接续。您可以在控制台的 Automations 部分查看和编辑这些文件。

Cursor 3 的定价与方案要求

并非所有功能在每个方案上都可用。以下为当前划分：

云端代理和 Composer 2 需要 Pro 或以上。团队市场需要 Teams 或 Enterprise，自托管云端代理仅限 Enterprise。

Cursor 在个人付费方案上运行两套独立的积分池：一套用于 Auto 模式和 Composer 的使用，Cursor 将其描述为“宽松”，但未公布上限；另一套用于手动选择的前沿模型，如 Claude 或 GPT。您手动选择模型时，会从该积分池中扣减；Auto 模式不会。

给重度用户的提示：在 Pro 方案下频繁运行代理会话的开发者反馈，一旦超量计费开始，实际月花费更接近 $40 至 $50。$20 只是下限。

Cursor 3 如何改变开发者的工作流

以下是一个标准后端 API 任务的具体对比：

转变并不是从“难”到“易”，而是从“写作”到“指挥”。您在实现上的时间更少，在定义需求和审阅输出上的时间更多。这种取舍是否值得，取决于任务本身——老实说也取决于您当天对代理的信任度。

长时间运行的任务受益最大。一个要在终端里花上数小时的重构，可以交给云端代理；您合上电脑，代理继续跑，等您回来时差异就在那里等您审阅。

Cursor 3 与以往版本对比

早期的 Cursor（2022–2024）是一个以 IDE 为先的工具。在 VS Code 环境中进行 AI 辅助的文件编辑。

Cursor 1.0（2025 年 6 月）是首个稳定版。Cursor 2.0（2025 年 10 月）带来了首个 Composer 模型和内置浏览器。Cursor 2.5（2026 年 2 月）增加了异步子代理和插件市场。Cursor 2.6（2026 年 3 月）增加了团队市场。

Cursor 3.0 正式完成了转变。云端代理已完全从编辑器中移出，现仅存在于“代理窗口”。工作树支持也有变化：旧的下拉 UI 被弃用，取而代之的是 /worktree 和 /best-of-n 命令，它们在经典编辑器聊天中运行。如果您有内部文档指导如何使用工作树下拉菜单或在编辑器内启动云端代理，这些内容已过时。

Cursor 利用 3.0 的重构清理了 2.x 的性能负债：内存和 CPU 泄漏修补、React 编译器。Robinson 表示，结果是更快且更少 UI 卡顿。已全面支持 Windows，界面可在单个窗口中管理多个工作区。

从 2.x 到 3.0 的跃迁比表面更具结构性。早期版本是在 IDE 上添加代理功能；Cursor 3 则是在代理平台上添加 IDE。顺序很重要。

Cursor 3 与传统 IDE 对比

传统 IDE 以文件为中心。您打开文件、编辑文本，IDE 帮助您更快输入。即便安装了 GitHub Copilot，这种抽象仍然是文档。

Cursor 3 将文件置于次要位置。主要界面是任务队列。IDE 成为无法用提示准确描述的细化编辑的兜底方案。

不过，比较正在变得更模糊。GitHub Copilot 现在在个人方案层级就提供云端代理和代码评审。JetBrains 在其 AI 订阅中捆绑了自家的自主编码代理 Junie。如前所述，Cursor 现已通过 ACP 在 JetBrains IDE 中运行。大家都有代理了。Cursor 3 的真正不同点在于：它的工作区是围绕代理构建的，而不是给已有编辑器加一个代理功能。

限制与悬而未决的问题

日常体验比发布材料所暗示的更有摩擦。

开发者监督

代理会出错。在复杂的多文件任务上，会频繁出错。审阅代理输出需要对代码库足够熟悉，才能抓住不正确的假设、幻觉出的函数，以及“几乎可用”的逻辑。省下的写作时间转移到了阅读与验证。无法阅读并检查生成代码的开发者，将无法维持代码库的正常工作。这并非对 Cursor 的特定指摘；对所有代理式编码工具都成立。

云端代理的可靠性

环境搭建失败是已知且持续的问题。机密无法在初始设置脚本期间注入，只能在设置完成后。长时间的并行会话会消耗大量资源；一些用户在本应轻松应对的机器上也报告了高内存占用。尽量将会话控制在两小时内，更长任务请添加重建索引的检查点。

另一个具体缺口：规划模式（Plan Mode）尚未在 Cursor 网页端提供。您可以在 Cursor 3 桌面应用中启动并运行包含规划的云端代理，但无法直接在cursor.com/agents 上直接进行。

另有已知缺陷：当“代理窗口”不在焦点时，代理会挂起。该问题在发布后不久被报告，截至 2026 年 4 月上旬仍未解决。对一个以长时会话为核心的工具来说，这是个实打实的问题。

关于并行代理更宏观的一点：Google DeepMind 对多代理系统的研究发现，在非结构化网络中错误会被放大至 17.2 倍。即便单代理可靠性达 99%，串联十个代理后总体可靠性也会降至约 90%。/best-of-n 命令使用隔离工作树，在一定程度上限制了此问题，但并不能消除。

安全性考量

2025 年发现并修复了两个 CVE。CVE-2025-54136（MCPoison）允许已批准的 MCP 工具的命令被静默修改；在 1.3 版中修补。CVE-2025-64106 是一个深链路远程代码执行漏洞，严重性评分 8.8，于两天内修补。Workspace Trust 默认为关闭。如果您在敏感环境中连接 MCP 工具，这一点非常重要。

前文提到的自托管云端代理可以让代理工作留在您的网络内，但 Cursor 平台本身并未提供完整的本地化部署。Cursor 未取得 FedRAMP 或 HIPAA 认证。BAA 的可用性未公开文档说明，因此在依赖其作合规决策前请直接与 Cursor 确认。如果您的环境要求 FedRAMP 或完全本地化部署，Cursor 3 并不适用。

还有两点实用限制：设计模式目前仅在 Chrome 中可用；Firefox 和 Safari 不支持。而在 Cursor 3 发布后的数日内，社区报告了 Composer 2 的 token 消耗对部分用户而言约为正常的 10 倍，关联到缓存读取问题。

积分模型

如在并行代理部分所述，每个 /best-of-n 模型会单独计费。在复杂任务上进行三模型对比，可能在一次会话中就消耗您月度积分池的很大一部分。

谁该使用 Cursor 3？

如果您已经在运行由代理辅助的工作流，并希望一切集中到一个地方，这就是为您打造的。它最适合跨多个仓库协作的团队、可以交给云端处理的长任务，以及需要代码留在自有基础设施内的企业团队。

我不建议初学者使用。不是因为它难用，而是因为代理会产出需要您批判性阅读的代码。如果您分辨不出输出何时有误，就无法修复，六个月后代码库会反映出这一点。对于简单脚本或一次性任务，搭建开销也不值得。如果您的环境受 HIPAA 监管或是隔离网，请在继续前仔细阅读安全性部分。

大型遗留 monorepo 依然是实打实的问题。上下文窗口在它们面前仍会“爆掉”。

与 Cursor 共迎 AI 编码的未来

在 2026 年 2 月，Cursor 发布《走向自动驾驶代码库》，介绍了在大型代码库上编排数千个代理的实验。其目标表述为：“直到代码库能够自动驾驶”。

上下文窗口在大型 monorepo 上仍不堪重负。代理经常产生幻觉。这个愿景还远，不足以据此做规划。

Cursor 3 做的是把关键拼图放到位：有 Composer 2 作为模型，“代理窗口”作为界面，云端虚拟机作为运行时，以及面向企业的自托管选项。自动驾驶代码库依赖于 Cursor 并不完全掌控的模型进步。

Truell 的“工厂”比喻离现实仍有很长距离。就目前而言，您仍然要亲自审阅“工厂车间”。

结论

Cursor 3 的主要变化并不是某个功能，而是界面基于一个不同的假设被重构：代理，而非文件，是工作的基本单元。两年前这还是一个赌注。使用数据表明，这笔赌注正在回报。

它是否适合您的工作流，取决于我在此无法判断的因素：代码库规模、安全需求，以及您能否接受一个刚发布数周、仍有粗糙边角的产品。如果犹豫不决，我建议在做决定前重读“限制”一节。

若想进一步上手 Cursor 的实战用法，我们的《使用 Cursor 进行软件开发》课程涵盖提示编写、重构、测试和代理工作流。