多模型Agent系统显然是未来的趋势。cursor 的一篇很不错的文章。他们的最新研究表明，将前沿模型作为规划者和协调者，与一个更廉价的“主力”模型搭配，可以大幅降低项目中总token的成本，从而实现 15 倍的成本改进。
在大任务中的少数时刻真正需要前沿智能，例如最初的分解、设计决策以及某些权衡。一旦前沿规划者将模糊性转化为详细、明确的指令，更廉价的模型只需遵循它即可。
这正日益成为复杂代理的核心设计模式，因为在许多任务中大量工作所使用的token并不需要与规划步骤相同的高智能阈值。通过根据任务进度路由到不同模型，你能获得整体上更高的效率。
这为 AI 应用层将如何实现差异化提供了模板。你只有深入了解领域并具备处理多层模型的能力，才能驱动这种效率；那些能做到这一点的公司在编码、金融、法律、医疗、生命科学以及其他关键领域，将处于有利位置，能够承接原本对客户而言过于昂贵的大规模工作负载。
今年，Cursor 的研究团队做了一件挺硬核的事：只给 AI 智能体一份835页的 SQLite 官方文档，不给源码，不给测试用例，不给网络，让它们从零用 Rust 把 SQLite 重新造一遍。
结果两版智能体系统跑了同一个任务，用的是同样的模型，同样的时间预算，成绩却相差巨大。新版系统在所有模型组合下都赢了旧版。用 Grok 4.5 跑的时候，新版四小时内做到了80%的测试通过率，旧版还没撑到两小时就直接崩了，团队不得不把它暂停。
更有意思的是成本。团队还试了不同的模型分工方式，有的让一个模型包办规划和执行，有的让强模型负责拆解任务，弱模型负责干活。几种方式做出来的质量差不多，但花的钱天差地别，最便宜的方案只要一千多美元，最贵的要一万多美元。
这篇文章就是 Cursor 团队把这次实验从头到尾讲了一遍，包括他们怎么设计这套智能体协作系统，踩了哪些坑，又是怎么解决的。
一件大任务拆开来看，天然长得像一棵树。最顶上是目标，然后一层层往下拆，拆到最后变成一个个具体能干的小活。
worker 智能体，通常用更快更便宜的模型，专门负责把分到手的活干完。
这套设计不会给任务强行套一个固定的组织结构，系统会跟着问题本身的形状自然展开，算力和上下文消耗也随着任务复杂度同步增长。
团队认为，这也是这套系统能同时用来做浏览器、解数学题、优化 GPU kernel 的原因。团队内部还用它来找开源软件的漏洞、给自己的代码库补测试、批量生产训练数据。
如果一个智能体要独自扛下整个任务，它就得从头走到尾，一路下探到每一个具体的小任务，同时还得一直记着任务树上面的目标和自己当前走到哪一步了。
团队猜测，这正是长时间跑的单个智能体容易跑偏的原因。要么盯着眼前的活，把大局丢了；要么死死抓住大局，眼前的活却做得稀烂。
而在蜂群里，规划器从来不干具体活，所以它的脑子里不会塞满执行细节；worker 也从来不管规划，所以它能把全部注意力都砸在自己手上这一小块活上。
团队怀疑，智能体蜂群真正的优势更多来自这种省内存的效果，而不单纯是并行干活。这个效果在任何规模的蜂群里都存在，所以哪怕任务规模不大，这种拆分方式也能让智能体表现更好。
这个道理放在别处也说得通。经济学家 Ronald Coase 当年琢磨企业为什么会存在，得出的答案是，协调的成本涨得比干活本身还快，所以组织自然会长成一层层边界清楚的单元，Pg电子平台网址不会让每个人都直接对接所有人。
Cursor 之前的文章提过，Git 和 Cargo 这类工具靠的是粗粒度的锁来处理并发。一个人用没问题，几百个智能体同时干活就完全扛不住了。
今年早些时候那个造浏览器的蜂群，在 Git 上一个小时最多提交1000次。新系统一秒钟就能提交1000次。
为了撑住这个速度，团队干脆自己重新写了一套版本控制系统。吞吐量只是原因之一，更重要的是，每一次改动都要经过这一层，冲突第一时间就会在这里暴露出来，而接下来要讲的几个协调机制，也都是直接写在这一层里面的。
人类工程团队有一整套约定俗成的协作方式，代码审查、明确的责任人、站会、合并队列。这些放在人类的工作节奏里没问题，但换到智能体每秒上千次提交的场景下，会冒出一堆人类团队平时基本碰不到的新问题。
两个互不知情的规划器，在代码库不同的地方，各自用不同的方式实现了同一个概念。
团队的解法是调整提示词，让规划器自己拍板设计决策，不往下委派，同时明确要求它们别让两个分出去的子任务同时决定同一件事。
更麻烦的情况是，两个规划器互相知道对方存在，却围着同一批文件反复改来改去，谁也不让谁。
问题的根源在于，两边对现状的理解本来就不一样，靠合并工具解决不了这种分歧。团队让智能体把决策写进一份共享的设计文档里。凡是依赖某个决策的代码，都会带一个能过编译检查、能追溯回对应文档的引用。等到两个规划器的矛盾被发现，协调器会合并这些文档，那些引用会把最终结果一路传导到下游代码。
蜂群里的智能体经常会因为同时改同一个文件撞上。要解决这个问题，得先停下来搞懂对方改了什么，再在这个基础上合并。worker 智能体不太擅长干这个，实际情况往往是要么直接覆盖对方的改动，要么干脆放弃自己的。
团队为此专门搭了一套机制，一旦出现合并冲突，就找一个中立的第三方智能体出面，替双方把冲突解决掉。它唯一的任务就是保持公正和效率，有点像人类工程团队里合并队列的角色。
有些文件特别容易变成大家扎堆修改的对象。每个智能体可能只往里加一点点代码，但没有谁专门负责把这些文件收拾精简。
这种臃肿文件会拖慢整个系统。传输慢、比对差异慢、合并慢，还老是冲突的重灾区。
团队让 worker 智能体可以主动标记这种臃肿文件。文件一旦被标记，系统就会先冻结新的提交，再找一个外部智能体把这个过度膨胀的文件拆成几个小模块。
智能体在有人类参与的老代码库里干活时，已经养成了习惯，哪怕核心代码真的需要改，也尽量绕着走，不去动它。
团队的解法是允许智能体主动引入破坏性改动。如果某个智能体判断核心部分确实值得改，它可以在自己负责的范围之外，提交一个针对性的补丁，并附上注释说明原因。
编译器会把这次改动的影响传导到整个系统，所有依赖旧设计的地方都会构建失败。每个撞上这个报错的智能体，都会去找那条注释，看懂原因，再更新自己负责的部分，让整体保持一致。
在一个长时间运行、又有很多智能体同时在干活的系统里，错误会不断累积。所以这个群体需要一种机制，能在小错误变成根本性问题之前，把自己纠正过来。
团队试了很多种审查角度，比如给审查智能体看 worker 完整的对话记录，或者只给它看输出结果，或者只给它看代码库本身。他们还试过让审查者用不同的模型、经过不同训练、带着不同的性格来跑。
没有哪一个单独的审查角度能揪出所有问题，但把几个互相之间关联不大的角度叠加起来，效果就出来了，这有点像自动驾驶系统，靠的不是某一个完美的部件，而是整体叠加做到比人类更可靠。花在审查上的算力很划算，因为审查的成本比被审查的工作本身低得多。团队怀疑，这种叠加起来的审查机制，正是这些长时间运行的任务能一直保持高质量的重要原因。
迹象引导（stigmergy）是蚂蚁、白蚁这类群居生物不需要直接交流也能协同工作的机制。它们改造环境，环境再反过来影响下一个个体的行为。
在更早的实验里，团队加过一些规则，比如让智能体保留笔记、记录决策，当时纯粹觉得这样做显然有好处。现在回头看，这其实就是在让智能体替未来的自己和队友积累知识。
后来团队又往前走了一步，做了一个完全由智能体自己写、自己维护的共享上下文实验，取名叫 Field Guide。这是一个完全交给智能体自己管理的文件夹，里面的 index.md 会在每个智能体启动时自动塞进它的上下文。哪些内容值得写进这份指南，由智能体自己判断，唯一的限制是行数不能超预算。
这套东西背后的逻辑是，模型的权重是冻结不变的，真正值得记下来的，恰恰是那些出人意料的情况，这样下一个智能体走的弯路就能更短。
Field Guide 还处于早期阶段，但已经看出一些效果。团队预计，在那些不完全由智能体自己掌控的代码库里，它带来的好处会更明显。训练模型学会替自己的后继者写东西，记录得越好、拿到的奖励就越高，这是一个值得继续琢磨的方向。
团队把上面提到的所有改进都装进新版蜂群里，让它用 Rust 实现 SQLite 那份长达835页手册里的全部内容。没有给它源码，没有给测试套件，没有给 SQLite 的二进制文件，也没给它联网的权限。
用来打分的标准叫 sqllogictest，这是 SQLite 项目自己做的一套测试，专门检查不同的数据库引擎面对同样的查询会不会返回同样的结果。里面有几百万条查询，每条都有已知的正确答案，得分就是蜂群做出来的数据库答对的比例。跑一次任务的进展，就是一条随时间往上走的曲线。
团队从没告诉蜂群这套测试的存在。每跑完一次，团队都会人工看一遍代码和整个运行过程，检查有没有作弊或者抄近道，确认整个系统是稳步推进的，没有专挑测试能检测到的地方使劲。
看这些曲线的时候要注意，策略是智能体自己选的。有的会先把地基打得很宽，好几个小时分数都不高，后期突然往上蹿；有的会先死磕一个领域，很快就能拿分，后面补其他部分的时候就进入平台期。跟某一个时间点的具体分数比起来，整体的走势更值得关注。
Grok 4.5 同时当规划器和 worker，这是团队目前性价比最高的前沿模型，当基准线用。
Fable 5 当规划器，Composer 2.5 当 worker，用来看看换一个次一级的规划器，这套混合方案是变得更划算，还是反过来更糟糕。
Fable 5 这套混合方案，第一个小时就通过了差不多三分之二的测试。跑满四小时截止的时候，新版的成绩落在73%到85%之间，旧版则是11%到77%，波动大得多。
旧版跑 Grok 4.5 的那次，在接近两小时的时候被暂停了。所有新版配置最后都通过了完整的测试集。
团队接下来想把规划器和 worker 的组合跑一个完整的 N×N 矩阵。这一轮实验里，真正重要的是新旧两个框架版本之间的对比，实际表现出来的差异，比分数上的差距要大得多。
先看最简单的活跃度指标，Grok 4.5 在新旧框架下的提交速率完全不是一个量级。旧版跑的前两个小时提交了68000次，速度大概是新版的70倍。
提交多可以理解成干活效率高，但也可以理解成大部分提交都是无效瞎忙，反复折腾、互相抢地盘、来回改。
合并冲突的数据支持后一种解读。旧版在被叫停之前，已经攒了超过70000次冲突，而且还在加速增长，没有收敛的意思。新版跑满整整四个小时，冲突加起来还不到一千次。
冲突主要扎堆在体量涨得最猛的几个文件上。旧版运行里，最大的几个文件从头到尾一直在膨胀，冲突最严重的那个文件累计冲突7771次，被1173个不同的智能体改过。新版运行里，整个代码库争抢最激烈的文件也只有47次冲突。
旧版蜂群最大的协调事故，也就是脑裂，几个规划器重复了彼此的工作，直接体现在 package 结构上。Rust 代码是按 crate 来组织的，这样的项目里，一个 crate 大致对应一个主要组件。
旧版一路膨胀到54个 crate，里面居然有三个各自独立、互不知情的 SQL package。新版很早就稳定在9个 crate，后面再没增加过。
这些差异最后都体现在最终的代码库里。用 Fable 5 混合方案跑出来的结果，新旧两版最后都通过了完整测试，但旧版用了64305行引擎代码，新版只用了9908行。Opus 混合方案也是同样的趋势，旧框架用了19013行代码，Pg电子平台网址得分97%；新框架只用了4645行，得分反而是100%。
前面提到过，不同模型组合做出来的质量都差不多，但花的钱差了一大截，从 Opus 4.8 混合方案的1339美元，到全程用 GPT-5.5 的10565美元。token 的用量数据能解释这个差距从哪来。
每次运行的花费结构都很一致，worker 至少吃掉了69%的 token，大多数运行里这个比例超过了90%。
但美元花费的分布跟 token 占比对不上，因为规划器的 token 单价更贵。在 Opus 4.8 配 Composer 2.5 的组合里，当规划器的 Opus 只产生了很少一部分 token，却占掉了大概三分之二的花费；当 worker 的 Composer 处理了绝大多数 token，花费却只占剩下的三分之一。
大型任务里，真正需要顶级智能的环节其实不多，比如最初怎么拆解任务、做设计决策、权衡取舍。前沿规划器一旦把这些不确定的东西收敛成详细明确的指令，后面便宜的模型照着执行就行。这是省钱的一个大来源。同时用 GPT-5.5 当规划器和 worker 的那次运行，光是 worker 那部分就花了9373美元。换成 Opus 4.8 规划、Composer 2.5 执行，整个 worker 集群加起来只花了411美元。
还有一个细节值得注意，对比两次混合运行就能看出来。Fable 5 当规划器时账单反而比 Opus 4.8 略低，尽管它每个 token 的单价大概贵一倍，原因是它用的规划 token 少得多。但那次运行里的 worker 消耗的 token 是另一组的好几倍，所以整次运行下来总花费明显更高。
自动补全的时候，工程师能按单行代码来干活。早期的模型把这个层级提到了一整段代码，智能体又把它提到了单个文件或者单个功能。
但要让这套方式真正跑得通，蜂群得能老老实实照着规格说明来，这也是这篇文章大部分内容真正要讲的东西。团队给了蜂群835页的文字说明，它最后交出了一个数据库。这次实验里真正稀缺的东西，也是团队预计未来软件工程里会一直稀缺的东西，是把意图描述准确。
从这个角度看，蜂群开始有点像编译器。编译器通过一连串中间步骤，把源代码翻译成机器代码。蜂群对意图做的事情跟这个很像，规划器先把目标解析成一棵任务树，再一步步细化成能执行的具体工作。区别在于，编译器每一步都能保住语义不丢，而蜂群的每一步都是概率性的，不保证百分百准确。这篇文章讲的所有内容，做的都是缩小这个差距的事。