读这一部之前，需要知道什么

第五部留下的不是一段“聊天记录”，而是一条有身份的 Thread。它在运行时有 live History，在磁盘上有 append-only rollout，在 SQLite / ThreadStore 里还有用于查找和列表的投影；resume、fork、Memory 与 Goal 又各自补上不同的连续性。app-server 能把这些状态变成协议对象，但它不是这些状态的最终 owner。

第六部从这条边界继续。现在交到手里的材料应该至少包含 ThreadId、当前 session/turn/item 状态和一条带 thread identity 的 typed notification。TUI 收到通知后，先判断它属于主 Thread、某个 side Thread、app scope 还是 global scope，再决定进入哪个 buffer 和哪个 ChatWidget。所以“终端里出现了一行字”只能证明最后一个投影结果，不能反推 Core 一定发过正确事件，更不能反推 rollout 已经写入。

固定版本的 TUI 会在 ChatWidget 之前完成 thread targeting。thread-scoped notification 进入主 Thread 或 side Thread 的队列；非法 thread_id 被忽略，app-scoped MCP startup notification 也不会落进当前对话。只有 global notification 才直接交给当前 widget。

ThreadEventStore 保存 session snapshot、turns、bounded buffer、pending interactive replay、active turn 和 composer input state。这是一份 UI ownership，不是第五部 rollout 的另一种叫法。切换 Thread 时发生的是有容量上限、有过滤规则的界面重放。

这一部负责讲清什么

前五章处理 runtime 的承载与协作面，第 36 章单独处理验证面。它们会互相产生事件、交接 identity 或留下观察结果，但没有一个总状态机能替代各自的 owner。

flowchart TB
  accTitle: Agent runtime 的承载、协作与证据边界
  accDescr: app-server 与 TUI、parent/child Threads、MultiAgentV2、Realtime、Hooks 和 evidence sinks 各有独立状态与生命周期，它们共同承载 Agent，但不构成一条单线流水线

  subgraph UI["UI projection"]
    APP["app-server\nthread-scoped notification"]
    TUI["TUI\nThreadEventStore / ChatWidget"]
    APP -->|"typed notification"| TUI
  end

  subgraph AGENTS["Agent graph and activity"]
    PARENT["parent Thread"]
    CHILD["child Thread"]
    MULTI["MultiAgentV2\nmailbox / steer / shutdown"]
    PARENT -->|"thread-spawn edge"| CHILD
    MULTI -->|"queue / trigger / activity"| PARENT
    MULTI -->|"queue / trigger / activity"| CHILD
    PARENT -.->|"communication"| MULTI
    CHILD -.->|"communication"| MULTI
  end

  subgraph REALTIME_STATE["Separate Realtime state"]
    REALTIME["RealtimeConversationManager\nConversationState / audio-text queues"]
  end

  HOOKS["Hooks\nten lifecycle contracts"]

  subgraph EVIDENCE["Evidence sinks"]
    WIRE["wire fixture / exact test"]
    TRACE["rollout-trace replay"]
    OTEL["OTel SessionTelemetry"]
    SCREEN["VT100 / terminal capture"]
  end

  PARENT -.->|"Core event"| APP
  CHILD -.->|"Core event"| APP
  REALTIME -.->|"handoff / text routing -> Op::UserInput"| PARENT
  HOOKS -.->|"session / turn / tool / compact / stop"| PARENT
  HOOKS -.->|"subagent lifecycle"| CHILD

  APP -.-> WIRE
  TUI -.-> SCREEN
  PARENT -.-> TRACE
  CHILD -.-> TRACE
  PARENT -.-> OTEL
  REALTIME -.-> OTEL
  HOOKS -.-> WIRE

图里唯一明确的 UI 实线是 app-server -> TUI。parent/child 实线表示 spawn topology，不表示 parent 要同步等待 child；MultiAgentV2 的双向活动也没有被画成 join。Realtime 位于单独的状态框里，只在源码已经定义的 handoff/text-routing 边界与普通 Thread 接触；steer 留在 MultiAgentV2 的 mailbox 语义里。Hooks 用虚线横切若干生命周期，但不会因此拥有 Thread、Realtime 或 TUI 状态。

最下面四个 evidence sink 也不是 runtime 的下一阶段。wire fixture、trace、telemetry 和终端投影从不同位置观察已经发生的行为；任何一条线都只能支持与它的采样位置相称的 claim。

六章共用哪套实验

