Cursor 这次发布 Projects 时，抛出了一句话很容易让人上头，协调者可以指挥数千个子 Agent。

我第一反应不是「终于不用写代码了」，而是另一件更扫兴的事。一个人 review 三个 PR 都会漏细节，把一千个会改代码的 Agent 放进同一个仓库，谁来决定它们该改什么、不能改什么、改坏了怎么停？

这不是 Agent 数量的问题。

这是软件工程开始从「写出一个改动」转向「治理一群持续制造改动的执行者」。

9 月 10 日，Cursor 发布 beta 版 Projects。官方给它的定位不是一次聊天，也不只是 Cloud Agent 的并发开关，而是一个能跨月保持上下文、派发子任务、在没有新 Prompt 时继续处理工作的项目单元。它能跑在独立机器上，可以关注 Slack、PR 和定时任务。Cursor 还给出一组很亮眼的内部数据，新用户合并 PR 的数量提高 30%，主要使用 Projects 的人达到六倍。数据来自厂商自身，样本口径和因果关系都还没有公开，所以把它当成方向信号比当成生产力定理更合适。

但产品形态值得认真看。它踩到的不是「更强的代码补全」，而是一个多数团队迟早会碰到的硬问题，长周期、跨仓库、要持续收尾的工程工作，到底怎么交给 Agent。

Cursor 卖的不是并发，是一条不断续上的工作线

很多人可能有过这个体验。你让 Agent 做一个 Spring Boot 模块改造，开局很猛，十分钟以后它开始问「这个 DTO 为什么这么设计」。你把上下文补齐，第二天换一个会话，又得从头解释模块边界、灰度策略、测试命令和那条谁都不敢碰的兼容逻辑。

短对话很适合解决局部问题。长工程不是。

Cursor 对 Projects 的设计有三个部件。协调者负责接收目标、拆解工作、盯住状态，但自己不写代码。子 Agent 在云端或本地机器执行研究、修改和测试。第三部分是一组项目级共享文件，记录研究材料、产物、代码库认知以及用户偏好，并同步给后续的 Agent。

这个结构看起来朴素，甚至有点像一个项目经理加一堆执行同学。可它解决了单 Agent 最别扭的地方，执行者每次醒来都像刚入职，最贵的并非生成代码的 token，而是重新理解「这家公司为什么这么干」。

从 LangGraph 或传统工作流的视角看，Projects 并不是神秘的新范式。协调者像一个 Planner，子 Agent 像并行 Worker，共享上下文像带版本的项目状态，Slack、CI、PR 则是触发器。区别在于它把这套结构做成了开发者能直接使用的产品，而且把状态留得足够久。

状态能留下来，责任才有地方落。

对 Java 和 Spring 团队，这种长记忆尤其有价值。一个看似简单的依赖升级，往往同时牵动 BOM、Spring Cloud 兼容矩阵、容器镜像、启动参数、集成测试和线上可观测性。让五十个 Agent 同时改五十个服务并不难。难的是让每一个 Agent 知道，哪些接口是外部契约，哪些 migration 已经做过，哪些失败可以自动重试，哪些失败必须停下来等人。

三种适合交给项目 Agent 的活，不是一堆模糊需求

Cursor 自己列了 feature work、migrations 和 gardening 三个模式。我觉得这个分类挺诚实，因为它没有把「任何需求」都塞进去。

功能开发，先让 Agent 研究，再让它写

一个跨多个 PR 的功能，第一步不该是让 Agent 直接动手。更靠谱的顺序是让它产出当前架构地图、调用链、风险点和验收清单，把这些东西放到共享上下文里，再拆成可以并行的实现与测试任务。

你想想看，如果一个 Agent 负责订单领域模型，另一个 Agent 同时改库存扣减，它们都各自「合理地」引入了事件。没有明确的幂等键、事件顺序和回滚策略，代码都能通过 CI，业务还是会在峰值时给你一记闷棍。

