在探讨大语言模型（LLM）的工程落地边界时，**多智能体（Multi-Agent / Agent Swarm）**协作一直被寄予厚望。然而在实际的复杂软件工程任务中，多个智能体同时协作往往会迅速陷入代码冲突、上下文丢失和逻辑死锁。
近日，一项极具突破性的工程实验向开发者展示了解决这一瓶颈的完整工程路径：研究团队让一个智能体代理群使用 Rust 语言从零重写关系型数据库的行业标准——SQLite（并使用 sqllogictest 进行严格的基准测试）。
实验结果令人振奋：在应用了全新的架构后，代理群在使用 Grok 4.5 模型的情况下，仅用 4 小时便达到了 80% 的 SQL 测试通过率，并最终成功达到了 100% 的通过率。而作为对照组的“旧版代理群”，在任务开始不到 2 小时便陷入全面混乱而被迫终止。
本文将深度拆解该实验中披露的核心架构创新。
1. 核心基石：树状分解（Tree Decomposition）
长周期单体 Agent 失败的根本原因在于内存与上下文的冲突——它们要么沉浸在底层细节中失去了对全局架构的把控，要么为了维持全局视野而写出漏洞百出的底层代码。
研究团队引入了严格的**树状分解（Tree Decomposition）**结构，明确划分了两种角色：
- 规划者 (Planners)：由最强（但也最贵）的模型驱动，负责将宏观目标拆解为具体的微任务并进行分发。它们永远不写具体实现代码，因此上下文永远不会被底层细节塞满。
- 执行者 (Workers)：由速度快、成本低廉的模型驱动。它们不关心全局架构，将所有的上下文窗口全部用于完美实现当前被分配的一个狭窄代码块。
这种模式极其类似现代大厂的敏捷研发：架构师负责设计与契约，一线研发负责实现与 TDD。它不仅提升了代码质量，更通过高低模型的搭配（如 Fable 5 搭配 Composer 2.5）实现了极佳的模型经济学（Model Economics）。
2. 工程基建：专为硅基生命打造的 VCS
当数百个智能体同时并发工作时，传统的版本控制系统（如 Git）由于采用粗粒度的并发锁机制，会瞬间崩溃。该实验中的代理群在高峰期达到了惊人的 每秒 1,000 次提交。
为了支撑这种非人类的编码节奏，研发团队从零开始为 Agent 构建了一个专用的、极速版本控制系统（VCS）。这个 VCS 成为了整个智能体生态的数据总线，所有的状态碰撞都在这里被捕获并解决。
3. 每秒千次提交下的 5 大致命缺陷与解法
在极高的并发下，系统暴露出了人类团队从未遇到过的奇特失效模式（Failure Modes）。研发团队针对性地给出了解决方案：
缺陷一：裂脑设计 (Split-brain design)
现象：两个互相不知道对方存在的 Planner，在代码库的不同地方用截然不同的逻辑实现了同一个概念。 解法：通过 Prompt 工程，强制 Planner 必须自己做出设计决策并记录，同时确保下发给子节点的任务树中不存在决策重叠。
缺陷二：Planner 间的恶意争夺 (Contention)
现象：两个知道彼此存在的 Planner，在同一个文件上反复拉锯修改，试图覆盖对方的逻辑。Merge 工具无法解决“对现实认知”的冲突。 解法：引入“共享设计文档”。任何依赖该决策的代码必须带有编译期检查的文档引用。当 Planner 发生认知冲突时，一个专门的“仲裁智能体”会合并这些设计文档，并将最终决议向下游广播。
缺陷三：暴力的代码合并 (Merge conflicts)
现象：Worker 在遇到代码合并冲突时，往往没有耐心去吸收对方的上下文，而是直接粗暴地覆盖对方的代码，或者直接放弃自己的提交。 解法：引入第三方中立合并智能体。它的唯一任务就像开源社区的 Merge Queue 一样，高效、公正地为冲突各方解决代码冲突。
缺陷四：巨型文件阻塞 (Megafiles)
现象：某些核心文件（如 utils.rs 或核心 Struct 定义）会吸引大量 Agent 来修改。由于每个 Agent 只加几行代码，没人负责重构，文件很快变得无比臃肿，导致 Transport、Diff 和 Merge 的成本急剧上升，成为系统的性能死锁。
解法：允许 Worker 标记“臃肿文件”。一旦被标记，该文件即被锁定（禁止新提交），随后系统会唤醒一个专门的重构智能体，将其强行拆分为多个小模块。
缺陷五：系统僵化 (Ossification)
现象：聪明的大模型在人类代码库中训练得出了一个经验——“尽量不要碰核心代码”。这导致代理群在发现核心架构设计错误时，宁可写无数个丑陋的 Workaround（补丁），也不敢去动核心代码。 解法：授予 Agent “合法破坏权”。如果 Agent 认为修改核心库是有价值的，它可以在其权限外提交一个专注的 Patch，并附上一段解释原因的注释（Comment）。随后，编译器会将这个“破坏”传递给整个系统，导致所有依赖旧设计的模块报错。其他 Agent 在遇到报错时，会读到那个解释注释，并据此更新自己的模块以适配新架构。
4. 引入“环境场”与叠加审查
除了上述架构，实验还验证了两个极具启发性的机制：
- 堆叠式审查 (Review Lenses)：由于单靠一个 Review Agent 无法发现所有问题，系统采用了“多视角盲审”。有的审查者只能看到代码变更，有的只能看到执行日志。这些“去相关性”的审查视角叠加在一起，以极低的推理成本，实现了远超人类的漏洞拦截率。
- 环境场 (Stigmergy) 与 Field Guide：受生物学中蚂蚁通过改变环境来协调群体的启发，研发团队给予了代理群一个名为
Field Guide的完全自主拥有的文件夹。Agent 们自发地在这里记录踩过的坑和系统怪癖。系统在启动每个 Agent 时会自动注入index.md。这种**“将知识环境化”**的机制，让前人踩过的坑直接化为了后人的先天直觉。
总结
这项“代理群重写 SQLite”的实验向我们宣告：在追求 AI 替代程序员的道路上，工程架构的创新（如 Tree Decomposition、定制 VCS）与底层模型能力的提升同样重要。当基础设施不再局限于“碳基生命”的认知极限时，软件工程的下一次大爆炸已经到来。