第 31 至 35 章先按各自机制积累局部证据：TUI 使用相邻的路由与渲染测试，Subagent 保留身份表，MultiAgentV2 保留活动时间线，Realtime 区分两套 session，Hooks 使用逐事件矩阵。第 36 章才把这些局部证据统一收进证据账本（evidence ledger）。它先用 GuardianWarning 做最小样本，围绕同一事件类型和字段合同登记 Core emitter、app-server JSON-RPC serialization、TUI thread target、buffer/replay 规则和最后的 history cell。各项证据来自相邻但独立的 fixture，不能假装它们共享同一个运行时 thread_id 或同一条 message 实例。统一账本的格式是：

claim -> owner -> source range -> exact test or fixture -> observed sink -> unproven boundary

GuardianWarning 只在这里充当账本样例，不在导言重复做完整审计：Core emitter、app-server serialization、TUI target 和 ChatWidget render 各有独立 fixture，没有共享 event id 或 message 实例。四层测试、源码范围和中间缺失的 E2E 边界都留给第 36 章逐项对账。

第 32、33 章提供的是第 36 章随后要归档的 parent/child Thread 证据：parent identity、child ThreadId、AgentPath、history mode、persisted edge 和 mailbox activity。这里最容易写错的是 wait_agent。它订阅 InputQueueActivity，结果只有 mailbox、steer 或 timeout；child completion 只是可能进入 mailbox 的一类通信。

第 34 章保留普通 Responses 与 Realtime 两份记录。普通路径里，ModelClientSession 每 Turn 新建，只让本 Turn 持有新的 turn_state；它会从 session-scoped ModelClient 取走缓存的 WebsocketSession，销毁时再归还。因此，未关闭的连接和上一份 request/response 状态可以跨 Turn 借还，sticky token 不会跨 Turn。Realtime manager 另持有 audio/text channels、handoff state、tasks、active flag 和 cancellation token。两套状态只在源码明确的 handoff/text-routing 处关联，不能因为都使用 WebSocket 就合成同一个 session。

第 35 章先用十行 Hook matrix 分别登记 scope、matcher、payload、parser、mutation、block、additional context 和 error behavior。第 36 章再第一次把前五章的局部记录汇总成 evidence ledger，并尝试一个更强的本地任务：真实 codex exec binary 对 fake Responses provider 发请求，经顶层 exec code cell 调用嵌套的 tools.apply_patch，再检查文件副作用、rollout、resume --last 与 rollout-trace。

导读只规定这项实验必须交出的证据：固定 source 与 fixture identity，确认命名测试确实执行，区分 rollout JSONL 的文本观察和 trace replay 的结构化归因，并在结束后核对权威 checkout 没被测试污染。运行结果、请求与 trace 计数、内容 hash，以及这些记录究竟能证明到哪一步，都留在第 36 章现场核对。这里不先给出答案。

哪些机制暂时不讲

第六部已经是全书最后一部。“暂时不讲”不再表示后面还有一章会补完，而是明确列出仓库和本地 fixture 到不了的边界。

• 不用随机 live-model 输出做稳定合同。fake Responses server 可以固定 request、tool call 和 completed response，不能证明生产服务的可用性、配额、路由或模型质量。
• 不把 loopback Realtime 当成真实音频设备测试。固定版本的 WebRTC native 实现只在 macOS 编译；fake WebSocket round trip 也没有覆盖麦克风、扬声器、系统权限和真实网络抖动。
• 不把 Hook parser 通过当成外部脚本可靠。真实 command handler 仍受文件权限、shell、timeout、信任来源和脚本自身副作用影响；PostToolUse 看到的是已发生的工具结果，不能自动回滚副作用。
• 不把 persisted agent graph 当成 live process table。ephemeral child 可以保持 live 却不写 durable edge；interrupt、close 和 subtree shutdown 也有不同的状态与清理范围。
• 不把 OTel、rollout-trace 或截图当成彼此替代品。telemetry 可以关闭且默认隐藏 prompt；trace 只有在 producer 写出足够事件时才可 replay；VT100 和真实终端截图都只观察 projection。
• 不声称本册覆盖所有 client、shell、终端、操作系统和外部 provider 组合。平台 skip、running 0 tests、fixture 未构建和默认线程栈溢出都必须在实验记录里单独标出，不能算绿色证据。

WebRTC 的平台边界在 crate 入口处写得很直接：native module 只为 macOS 编译，其他平台调用 start 或 apply answer 都返回 UnsupportedPlatform。

读完这一部，你应该能做什么

给你一条“子 Agent 已经完成，但主界面没有反应”的报告，你应该能先问清是哪一种反应：child 是否发出 completion communication，parent mailbox 是否收到 activity，wait_agent 是否因 mailbox/steer/timeout 返回，app-server notification 是否带对 thread_id，TUI 是否路由到当前 Thread，还是消息只存在于另一个 side Thread 的 buffer。排查不再从截图猜调用链。

