大家好，我是拭心。
2008 年 9 月 2 日，Google Chrome 浏览器正式发布。这个项目从 2005 年立项到发布，「历时 3 年，投入了数千名工程师」。如今，Chromium 代码规模已超过 3600 万行，被称为“人类史上最复杂的软件工程项目之一”。
而就在最近，Cursor 团队做了一件让人震惊的事：「他们用上百个 AI Agent，花了不到一周时间，从零开始构建了一个浏览器，写出了超过 100 万行代码」。
这不是概念验证，也不是玩具项目。
他们用 Agent 持续运行数周，在多个超大型项目上写出了数百万行代码：Java LSP（55 万行）、Windows 7 模拟器（120 万行）、Excel（160 万行）。更令人震撼的是，它们还直接在 Cursor 自己的生产代码库中完成了一次大规模框架迁移，代码增删量达到 +266K/-193K，用时 3 周多。
「从 3 年到 1 周，从数千名工程师到上百个 Agent，这不是量变，是质变」。
AI 编程正在跨越一个关键门槛：从“辅助写代码”到“自主开发项目”。
这篇文章我们来了解下 Cursor 是如何做到的，以及对我们意味着什么。
一、多 Agent 协作：从失败到突破
单个 AI Agent 能写出几百行代码，但要开发一个百万行级别的项目，光靠一个 Agent 显然不够。
Cursor 团队的目标是让编码 Agent 持续运行数周，完全自主地完成超大型项目。
这意味着必须让上百个 Agent 同时工作。但问题来了：「怎么让它们高效协作，而不是互相干扰？」
1.1 扁平结构：一场灾难
Cursor 团队最初的想法很直觉：让所有 Agent 具有同等地位，通过一个共享文件自行协同。
每个 Agent 会检查其他 Agent 在做什么、认领一个任务并更新自己的状态。为防止两个 Agent 抢占同一项任务，他们使用了锁机制。
但这套方案在并发方面失败了：
「锁机制成了瓶颈」。 Agent 会持有锁太久，或者干脆忘记释放锁。即使锁机制正常工作，它也会成为瓶颈。二十个 Agent 的速度会下降到相当于两三个 Agent 的有效吞吐量，大部分时间都花在等待上。
「系统非常脆弱」。 Agent 可能在持有锁的情况下失败、尝试获取自己已经持有的锁，或者在完全没有获取锁的情况下更新协调文件。
后来他们尝试用乐观并发控制来替代锁：Agent 可以自由读取状态，但如果自上次读取后状态已经发生变化，则写入会失败。这种方式更简单、也更健壮，但更深层的问题依然存在。
在没有确定任务的情况下，Agent 变得非常规避风险。 它们会回避困难任务，转而做一些小而安全的修改。「没有任何一个 Agent 承担起解决难题或端到端实现的责任」（像极了曾经遇到的同事）。结果就是工作长时间在空转，却没有实质性进展。
这就像一个没有项目经理的团队，每个人都在做“看起来安全”的小任务，没人敢碰核心难题。
1.2 分层结构：像真实的团队一样工作
Cursor 团队后来尝试里将不同角色拆分开来。不再使用每个 Agent 都什么都做的扁平结构，而是搭建了一条职责清晰的流水线：
「规划者」（Planners）：持续探索代码库并创建任务。他们可以针对特定区域派生子规划者，使规划过程本身也可以并行且递归地展开。
「执行者」（Workers）：领取任务并专注于把任务完成到底。他们不会与其他执行者协调，也不关心整体大局，只是全力处理自己被分配的任务，完成后再提交变更。
在每个周期结束时，会有一个「评审 Agent」判断是否继续，然后下一轮迭代会从干净的初始状态重新开始。
这套结构基本解决了协同问题，并且让他们可以扩展到非常大的项目，而不会让任何单个 Agent 陷入视野过于狭窄的状态。成百上千个 Worker 并发运行，向同一个分支推送代码，而且几乎没有冲突。
这就像一个真实的开发团队：「有人负责架构设计和任务拆解，有人专注执行具体任务，各司其职，高效协作。」
1.3 三个震撼案例
有了这套系统后，Cursor 团队开始测试它的边界：
「从零开始构建浏览器」。 Agent 持续运行了将近一周，在 1，000 个文件中写出了超过 100 万行代码。虽然看起来只是一张简单的截图，但从零开始构建一个浏览器极其困难。尽管代码库规模庞大，新启动的 Agent 仍然可以理解它并取得实质性进展。
「Cursor 代码库的框架迁移」。 他们在 Cursor 代码库中就地将 Solid 迁移到 React，整个过程持续了 3 周多，代码增删量达到 +266K/-193K。随着测试的进行，他们确实认为有可能合并这次大规模改动。
「产品性能提升 25 倍」。 在一款即将上线的产品中，一个长时间运行的 Agent 通过一个高效的 Rust 实现，让视频渲染速度提升了 25 倍。它还新增了平滑缩放和平移的能力，使用自然的弹簧过渡和运动模糊效果，并能跟随光标顺畅移动。这部分代码已经合并，不久就会在生产环境中上线。
这些案例证明，多 Agent 开发大型项目不再是概念验证，而是真实的生产力。
二、为什么现在可以做到
上百个 Agent 协作开发超大型项目，这在一年前几乎是不可想象的。Cursor 团队的成功，背后有几个关键因素。
2.1 模型能力的质变
在运行时间极长的任务中，模型选择至关重要。Cursor 团队发现，不同模型在长时间自主工作时表现差异巨大。
「GPT-5.2 系列在长时间自主工作方面要优秀得多：更能遵循指令、保持专注、避免偏离，并且在实现上更加精确和完整」。相比之下，Opus 4.5 往往会更早结束、在方便的时候走捷径，更快地把控制权交还给用户。
这不是说 Opus 4.5 不好，而是不同模型有不同的“性格”。Opus 4.5 更适合需要人类频繁介入的场景，而 GPT-5.2 更适合长时间无人值守的自主开发。
更有意思的是，不同模型在不同角色上各有所长。即便 GPT-5.1-codex 是专门为编码训练的，GPT-5.2 依然是更好的规划者。现在 Cursor 团队会「针对每个角色选择最适合的模型，而不是依赖单一通用模型」。
规划者用 GPT-5.2，执行者用 GPT-5.1-codex，评审者可能又是另一个模型。这就像组建一个真实团队，你会根据每个岗位的特点选择最合适的人。
2.2 提示词比框架更重要
系统中有相当大一部分行为，很大程度上取决于如何为这些 Agent 设计提示词。要让它们良好协作、避免异常行为，并在长时间内保持专注，Cursor 团队做了大量实验。
运行框架和模型本身固然重要，但提示词更重要。
这个结论可能让很多人意外。我们往往以为技术架构和模型才是关键，但 Cursor 团队发现，同样的架构，不同的提示词设计，Agent 的表现会有天壤之别。
如何让规划者拆解任务时粒度合适？如何让执行者在遇到困难时不放弃？如何让评审者准确判断工作质量？这些都需要精心设计的提示词。
这也揭示了一个重要趋势：「Prompt Engineering（提示词工程）是成为 AI 时代的核心技能。」
❝推荐阅读我写的《提示词工程：你缺的不只是专业术语》
❞
2.3 减法思维：少即是多
Cursor 团队的许多改进来自“减法”而不是“加法”。
一开始他们为质量控制和冲突解决设计了一个集成者（Integrator）角色，专门负责协调各个 Worker 的代码、解决冲突、确保质量。听起来很合理，对吧？
但后来发现，「集成者制造的瓶颈多于解决的问题。各个 Worker 本身就已经有能力处理彼此之间的冲突。多出来的这个角色反而让流程变得复杂、脆弱，成了整个系统的瓶颈」。
去掉集成者后，系统反而更流畅了。
这个经验很有启发性：最好的系统往往比你想的更简单。起初 Cursor 团队尝试借鉴分布式计算和组织设计中的系统模型，但并不是所有这些方法都适用于 Agent。
三、剧变来临的信号
Cursor 团队告诉我们，「上百个 Agent 可以在同一个代码库上协同工作数周，推动雄心勃勃的项目取得实质进展。这不是理论，而是已经发生的现实」。
但他们也坦承：多智能体协同仍然是一个难题。当前的系统虽然可用，但离最优状态还差得很远。Planner 应该在任务完成时自动“醒来”规划下一步，Agent 有时会运行时间过长，他们仍然需要定期从头重启，以对抗漂移和思维视野过于狭窄的问题。
即便如此，对于核心问题——“能否通过投入更多 Agent 来扩展 AI 自主编码能力”——他们得到的答案依然比预期更乐观。
回顾过去几年 AI 编程工具的发展：
2022 年：GitHub Copilot 补全代码片段
2023 年：ChatGPT 生成完整函数
2024 年：Cursor 理解项目上下文
2025 年：Cursor/TRAE 支持 Agent 自主开发
2026 年：Cursor 探索多 Agent 系统自主开发超大型项目
编程工具进展神速，AI 从“辅助写代码”变成了“自主开发项目”。
今天，Cursor 用上百个 Agent 写出了 100 万行代码。明年呢？后年呢？AI 编程的能力边界正在快速扩张。
对于开发者来说：如果你的核心能力是“写代码”，那么你需要警惕了。但如果你的核心能力是“理解需求、设计架构、协调资源、解决问题”，那么你反而会因为 AI 而变得更强大。
那些提前拥抱 AI、学会与 AI 协作的人，正在获得巨大的竞争优势。不要等到 AI 完全成熟了再去学习，因为到那时候，窗口期可能已经关闭了。
Cursor 用上百个 Agent 开发超大型项目，这不是终点，而是起点。剧变正在发生，你准备好了吗？
好了，这篇文章到这里就结束了。感谢你的阅读，愿你平安顺遂。
如果对你有帮助，欢迎评论点赞转发，你的支持是我最大的动力❤️
参考资料：
https://cursor.com/cn/blog/scaling-agents
