Datawhale干货
作者：Wilson Lin，Cursor团队
在现代编程领域，自动化和智能化的编码助手正在迅速发展。
通过让多个智能代理（Agent）并行工作，团队能够加快开发进度，在几周内完成通常需要几个月才能完成的任务。
Cursor团队公布了他们一直在探索如何使编码 Agent 能够持续运行数周，并完全自主地完成工作。这些项目通常需要人类团队花费数月时间才能完成。
本文将介绍他们如何在单个项目上同时运行数百个并发 Agent、协调它们的工作，并观察它们写出超过一百万行代码和数万亿个 token，以及从中获得的经验。
一、单个 Agent 的局限
如今的 Agent 在执行专注的小任务时表现不错，但在复杂项目上却显得缓慢。自然而然的下一步，是并行运行多个 Agent，但要搞清楚如何协调它们却并不容易。
我们最初的直觉是，事先规划会过于僵化。推进一个大型项目的路径往往并不明确，合理的工作拆分在一开始也并不清晰。于是我们从动态协调入手，让 Agent 根据其他 Agent 此刻正在做的事情来决定自己的下一步。
二、学习如何协同
我们最初的方法是让所有 agent 具有同等地位，并通过一个共享文件自行协同。每个 agent 会检查其他 agent 在做什么、认领一个任务并更新自己的状态。为防止两个 agent 抢占同一项任务，我们使用了锁机制。
这一方案在一些有趣的方面失败了：
agent 会持有锁太久，或者干脆忘记释放锁。即使锁机制正常工作，它也会成为瓶颈。二十个 agent 的速度会下降到相当于两三个 agent 的有效吞吐量，大部分时间都花在等待上。
系统非常脆弱：agent 可能在持有锁的情况下失败、尝试获取自己已经持有的锁，或者在完全没有获取锁的情况下更新协调文件。
我们尝试用乐观并发控制来替代锁。agent 可以自由读取状态，但如果自上次读取后状态已经发生变化，则写入会失败。这种方式更简单、也更健壮，但更深层的问题依然存在。
在没有层级结构的情况下，agent 变得非常规避风险。它们会回避困难任务，转而做一些小而安全的修改。没有任何一个 agent 承担起解决难题或端到端实现的责任。结果就是工作长时间在空转，却没有实质性进展。
三、规划者和执行者
我们的下一个尝试是将不同角色拆分开来。不再使用每个 Agent 都什么都做的扁平结构，而是搭建了一条职责清晰的流水线。
规划者（Planners）持续探索代码库并创建任务。他们可以针对特定区域派生子规划者，使规划过程本身也可以并行且递归地展开。
执行者（Workers）领取任务并专注于把任务完成到底。他们不会与其他执行者协调，也不关心整体大局，只是全力处理自己被分配的任务，完成后再提交变更。
在每个周期结束时，会有一个评审 Agent 判断是否继续，然后下一轮迭代会从干净的初始状态重新开始。这样基本解决了我们的协同问题，并且让我们可以扩展到非常大的项目，而不会让任何单个 Agent 陷入视野过于狭窄的状态。
四、运行数周之久
为了测试这个系统，我们给它设定了一个雄心勃勃的目标：从零开始构建一个浏览器。Agent 持续运行了将近一周，在 1,000 个文件中写出了超过 100 万行代码。你可以在 GitHub 上浏览源码（https://github.com/wilsonzlin/fastrender）。
尽管代码库规模庞大，新启动的 agent 仍然可以理解它并取得实质性进展。成百上千个 worker 并发运行，向同一个分支推送代码，而且几乎没有冲突。
虽然看起来只是一张简单的截图，但从零开始构建一个浏览器极其困难。
我们做的另一个实验，是在 Cursor 代码库中就地将 Solid 迁移到 React。整个过程持续了 3 周多，代码增删量达 +266K/-193K。随着我们开始测试这些变更，我们确实认为有可能合并这次大规模改动。
还有一个实验是改进一款即将上线的产品。一个长时间运行的 agent 通过一个高效的 Rust 实现，让视频渲染速度提升了 25 倍。它还新增了平滑缩放和平移的能力，使用自然的弹簧过渡和运动模糊效果，并能跟随光标顺畅移动。这部分代码已经合并，不久就会在生产环境中上线。
我们还有一些仍在运行的有趣示例：
Java LSP：7.4K 次提交，55 万行代码（LoC）
https://github.com/wilson-anysphere/indonesia
Windows 7 模拟器：14.6K 次提交，120 万行代码（LoC）
https://github.com/wilsonzlin/aero
Excel：12K 次提交，160 万行代码（LoC）
https://github.com/wilson-anysphere/formula
五、运行数周之久
我们在这些 Agent 上已经运行了数十亿个 token，目标只有一个。这个系统并不是绝对高效，但它的效果远超我们的预期。
在运行时间极长的任务中，模型选择至关重要。我们发现，GPT-5.2 系列在长时间自主工作方面要优秀得多：更能遵循指令、保持专注、避免偏离，并且在实现上更加精确和完整。
Opus 4.5 往往会更早结束、在方便的时候走捷径，更快地把控制权交还给用户。我们也发现，不同模型在不同角色上各有所长。即便 GPT-5.1-codex 是专门为编码训练的，GPT-5.2 依然是更好的规划者。现在我们会针对每个角色选择最适合的模型，而不是依赖单一通用模型。
我们的许多改进来自“减法”而不是“加法”。一开始我们为质量控制和冲突解决设计了一个集成者角色，但后来发现，它制造的瓶颈多于解决的问题。各个 Worker 本身就已经有能力处理彼此之间的冲突。
最好的系统往往比你想的更简单。起初我们尝试借鉴分布式计算和组织设计中的系统模型，但并不是所有这些方法都适用于 Agent。
合适的结构化程度其实介于两端之间。结构太少，Agent 会互相冲突、重复劳动、不断偏离；结构太多，则会让系统变得脆弱。
系统中有相当大一部分行为，很大程度上取决于我们如何为这些 Agent 设计提示。要让它们良好协作、避免异常行为，并在长时间内保持专注，我们做了大量实验。运行框架和模型本身固然重要，但提示词更重要。
六、接下来会怎样
多智能体协同仍然是一个难题。当前的系统虽然可用，但离最优状态还差得很远。Planner 应该在其任务完成时自动“醒来”，规划下一步。Agent 有时会运行时间过长。我们仍然需要定期从头重启，以对抗漂移和思维视野过于狭窄的问题。
不过，对于那个核心问题——“能否通过向一个问题投入更多 Agent 来扩展自主编码能力”——我们得到的答案比预期更乐观。上百个 Agent 可以在同一个代码库上协同工作数周，推动雄心勃勃的项目取得实质进展。
一起“点赞”三连↓
