对模型说随便并行，底下用锁管住
模型看见的、实际执行的、历史记录的，是三套顺序。一面旗允许一次发多个调用，一把读写锁决定谁能叠着进。
- build_prompt 把并行旗写成 trueturn.rs L1321
- 编请求时和 Lite 标记做与client.rs L952
- 路由查注册表，没有就当 falserouter.rs L137
- Hidden 即使自称并行也当串行registry.rs L472
- 先 spawn，再等就绪，最后拿锁parallel.rs L144
- 能并行就 read，否则 writeparallel.rs L152
- 结果按 FuturesOrdered 插入顺序入账turn.rs L2135
你让模型同时读 src/main.rs、读 src/lib.rs，再打一处补丁。屏幕上两份读文件几乎同时出进度，打补丁那一下却停了一拍。
如果运行时把可以并行理解成这些调用叠着跑，两个 apply_patch 会一起改共享的 diff 记账，账会乱。如果这些调用首尾相接，两个读文件也要排队，多耗一轮墙钟。请求侧那面旗只回答模型愿不愿意一次发多个盒子，回答不了盒子落地时谁能重叠。
发给模型的旗写在 Prompt 上。字段默认是 false，采样主路径走 build_prompt，把旗写成 true。编成 Responses 请求体时，再和模型是不是 Responses Lite 做一次与。Lite 上这面旗关掉。压缩那两条组包路径也写死 true，为的是和主采样请求的形状对齐，websocket 复用会逐字段对比，其中就包括这面旗。
出处：codex-rs/core/src/session/turn.rs 第 1312 至 1328 行 · codex-rs/core/src/client.rs 第 946 至 953 行
执行侧另有一张表。ToolExecutor 默认 supports_parallel_tool_calls 返回 false。漏写覆盖就走写锁。exec_command、view_image、tool_search 覆盖成 true。apply_patch 不覆盖。路由先查注册表，查不到当 false。曝光是 Hidden 的，handler 自己返回 true 也没用。MCP 还要服务器开关或只读提示，缺省仍是串行。
出处：codex-rs/tools/src/tool_executor.rs 第 122 至 124 行 · codex-rs/core/src/tools/registry.rs 第 470 至 473 行
模型只看见 parallel_tool_calls 为 true 或 Lite 下的 false。它看不见谁能并行。工具清单也不会因为某个工具其实要拿写锁而少掉一项。
对模型的许可以和宿主调度拆开，换语言重写也用得上。请求侧只回答愿不愿意一次发多个调用。执行侧只回答这一次能不能和别人重叠。Lite 测试把旗关掉，说明作者接受某些模型路径上失去这层提示。闸门始终在。模型如果仍在一条响应里发出两个调用，两个任务照样 spawn，照样按本地表拿锁。
分类对了，还要有人看门。两个读可以共存，一个写必须独占。若先握住锁再等 MCP 服务器连上，一次冷启动会让旁边已经就绪的 exec_command 也卡住。
还有公平性。若后来的读者能从写者头顶上翻进去，补丁可能一直拿不到锁。换成标准库那把 RwLock，优先级依赖操作系统，写者有机会被饿死。
一次采样共用一把 tokio::sync::RwLock<()>。锁保护的值是单元类型，里面没有业务数据，只当闸门。任务先 spawn，可选地等就绪，再拿锁。能并行就 read，否则 write。就绪等在锁外面。一个还没连上的 MCP 服务器，不会占着写锁让旁边的 shell 也卡住。
出处：codex-rs/core/src/tools/parallel.rs 第 144 至 156 行
这把锁的优先级是 fair，也叫 write-preferring。已经排队的写请求没拿到、没释放之前，后面的读锁不会发下去。一个 view_image 还在跑，apply_patch 已经在门外，再来的 exec_command 明明可以和 view_image 重叠，却必须排在补丁后面。fair 换来的是写者不会饿死，代价是后来的读者被写者隔开。
分类粒度是工具实例，看不到这一次的参数。exec_command 无论跑 ls 还是 rm，都走读锁。apply_patch 无论补丁多大，都走写锁。两个无关的串行工具也会互相挡住。检索业务代码，没有容量上限。十个 shell 可以一起进。容量交给进程、沙箱和操作系统。
问的是这一刻有没有独占者。餐厅可以多人同时看菜单，只准一人进后厨。公平策略写在锁的实现里。业务代码只问并行还是独占。换一把会让新读者插队的锁，写者就有机会被饿死。把就绪等待放在锁外面，也是同一类判断：还没准备好的人，不要占着门口。
两个 exec_command 叠着跑，后发出的可能先跑完。若按完成顺序写历史，模型下一轮看到的结果顺序会和它发出的调用对不上。流内每到一条 OutputItemDone 就建 future，那一套管的是何时开工。这里管的是开工之后谁能重叠，以及结果按什么顺序入账。
采样循环把 tool_future 按到达顺序推进 FuturesOrdered。drain 按插入顺序出队，再写入会话。读锁让两个 shell 叠着跑，入账仍按发出顺序。先发出的先入账，哪怕它其实更晚跑完。
出处：codex-rs/core/src/session/turn.rs 第 2130 至 2140 行
观测顺序和执行重叠从结构上分开。并行只改墙钟，不改账本。自己做 Agent 时，至少把这两条队列分开写。对模型说可以并行，跑工具时再看本地表，结果仍按调用列表的原顺序收下。
DeepSeek Harness：按参数分类，独占当屏障
DSH 让每个工具提供 isConcurrencySafe(args)。只有精确的 true 才加入并行。缺声明、参数不合法、分类器抛错，都是独占。bash 没有分类器，整条独占。调度器等完整消息到齐，连续的并行调用编成一组，每个独占调用单独成组当屏障。组内滚动池，上限默认 10。
Codex 可以没有这套分组，因为它把判断压成工具级布尔，再用一把锁模拟屏障。DSH 能让只读的 bash 仍然串行，少掉一部分并发。Codex 能让两个 ls 叠着跑，两个 rm 也可以叠着跑。
Claude Code：按参数分批，只读 bash 才并行
Claude 的 isConcurrencySafe 默认返回 false。BashTool 把并行交给 isReadOnly：命令通过只读约束才返回 true。ls 可以进并行批，带写副作用的命令进串行批。连续的安全调用收成一批走并发，不安全的每个自成一批，一批里也是一个接一个。上限来自环境变量，解析失败时是 10。
Codex 的 exec_command 省掉命令解析，写命令也进读锁。三边都把调度元数据藏在宿主，闭合的位置不同。Codex 闭合在默认值和 Hidden，对 shell 最放开。DSH 闭合在分类器，bash 全串行。Claude 夹在中间。
后到的读能不能插队
view_image 还在跑，apply_patch 已经在门外排队。这时模型又发出一个 exec_command。演示里切到后到的读，单步走完，对照下面三问。
exec_command 能不能和还在跑的 view_image 叠着跑。apply_patch 的窗口改成读牌，闸门还会不会把它单独拦住。