上个月你给后台提了一个需求：把订单导出做成三种格式，再加一个按时间筛选的条件。放以前这是一个下午的活，现在你把需求丢进编辑器，让它同时开多个会话分头去写。十几分钟后你面前摆着四份改动，每一份看起来都像模像样。你以为省下的是一个下午，结果整个晚上都花在同一件事上——判断第三份到底有没有把原来的接口改坏，以及四份之间究竟该留下哪一份。这种体验并不是工具不好用，而是你把一件需要做判断的事，当成了可以并行分发的事。写代码可以并行，决定留哪一份不行。
Cursor 2.0的更新说明写得很直接：针对同一个提示，最多可以并行运行八个智能体，侧边栏集中展示你的智能体和计划。做法是用git worktrees或者远程机器来避免文件冲突，每个智能体都在自己独立的代码库副本里运行。换句话说，并行不是把同一份代码交给八个进程去改，而是先切出八份互不干扰的工作区，各自改完再合回来。
为什么非要这么设计？因为文件冲突这件事，靠提示词是解决不了的。两个智能体同时改同一个文件，最后谁覆盖谁完全不可控，而且这种覆盖往往不报错，只是安静地把对方的一段逻辑吃掉，你可能过了两天才发现某个分支判断不见了。用独立副本的办法，把冲突从运行期的偶发事故，挪到了合并期的显式动作——冲突还在，但它变得可见、可处理了。这也是为什么这类工具都在往隔离环境上使劲，而不是往提示词约束上使劲。提示词能约束的是行为方式，约束不了两个进程同时写同一份文件这个物理事实。
不过独立副本有它的账单。每个工作区都要把项目完整拉一份，依赖装一遍，构建产物各存一份。一个依赖两三百个包的项目，第一次把八个工作区都拉齐，磁盘占用和等待时间都不算小。如果你的项目本身就轻，这不算什么；如果是那种装依赖就要十分钟的老项目，开八个并行之前最好先想一下值不值，尤其当你只是要改几行文案的时候。
这次同步推出的还有Composer，官方称是首款具备智能代理能力的编程模型，在同等智能水平下速度提升4倍，多数交互能在30秒内完成。这个数字要放对位置看：它说的不是猜得更准，而是等得更短。对一个要连续走十几个来回的任务来说，单次等待从两分钟压到三十秒，体感差别比想象中大。它更像是把交互节奏调顺了，而不是把难度降下来了。另外要留意的是，这个模型是绑在它自己的环境里的，能力再强也是冲着这个编辑器的工作流设计的，不是说把它单独拎出来就能替代你现有的整套工具链。
并行的瓶颈不在写代码，在验收
比并发数字更值得留意的是沙箱终端。2.0起在macOS上默认在安全沙箱里运行智能体命令，不在允许列表里的shell命令自动进沙箱，对工作区有读写权限，但拿不到互联网。这条在多个智能体同时跑的时候格外重要：八个智能体，等于八倍的命令在无人盯着的情况下执行。原先你可能对某条命令会不会误伤什么还有意识，并发起来之后，这层意识很容易被稀释掉。
官方在发布说明里承认了一件事：随着更多用智能体写代码，出现了两个新瓶颈——审查代码和测试改动，2.0里同时在这两件事上做了改进，比如更容易一次性看完多个文件的改动，以及内置的浏览器工具能让它自己试着跑一遍、看到结果不对再改。工具方肯承认瓶颈转移，说明这已经是个普遍现象：写变便宜了，看和验并没有跟着变便宜。
官方还提到一个反直觉的观察：让多个模型同时尝试同一道难题，再挑最好的结果，最终产出会明显更好。这不等于多开几个就更强，它之所以有效，是因为你多了可以比较的样本。代价同样清楚——成本翻了几倍，而且挑的过程需要你有能力判断。判断力不够的时候，八个结果和八个噪音之间没有区别。更实际的判断依据是任务的可验证程度：有明确通过标准的任务，比如测试能不能跑绿，多开几个比一比是值得的；标准模糊的任务，比如这个交互好不好用，多开几个只会让你更纠结。
所以真要用并行，先按任务性质分个类。适合并行的，是面大但彼此独立、互不牵扯的活，比如把三十个页面的文案统一成一种语气、给几个模块补上缺失的测试、把散落各处的日志格式调成一套。不适合并行的，是那些动同一个抽象层的改动——同一个核心函数、同一套状态管理、同一份配置结构。这类改动越并行越乱，因为它们的成败本来互相耦合。
多智能体把写代码变成了便宜资源，这是真的。但它顺手把稀缺位置挪了：现在真正卡人的，是能不能把要什么说得足够清楚，以及有没有能力在几份看起来都不错的产出里，认出哪一份真的对。前者决定并行有没有意义，后者决定并行省下的时间会不会原样还回去。工具能同时开八个，能替你做决定的还是只有你自己。所以开并行之前，先问自己一句：这几份产出我有没有办法在三分钟内分出高下。答不出来的话，先把任务拆清楚，比多开几个会话有用得多。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
