agent loop是codex任务执行的生命线，严格遵循五阶段循环：①receive input、②build prompt、③call llm、④execute tool、⑤check done，每轮仅决定下一步动作，直至任务完成。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要真正理解 Codex 如何把一句“清理 src/main.rs 里的 TODO 注释”变成实际的文件修改操作，必须穿透 API 调用表层，看清它内部持续运转的 Agent Loop——这个循环不是辅助逻辑，而是任务执行本身的生命线，每一轮都决定下一步是生成代码、读取文件，还是重试修复。
Agent Loop 的五阶段主干结构
Codex 的核心循环被严格抽象为五个不可跳过的阶段，顺序执行，缺一不可：
① Receive Input：接收新输入，可能是用户原始指令，也可能是上一轮工具执行返回的 【tool_result】；若输入为空且无待处理结果，循环直接终止。
② Build Prompt：将系统身份、可用工具 schema、历史消息、当前 tool_result 全部拼装成结构化 Prompt；这一步若漏掉 tool_result，模型就无法感知上一步执行结果，必然导致错误决策。
③ Call LLM：向大模型发起推理请求，等待流式响应；响应中只允许包含两类内容：自然语言回复，或符合 JSON Schema 的 tool_calls 数组。
④ Execute Tool：仅当模型输出 tool_calls 时触发本地执行；CLI 端解析参数后调用对应工具（如 file_read、shell_exec），并严格捕获 stdout/stderr 作为下一轮输入。
⑤ Check Done：判断是否满足退出条件——tool_calls 为空、无 pending tool_result、用户无新输入；三者同时成立才结束循环。
一次“清理 TODO 注释”任务的完整流转
用户输入：“帮我把 src/main.rs 里的 TODO 注释清理掉”。
第一步：Codex 构建初始 Prompt，明确注入 system 指令“你是一个 Rust 项目维护助手”，加载 tools 列表（含 file_read、file_write、grep 等），并将该句设为 user message。
第二步：模型首轮响应不是直接写代码，而是发出 tool_call：{"name": "file_read", "parameters": {"path": "src/main.rs"}}；这说明模型选择先观察，而非盲写。
第三步：CLI 执行 file_read，读取文件内容后生成 tool_result，并将其作为新 message 加入上下文，再次进入 Loop。
第四步：模型看到文件内容，识别出三处 TODO 行，生成新的 tool_call：{"name": "file_write", "parameters": {"path": "src/main.rs", "content": "已移除 TODO 行的完整文件内容"}}。
第五步：CLI 执行写入，返回成功状态；模型收到 tool_result 后，本轮不再生成 tool_call，转而输出自然语言总结：“已清理 src/main.rs 中全部 3 处 TODO 注释”。
第六步：Check Done 判定无新 tool_calls、无 pending result、用户未追加输入 → 循环终止，任务完成。
断点恢复机制如何保障长任务不中断
方法一：每次 Loop 开始前自动落盘保存 Checkpoint
Checkpoint 是一个轻量 JSON 对象，只包含 messages 数组和 turn 计数器；它被持久化到本地磁盘固定路径，不依赖内存状态。
方法二：进程重启后优先加载最新 Checkpoint
runAgent 函数启动时，首先调用 loadCheckpoint()；若磁盘存在有效文件，就跳过初始 Prompt 构建，直接从上次中断处 resume agentLoop()。
注意：SSE 流中断后，只要 checkpoint 文件未损坏，重连 /chat 接口即可续跑；【丢失 checkpoint 将导致整轮任务回退到起点】。
验证与修复闭环为何不可省略
Agent Loop 不止于“执行完就交差”。以迁移 Express 到 Fastify 为例：
Observe 阶段读取 package.json 和 app.js；
Plan 阶段识别出 app.use()、app.get() 等 Express 特有调用；
Act 阶段生成 Fastify 替代代码并写入；
Verify 阶段自动运行 npm test + node app.js，捕获启动报错；
Reflect 阶段将报错日志喂回模型，驱动新一轮 Plan→Act 迭代；
Continue 直至测试全通或达到最大重试次数。
没有 Verify 的 Loop 只是单向代码生成器，无法形成真实工程闭环。
