# Agent Swarm 与新模型经济学：Fable 5 全程两万刀，Opus 规划 + Composer 执行一千三 https://cursor.com/blog/agent-swarm-model-economics 当任务规模大到单 a...

- 来源：Meng Shao
- 发布时间：2026-07-21 09:24
- AIWatch 分数：65
- AIWatch 标记：当日精选
- AIWatch 链接：https://aiwatch.icu/events/evt_01ky16r76r20afbq9bn2a5arna
- 原文链接：https://x.com/shao__meng/status/2079377048582426679

## 精选理由

高信息密度，值得细读

## AI 摘要

单Agent处理大任务时瓶颈从模型智力转向协调成本与上下文经济学。Cursor团队用树形swarm架构（Planner强模型+Worker便宜模型）从零实现SQLite，通过自研VCS、Review lenses、Field Guide等机制，使成本降低一个数量级（Opus规划+Composer执行总成本$411 vs 全程Fable $20,057），质量接近（新系统4小时达73%-85%）。验证了上下文分工和模型组合经济学，提示开发者应关注协调工程，成本优化主杠杆是frontier只做高熵决策。
核心观点：
1. 树形swarm架构使冲突从7万+降至<1000，代码量从64305行降至9908行。
2. Opus规划+Composer执行总成本$411，而全程Fable成本$20,057，质量接近。
3. 新系统4小时冲突<1000、包结构9 crates，旧系统commits多但thrash严重，协调成本是瓶颈。

## 正文

当任务规模大到单 agent 扛不住时，真正的瓶颈从模型智力转向协调成本与上下文经济学；把 harness 工程化之后，模型组合可以做到质量接近、成本差一个数量级。

Cursor 团队在验证什么？
早先用 swarm 从零写浏览器：能跑通，但远未成「成品」。那次是经验摸索；这次目标是把 swarm 从试出来变成设计出来。

对照任务：只给 835 页 SQLite 文档，用 Rust 从零实现；无源码、无官方测试、无二进制、无外网。用 withheld 的 sqllogictest 打分。新旧 harness、同模型、同时间预算对比。

· 新 harness 在所有模型配置下都更好
· Grok 4.5：新系统 4 小时约 80%；旧系统不到 2 小时就失控暂停
· 不同模型 mix 质量接近，费用差极大

架构：树，而不是固定流水线
大任务天然是树：根目标递归拆到叶子。
· Planner：强模型，拆分、决策、委派
· Worker：快且便宜的模型，执行窄任务

形状随问题生长，不是固定拓扑。他们认为这解释了为何同一套结构能覆盖浏览器、数学、GPU kernel、找漏洞、提覆盖率、造合成数据等不同任务。

关键判断：可扩展性主要来自上下文效率，而不只是并行。
单 agent 要一边盯全局一边做局部，必然漂移；swarm 让 planner 不写实现、worker 不规划，各自把上下文用在该用的地方。文中用科斯的企业理论类比：协调成本上升比工作本身更快，所以组织会出现分层边界。

工程现实：千级 commit/秒下的失败模式
旧浏览器 swarm 约 1000 commits/小时；新系统峰值约 1000 commits/秒。Git 级粗锁不够用，他们自研了面向 agent 的 VCS——吞吐只是一半理由，另一半是：所有变更都过 VCS，碰撞最先在这里暴露，协调机制也可做进这一层。

五类失败与对策（这是文章的工程骨架）：
· Split-brain：两个 planner 不知情地做同一设计
· Planner 争用：双方知道对方却在改同一文件对打
· Merge conflict：Worker 不会好好 merge，会覆盖或放弃
· Megafiles：热文件膨胀 → 传输/diff/冲突爆炸
· Ossification：Agent 学「别动核心」

另外两块「质量与记忆」：
· Review lenses：多视角、去相关的审查叠加（类自动驾驶多传感器）；审查比重做便宜，他们认为这对长期质量贡献很大
· Field Guide（stigmergy）：agent 自写共享上下文，启动时注入；权重冻结时，值得记录的是「意外」——缩短后续轨迹

结果：分数接近时，行为差很多
四小时节点：新系统约 73%–85%，旧系统约 11%–77%；之后新配置都能到 100%。

更说明问题的是「过程指标」：
· 旧 Grok：2 小时约 6.8 万 commits（约新系统 70 倍），冲突 >7 万 且加速；新系统 4 小时冲突 <1000
· 最热文件：旧 7771 次冲突 / 1173 个 agent；新最热文件仅 47
· 包结构：旧 54 crates（含 3 个 SQL 包）；新早期定 9 crates 后不再增
· 代码量（同过全套）：Fable mix 旧 64305 行 vs 新 9908；Opus mix 旧 19013@97% vs 新 4645@100%

Commit 多 ≠ 生产力高；多数是 thrash。Harness 差，会把算力烧成协调税。

模型经济学（标题真正落点）
质量相近时，成本约从 $1,339（Opus 4.8 planner + Composer 2.5 worker）到 $20,057（全程 Fable 5）。

支出结构稳定：
· Token：worker 通常占 ≥69%，多数 >90%
· 美元：planner 单价高，可占成本大头（Opus hybrid 里 planner 约 2/3 费用，却只产小部分 token）

核心经济命题：
大任务里真正需要 frontier 的时刻很少——根拆解、设计决策、关键取舍。一旦歧义被压成明确指令，便宜模型就能执行。

对照：GPT-5.5 双角色时，仅 worker 就 $9,373；Opus 规划 + Composer 执行时，整个 worker 舰队 $411。

补充细节：更强的 Fable 5 planner 虽单价更高、规划 token 更少，但 worker 消耗暴增，整次跑反而更贵——说明「更强 planner」不等于更优总账，还要看它如何塑造下游工作量。

更大叙事：抽象层级上移到 Spec
能力跃迁在抬高工程师的工作单元：行 → 块 → 文件/功能 → spec。

他们把 swarm 比作编译器：把意图逐级 lower 成可执行工作；区别是编译器逐步保义，swarm 每步都是概率的——文中整套机制，都是在缩小这条概率间隙。

稀缺资源从「会不会写代码」转向 意图描述是否正确、可执行、可检查。公开产物：
cursor/minisqlite
https://github.com/cursor/minisqlite

读完后应保留的判断边界
· Harness > 模型混搭：行为差异比分数差异更能解释「能不能持续跑完」。
· 并行不是主因，上下文分工才是——这解释了为何中等任务也可能受益。
· 成本优化的主杠杆是「frontier 只做高熵决策，廉价模型吃执行量」，不是一律上最贵模型。
· 这是强受控实验（封闭环境、文档即规格、功能等价测试）；真实工程还有产品判断、历史包袱、组织流程，不能直接外推为「swarm 已可替代团队」。
· Cursor 团队也承认：GPT-5.6 Sol 因 prompt 敏感导致 runaway，未公平纳入；solo frontier 成本仅作参考、未正式打分。