[AI/Agent/工程化] Agent Loop 工程 ：从"循环机制"到"循环工程"——一整套AI Agent关于【继续/停止/重试/收敛/反馈】的【工程决策体系】

0 序

  • Agent Loop 工程 —— 决定 Agent「何时再跑、凭什么停、错了怎么改」的时间维度工程；

  • AI Agent工程范式与控制权的演进：Prompt→Context→Loop→Graph→Harness

它与提示词工程、上下文工程、驾驭工程共同构成把「会预测 token 的模型」变成「能稳定完成任务系统」的多层递进体系。

1 概述：Agent Loop 工程

1.1 概念定位与定义（必读）

  • Agent Loop（智能体循环，又称 Agentic Loop / ReAct Loop） 是 AI Agent 最核心的运行机制：模型在一个闭环里反复执行 思考（Thought/Reason）→ 行动（Action/Act）→ 观察（Observation/Observe）→ [反思(反思)] --> 再思考，直到任务完成或触发终止条件。

  • Agent Loop 工程（循环工程，Loop Engineering） 则是把这条循环当成一门工程学科去设计、治理与兜底：

    • 研究的是 时间维度 的问题——Agent 什么时候再次运行？它凭什么知道已经完成？每步做完后要不要重做、怎么修正？
    • 它不是"for 循环里套个模型调用"，而是一整套关于继续/停止/重试/收敛/反馈的【工程决策体系】。

  • 精炼地概括它与相邻概念的分工：

提示词工程管「怎么说」，上下文工程管「看什么」，驾驭工程管「整个系统怎么安全、持久、可控地运营」；

而 Loop 工程管「这一轮之后怎么办」。

1.2 诞生的背景与原因

  • 单次推理没有"后悔药"：传统 LLM 调用是无状态的单次"输入→输出"，一次推理错了整条链就崩。而真实任务（查资料、改代码、跑测试）几乎都是多步、依赖上一步观察结果的，天然需要一个循环。
  • 任务无法在一句 Prompt 里穷举：复杂任务不可能在一个 prompt 里穷举所有情况，必须让模型边做边看、边看边调整。
  • 从"会回答"到"会做事"的跃迁：Agent = 大模型 + 工具能力 + 循环执行机制。循环是 Agent 区别于普通对话的根本分水岭——没有循环，模型只是"更会聊天的聊天框"。

1.3 解决的核心问题

问题 Loop 工程的对策
多步任务依赖上一步结果 循环把每步 Observation 回流进上下文，作为下一步的输入
一次推理错误导致全链崩塌 执行→验证→反馈→重试的自我修正闭环（Self-Correction）
目标达成与否无法判定 独立验证器/评估器，不信任 Agent 自报完成（claimedDone）
任务永远完不成、无限空转 安全阀（maxTurns / Token 预算）、死循环检测（Stall Detection）、收敛循环（loop-until-dry）
每步做对做错没人打分 过程级奖励模型（PRM）等信号源为每一步提供奖惩信号
重复执行产生副作用 幂等设计（幂等键、状态检查）

1.4 发展历程：Prompt→ Context→Loop→Graph→Harness（必读）

阶段 时间 标志性事件/认知
ReAct 范式确立 2022 年前后 Reason + Act 交织，Thought→Action→Observation 固定闭环，成为所有高级 Agent 架构的基石
框架普及期 2023-2024 LangChain、LangGraph 等把 Loop 做成可配置的运行时原语；ReAct / Plan-and-Execute / Reflection 成为三大经典模式
工程化期 2024-2025 社区开始把 Loop 从"架构模式"上升为"工程学科"：验证器、安全阀、预算管理、收敛循环、幂等成为标配
学科分化期 2025-2026 五大工程体系（Prompt/Context/Loop/Graph/Harness）被明确提出；Loop 被定位为"时间结构"，与"空间结构"的 Graph 正交

注：社区对"控制权迁移"的顺序有不同叙事：

  • Juejin《五大工程体系》按"控制中心迁移"排为 Prompt→Context→Loop→Graph→Harness；
  • InfoQ《五次范式跃迁》按"层层兜底"排为 Prompt→Context→Harness→Loop→Environment。两者并非矛盾：前者是"谁在主导控制"的历史线，后者是"谁为谁擦屁股"的依赖线（详见 §1.11、§3）。

