Agent Loop（智能体循环）

Agent Loop（智能体循环） 是 AI Agent（智能体）的最小运行结构：接收用户输入，构造 prompt，调用模型推理；如果模型请求工具调用，harness 执行工具并把观察结果追加回上下文，再次调用模型；直到模型停止请求工具、返回 assistant message，控制权交还给用户。

从更高视角看，一个完整的 Agentic Loop 由两个要素构成：触发器（trigger）（事件驱动、定时或人工触发）和可验证目标（verifiable goal）（Agent 自主迭代直到目标满足，无需每轮重新提示）。这一视角把单次推理-工具循环和驱动它持续运行的外部控制逻辑统一起来，是理解 Loop Engineering（循环工程）的基础。

OpenAI 对 Codex 长程任务的复盘把同一变化表述为时间跨度 问题：Agentic coding 越来越不是单次生成是否聪明，而是 Agent 能在多长时间内保持目标、修复失败并端到端交付。文章引用 METR 的长任务 benchmark，指出前沿模型能以约 50% 和 80% 可靠性完成的软件任务时长在快速增长，粗略呈现约 7 个月翻倍的趋势。Codex 的 25 小时设计工具实验就是这个趋势的工程样本。

它不是一个抽象比喻，而是 Agent 产品里的实际控制逻辑。Codex 的 CLI harness 就围绕这个循环组织：用户、模型、工具、本地执行环境和上下文窗口都由循环协调。

伪代码上，它近似一个 while 循环：询问模型下一步，若模型请求工具则执行并把结果返回，若模型给出最终回答则结束。这个结构解释了为什么"会查资料、会写代码、会操作系统"的 Agent 在底层形态上并不神秘；真正复杂的是循环如何被 Harness Engineering（驾驭工程）约束、如何用 Evals（评估）判断进展、以及何时必须停止。

OpenAI 的 Agent 构建指南也把 run 明确描述为循环：Agent 会持续运行，直到触发退出条件。常见退出条件包括最终输出、没有继续工具调用、出现错误、达到最大 turn 数，或某个高风险动作需要把控制权交还给人。

五阶段循环模型

从模型自身视角看，Agent Loop 可以分解为五个持续迭代的阶段：

感知（Perceive）：接收输入——用户消息、上一步工具输出、错误信息或环境状态变化
推理（Reason）：模型在当前上下文中决定下一步做什么；ReAct要求这一步产生显式的 Thought 轨迹
规划（Plan）：复杂任务时将目标分解为子步骤；简单任务可跳过，直接进入行动
行动（Act）：执行工具调用、API 请求、代码执行或文件读写
观察（Observe）：获取行动结果，再进入下一轮感知

这五阶段持续循环，直到达成目标、触发停止条件，或模型判断无法继续推进。

五阶段是从模型端描述循环结构，和 harness 端看到的"while 循环"是同一过程的两个视角：harness 管工具执行和上下文追加，模型管推理和行动选择。

典型实现模式是 ReAct——模型在每次工具调用前输出显式推理轨迹（为何选这个工具、结果意味着什么），而不是直接输出函数调用。这使 Agent 能根据真实观察动态调整计划，而非盲目执行预设步骤。

在 OpenAI API 里，Function Calling（函数调用）把“行动”阶段结构化为 function_call，再用 function_call_output 把观察结果交还给模型。在 Claude Messages API 里，同一循环表现为 Claude API Tools的 tool_use 和 tool_result：client tools 由应用执行，server tools 由 Anthropic 平台执行。模型可以在一个 turn 中请求零个、一个或多个工具调用；harness 必须负责解析、执行、回填结果，并决定是否允许并行或触发人工审批。

OpenAI 的 Agents SDK 文档把这条边界产品化成两个层级：用 Responses API（响应 API）时，应用自己拥有 loop；用 OpenAI Agents SDK时，SDK runner 负责运行工具循环、处理 handoff 后的 Agent 切换，并在 run 完成或等待审批时暂停。也就是说，Agent Loop 可以由应用手写，也可以由编排 SDK 承担一部分生命周期管理。

Claude Agent SDK也是这种“SDK 拥有 loop”的形态，但它的起点不是通用 Messages API，而是把 Claude Code的文件读写、Bash、搜索、编辑、Hook、权限、session、MCP 和 subagent 能力作为库暴露给应用。开发者配置 allowed_tools、权限和会话选项，SDK 在本地或自有基础设施中运行行动-观察循环。

Pi 的 pi-agent-core 给出了一个供应商无关的开源实现：模型返回 tool call 后，runtime 校验参数并执行工具，再把 tool result 送回下一轮模型调用；默认允许同一批工具并行，但工具可要求整批串行。它还把 beforeToolCall、afterToolCall 和细粒度事件流暴露给上层 harness，使 UI、审计、阻断和结果转换不必写进循环主体。

一轮对话

Agent Loop 中的一个 turn 指用户发出一条消息后，到 Agent 返回 assistant message 为止的完整过程。一个 turn 内部可以包含很多次"模型推理 → 工具调用 → 工具输出 → 再推理"的迭代。

这意味着 Agent 的输出不只是最后那条文本消息。对软件 Agent 来说，真正的主要输出往往是它写入或修改的代码、文件和命令执行副作用；assistant message 只是循环终止信号，例如告诉用户已经完成了哪些文件修改。

Prompt 的增长

