Agent Loop

从“一次回答”到“多步执行”

语言模型本身只完成一次输入到输出的映射。Agent 能连续工作，是因为宿主程序把输出分类：

• 如果输出是普通消息，视为本轮的候选终点；
• 如果输出是工具调用，执行工具，把结果追加到历史，再次请求模型；
• 如果执行触发审批，暂停并等待人的决定；
• 如果被取消、达到限制或遇到不可恢复错误，终止本轮。

这个宿主程序就是 Agent Loop 的真正执行者。

stateDiagram-v2
[*] --> Assemble: 收集输入与上下文
Assemble --> Sample: 请求模型
Sample --> Final: assistant 消息
Sample --> Authorize: tool call
Authorize --> Execute: 允许或无需批准
Authorize --> Waiting: 需要人工批准
Waiting --> Execute: approve
Waiting --> Observe: deny
Execute --> Observe: stdout / diff / error
Observe --> Sample: 仍需后续推理
Final --> Verify: 结果陈述
Verify --> [*]

一次 Turn 内到底发生什么

在 Codex 的术语里，用户提交一次任务后，会产生一个 Turn。一个 Turn 可以包含多次模型采样和多次工具执行。

1. run_turn 捕获本轮配置与运行环境；
2. 构建模型请求：输入历史、指令、工具 schema、模型参数；
3. 流式读取模型响应；
4. 对每个完成的输出 item 分类；
5. 工具调用被派发并异步执行；
6. 工具结果记录回 Context；
7. 若 needs_follow_up 为真，继续采样；
8. 无工具调用且拿到最终消息后，完成 Turn。

动手观察一个缩小版循环

下面不是连接真实仓库的 Agent，而是把一次“修复重试 bug”的典型事件按顺序回放。注意每一步都消费前一步的证据。

$ codex
> 修复登录失败，并运行相关测试

工具错误不是程序错误

对传统程序来说，命令返回非零通常意味着失败退出；对 Agent 来说，它还可能是有价值的观察。

例如 rg 没找到目标、测试暴露另一个断言、Patch 因上下文不匹配而失败。Runtime 应把这些信息以结构化、长度受控的方式交还模型，让它决定换关键词、重新读文件或调整 patch。

何时停止

停止条件不是单一的：

源码中的网络采样路径包含重试处理；工具路径则由 router、registry 和 orchestrator 统一包装错误与事件。

并行工具不等于并行思考

Codex 可以把一组满足条件的工具调用并行调度，但下一次模型采样仍基于它们已返回的结果。并行主要减少独立读取或查询的等待时间，并不会消除共享状态冲突。

一个判断口诀

看到任何 Agent 行为时，依次问：

1. 它现在看到了什么？
2. 模型选择了什么动作？
3. 谁真正执行这个动作？
4. 执行结果如何回到上下文？
5. 什么证据允许它结束？

下一章把这个循环放进一个具体修改，追踪 从 Prompt 到 Patch 的全过程。