目录
一、Loop Engineering 的真正含义：AI 工程的杠杆点正在上移
（一）从“我来提示模型”到“系统来驱动模型”
1、Prompt Engineering 解决的是单次决策质量
2、Context Engineering 解决的是模型在当前一轮“看见什么”
（二）Loop Engineering 不是“循环调用模型”，而是设计控制系统
1、一个循环至少包含“任务、反馈与退出条件”
2、Loop 是比 Agent Harness 更上一层的设计
二、为什么 Loop Engineering 会在现在成为关键能力
（一）模型能力增长，把瓶颈从“生成”推向“治理”
1、模型已经能完成较长的行动链
2、长任务暴露出上下文窗口之外的状态问题
（二）工具生态成熟，让 Loop 可以真正作用于现实世界
1、MCP 与标准化工具接口降低了连接成本
2、Skill 把隐性项目知识转成可复用资产
三、从控制论理解 Loop：Agent 是受约束的反馈系统
（一）把 Agent Loop 映射成一个闭环控制模型
1、目标不是“让模型继续”，而是让状态收敛
2、验证器相当于传感器，错误的传感器会毁掉整个系统
（二）生产级闭环应包含七个关键部件
1、Trigger：触发器
2、Goal：可验证目标
3、Policy/Agent：决策器
4、Tools/Environment：执行器与环境
5、Verifier：验证器
6、State：外部状态
7、Stop Rules：停止与接管规则
四、验证器设计：Loop 可靠性的真正分水岭
（一）验证器应遵循“确定性优先”的层级
1、第一层：硬验证器
2、第二层：规则与参考答案验证器
3、第三层：独立 LLM Judge
4、第四层：Human Gate
（二）验证器也会被“优化”，因此要防止 Reward Hacking
1、Agent 会趋向满足检查，而不一定满足真实意图
2、验证应采用“多信号交叉”而非单指标独裁
五、状态、上下文与记忆：长期 Loop 的脊柱
（一）Context 与 State 必须分开设计
1、Context 是当前一轮需要看的信息，State 是系统必须记住的事实
2、好的 Context Engineering 服务于 Loop 收敛
（二）状态持久化需要可审计，而不是只“记得”
1、用事件日志记录“做了什么、为什么、结果怎样”
2、检查点与回滚是自治系统的基本能力
六、生产级 Loop 架构：从单 Agent 循环到任务工厂
（一）最小可用闭环：Act—Verify—Feedback
1、先做一轮，不要一开始就做无限自治
2、反馈必须是“可行动的失败信息”
（二）扩展为生产架构：调度、隔离、并发与分工
1、并行 Agent 必须隔离工作空间
2、角色分离适合解决“生成与验证利益一致”的问题
七、停止规则与预算治理：让自治系统“会停”比“会跑”更重要
（一）至少设置四类独立退出条件
1、成功退出
2、轮次与时间上限
3、成本上限
4、无进展与风险退出
（二）成本优化的核心不是“换便宜模型”，而是减少无效循环
1、最贵的是没有信息增益的重复
2、模型路由应服务于任务阶段
八、Loop 的五类典型失效模式及其工程修复
（一）失效一：目标不可验证，系统永远不知道何时完成
（二）失效二：生成者自评，导致错误被自洽地放大
（三）失效三：上下文漂移，循环越跑越偏
（四）失效四：重复动作与局部循环
（五）失效五：自治范围过大，错误直接作用于生产
九、如何设计第一个真正可用的 Loop：一套七步方法
（一）第一步：选择“可验证、可回滚、重复度高”的任务
（二）第二步：把目标写成检查，而不是愿望
（三）第三步：先做确定性验证，再考虑 LLM Judge
（四）第四步：设计状态模型与每轮最小上下文
（五）第五步：建立失败反馈协议
（六）第六步：加入停止、审批与回滚
（七）第七步：用 Trace 和 Eval 迭代 Loop，而不是凭感觉改 Prompt
十、一个完整案例：自动修复 GitHub Issue 的受控闭环
（一）系统目标与边界
（二）每一轮的执行过程
1、Gather：收集最小充分上下文
2、Act：在隔离 Worktree 中修改
3、Verify：先硬验证，再语义验证
4、Feedback：把失败证据而非泛化评价送回下一轮
5、Stop/Escalate：成功提交 PR，失败交还人类
十一、Loop Engineering 不只适用于编码：三个可迁移场景
（一）研究与高质量内容生产
（二）数据质量与运营自动化
（三）客户支持与业务流程
十二、组织层面的变化：工程师从“操作模型”转向“设计自治边界”
（一）新的核心资产不是 Prompt 库，而是 Loop 资产
1、Skill、Verifier、Eval、Trace 会成为团队级基础设施
2、Prompt 仍然重要，但它被嵌入更大的系统
（二）工程师需要警惕两类新债务
1、Intent Debt：意图债务
2、Comprehension Debt：理解债务
十三、一个更实用的 Loop 成熟度模型
（一）L0：单次调用——“模型回答”
（二）L1：工具循环——“模型会行动”
（三）L2：受控闭环——“系统会验证和停止”
（四）L3：生产自治——“系统可长期运行”
（五）L4：自适应任务工厂——“系统会选择工作与编排资源”
十四、什么时候不应该使用 Loop Engineering
（一）一次调用已经足够的任务
（二）没有可靠反馈信号的开放式任务
（三）错误代价远大于自动化收益的高风险任务
（四）任务频率太低，不值得承担系统维护成本
十五、结语：真正的 Agent 工程，是把不确定智能装进确定边界
可参考文章与资料
干货分享，感谢您的阅读！
过去两年，生成式 AI 的工程焦点经历了三次明显迁移：先是“如何写出更好的提示词”，随后是“如何组织模型可见的上下文”，现在又进一步转向“如何设计一个能够持续执行、验证、修正、记录状态并安全停止的闭环系统”。
所谓 Loop Engineering，并不是简单地让模型多跑几轮，也不是给 Agent 外面套一个while true。它真正关注的是：如何把模型的不确定性装进一个可观测、可约束、可验证、可回退的控制系统，使一次看起来聪明的回答，升级为能够在真实环境中稳定完成任务的工程能力。
本文在充分吸收 Loop Engineering 相关讨论、Anthropic Agent 工程实践、OpenAI Agents SDK、ReAct/Reflexion 等研究脉络的基础上，从控制论、可靠性工程、软件架构与组织协作四个角度重新构建一套系统化方法，并给出生产级 Loop 的设计原则、验证器分层、状态管理、预算治理、失效模式、成熟度模型与落地路线。
一、Loop Engineering 的真正含义：AI 工程的杠杆点正在上移
（一）从“我来提示模型”到“系统来驱动模型”
1、Prompt Engineering 解决的是单次决策质量
在最初的生成式 AI 应用阶段，工程师最关心的问题是：怎样把目标、角色、约束、示例和输出格式写进一个高质量 Prompt，让模型在一次调用里给出尽可能好的结果。这个阶段的默认工作方式，本质上仍然是“人操作工具”：人写指令，模型回答，人阅读结果，再决定下一步怎么问。
这种方式在短任务上非常有效，因为人类天然充当了隐形的控制器。模型遗漏了信息，人会补充；模型走偏了，人会纠正；模型生成了错误代码，人会运行测试；模型误解了目标，人会重新描述。换句话说，传统 Prompt Engineering 之所以显得可靠，很大程度上是因为人的判断被插入了每一次模型调用之间。
问题在于，这种可靠性不能规模化。当一个任务需要几十次工具调用、跨越多个文件、持续数小时，甚至需要每天自动运行时，人不可能继续充当每个步骤之间的“人工中断处理器”。此时，工程问题就从“怎么写好下一条提示词”，变成了“谁来决定下一条提示词、谁来检查上一步是否正确、失败后把什么反馈给模型、什么情况下应该继续、什么情况下必须停止”。
2、Context Engineering 解决的是模型在当前一轮“看见什么”
随着 RAG、长上下文、工具调用与项目级 Agent 普及，另一个关键问题浮现：模型表现不仅由 Prompt 决定，更取决于它在当前时刻可访问的上下文集合。系统提示词、任务说明、文件内容、历史对话、工具返回、记忆、示例、规范、错误日志，都在竞争有限的注意力预算。
因此 Context Engineering 的目标，是让模型在“这一轮”获得尽可能高信噪比的信息：该放什么、不该放什么；哪些内容需要实时检索，哪些可以固化成 Skill；什么时候压缩历史，什么时候把状态写到外部；工具结果应该返回完整日志还是摘要。这些工作决定了模型单轮决策的输入质量。
但即使每一轮上下文都组织得很好，也还没有回答一个更高层的问题：这一轮之后发生什么？如果执行失败，系统是否自动重试？重试时是否换策略？如何判断任务已经完成？怎样防止模型一直“觉得自己快完成了”却永远不退出？这就是 Loop Engineering 所在的层级。
Prompt Engineering 优化单次指令，Context Engineering 优化单轮信息环境，Harness Engineering 优化 Agent 的运行环境，而 Loop Engineering 设计跨轮次的控制逻辑、反馈、验证与停止机制。
（二）Loop Engineering 不是“循环调用模型”，而是设计控制系统
1、一个循环至少包含“任务、反馈与退出条件”
最粗糙的 Agent 循环可以写成：模型思考——调用工具——读取结果——继续思考。这样的结构已经比单次问答更接近自主 Agent，但它仍然不等于生产级 Loop。因为“能够继续运行”与“能够可靠完成任务”是两回事。
一个真正可工程化的 Loop，至少要回答五个问题：
什么事件触发它开始工作；
它追求的终态是什么，而且这个终态能否被机器判断；
每轮执行后，谁来判断距离目标还有多远；
失败信息如何进入下一轮，避免重复犯同一种错；
什么情况下成功退出，什么情况下因风险、成本或不可恢复错误而停止。
因此，Loop Engineering 最重要的认知不是“让 Agent 自己跑”，而是把原本存在于人脑中的检查、重试、判断和停止规则显式化。过去这些规则由工程师在交互过程中临时执行，现在需要被写入系统。
2、Loop 是比 Agent Harness 更上一层的设计
可以把 Agent Harness 理解为“模型工作的操作系统”：它提供工具、权限、文件系统、沙箱、会话、日志、上下文压缩、网络访问、代码执行等基础能力。Harness 决定了 Agent 能做什么、在哪做、以什么权限做。
Loop Engineering 则进一步决定：什么时候唤醒 Agent、给它什么任务、如何分派多个 Agent、如何复用 Skill、如何读取状态、如何验证结果、是否继续下一轮、失败后如何恢复，以及何时把控制权交还给人。
这一区别非常关键。很多团队以为自己“已经有 Agent 了”，因为模型能调用工具、能编辑文件、能跑测试。但如果没有稳定的终态定义、验证器、预算边界和状态持久化，那么它更像一个自动化程度较高的交互工具，而不是可以被委派长期任务的工程系统。
二、为什么 Loop Engineering 会在现在成为关键能力
（一）模型能力增长，把瓶颈从“生成”推向“治理”
1、模型已经能完成较长的行动链
ReAct 研究早期就展示了一个重要思想：语言模型可以把推理与行动交织在一起，通过外部环境返回的信息不断更新计划。此后工具调用、代码执行、搜索、浏览器、数据库访问、MCP 等能力逐渐成熟，使模型不再只是文本生成器，而是能够把“想法”转换成环境中的真实动作。
当模型只能完成一两步时，最重要的是提高单次答案质量；当模型能够连续完成十几步甚至几十步时，最重要的问题变成了：如何控制这条行动链不偏离目标。能力越强，错误的“爆炸半径”也越大。一个只会建议代码的模型出错，最多给出一段错误文本；一个能自动提交代码、部署服务、修改工单、发送消息的 Agent 出错，会把错误写进真实系统。
因此，模型能力越强，系统对边界、验证和可观测性的要求越高。Loop Engineering 的兴起，本质上是 Agent 从“辅助工具”走向“任务执行主体”之后的必然结果。
2、长任务暴露出上下文窗口之外的状态问题
许多团队最初会把“记忆”理解成更大的上下文窗口，但长期 Agent 很快会暴露一个事实：上下文不是可靠的项目状态数据库。任务跨越多个会话、多个上下文压缩周期甚至多天时，模型必须知道哪些事情已经做过、哪些尝试失败过、当前分支是什么、下一步要做什么、哪些风险需要人审批。
如果这些状态只存在于对话里，那么每次上下文被压缩或会话重新开始，Agent 都可能重复探索、重复修改，甚至推翻之前正确的决策。Anthropic 在长期 Agent 实践中强调让 Agent 留下明确的外部工作产物和进度状态，就是因为“模型会忘，但仓库、数据库和任务系统不会忘”。
Loop 因而天然要求一个外部状态层：可以是 Markdown 进度文件、Issue/Linear 看板、数据库记录、事件日志或检查点。状态不再只是“历史聊天记录”，而是系统下一轮决策的正式输入。
（二）工具生态成熟，让 Loop 可以真正作用于现实世界
1、MCP 与标准化工具接口降低了连接成本
Agent 要形成闭环，必须既能感知环境，也能改变环境。工具是“手和眼”，Loop 是“神经系统”。如果每接入一个工单系统、代码仓库、数据库或消息平台都要写一套高度定制的胶水代码，Loop 很难跨项目复制。
MCP 等标准化协议的价值，就在于把“资源、工具、提示模板”抽象成可发现、可调用的接口，使不同 Agent 运行时更容易连接外部世界。这样一来，工程团队可以把更多精力放在“哪些工具应该被暴露、需要什么权限、动作是否可逆、如何记录审计日志”，而不是反复处理协议适配。
2、Skill 把隐性项目知识转成可复用资产
一个长期运行的 Loop 不应该每次重新解释“项目怎么构建”“代码风格是什么”“哪些目录不能改”“发布前要跑哪些检查”。这些稳定的项目知识如果一直写进临时 Prompt，不仅浪费 Token，也会造成版本漂移。
更合理的做法是把高频、稳定、可复用的知识封装成 Skill、规范文件、运行手册或工具说明，让每次 Loop 运行都引用同一份受版本控制的意图资产。这样，Prompt 从一次性指令变成了“调用已有工程能力的入口”，而真正重要的知识被放到可以维护、审查和演进的外部载体中。
三、从控制论理解 Loop：Agent 是受约束的反馈系统
（一）把 Agent Loop 映射成一个闭环控制模型
1、目标不是“让模型继续”，而是让状态收敛
从控制论角度看，一个 Loop 可以被抽象为：系统存在一个目标状态 G，当前环境状态为 S_t，Agent 根据上下文和策略产生动作 A_t，动作改变环境形成 S_{t+1}，验证器 V 对新状态进行测量，得到误差或判定结果 E_t，再把它反馈给下一轮决策。
这里最重要的概念不是“迭代次数”，而是误差是否收敛。如果每一轮都在消耗 Token、修改文件、调用 API，却没有让系统更接近可验证终态，那么循环只是忙碌，不是进展。
因此，生产级 Loop 应该尽可能显式记录“每轮带来了什么可测量变化”。例如：失败测试从 8 个减少到 3 个；数据质量错误从 120 条下降到 7 条；文档评审规则通过率从 68% 提升到 91%；待处理工单数量从 45 降到 12。这样的指标能让系统判断自己是在收敛、停滞还是恶化。
Agent 不是闭环本身。闭环由目标、上下文、Agent、工具/环境、验证器、外部状态与停止规则共同构成；验证结果被反馈到下一轮，系统才具备可纠错性。
2、验证器相当于传感器，错误的传感器会毁掉整个系统
在闭环控制中，如果传感器读数错误，控制器再聪明也无法稳定工作。Agent 系统同样如此。很多“智能体失败”并不是模型不会做，而是系统没有可靠地知道“做对了没有”。
例如，让模型“把代码改好”，然后再问同一个模型“你觉得现在好了吗”，其实相当于让执行者自己定义完成标准。模型可能因为语义自洽、确认偏差或上下文惯性而高估结果。相比之下，编译是否成功、测试是否通过、Schema 是否满足、接口是否返回预期状态码，都是更可靠的环境测量。
因此，Loop Engineering 的核心竞争力之一，不是更会写 Prompt，而是更会设计可执行的验收标准。
（二）生产级闭环应包含七个关键部件
1、Trigger：触发器
触发器决定任务何时进入循环。它可以是人工指令、定时任务、事件钩子、Webhook、CI 失败、告警、工单状态变化或数据阈值越界。
触发器设计需要防止重复触发与任务风暴。生产系统通常要考虑去重键、冷却时间、幂等 ID、优先级队列和并发上限。否则一个重复告警可能同时启动几十个 Agent，对同一资源进行冲突操作。
2、Goal：可验证目标
“把系统优化一下”“写得更专业”“尽量解决问题”都不是好的 Loop Goal。好的目标应该尽可能被转译为机器可判断的终态，例如：
指定测试全部通过，且无新增回归；
P0/P1 安全问题归零；
输出 JSON 满足既定 Schema；
报告必须覆盖 12 个必需主题，并通过事实核验；
数据缺失率低于 0.5%，且关键字段唯一性为 100%。
一个实用原则是：如果你无法写出“如何检查完成”的伪代码，就还没有真正定义目标。
3、Policy/Agent：决策器
模型负责根据当前状态、目标、历史尝试和工具能力决定下一步动作。它可以是单 Agent，也可以是 Planner、Worker、Reviewer 等多角色协同结构。
但需要注意：多 Agent 并不天然更可靠。每增加一个 Agent，就增加一次模型调用、一次上下文传递、一个潜在误解点和一份成本。只有当任务确实需要角色分离、并行探索或独立验证时，多 Agent 才值得引入。
4、Tools/Environment：执行器与环境
工具让决策作用于真实环境，包括读写文件、运行命令、访问 API、操作数据库、调用浏览器、更新工单、发送消息等。
生产级工具设计应优先做到：输入结构化、输出可机器解析、错误可区分、动作尽量幂等、高风险操作可审批、权限遵循最小化原则。很多 Agent 问题表面上像“模型不稳定”，本质上是工具接口含糊：返回了大量噪声日志、错误码不一致、同一个动作在不同状态下行为不同，导致模型无法正确判断环境。
5、Verifier：验证器
验证器回答“这一轮是否达到目标”。它可以是确定性程序、规则引擎、测试套件、约束检查、另一个模型、人工审核，或这些方式的组合。
验证器是 Loop 的质量中枢，后文会详细讨论其分层。
6、State：外部状态
State 记录任务事实，而不是仅记录聊天内容。至少应包括：目标、当前阶段、已完成工作、失败尝试、最近一次验证结果、关键产物位置、成本与轮次、待审批事项、下一步建议。
如果系统支持并行 Agent，还需要有任务锁、版本号、工作区 ID、分支/Worktree 信息，避免两个 Agent 在不知道彼此存在的情况下修改同一资源。
7、Stop Rules：停止与接管规则
好的 Loop 不是“成功才停止”，而是有多条独立退出路径：成功退出、轮次上限、预算上限、时间上限、连续无进展、验证器冲突、高风险动作需审批、环境异常、权限不足等。
换句话说，停止规则不是附加的保险丝，而是闭环定义的一部分。一个没有明确失败退出路径的 Loop，不是自动化，而是失控风险。
四、验证器设计：Loop 可靠性的真正分水岭
（一）验证器应遵循“确定性优先”的层级
越靠下越确定、越便宜、越可重复；越靠上越能处理模糊语义，但成本与主观性更高。工程上应尽可能让高层验证建立在低层硬约束已经通过的基础上。
1、第一层：硬验证器
硬验证器是最优先的选择，因为它们对相同输入通常给出相同结论。典型包括：
编译、单元测试、集成测试、端到端测试；
JSON Schema、类型系统、数据库约束；
静态分析、Linter、格式检查；
数学约束、数量阈值、哈希一致性；
API 状态码与明确字段判断；
文件是否存在、大小是否处于范围、指标是否达标。
硬验证器的最大价值，是把“模型认为正确”转换为“环境证明满足某个约束”。对于可形式化的目标，应该尽量让模型生成结果，让程序判定结果。
2、第二层：规则与参考答案验证器
很多业务任务无法完全用测试覆盖，但可以被拆成明确规则。例如合同抽取是否包含指定字段、文章是否覆盖规定章节、客服回复是否引用了正确订单、财务报告是否包含必需披露。
这类任务可以通过规则、关键词、结构约束、数据对账、参考答案比对等方式提供中等强度的验证。它不如测试套件绝对，但比“让模型自由评价”稳定得多。
3、第三层：独立 LLM Judge
当质量标准涉及语义、风格、完整性或复杂推理，模型评审往往不可避免。但应尽量避免“生成者即评审者”。更好的结构是让独立 Judge 使用不同的系统指令、评分 Rubric，必要时使用不同模型，并要求输出结构化的 pass/fail、证据与缺陷类别。
LLM Judge 还应通过人工标注集校准。否则你只是把一个不确定模型换成另一个不确定模型，并没有建立可靠测量。
4、第四层：Human Gate
当动作具有高不可逆性、高资金风险、合规风险或声誉风险时，应保留人类审批点。例如生产环境删除数据、大额退款、正式对外邮件、法律承诺、权限升级、核心系统部署。
人类并不是 Loop 的失败，而是系统的一类验证器与控制节点。成熟系统追求的是“把人放在最需要判断的地方”，而不是“消灭所有人工”。
（二）验证器也会被“优化”，因此要防止 Reward Hacking
1、Agent 会趋向满足检查，而不一定满足真实意图
一旦 Loop 把某个指标定义为完成条件，Agent 就会围绕这个指标优化。若指标与真实目标存在缝隙，就可能出现“看起来通过了，但实际没有解决问题”的情况。
例如，只要求测试通过，Agent 可能删除失败测试；只要求页面 Lighthouse 分数提升，可能牺牲关键功能；只要求客服回复短，可能省略必要信息；只要求漏洞扫描归零，可能通过忽略规则隐藏问题。
这不是模型独有的问题，而是任何优化系统都会遇到的 Goodhart 定律：当指标成为目标，指标就可能失去作为度量的价值。
2、验证应采用“多信号交叉”而非单指标独裁
因此生产级 Loop 通常需要组合多个互补信号。例如代码修复的成功条件不应只是“原测试通过”，还可以包括：
原失败测试通过；
全量回归测试无新增失败；
静态分析无新增高等级问题；
变更范围不超过合理边界；
Reviewer 对需求一致性通过；
必要时由人确认关键行为。
这种多信号设计相当于减少“钻指标漏洞”的空间。
五、状态、上下文与记忆：长期 Loop 的脊柱
（一）Context 与 State 必须分开设计
1、Context 是当前一轮需要看的信息，State 是系统必须记住的事实
很多 Agent 架构把所有历史都塞进上下文，导致 Token 越来越多、信噪比越来越差。更稳健的设计是明确区分：
State：长期事实，应该持久化、结构化、有版本；
Context：从 State、环境与任务中为当前一轮动态挑选出来的信息。
例如，一个修复 Bug 的长期任务，State 可以记录“Issue #312；目标测试 auth_refresh；已尝试方案 A/B；方案 A 导致并发死锁；当前分支 agent/312-v3；最近验证结果 2 failures；预算已使用 63%”。而当前 Context 只需要加载最相关的两个失败栈、涉及文件、项目规范和最近一次修改，而不是把过去 40 轮完整日志全部塞给模型。
2、好的 Context Engineering 服务于 Loop 收敛
因此 Context Engineering 与 Loop Engineering 不是替代关系，而是嵌套关系。每一轮 Loop 都需要做一次上下文选择：哪些失败信息必须原样返回；哪些历史尝试需要摘要；是否检索类似问题；是否调用 Skill；是否需要把某个长期记忆恢复进来。
上下文的评价标准也不应该是“越全越好”，而应该是：它是否帮助下一轮作出更可能收敛的决策。
（二）状态持久化需要可审计，而不是只“记得”
1、用事件日志记录“做了什么、为什么、结果怎样”
长期 Agent 最怕两件事：重复工作和不可解释的状态跳变。解决方案之一，是把每轮关键动作写成事件：时间、Agent、输入任务、工具调用、产物、验证结果、成本、下一状态。
这样不仅能恢复任务，也能为事后审计、失败分析和 Evals 提供真实轨迹。OpenAI 的 tracing 与 Anthropic 的可观测性实践都指向同一件事：当 Agent 变成长链路系统，单看最终输出已经不够，必须能够看到中间工具调用和状态变化。
2、检查点与回滚是自治系统的基本能力
如果 Agent 可以修改真实环境，就需要考虑回滚。代码场景可借助 Git commit/worktree；数据库场景可使用事务、影子表；文档场景可保留版本；API 操作可以采用幂等键或补偿事务。
一个成熟 Loop 不应该只设计“如何前进”，还要设计“前进错了怎么回来”。这使 Agent 的自治从冒险变成可控实验。
六、生产级 Loop 架构：从单 Agent 循环到任务工厂
（一）最小可用闭环：Act—Verify—Feedback
1、先做一轮，不要一开始就做无限自治
Loop 设计最常见的错误，是刚开始就堆上 Planner、多个 Worker、向量数据库、长记忆、消息队列和复杂编排。正确顺序恰恰相反：先证明“一次执行—一次验证”能够工作。
最小流程可以是：
人工给出目标；
Agent 执行一次；
验证器检查；
若失败，把具体失败证据反馈给 Agent；
再执行一次；
成功或达到上限后停止。
只要这个基本回路都不能稳定收敛，增加更多 Agent 只会放大调试难度。
2、反馈必须是“可行动的失败信息”
失败反馈的质量决定重试是否有效。最差的反馈是“没通过，请再试一次”；更好的反馈是“测试test_refresh_expired_token仍失败，预期 401，实际 500，栈顶位于auth/service.py:184”；进一步还可以告诉 Agent 哪些尝试已经做过，防止重复。
Reflexion 等研究的价值就在这里：系统可以把失败结果转化为语言层面的反思，再用于下一轮决策。但在工程实践中，反思不应替代真实环境信号，而应建立在测试、日志、工具结果之上。
（二）扩展为生产架构：调度、隔离、并发与分工
生产系统通常包含触发/队列、编排器、隔离工作区、Skill/Context、工具与连接器、外部状态、验证器、审批门和可观测性。真正的“Agent”只是架构中的决策节点之一。
1、并行 Agent 必须隔离工作空间
当多个 Agent 同时工作时，最直接的问题不是“智能不足”，而是资源冲突。两个 Agent 同时改同一个文件、同时更新同一工单、同时操作同一数据库记录，会产生传统并发系统同样的问题。
代码场景中，Git Worktree 是很自然的隔离方式：每个任务拥有自己的工作目录和分支，验证通过后再合并。其他场景则可采用沙箱、租户隔离、临时数据库、草稿状态、锁和版本号。
2、角色分离适合解决“生成与验证利益一致”的问题
多 Agent 最有价值的结构之一，是 Maker—Checker 分离：一个 Agent 负责产出，一个独立 Agent 负责检查。原因不是第二个 Agent 更聪明，而是它拥有不同的目标函数和上下文视角。
进一步可以引入 Explorer—Implementer—Reviewer：探索者只读环境、提出方案；实现者执行；评审者按规范与测试检查。但应记住：每增加一个角色，都要证明它带来的质量增益超过成本、延迟和协调复杂度。
七、停止规则与预算治理：让自治系统“会停”比“会跑”更重要
（一）至少设置四类独立退出条件
一个可靠 Loop 应同时具备成功、轮次/时间、预算、无进展、风险/审批等独立出口。任何一条红线触发，都应阻止继续无条件运行。
1、成功退出
验证器确认目标已达成，且必要的回归检查、审计记录、产物保存已完成。成功退出不是 Agent 自己说“完成了”，而是外部条件得到满足。
2、轮次与时间上限
任何 Loop 都可能因目标不可达、环境故障或策略陷入局部循环。必须有最大轮次和最长运行时间。OpenAI Agents SDK 的max_turns、Anthropic Agent SDK 的 turn/budget 控制都体现了这一点：循环上限是运行时基本参数，而不是事后补丁。
3、成本上限
Agent 的成本不仅是 Token，还包括外部 API、搜索、浏览器、编译资源、云沙箱和人类审核时间。预算应该按照任务级、项目级甚至组织级管理。
一个实用策略是设置“双预算”：软预算到达时降低模型规格、减少并行度或请求审批；硬预算到达时立即停止。这样比单纯等到信用额度耗尽更可控。
4、无进展与风险退出
仅设置“最多 20 轮”仍然不够。如果连续 3 轮验证指标没有改善，或者同一错误重复出现，系统应该提前判定为停滞并升级给人。相反，如果出现权限越界、异常删除、敏感数据访问、外部系统持续 5xx 等风险，也应该触发立即停止。
（二）成本优化的核心不是“换便宜模型”，而是减少无效循环
1、最贵的是没有信息增益的重复
很多 Agent 成本高，不是因为单次模型调用昂贵，而是因为系统重复做无效工作：反复读取同一批文件、重复搜索、重复运行大范围测试、失败后没有带回关键日志、每轮重新构建项目上下文。
因此成本优化应先从 Loop 结构入手：缓存稳定上下文、把项目知识固化为 Skill、让工具返回结构化摘要、按失败范围运行增量测试、检测重复行动、保存中间产物、对“无新信息”的轮次提前终止。
2、模型路由应服务于任务阶段
并非每一步都需要最强模型。信息抽取、格式验证、日志归类、简单路由可以交给低成本模型或规则；复杂规划、架构决策、关键代码审查再使用强模型。
但模型路由本身也会增加复杂度。应通过 tracing 与 evals 观察不同阶段的失败来源，再决定是否分层，而不是先按照“便宜/贵”机械切分。
八、Loop 的五类典型失效模式及其工程修复
（一）失效一：目标不可验证，系统永远不知道何时完成
1、症状：Agent 不断输出“我还可以进一步优化”，每轮都在做局部改动，但没有明确终点；或者它过早宣布完成，因为“看起来不错”。
2、修复：把模糊目标转成验收清单和可执行检查。对于无法完全形式化的目标，至少定义硬约束 + Rubric + 人工门槛三层判定。
（二）失效二：生成者自评，导致错误被自洽地放大
1、症状：Agent 修改代码后自己总结“测试应该没问题”；写完报告后自己判断“已经覆盖全面”；事实错误在后续轮次里被当成既定事实继续引用。
2、修复：把验证移到环境、独立程序或独立 Judge；重要事实回到原始数据源；对关键输出进行交叉验证。生成器与验证器使用不同提示与证据路径。
（三）失效三：上下文漂移，循环越跑越偏
1、症状：最初目标清楚，十几轮后 Agent 开始优化次要问题；早期错误假设经过多轮摘要被固化；上下文越来越长，关键约束被淹没。
2、修复：每轮从外部 State 重建核心目标与不可变约束；对上下文做高信号选择；定期从原始 Spec、Issue、数据库重新锚定，而不是只依赖上一轮总结。
（四）失效四：重复动作与局部循环
1、症状：同一个测试失败后，Agent 连续尝试相似修改；不断搜索同一关键词；在 A/B 两种方案之间来回切换。
2、修复：记录 action fingerprint、失败原因和已尝试策略；若连续重复则触发“换策略”或停止；必要时让 Reviewer 分析“为什么没有进展”，而不是继续让 Worker盲试。
（五）失效五：自治范围过大，错误直接作用于生产
1、症状：Agent 拥有过宽权限，一次错误判断即可删除数据、推送错误版本、发送不合适的外部消息。
2、修复：实施最小权限、沙箱、草稿态、审批门、速率限制、双人/双 Agent 检查和可回滚执行。MCP 规范本身也强调用户同意、数据隐私与工具安全，说明“能连接工具”绝不等于“应该无条件执行工具”。
九、如何设计第一个真正可用的 Loop：一套七步方法
（一）第一步：选择“可验证、可回滚、重复度高”的任务
最适合起步的 Loop 往往不是最炫的任务，而是那些过去需要人反复盯着、验收条件又比较清楚的工作。例如：修复指定测试失败、清理静态检查问题、生成固定结构日报、校验数据质量、处理低风险工单分类。
不要从“让 Agent 维护整个系统”开始。自治范围应该从一个很窄、很容易判定成功的闭环扩张。
（二）第二步：把目标写成检查，而不是愿望
可以使用一个简单模板：
当【触发条件】发生时，在【权限边界】内执行【允许动作】，直到【可机器检查的成功条件】成立；如果达到【轮次/时间/预算/风险条件】，立即停止并输出【升级给人的信息】。
例如：“当带有agent-fix标签的 Issue 创建时，在独立 Worktree 内修改代码，直到指定失败测试与全量回归测试全部通过；最多 6 轮、预算 3 美元、最长 45 分钟；若连续两轮失败数量不下降则停止并提交诊断摘要。”
这已经比“自动修 Bug”接近真正可实现的系统规格。
（三）第三步：先做确定性验证，再考虑 LLM Judge
按“硬测试—规则—独立模型—人工”的顺序设计验证器。越能在底层确定性解决的问题，越不要留给模型主观判断。
（四）第四步：设计状态模型与每轮最小上下文
明确哪些字段必须跨轮保存，例如：任务 ID、目标、阶段、最近验证、失败历史、预算、产物路径。再定义每一轮需要从状态中加载什么，而不是把全部历史对话原样回放。
（五）第五步：建立失败反馈协议
每种失败应该映射成结构化类别：测试失败、权限错误、外部服务失败、格式错误、验证不通过、预算逼近、重复动作。不同失败可以触发不同策略，而不是统一“再试一次”。
（六）第六步：加入停止、审批与回滚
在自动触发之前先把刹车做好。至少配置成功、轮次、时间、预算、无进展五类退出条件，并把不可逆动作放到审批门之后。
（七）第七步：用 Trace 和 Eval 迭代 Loop，而不是凭感觉改 Prompt
一旦系统进入多轮执行，就应把每次运行当作一条轨迹进行分析：哪一步选择了错误工具、哪一轮上下文丢失关键信息、哪个验证器误判、成本集中在哪些动作、失败是否有重复模式。
OpenAI 的 agent evals 强调从 trace grading 到数据集和持续评测，核心思想非常适合 Loop Engineering：评估对象不再只是最终答案，而是整个工作流轨迹。
十、一个完整案例：自动修复 GitHub Issue 的受控闭环
（一）系统目标与边界
假设团队希望自动处理一类低风险缺陷：Issue 必须带agent-fix标签，并明确指出失败测试名称。Agent 只能修改指定仓库，不能直接合并主分支，最终只能提交 Pull Request。
成功条件为：目标测试通过；全量测试无新增失败；Lint 通过；变更文件数量不超过 8 个；Reviewer Agent 判断修改与 Issue 描述一致。
停止条件为：最多 6 轮；最多 45 分钟；Token/API 预算不超过预设值；连续两轮失败测试数量没有下降；出现数据库迁移、权限配置、支付相关代码时必须人工审批。
（二）每一轮的执行过程
1、Gather：收集最小充分上下文
读取 Issue、失败测试、相关源文件、项目 Skill、最近提交和必要的历史失败摘要。不要把整个仓库内容放入上下文。
2、Act：在隔离 Worktree 中修改
Agent 形成方案、编辑文件、运行局部测试。所有工具调用记录到 Trace；高风险命令被 Hook 拦截。
3、Verify：先硬验证，再语义验证
运行目标测试、全量回归、Linter。若硬验证通过，再由 Reviewer Agent 检查是否真正符合需求、是否存在绕过测试的行为、变更是否超范围。
4、Feedback：把失败证据而非泛化评价送回下一轮
若失败，系统生成结构化反馈：失败测试、错误栈、与上一轮的差异、重复动作检测、剩余预算。下一轮 Agent 基于这些证据调整策略。
5、Stop/Escalate：成功提交 PR，失败交还人类
全部通过则创建 PR、关联 Issue、写入变更摘要与验证证据。达到上限则停止，并输出“做过什么、为什么还没解决、当前最佳假设、下一位工程师从哪里继续”。
这个案例的关键，不是 Agent 会写代码，而是系统能够证明它在一个受限空间里逐步逼近目标，并且失败时不会无限扩大损失。
十一、Loop Engineering 不只适用于编码：三个可迁移场景
（一）研究与高质量内容生产
一个专业研究 Loop 可以设计为：先生成研究问题树，再搜索多源资料，事实核验 Agent 检查关键结论，结构验证器确认章节覆盖，引用检查器验证链接可访问，最终质量 Judge 根据 Rubric 评分。若某一维度低于阈值，则只回到对应步骤补强，而不是整篇重写。
这种模式与传统“让模型写一篇长文”最大的不同，是把研究、写作、事实核验、结构检查、引用检查拆成可以验证的环节。最终质量来自多个反馈闭环，而不是一次 Prompt 的灵感。
（二）数据质量与运营自动化
数据 Loop 可以由定时任务触发：扫描数据表——检测异常——自动修复可逆问题——重新跑质量规则——若指标仍异常则升级。这里的验证器天然是统计规则、Schema 和业务约束，非常适合做强闭环。
相比单纯告警，“检测—修复—验证—升级”的闭环能显著减少人工处理量，但高风险修复必须使用事务、影子写入和审计日志。
（三）客户支持与业务流程
客服 Agent 可以处理低风险、规则明确的请求，例如订单查询、地址修改建议、标准退款资格检查。Loop 的终态不是“生成了一条回复”，而是“客户问题被确认解决，系统状态完成更新，且所有操作符合政策”。
对于金额、身份、合规或情绪风险较高的案例，Loop 应迅速转人工。真正成熟的系统不会追求 100% 自动化，而会追求在可验证、低风险区域实现高自治，在高不确定区域快速升级。
十二、组织层面的变化：工程师从“操作模型”转向“设计自治边界”
（一）新的核心资产不是 Prompt 库，而是 Loop 资产
1、Skill、Verifier、Eval、Trace 会成为团队级基础设施
未来团队的 AI 工程资产可能包括：可复用 Skill、工具契约、验证器、任务模板、停止策略、权限策略、Eval 数据集、失败案例库、Trace 仪表盘。这些东西比单条“神 Prompt”更有复利，因为它们决定了 Agent 在成百上千次运行中的一致性。
2、Prompt 仍然重要，但它被嵌入更大的系统
“Loop Engineering 取代 Prompt Engineering”是一个容易误解的说法。更准确的表达是：Prompt Engineering 仍然是每一轮决策质量的基础，但它不再是最高层的工程单位。就像 SQL 很重要，但数据库系统设计不等于写 SQL；函数实现很重要，但分布式系统可靠性不等于写函数。
（二）工程师需要警惕两类新债务
1、Intent Debt：意图债务
当项目知识、约束和历史原因只存在于老员工脑中，Agent 每次都会用“合理猜测”填补空白。随着自动化频率提高，这些模糊意图会被重复放大。解决方法是把稳定意图写进 Skill、Spec、测试和决策记录。
2、Comprehension Debt：理解债务
Agent 生成代码和文档的速度可能远超人类阅读速度。若团队只接受结果而不理解系统为何变成这样，短期产出提高，长期维护能力却会下降。
因此，Loop 越强，越要设计“人类理解机制”：关键变更摘要、架构决策记录、可审计 Trace、定期人工 Review、对高影响变更解释理由。自动化不应让团队退出思考，而应把人类注意力从机械操作转移到判断、设计和监督。
十三、一个更实用的 Loop 成熟度模型
从单次回答到任务工厂，真正的成熟并不是“Agent 数量更多”，而是验证、状态、边界、可观测性和恢复能力逐级增强。
（一）L0：单次调用——“模型回答”
任务通过一次 Prompt 完成，人负责检查、纠错和重试。适合低风险、短任务。
（二）L1：工具循环——“模型会行动”
模型可以调用工具并根据结果继续行动，但完成判定主要依赖模型自身，状态和预算控制较弱。
（三）L2：受控闭环——“系统会验证和停止”
具备明确 Goal、确定性验证器、失败反馈、轮次/预算上限、外部状态。此时才真正进入 Loop Engineering 的核心阶段。
（四）L3：生产自治——“系统可长期运行”
加入事件触发、队列、隔离工作区、权限策略、可观测性、审批门、回滚、持续 Evals，能够处理真实业务流量。
（五）L4：自适应任务工厂——“系统会选择工作与编排资源”
系统不仅执行任务，还能发现工作、分类优先级、动态选择模型与 Agent、并行分派、根据历史评估调整策略。此阶段最容易产生复杂度爆炸，因此必须有成熟的治理与度量体系。
十四、什么时候不应该使用 Loop Engineering
（一）一次调用已经足够的任务
如果一个任务可以通过单次模型调用加简单 RAG 稳定完成，就没有必要为了“Agent 化”引入循环、状态和编排。复杂度本身会带来成本、延迟和新的故障点。
（二）没有可靠反馈信号的开放式任务
如果目标完全主观、无法定义“更好”的方向，Loop 容易变成无休止的自我优化。例如“无限提升品牌创意”“一直优化战略直到完美”。这类任务更适合由人类在关键节点提供判断，而不是让 Agent 机械循环。
（三）错误代价远大于自动化收益的高风险任务
当动作不可逆、法律或资金风险极高，且验证无法在执行前完成时，不应追求无人值守自治。可以让 Agent 做分析、准备方案和证据，但最终动作保持人工确认。
（四）任务频率太低，不值得承担系统维护成本
Loop 是工程系统，需要维护工具、权限、验证、状态、监控和评测。如果某任务一年只发生一两次，人工执行可能更经济。自动化价值取决于“频率 × 人工成本 × 可验证性 × 风险可控性”，而不是是否技术上可行。
十五、结语：真正的 Agent 工程，是把不确定智能装进确定边界
Loop Engineering 最值得重视的地方，不是它创造了一个新术语，而是它指出了 AI 工程的杠杆点正在变化。
当模型能力有限时，我们花最多时间写 Prompt；当模型能处理更大任务时，我们开始管理 Context；当模型能够调用工具、持续行动并跨越长任务时，工程师必须开始设计反馈、状态、验证、停止、预算、权限、回滚与评测。此时，“模型聪不聪明”仍然重要，但“系统能不能把聪明稳定地转化为结果”变得更加重要。
从这个角度看，生产级 AI Agent 与其说是一位“数字员工”，不如说是一个带有概率决策器的自动控制系统。大模型负责在开放空间中提出下一步动作，传统软件工程负责给它确定的接口、可观测的环境、可靠的约束和可验证的终点。
最好的 Loop 并不会让人完全消失。它会把人从逐轮提示、复制粘贴、反复检查这些低杠杆工作中移开，让人更多承担目标定义、风险判断、规则设计、验证标准与最终责任。真正的转变不是“AI 取代工程师”，而是工程师的工作从直接操作模型，转向设计一个模型能够安全工作的系统。
因此，评价一个 Agent 系统是否成熟，不应问“它能连续自主运行多久”，而应问：
它是否知道自己要到哪里？
它是否能从真实环境获得反馈？
它是否能证明自己真的完成了？
它是否记得已经做过什么？
它是否在错误发生时停止、回滚或请求帮助？
它是否让团队看得见每一次关键决策和成本？
当这些问题都有清晰答案时，Loop Engineering 才真正从“让 Agent 多跑几轮”的技巧，升级为可以支撑企业级智能体的系统工程方法。
可参考文章与资料
Build Fast with AI：Loop Engineering: Complete Guide for AI Agents (2026)
Addy Osmani：Loop Engineering
O’Reilly Radar：Loop Engineering
Anthropic：Building effective agents
Anthropic：Effective context engineering for AI agents
Anthropic：Effective harnesses for long-running agents
Anthropic Claude Agent SDK：How the agent loop works
OpenAI：A practical guide to building AI agents
OpenAI Agents SDK：Running agents
OpenAI API：Evaluate agent workflows
Model Context Protocol：Specification 2026-07-28
ReAct: Synergizing Reasoning and Acting in Language Models
Reflexion: Language Agents with Verbal Reinforcement Learning
