在开源 Agent 项目中，真正决定产品体验的往往不是某一个模型接口，而是运行时如何组织一次完整的推理与执行。Codex 最近被开发者逐层拆解的源码显示，一次用户输入进入系统后，并不是简单发给模型等待回复，而是先进入一套 turn 生命周期管理：系统要判断这是开启新一轮任务，还是插入正在执行的任务；随后由外层循环、内层采样、工具执行、审批判定和状态回灌共同组成一条闭环链路。这条链路，构成了 Codex Agent 运行时的核心骨架。
一次 Turn 从输入开始，先解决“新任务还是补充输入”
按照源码导读的梳理，用户按下回车后，Codex 首先要回答的问题不是“模型怎么回复”，而是当前输入应该被当作一个全新的 turn，还是并入一个正在运行的 turn。相关逻辑位于 session/turn_input.rs 中的 steer_input 守卫流程。
该函数会依次检查多个条件：是否存在活动 turn、活动 turn 是否还有对应任务、客户端指定的 turn 是否已经过期、当前任务类型是否允许插话，以及输入内容是否为空等。值得注意的是，普通 Regular 任务可以接受用户中途补充输入，但 Review 和 Compact 类型的任务并不支持这种“steer”操作。也就是说，在审查轮或压缩轮期间，用户输入会被拒绝，而不是排队等待。
如果没有可插入的活动 turn，系统则会通过 tasks/mod.rs 中的 spawn_task 开启新的任务。这里有一个非常明确的设计原则：一个 session 同时只允许一个活动 turn。新任务启动前，旧任务会先被终止，原因被标记为 Replaced。这意味着 Codex 并没有采用多个 turn 并行执行的模型，而是通过替换机制保持会话执行状态的单线一致性。
外层循环与内层采样：Agent 不是一次问答，而是持续推进的状态机
进入任务执行后，Codex 的结构并不是“请求模型—返回结果”这样一次性的流程，而是由外层 loop 和内层采样 loop 共同驱动。在 tasks/regular.rs 中，RegularTask 的 run 方法包含一个外层循环，其作用不是单纯调用模型，而是持续判断一轮结束后是否还需要继续执行。
每次进入 run_turn 前，系统会先完成准备动作，包括 hook 处理、上下文整理以及 step context 的构建。随后进入位于 session/turn.rs 的内层循环，在这一阶段读取模型流式输出，并同步处理工具调用。导读中提到，工具甚至可以提前启动，而不是等模型完整输出后再统一处理。
这里的关键问题是：一轮什么时候算结束？Codex 并不是靠模型“说完了”就停止，而是根据多个条件共同判断是否需要继续。例如，模型是否发出了工具调用、是否存在排队中的用户输入、是否触发了 end_turn 等。如果后续动作仍被需要，系统会再次进入采样循环；如果不再需要，则进入 stop hooks 和收尾逻辑。
这种设计让 Agent 的执行更接近一个持续推进的状态机，而不是一次性对话补全。模型负责提出下一步动作，运行时负责判断该动作是否需要执行、是否可以执行、执行之后是否还要继续。
工具执行不是直接运行，先经过安全链与审批链
在 Agent 运行时里，工具调用往往比模型输出更复杂，因为它牵涉到真实执行权限。Codex 的源码显示，工具从被提出到真正执行，需要穿过一整套安全与审批机制。
在 tools/parallel.rs 和 tools/registry.rs 等模块中，工具执行被拆分为不同阶段，并进一步与事件系统衔接。真正决定“能不能执行”的，则是由 tools/orchestrator.rs、tools/approvals.rs、exec_policy.rs 以及 execpolicy/ 目录组成的审批与策略体系。
从导读披露的信息看，工具执行会经历多个判定结果：如果是 Forbidden 或 Denied，失败结果会回灌给模型；如果是 Abort，当前 turn 会直接终止；只有在 Skip 或 Approved 的情况下，工具才会进入沙箱内真实执行。这一流程说明，Codex 并不是让模型随意触发工具，而是把工具调用放在策略、审批和执行层的多重约束下。
审批机制本身也被设计成一次“等待”。当系统判断需要用户确认时，相关流程会通过 session/mod.rs 和 state/turn.rs 转入等待状态，再由 protocol/src/approvals.rs 与 tui/approval_overlay.rs 完成弹窗和交互层处理。这意味着在 Codex 的运行时里，等待用户授权并不是额外的 UI 功能，而是 turn 状态转换的一部分。
对开源 Agent 开发的启示：运行时比单点能力更关键
从这次源码导读可以看到，Codex 的核心价值并不只体现在模型能力本身，而在于它如何把模型输出、工具调用、用户干预和任务终止组织成一条完整链路。一次 turn 的完整生命周期，至少包含三层协作：
- 会话层负责判断输入是开启新 turn，还是插入现有 turn；
- 任务层负责管理外层循环、内层采样、取消令牌和完成信号；
- 工具层负责执行阶段划分、策略判定、审批等待和结果回灌。
这种结构让 Agent 的行为更可解释，也更容易控制。模型不再是一个黑盒输出器，而是运行时循环中的一个节点；工具也不再是模型想调就调的插件，而是必须经过策略和审批约束的执行对象。
对于正在构建开源 Agent 框架的开发者来说，Codex 的这套实现提供了一个很具体的观察样本：真正决定 Agent 稳定性的，往往不是提示词写得有多精巧，而是运行时能否清晰管理“何时继续、何时等待、何时终止”这三个问题。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/du-dong-codex-yuan-ma-yi-ci-turn-ru-he-chuan-qi-mo-xing
