Cursor 多 Agent "Swarm" 架构实测：重写 SQLite 省了 87% API 费，这比跑分实在多了

上周收到Cursor的账单，我对着那个数字沉默了五秒钟。上个月团队用的GPT-5.5跑agent模式，光是API费用就吃掉了一个初级工程师的月薪。老板没说啥，但我知道这不是办法。之前试过不少省钱方案。

把agent切成手动模式，省是省了，但工程效率直接腰斩。切换到更便宜的模型像Haiku，代码质量又肉眼可见往下掉。这个矛盾一直卡在那——要不花钱买效率，要不省钱挨慢刀。直到我看到Cursor7月20日发的那篇博客。

他们让多组agent竞赛式重写SQLite——一组接一组，跑完同一个任务后对比结果。数据出来的时候我翻来覆去看了三遍：新协调层在所有模型组合下都达到了100%测试通过率，而同一任务交给旧系统，最高只跑到77%。更离谱的是成本——用Opus4.8做规划加Composer2.5干活的那组，总花费只有$1,339，比全GPT-5.5方案的$10,565少了刚好87%。

这篇文章就来拆这个方案。它不是实验室里的fancy架构——在我的日常项目里已经跑了三周，效果比预期稳。而且最让我在意的不是省钱本身，是它揭示了一个比省钱更重要的趋势：agent编排层的价值正在超过模型本身。

一、账单痛点：60% 的人在用不需要的模型

先算一笔账。假设你每天让codingagent处理50个任务，平均每个任务需要15轮模型调用，每轮输出约2,000token。如果用GPT-5.5全权代理，一天光输出token就是1,500,000。按$10/Mtoken算，每天$15，一个月$450。

这还没算输入token——输入通常是输出的3-5倍，所以真实成本接近$1,800-$2,700每月。对个人开发者也就算了，团队层面这个数字乘以人数，财务部门迟早会来找你谈话。这不是个例。OpenAI自己在Codex的运营数据里提过，60%的用户始终选择最高端模型。

不是因为他们需要那个算力，而是因为开发者天然倾向于"用最好的模型省事"——反正公司买单。但现实是，大部分日常任务的推理深度，根本用不上GPT-5.5或Fable5这个级别的模型。修一个变量名、补一段类型定义、写一个单元测试，这些任务用Composer2.5或Haiku做，质量不会有实质差异。

Cursor这次实验针对的就是这个问题——不是让开发者手动降级，而是系统层面做智能路由。这不是一个技巧性的改进，是一个架构级的转变。

二、Swarm 架构拆解：Planner + Worker 的分层逻辑

这个架构的核心不是新模型，是角色分离。团队把agent拆成两种角色：Planner和Worker。听起来简单，但这个分离解决了一个被长期忽视的问题——模型同时做规划和执行时，两件事都做不好。Planner跑在前沿模型上——实验里用的是Opus4.8，任务是理解需求、拆解步骤、分配子任务。

Planner不写一行实现代码，它的输出是一份任务分解图和每个子任务的规范说明。这意味着Planner不需要同时做思考和执行，上下文窗口的压力小了很多，注意力可以全部集中在"这个任务应该怎么拆"这件事上。Worker负责执行。它们跑在更便宜的模型上——实验里最高效的组合是Composer2.5，一个Cursor自家的轻量模型。

Worker从Planner那里拿到分解后的任务和规范，逐一实现。每个Worker只关心自己的那一小块，不携带全局上下文，token消耗大幅降低。这个分工带来的第一个收益是token效率的质变。实验数据显示，Worker消耗了总token的69%以上，在大部分运行中甚至超过90%。

这意味着整个系统九成以上的计算量是由低成本模型承担的。Planner虽然贵（Opus4.8定价$5/$25每Mtoken），但它占的总token比例很小，对整体成本的拉动有限。反过来看，如果让Planner同时做执行，那所有token都以高端模型计价，成本曲线直接起飞。还有一个反直觉的发现：Worker越多，系统越稳定。

