目录一、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 把隐性项目知识转成可复用资产三、从控制论理解 LoopAgent 是受约束的反馈系统一把 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 Judge4、第四层Human Gate二验证器也会被“优化”因此要防止 Reward Hacking1、Agent 会趋向满足检查而不一定满足真实意图2、验证应采用“多信号交叉”而非单指标独裁五、状态、上下文与记忆长期 Loop 的脊柱一Context 与 State 必须分开设计1、Context 是当前一轮需要看的信息State 是系统必须记住的事实2、好的 Context Engineering 服务于 Loop 收敛二状态持久化需要可审计而不是只“记得”1、用事件日志记录“做了什么、为什么、结果怎样”2、检查点与回滚是自治系统的基本能力六、生产级 Loop 架构从单 Agent 循环到任务工厂一最小可用闭环Act—Verify—Feedback1、先做一轮不要一开始就做无限自治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 从一次性指令变成了“调用已有工程能力的入口”而真正重要的知识被放到可以维护、审查和演进的外部载体中。三、从控制论理解 LoopAgent 是受约束的反馈系统一把 Agent Loop 映射成一个闭环控制模型1、目标不是“让模型继续”而是让状态收敛从控制论角度看一个 Loop 可以被抽象为系统存在一个目标状态 G当前环境状态为 S_tAgent 根据上下文和策略产生动作 A_t动作改变环境形成 S_{t1}验证器 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 Hacking1、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—Feedback1、先做一轮不要一开始就做无限自治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 AILoop Engineering: Complete Guide for AI Agents (2026)Addy OsmaniLoop EngineeringO’Reilly RadarLoop EngineeringAnthropicBuilding effective agentsAnthropicEffective context engineering for AI agentsAnthropicEffective harnesses for long-running agentsAnthropic Claude Agent SDKHow the agent loop worksOpenAIA practical guide to building AI agentsOpenAI Agents SDKRunning agentsOpenAI APIEvaluate agent workflowsModel Context ProtocolSpecification 2026-07-28ReAct: Synergizing Reasoning and Acting in Language ModelsReflexion: Language Agents with Verbal Reinforcement Learning