并行不只是同时发起多个模型调用。两个智能体共享同一个工作器池、预算或文件系统时，并不因为提示词不同就相互独立。扩展之前，执行框架必须分类：每个问题读什么、写什么状态。
确定性问题是最好并行的——结果由代码拥有，模型调用彼此不纠缠。语义问题需要证据与后果分析。有副作用的问题需要租约、预算与回滚。
危险的模式是乐观并行：先跑多条投机路线，再试图调和它们产生的效果。这把一个调度问题变成了分布式一致性问题。除非效果幂等或被隔离，否则更安全的做法是：并行做评估，串行做执行。
每个并行 Jev 问题都应声明它的状态切片（state slice）。切片定义可以读哪些字段、可以写哪些输出、可以锁哪些资源。两个写入重叠状态的问题，没有协调者就不应并发运行。
状态切片应当成为决策回执的一部分。这样在故障之后，你才能说出每条分支用了哪个投影，以及陈旧数据或丢失更新是否破坏了结果。
快照有版本时，只读并行是安全的；写入则需要所有权。只做分类的问题可以扇出；会改变外部状态的问题需要更窄的并发预算。
| 状态字段 | 并行规则 |
|---|---|
| 只读快照 | 可安全扇出 |
| 实时工具状态 | 串行化或加租约 |
| 共享预算 | 原子化预留 |
| 产物存储 | 以唯一 ID 追加 |
| 副作用队列 | 同一时间一个所有者 |
共享预算、配额与外部凭据值得特别注意。两条并行路线各自看都合理，合计却可能突破速率限制、成本上限或用户的容忍度。预留必须原子化；超支应当让一条分支失败，而不是把两条都弄坏。
产物存储同样是共享状态。并行写入者需要唯一标识符、带版本的对象或追加式日志。「最后写入者获胜」的规则会悄悄掩盖那些产出了有价值证据的分支。
共享的工作器池会把看起来独立的问题耦合起来。一条路线长时间占用工具会话时，其他路线可能在它后面排队，耗尽同一个并发预算。容量隔离让一条坏分支的爆炸半径可控。
独立子问题的状态切片不相交、副作用不相交、没有顺序约束。例如：对三份互不相关的文档分别分类，可以扇出；先总结一份文档、再翻译那份总结，则不行。
独立性必须从状态访问证明，而不是从问题的表面措辞。两个「关于同一用户」的问题看起来独立，却可能都在写同一份档案。
workers@2 two worker leases
依赖路线需要排序或协调者。选项取决于前一次分类的检索问题必须等待。当依赖是语义的而非机械的时候，把这一对问题当作一个复合契约处理，中间设置检查点。
投机执行仍然有用：两个分支都评估，但只执行胜者。败者的副作用必须被抑制或保持幂等，且两次评估都记入回执，供校准分析使用。
并发测试应当包含：交错写入、预算耗尽、一条分支半途失败、部分效果之后的重试。顺序运行分支的测试证明的是逻辑，不是并行安全。
维护一个小的敌意调度库：以打乱的完成顺序和强制争用运行同一组问题。你要找的是非确定性的数据损坏，而不仅仅是慢吞吐。