所以 feature Project 的交付物不该只有代码。至少还该有这几样东西。

  • 架构决策记录，写清接口边界、不可变约束和被排除的方案
  • 可执行的验收场景，尤其是失败路径与回滚路径
  • 任务依赖图，标明哪些 PR 可以并行，哪些必须按序
  • 每个 Agent 的权限范围，例如只能改一个 Gradle module，不能碰生产配置

很多团队会嫌这套东西慢。这个担心很合理。两小时能做完的小修复，写一堆项目文件反而是仪式感过剩。Projects 的价值出现在工作会活过一次会话、牵动多处边界，并且未来还会回头维护的时候。

回到主线，Agent 规模化的前提不是更大胆地下指令，而是更严格地定义工作单元。

大规模迁移，机器擅长重复，人要守住第一批样本

Cursor 提到它们用 Projects 做过几百个 PR 的框架迁移和样式系统替换。这个场景确实很对 Agent 的胃口。迁移通常有明确规则、大量重复和长尾异常，恰好不适合工程师日复一日机械点击。

但这里最容易犯的错，是把第一批迁移成功误判为已经自动化成功。

我自己的感受是，迁移项目最该重视的不是吞吐量，而是「规则何时算被证实」。比如把 Spring MVC 的某种拦截器迁到新的安全链路，开始只放行十个服务。每个 PR 都要有人看 diff、跑回归、看指标。等十个服务的异常样本已经被吸进规则库，才扩到五十个。

这很像制造业里的首件检验。机器可以把一万件产品做得很快，但模具歪了一毫米，产量越高，损失越大。

一个可以落地的迁移闸门大概是这样。

1
2
发现模式 → 生成小批候选 PR → 人工 review → 跑契约与回归测试
→ 观察预发指标 → 固化规则与反例 → 扩大批次

关键在「反例」。Agent 最需要的往往不是成功样本，而是那几种不能套规则的服务。旧系统里总有几个接口把鉴权、缓存和事务塞在一个类里，文档也没写。说实话我也不确定任何产品能自动识别所有这种历史债，但项目上下文至少能让你把踩过的坑留下来，不必让下一个 Agent 再踩一次。

Gardening，最诱人，也最需要刹车

Cursor 的第三个例子叫 gardening。协调者可以盯 PR、接 Slack 报错、按计划巡检，还能在发现同一种问题第二次出现时补一条 lint rule。官方给出的案例里，这个 Project 预计每天触达 20 到 100 个 PR。

这段最让我兴奋，也最让我警惕。

因为从这里开始，Agent 不再等你分派任务，而是在组织的信号流里主动行动。CI 红了、线上日志出现新模式、PR 违反设计系统，这些事情都可以成为触发器。工程流程会从人发起、机器辅助，慢慢变成机器发现、人类裁决。

问题是，自动修 CI 和自动修改业务代码不是同一个风险等级。前者可以限定为格式、锁文件、已知 flaky test 的重跑。后者可能改变金额计算、权限校验或数据删除。触发器越自动，停机开关越应该靠前。

不是说 Agent 不行，而是说它不该拿到超过证据强度的权限。

我会把 gardening 的动作分成三层。低风险动作可以自动执行，例如补充格式化、创建 issue、重跑允许重试的测试。中风险动作可以自动提 PR，但必须带上变更理由、影响范围、测试结果和回滚建议。高风险动作只能生成诊断报告，涉及权限、支付、数据迁移、生产配置和外部副作用时，一律由人确认。

这话听着有点保守，但一条错误的自动修复规则，足够让一百个 PR 同时带病前进。Agent 把速度提上去以后，护栏不能还停在手工时代。

真正要管理的是上下文，不是 Prompt

现在很多 Agent 实践仍然围着 Prompt 打转，系统提示词写得很长，角色很多，输出格式也很整齐。可一旦任务跨过几天，真正决定质量的不是开头那段漂亮 Prompt，而是项目状态有没有被维护好。

Cursor 的共享文件思路，恰好点中了这件事。对一个工程 Project 来说，我建议把上下文拆成四类，而不是堆成一篇永远增长的说明书。

