拓冰网站定制 
9 月 10 日Cursor 推出新功能 Projects已经进入 beta、逐步向所有用户开放。它想解决的问题很具体一次对话搞不定的活——一个跨多个 PR 的大功能、一次全库迁移或者一个完整应用。官方给了组数据在 Cursor 内部用了一段时间后新用户合并的 PR 数量提升了 30%而主要使用 Projects 的用户合并量达到原来的 6 倍据报道来自官方博客。一、概念其实只有一个加一层抽象Projects 的核心思路不复杂你不再直接跟写代码的 Agent打交道而是跟一个协调者 Agentcoordinator对话。这个协调者自己不写代码只负责拆任务、派活、盯进度。因为它只委派不亲自下场所以它永远不会被某段代码卡住随时能响应你的指令。官方说法里有个数字它可以向成千上万个子 Agent 委派任务并让它们并行跑。说白了这就是把人管 Agent变成了Agent 管 Agent 群。层级没变只是中间那层从你换成了一个不睡觉、不抱怨、但也不懂业务的分包经理。二、三个关键设计官方讲了支撑 Projects 的三件事1默认跑在云端需要时切本地。每个 Project 有自己的电脑合上笔记本它也不会中断。云端并行跑的子 Agent 数量远超你本地笔记本能扛的规模。当某段工作必须在你机器上验证协调者才启动一个本地 Agent 干活。2共享上下文。每个 Project 维护一组文件在所有云端和本地机器之间同步。Agent 会把研究结论、产出物、对代码库的理解以及你的偏好记进去。比如某个 Agent 摸清了这个服务怎么测后面的 Agent 就能直接复用不用每次重新交代背景。3订阅。协调者可以监听 Slack 频道、按计划运行、跟踪你所有 PR——PR 打开或合并时它能顺手把 CI 修了不需要你先发指令。三、官方给的三种用法Cursor 内部把 Projects 的用法归成三类挺有参考价值功能开发先让 Agent 调研系统并记录再由协调者规划、派多个 Agent 并行实现和测试不同部分功能上线后接着盯日志、处理缺陷。迁移官方说这类开头容易、收尾难的活最适合。先定稳妥方案再全库逐步落实。早期你逐个 PR 审查方案经受住考验后逐渐放松协调者自己推进。园丁式维护处理那些永远做不完的事比如维护代码质量、盯回归。官方举例说有工程师跑的设计系统 Project起步是每处修复都人工审后来协调者扫每个新 PR、提取属于设计系统的组件同一个错误出现第二次就加一条 lint 规则。官方称这个 Project 有望做到每天处理 20 到 100 个 PR。四、不是只有 Cursor 在往这个方向走这事不是孤例。9 月 26 日的行业早报里提到Runway 发布了 WorldPromptMeta 在推 AI 挂件绕开大模型入口之争据报道来自钛媒体。更早一点普林斯顿的 PRPL 实验室有篇论文在 28 个仿真环境做了 98000 次评估发现 Claude Code、Codex 这类通用 coding agent 在广义任务与运动规划TAMP问题上表现超过了手工设计的专用方法据报道来自钛媒体。把它翻译成人话Agent 的分工协作正在从一个助手帮你写函数变成一群助手接一个项目。抽象层级每往上抬一次人负责的环节就少一段。五、对普通开发者的实际影响先说好的一面长跨度工作终于有地方放了。跨几十上百个 PR 的迁移、样式替换本来就是人最烦、最容易漏的事交给 Project 盯挺合适。上下文可以积累。最怕的就是每次开新对话都像失忆共享上下文文件这点确实能省事。再说要留个心眼的地方它不理解你的业务。协调者 Agent 拆任务再合理前提是你把目标说清楚。目标含糊它拆出来的子任务只会一起含糊而且因为是并行跑错起来也是并行的。审查不能一步到位地放开。官方自己的做法都是先逐个 PR 审方案稳了再放松。迁移类任务尤其要先看清 diff 再合并。并行不等于省钱。大量子 Agent 并行本质是把云端算力一次性铺开用量和费用都得盯着。跑之前先在小范围试。别把关键流程全托管。涉及线上发布、数据迁移、权限变更的步骤最好保留人工卡点。想先感受一下自己仓库的 PR 规模用gh就够了# 看当前打开的 PR 数量和标题ghprlist--stateopen--limit20--jsonnumber,title,author\--template{{range .}}#{{.number}} {{.title}} ({{.author.login}}){{\n}}{{end}}六、收个尾Cursor Projects 这类东西本质上是在回答一个问题当 Agent 能自己写代码之后人还负责什么它给的答案是——人负责定义目标和验收中间那层执行交给一群不睡觉的 Agent。对打工人来说这既是效率工具也是一次岗位内容的重新划分会写代码的门槛在降会定义问题、拆任务、验收结果的要求在升。工具越强越考验你知不知道该让它干什么。你在团队里试过类似的 Agent 编排吗效果怎么样评论区聊聊。 Cursor 发布 Projects：协调者 Agent 指挥上千子 Agent
9 月 10 日Cursor 推出新功能 Projects已经进入 beta、逐步向所有用户开放。它想解决的问题很具体一次对话搞不定的活——一个跨多个 PR 的大功能、一次全库迁移或者一个完整应用。官方给了组数据在 Cursor 内部用了一段时间后新用户合并的 PR 数量提升了 30%而主要使用 Projects 的用户合并量达到原来的 6 倍据报道来自官方博客。一、概念其实只有一个加一层抽象Projects 的核心思路不复杂你不再直接跟写代码的 Agent打交道而是跟一个协调者 Agentcoordinator对话。这个协调者自己不写代码只负责拆任务、派活、盯进度。因为它只委派不亲自下场所以它永远不会被某段代码卡住随时能响应你的指令。官方说法里有个数字它可以向成千上万个子 Agent 委派任务并让它们并行跑。说白了这就是把人管 Agent变成了Agent 管 Agent 群。层级没变只是中间那层从你换成了一个不睡觉、不抱怨、但也不懂业务的分包经理。二、三个关键设计官方讲了支撑 Projects 的三件事1默认跑在云端需要时切本地。每个 Project 有自己的电脑合上笔记本它也不会中断。云端并行跑的子 Agent 数量远超你本地笔记本能扛的规模。当某段工作必须在你机器上验证协调者才启动一个本地 Agent 干活。2共享上下文。每个 Project 维护一组文件在所有云端和本地机器之间同步。Agent 会把研究结论、产出物、对代码库的理解以及你的偏好记进去。比如某个 Agent 摸清了这个服务怎么测后面的 Agent 就能直接复用不用每次重新交代背景。3订阅。协调者可以监听 Slack 频道、按计划运行、跟踪你所有 PR——PR 打开或合并时它能顺手把 CI 修了不需要你先发指令。三、官方给的三种用法Cursor 内部把 Projects 的用法归成三类挺有参考价值功能开发先让 Agent 调研系统并记录再由协调者规划、派多个 Agent 并行实现和测试不同部分功能上线后接着盯日志、处理缺陷。迁移官方说这类开头容易、收尾难的活最适合。先定稳妥方案再全库逐步落实。早期你逐个 PR 审查方案经受住考验后逐渐放松协调者自己推进。园丁式维护处理那些永远做不完的事比如维护代码质量、盯回归。官方举例说有工程师跑的设计系统 Project起步是每处修复都人工审后来协调者扫每个新 PR、提取属于设计系统的组件同一个错误出现第二次就加一条 lint 规则。官方称这个 Project 有望做到每天处理 20 到 100 个 PR。四、不是只有 Cursor 在往这个方向走这事不是孤例。9 月 26 日的行业早报里提到Runway 发布了 WorldPromptMeta 在推 AI 挂件绕开大模型入口之争据报道来自钛媒体。更早一点普林斯顿的 PRPL 实验室有篇论文在 28 个仿真环境做了 98000 次评估发现 Claude Code、Codex 这类通用 coding agent 在广义任务与运动规划TAMP问题上表现超过了手工设计的专用方法据报道来自钛媒体。把它翻译成人话Agent 的分工协作正在从一个助手帮你写函数变成一群助手接一个项目。抽象层级每往上抬一次人负责的环节就少一段。五、对普通开发者的实际影响先说好的一面长跨度工作终于有地方放了。跨几十上百个 PR 的迁移、样式替换本来就是人最烦、最容易漏的事交给 Project 盯挺合适。上下文可以积累。最怕的就是每次开新对话都像失忆共享上下文文件这点确实能省事。再说要留个心眼的地方它不理解你的业务。协调者 Agent 拆任务再合理前提是你把目标说清楚。目标含糊它拆出来的子任务只会一起含糊而且因为是并行跑错起来也是并行的。审查不能一步到位地放开。官方自己的做法都是先逐个 PR 审方案稳了再放松。迁移类任务尤其要先看清 diff 再合并。并行不等于省钱。大量子 Agent 并行本质是把云端算力一次性铺开用量和费用都得盯着。跑之前先在小范围试。别把关键流程全托管。涉及线上发布、数据迁移、权限变更的步骤最好保留人工卡点。想先感受一下自己仓库的 PR 规模用gh就够了# 看当前打开的 PR 数量和标题ghprlist--stateopen--limit20--jsonnumber,title,author\--template{{range .}}#{{.number}} {{.title}} ({{.author.login}}){{\n}}{{end}}六、收个尾Cursor Projects 这类东西本质上是在回答一个问题当 Agent 能自己写代码之后人还负责什么它给的答案是——人负责定义目标和验收中间那层执行交给一群不睡觉的 Agent。对打工人来说这既是效率工具也是一次岗位内容的重新划分会写代码的门槛在降会定义问题、拆任务、验收结果的要求在升。工具越强越考验你知不知道该让它干什么。你在团队里试过类似的 Agent 编排吗效果怎么样评论区聊聊。