每次工具调用都会产生新的观察结果，随后被追加到下一次模型请求的输入里。多轮对话继续时，上一轮的 assistant message 和新用户消息也会追加进去。因此，Agent Loop 天然制造不断增长的上下文。

这个增长带来两个工程后果：

上下文窗口压力：工具输出、历史消息和推理条目可能耗尽模型的 context window，需要Context Engineering（上下文工程）介入
性能压力：如果每次都重新处理完整历史，长对话的推理成本会快速上升，需要Prompt Caching（提示缓存）和压缩机制配合

Harness 的职责

Agent Loop 不是模型自己完成的，而是 Harness Engineering（驾驭工程）的典型职责。一个可用的 loop 至少要处理：

构造初始 prompt：系统/开发者/用户指令、工具定义、环境上下文
调用模型推理 API，如 Responses API（响应 API）
解析模型输出，区分最终消息、reasoning item 和 tool call
执行工具，并把工具输出绑定到对应 call id
在多 Agent 工作流中处理 handoff、specialist 切换和 run 状态
管理上下文窗口、缓存命中和压缩
在工具执行涉及文件系统或网络权限时套用Agent Sandbox（Agent 沙箱）和审批规则

常见失效模式

Agent Loop 在生产环境中有六类典型失效，设计停止条件时应逐一考虑：

失效模式	说明
无限循环	缺乏客观目标验证，Agent 自称完成但未能终止
目标漂移（Goal Drift）	Agent 在迭代中偏向相邻目标，原始目标逐渐被替换
上下文溢出退化	长循环中上下文窗口填满，早期关键信息被截断，导致推理质量下降
静默失败	Agent 没有明显报错，输出看起来合理，但实际没有推进目标
Token 成本爆炸	每轮都追加工具输出，成本以多轮×每轮开销叠加
错误传播	某轮产生的错误被后续轮次当作事实前提，在上下文中累积

生产循环应设置：硬性迭代上限、token/成本预算、连续无进展检测、任务级和工具级超时，以及外部可验证的目标判定（而非仅靠 Agent 自称完成）。

高风险工具调用也是停止条件的一部分。比如退款、付款、删除数据、生产发布等动作不应只由模型继续推进，而应通过 Agent Guardrails（Agent 护栏）触发人工审批或更受限的业务流程。

四代循环演进

Agent Loop 的工程形态经历了四代演进（2023–2026）：

第一代（2023）：AutoGPT 等实验性系统证明了 Agent Loop 的可行性，但普遍面临无限循环和高 Token 消耗问题。

第二代（2022–2023）：三种具体模式各自探索提升质量的路径：

ReAct：在行动前输出显式推理轨迹（Thought-Action-Observation 三元组），在 AlfWorld 等基准上提升约 34%
Reflexion（反思）：在 ReAct 外加语言自评估层，失败后反思失因写入情节记忆再重试，适合试错密集型任务
Plan-and-Execute（规划与执行）：先完整规划后并行执行子步骤，通过并行化实现显著速度提升

第三代（2024）：关注多 Agent 编排与复杂控制流：OODA 循环（Observe-Orient-Decide-Act 结构）、内外双循环（战略层与战术层分离）、多 Agent 编排（Supervisor 协调专职子 Agent，Token 消耗约为标准对话的 15 倍）。

第四代（2025–2026）：原生目标追踪与外部状态持久化：Codex 的 Goals 把目标、生命周期、预算和证据检查持久化到当前线程；Claude Code /loop 强调会话内节奏性唤醒；Ralph Loop 用每轮新开上下文的 shell 循环缓解上下文溢出；并行工作流模式则结合多 Agent 并行与项目知识持久化。

第五阶段：持久编排循环

Matt Van Horn 把 Agent Loop 的演进总结为五个阶段，前四代聚焦单 Agent 内部结构，第五阶段是质的跃迁：

循环监督循环（loops supervising loops）
循环按计划自动触发，而不只是由人手动启动
循环能在进程重启、部署、崩溃后存活
循环可以派生子 Agent 并等待结果（有时需要数小时）
循环需要在事后可观察

这不是 Prompt 问题，而是基础设施问题。一个在服务器上跑的 Agent 循环，进程迟早会死——重启后，循环从第几步开始？它是否已经发出了那条通知？它是否已经启动了那个子 Agent？

“只在容器里运行” 能提供 uptime（可用性），但不能提供 correctness（正确性）。 解决第五阶段的关键不是更好的错误处理，而是 Durable Execution（持久执行）——每个步骤被检查点化，每个决策被持久化，恢复意味着从上一个成功步骤续接，而不是从头开始。

三层执行架构

在第五阶段，完整的 Agent 循环系统需要三个层次：

层	角色
Loop（循环）	Cron/事件触发 + LLM 决策
Skill（技能）	可复用的持久工作流函数（多步骤、可重试、可独立部署）
Orchestrator（编排器）	运行一切的引擎：调度 Cron、管理步骤、存储历史、热部署

LLM 和工具在循环内部；编排层使整个系统在生产中持久、可观察、可恢复。

与循环工程的关系

Loop Engineering（循环工程）是更高层的工作流方法论，关注如何设计自动发现任务、验证结果、记录状态和跨 Agent 协调的系统。Agent Loop 是单个 Agent 内部的执行循环，是循环工程的底层积木。

可以粗略区分：

层次	关注点
Agent Loop	单个 Agent 如何在推理和工具调用之间迭代
Loop Engineering	如何把一个或多个 Agent 放进可验证、可停止、可审计的工作流