面对 Realtime 问题，你能先判断是普通 Responses transport reuse、Realtime conversation queue、WebRTC call、handoff 还是 app-server projection，再选择对应的 exact test。面对 Hook 问题，你能从十种 event-specific contract 中找到当前 parser 和 block/mutation 能力，而不是在一个想象的 middleware stack 里找顺序。

更重要的是，你应该能为一个完整本地 Codex 任务建立证据账本：

1. 固定 source identity 和实验输入；
2. 捕获真实配置入口与模型请求；
3. 观察工具调用和文件副作用；
4. 在 rollout 中找到 prompt、tool call、tool output 与 completed response；
5. 用相同 rollout identity 验证 resume append；
6. replay trace，确认 inference 与 tool-dispatch 的可归因关系；
7. 对每条 claim 写下尚未证明的外部边界。

这就是本部最后要建立的“分层系统验证能力”：不是收集尽可能多的绿色命令，而是知道某个行为由谁承载、证据在哪一层生成、哪一层仍然是空白。第 36 章会以这份账本收束全书，不再往后交给一个更大的抽象。

源码工作台

核心目录与 owning types

AgentRegistry 是 live session 共享的容量与 metadata owner；AgentGraphStore 是持久 parent/child topology 的 storage-neutral boundary。把两者拆开，才能解释“ephemeral child 仍然活着，但 durable child list 为空”。

MultiAgentV2 的 message tools 共用 submission path，差别只在 trigger_turn。send_message 使用 QueueOnly，followup_task 使用 TriggerTurn；两者都不是“同步执行对方并返回结果”。

Hooks 的公共 enum 恰好有十个 variant，但公共名称不等于公共 output contract。PreToolUse、PreCompact 和 Stop 的三个命名测试已经给出三个不同例子：deny blocks tool processing、continue:false stops before compaction、block reason becomes a continuation prompt。

OTel 与 rollout-trace 也不能合并。SessionTelemetry 允许 metrics exporter 缺席，user prompt 默认可被替换成 [REDACTED]；RolloutTrace 则保存 thread、turn、conversation item、inference、tool、terminal、compaction、interaction edge 与 raw payload identity，交给严格 reducer 重放。

第 31 至 35 章选取的命名测试与证据范围

下面只列第 31 至 35 章使用的局部测试。它是一张索引，不代表下面的命令会一次执行所有条目；Guardian 四层审计、rollout-trace 和本册 local E2E 在第 36 章单独列出和运行。证明范围 比“测试通过”更重要；同名 filter 如果显示 running 0 tests，或 test body 因 gate 提前返回，都没有提供表中证据。

spawn、fork 与 ephemeral 三条测试把 live Thread 和 durable graph 分开写进断言。尤其 ephemeral case 明确检查 persisted children 为空，同时 get_thread(child_thread_id) 仍成功。

Realtime 的两条测试都使用本机 fake WebSocket server，而且 test body 先调用 skip_if_no_network!。看到 Cargo 报 ok 还不够，必须确认 server handshake、response.create、session update、audio append 和 close 断言真正执行。

三条 Hook exact test 不能互相替代，因为各自 parser 的输出结构和允许动作不同。

实验准备与当前校准

固定 checkout 只负责 source identity。Rust 测试应在 disposable archive 或 detached worktree 中运行，使用外部 CARGO_TARGET_DIR，并记录固定 checkout 测试前后的 git status --porcelain 完全相同。这个 tag 的 workspace version 与 lockfile 需要在副本里离线校准；不要为了跑测试直接修改权威 checkout，也不要给 fake server 配真实凭据。

第六部使用自己的独立 bash 或 zsh，并要求 shell 支持 pipefail；不要沿用前五部的 ARCHIVE_DIR 或覆盖它们的 EXIT trap。请从博客仓库根目录运行下面的准备脚本，或预先把 BLOG_ROOT 指向该目录；脚本会在切入 Codex archive 前保存这个位置。第 31 至 35 章的局部 Rust 测试使用 archive，第 36 章的 handbook E2E runner 则显式切回 $BLOG_ROOT，再通过 --source-dir 创建 detached worktree。

set -euo pipefail

