11. 真实任务走读：修复测试失败¶
本章以“修复测试失败”为例串联 Codex 智能体的运行机制。该任务从用户输入开始，经过轮次创建、上下文构造、模型采样、工具执行、权限检查、结果回填、再次采样和最终收束。
输入进入轮次¶
用户在终端界面或一次性执行中提交“修复测试失败”。入口层将输入提交为 turn/start 请求，请求中可能同时包含当前目录、模型、权限、环境变量和输出格式等本轮配置。
会话收到请求后将其排入队列。当前没有活跃轮次时，会话创建新的轮次上下文并启动普通任务；当前存在活跃轮次时，输入可能作为待处理输入注入当前任务。
这个阶段建立任务边界。后续所有模型采样、工具调用、权限审批和事件都归属于该轮次，直到运行时发出轮次完成、失败或中断。
运行现场固定¶
普通任务启动后，运行时固定本轮现场。现场包括工作目录、模型、项目规则、权限边界、审批策略、沙箱、网络策略、可用工具、技能、插件和输出格式。
该现场同时影响模型上下文和工具执行。模型会看到权限和项目规则，本地工具运行时也按相同规则执行或拒绝动作。
运行现场固定后，模型不能通过文本修改权限，工具也不会从入口层重新读取临时配置。目录、权限和工具集合以轮次上下文为准，保证多轮采样期间规则一致。
模型上下文构造¶
轮次运行构造模型输入。模型看到当前用户目标、历史、项目规则、权限说明、环境信息、可用工具、显式触发的技能以及可能存在的长期记忆。
首次真实轮次注入完整规则，后续轮次主要注入变化。上下文构造结果进入历史和持久化记录，使后续采样、恢复和分叉保持现场连续。
上下文中包含可见工具规范，因此模型知道能够请求运行命令、读取文件或应用补丁。上下文中也包含权限说明，因此模型能够在只读或需审批环境下调整策略。
首次模型采样¶
模型基于上下文选择第一步。修复测试失败的常见路径是先复现失败，因此模型会请求 shell 工具运行测试命令。
模型此时只提出工具调用。命令尚未执行，本地运行时需要解析调用并进入权限链路。
工具调用会以结构化条目进入模型事件流。运行时等待完整参数到达后再解析命令，避免在参数尚未闭合时执行本地动作。
权限检查与测试执行¶
shell 处理器解析命令参数。权限系统结合权限配置、审批策略、执行策略和沙箱策略判断命令是否可执行。
当前策略允许时，测试命令在受控环境中执行。需要更高权限时，运行时发出审批请求或交给守护复核。审批被拒时，拒绝信息会写回模型上下文。
普通测试失败表现为命令退出码非零和错误输出，属于工具结果，不属于权限失败。
权限拒绝与测试失败的差异会影响后续模型行为。测试失败推动模型分析代码；权限拒绝推动模型请求授权、缩小操作范围或说明限制。
失败分支也会进入同一条回填链路。命令参数不合法时，工具结果会说明解析失败；沙箱阻止时，结果会说明动作被隔离层拦截；用户拒绝审批时，模型下一轮只能换成受限方案或向用户说明无法继续。这些结果不是旁路日志，而是下一次采样的正式输入。
测试输出回填¶
测试结束后，标准输出、标准错误、退出码和错误信息写入历史，并通过事件流展示给客户端。下一次模型采样会读取这些工具结果。
模型因此获得具体失败事实，例如失败测试名称、断言差异、编译错误、snapshot 变更或堆栈位置。后续分析基于真实执行反馈。
工具输出同时服务客户端和模型。客户端实时看到命令输出，模型在下一轮采样看到结构化工具输出。实时事件和历史记录来自同一次执行，但分别服务展示和推理。
文件读取与定位¶
模型根据失败输出选择读取相关文件。读文件可以通过 shell、文件查看工具、MCP 或连接器完成。读取结果进入历史，供下一次采样使用。
模型逐步建立失败与代码之间的关系：失败位置、相关实现、测试期望、最小修改范围、公共 API 影响和是否需要更新 snapshot。
读取文件可能发生多轮。模型可能先读取失败测试，再读取被测实现，再读取相关类型定义。每次读取结果都会回填历史，使模型逐步缩小修改范围。
修改生成与应用¶
模型定位问题后可能生成补丁。补丁进入本地安全评估，运行时检查修改路径、写入范围、权限、沙箱约束和审批要求。
评估通过后，补丁应用到工作区。应用结果、差异和相关事件写入历史与事件流。评估失败时，拒绝原因写回模型，模型需要调整方案、请求权限或说明限制。
差异事件使客户端看到工作区变化，补丁结果使模型知道修改是否成功。二者不完全相同：差异面向展示和审查，工具输出面向下一轮模型推理。
待处理输入介入¶
任务运行中用户可能追加限制，例如“避免修改公共 API”。该输入进入会话队列，并作为待处理输入合并到当前活跃轮次。
下一次模型采样会同时看到已有失败输出、已读文件内容、已产生的修改意图和用户新增限制。模型据此重新评估方案，避免继续执行与新约束冲突的动作。
待处理输入合并保持轮次连续性。用户追加限制不会丢弃已有工具结果，也不会默认开新任务；它改变的是当前任务下一次采样的上下文。
验证循环¶
修改完成后，模型通常再次请求运行目标测试。该请求重复工具调用、权限检查、沙箱执行和结果回填流程。
测试仍失败时，工具结果推动下一轮分析和修改。测试通过后，模型可能进行补充验证或输出总结。验证结果为运行时收束任务提供事实依据。
验证也会受权限系统约束。需要网络、写工作区外文件或无沙箱重试的验证命令仍会进入审批路径。通过结果只有在工具实际执行后才成为模型可用事实。
轮次收尾¶
模型不再请求工具并输出最终说明后，运行时确认没有未完成工具、没有待后续的工具结果、没有待处理输入，并且模型流和事件记录已经收束。
普通任务随后更新 token 用量、差异、长期记忆指标和活跃轮次状态，发送轮次完成。持久化记录和线程存储保存本次任务的关键记录，支持后续恢复、分叉和历史回放。
收尾记录包括最终助手输出、中间工具结果、上下文变化和轮次状态。后续恢复会话时，系统依赖这些记录重建模型曾经看到的事实和规则。
机制串联¶
“修复测试失败”任务展示了 Codex 智能体的核心协作：
用户目标
-> 会话队列
-> 轮次上下文
-> 模型上下文
-> 模型请求工具
-> 权限和沙箱检查
-> 本地工具执行
-> 工具结果回填
-> 模型继续采样
-> 验证和总结
-> 轮次完成
-> 历史持久化
模型负责选择下一步，本地运行时负责执行边界，工具结果提供真实反馈，事件和持久化保证过程可观察且可恢复。