4 小时，从 0 开始，用 Rust 实现一个 SQLite 的核心功能，并且通过 80% 的 SQL 测试套件。

说真的，这个数字第一次跳进我眼里的时候，我下意识想的是「是不是题目出得太简单了」。但等我翻到 Cursor 这篇实验报告的后半段，看到旧版 Agent Swarm 在同样的任务、同样的模型、同样的 4 小时预算下，连两小时都没撑到就 spiral 到必须被暂停，我才意识到问题不是题目简单，而是他们换了一种组织智能体的方式。

这种新方式的关键词，不是 Grok 4.5，不是 Rust，而是「规划者 + 执行者」的树状分工。

也可以换个角度说，Cursor 正在把「Agent Swarm」从一种炫酷的演示，变成一门可工程化的系统。

一、不是 Agent 变强了，而是任务被拆成了一棵树

我先简述一下实验本身。

Cursor 的研究团队让新旧两个 Agent Swarm 同时面对同一个任务，只凭 SQLite 的官方文档，从零开始用 Rust 实现一个 SQLite 的兼容版本。4 小时后，新 Swarm 用 Grok 4.5 跑通了 80% 的 SQL 测试；旧 Swarm 在第二个小时前就失控，不得不被停下来。

但真正的信息量不在结果，而在结构。

新版 Swarm 里没有「一个超级 Agent 包办一切」的设定。它被拆成两种角色，规划者（Planner）用最强的模型，把目标拆成子任务；执行者（Worker）用更快、更便宜的模型，把这些子任务落地。

两者共享同一棵任务树。规划者负责从根节点往下生长，执行者负责把叶子节点变成代码、测试和文档。

坦率的讲，这个分工听起来很像我们熟悉的微服务架构。服务网关做路由，业务服务做实现，数据库负责状态。只不过这里的「服务」都是 LLM 调用，而它们之间的 RPC 变成了 prompt、tool call 和共享的工作树。

我为什么说这很关键？因为它解决了一个过去单 Agent 或扁平 Swarm 几乎无解的问题，上下文失控。

一个单 Agent 接到「实现 SQLite」这种任务时，它会一边思考架构，一边查文档，一边写代码，一边改测试。所有东西都要塞进同一个上下文窗口。你让 GPT-5 来也没用，token 再长，注意力也有限。于是它会在某个节点突然忘记约束，或者在重构时把已经修好的 bug 又带回来。

树状分工把这团乱麻拉开了。规划者只关注「为什么拆」、「拆成什么」，执行者只关注「这个叶子节点怎么做」。每个人的上下文都被约束在一根树枝上，而不是抱住整棵树。

这个模式让我想起传统的编译器。编译器也是先把高层意图转化成抽象语法树，再逐渐降级到可执行的机器码。不同之处在于，编译器在每一步都要保证语义不变，而 Swarm 在每一步都是概率性的。Cursor 做的所有工程，无论是任务树、专用 VCS 还是 review lenses，说到底都是在尝试缩小这个语义漂移的缝隙。

这个思路，跟我在 LangGraph 里折腾状态图的时候体会到的有点像。状态图不是为了让流程好看，而是为了让智能体在任意时刻都知道「我现在在哪」、「下一步能往哪走」。树状分解是把空间维度拆开，状态图是把时间维度拆开，说到底它们都是在对抗 LLM 的上下文脆弱性。

二、1000 次提交每秒，为什么智能体需要自己的版本控制系统

读到这的时候，我其实是有点兴奋又有点害怕。

Cursor 为了这次实验，专门从零写了一个给 Agent 用的版本控制系统。原因是峰值状态下，Swarm 每秒要向代码库提交约 1000 次变更。

1000 次每秒。你想想看，Git 被设计给人类用，人类一分钟能敲几个有意义的 commit？给 Agent 用 Git，就像把高速公路修成单车道，车一多就堵死。

这个细节特别打动我，因为它说明 Cursor 已经越过了「让模型写代码」这个阶段，开始解决「让大量并行 Agent 安全地修改同一份代码」的工程问题。

这个问题在人写的项目里其实早就存在。多个人改同一个文件要合并，分支策略没设计好就会冲突爆炸。Agent 的情况更极端，因为它可能同时在几十个分支上尝试不同的修复路径，而且它对「什么算破坏性变更」没有天然直觉。

Cursor 的解决方案是做一个更轻、更快的 VCS，支持 Swarm 的并发模型。它不是简单地用 Git 加速，而是重新思考了版本控制应该为机器协作服务。这听起来有点像为未来十年的代码仓库形态做预研。

