代理群体与新模式经济学 · Cursor

今年早些时候，Cursor团队进行了一系列实验，旨在测试大规模代理群体协同完成目标的极限。他们的核心假设是，这种协同能够解锁更高层级和复杂度的任务。旗舰项目是一个长期运行的代理群体，从零开始构建一个网页浏览器。虽然这个概念验证取得了成功，但最终成品远未达到精致软件的标准。

这项工作是实验性的，团队从一张白纸出发，逐步优化出一个稳定有效的系统。此后，他们的目标转变为深入理解代理群体，以便能够有意地设计它。为了验证进展，他们选择了一个旧群体曾经挣扎的任务：仅凭文档，用Rust语言从零构建SQLite。

初步结果令人鼓舞。他们在相同任务、相同模型和时间预算下运行了新旧两种群体，并衡量了每个版本通过独立SQL测试套件的比例。新群体在所有模型配置下都表现更好。使用Grok 4.5时，新群体在四小时内达到了80%的通过率，而旧群体在第二小时前就陷入螺旋式下降，不得不暂停。

他们还变化了不同模型承担的角色。在某些运行中，一个模型处理所有工作，而在其他运行中，由前沿模型规划，快速廉价模型执行。每种混合方式都产生了相似的质量，但成本差异巨大。

团队将大型任务的描述自然视为树状结构，目标为根，递归分解为基本工作单元。他们的群体有两种角色，都围绕这种树状分解组织：规划者代理由最智能的模型驱动，将目标分解并委派工作；工作者代理通常由更快更便宜的模型驱动，执行具体任务。这种设计是更严格编排系统的超集。群体的形状会随着问题轮廓增长，计算和上下文按任务复杂度成比例扩展。

团队认为，这就是设计能够泛化到构建浏览器、解决数学问题和优化GPU内核等多样任务的原因。他们内部也用它来发现和修复开源软件中的漏洞、提高自己代码库的测试覆盖率，以及生成数十亿令牌的合成训练数据。

在单个代理处理完整任务时，它必须自行遍历整棵树，同时保持祖先、当前位置和全局目标在上下文中。团队认为这解释了长期运行的单一代理为什么会漂移——它们要么专注于眼前工作而失去全局，要么坚持大局而影响局部工作。在群体中，规划者从不实施，因此上下文不会被低层细节填满；工作者从不规划，因此可以将所有上下文用于单个狭窄工作。

团队怀疑，代理群体规模化能力来自这种上下文效率，而不仅仅是并行性本身。即使在中等规模任务上，这种分解也有助于代理性能。

类似的机构在经济学家罗纳德·科斯的公司理论中也有体现：协调成本增长快于工作本身，因此组织形成有限单元层级，而不是让每个人与每个人对话。

为了适应群体极高的提交率（旧群体峰值约每小时1000次提交，新系统约为每秒1000次），团队从头构建了全新的版本控制系统（VCS）。高吞吐量并非唯一原因，每个变更都经过VCS，使得冲突首先在这里变得可见，且多种协调机制直接在VCS中实现。

在人工程序员团队中，代码审查、所有权、站会和合并队列是标准协调机制。但在群体的提交速率下，出现了人类团队通常不会遇到的故障模式。例如，分裂大脑设计：两个规划者互不知情，在代码库的不同部分以不同方式实现同一概念。团队通过提示修复：规划者自己做设计决策，并确保没有两个委派的子树决定同一问题。

规划者之间的冲突是更棘手的形式，两个规划者互相知道对方的存在，并通过来回修改同一文件而争斗。团队通过让代理在共享设计文档中记录决策来解决。依赖某个决策的代码携带对该文档的编译时引用。当规划者无意中相互矛盾时，协调者合并文档，引用将决议传播到下游。

合并冲突在群体中频繁发生。为了解决冲突，代理必须停止工作，吸收另一代理的上下文并合并。工作者代理不擅长此道，在实践中要么覆盖对方更改，要么放弃自己的更改。为此，团队创建了由中立第三方代理介入合并冲突的系统，其唯一目标是公正高效，类似于人工程序员团队的合并队列。

某些文件成为代理工作的热门地点。每个代理可能只添加少量代码，但没人负责保持文件小巧。这些“巨文件”导致所有操作变慢。团队让工作者代理标记臃肿文件，然后阻止新提交并由外部代理将过大的文件分解为更小的模块。

另外，代理学会了在有人类参与的现有代码库中不触及核心代码，即使需要更改。团队允许有意破坏：认为核心更改有价值的代理可以在其范围之外制作专注补丁，并留下解释注释。编译器将更改传播到整个系统，依赖旧设计的构建失败。遇到错误的每个代理会找到注释、阅读理由并更新自己的工作以匹配。

在长期运行的多代理系统中，错误会累积，团队需要一种机制在微小错误成为基础问题前纠正。他们尝试了多种审查视角，如给审查者提供工作者的完整记录、仅输出或仅代码库。没有一个单一视角能捕获所有问题，但去相关视角叠加起来，就像自动驾驶系统无需任何完美组件就能达到超人类可靠性。团队怀疑这种叠加审查系统是运行质量持续高水平的主要原因。

群体生物如蚂蚁和白蚁通过环境塑造来实现无直接通信的协调，这种机制称为“stigmergy”。团队之前就植入“记笔记”和“记录决策”等规则，因为它们显然有益。回顾来看，这些规则让代理为未来的自己和队友制度化知识。他们进一步通过称为“现场指南”的实验推动这一点，这是一个完全由代理拥有的文件夹，其中的index.md自动注入到每个代理启动时。代理负责策划指南内容，唯一约束是行预算。指南的基本逻辑是模型权重冻结，因此恰好是那些意外遭遇值得捕捉，以使下一条代理轨迹更短。

现场指南是一个早期实验，取得了有希望的结果。团队预计在代理不完全拥有的代码库上益处更大。训练模型为继任者写作，更好的捕获带来更好的奖励，是一个有趣的后续研究领域。

在最终的SQLite实验中，新版本群体配备了上述所有改进，被指示用Rust实现整个835页的SQLite手册。团队屏蔽了源代码、测试套件和SQLite二进制文件，并禁止访问互联网。他们使用sqllogictest（SQLite项目中用于检查不同数据库引擎对相同查询返回相同结果的测试套件）来衡量进展。该套件包含数百万个已知正确答案的查询，评分是群体数据库正确回答的比例。

群体从未被告知该套件的存在。每次运行后，团队手动审查代码和运行过程，检查作弊和捷径，并确认系统是均匀构建的，而不是仅仅在测试检测的地方。

团队测试了四种配置：GPT-5.5同时作为规划者和工作者；Grok 4.5同时作为两者；Opus 4.8作为规划者搭配Composer 2.5作为工作者；Fable 5作为规划者搭配Composer 2.5作为工作者。新框架在所有组合中均优于旧框架。Fable 5混合在第一个小时内通过约三分之二的套件。到四小时截止时，新运行介于73%到85%之间，而旧运行范围从11%到77%。旧Grok 4.5运行在不到两小时时被暂停。每个新配置最终都通过了套件的100%。

从活动率来看，旧运行在最初两小时内产生了68,000次提交，约为新运行速率的70倍。但这主要是忙碌工作（抖动、争用、流失）。旧运行积累了超过70,000个冲突后被迫暂停。新运行则表现出稳定高效的进步。