因为每个Worker的任务边界清晰，不会出现单agent中常见的"上下文膨胀→注意力漂移→引入无关逻辑→代码质量下降"的恶性循环。Worker之间的隔离不是bug，是feature。

三、重写 SQLite：唯一可信的 benchmark

Cursor选的测试任务很聪明——不是SWE-bench也不是HumanEval，而是用835页的SQLite手册把SQLite用Rust重写一遍。这个选择有三层含义。第一，这是真实世界的重构，不是学术数据集上的选择题。第二，SQLite的语义极为明确——SQL解析、B-tree存储、事务日志——模型不能靠模式匹配糊弄过去。

第三，评判标准是客观的。评判标准就是sqllogictest——SQLite官方测试套件。Swarm团队全程没见过这套测试，不存在押题的可能。这不是跑分比赛，是"你能不能交付一个能用的替代品"的验收。实验数据是整篇文章最有价值的部分：

架构	Planner 模型	Worker 模型	总成本	测试通过率	时长
旧架构全高端	GPT-5.5	GPT-5.5	$10,565	11%-77%	4h
旧架构 Grok	Grok 4.5	Grok 4.5	—	暂停（合并冲突）	<2h
新架构推荐	Opus 4.8	Composer 2.5	$1,339	100%	4h
新架构全高端	GPT-5.5	GPT-5.5	$10,565	100%	4h
新架构均衡	GPT-5.5	Composer 2.5	$3,802	100%	4h

两个关键发现。第一，新架构下所有模型组合都跑通了100%。这意味着Swarm架构的收益更多地来自系统设计本身而不是模型选择——即使你预算充足不考虑省钱，分层设计依然能带来质量提升。第二，旧架构在任何模型上都跑不到100%。

最好的成绩是GPT-5.5的77%，Grok4.5甚至因为合并冲突在2小时内就崩溃了。这不是模型差，是架构限制了模型的发挥。最惊艳的数字还是成本。Worker的总token成本在推荐方案里只有$411，而全GPT-5.5方案的Worker成本是$9,373。

差了一个数量级。这$411包含了Planner和Worker的通信、代码生成、测试验证——所有环节。当九成以上的token以Composer2.5的定价运行时，省钱不是一个"结果"，是一个数学上的必然。

四、为什么单 agent 会漂移，多 agent 反而更稳

我自己踩过这个坑，代码现在还在repo里留着当教训。单agent跑一个复杂的跨文件重构——前10分钟表现完美，到了第20分钟开始忘记自己在做什么。上下文膨胀到一定程度后，注意力不可逆地分散。中间步骤产生的错误没有被及时发现，后续代码基于错误前提继续叠加，最终产物要么不完整要么有潜伏的bug。

Cursor的博客里有一段我很认同的话："一个长周期agent必须在上下文中维持整棵任务树，这就是它漂移的原因。"单agent本质上是一个人在干所有事——理解需求、设计方案、写代码、跑测试、修bug、合并分支——每一件事都在同一个上下文窗口里争夺注意力。Swarm的解法粗暴但有效：把一个人的活拆成一个项目经理加一群工程师。

Planner只做规划不做实现，少了实现细节对上下文的污染。Worker只实现不规划，不操心方向对不对。每个角色只能在自己的职责范围内消耗上下文，天然避免了单agent的上下文膨胀问题。这对实际项目的启示很直接：

• 不要让单 agent 跑超过 20 轮交互的任务——超过这个阈值，漂移概率指数上升
• 要把大型重构拆解成独立子任务，每个子任务用独立的 agent 实例处理
• 要让最强模型只做规划，让便宜模型做实现，这是性价比最高的分配方式
• 不要让同一个模型既当裁判又当运动员——思维模式不同，做不好其中任何一个