export BLOG_ROOT="${BLOG_ROOT:-$PWD}"
export SOURCE_ROOT="${CODEX_SOURCE_DIR:-/tmp/codex-handbook-final-rust-v0.144.6}"
export COMMIT=5d1fbf26c43abc65a203928b2e31561cb039e06d
export ARCHIVE_DIR="$(mktemp -d "${TMPDIR:-/tmp}/codex-part6.XXXXXX")"
export ARCHIVE_CODEX_RS="$ARCHIVE_DIR/codex-rs"
export CARGO_TARGET_DIR="$ARCHIVE_DIR/target"
trap 'rm -rf "$ARCHIVE_DIR"' EXIT

test -f "$BLOG_ROOT/package.json"
test -f "$BLOG_ROOT/scripts/verify-codex-handbook-e2e.ts"
test "$(git -C "$SOURCE_ROOT" rev-parse HEAD)" = "$COMMIT"
test "$(git -C "$SOURCE_ROOT" describe --tags --exact-match HEAD)" = rust-v0.144.6
test -z "$(git -C "$SOURCE_ROOT" status --porcelain)"
git -C "$SOURCE_ROOT" archive "$COMMIT" | tar -x -C "$ARCHIVE_DIR"

cd "$ARCHIVE_CODEX_RS"
cargo update --workspace --offline
cargo metadata --locked --format-version 1 --no-deps >/dev/null

命令按证据面分组，而不是拼成一条“全系统测试”：

: "${ARCHIVE_CODEX_RS:?先执行本部导读的 archive 准备脚本}"
cd "$ARCHIVE_CODEX_RS"
just test --locked -p codex-tui -E \
  'test(guardian_warning_notifications_route_to_threads) | test(live_app_server_guardian_warning_notification_renders_message)'

just test --locked -p codex-core spawn_agent_creates_thread_and_sends_prompt
just test --locked -p codex-core spawn_agent_fork_flushes_parent_rollout_before_loading_history
just test --locked -p codex-core ephemeral_spawn_does_not_persist_agent_graph_edge

just test --locked -p codex-core -E \
  'test(multi_agent_v2_followup_task_completion_notifies_parent_on_every_turn) | test(multi_agent_v2_wait_agent_returns_summary_for_mailbox_activity) | test(shutdown_agent_tree_closes_live_descendants)'

if [[ -n "${CODEX_SANDBOX_NETWORK_DISABLED+x}" ]]; then
  printf '%s\n' '拒绝运行：网络禁用标记会让 Realtime 测试提前返回' >&2
  exit 1
fi
just test --locked -p codex-core -E \
  'test(responses_websocket_v2_incremental_requests_are_reused_across_turns) | test(conversation_start_audio_text_close_round_trip)' \
  --no-capture

just test --locked -p codex-hooks -E \
  'test(permission_decision_deny_blocks_processing) | test(continue_false_stops_before_compaction) | test(block_decision_with_reason_sets_continuation_prompt)'

source_status="$(git -C "$SOURCE_ROOT" status --porcelain)"
test -z "$source_status"

2026-07-22 的本机校准结果如下：TUI 两条 exact test 各实际运行并通过；三条 Agent spawn/graph test 由项目 just test recipe 设置 8 MiB worker stack 后通过；MultiAgentV2 三条和 Hooks 三条也都由 just 实际运行并通过。Realtime 两条在运行前确认 sandbox network-disable marker 不存在，随后跑过 fake loopback；日志确认了真实 handshake / message activity，不是 test-level skip。第 36 章另行记录 Guardian、rollout-trace 和 local E2E，不把它们算进这段分章校准。

第 36 章的本地任务不并入这段分章校准。它需要单独核对命名测试、summary、rollout、trace 和 checkout 清理，再报告自己的结果；不能从上面这些相邻测试已经通过，提前推出完整任务也通过。

裸 cargo test 的默认线程栈下，部分 Codex Core exact test 会在 harness 中 stack overflow。项目 just test recipe 会设置 RUST_MIN_STACK=8388608 再调用 nextest；使用这个标准入口只是在本机排除测试环境噪声，不是业务修复，也不能省略测试名、running N tests、pass count 与 skip 日志。独立 CARGO_TARGET_DIR 仍可能因为随机临时 worktree 路径触发较大范围的 Rust 重编译；编译耗时不是 runtime 行为证据。

Feature 成熟度

固定版本把 CodexHooks 标成 Stable/default-on，把 MultiAgentV2 与 RealtimeConversation 标成 UnderDevelopment/default-off。两个后者即使在测试里完整走通，也不能写成稳定、默认可用的对外合同。

平台、fixture 与观察限制

工作台到这里停止。先从第 31 章：TUI 如何把事件流还原成一个稳定界面检查一条 thread-scoped notification；读到第 36 章：没有证据的“跑通”不算跑通时，再用 evidence ledger 审核全书最后那条完整本地任务。