第七章：Codex 的输入通道、步骤快照与执行编排

7.1 接受输入不等于立即调用模型

CodexThread::start_or_steer_turn() 把请求交给带模式的会话输入提交逻辑。方法名里的 start 或 steer 反映了一个重要问题：输入到达时，系统可能空闲，也可能已经在执行。宿主必须先决定输入怎样进入活动状态。Codex · codex_thread.rs L415–429

沿上游导读与实际文件，可以继续追踪会话提交、TurnInput 处理、普通任务到 run_turn()。本章把这条主线作为定位路线，不声称它就是没有其他辅助层的完整调用栈。Codex · turn.rs L171–185

7.2 Turn 之内还需要一致的步骤视图

一次用户任务可以包含多次模型生成、工具调用、追加输入和上下文工作。run_turn 维护本轮执行条件，再在请求时使用步骤相关上下文。读取工具路由时，可以看到它持有模型可见规格以及匹配的执行注册表。Codex · router.rs L83–97

这种一致性很重要：模型是在某一步看到一份工具说明后提出调用的。即使调用实际执行得较晚，也不应该悄悄用另一份工具语义解释它。ToolCallRuntime 保存对应 StepContext 的源码注释，直接说明工具列表与后续执行需要关联。

对自己的实现，可以把这一点简化为：每份请求绑定一个不可变工具快照，并保存版本号。工具注册更新只影响下一份请求，或者通过明确的迁移规则处理，不能无声改变已接受调用的含义。

7.3 是否继续由真实状态决定

run_turn 中有一个直观判断：model_needs_follow_up || has_pending_input。它说明下一步不只由模型输出决定，待处理输入也可以让工作继续。完整结束判断还涉及预算、取消与其他机制。Codex · turn.rs L608–622

这对理解代理“自主性”很有帮助。宿主不是被动地一直请求到模型说停，而是根据多个状态源决定继续、暂停或结束。运行中的用户纠正、工具产生的新信息，以及任务预算，都是调度输入。

7.4 工具执行跨过多个边界

ToolRouter 解决调用身份、可见规格和注册分派。ToolOrchestrator 则协调审批、沙箱选择以及受限执行失败后的重试。它的文件开头特别指出：审批针对已审查的权限，升级执行权限需要重新审查重试。Codex · orchestrator.rs L1–13

这不是一个通用的“失败后再试一次”。网络抖动下重发模型请求，与放宽权限后重新运行命令，具有不同的授权与副作用含义。研究重试时，要把动作身份、权限范围和结果未知一并考虑。

7.5 长进程需要可继续的句柄

统一执行模块中的 write_stdin 接受已有进程交互请求，并区分 yielded、exited、cancelled 与 failed 等结果。这里的 yielded 表示进程工作尚未结束、调用暂时让出控制，不应当作成功退出。Codex · process_manager.rs L877–891

一个系统如果支持长时间构建或服务启动，就需要保存进程身份、输出状态和终止路径。只保存“曾经运行过命令”不足以继续等待，也不足以防止恢复时重复启动。句柄是否仍然有效，要向执行层确认。

练习：沙箱限制导致命令失败，是否可以自动改成更大权限继续？不能从这次失败直接推出新授权。应由实际策略与审批流程确定，而且要核对首次尝试是否可能留下部分副作用。