过去两周 Cursor 发布了两个重量级更新：Cursor Router 智能模型路由和 Agent Swarm 系统。这两篇文章表面上是产品发布，实则揭示了 AI 编程工具下一阶段竞争的核心战场——成本效率与大规模多 agent 协作。

Cursor Router：从"选模型"到"让系统选模型"

产品逻辑

Cursor Router 解决的是一个很实际的问题：大多数开发者选定一个模型后就一直用到底。这意味着用 Opus 4.8 的价格处理 console.log 级别的任务，或者用便宜模型硬扛需要深度推理的复杂重构。

Cursor Router 的做法是在请求层面加一个分类器，基于 query、context、任务复杂度、领域等特征，判断应该用哪个模型。官方数据显示：

  • 60% 的开发者只用单一模型作为日常驱动
  • Auto Intelligence 模式下，用户满意度接近 Fable，但成本降低约 60%
  • 企业客户实测：3 家高流量账户节省 30%-50%，且质量不下降

技术层面有意思的点

Cursor 特意强调了他们用在线 A/B 测试而非离线评测来评估路由效果。这个选择背后有深层逻辑：

离线评测有三个根本缺陷：数据集小、远离真实使用场景、难以将"成功"简化为单一 rubric。更关键的是，真实路由发生在对话过程中，前面的选择会影响后续的 cache miss 成本——这是离线评测完全无法捕捉的。

这让我想到一个更大的问题：AI 编程工具的评估体系正在从静态评测转向生产环境数据驱动。Cursor 掌握数百亿次编码请求的数据，这是他们训练 Router 的壁垒，也是 gegenüber GitHub Copilot 的竞争优势。

成本模式的结构性变化

Router 提出了三种模式（Intelligence / Balance / Cost），让团队在"成本-智能"帕累托前沿上自主选择。但更有意思的是其隐含的假设：模型能力已经过剩，但成本控制将成为差异化因素。

这个判断如果成立，会对编程工具市场产生深远影响。Copilot 和 Cursor 的下一阶段竞争，可能不是谁接了更强的模型，而是谁的路由策略更聪明。

Agent Swarm：从概念验证到工程系统

为什么重要

今年初 Cursor 展示过用 Swarm 从零构建浏览器的实验，那是一个令人印象深刻的概念验证，但" fell far short of polished software"。这次他们重新做了同一任务（用 Rust 从零构建 SQLite），新系统 4 小时达到 80% 测试覆盖率，旧系统不到 2 小时就 spiral 了。

这个对比的真正意义不是数字，而是它说明：Cursor 已经把 Swarm 从实验品变成了可重复的工程系统。

架构设计：树状分解与角色分离

Swarm 的核心架构是两层角色：

  • Planner agents：用最强模型，将目标递归分解并委托
  • Worker agents：用更便宜更快的模型，执行具体工作

这个设计的洞察来自对单 agent 失败模式的分析：长时运行的单 agent 会"drift"——要么专注眼前工作失去大局观，要么保持大局观却做不好具体任务。Planner 不实现，Worker 不规划，各自上下文保持干净。

这个思路有现实类比：Ronald Coase 的企业本质理论认为，协调成本增长快于工作本身，所以组织演化为层级结构而非全员互联。Swarm 的 planner-worker 分解正是这种经济逻辑在 agent 系统中的体现。

1000 commits/秒背后的工程挑战

Browser swarm 峰值约 1000 commits/小时，新系统峰值约 1000 commits/秒——三个数量级的跨越。为支撑这个吞吐量，Cursor 从零写了自定义 VCS。

这个 VCS 不只是性能需求，也是协调机制的核心。每一次变更都经过 VCS，所以冲突在那里最早可见，多个协调机制直接实现在 VCS 内部。这是一种垂直整合的选择，和传统 Git 工作流完全不同。

失败模式工程

文章详细描述了五种失败模式及其解决方案：

  1. Split-brain：两个 planner 独立实现同一概念的不同版本。解法：强制 planners 自己决策，不委托，并确保没有两个子树解决同一问题。

  2. Planner 竞争：两个 planner 知道对方存在，在同一文件上拉锯。解法：不是靠 merge 工具（无法解决观点分歧），而是让 agents 把决策写入共享设计文档，代码编译时携带对文档的可检查引用。

  3. Merge conflicts：Workers 遇到冲突时要么覆盖对方变更要么放弃自己的。解法：引入中立第三方 agent，专门处理 merge conflict，只追求公正和效率。

  4. Megafiles：热门文件被大量 agent 同时修改，变成巨型文件后成为性能瓶颈。解法：Worker 可以标记 bloated 文件，标记后阻止新提交，外部 agent 负责拆解。

  5. Ossification：Agents 从人类代码库学会不碰核心代码，即使需要改。解法：允许有意破坏——agent 做 patch 并留注释解释理由，依赖方编译失败后读取注释并更新自己的代码。

这个 failure mode 清单非常有价值。它说明多 agent 编程系统的问题不是"能不能工作"，而是会以什么方式失败。每种解法都指向一个具体的人类工程团队实践：设计文档、merge queue、代码所有权——被翻译成了 agent 协作协议。

Review Lenses：堆叠的去相关评审

Swarm 引入"review lenses"概念——用不同模型、不同训练、不同人格的评审 agent 来看同一段工作。没有单一 lens 能捕获所有问题，但去相关的 lens 会堆叠，自驾驶系统就是用这个方法达到超人类可靠性的。

这个设计的洞察是：review 比 work 便宜得多，所以 review 上的计算投入有很高回报。

Stigmergy 与 Field Guide

文章引用了 stigmergy（蚂蚁/白蚁通过改变环境来协调，而非直接通信）的概念，用来解释为什么 agents 需要共享的"Field Guide"。这是 agents 自己编写和维护的共享上下文文件夹，index.md 自动注入每个 agent 的启动上下文。

这个设计的深层含义是：agents 在为未来的自己和队友建立制度性记忆。这是从单 agent 记忆问题中跳出来，用群体记忆来解决个体上下文限制的思路。

总结：两条主线的交汇

Cursor 过去两周的更新，表面上是两个独立产品——Router（成本控制）和 Swarm（能力规模）。但它们共享同一个底层逻辑：

AI 编程工具的价值 = 模型能力 × 成本效率 × 协调机制

Router 解决成本效率问题，S warm 解决协调机制问题，两者都在为"self-driving codebases"这个愿景铺路。在那个愿景里，agents 会自己 merge PRs、管理 rollouts、监控生产。

这不是科幻，而是 Cursor 已经开始着手解决的工程问题。

本期综述覆盖 2026-07-20 至 2026-07-26 Cursor 重要更新。