我们一直在尝试让编码 Agent 一运行就是数周，且完全自主地工作。

我们的目标是了解，在这类通常需要人类团队耗时数月完成的项目上，我们在 Agent 驱动的编码前沿上究竟还能推进多远。

这篇文章将介绍我们如何在单个项目上同时运行数百个并发 Agent、协调它们的工作，并观察它们写出超过一百万行代码和数万亿个 token，以及从中获得的经验。

#单个 Agent 的局限

如今的 Agent 在执行专注的小任务时表现不错，但在复杂项目上却显得缓慢。自然而然的下一步，是并行运行多个 Agent，但要搞清楚如何协调它们却并不容易。

我们最初的直觉是，事先规划会过于僵化。推进一个大型项目的路径往往并不明确，合理的工作拆分在一开始也并不清晰。于是我们从动态协调入手，让 Agent 根据其他 Agent 此刻正在做的事情来决定自己的下一步。

#学习如何协同

我们最初的方法是让所有 agent 具有同等地位，并通过一个共享文件自行协同。每个 agent 会检查其他 agent 在做什么、认领一个任务并更新自己的状态。为防止两个 agent 抢占同一项任务，我们使用了锁机制。

这一方案在一些有趣的方面失败了：

1. agent 会持有锁太久，或者干脆忘记释放锁。即使锁机制正常工作，它也会成为瓶颈。二十个 agent 的速度会下降到相当于两三个 agent 的有效吞吐量，大部分时间都花在等待上。

2. 系统非常脆弱：agent 可能在持有锁的情况下失败、尝试获取自己已经持有的锁，或者在完全没有获取锁的情况下更新协调文件。

我们尝试用乐观并发控制来替代锁。agent 可以自由读取状态，但如果自上次读取后状态已经发生变化，则写入会失败。这种方式更简单、也更健壮，但更深层的问题依然存在。

在没有层级结构的情况下，agent 变得非常规避风险。它们会回避困难任务，转而做一些小而安全的修改。没有任何一个 agent 承担起解决难题或端到端实现的责任。结果就是工作长时间在空转，却没有实质性进展。

#规划者和执行者

我们的下一个尝试是将不同角色拆分开来。不再使用每个 Agent 都什么都做的扁平结构，而是搭建了一条职责清晰的流水线。

• 规划者（Planners） 持续探索代码库并创建任务。他们可以针对特定区域派生子规划者，使规划过程本身也可以并行且递归地展开。

• 执行者（Workers） 领取任务并专注于把任务完成到底。他们不会与其他执行者协调，也不关心整体大局，只是全力处理自己被分配的任务，完成后再提交变更。

在每个周期结束时，会有一个评审 Agent 判断是否继续，然后下一轮迭代会从干净的初始状态重新开始。这样基本解决了我们的协同问题，并且让我们可以扩展到非常大的项目，而不会让任何单个 Agent 陷入视野过于狭窄的状态。

#运行数周之久

为了测试这个系统，我们给它设定了一个雄心勃勃的目标：从零开始构建一个浏览器。Agent 持续运行了将近一周，在 1,000 个文件中写出了超过 100 万行代码。你可以在 GitHub 上浏览源码。

尽管代码库规模庞大，新启动的 agent 仍然可以理解它并取得实质性进展。成百上千个 worker 并发运行，向同一个分支推送代码，而且几乎没有冲突。

虽然看起来只是一张简单的截图，但从零开始构建一个浏览器极其困难。

我们做的另一个实验，是在 Cursor 代码库中就地将 Solid 迁移到 React。整个过程持续了 3 周多，代码增删量达 +266K/-193K。随着我们开始测试这些变更，我们确实认为有可能合并这次大规模改动。

还有一个实验是改进一款即将上线的产品。一个长时间运行的 agent 通过一个高效的 Rust 实现，让视频渲染速度提升了 25 倍。它还新增了平滑缩放和平移的能力，使用自然的弹簧过渡和运动模糊效果，并能跟随光标顺畅移动。这部分代码已经合并，不久就会在生产环境中上线。

我们还有一些仍在运行的有趣示例：

• Java LSP：7.4K 次提交，55 万行代码（LoC）
• Windows 7 模拟器：14.6K 次提交，120 万行代码（LoC）
• Excel：12K 次提交，160 万行代码（LoC）

#我们学到了什么

我们在这些 Agent 上已经运行了数十亿个 token，目标只有一个。这个系统并不是绝对高效，但它的效果远超我们的预期。

在运行时间极长的任务中，模型选择至关重要。我们发现，GPT-5.2 系列在长时间自主工作方面要优秀得多：更能遵循指令、保持专注、避免偏离，并且在实现上更加精确和完整。

Opus 4.5 往往会更早结束、在方便的时候走捷径，更快地把控制权交还给用户。我们也发现，不同模型在不同角色上各有所长。即便 GPT-5.1-codex 是专门为编码训练的，GPT-5.2 依然是更好的规划者。现在我们会针对每个角色选择最适合的模型，而不是依赖单一通用模型。

我们的许多改进来自“减法”而不是“加法”。一开始我们为质量控制和冲突解决设计了一个集成者角色，但后来发现，它制造的瓶颈多于解决的问题。各个 Worker 本身就已经有能力处理彼此之间的冲突。

最好的系统往往比你想的更简单。起初我们尝试借鉴分布式计算和组织设计中的系统模型，但并不是所有这些方法都适用于 Agent。

合适的结构化程度其实介于两端之间。结构太少，Agent 会互相冲突、重复劳动、不断偏离；结构太多，则会让系统变得脆弱。

系统中有相当大一部分行为，很大程度上取决于我们如何为这些 Agent 设计提示。要让它们良好协作、避免异常行为，并在长时间内保持专注，我们做了大量实验。运行框架和模型本身固然重要，但提示词更重要。

#接下来会怎样

多智能体协同仍然是一个难题。当前的系统虽然可用，但离最优状态还差得很远。Planner 应该在其任务完成时自动“醒来”，规划下一步。Agent 有时会运行时间过长。我们仍然需要定期从头重启，以对抗漂移和思维视野过于狭窄的问题。

不过，对于那个核心问题——“能否通过向一个问题投入更多 Agent 来扩展自主编码能力”——我们得到的答案比预期更乐观。上百个 Agent 可以在同一个代码库上协同工作数周，推动雄心勃勃的项目取得实质进展。

我们在这里开发的技术最终会逐步融入 Cursor 的 Agent 能力中。如果你对攻克 AI 辅助软件开发中最棘手的问题感兴趣，欢迎通过 hiring@cursor.com 与我们联系。