今年早些时候，我们进行了一系列实验，以测试代理间合作实现目标的规模极限。我们的假设是，这将开启任务规模和复杂性的新层次。旗舰项目是一个长期运行的群体，从零开始构建一个网络浏览器。虽然它成功地证明了这一概念，但在软件的精细度上远未达到要求。这项工作是故意以经验主义为基础的。我们从空白画布开始，并朝着一个稳定有效的系统攀升。此后，我们的目标就是充分了解代理群体，以便能够有意识地进行工程设计。为了测试这一进展，我们回到了一个老群体曾经挣扎过的任务：从头开始用Rust构建SQLite，仅凭其文档进行开发。我们的初步结果令人鼓舞。我们在同一任务上同时运行了旧群体和新群体，使用相同的模型和时间预算，并测量了每个群体可以通过多少个排除的SQL测试套件。新群体在每种模型配置中表现得更好。使用Grok 4.5时，它在四小时内达到了80%，而旧群体在第二小时之前就陷入了困境，不得不暂停。我们还调整了哪些模型完成哪些任务。在某些情况下，一个模型处理所有内容，而在其他情况下，一个前沿模型进行规划，而一个快速、低成本的模型执行工作。每种组合产生的质量相似，但成本差异巨大。 1 树和叶子 大任务的描述自然呈现出树的形状，目标位于根部，递归地细分为基本工作单位。我们的群体有两个角色，都是围绕着同一个树状分解组织的：由最智能的模型驱动的规划者代理，将目标拆分成多个部分并进行委派。通常由更快、更便宜的模型驱动的工作代理，则执行这些任务。该设计是更严格的编排系统的超集。群体的形状不是强制在问题上施加固定拓扑，而是随着问题的轮廓增长，计算和上下文的规模与任务的复杂性成比例。我们认为这就是为什么该设计能够推广到构建浏览器、解决数学问题和优化GPU内核等各种任务。我们还在内部使用它来发现并修复开源软件中的漏洞，提高我们自有代码库的测试覆盖率，还生成了数十亿个合成训练数据的令牌。 树对记忆的作用 当一个代理承担一个完整任务时，它必须自己遍历整个树，一路下降到每个叶子，同时保持对其祖先、当前位置以及整体目标的上下文意识。我们认为这解释了为什么长期运行的单一代理会偏离轨道。他们可能专注于眼前的工作，而失去对更大图景的视野，或者关注大局，从而在具体任务上表现更差。而在群体中，规划者从不实施，因此其上下文不会充满低级细节，而工作者则从不进行规划，因此可以将所有上下文集中在一项狭小的工作上。我们怀疑，代理群体能够扩展的能力更多地来自于这种上下文效率，而非并行性本身。这种效率在每一个规模的群体中都是存在的，这就是为什么这种分解在中等大小的任务中也能帮助代理性能。 这种结构在其他地方也有回声。经济学家罗纳德·科斯曾问过企业存在的原因，认为协调成本比工作本身增长更快，因此组织会形成界限分明的单元，而不是让每个人都相互沟通。 代理的版本控制系统 在之前关于群体的帖子中，我们指出，像Git和Cargo这样的工具依赖于粗略锁定来进行并发控制。这对于一个开发者来说没问题，但对于数百个并发代理所产生的大量工作则不可行。今年早些时候的浏览器群体在Git上的提交峰值大约为每小时1000次，而新系统的峰值约为每秒1000次。为了促进这种活动的速度，我们从头开始构建了一个新的版本控制系统（VCS）。通过率并不是拥有这一层的唯一原因。系统中的每一个变更都经过VCS，因此它是冲突首次变得可见的地方，而下一节中的多个协调机制直接在其中实现。 每秒1000次提交的失败模式 人工工程团队有标准的协调机制，如代码审查、所有权、站会和合并队列。这些系统以人类的节奏工作，但在群体的提交速率下，我们看到了一些人类团队不常遇到的失败模式。 分裂大脑设计 两个规划者彼此不知情，在代码库的不同部分以不同方式实施相同的概念。我们通过提示解决了这个问题。规划者自行做出设计决策，而不是委派，并要求他们确保没有两个委派的子树决定同一个问题。 规划者之间的竞争 更困难的一种竞争形式是当两个规划者彼此知晓并互相干扰时。