Cursor 自研 Composer 模型突围：数百 Agent 并发协作改写 AI 编程规则

2025年10月30日，Cursor 2.0 正式发布。沉寂了将近半年的 AI 编程工具老炮拿出了两个大招：首个自研编码模型 Composer 和多 Agent 并行运行的新界面。这次更新被开发者社区形容为"求生欲拉满"，因为 Cursor 第一次在底层模型上摆脱了 OpenAI 和 Anthropic 的依赖。

自研 Composer：Cursor 的生死存亡之战

Cursor 是 AI 编程工具的先行者。从最早接 GPT-4 写补全，到接入 Claude 3.5 做 Composer 模式，它靠集百家之长拿到了早期红利。但这个模式有个致命问题——Cursor 本质上是 OpenAI 和 Anthropic 的 API 中介，底层模型涨价或限速会直接传导到用户体验。2024 年下半年 Claude 3.5 涨价、限速，Cursor 跟着涨价、流失用户。

Java 技术栈博主 R 哥把这个问题讲得很直白：Cursor 之前干的是赚差价的中间商生意，第三方模型一涨价、一限速，Cursor 用户体验就跟着一起遭殃。2025 年 Anthropic 和 OpenAI 亲自下场做 Claude Code 和 Codex 之后，Cursor 的处境进一步边缘化——R 哥自己说身边许多博主都转了 Claude Code 和 Codex。

2025 年 10 月发布的 Composer 是 Cursor 的反击。官方口径是同等智能模型的 4 倍速度，绝大多数复杂对话在 30 秒内搞定一轮。Composer 不是一个通用大模型，而是针对编码场景的低延迟智能体模型——通过强化学习和一组覆盖整个代码库的语义搜索工具训练，重点解决大型项目里"找文件、追踪依赖、跨文件修改"的工程难题。Composer 跟 Cursor 的多智能体架构做了深度集成：负责代码审查、测试运行、文档生成的 Agent 可以共用同一个 Composer 实例，多 Agent 协作在速度和成本上变得更可控。

多 Agent 协同：从扁平失败到 Planner-Worker 流水线

Cursor 2.0 同时上线了多 Agent 并行界面。默认布局从以文件为中心改成以 Agent 为中心，左侧多了 Agents / Editor 切换标签，每个 Agent 跑在独立的 git worktree 或远程环境里互不干扰。这部分由 Cursor 1.0 时代的 Background Agent 演化而来，但覆盖了 2.0 之后的所有 Agent 类型。

但界面只是表面功夫。真正的难题是怎么让几百个 Agent 在同一个代码库上协同工作数周。Cursor 团队 2026 年 5 月公开的工程博客详细记录了他们的踩坑过程。

第一种尝试是扁平化结构——所有 Agent 地位平等，通过一个共享文件认领任务、彼此协调。结果这套系统迅速崩溃：Agent 会持有文件锁太久不释放，二十个 Agent 并发后实际吞吐只有两三个 Agent，大部分时间花在等锁上；更糟的是 Agent 失败时不会释放锁，乐观并发控制尝试也失败，因为没有 Agent 愿意认领困难任务，整个系统陷入小修改空转的死循环。

第二种尝试是角色分层——把 Agent 拆成两类：规划者（Planners） 负责探索代码库、拆解任务、可以递归派生子规划者；执行者（Workers） 领取任务后埋头干完，不关心整体大局；中间有一个评审 Agent 判断是否进入下一轮迭代。这套结构让 Cursor 把协同规模从十几扩展到几百，而不会出现"谁都不敢做难活"的局面。

百万行代码的真实工程数据

这套系统在多个真实项目上跑了数周，数据扎实：

• 从零构建浏览器：Agent 持续运行将近一周，在 1,000 个文件里写出超过 100 万行代码，项目开源在 GitHub（wilsonzlin/fastrender），任何人可审计。

• Windows 7 模拟器：14.6K 次提交，120 万行代码。

• Excel 复刻：12K 次提交，160 万行代码。

• Cursor 自身代码库迁移：把前端框架从 Solid 迁到 React，整个过程 3 周多，代码增删 +266K/-193K。

• 生产环境的视频渲染优化：一个 Worker 用 Rust 重写渲染管线，速度提升 25 倍，已合并到生产代码。

这些不是演示 Demo——Java LSP、Windows 7 模拟器、Excel 三个项目目前仍在 GitHub 持续更新，且每个新启动的 Agent 都能直接读懂上百万行代码库并做出有意义的改动。

模型选择：不是越强越好，而是对位才有效

Cursor 团队在工程博客里抛出了一个反常识的结论：模型选择比想象的重要得多，而且不同模型适合不同角色。

GPT-5.2 系列在长时间自主工作上明显更强——更守指令、不会跑偏、能完整实现端到端功能。Opus 4.5 的问题不是不够聪明，而是太聪明了以至于偷懒——它倾向于在便利时走捷径、把控制权提前交回给用户，更像边问边干的协作风格。

更细节的发现是：GPT-5.1-codex 是专门为编码训练的，但 GPT-5.2 反而是更好的规划者。Cursor 现在的做法是针对每个角色（规划、编码、评审）选不同模型，而不是依赖单一通用模型。

Cursor 团队还有一个意外收获：他们许多改进来自减法而不是加法。一开始为质量控制设计了集成者角色，后来发现这个角色制造的瓶颈多于解决的问题——各个 Worker 本身就有能力处理彼此之间的冲突。这与分布式系统设计的常识相反，但放在 Agent 协同里却很有效。

求生战还在继续，多 Agent 协同仍在早期

Cursor 2.0 是一次被动的背水一战。R 哥的判断是：Cursor 早已经被边缘化，如果再不出大招，市场份额真的会被 Claude Code / Codex 抢光。但光有 Composer 不够——价格方面，Cursor 真该拿出诚意了。同样的订阅价，用编码能力更强的 Claude / GPT 不更香吗？

Cursor 团队自己也承认：当前的 Planner 不能在任务完成时自动"醒来"规划下一步；Agent 有时会运行时间过长；他们仍然需要定期重启系统来对抗漂移和视野狭窄。多 Agent 协同这道题，离最优状态还差得很远。

AI 编程工具的 2026 年战局已经很清楚了——不是比谁的 UI 漂亮，而是比谁的模型更懂工程实践、谁的多 Agent 协同更稳定。Cursor 用 Composer 和 Planner-Worker 流水线给自己续了一条命，但 Claude Code 和 Codex 不会停下来等它把路走完。