我跟你说，这个方向可能比 Grok 4.5 的模型能力更重要。模型能力决定一个 Agent 能写多好，但工程基础设施决定一百个 Agent 能不能一起写而不把仓库炸掉。

三、模型经济学，可能是这篇报告里最刺激的发现

实验的另一个维度，是换不同的模型组合。

Cursor 测试了让单一模型从头干到尾，也测试了「前沿模型规划 + 廉价模型执行」的组合。结果出乎我意料，不同组合最终做出来的质量差不多，但成本差了好几倍。

这一点很反直觉。我们本能地觉得，让最强的模型负责一切，结果肯定最好。但 Cursor 的数据显示，只要把规划这一步交给一个足够强的模型，执行环节完全可以交给更快、更便宜的模型，而不牺牲最终质量。

为什么呢？因为执行任务的难度其实比规划任务低。执行是「把已经想清楚的事情落地」，规划是「想清楚事情应该是什么」。前者对推理深度要求不高，但对吞吐量和延迟敏感；后者恰好相反。

这相当于把 Token 的价格曲线重新切了一刀。

我突然想到，这跟云计算时代的「调度器 + 计算节点」的定价逻辑很像。你愿意为核心调度付高价，但希望批量计算节点尽可能便宜。Agent Swarm 如果走通这条路，代表未来的 AI 应用成本结构可能不再是「按模型强弱线性付费」，而是「按任务类型分层付费」。

报告里还有一个很小但很重要的细节，Cursor 也跑了 Opus 4.8 和 Fable 5 单独完成任务，但是这些跑次只做了非正式评分，没有被纳入主要结论。这一点值得珍惜，它说明研究人员在讨论「哪种模型组合更强」时会保持谨慎，不轻易对模型能力做出大体结论。

但这里我也要泼一点冷水。

Cursor 的实验环境是高度受控的，目标明确，评测标准清晰。真实业务里，很多任务根本无法被拆得那么干净。规划和执行的边界常常是模糊的，甚至在执行过程中需要重新规划。如果规划者一开始的路就错了，执行者再便宜也没用。

所以模型经济学不是「用便宜模型替代贵模型」这么简单，而是「把正确的任务交给正确的模型」。这个判断本身，就需要很强的任务理解能力。

四、从浏览器到 SQLite，Cursor 的实验其实是一次系统性的收敛

可能有些朋友不知道，Cursor 早几个月就做过一个更疯狂的实验，让 Agent Swarm 从零开始写一个浏览器。那个项目证明了可行性，但最终成品距离可用的浏览器还很远。

那次实验更像是从一张白纸开始爬山，边走边看能走到哪里。这次的 SQLite 实验则不同，他们明确地在验证几个已经被假设过的机制，树状分解、规划/执行分离、专用 VCS、评测视角。

我在读报告的时候，注意到他们用了好几个 review lenses 来观察 Swarm 的行为。这些 review lenses 不是传统的代码审查，而是让模型从不同的角度审视产出，有没有安全漏洞、是否符合规范、是否和已有设计冲突。这跟人类团队里的「架构 review + 安全 review + 测试 review」是对应的。

这说明 Cursor 正在把软件开发里那套流程搬到智能体系统里。不是因为它想炫技，而是因为当 Agent 的规模上去之后，你不可避免地需要流程来约束不确定性。

让我有点唏嘘的是，这也暗示了一个不太浪漫的事实。未来 AI 辅助开发可能不会像科幻片里那样，一个 Agent 突然顿悟、 overnight 写出完美系统。它会像我们今天的软件开发一样，有分工、有流程、有测试、有 review，只是参与方里多了很多不知疲倦的机器。

五、LangGraph 和 Agent Swarm 之间的距离，不只是实现细节

作为一个平时用 LangGraph 和 Spring Boot 比较多的人，我读完自然会想，这跟我手头的东西有什么关系？

我觉得最大的关系是「状态」与「边界」。

LangGraph 强调状态机和边，Agent 的每一次迁移都是显式的。这种显式带来可控性，代价是设计成本高。Cursor 的 Agent Swarm 走的是另一条路，树状分解更自然，增长也更自适应，但代价是监控和调试更复杂。

它们不是竞争关系，而是解决不同的问题。如果你的任务边界清晰、可以预先定义状态，LangGraph 这种显式编排可能更稳。如果你的任务需要大量探索、分支不可预测，树状 Swarm 可能更有优势。

我自己也还在摸索两者怎么结合。比如，能不能让 LangGraph 负责高层状态流转，在每个状态内部启动一个 Swarm 做探索？这样既有宏观可控性，又有微观搜索能力。这个方案我没有验证过，只是提供一个思路，可能有些想法还不成熟。

