以前用 Cursor 改一个大型功能，等它跑完的时间够喝两杯咖啡。现在不用等了——至少理论上不用了。
Cursor 今天上了两个功能，放在一起看比单独看有意思。
并行子代理："Build in Parallel"
点一下 "Build in Parallel"，Cursor 会先分析你的任务，识别出哪些子任务互相独立，然后同时跑。不是排队，是真正的并发。
想象一下你让它同时做这几件事：给 API 加三个新 endpoint、写对应的单元测试、更新前端调用。以前是一个接一个跑，现在是三个子代理同时开工。
这招对重构类任务尤其有效。改 A 模块不影响 B 模块的时候，并行执行的时间节省是线性的。
PR 自动拆分：从一团混沌到干净的 git log
并行跑完了，改动怎么合并？Cursor 现在能识别逻辑上独立的改动块，提出一个拆分方案让你审批，然后自动创建多个小 PR。
这比那种 "一次改了 47 个文件、commit message 叫 update" 的 PR 文明多了。每个 PR 只干一件事，review 的人也少掉两根头发。
另一个信号：/orchestrate
同一天，Cursor 还发布了 /orchestrate skill——可以递归地生成子 agent 来处理更复杂的任务。他们自己用它来自动研究内部 skills，token 用量降了 20%，评估分数还提高了。内部后端冷启动时间砍了 80%。
递归生成 agent 这件事本身不新鲜，但 Cursor 把它做成了一个开箱即用的 skill，降低了使用门槛。
我的看法
这两个功能加在一起，Cursor 正在从一个 "帮你写代码的助手" 变成一个 "可以分派任务的工程团队"。
之前有人总结过：Claude Code 是短生命周期的 coding agent，单线程异步循环。Cursor 现在的路径更像是在搭建一个可以多任务并行的工程环境。
实际效果要看几个东西：
- 并行子代理的上下文隔离做得好不好——如果子代理之间互相干扰，那还不如串行
- PR 拆分的逻辑是否靠谱——拆得太细会变成 PR 海啸，拆得太粗失去了拆分意义
- 资源消耗——多个子代理同时跑，token 用量会不会爆炸
我的直觉是，对小项目来说收益有限，对中型以上项目的重构和大规模改动，这个功能会省下不少时间。
下次大改之前，值得先试一下 "Build in Parallel"。
主要来源：