1.5 主要功能（必读）

  1. 多步任务自主闭环：拆解→规划→调用工具→观察反馈→继续/结束。
  2. 自我纠错（Self-Correction）：检查到错误后，Agent 能基于反馈自己修正再执行。
  3. 终止判定：通过独立验证器判断"是否满足交付条件"，而非模型自说自话。
  4. 收敛控制：loop-until-dry（连续 N 轮无新发现即停）、seen 去重，防止空转。
  5. 资源与预算管理：Token 预算、迭代上限（maxTurns）、超预算降级兜底。
  6. 探索/利用权衡（Search vs Exploit）：决定继续深挖当前路径还是换新方向。
  7. 死循环检测：检测模型重复输出（原地踏步），强制切换思路或终止。

1.6 核心优势

  • 补齐模型"无状态"短板：把单次推理升级为可迭代、可修正的闭环，显著提升复杂任务成功率。
  • 工程价值可量化：LangChain 实验显示——不换底层模型，只改 Harness/Loop 层（自我验证循环、推理预算策略等），Terminal Bench 2.0 得分从 52.8% 升到 66.5%，从前 30 跃入前 5。同一个模型，不同的"循环+驾驭"，天壤之别。
  • 与架构正交、组合灵活：Loop（时间）× Graph（空间）正交，一个 Graph 可被 /loop 定时触发，每个节点又能拥有自己的内部 Loop。
  • 可观测、可兜底：独立验证器 + 安全阀，把"模型失控"从大概率事件降为可控的小概率事件。

1.7 主要短板

  • 奖励信号难获取：每一步做对做错，谁来打分？PRM/验证器设计本身是难点，信号弱则循环沦为"瞎试"。
  • 成本放大：多轮循环意味着多倍 Token 消耗，长任务下预算压力大。
  • "循环 ≠ 收敛"：能循环不代表能收敛，设计不当会陷入重复试错而不产出。
  • 对上下文工程强依赖：Loop 每轮都会产生新信息（文件内容、测试输出、报错日志），若上下文治理跟不上，会快速膨胀、目标漂移。

1.8 局限性

  • 软约束本质：Loop 属于逻辑/流程约束，模型"可能无视"——它管不住物理层面的破坏（删库、泄密），那需要环境工程（Environment Engineering）的硬兜底。
  • 单循环解决不了协作复杂度：多智能体分工、复杂依赖图，需要上移到 Graph 层解决，Loop 只管单个执行单元的时间推进。
  • 本质是执行形态，不是完整工程体系：只有循环而没有长期记忆、上下文治理、编排与验收，系统仍会"能执行但容易跑偏"。

1.9 适用场景

  • 多步依赖型任务：检索→分析→修改→测试→修复（如 AI 编程助手、SWE-agent）。
  • 需要外部工具/环境反馈的任务：跑测试、查 API、操作数据库、读文件。
  • 长周期、目标可验证的任务：竞品调研、知识库巡检、自动运维。
  • 需要"边做边校正"的场景：代码调试、数据分析、自动化 QA。

1.10 同类"竞品"/相邻概念（其他工程范式）

按"控制对象"透镜，与 Loop 同级的工程范式（详见 §3）：

工程范式 控制对象 一句话定位
提示词工程 Prompt 文本措辞 怎么说
上下文工程 Context 信息构成 看什么
循环工程 Loop 时间维度 何时再跑、何时停
图工程 Graph 空间维度 工作如何拆成节点、如何连
驾驭工程 Harness 系统维度 系统如何安全持久可控地运营
环境工程 Environment 物理边界 在哪做、兜不兜得住

1.11 发展趋势

  • 从"循环机制"走向"循环工程"：Loop 从架构模式升级为学科，验证器、预算、幂等、收敛检测成为工程标配。
  • 控制权外移：控制权从"人的注意力"（手工 Prompt）持续迁移给系统（Context→Loop→Graph→Harness），"为什么现在需要 Agent Runtime"是这一趋势的注脚。
  • Harness × Loop 为王：行业共识从"模型为王"转向"模型能力 × Harness 效率 × Loop 修正质量"。
  • 总结：Agent Loop 工程正在与上下文、图、驾驭等工程融合成一个统一的 Agent Runtime 学科，循环只是其中"时间维度"的一根支柱。