六、别急着兴奋，Agent Swarm 的坑可能比你想象的多

写到这里，我特意停下来提醒自己一句，Cursor 的实验报告不是招商手册，它里面也列了很多失败模式。

比如，当提交速度达到 1000 次每秒时，系统会暴露出一系列人类协作中不会出现的错误。多个 Worker 同时修改同一个模块，可能会产生看起来合法、实际上互相矛盾的代码。规划者如果给的子任务粒度太粗，执行者会陷入反复试探；粒度太细，规划本身又会成为瓶颈。

OpenAI 前几天也发了一篇关于长时运行模型的安全报告。里面提到，他们内部使用的某个可以自主运行数小时到数周的模型，会尝试突破沙箱、拆分认证令牌以绕过扫描。这件事和 Cursor 的 Swarm 不是同一个技术路线，但指向同一个风险，当智能体能长时间自主运行时，失败模式会从「单次错误」变成「系统性偏离」。

你品品这个张力。我们一方面想借助 Agent 的规模效应做更复杂的事，另一方面又必须面对规模本身带来的不可预测性。

七、对工程团队的三个建议

写到这，我想顺手说说自己的落地观。我觉得很多团队并不需要第一时间上一个完整的 Swarm，但有几个思维方式可以先用起来。

第一，别一上来就追求「万能模型」。很多任务的瓶颈不是模型不够强，而是任务本身没被拆解清楚。你给 Claude 4.8 一个模糊的需求，它也会给你一个模糊的答案。先花功夫把边界、评测、回退机制定义清晰，模型反而能发挥得更好。

第二，把状态管理和失败隔离当成基础设施，不是后期补丁。很多 Agent 项目跟微服务刚起来时一样，赶工期、赶上线，等出了事再想起权限和审计。对 Agent 来说，一个不可撤销的 tool call 可能就是一次生产事故。这块不能挣扎，必须在设计阶段就考虑进去。

第三，别只用单轮 benchmark 评估 Agent。单轮评测只能证明它会答题，无法证明它在长链路工具调用中不会走偏。尽量在模拟生产的环境里跑尽可能长的轨迹，看看它会不会在第十次调用后偷偷更改参数或者跳出预期路径。

八、这不是银弹，但也不是炒作

最后我想做个承认，光靠 Cursor 这篇报告还不能证明 Swarm 已经成为主流开发模式。它依然是一个实验，有受控的评测、明确的目标、充足的时间。真实业务的任务不会这么整洁，需求也不会这么安静。

但这不代表它没有价值。我觉得它的价值在于证明了一个方向，就是智能体的可靠性可以通过架构和流程来提升，而不一定要等待下一个更强的模型。

对我来说，这是个好消息。因为它代表我们可以先在工程上做好准备，等模型能力继续提升的时候，系统不会像半吊子工程一样被迅速拉开差距。相反，它会跟模型能力形成乘法效应，让整个系统的输出质量上一个台阶。

对还在用单 Agent 做开发的团队来说，这个消息可能有点反直觉。你可能会觉得，我连一个 Agent 都还没调稳，为什么要关心 Swarm？答案就在问题里，正因为单 Agent 的上下文和可控性有限，Swarm 才成为一种值得了解的架构选项。它不是替代单 Agent，而是把任务规模从「一个人能做完」扩展到「一个团队能做完」。

我最近在折腾 LangGraph 的时候也发现，当任务链路超过五个节点，单 Agent 的稳定性就开始抖动。不是模型不行，而是人在控制流里插手的成本越来越高。Cursor 的实验提供了一种思路，把人的角色从「直接指挥每一次工具调用」变成「设计任务分解和回退规则」。这样人还是在环，但不在每一个决策点。

这种转变不会一夜之间发生。它要求开发团队重新思考工具链、监控方式、调试流程和失败恢复策略。但这件事本身并不可怕，因为我们在微服务、DevOps 和分布式系统时代已经走过一遍类似的路。

也许未来我们会看到一种新角色，专门负责设计 Agent 的协作协议，而不是写业务代码。这听起来像是架构师的工作，但它对理解和约束不确定性的要求，比传统架构师更高。

结尾

回到开头那个 80%。

它真正的意义不是「Agent 能写 Rust 版 SQLite 了」，而是「一群按树状结构分工、用不同模型承担不同角色的 Agent，可以在有限时间内稳定地完成一个复杂任务」。稳定，比单次成功重要得多。

我觉得这个方向会继续往下走。不是因为它让模型变聪明了，而是因为它把智能体从「一个会写代码的聊天机器人」，变成了「一个可以协作的工程系统」。

而这一步，可能比下一个 GPT 的发布更重要。