Cursor团队最新实验：将任务拆成规划者+执行者的树状结构后，智能体集群4小时内用Rust写出SQLite并通过80%测试用例，旧方案2小时即崩溃。拆解背后关于上下文效率、协作冲突和规模化瓶颈的三个关键信号。
一个由数十个AI智能体组成的编程集群，接到一个任务：仅凭文档，用Rust从零实现SQLite。2026年初，这个实验进行到第2个小时就崩溃了——各实例开始在同一个文件上反复覆盖彼此的代码，合并冲突呈指数级增长，协调成本吞噬了所有算力。2026年7月，同一支团队换了一套架构重新跑：4小时内通过80%的SQL测试套件，峰值提交速度达到每秒1000次。这与Bun团队用AI驱动Rust重写53万行代码时遇到的规模化问题如出一辙。
这个实验来自Cursor背后的工程团队。他们把这套新架构称为"树状分解"（Tree Decomposition），核心思路不是堆更多模型、加更多实例，而是重新设计了协作方式。本文拆解实验的关键发现，以及企业AI编程落地可以直接借鉴的三个工程原则。
根据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解决的是"单人+AI"的编程效率问题。多智能体集群解决的是"多人+多AI"的协作效率问题。两者不在同一个层面。如果你的团队还在3人以内，优先把单人AI编程流程跑通；如果已经跨过5人+2万行代码的临界点，协作层面的工程问题会变成主要瓶颈。