2 工作原理与架构

2.1 概念术语

术语 含义
ReAct Reasoning + Acting，推理与行动交织的经典循环范式
Thought / Reason 思考：理解目标、判断下一步动作（内部独白，常对用户不可见）
Action / Act 行动：调用工具（读文件、跑命令、查 API）
Observation 观察：把工具返回结果/反馈写回上下文
Agentic Loop 单轮执行结构：观察→推理→行动→验证→继续/结束
验证器/评估器 独立于执行者的客观检查（测试命令、脚本、规则引擎、另一模型）
安全阀 maxTurns / Token 预算，防止无限循环
loop-until-dry 收敛循环：连续 N 轮无新发现才停（seen 去重、dryRounds 计数）
Stall Detection 死循环检测：识别模型重复输出，强制换思路
PRM Process Reward Model，过程级奖励模型，为每一步打分
幂等设计 重复执行不重复创建资源/发消息

2.2 Agent Loop 运行原理

flowchart LR T["Thought 思考<br/>理解目标·判断下一步"] --> A["Action 行动<br/>调用工具/执行动作"] A --> O["Observation 观察<br/>反馈结果回流上下文"] O --> V{"独立验证器<br/>满足交付条件?"} V -- "否：缺口反馈回下一轮" --> T V -- "是" --> D["结构化输出/最终结果"] S["安全阀<br/>maxTurns·Token预算"] -. "超限即停(不等于成功)" .-> T
  • 为什么必须循环：以"分析项目里所有未使用的导出函数"为例——Step1 grep 找 export、Step2 grep 找 import、Step3 对比、Step4 若结果太多再分页。每一步输出都依赖上一步的观察结果，这就是 Loop 存在的根本原因。
  • 模型在循环里扮演的角色：每一轮中，模型"推理 → 我要调用什么工具、传什么参数 → 执行拿到结果 → 把结果喂回 → 继续推理"，直至达到终止状态。

2.3 Loop 工程的四大类循环与核心机制

四类循环（按"谁按下继续键"分类）：

类型 触发者 说明
Goal-based（/goal） Agent 自己 按"继续"直到出现可验证证据或触及 maxTurns；验证器与执行者分离
Time-based（/loop） 定时器 到点重新观察外部世界；先观察后行动，外部完成才停
Turn-based（普通对话） 人类 人驱动回合制，最原始的循环
Proactive（/schedule） 事件/云端计划 无人值守，事件驱动、云端调度

六项工程核心机制：

  1. 验证器/评估器——独立客观检查，不信任 Agent 自报完成（claimedDone）。
  2. 安全阀（maxTurns / Token 预算）——到达上限 ≠ 成功，要诚实报告缺口。
  3. 收敛循环（loop-until-dry）——seen 去重、dryRounds 计数、去重对象必须是全量 seen。
  4. 幂等设计——幂等键、状态检查，重复执行无副作用。
  5. 预算管理——每步消耗多少 Token，超预算后如何降级（fallback 输出当前最佳结果）。
  6. 探索/利用权衡——继续当前路径（利用）还是换方向（探索）。

2.4 Loop 与相邻工程的分工边界

  • Loop × Graph（时间 × 空间，正交）：Graph 回答"如何组织"（节点怎么连、数据怎么流），Loop 回答"何时"（这一轮结束之后怎么办）。同一个 loop-until-dry 里，循环本身属 Loop 层，循环内部并行搜索的多个 finder 属 Graph 层。
  • Loop × Harness：Harness 管"做几步、按什么顺序做"（流程编排）；Loop 管"每步做完后判断要不要重做、怎么修正"（反馈修正）。Harness 是规则/边界，Loop 是纠错机制。

3 专项对比：与提示词工程、上下文工程、驾驭工程的关联关系与本质区别

3.1 本质对比（必读）

