TL;DR
- Cursor 报告 Grok 4.5 新代理群在四小时通过约 80% 的保留 sqllogictest 测试；各新配置继续运行后通过全部指定测试。
- 树状分工、共享设计、独立合并、文件拆分和多视角审查是该实验采用的协调机制。
- 测试成绩不等于生产级 SQLite 替代能力；本站未独立复现。
2026 年 7 月 20 日，Cursor 的 Wilson Lin 发布了 Agent swarms and the new model economics，介绍团队让代理群依据 SQLite 文档构建 Rust 实现的实验。本文是 T Salon 编辑部的新闻解读，重点讨论多智能体如何协调设计、代码与共享经验；本站未独立复现该实验。
先说明测试结果衡量了什么
按照 Cursor 披露的实验设置与结果，团队向代理群提供 SQLite 文档，但不向其开放源码、测试集、SQLite 程序或网络访问，并用未向代理群公开的 sqllogictest 评估 SQL 查询结果。
使用 Grok 4.5 的新代理群在四小时达到约 80% 的测试通过率，旧代理群在第二小时之前被暂停。原文还报告，各新配置在继续运行后均通过了该测试集。这里的“100%”指指定测试集的成绩，不代表完整 SQLite 兼容性、持久性、性能或生产可靠性都已获得验证，也不是说所有配置在四小时内达到 100%。
对准备采用多智能体开发的团队来说，值得研究的是协调机制如何影响有效产出。提交得更多、运行得更久，未必意味着实现更完整。
树状分解：把规划与实现分开
在 Cursor 的这套架构中，任务沿树状结构拆分为较小的工作单元，两类角色承担不同职责：
- 规划者（Planner）负责拆解目标、作出设计决定和分派工作，不编写实现代码。
- 执行者（Worker）负责完成范围较窄的实现任务，不承担全局规划。
这种分工减少了一个上下文窗口同时容纳全局目标和全部实现细节的压力。作者把上下文效率视为代理群表现改善的一种解释；这并不能证明所有单体 Agent 失败都源于相同原因。
原文也比较了不同模型分工，包括 Fable 5 规划者与 Composer 2.5 执行者。其工程含义是：规划与执行可以分别评估质量和成本，而不必让同一个模型承担所有工作。哪种组合更划算，仍取决于任务、返工量与实际计费。
版本控制为什么成为协调层
Cursor 的 VCS 说明描述了原有工具在高并发工作负载中的锁竞争，并报告新系统峰值约为每秒 1,000 次提交。团队为此构建了专用版本控制系统，让冲突识别和部分协调机制直接接入代码变更流程。
这不是“Git 遇到多智能体就会崩溃”的证据。本文的编辑判断是：先确认瓶颈来自锁、合并、文件结构还是任务重叠，再决定是否需要专用基础设施。较低并发的项目可能更适合从工作隔离和合并队列做起。
五类协作问题及本次实验的处理方式
以下机制来自 Cursor 的失效模式记录，是该系统的处理办法，不是所有代理群都必须采用的标准架构。
1. 设计分裂：同一问题出现多个答案
两个规划者可能在互不知道的情况下，对同一个概念给出不同实现。团队要求规划者自行作出设计决定，并避免将同一决定分派给不同子树。
对使用者的启发是先划清“谁负责决定接口”，再拆分实现任务。只把代码切成小块，仍可能留下重复决策。
2. 规划者竞争：共享设计反复被改写
如果规划者对系统设计持不同意见，仅处理文本合并无法消除分歧。团队用共享设计文档记录决定，让依赖这些决定的代码携带可由编译检查的引用；出现冲突时，由协调者合并设计，并将结论传递给下游。
这里的竞争描述的是修改行为，不意味着模型具有“恶意”。需要治理的是决策冲突及其传播路径。
3. 合并冲突：实现任务被迫吸收额外上下文
原文观察到，执行者处理冲突时可能覆盖另一方改动，或放弃自己的修改。系统因此引入独立的合并智能体，集中处理冲突双方的上下文。
分工的价值在于把合并责任明确下来，并非引入第三方后就能保证每次合并正确。最终代码仍需通过项目的验证。
4. 巨型文件：局部修改累积为共享瓶颈
当很多智能体向同一个文件添加少量代码，而没有角色负责拆分时，传输、差异比较与合并成本会持续增加。实验允许执行者标记过大的文件，暂时阻止新提交，再由专门的智能体拆分模块。
对于现有项目，应关注的是反复发生冲突的文件和修改集中度，而不只是并发智能体数量。
5. 结构僵化：核心设计有问题却不断叠加补丁
为避免智能体始终绕开核心代码，实验允许提交有说明的、范围集中的跨职责修改。编译错误使依赖旧设计的模块暴露出来，其他智能体据此读取说明并调整实现。
这种做法依赖可追踪的变更理由和有效的编译检查。迁移到其他项目时，还要考虑回滚与测试覆盖，不能把“允许破坏”理解成无条件扩大修改权限。
审查视角与共享经验如何配合
Cursor 还介绍了 Review Lenses：让不同审查者分别查看完整工作记录、输出结果或代码库，也尝试不同模型。多个视角有机会互补发现问题，但文中没有可供本文引用的人类漏洞拦截率对照数字，因此不能据此宣称“审查效果远超人类”。
另一个机制是 Field Guide。智能体共同维护经验目录，启动时读取 index.md，在篇幅预算内记录环境特点与已遇到的问题。它让工作经验可以被后续任务复用；作者仍把它描述为早期实验。
迁移到自己的项目前，先看四件事
以下是基于该案例的编辑建议：
- 任务能否拆分。接口和决策归属是否明确，还是多个智能体会反复决定同一问题？
- 共享决定能否传达。架构修改后，依赖它的实现是否能及时识别变化？
- 协调成本是否可见。冲突、重复实现和返工是否抵消了并发收益？
- 测试是否覆盖目标。通过率究竟证明了查询结果、兼容性还是性能，哪些生产要求仍需另测？
这四项比单独增加智能体数量更适合作为试验起点。SQLite 案例提供了可研究的协作机制，实际收益仍应由自己项目的结果与成本来判断。