第 6 章 委派、验证与持久状态：谁来防止系统自己给自己打高分
6.1 多代理的真正问题是责任
一听多代理就想到效率提升，像听公司扩编——其实真正棘手的从来是多出来的责任怎么切。若同一系统既执行又总结又验证，还顺手给自己写评语，结论多半令人宽慰但不可靠："干得不错"。Claude Code 清醒地把 explore、execute、synthesis、verification 拆开，verify 是独立纪律而非礼貌动作——系统不愿让"完成"由执行代理自己宣布。Codex 也走这条路：tools/src/lib.rs 里 create_spawn_agent_tool_v*、create_wait_agent_tool_v*、create_send_message_tool、create_close_agent_tool_v* 说明委派是正式工具能力，不是黑魔法。
6.2 Claude Code：多代理服务于运行时职责分区
Claude Code 的多代理围绕主循环和任务推进展开——主代理不该什么都自己干，尤其不该既干活又验收。因此多代理主要用于：探索外包、执行分流、synthesis 汇总、verification 独立复核。这很符合它的强项在运行时编排——多代理被纳入"当前这轮怎么推进"的治理框架，而不是先有 agent platform 再往里塞任务。
6.3 Codex：多代理服务于显式工具化协作
Codex 把委派定义成工具接口，多代理更像正式子系统。两个直接影响：委派动作更易被记录、审计和组合（显式工具调用，不是 runtime 魔法）；协作更易与线程、状态和审批体系对齐（thread/rollout/policy 本就一等公民）。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 一起关闭——抢占、等待、收尾都是协议字段。适合做成平台能力，不见得更灵巧但更易长期维护。
6.4 持久状态让验证不只是礼仪
验证流于形式的一个主因是系统没有足够好的状态承接——上一步干了什么、为什么、哪些工具动过、哪些文件变过，若只在执行代理脑子里，验证就容易沦为貌似认真实则缺材料的表演。Claude Code 让会话状态、工具结果和恢复分支在 runtime 里连续可见，配合独立验证纪律降低自我美化。Codex 通过 thread、rollout、message history、state DB bridge 给验证提供更清楚的材料基础。二者并不冲突——前者补执行者过于沉浸现场的问题，后者补系统协作必须留下结构化证据的问题。
6.5 对恢复与收尾的不同态度
Claude Code 很在乎 task cleanup、父子 abort 传播、subagent lifecycle hook——在它的世界里，多代理首先是运行时现场的一部分，出问题必须能及时收口。Codex 则把代理生命周期纳入显式状态管理和调用协议：不只关心"子代理死没死"，还关心"委派行为作为系统事件该如何留存"。前者像现场总工，担心人散场后地上还留坑；后者像带项目管理系统的组织者，担心每个协作动作是否进入记录体系。
骨架：Codex 代理委派协议 (skeleton)
// 骨架: agent_tool.rs spawn/wait/send/close
handle = spawn_agent { role, prompt, timeout, inherit_approval }
for msg in updates:
send_input(handle, msg, interrupt ∈ {true, false}) // true=立即打断, false=排队
result = wait_agent(handle, timeout ∈ [min, default, max])
close_agent(handle, cascade=true) // 连同 open descendants 一并关闭
孤儿与超时故障矩阵
| 事件顺序 | 前置状态 | 触发 | 下一步 | 阈值 |
|---|---|---|---|---|
| 父代理 abort | 子代理在飞 | parent.abort | cascade abort 传到 handle；写 rollout 事件 | — |
wait_agent 超时 |
子代理未返回 | timeout ≥ max | 关闭 handle，返回 timeout 结果 | wait_agent.max |
send_input(interrupt=true) |
子代理排队中 | 抢占 | 丢弃队列，注入新输入 | — |
close_agent |
有 open descendants | 显式关闭 | 级联关闭所有后代 | cascade=true |
| 子代理崩溃 | — | 异常退出 | 返回 error，保留 thread 记录 | — |
| handle 泄漏 | 任务结束未 close | finalize | 强制 close + evict | 不允许悬挂句柄 |
6.6 本章结论
这一章的结论不难写：
Claude Code 的多代理设计更强调运行时职责分离与现场收尾，Codex 的多代理设计更强调工具化委派、状态承接与可审计协作。
二者都试图避免系统自己给自己打高分。
只是 Claude Code 更靠角色分离和验证纪律。
Codex 更靠显式接口、线程状态和协作记录。
最后一章，我们把前面六章压成总判断，回答书名里的问题：究竟是殊途同归，还是根本不同种。