当你需要比较策略、分析选项或评估方案时，在一个会话中顺序探索会产生有偏差的结果。先探索的选项会锚定 agent 对后续所有选项的评估。fork_session 通过从共享基线创建独立分支来消除这个问题。
机制
fork_session 取一个现有会话，创建一个新的独立分支。原始会话和 fork 都继承到 fork 点为止的完整上下文。之后它们独立发展——一个分支中的工具调用、推理和结论不影响另一个。
可以 fork 两次以上。三种竞争的架构方案？从共享的代码库分析 fork 三个分支。每个在隔离中探索一种方案。
锚定偏差问题
一个客服系统在同一个会话中顺序评估两种解决方案：
- 方案 A（先探索的）：在 85% 的案例中被评为”推荐”
- 方案 B（后探索的）：在 90% 的案例中被评为”可接受但不如 A”
- 颠倒顺序后：方案 B 更多时候被评为”推荐”
偏差跟的是位置，不是质量。顺序评估导致锚定——agent 承诺于先探索的方案，然后以它为参照评估其他所有方案。这是结构性的污染，不是 prompt 设计问题。
数据：fork vs 顺序
| 方法 | 专家一致度 | 成本 |
|---|---|---|
| 顺序（一个会话） | 62% | 1.0x |
| Fork（独立分支） | 89% | 1.8x |
在相同策略对上 27 个百分点的准确率差距证明了 fork 评估消除了锚定。1.8x 的成本增加是合理的——错误的策略选择造成的下游成本远超评估开销。
什么时候 fork，什么时候 resume
Fork — 用于发散探索。比较策略、评估替代方案、测试不同分析框架。关键测试：探索 A 的推理是否会污染对探索 B 的评估？如果是 → fork。
Resume — 用于线性跟进。澄清、深入、同一主题的迭代。跟进基于之前的上下文而非从中分岔。
某系统过度 fork：每个研究任务 12 个 fork，但只有 3 个是真正发散的——另外 9 个是简单澄清。每个不必要的 fork 花 1.8x 而 resume 只要 1.0x。修复：只在发散探索时 fork，其他都 resume。
干净对比的规则
不要在分支间共享发现。 跨分支的信息流会重新引入 fork 设计要防止的污染。每个分支独立探索。
不要在一个会话中顺序探索。 即使有显式指令”独立评估”，agent 对方案 A 的推理会成为方案 B 的上下文。偏差是结构性的，不能靠 prompt 纠正。
用一个全新的协调者做综合。 Fork 分支完成后，在一个没有参与任何分支分析的协调者会话中比较它们的输出。参与了某个分支的协调者会偏向它。
用例
- 架构比较：fork 3 个分支——微服务 vs 模块化单体 vs 事件驱动 → 独立评估 → 全新协调者推荐
- 依赖升级评估：从当前分析 fork → 在 fork 中探索升级影响 → 原始会话保留完好用于对比
- 研究框架：从共享数据 fork → 经济分析、权利分析、创新分析 → 比较结论
- 重构策略：从代码库分析 fork → 提取库 vs 插件架构 → 比较权衡
顺序探索不总是错的
如果你不需要独立评估——如果任务是逐步构建理解而不是比较替代方案——在一个会话中顺序进行或 resume 就够了。Fork 的开销（1.8x 成本）只在锚定偏差重要时才值得。
一句话总结： Fork 消除锚定偏差（策略比较中 89% vs 62% 准确率），成本 1.8x 但防止错误决策——只在发散探索时用 fork，线性跟进用 resume，分支间绝不共享发现。