2026 年 9 月 10 日，Cursor 在官方博客《Introducing Projects》和 Changelog 同步宣布：Projects 以 beta 形式向所有用户推出。它面向的不是再开一轮聊天，而是一次会跨多个 PR、持续数周甚至数月的工作——做一个功能、完成一次迁移，或者把整套应用交给 Agent 体系推进。官方写明，Projects 会长期保留上下文，把任务委派给上千个子 Agent，并在你没有每次提示的情况下处理周期性工作。
卡住长任务的，通常不是模型写不出第一段代码，而是每次新开 Agent 都要重新交代仓库结构、测试方法和你的偏好。Cursor 把工作单位从一次聊天上移到一个 Project：你从左侧导航进入，主要对话对象变成协调器。协调器自己不写代码，只做计划、委派，再把完成的工作交回给你检查。
本文只讨论这一次发布：一个会活过单次会话的功能或迁移，接到 Projects 之后，改的是哪一步，以及人还必须守住哪里。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
协调器把“管 Agent”收成一层
Cursor 把 Projects 写成它在 2 月提出的“软件开发第三阶段”的具体落地：由一队 Agent 承接整块工作，而不是开发者亲手调度每一个会话。你监督一个 Project 的方式，是和它的协调器聊天。官方强调，协调器因为只委派、不亲自执行，所以不会被单次实现任务堵住，可以持续接收方向；它会按工作需要创建并管理 Agent，并行数量由任务本身决定。
官方把这件事拆成三项能力。第一，默认跑在云端计算机上，合上笔记本也不会停；这样可以并行的子 Agent 数量，不再受你这台笔记本限制。当某一步必须在本机验证时，协调器会再拉起一个本地 Agent 去跑。第二，每个 Project 维护一组会在所有云端和本地机器之间同步的文件。Agent 会往里面追加调研、产物，以及它们对代码库和你偏好的理解；官方举例：如果一个 Agent 搞清楚了某个服务怎么测，后面的 Agent 可以直接用这份说明。第三，协调器可以订阅信号：看一个 Slack 频道、按计划运行，或跟踪你的全部 PR，在 PR 打开或合并时修 CI、采取动作，而不必等你再提示一次。
一个功能怎样从调研走到上线后的值守
把一次真实功能接到这条路上，顺序是清楚的。工程师先为这块工作新建 Project，Agent 先调研系统并把学到的内容写成共享上下文；协调器再出计划，把实现和测试拆开，派不同 Agent 并行做。你每轮反馈，Project 都会记下架构和偏好。功能可以试用时，协调器能在你的电脑上启动 Agent 做本地验证。上线之后，同一个 Project 还可以继续看日志、接缺陷，并且带着当初那些决策上下文，而不是另开一个失忆的会话。
Changelog 把入口写得很短：从左侧导航打开 Projects，描述你要做成什么，协调器接着往下做。它明确说，更适合会活过单次聊天的工作，比如带多个 PR 的功能、一次迁移，或你不在时也希望有人接着处理的任务。Slack 的例子同样具体：把协调器连到缺陷反馈频道后，每来一个缺陷，它就开始委派，而不是等你把工单再粘贴进对话框。
它改变的是工作单位，不是又加长一次对话
如果只把它理解成“上下文窗口更大的 Chat”，会漏掉官方真正改的那一层。以前一次云端 Agent 会话结束，下一次仍要重新交代约束；Projects 把这些约束写成会生长的共享文件，并让协调器而不是你去创建子 Agent。对迁移尤其明显：官方说这类工作容易开头、难收尾，Cursor 内部用它做过跨几百个 PR 的框架替换和样式系统替换。你先和协调器确认一套安全做法，再让它按这套做法在代码库里增量推进；前期你仔细看每个 PR，后面修复站得住了，你就少看，协调器继续把迁移做完。
另一类是永远做不完的“园艺”工作，比如维持代码质量或盯回归。官方写到，一位工程师用设计系统 Project 走这条路：一开始人工审每一处修复并纠正错误；现在协调器会扫描每个新 PR，把属于设计系统的组件抽出来，并在同一类错误出现第二次时补一条 lint 规则。这个 Project 的节奏是每天触及 20 到 100 个 PR，所以协调器负责组织，工程师只在需要注意力的地方介入。这和“再问一次 Agent 帮我改个文件”不是同一条工作流。
还不能把它当成已经替你做完验收的团队
先看状态。Projects 是 beta，官方写的是从当天起向所有用户滚动放出，并不等于每个账号、每个仓库都已经看到完整能力。入口在左侧导航，但具体滚动到你的时间，仍以产品实际放出为准。
再看证据边界。Cursor 称内部已用 Projects 数月，做过几百个 PR 的迁移、设计系统一致性，以及把 Projects 自己做出来；同时给出一组公司自述数据：新用户合并 PR 增加 30%，主要使用 Projects 的用户合并数量达到六倍。这是官方博客里的产品方数据，不是第三方审计，也不能直接外推到你的仓库规模、审查制度和发布节奏。协调器“自己不写代码”也不等于结果已经正确：实现仍由子 Agent 完成，PR、CI 和线上回归还是要人看。
最后看相邻能力，避免拼盘。9 月 2 日 Changelog 里的 Self-hosted machines，讲的是把工具执行留在你自己的网络，和这次“以 Project 为工作单位调度云端子 Agent”不是同一件事。订阅 Slack、日程和 PR 是 Projects 的一部分，但官方没有说它能替代值班、事故响应或发布审批。试用时应用一块会活过单次聊天的真实工作，而不是把一次性改文件硬塞进 Project 里看热闹。
信息来源
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。
如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。
值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
