同时派出多个 fork 子代理时，它们终于分得清「哪件事是我的」
fork 子代理是从当前对话分叉出去的一路，会带着主对话已有的上下文去另一条线上把事情做完。在 fork 子代理默认开启 之后，一个常见用法是：主对话把一个大任务拆成几块，一口气同时 fork 出好几个子代理并行处理。
问题出在「上下文太像了」
fork 的优点是继承上下文，麻烦也在这里。几个 fork 同时从同一个时刻分叉，它们看到的对话历史几乎一模一样——包括主对话「我要启动 A、B、C 三个 fork」这一段。于是某个 fork 可能分不清自己到底是 A、B 还是 C：
- 负责 A 的 fork 顺手把 B 的活也做了；
- 两个 fork 改了同一批文件，结果互相覆盖；
- 甚至有 fork 以为自己是主对话，试图再去启动其他 fork。
2.1.307 的改进
CLI 2.1.307 的更新说明里写道：改进了一起启动的 fork 子代理——每个 fork 现在会被告知哪一次启动是它自己的，因此 fork 去尝试开始彼此工作的可能性大大降低。
也就是说，每个 fork 拿到的不只是共享的历史，还有一个明确的「你是这一个」的标记。它知道自己该接哪一块，对其他几块只是知情，不去插手。
官方用的说法是「much less likely」，即大幅降低而不是彻底杜绝。所以拆分任务时的基本功仍然值得保留。
拆分任务时的几点建议
- 按互不重叠的范围切：按目录、模块或文件清单分配，尽量避免两个 fork 碰同一个文件；
- 每块写清交付物：例如「只修改
src/api/，完成后汇报改了哪些文件」，比「去处理接口部分」可靠得多； - 让主对话负责合并：fork 各自汇报，由主对话检查冲突、统一收尾，而不是让 fork 之间互相协调；
- 有先后依赖的别并行：B 依赖 A 的结果时，顺序执行反而更快。
适合并行 fork 的场景
- 给多个独立模块分别补测试；
- 同时调研几种实现方案，各自写一份结论；
- 对一批互不相关的文件做同类修改，比如统一替换已废弃的 API。
小结
- 2.1.307 起，同时启动的多个 fork 子代理各自知道哪次启动属于自己；
- 互相抢活、重复劳动的情况会少很多，但仍建议按互不重叠的范围拆分任务；
- 合并和冲突处理交给主对话，是并行 fork 最稳的用法。