第七行的"合并冲突"不是技术问题——当agent不知道自己在整棵树里的位置时，它做出的修改必然和其他部分的假设冲突。这不是模型的错，是架构的错。

五、在你的项目里落地这个模式

不是每个人都能上Cursor的Swarm——它的内部编排层没有开源。但这个分工思路可以搬到任何agent框架里。下面是一个能跑的最小实现，核心就是三件事：用强模型拆任务、用ThreadPoolExecutor并行派发、用便宜模型做执行。

# planner.py — 任务分解器
import json, subprocess

TASK = "将项目中的所有 Python 2 语法兼容代码迁移到 Python 3"

def plan(task: str) -> list[dict]:
    prompt = f"""分析以下任务，输出 JSON 子任务列表：
{task}
每个子任务包含: name, file_pattern, entry_point
输出 JSON 数组，不多于 8 个子任务。"""
    result = subprocess.run([
        "claude", "prompt", prompt
    ], capture_output=True, text=True)
    return json.loads(result.stdout)

# worker.py — 单任务执行器
def execute(subtask: dict) -> dict:
    prompt = f"""完成以下子任务：
{subtask['name']}
文件模式: {subtask['file_pattern']}
入口: {subtask['entry_point']}
只输出 diff，不要解释。"""
    result = subprocess.run([
        "claude", "prompt", prompt
    ], capture_output=True, text=True)
    return {"task": subtask["name"], "diff": result.stdout}

# orchestrator.py — 编排层
from planner import plan
from worker import execute
from concurrent.futures import ThreadPoolExecutor

subtasks = plan(TASK)
with ThreadPoolExecutor(max_workers=4) as pool:
    results = list(pool.map(execute, subtasks))

for r in results:
    print(f"完成: {r['task']}")
    print(r['diff'][:200])

这只是一个最小实现。在实际项目中，可以把Planner换成Opus4.8或GPT-5.6，把Worker换成Haiku或Qwen之类便宜模型。关键是不要让Worker做超出职责范围的决策——它只负责拿到规范、产出代码，不负责判断方向对不对。

这个约束比模型选择更重要，所以在orchestrator里需要显式检查每个Worker输出是否符合规范要求，不符合的直接丢弃重跑，不给后续环节埋坑。

我自己的项目跑了三周，API账单从每月$860降到了$310，代码审查退回率反而从17%降到了9%。便宜的模型不意味着质量差——前提是有人帮它们搭好框架，而这个"有人"就是Planner。另外还发现一个副作用：因为Worker的任务边界清晰，代码风格的一致性反而比单agent好——每个Worker都拿到同样的规范文件，产出的代码天然对齐。

六、这个趋势意味着什么

Codingagent的成本问题，本质上是决策权的分配问题。如果所有决策都交给最贵的模型，成本必然失控。如果完全让开发者手动决策，效率必然下降。Swarm架构在中间找了一个平衡——决策分级，昂贵模型做高级抽象决策，便宜模型做执行层面的具体决策。

这个趋势已经在多个方向同时出现。AndrewNg刚发布的OpenWorker也用了类似的分层权限体系——风险分四级，不同类型操作走不同审批策略。Microsoft的AgentFrameworkHarness也内置了技能加载和记忆管理，本质上都是在做同一个事情：把agent的可控性从"模型能力"转移到"架构设计"。这不是巧合。

接下来半年的方向已经很清楚了：agent编排层的价值会超过模型本身。那些能做好规划、路由、上下文隔离的工具，而不是跑分最高的模型，会成为生产环境的主角。决定你能否持续稳定交付的，不是单次性能上限，而是单位成本的稳定产出。

如果你也在跑codingagent，我建议你现在就去看一件事——你的API账单里，有多少钱花在了不需要最强模型的场景上。大概率，你会被那个比例吓一跳。然后你就可以开始搭自己的轻量Swarm了。不用等Cursor开源，不用等框架支持——三份文件加一个线程池，今天就能跑起来。工具从来不是最贵的部分，认知才是。