AI Agent多智能体并发协同最佳实践：Cursor数百智能体架构设计解析

Cursor团队近期分享了其在扩展长时间运行的自主编码能力方面的最新研究成果：他们探索了如何在单个项目上同时运行数百个并发Agent，协调它们的工作，并观察它们写出超过一百万行代码和数万亿个token，从中获得了宝贵的实践经验。

单个 Agent 的局限

如今的AI 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源码：https://github.com/wilsonzlin/fastrender。

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

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

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

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

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

• Java LSP： https://github.com/wilson-anysphere/indonesia ：7.4K 次提交，55 万行代码（LoC）
• Windows 7 模拟器：https://github.com/wilsonzlin/aero：14.6K 次提交，120 万行代码（LoC）
• Excel：https://github.com/wilson-anysphere/formula：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可以在同一个代码库上协同工作数周，推动雄心勃勃的项目取得实质进展。

更多技术细节和讨论，可以在云栈社区的人工智能版块与其他开发者继续交流。

原博客地址：https://cursor.com/cn/blog/scaling-agents