Agent Loop

goal and state
→ model decides next action
→ tool or environment executes
→ observation enters state
→ model continues, stops or asks for help

状态不是 messages[] 的同义词。跨轮连续性由 Agent State and Model APIs 中的外部状态、对话轨迹、兼容 reasoning items、compaction state 和环境快照共同组成。

工程关注

tool schema、输入验证、超时、重试与幂等
short-term context、long-term memory 与 retrieval
planning、ReAct、plan-and-execute 等控制方式
structured output、checkpoint 与 human-in-the-loop
权限、prompt injection、数据泄漏和高风险动作确认

Agent 工程不等于 Agentic RL。只有轨迹采集、奖励、策略更新和持续闭环属于 MOC - Agentic RL 核心。

逐轮状态如何改变结果

goal
→ 当前 state 压缩/选择
→ model 产生 action
→ tool 执行并返回 observation
→ observation 写入 state
→ termination / retry / human handoff

这里的关键不是循环本身，而是每一轮携带什么信息和什么副作用。状态过长会挤压模型输入，压缩过度会丢失约束；重试没有幂等键会重复扣款或写入；没有显式终止条件会把失败循环伪装成“更努力”。因此要为每个 action 记录输入、结果、耗时、重试次数和可恢复 checkpoint。

评测最小闭环

先用确定性的 tool/schema 单测，再做带故障注入的轨迹回放，最后看真实任务成功率和人工接管率。单次最终答案无法解释到底是规划、工具、状态还是恢复层出了问题。

一轮循环的真正接口

把循环写成 while model_has_not_finished 会掩盖几个必须由 runtime 决定的契约。一次 action 至少要有可追踪的 run_id、step_id、工具版本、结构化参数和幂等键；一次 observation 除了返回值，还要记录来源、状态码、耗时、截断情况和是否可以安全重试。模型只提出意图，runtime 决定这个意图是否有权限、是否满足 schema、是否真的执行。

model proposes action
→ policy / permission gate
→ schema + budget validation
→ idempotent tool execution
→ observation + side-effect receipt
→ state append / checkpoint
→ continue, retry, handoff or stop

这也解释了为什么“工具调用成功”不能只看 HTTP 200：一个写文件工具可能返回 200 但只写入了部分内容；一个搜索工具可能成功返回空集合；一个重试可能把同一笔外部支付执行两次。对有副作用的工具，执行结果应带操作 receipt 或去重状态，恢复时先查询 receipt 再决定是否重放。

失败不是一种失败

同一条失败轨迹可以按发生位置拆开，否则修复会不断堆 prompt：

现象	更可能的故障层	可验证的修复
选择了不存在的工具	schema/模型接口	约束工具集合并做参数回放
参数合法但权限拒绝	policy/runtime	在模型调用前做授权门，不让模型猜权限
工具超时后重复写入	retry/幂等	注入 timeout，检查同一 `idempotency_key` 是否只产生一次副作用
多轮后忘记用户约束	state/compaction	比较完整轨迹与压缩轨迹的约束召回率
一直重复同一动作	termination/recovery	对相同 action-observation 循环设置预算和人工接管

因此 Agent Loop 的性能指标也不能只有模型 latency；需要把每轮的等待、工具耗时、上下文 token、重试次数和恢复点一起记录。这些 trace 最终由 Agent Evaluation 解释，跨请求连续性的表示边界见 Agent State and Model APIs。

一个可复现的最小实验

选一个会修改仓库的工具，构造三条轨迹：正常返回、执行成功但响应丢失、执行超时后重试。比较没有 checkpoint、只保存 messages、保存 messages 加 receipt 三种 harness。真正通过的标准不是“模型最后说完成了”，而是文件状态正确、重复副作用为零、从中断点恢复后仍能解释当前状态。这个实验比再增加一种 planning prompt 更能说明 runtime 是否可靠。