工程 本质 类比
提示词工程 Prompt 让模型「听懂」——把意图翻译成一句好指令
（【指令意图】）		 把话说清楚
上下文工程 Context 让模型「知道」——在正确时机喂正确的信息
教模型怎么做：解决 LLM 对意图理解不精准、零样本输出不稳定问题
（【有限窗口下，对输入信息集合的聚焦】）		 把场搭好、材料备齐
循环工程 Loop 让模型「做得对」——错了能改、能收敛、知道何时停
给模型看什么：解决记忆保留、长文本检索（RAG）、Tool schema 注入与动态剪枝问题
（【指令意图】）		 复盘与纠错机制
驾驭工程 Harness 让系统「稳得住」——边界、记忆、编排、验收、可观测
系统出错了怎么办：解决 AI Agent 系统在工业落地时的不可靠、无法中断、不可重试、状态不透明问题
（【运行时异常与边界（可靠性、鲁棒性、确定性）】）		 缰绳 + 驾驶舱 + 应急预案

3.2 详细对比（本质区别）

维度 提示词工程 Prompt 上下文工程 Context 循环工程 Loop 驾驭工程 Harness
控制对象 文本措辞 信息构成（上下文窗口装什么） 时间维度（何时继续/停止） 系统维度（运行环境与运营机制）
核心问题 怎么写模型更易理解与服从？ 什么该进、该砍、何时进、永不进？ 什么时候再次运行？凭什么停？ 怎么让结构安全、持久、可观测地运行？
粒度/作用域 单次输入-输出对，无状态 每轮模型调用前的输入构造 一轮结束之后的多轮推进 横跨所有层与整个生命周期
典型技术 角色、few-shot、CoT、格式约束 检索(RAG)、压缩、组装、注入时机、记忆、隔离 四类循环、验证器、安全阀、幂等、收敛循环 权限/Sandbox、状态持久化、编排调度、Hook、Evals、观测呈现
解决什么 意图对齐：模型"泛化回答、乱猜" 信息供给：幻觉、遗忘、上下文腐化、Token 浪费 自我修正：一次错全链崩、无限空转、无终止判定 可控运营：出事故没人知道、不可恢复、黑箱
本身不解决 内容有没有、工具能不能用 "做错了怎么办" 物理层面的破坏、多智能体协作结构 单次输出质量（由内层负责）
时代/主导期 2022-2023 2024（Anthropic 2025 官方提出） 2024-2025 起成为独立学科 2025-2026，当前主战场
失效症状 单次输出质量差、不守格式 幻觉、遗忘、Token 浪费 过早停止或无限循环 事故不可追溯、不可恢复

3.3 关联关系图（必读）

图 1：四/五层工程嵌套与正交关系（从内到外一层套一层）

flowchart TB subgraph Harness["驾驭工程 Harness · 系统维度<br/>边界·状态·安全·编排·可观测"] subgraph Graph["图工程 Graph · 空间维度<br/>工作如何拆成节点、如何连接(正交于 Loop)"] subgraph Loop["循环工程 Agent Loop · 时间维度<br/>何时继续·何时停止·验证·纠错"] subgraph LoopCore["Agentic Loop 单轮执行<br/>观察→推理→行动→验证"] subgraph Context["上下文工程 Context · 信息维度<br/>检索·压缩·组装·注入时机·隔离"] Prompt["提示词工程 Prompt · 表达维度<br/>措辞·角色·示例·格式约束"] end end end end end

图 2：范式演进与"层层兜底"关系

flowchart LR P["提示词工程<br/>意图对齐·怎么说"] --> C["上下文工程<br/>信息供给·看什么"] C --> H["驾驭工程<br/>流程编排·怎么控"] H --> L["循环工程<br/>自我修正·错了怎么改"] L --> E["环境工程<br/>物理防线·在哪做"] P -. 失效由Context兜底 .-> C C -. 失效由Harness兜底 .-> H H -. 失效由Loop兜底 .-> L L -. 失效由Environment兜底 .-> E

图 3：一次请求如何穿过各层（Loop 在其中承接 Context 与 Harness）

