第 6 章：委派、验证与持久状态 — 谁来防止系统自己给自己打高分
出处
来源：原网页 · 状态：已读 · PDF：book2-comparing.pdf p.31–33
一句话
多代理的真正问题是责任，不是扩编。 两边都试图避免系统自己给自己打高分：Claude Code 靠角色分离与验证纪律，Codex 靠显式接口、线程状态与协作记录。verify 是独立纪律，不是礼貌动作。
核心概念
扩编式效率叙事掩盖了真正难点：多出来的责任如何切分。同一套系统若兼做执行、总结、验收并自评，结论往往只是宽慰。系统不愿让「完成」由执行代理自己宣布。
Claude Code 把 explore / execute / synthesis / verification 拆开。多代理绕主循环与任务推进运转：主代理不该包办一切，更不该边干边验。用途是探索外包、执行分流、synthesis 汇总、verification 独立复核。它被收进「当前这轮怎么推进」的治理里，而不是先搭 agent platform 再塞任务。
Codex 把委派定义成工具接口，多代理更像正式子系统。create_spawn_agent_tool_v*、create_wait_agent_tool_v*、create_send_message_tool、create_close_agent_tool_v* 把委派做成正式工具。agent_tool.rs 里 spawn_agent、send_input、wait_agent、close_agent 各有 schema：send_input 用 interrupt=true 立即打断、默认排队；wait_agent 有 default/min/max timeout；close_agent 连 open descendants 一起关。抢占、等待、收尾都是协议字段——更适合当平台能力长期维护。
验证流于形式的一个主因，是系统没有足够好的状态承接。上一步做了什么、为何、哪些工具与文件动过，若只停在执行者脑子里，复核就缺材料。Claude Code 让会话状态、工具结果、恢复分支在 runtime 连续可见，配合独立验证压低自我美化。Codex 用 thread、rollout、message history、state DB bridge 给复核提供结构化证据。前者补现场沉浸，后者补协作必须留痕。
Claude Code 盯 task cleanup、父子 abort 传播、subagent lifecycle hook——多代理是运行时现场，出事必须及时收口。Codex 把代理生命周期纳入显式状态与调用协议，关心委派作为系统事件如何留存。前者像现场总工，担心人散场后地上还留坑；后者像带项目管理系统的组织者。
调用顺序：spawn_agent → 循环 send_input（interrupt 立即/排队）→ wait_agent（min/default/max）→ close_agent(cascade=true)。故障矩阵：父 abort 级联到子并写 rollout；wait_agent 超时关 handle；interrupt 丢队列注入新输入；close 级联后代；子崩溃返回 error 但保留 thread；finalize 强制 close，不允许悬挂句柄。
关键洞察
Claude Code 的多代理设计更强调运行时职责分离与现场收尾，Codex 的多代理设计更强调工具化委派、状态承接与可审计协作。二者都试图避免系统自己给自己打高分。没有持久状态，验证就只是礼仪；没有独立 verifier，完成就会退化成「已经写完并且我觉得没问题」。
个人思考
Book 1 第 7 章已经把并行的价值写成职责更清楚，而不是人海战术。这一章补上：职责清楚之后，证据放哪。自己写多 agent 最常见的半成品是「能 spawn，不能 close」——子代理成功了没人收，失败了没人认，超时了还占着上下文。Codex 把 cascade close 写成协议字段，就是在防这件事。