从2小时崩溃到4小时80%通过率：智能体集群树状分解如何改变AI编程的工程上限

一个由数十个AI智能体组成的编程集群，接到一个任务：仅凭文档，用Rust从零实现SQLite。2026年初，这个实验进行到第2个小时就崩溃了——各实例开始在同一个文件上反复覆盖彼此的代码，合并冲突呈指数级增长，协调成本吞噬了所有算力。2026年7月，同一支团队换了一套架构重新跑：4小时内通过80%的SQL测试套件，峰值提交速度达到每秒1000次。这与Bun团队用AI驱动Rust重写53万行代码时遇到的规模化问题如出一辙。

这个实验来自Cursor背后的工程团队。他们把这套新架构称为"树状分解"（Tree Decomposition），核心思路不是堆更多模型、加更多实例，而是重新设计了协作方式。本文拆解实验的关键发现，以及企业AI编程落地可以直接借鉴的三个工程原则。

实验：让一群AI智能体从零写一个SQLite

根据Cursor团队在2026年7月发布的技术博客，实验设定很直接：给智能体集群一份SQLite的文档规范，不给任何参考代码，要求用Rust语言从零实现。衡量标准是保留的SQL测试套件通过率。

旧版集群——也就是今年初构建浏览器原型的那套系统——在第二小时前就陷入了混乱。问题不是模型不够聪明，而是各节点之间的协调机制在规模化时崩溃了。新版集群用完全不同的架构重跑，使用Grok 4.5模型，4小时达到80%通过率。更有意思的是，团队还测试了不同模型分工的组合：用前沿模型做规划、低成本快速模型做执行，产出质量相近但成本差异巨大——这与我们在AI编程落地的隐性成本账中测算的结论一致。

上下文窗口是真正的瓶颈

实验报告里有一个容易被忽略但非常重要的判断："集群的扩展能力源于上下文效率，而非并行性本身。"

当单个AI实例承担完整任务时，它必须在上下文中同时持有全局目标、当前子任务、祖先节点的信息以及更宏观的约束。这解释了为何长时间运行的单一实例会出现"漂移"——要么专注于眼前工作而忽略全局，要么紧抓全局而在具体环节表现糟糕。

树状分解的关键设计是把这两个角色彻底分开：

角色	职责	上下文特点
规划者（Planner）	拆解目标、委派子任务、做设计决策	从不执行代码，上下文不被底层细节填满
执行者（Worker）	完成单一狭窄任务、产出代码	从不做规划，全部上下文用于一项具体工作

团队认为，这种分离带来的上下文效率提升，即使在中型任务上也存在——它不是只在大规模场景下才生效的优化。对于企业里正在尝试用AI辅助开发的团队，这意味着：与其让一个"全栈AI"端到端写整个功能，不如把任务拆成规划和执行两层，分别用不同模型处理。

每秒千次提交暴露的工程问题

新集群的峰值提交速度达到每秒1000次，团队不得不从零构建一套专用版本控制系统。在这个速率下，出现了几个人类团队也会遇到、但在多智能体集群中被极端放大的故障模式：

• 脑裂式设计：两个规划器互不知情，在代码库不同位置以不同方式实现了同一个概念。修复方式：规划器自己做出设计决策而不是委托出去，并确保没有两个被委托的子任务对同一问题做决策。
• 规划器间争用：两个规划器知道彼此存在，但通过在相同文件上来回修改进行对抗。修复方式：让各节点把决策记录在共享设计文档中，代码对决策的依赖携带编译时可检查的引用。
• 合并冲突：执行节点在冲突时要么覆盖对方修改、要么放弃自己的修改。修复方式：引入中立的第三方实例专门介入合并冲突——类似工程团队的合并队列。
• 巨型文件：某些文件成为各执行节点的热门工作场所，不断膨胀拖慢一切。修复方式：执行节点标记臃肿文件，外部实例将其分解为更小模块。
• 僵化：各实例在与人类协作中学到了"不去碰核心代码"，即使这些代码需要修改。修复方式：允许有意的破坏，由一个判断节点决定何时重构是安全的。

有意思的是，这五个故障模式恰好映射到人类工程团队在规模化时面临的经典问题：跨组重复造轮子、架构决策冲突、合并地狱、单体膨胀、以及"没人敢动祖传代码"。

企业落地：三个可以直接用的工程原则

这个实验不是象牙塔里的学术成果——它来自一家正在向企业交付AI编程工具的公司。蓝曜炬辉在协助客户落地AI辅助开发流程时也观察到了类似的规律：团队一开始让每个开发各自用Copilot/Cursor写代码，效率确实提升了，但当项目规模跨过某个临界点（通常是5个以上开发者、代码量超过2万行），协调成本开始淹没个体效率提升。Anthropic用Claude Code两周完成Bun百万行代码迁移的案例也验证了这一点——规模化AI编程的瓶颈不在模型能力，在工程流程。

从树状分解实验和我们的工程实践中，可以提炼出三个原则：

第一，把"规划"和"执行"在流程层面分开。不要让同一个开发者（或同一个AI实例）同时承担"这个功能怎么设计"和"代码怎么写"两个角色。让最有经验的架构师或最强的模型做设计决策并产出规格说明，然后由执行层（人类初级开发者或低成本模型）严格按规格实现。这不是"不信任执行层"，而是保护上下文的干净。

第二，设计文档必须是编译时可检查的。规划器争用问题的解决方案——"代码携带对设计文档的编译时引用"——在企业场景同样有效。当你要求每个PR必须引用它所依据的设计文档，并且CI在编译期检查引用有效性时，"两个组做了冲突决策"的问题会大幅减少。

第三，为"合并"分配专门资源。合并冲突不应该由写代码的人自己在提交时临时解决——这会破坏执行层的上下文纯度。无论是人类团队还是智能体集群，都应该有一个角色专门负责合并和集成。在AI编程场景中，让一个独立实例专门处理合并冲突，效果远好于让写代码的实例自己处理。

常见问题

树状分解只适用于"从零构建"这种任务吗？

不是。Cursor团队同时在构建浏览器、修复开源漏洞、生成合成训练数据等任务上验证了这套架构。树状分解的泛化性来自一个事实：它不把固定拓扑强加于问题，而是让结构随问题的轮廓自然生长。对现有代码库的增量开发同样适用——规划者负责将需求拆分为对现有代码的最小侵入修改。

企业现在能用上这种多智能体集群吗？

直接使用Cursor团队这套系统需要较高的工程投入（自建VCS、部署多个模型实例、配置协调层）。但核心思想——规划/执行分离、设计文档引用、专门合并角色——不需要任何特殊基础设施，可以从今天开始在人类团队中应用。无问芯穹在2026年WAIC上发布的Agentic Infra也在朝这个方向走，计划逐步降低企业接入门槛。

这和直接用Copilot/Cursor有什么不同？

Copilot和Cursor解决的是"单人+AI"的编程效率问题。多智能体集群解决的是"多人+多AI"的协作效率问题。两者不在同一个层面。如果你的团队还在3人以内，优先把单人AI编程流程跑通；如果已经跨过5人+2万行代码的临界点，协作层面的工程问题会变成主要瓶颈。

参考

• Agent Swarm: Tree Decomposition Achieves 80% SQL Test Pass Rate in SQLite Build — Cursor工程团队, 2026-07-21
• 无问芯穹夏立雪：数字世界与物理世界的所有AI生产力运行，都需要 Agentic Infra — InfoQ, 2026-07-20
• ArXiv上超30%新投稿文本特征与AI撰写一致 — Unslop Research, 2026-07-20