Cursor Composer 2.5 Build in Parallel 实战：把 IDE 当依赖图调度器

💡 一句话总结：Composer 2.5 不是简单升级了模型，而是 Cursor 把『agent + 依赖图 + KV cache』三层栈做到了一体化。Build in Parallel 让 IDE 第一次像 CI/CD 系统那样调度任务。

Composer 2.5 五分钟概览

5 月 18 日 Cursor 在博客 Introducing Composer 2.5 上线了自家最强的编码模型。数字先放最前面：

价格只有 Opus 4.7 的 1/10，性能基本持平 —— 这是 5 月 18 日以来 Hacker News 顶起来的关键事实。但 Cursor 真正的杀手锏不是模型本身，而是配合 Cursor 3.3（5 月 7 日推送）的 Build in Parallel 功能。

Build in Parallel 解决什么问题

老 agent 模式的痛点：

• 一个 plan 里 80% 的子任务其实彼此独立（比如『加 lint 配置 / 写 README / 补 e2e 测试』），但被串行执行了
• 工程师等 agent 等到下班，因为每次只能跑一个
• 想多开几个 agent 又要自己拆分任务，拆错了合并冲突地狱

Cursor 在 3.3 里把这个问题正面解了：

1. 依赖图分析：Composer 收到大任务后，先把它拆成 N 个 step，每个 step 标注上下游依赖关系（读哪些文件、改哪些文件、产出什么）
2. 拓扑排序 + 并行调度：IDE 把没有依赖的 step 同时丢给 async subagent，相互依赖的保持串行
3. 统一合并：所有 subagent 完成后，主 agent 检查 patch 不冲突，再统一 commit

这套机制公开的官方说法是 “dependency-aware execution graph”，跟 CI/CD 系统的 DAG 调度本质一样。

启用与基础用法

Step 1: 开启 Build in Parallel

设置入口：Cursor → Settings → Features → Build in Parallel。需要 Cursor 3.3 以上（菜单里如果没有这一项，先升级 IDE）。

启用后会有两个新选项：

• Auto parallelize: 默认 off，开启后 Composer 自动判断是否拆分；建议先 off 自己控制
• Max concurrent subagents: 默认 3，免费用户最高 3，Pro 5，Business 8

Step 2: 用 /multitask 显式触发

在 chat 输入 /multitask 后跟任务描述，例如：

/multitask 
重构 src/api/payment 模块：
1. 把 PaymentService 拆成 PaymentGateway + PaymentValidator 两个类
2. 更新所有 caller（src/handlers/, src/jobs/）
3. 补充单元测试到 80% 覆盖率
4. 更新 docs/payment.md
5. 给 CI 加 contract test

Composer 收到后会先返回一个 plan，类似：

