不写代码的「包工头」：Cursor Projects 让一个协调者指挥几千个子智能体

💡 一句话总结：Cursor 9 月 10 日推出的 Projects，把 AI 编程的抽象层级又抬了一层——你不再管理一堆 agent，而是跟一个「包工头」（协调者智能体）对话，它规划工作、派活给几千个并行子智能体、验收后交回给你；项目记忆能攒好几个月，还能自己盯 Slack 和 PR。发布事实清楚，官方效益数据（6 倍 PR）是自报口径，计费方式还没说清。

用 AI 编程工具够久的人，多半体会过一种新型疲惫：开了七八个 agent 会话，这个在跑测试、那个在改一半的分支，你夹在中间当人肉调度器——比亲自写代码还累。工具厂商把这叫「管理 agent 的开销」，而 Cursor 的判断是：这个开销不该由你承担。

9 月 10 日发布的 Projects（beta），就是他们对这个问题的答案。

想看一手资料？

📦 Projects 到底是个什么东西

一句话：项目级的持久工作容器 + 一个不写代码的协调者。

具体分工是这样的：你跟协调者（coordinator agent）聊天，它负责理解需求、拆解计划、创建并管理执行 agent；执行 agent 干活，协调者永不被单个任务卡住，随时能响应你的新指令。工作完成后，它把成果收拢带回给你检查——人保留最终验收的位置，这点和「全自动工程师」类的产品路线有明显区别。

三个关键设计，决定了它和「多开几个 Chat 窗口」不是一回事：

  • 云端优先，本地补位：每个 Project 跑在云端专属的计算机上，合上笔记本它照常干活；需要在你本机跑测试时，协调者会临时拉起一个本地 agent。正因如此，并行的子智能体数量不再受你那台笔记本限制——官方口径是可以支撑数千个。
  • 共享上下文（shared context）：项目内的一组文件在所有云/本地机器之间同步；agent 们沉淀的研究结论、产物、以及「这代码库怎么测、这团队偏好怎么做事」的经验，后来的 agent 直接继承。官方举的例子很形象：某个 agent 摸索出了某个服务的测试方法，之后所有 agent 都会这一手。这份记忆跟着项目走，能积累几个月。
  • 订阅（subscriptions）：协调者可以监听一个 Slack 频道、按计划定时运行、或者跟踪你所有的 PR——bug 报告一进频道它就派活，PR 一开它就盯 CI。不再需要你逐条提示。

官方在博客里给了内部数据：Cursor 团队自己用 Projects 干了几个月的活——数百 PR 的框架迁移、设计系统一致性维护、甚至 Projects 本身就是用 Projects 开发的；新用户合并 PR 数提升 30%，以 Projects 为主力的用户合并 PR 数是 6 倍。这个数字先标记一下：官方自报，没有方法论和样本说明 (uncertain)，方向可以参考，幅度别当承诺。

🔨 三种官方玩法：feature、migration、gardening

比功能列表更有信息量的是 Cursor 工程师们实际怎么用它——三种模式基本覆盖了大头场景：

  • Feature 开发：起步阶段先派 agent 调研系统、把结论写进共享上下文；协调者出计划，并行派 agent 实现和测试；每轮反馈都让项目更懂你的架构和偏好；上线后同一个项目还能继续盯日志、处理 bug 报告——带着当初做决策的完整上下文。
  • Migration（迁移）：官方点名的最佳场景，「容易启动、难收尾」的那类活。先和协调者确定安全方案，再增量铺开到整个代码库；前期你逐个严审 PR，等修复质量稳定了逐步放手，协调者自己把几百个 PR 推完。
  • Gardening（园艺活）：那种永远做不完的维护型工作。团队里一位工程师的设计系统项目，现在每天扫全部新 PR、自动抽取该进设计系统的组件、同一错误出现两次就自动加一条 lint 规则——触达量达到每天 20 到 100 个 PR，工程师只在需要关注的地方介入。

看完这三个模式，你会发现 Projects 的真实定位不是「更强的补全」，而是承接那些寿命超过单次会话的工作——一个带多个 PR 的 feature、一次迁移、一份你出门在外也想让它推进的差事。

⚠️ 兴奋之前，先看这三个坑

把官方叙事放一边，社区里已有的信号值得每个准备重度使用的人掂量。

第一个坑是钱。 子智能体成本失控在 Cursor 论坛不是新话题——早有用户投诉 agent 未经明确同意就启动昂贵的 Task 子智能体、调用高档模型，导致账单飙升、触发用量上限。Projects 把「数千子智能体并行」做成了默认形态，而项目级预算上限、并行计费方式，官方博客一个字没提 (uncertain)。在你搞清楚计费模型之前，先别把公司最大的一次迁移直接丢给它。

第二个坑是自主性的边界。 订阅驱动的「无需提示即行动」（自动修 CI、响应 PR）加上项目级共享上下文的自动传播，意味着一次误动作的影响半径变大了：一条被污染的经验写进共享上下文，后续所有 agent 都会「学会」它。安全社区对多智能体形态的提示注入风险早有预警，Cursor 自己 7 月还披露过恶意克隆仓库触发漏洞、且当时没有对应安全公告的旧账。数千 agent 自主并行，这类风险不是加法而是乘法（这一段是风险评估，非官方结论）。

第三个坑是竞争与依赖。 时间点上有个微妙背景：OpenAI 已宣布因 SpaceX 收购 Cursor 一事，11 月 12 日起终止向其提供模型访问。Cursor CEO 回应称 OpenAI 模型约占其流量 5%、双方正在沟通。在这个节骨眼上推 Projects——一个把价值锚在「平台、上下文、机器编排」而非「模型」上的产品——很难说是巧合。对你而言，项目里积累数月的 shared context 既是生产力也是迁移成本：用得越深，越难走。

另外社区还有零星性能反馈：有用户报告 5 个以上 Projects 并发跑模型时出现系统性性能劣化（单用户报告，官方未回应）(uncertain)。

🧭 把话说明白

收个尾：这次发布里，站得住的部分是产品事实——官方博客和 changelog 双源一致，三大能力描述清晰，自家工程师的使用证言具体到「每天 20–100 个 PR」这种可证伪的细节；有待观察的部分是效益数据（6 倍 PR 无方法论）和成本模型（计费未公布）；需要警惕的部分是自主性扩大后的安全与审计问题。

对不同人的意味也不同：维护着大型遗留系统、常年背迁移任务的团队，Projects 的「先严审后放手」模式几乎是为你们设计的；个人开发者的独立项目，它更像一个「出门也能干活的远程队友」；而预算敏感的团队，建议等官方把计费和预算控制讲清楚再放量——毕竟「包工头」很能干，但工时费怎么算，现在还没贴出来。

参考来源

posted @ 2026-09-11 08:28  Lusca2026  阅读(43)  评论(0)    收藏  举报