抽象层级往上抬了一格
据 Cursor 官方博客，Projects 于 9 月 10 日发布并进入 beta，开始向所有付费用户逐步开放。官方对它的定位是「承接更大规模的工作」——一项功能、一次迁移，或一个完整的应用，并且能在长达数月的工作中维持上下文，向成千上万个派生智能体委派任务，还能在没有提示的情况下自动完成周期性工作。
值得注意的是官方给出的自我定位：Projects 不是「更强的编辑器」，而是把开发者从「管理智能体」的位置挪到「指挥工作」的位置。这个说法对应一个具体的变化——过去开发者本身就是那个循环，负责在智能体跑偏时把它拉回来；在 Projects 里，协调智能体承担了这个循环。
截至目前，Projects 的云算力计费细则、不同档位下的并发上限与配额规则，官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
三项机制
据官方说明，让 Projects 成立的是三件事。
默认云端执行，需要时切回本地。每个 Project 运行在自己的云端机器上，因此合上笔记本不会中断工作。这也解释了它为什么能并行运行远超本地承载能力的子智能体：子智能体在隔离环境中启动，各自持有干净的上下文，互不干扰。当某项工作需要在开发者本机验证时，协调智能体会启动一个本地智能体来完成。
共享上下文。官方描述的做法是：每个 Project 维护一组文件，并在其智能体使用的所有云端与本地机器之间同步。智能体会持续补充研究成果、产出物、对代码库的理解以及开发者偏好的工作方式。官方举的例子很具体——某个智能体弄清了如何测试某项服务之后，后续每个智能体都能直接沿用这份说明。这个设计的实质是把「重新交代背景」这件事从人的工作变成了系统的状态。
订阅式触发。协调智能体可以监听 Slack 频道、按计划运行，或跟踪开发者的 PR，在 PR 打开或合并时修复 CI 并采取行动。官方的说明是它会根据检测到的信号主动行动，不需要等待提示。据第三方拆解，这套能力建立在 Cursor 今年早前推出的 Automations 系统之上，被接入了协调者模型。
六倍这个数字应该怎么读
官方公布了两组数据：尝试使用 Projects 的新用户，合并 PR 数量提升 30%；以 Projects 为主要工作方式的用户，合并量达到原先的六倍。
这两组数字需要用谨慎的方式理解。据第三方分析，Cursor 没有公布队列规模、基线定义与时间窗口，因此它们更适合作为方向性信号而非基准成绩。官方自身也给出了限定：六倍这一数字来自已经接受该工作流的用户，收益会随使用深度增加而放大。更关键的是，六倍这个数字真正的含义可能不在效率，而在瓶颈转移——如果智能体开出的 PR 数量变成六倍，团队的限制因素就从「写代码」变成了「审代码」，人类注意力而非实现吞吐量成为约束。这一点在引入任何高并发编程智能体时都成立，值得提前规划评审能力。
官方同时公开了适用场景：功能开发、代码迁移与持续维护。其中迁移被描述为最契合的场景——框架升级或全系统重构往往横跨数百个 PR，协调者可以起草迁移方案、并行运行智能体、逐步验证，并把每个失败的测试当作调整信号。反之，对于快速、定义明确的任务，搭建协调者的开销并不划算；官方推荐的判断标准是「以天或周计的工作，而不是以小时计的工作」。
一个刻意保留的边界
据第三方分析指出，Projects 有一个值得注意的设计选择：协调者把工作带回给开发者审批，不会自主推送到主干分支。这不是技术限制，而是信任决策。官方在发布说明中也明确提示，使用前需要具备可靠的 CI、扎实的代码审查实践与良好的可观测性作为前提。
这个提示对应的风险是真实的：协调者模式会同时放大正确的工作与错误的判断。规划阶段的一个小误解，可能在几十次子智能体运行之后才被发现。官方对迁移场景的建议是，早期人工审查要更密集，等方案成熟后协调者再接手更多环节。换句话说，Projects 并没有取消人的责任，只是把人的介入点从「每一步」上移到「方案与结果」。
另一条路线：把轨迹摊开给人看
值得对照的是，在云端协调者模式扩张的同时，GitHub 上在 9 月初集中出现了一批走相反方向的框架，强调「本地优先」与「可审计」。
据公开整理，9router-framework 于 9 月 8 日发布，定位是 TypeScript 优先的实验性框架，提供类型化智能体定义、并发运行、子智能体、插件系统与本地运行时，底层使用 Elixir 与 OTP 语义内核，并提供三种起步模板：用于单一有状态智能体的 basic、用于父智能体创建并询问工作智能体的 coordinator、以及用于同一套定义多实例的 world。Native 框架的核心主张是「运行轨迹优先于摘要」——每次工具调用的参数、耗时与原始结果都在屏幕上可见，生成的文件从磁盘重新打开验证，而不是依赖代码中的描述。Nexora 则主打自托管与 MIT 许可，支持约 90 种工具与 46 家模型提供商。此外，本栏目此前报道过的 9Router 本地网关走的也是同一思路，其 RTK 工具输出压缩在实测中把工具载荷 token 降低约 25% 至 35%。
两条路线的差别不在「云还是本地」，而在信任建立方式。云端协调者模式靠能力与规模换取信任，前提是配套的评审与可观测性；本地优先路线靠可见性与可复现换取信任，代价是规模与便利性受限。据公开整理的观点，在云端平台里用户通常只能看到最终输出，中间过程被抽象为黑箱；而本地优先框架把轨迹放在可见位置，用户可以在执行过程中介入，而不是等到任务结束后才发现问题。对处理敏感数据或执行关键操作的场景，可审计的运行轨迹是建立信任的基础。
一个现实的判断是：这两条路线大概率不会互相取代，而是按任务性质分工——大规模、可并行、结果可验证的工作适合协调者模式，涉及密钥、生产环境与合规边界的工作更适合本地优先。真正需要警惕的是把两者混用却不补齐各自缺失的那一半：用协调者的规模去跑高风险任务，却没有本地路线那样的可见性。
中立思辨
需要辩证看待。其一，六倍与 30% 两个数字缺乏队列规模、基线与时间窗说明，官方也承认六倍来自已接受该工作流的用户，属于自我选择样本，不宜作为通用预期。其二，云算力成本未公开，而并行子智能体的计费速度快、消耗规模大，据第三方建议，启用前应先设置消费上限，并从非关键项目开始试点。其三，规划层的错误会被放大，这是协调者架构的内生特性，缓解手段是工程实践而非产品功能，团队如果 CI 与评审不健全，收益会被抵消。其四，共享上下文在提升效率的同时也引入污染风险——一份错误的理解会被后续所有子智能体沿用，目前公开材料未说明这份上下文是否有版本管理与纠错机制。其五，订阅式触发让智能体可以在无人提示时行动，便利性与可预测性之间存在张力，需要明确哪些动作允许自动执行、哪些必须等待确认。其六，本地优先路线虽然强调可审计，但工具链成熟度、生态规模与团队协作能力通常弱于商业平台，迁移成本不低。其七，「第三时代」这类叙事带有明确的商业立场，评估时应回到可验证的能力与约束条件。
趋势研判
短期，编程智能体的竞争会集中在「长周期任务的上下文维持」与「大规模并行的成本控制」两点上，协调者模式会成为主流产品的默认形态；中期，团队的组织方式可能随之调整，评审、CI 与可观测性从「工程规范」升级为「智能体能否规模使用的前置条件」，评审工程师的价值会上升；长期，如果协调者模式被证明在数月周期内稳定可用，软件交付的计量单位可能从「人月」转向「可验证的任务批次」，而人的角色会集中在定义目标、设定边界与验收结果。
对准备引入这类工具的团队来说，一个务实的起步动作是：先统计当前 PR 的评审吞吐量与平均滞留时间。如果评审环节已经在排队，那么把编码产能再放大数倍，带来的不会是交付加速，而是更长的队列。