智能体集群新架构：用 Planner 与 Worker 协作，把吞吐推到每秒 1000 次提交

一家前沿实验室在最新工程博客中披露了其智能体集群（agent swarm）的迭代进展。新系统在「从零构建 Rust 版 SQLite」的回归任务上显著优于旧版本：使用 Grok 4.5 时，新集群 4 小时内即可通过 80% 的保留 SQL 测试集，而旧集群不到两小时就因状态发散被迫中止。实验覆盖多种模型配置，新集群在每一档配置下都取得了更好成绩。

双角色架构：Planner 与 Worker

集群沿用树状任务分解，把目标从根节点递归拆解到最小工作单元，并对应设置两类智能体：

• Planner 智能体：由最聪明的模型驱动，负责把目标拆解并下发给 Worker。
• Worker 智能体：通常由更快、更便宜的模型承担，专注执行单一小块任务。

这种设计被作者称为「更刚性编排系统的超集」——它不为问题预设固定拓扑，而是让集群结构随问题形态生长，计算量与上下文随任务复杂度伸缩。同一套架构被复用到构建浏览器、解数学题、优化 GPU kernel 等差异极大的任务中，并在内部被用于查找开源软件漏洞、提升自有代码测试覆盖率，以及生成数十亿 token 的合成训练数据。

为什么「树」能解决长任务的记忆问题

文章把单智能体在长任务中的漂移现象，归因于上下文负担过重：它必须在每一步同时持有祖先节点、当前位置与全局目标，要么顾此失彼，要么失去对细节的关注。在集群里，Planner 从不执行实现，其上下文不会被底层细节淹没；Worker 从不规划，能把全部上下文投入一块窄工作。作者认为，这种「上下文效率」才是集群可扩展的真正来源，而非并行本身，并援引经济学家 Ronald Coase 的「企业协调成本」理论作为类比。

自研 VCS：把吞吐推到每秒 1000 次提交

Git、Cargo 等工具的粗粒度锁机制无法支撑成百上千并发智能体同时写代码——今年初的浏览器项目峰值约为「每小时 1000 次提交」，新版系统则达到「每秒约 1000 次提交」。为此团队从零搭建了一套自有的版本控制系统：吞吐不是唯一动因，更关键的是每一处改动都要经过 VCS，它是冲突最早可见的位置，也是下文多个协调机制的承载层。

高频提交下的失败模式与对策

人类团队的代码评审、Owner 机制、站会与合并队列在「人类节奏」下有效，但在集群的高频写入下暴露出新的失败模式：

• 分裂设计（Split-brain design）：两个 Planner 各自实现同一概念的两种方案。通过提示工程强制 Planner 自己做设计决策，并要求其委派的子任务不重复决策同一问题。
• Planner 间争用：更难的一种，是两位 Planner 互相知道对方，却在同一文件上来回改动。解法是把决策落到共享设计文档，依赖代码用编译期引用指向文档；冲突时由 reconciler 合并文档，引用向下游传播。
• 合并冲突：Worker 互相覆盖或丢弃对方改动。团队引入一个「中立第三方智能体」专门解决合并冲突，目标只有公正与高效，类比人类团队的合并队列角色。

文章最后给出一组成本数据：在不同模型混搭实验中，最终质量相近，但 Planner 用前沿模型、Worker 用廉价快模型，与「单一模型全程包办」相比，成本差距巨大——这是「模型经济学」标题的落脚点，也为后续如何按复杂度分配算力留下了开放问题。