[Plan]
- Step A: 拆分 PaymentService → PaymentGateway + PaymentValidator (改 src/api/payment/*)
- Step B: 更新 src/handlers/ 中的 caller     (依赖 A)
- Step C: 更新 src/jobs/ 中的 caller          (依赖 A)
- Step D: 写新单元测试 tests/payment/*.test  (依赖 A)
- Step E: 更新 docs/payment.md                (无依赖)
- Step F: CI 配置加 contract test            (无依赖)

[Topology]
A → {B, C, D}   并行执行 B/C/D
{E, F}          独立并行

确认后 IDE 弹出 5 个 subagent panel（A 单独、B/C/D 并行、E/F 并行），同步显示每个 subagent 当前在改什么文件。

Step 3: 监督 + 合并

每个 subagent 完成后 panel 变绿，patch 进入 review 队列。主 agent 在所有依赖完成后做最后的全局检查：

• 文件冲突检测（两个 subagent 不能同时写同一个文件）
• 测试运行
• 风格一致性（同一个变量在 B/C/D 里被改成不同名字会被警告）

通过后 commit 一次。整个流程比串行快多少？根据 Cursor 公布的数据，平均加速 2.3x，依赖稀疏的大重构任务能到 4x。

三个真实场景的依赖图设计

场景 1：多模块跨语言迁移

任务：把 Python service 翻译成 Go。

错误的提示词写法：

把整个 service 翻译成 Go

—— Composer 不会拆分，会一文件一文件串行翻译。

正确写法：

/multitask
把 Python service 翻译成 Go：
- 每个 .py 文件对应一个 .go 文件，独立翻译
- 共享类型定义放在 pkg/types/，最先翻译
- 主入口 main.go 最后翻译
- 翻译完成后跑 go test ./... 验证

Composer 会识别出 pkg/types/ 是上游，主入口是下游，中间所有文件并行。8 个文件的 service，并行翻译比串行快 3.7 倍。

场景 2：仓库 onboarding 体力活

任务：给一个新仓库加上完整工程化配置。

/multitask
为这个新仓库添加以下配置（所有任务彼此独立）：
1. 加 ESLint + Prettier 配置，把现有代码格式化
2. 写 Dockerfile + docker-compose.yml
3. 写完整的 README.md（项目背景、安装、使用、贡献指南）
4. 加 GitHub Actions CI（lint + test + build）
5. 加 .gitignore + .editorconfig + LICENSE

5 个任务无依赖，并行执行后 IDE 在 5 分钟内完成 1 小时的体力活。

场景 3：bug 修复 + 回归覆盖

任务：修复一个 bug 同时补回归测试。

/multitask
issue #234 描述的 SSO 登录 401 问题：
- 主任务：定位 + 修复（先做）
- 同时：扫描 src/auth/ 找出现有覆盖率，补充缺失的单元测试

Composer 会把修复设为 Step A、测试补充设为 Step B，B 等 A 完成后再开始（因为要测新代码）。这种『主任务 + 影子任务』的写法可以在不打断思路的情况下顺便提升覆盖率。

跟其他三家的对比

5 月以来 4 家主流 AI IDE 都加了并行子 agent，差异如下：

选型建议：

• 想在 IDE 里深度协作、看每个 subagent 状态 → Cursor Composer 2.5
• 想跟 5 个 Agent 各自有完整 worktree → Windsurf Wave 13
• 任务跑 30 分钟以上、不想盯着 IDE → Antigravity 2
• 极致并行、可以接受简陋体验 → Grok Build

三个使用误区

误区 1：所有任务都用 /multitask

并行有额外协调成本。简单的『加一个按钮 / 修一个空格 bug』串行更快。一般经验是任务能拆成 3 个以上独立子步骤再用 multitask。

误区 2：并发开到最大

8 个 subagent 同时跑会导致 IDE 卡顿、token 消耗陡增。推荐保持 3-5。Max concurrent subagents 调到 5 之后再没收益。

误区 3：完全信任依赖图

Composer 偶尔会漏掉隐式依赖（比如『改了某个 enum 但没扫到所有 switch case』）。重要 plan 一定要看一眼依赖图，发现问题手动加 dependency。Step B depends on A 这种语句直接写在描述里 Composer 会识别。

总结

Composer 2.5 + Build in Parallel 是 Cursor 把 IDE 从『AI 副驾驶』推向『工程师指挥的并行车间』的关键一步。比起单纯堆模型，这次升级更值得关注的是依赖图调度——它把『AI 写代码』从『下一个 token 预测』升级到了『DAG 执行引擎』层面。

如果你已经在用 Cursor，今天就把 IDE 升级到 3.3 + 开启 Build in Parallel；如果还在用其他 AI IDE，对比下『并行 + 自家模型 + 价格』三件套，再决定要不要迁移。

Sources:

• Introducing Composer 2.5 · Cursor Blog
• Cursor Composer 2.5: Benchmarks, Pricing - DataCamp
• Cursor’s Composer 2.5 - Artificial Analysis