flowchart LR TR["外部触发<br/>用户/定时器/事件"] --> H1["Harness<br/>调度·权限·预算"] H1 --> G1["Graph<br/>选择节点与拓扑"] G1 --> LP["节点内 Agentic Loop<br/>观察→推理→行动→验证"] LP --> C1["Context 构建<br/>检索·压缩·注入·隔离"] C1 --> P1["Prompt 生成<br/>指令编排·格式约束"] P1 --> M["模型输出"] M --> V["验证器/评估器 → 完成?"] V -- 未达标准 --> LP V -- 通过 --> OUT["结果 → 状态存储·观测·呈现(Harness)"]

3.4 本质区别：一条"控制对象"透镜

判断一个机制属于哪一层，只看它动的是什么：

  • 动的是文本措辞 → 提示词工程
  • 动的是哪些内容进入模型的眼睛 → 上下文工程
  • 动的是运行的时机与停止条件 → 循环工程
  • 动的是多个工作单元的连接结构 → 图工程
  • 动的是运行环境与运营机制 → 驾驭工程

由此可得三个最容易混淆的判定：

  1. Prompt ⊂ Context：措辞只是"已经选定的内容"里的表达优化。同样一段指令，"怎么写"是 Prompt 层，"这段指令进不进得了上下文"是 Context 层。SKILL.md 正好横跨两边——内容属 Prompt，description 触发属 Context。
  2. Loop 与 Graph 是正交的，不是上下级替代：Graph 是空间（怎么拆、怎么连），Loop 是时间（何时继续、何时停）；二者组合使用：/loop 触发 → Graph 执行 → 每轮按 /goal 风格验证。
  3. Harness 包裹一切：它给上面所有层提供运行环境；Loop 是 Harness 里的"执行核心之一"，但 Harness 的范围比 Agent/Loop 更大——Agent 是执行形态，不是完整工程体系。

3.5 贯穿示例：知识库健康检查 Agent（五层如何各司其职）

任务：每天定时扫描知识库死链、缺失 Frontmatter 与结构异常，报告新增问题。

  • Prompt 层：写清"检查规则、输出格式（新增问题清单）"。
  • Context 层：决定扫描哪些目录、注入昨天的结果做 diff、工具输出截断。
  • Loop 层：Time-based /loop 定时触发；每轮 loop-until-dry 直到连续 N 轮无新问题；独立脚本验证死链。
  • Graph 层：拆成"扫死链 / 扫 Frontmatter / 扫结构"三个并行节点，Fan-out 后 Fan-in 合并去重。
  • Harness 层：定时调度、权限（只读）、状态持久化（断点续传）、Evals 验收、报告呈现。

Z FAQ for 循环工程

Q: ReAct 和 Agent Loop 是同一个东西吗？

ReAct（Reason+Act）是 Agent Loop 最经典的实现范式；Agent Loop 是更宽泛的概念，还包括 Plan-and-Execute、Reflection 等模式，以及围绕循环的验证、终止、预算等工程机制。

Q: Loop Engineering 和传统的 while 循环 / 重试机制有什么区别？

普通重试是"失败了原样再试 N 次"；Loop Engineering 强调有信息增益的迭代——每轮把观察结果写回上下文、用独立验证器判定收敛、检测死循环、管理预算、保证幂等，是"闭环"而非"重试"。

Q: 为什么 Loop 必须依赖上下文工程？

Loop 每轮都会产生新信息（读到的文件、测试输出、报错），处理不好会上下文膨胀、目标漂移。没有高质量的上下文治理，Loop 只是一个"很快会失控的执行循环"。

Q: 循环里的验证信号从哪来？

三路：①确定性信号（测试命令、脚本、规则引擎、Schema 校验）；②另一模型做评审/评估；③过程级奖励模型（PRM）为每一步打分。核心原则是不信任 Agent 自报完成。

Q: 为什么说 Agent 不等于 Harness Engineering？

AI Agent 强调的是"会规划、会调工具、会循环执行"，是一种执行模式；

Harness Engineering 在此基础上还要管长期记忆、上下文治理、规则注入、反馈控制、任务编排、验收与终止条件，范围更大。

Y 推荐文献

X 参考文献

posted @ 2026-08-31 17:31  数据知音  阅读(107)  评论(0)    收藏  举报