宪法文件，哪些东西绝不能碰

这里放业务不变量、兼容性承诺、数据安全边界、部署限制和代码所有权。它应该短、稳定、可被每次任务引用。

例如「退款状态只能单向迁移」「外部 REST API 不允许改字段语义」「数据库变更必须可回滚」。这些内容不属于某一个 PR，却决定每一个 PR 的生死。

当前地图，系统现在长什么样

模块依赖、关键调用链、环境差异、测试入口都放在这里。它要随项目变化更新，并且允许标记置信度。某条链路是从代码静态分析得出，还是已经在预发验证过，差别很大。

可能有小伙伴纳闷，为什么不把整个仓库都塞进 Context。因为无差别的上下文会制造一种很危险的错觉，Agent 看过很多字，就等于理解系统。其实吧，它更需要少量、可信、能指导决策的结构化信息。

工作日志，为什么当时这么选

这是 ADR、失败实验、线上事故摘要和 review 结论的归处。它不必写成长篇复盘，但要留下决策背景。半年后一个 Agent 建议把某段看起来多余的代码删掉，日志能告诉它，这段代码当初是为了绕过某个 JDBC 驱动的边界行为。

人会忘，Agent 更不会凭空记得。

可执行证据，怎么证明它没有乱改

测试命令、测试数据、验收脚本、Dashboards 的观察项、回滚操作放在这里。若一个 Agent 不能拿出可以复跑的证据，它的结论就只能算建议，不能算完成。

这四类文件并不新潮。成熟团队一直在做，只是以前靠 Tech Lead、Wiki、口口相传和一堆过期文档维持。Projects 把它们变成 Agent 的工作记忆，反而逼着团队把模糊经验写成可核验的规则。这是它最现实的价值。

协调者不写代码，可能是一个很好的克制

Cursor 明确说协调者不写代码，只指挥其他 Agent。我挺认同这个取舍。

如果协调者既做计划、又亲自改代码、还负责验收，它很容易在自己的局部实现里越陷越深。任务一多，它不是项目经理，而是一个不停切换窗口的高级 Worker。把执行和调度拆开，协调者才能保持对依赖、风险和优先级的注意力。

当然，架构图好看不等于系统就可靠。协调者是否真的能正确拆任务，子 Agent 的隔离程度如何，冲突怎么处理，失败任务会不会反复消耗资源，官方文章没有展开。所谓「数千个 Agent」也还需要更多公开的故障案例和真实用户数据来检验。

beta 阶段尤其要保留这份怀疑。

很多 Agent 产品的演示喜欢展示从一句需求到完整应用。现实工程里，更有价值的画面可能是协调者停下来，说「这个任务触及生产数据迁移，现有证据不足，需要人类确认」。能停住，才有资格跑得久。

给团队的一个起步方式

如果你正做 Java、Spring 或 AI Agent 工程，我不建议明天就开一个 Project，把全仓库交出去。可以从一个边界窄、收益清楚、失败可控的任务开始，比如统一补 OpenAPI 文档、清理废弃 feature flag、把一类重复的 CI 问题变成规则，或者为一批服务补健康检查契约测试。

起步时只做五件事。

  • 选一个可回滚、没有生产副作用的工作单元
  • 写出不变量和禁止修改区，控制在一页内
  • 用 5 到 10 个样本跑小批量，逐个 review
  • 把每次误判写成反例，不只记录成功经验
  • 给自动动作设预算、速率限制和一键暂停

反正我觉得，最稀缺的不是能同时运行多少个 Agent，而是团队能否把判断标准沉淀下来。没有这层东西，数千个 Agent 只是把混乱放大数千倍。有了它们，Agent 才可能从偶尔好用的结对程序员，变成可长期协作的工程成员。

那句「数千个 Agent」最终会不会成真，没那么重要。重要的是，下一次你面对一个跨月的迁移、一个永远修不完的 CI、一个越做越大的服务集群时，项目有没有留下足够清楚的记忆和护栏。

别让它们只会往前跑。

参考资料