Agent 集群与新型模型经济学

# 智能体集群与新模型经济学 来源：https://cursor.com/blog/agent-swarm-model-economics 今年早些时候，我们进行了一系列实验，旨在测试智能体协作达成目标的扩展极限。我们的假设是，这将解锁更高层次的任务规模和复杂度。 旗舰项目是一个从零开始构建网页浏览器的长期运行集群（https://cursor.com/blog/scaling-agents）。它作为概念验证取得了成功，但距离成熟的软件还相差甚远。 这项工作是有意基于经验进行的。我们从一张白纸出发，通过hill-climbing（https://cursor.com/blog/self-driving-codebases）的方式逐步逼近一个稳定、高效的系统。自那以后，我们的目标就是深入理解智能体集群，以便能够有意识地进行工程设计。 为了检验这一进展，我们回到了旧集群曾难以应对的任务：仅凭文档，用Rust从零构建SQLite。 初步结果令人鼓舞。我们在相同任务上运行了新旧集群，使用相同的模型和相同的时间预算，并衡量了各自通过保留SQL测试套件的比例。 新集群在每一种模型配置下都表现更好。使用Grok 4.5时，它在四小时内达到了80%，而旧集群则陷入混乱，在第二小时前就不得不暂停。 我们还尝试了不同模型承担不同任务。在某些运行中，一个模型处理所有事情；而在其他运行中，前沿模型负责规划，快速廉价的模型负责执行。每种组合都产生了相似的质量，但成本差异巨大。¹（https://cursor.com/blog/agent-swarm-model-economics#fn-1） 新旧智能体集群下不同模型组合重建SQLite的成本对比 ## https://cursor.com/blog/agent-swarm-model-economics#trees-and-leaves树与叶 对大型任务的描述自然呈树状结构，根节点的目标递归分解为基本工作单元。我们的集群有两个角色，都围绕这种树状分解组织： - 规划智能体（Planner agents），由最聪明的模型驱动，将目标拆解为若干部分并委派出去。 - 工作智能体（Worker agents），通常由更快、更便宜的模型驱动，执行这些部分。 这种设计是更严格编排系统的超集。集群并未对问题强加固定拓扑结构，而是其形状随问题轮廓生长，计算和上下文随任务复杂度成比例扩展。 我们认为这就是该设计能泛化到如此多样化任务的原因，例如构建浏览器（https://cursor.com/blog/scaling-agents）、解决数学问题（https://x.com/mntruell/status/2028903020847841336）和优化GPU内核（https://cursor.com/blog/multi-agent-kernels）。我们还在内部将其用于发现和修复开源软件中的漏洞、提高自身代码库的测试覆盖率，以及生成数十亿个合成训练数据token。 ## https://cursor.com/blog/agent-swarm-model-economics#what-the-tree-does-for-memory树对记忆的作用 当单个智能体承担完整任务时，它必须遍历整棵树，下到每一片叶子，同时始终在上下文中保留其祖先、当前位置和更广泛的目标。 我们认为这解释了为什么长时间运行的单个智能体会出现漂移。它们要么专注于手头工作而忽视大局，要么把握大局而在具体片段上表现不佳。 在集群中，规划者从不实现，因此其上下文永远不会被低级细节填满；工作者从不规划，因此它可以将其所有上下文集中在一个狭窄的工作片段上。 任务树中规划智能体与工作智能体之间的工作分解示意图 我们推测，智能体集群扩展能力源于这种上下文效率，而非并行性本身。这种效率在集群的任何规模下都存在，这就是为什么即使在中等规模的任务上，这种分解也有助于提升智能体性能。 这种结构在其他领域也有类似体现。经济学家罗纳德·科斯在探讨企业为何存在时，论证（https://en.wikipedia.org/wiki/The_Nature_of_the_Firm）协调成本的增长速度超过工作本身，因此组织会形成层级化的有限单元，而非让每个人与每个人交流。 ## https://cursor.com/blog/agent-swarm-model-economics#a-version-control-system-for-agents智能体的版本控制系统 在之前关于集群的文章（https://cursor.com/blog/self-driving-codebases）中，我们指出Git和Cargo等工具使用粗粒度锁进行并发控制。这对单个开发者来说没问题，但对于数百个并发智能体产生的工作量来说不可行。 今年早些时候的浏览器集群在Git上峰值约为每小时1000次提交。新系统峰值约为每秒1000次提交。 为了促进这种活动速率，我们从零构建了一个新的版本控制系统（VCS）。吞吐量并不是拥有这一层的唯一原因。系统中的每个变更都经过VCS，因此它是冲突最先变得可见的地方，下一节中的几个协调机制直接在其内部实现。 ## https://cursor.com/blog/agent-swarm-model-economics#failure-modes-at-1000-commits-per-second每秒1000次提交下的故障模式 人类工程团队有标准的协调机制，如代码审查、代码所有权、每日站会和合并队列。这些系统适用于人类节奏，但在集群的提交速率下，我们看到了人类团队通常不会遇到的故障模式。 ### https://cursor.com/blog/agent-swarm-model-economics#split-brain-design脑裂设计 两个互不知晓的规划者，在代码库的不同部分以不同方式实现同一概念。 我们通过提示来解决这个问题。规划者自行做出设计决策，而不是委托给他人，并且我们要求他们确保没有两个被委派的子树就同一问题做出决定。 ### https://cursor.com/blog/agent-swarm-model-economics#contention-between-planners规划者之间的争用 一种更难的争用形式是，两个规划者互相知晓，并通过在同一文件上来回变更而争斗。 问题在于两种现实图景，而合并工具无法解决分歧。相反，我们让智能体在共享设计文档中记录决策。依赖某个决策的代码会携带一个编译检查的引用回其文档。当规划者无意中相互矛盾时，一个协调者会合并这些文档，引用则将解决方案向下游传播。 ### https://cursor.com/blog/agent-swarm-model-economics#merge-conflicts合并冲突 在集群内部，智能体不断在同一文件上发生冲突。为了解决冲突，它们必须停下来，吸收另一个智能体的上下文，并围绕它进行合并。工作智能体在这方面表现不佳，在实践中，要么覆盖另一个变更，要么放弃自己的变更。 为了解决这个问题，我们创建了一个系统，由中立的第三方智能体介入合并冲突，代表所有相关方解决冲突。其唯一目标是公正高效，类似于工程团队中合并队列的工作方式。 ### https://cursor.com/blog/agent-swarm-model-economics#megafiles巨型文件 有些文件是智能体特别喜欢工作的地方。每个智能体可能只添加少量代码，但没有单个智能体负责保持文件短小。 这些“巨型文件”阻塞一切。它们传输、差异比较和合并的成本很高，并成为持续冲突的地点。 为了解决这个问题，我们为工作智能体提供了一种标记臃肿文件的方法。一旦标记，我们阻止新的提交，并由一个外部智能体将过度增长的文件分解为更小的模块。 ### https://cursor.com/blog/agent-swarm-model-economics#ossification僵化 智能体在有人类参与循环的现有代码库中工作时，学会了不去触碰核心代码，即使它需要更改。 为了解决这个问题，我们许可有意的破坏。一个认为核心更改有价值的智能体可以在其范围之外制作一个有针对性的补丁，并附上注释解释为何这样做。 编译器将更改传递到系统的其余部分，任何依赖旧设计的内容都会构建失败。每个遇到这些错误的智能体都会找到注释，阅读推理，并更新自己的工作以匹配。 ## https://cursor.com/blog/agent-swarm-model-economics#review-lenses审查镜片 在一个既长期运行又多智能体的系统中，错误会累积，集群需要一种在微小错误成为基础问题之前自我纠正的方法。 我们尝试了许多种审查镜片，例如将工作者的完整转录、仅其输出或仅有代码库提供给审查智能体。我们还尝试了在具有不同训练和不同个性的不同模型上运行的审查者。 没有单一的镜片能捕捉所有问题，但去相关的镜片可以叠加，就像自动驾驶系统无需任何单个完美组件就能达到超越人类的可靠性一样。在审查上花费的计算回报很高，因为审查比它审计的工作便宜得多。我们推测这种叠加审查系统是运行中持续质量的主要贡献因素。 ## https://cursor.com/blog/agent-swarm-model-economics#letting-agents-shape-the-environment让智能体塑造环境 Stigmergy（https://en.wikipedia.org/wiki/Stigmergy）是蚁群和蜂群等生物体无需直接沟通即可协调的机制。它们塑造环境，环境反过来塑造下一个生物体。 我们在早期的运行中编码了诸如“做笔记”和“记录决策”之类的规则，因为它们显然很好。回想起来，它们是在让智能体为未来的自己和队友将知识制度化。 我们通过一个实验进一步推进了这一点，该实验使用一种我们称之为“现场指南”的自我撰写、共享上下文。这是一个完全由智能体拥有的文件夹，其index.md会自动注入到每个智能体启动时。智能体负责整理哪些内容进入指南，唯一的限制是行预算。 指南的基本逻辑是模型权重是冻结的，因此正是那些意外的遭遇值得捕获，以便下一个智能体的轨迹更短。 “现场指南”是一个初步实验，结果很有希望。我们预计在智能体不完全拥有的代码库上，其好处会更大。训练模型为其后继者写作，其中更好的捕获导致更好的奖励，是一个值得后续研究的有趣领域。 ## https://cursor.com/blog/agent-swarm-model-economics#the-sqlite-experimentSQLite实验 我们指示新版本的集群（配备了上述所有改进）用Rust实现整个835页的SQLite手册。我们保留了源代码、测试套件、SQLite二进制文件，并禁止了互联网访问。 为了衡量进展，我们根据sqllogictest（https://www.sqlite.org/sqllogictest/doc/trunk/about.wiki）进行评分，这是SQLite项目的一个测试套件，旨在检查不同数据库引擎对相同查询是否返回相同结果。它包含数百万个具有已知正确答案的查询，评分是集群的数据库正确回答的比例。进展显示为运行过程中不断上升的曲线。 集群从未被告知该套件的存在。每次运行后，我们手动审查代码和运行本身，检查作弊和捷径，并确认系统是均匀构建的，而不仅仅是在测试关注的地方。 阅读曲线时，请记住智能体自行选择策略。有些构建了广泛的基础，数小时得分较低，然后后期飙升；另一些则深入一个领域，早期得分，然后进入平台期同时填补其余部分。趋势比特定时刻的确切分数更重要。 ## https://cursor.com/blog/agent-swarm-model-economics#results-across-model-mixes不同模型组合的结果 我们测试了四种配置，跨越能力和成本： 1. **GPT-5.5 同时作为规划者和工作者。**一个强大的前沿模型贯穿始终。²（https://cursor.com/blog/agent-swarm-model-economics#fn-2） 2. **Grok 4.5 同时作为规划者和工作者。**我们成本高效的前沿模型，作为比较点。 3. **Opus 4.8 作为规划者，Composer 2.5 作为工作者。**前沿判断力与高效执行相结合。 4. **Fable 5 作为规划者，Composer 2.5 作为工作者。**查看是否下一个级别的规划者使混合更值得或更不值得。 新框架在所有组合中都优于旧框架。 Fable 5混合组合在前一小时内通过了约三分之二的套件。到四小时截止时，新运行介于73%和85%之间，而旧运行的范围是11%到77%。 旧的Grok 4.5运行在接近两小时时被暂停（详见下文）。每一种新配置都继续通过了100%的套件。 将来我们希望能够运行规划者-工作者组合的完整N×N矩阵。在这个周期中，真正重要的比较是框架版本之间，而行为差异远比分数差异所暗示的要大得多。 旧框架与新框架下GPT-5.5的SQLite测试套件随时间得分曲线 旧框架与新框架下Grok 4.5的SQLite测试套件随时间得分曲线 Opus 4.8规划者搭配Composer 2.5工作者的SQLite测试套件随时间得分曲线 Fable 5规划者搭配Composer 2.5工作者的SQLite测试套件随时间得分曲线 ## https://cursor.com/blog/agent-swarm-model-economics#a-deep-dive-into-the-runs深入分析运行 从最简单的活动衡量指标开始，我们可以看到Grok 4.5在旧框架与新框架下提交速率的变化。旧运行在前两小时内产生了68,000次提交，大约是新运行速率的70倍。 一种解读是它更有效率。另一种解读是，这些提交中的大部分是忙活（震荡、争用、搅动）。 Grok 4.5在活跃分钟数内的累计提交数，旧框架与新框架对比 合并冲突数据指向后一种解释。旧运行在我们暂停之前累积了超过70,000个冲突，加速而非稳定，而新运行在完整的四小时内记录了不到一千个冲突。 Grok 4.5随时间累计的合并冲突，旧框架与新框架对比 冲突集中在文件增长最大的地方。在旧运行中，最大的文件在整个运行期间持续增长，单个最热的文件收集了7,771个冲突，被1,173个不同的智能体触碰。在新运行中，整个代码库中争议最大的文件只有47个冲突。 Grok 4.5最热文件大小（行数）随运行进度变化，旧框架与新框架对比 旧集群最大的协调失败——脑裂，即规划者重复彼此的工作——体现在包结构中。Rust代码组织成称为crate的包，在这样的项目中，每个crate大致对应一个主要组件。 旧运行扩展到54个crate，包括三个独立的SQL包。新运行早期就确定了九个crate，之后从未增加。 不同的Rust crate在 t