Cursor 推出「Projects」，用来承接更大块的工作——一个功能、一次迁移，或是一个完整应用。它能在几个月的工作里一直保有上下文，把任务委派给上千个子 Agent，而且不用提示也能执行周期性工作。该功能目前处于 beta 阶段，逐步向所有用户开放。

在发布视频中，Cursor 员工 Fredrika Lindh 提到，以前她的工作散在好几个对话（threads）里，现在只有这一个对话，由协调 Agent 来管理这些。另一位员工则表示，告别了一问一答式对话，不用再盯着每个 Agent 逐个指挥，更像和一位自主的同事合作。

协调 Agent 只管规划和委派，自己不写代码

从左侧导航栏就能打开「Projects」，主界面是和协调 Agent 的一个对话。协调 Agent 自己并不编写代码，而是负责规划工作、委派给负责实现的 Agent，并把完成的工作交回给你检查；它会代表你创建和管理 Agent，按需要并行运行任意多个。Fredrika 说，她有些 Projects 里有上千个 Agent，想开就开，没什么限制。

Cursor 此前公开过一次多 Agent 实验：让一群 Agent 只凭一本 835 页的手册，从零重写 SQLite 数据库。其中用 Grok 4.5 模型的那一组，旧版系统跑了两小时，测试通过率一直接近 0，被人工叫停；同一道题换成「负责规划的只拆任务、不写代码」的新分工，四小时通过了约 80% 的测试（实验和数据都由 Cursor 自己设计、统计）。

委派的过程可以看这段录屏：用户新建了一个名为「Tabs」的 Projects，让它弄清一个桌面应用（Grok）的标签页是怎么实现的、结构能怎么改。协调 Agent 说了打算怎么做，随后派出一个子 Agent 去读 Projects 说明文件、翻代码。演示到子 Agent 还在查代码时结束。

协调 Agent 怎么把工作交回给你，可以看发布对谈里演示的另一个 Projects：面板上挂着 64 个 PR（pull request，即一份等着并入主代码的改动，通常要经过审查和检查才会合并进去）。用户问哪些改动小、而且已经能安全并入，协调 Agent 列出几个最接近的候选后说目前一个都还不行——有的落后主干代码（main）太多需要先更新，有的还没证明通过合并前的检查——并建议先处理最接近的那个；用户发来一张所有图标都不显示的截图，它确认问题后说会去排查，把修复交给负责的那个改动，修好前不标记为可合并。

谁来拍板合并：原页写明协调 Agent 会把完成的工作交回给你检查；演示里另一个叫 Browser 的 Projects，备注写着 PR 合并由 Fredrika 本人核对后完成；另一处画面显示，部分审批已经自动通过——安全检查（Security）和代码负责人审批（codeowners）——系统还在等 CI（每次改动后自动跑的测试和构建）和 Bugbot（Cursor 的自动代码审查工具）。演示里也有它等你一句「go」再去合并 PR 的画面；它能不能不经确认自己合并、或设成自动合并，原页和视频都没说。

跑在云端，也能到你电脑上测试

Projects 通过云端 Agent（Cloud Agents）运行：每个 Projects 在云端有一台属于它自己的电脑，所以合上笔记本也不会停。原页还说，Projects 里的 Agent 可能用到多台云端机器和你的本地电脑，共享文件会在它们用到的这些机器之间同步；至于子 Agent 具体跑在哪台机器上，原页没细说。视频里也能看到多台机器配合的痕迹：约 88 秒处的一条回复提到，有一台虚拟机推不上代码，于是把同一个修复交给了另一台已经推送过代码的机器。

当某项任务需要在你的机器上测试时，协调 Agent 会启动一个本地 Agent 在你的电脑上执行。在发布视频中，用户请它在自己电脑上把应用跑起来，好测一下一个已合并的界面改动（「Align More with titles」，让名为 More 的元素和条目标题对齐）；协调 Agent 回复会在她的机器上启动 Glass（从画面看是他们正在开发的应用），让她对照标题检查 More 的位置。

跨机器同步的共享上下文：不再每次重新「带新人」

Cursor 的说法是，不该每开始一个任务，都要重新给 Agent 做一遍「上手介绍」。Projects 的办法是维护一组「共享上下文（Shared context）」文件，在它的 Agent 用到的每台云端和本地机器之间同步。

这组文件里放着三类东西：

• 方案与架构沉淀：例如在「Browser」Projects 的文档目录（Project/docs）下，存放着 Agent 写进去的文档，如 electron-concepts.md 等设计方案；
• 排错与测试说明复用：如果某个 Agent 摸清了如何测试某项服务，之后的每个 Agent 都能直接使用这些说明；
• 偏好与习惯记忆：协调 Agent 会记住你的工作偏好。新建 Tabs Projects 时，协调 Agent 的开场白里就说「随时告诉我换个做法，我会记住」；发布对谈里 Fredrika 提到，PR 一打开，它就已经自己跑完了两个技能：一个做代码简化（simplification），一个叫 Thermos（从画面看会产出审查意见）。这里的技能，指预先写好、能反复调用的一套操作说明（skill）；它会自己去跑，是因为 Fredrika 以前要求过。下面设置订阅的演示里，界面也显示它在编辑 preferences.md。

Cursor 说，共享上下文会随 Projects 一同积累，让协调 Agent 越用越高效。

订阅：交代一次，它按信号和计划自己开工

你告诉协调 Agent 要盯什么以后，它就会根据检测到的信号或按计划自己开工，不用你每次再提示。原页举了三类信号：

• Slack 频道：原页举例，连接 Slack 并将其指向缺陷上报频道后，每当有新缺陷提交，它都会自动开始分派任务；
• 定时计划（cron jobs）：按计划执行周期性工作。例如前面提到的 Browser Projects，设了一个夜里持续运行的任务（merge-readiness watch），每小时检查一次哪些 PR 已经可以合并，发现代码冲突、CI 或 Bugbot 问题就去修；
• 代码仓库的 PR 状态：跟踪你的所有 PR，包括 GitHub 和 Cursor 自家代码托管平台 Origin 上的 PR。

这些订阅与监听如何设置？发布对谈里，员工被问到这个问题时说：没有新手引导，也没有一步步配置的向导，用起来就像普通对话，但规模真的能做上去。

上面的录屏里，用户在「Design System」Projects 里用自然语言输入了一行指令：监听所有合并进来的 PR，检查是否违反了设计系统，比如是不是该换成已有组件、新建一个变体、去掉样式覆盖，或者新增一个组件。协调 Agent 回复会盯着合并并标出这几类问题，界面显示它在编辑 preferences.md，接着出现一个名为「Design system merge watch」的订阅，每小时运行一次。

内部数据和目前还不清楚的地方

在发布视频中，Cursor 员工提到了一些内部数据：他们内部看到使用 Projects 的人每周合并的 PR 约多 6 倍；在开始使用的第一周，合并率上升约 30%。这些数字是员工在视频中的口头说法，原页正文并没有出现；视频未说明对比基准、统计口径、合并率具体指什么，也未说明 30% 是相对增幅还是百分点。

原页正文和视频都没有提到计费方式和用量上限。

Fredrika 提到，这就是他们几个月来的工作方式，Projects 是第一次把它打包得让别人也能轻松用上。