Loop Engineering：从提示词工程到智能体闭环设计

提示词越写越长，效果却不见得跟着涨。这几乎是所有深入做过复杂AI任务的人都会遇到的困惑。一个需要调用几次工具、从外部系统拿数据、根据中间结果做决策的任务，指望靠一次性的提示词搞定，基本是天方夜谭——哪怕你写上千字的prompt，它该翻车还是会翻车。

问题不在提示词本身，在于我们试图解决的对象变了。我们真正需要设计的，不是“下一次怎么问得更好”，而是一个能让Agent自己行动、验证、纠错、并在恰当时候停下来的完整闭环。这就是Loop Engineering要解决的核心命题。

什么是Agent闭环

Anthropic在《Building effective agents》里给过一个很精炼的定义：Agent是“在循环中，基于环境反馈来使用工具的LLM”。把这个过程拆开来看，可以分成六个环节：

流程是这样的：Agent接到一个目标，然后调用工具或生成内容，等外部环境给它反馈（比如代码跑完的结果、API的返回值、检索到的文档），接着验证这个结果是不是符合预期——不行就重试，通过了就停下来，实在搞不定就升级处理。

这六个环节里，

来自人类，是模型调用工具或生成内容，是外部系统返回的结构化信号——比如编译器的报错、搜索引擎的返回结果、数据库写入成功的确认。而是整个闭环能否可靠运转的关键：它决定结果是否被接受，以及下一次迭代该往哪个方向调整。把验证反馈变成下一轮的输入，则负责在结果合格或预算耗尽时优雅退出。

这个模式听起来像是一个简单的while循环，但每一个环节都藏着工程选择：目标要精确到什么程度模型才能理解？行动结果怎么捕获才算完整？环境反馈里的噪声和信号怎么区分？验证通过和失败的标准又是什么？

大部分团队都低估了“验证”和“停止”这两个环节的设计难度。生成这件事已经越来越便宜，真正稀缺的能力是“怎么判断做完了”和“怎么在失控之前停下来”。

图1：Agent闭环由六个环节构成，其中「验证」和「停止」是可靠性的关键控制点。

验证器是真正的瓶颈

OpenAI的Agent实践指南里有一句关键判断：只有当你能够用评估建立起基线之后，才应该开始考虑优化成本和延迟。放到闭环的语境下，这句话的意思很明确——

。

验证器通常有三种形态：

是最可靠的。测试通过、类型检查通过、lint错误清零、Schema校验通过——这些都是硬信号，没有歧义。如果任务本身可以用这些信号来定义“完成”，那就不应该依赖模型自己来评估自己。

（LLM-as-a-judge）是降级选项。Anthropic的evaluator-optimizer模式用一个模型生成、另一个模型评估，在输出可以被清晰描述并反馈时有效。但它的可靠性完全取决于评估标准和模型本身的判断能力，同一个输出放在不同上下文里，可能得到完全不同的分数。

是最实用的路径：用确定性检查覆盖所有可以编程验证的部分，用模型自评覆盖剩下的主观判断，并且把每次的验证结果作为结构化反馈传给下一轮迭代。

“不够好”不是有效反馈，“第3个接口缺少错误处理，新增的边界条件没有测试覆盖”才是。验证器输出的结构化程度越高，下一轮迭代越不容易退化成盲目的重试。

还要避免生成器和验证器共享完全相同的盲点。如果同一个模型在同一个上下文中先生成、再自评，它很容易沿用原来的错误假设。更稳妥的做法是分离上下文，或者至少让验证器使用独立的评估标准和证据。对于代码任务，测试运行结果、类型系统和静态分析应该成为第一道防线，而不是把所有判断都交给另一个模型。

LangChain在《The Art of Loop Engineering》里把Agent执行环和验证环作为可叠加的两层：Agent执行任务，grader则对照评分标准检查输出，失败就带着反馈重试。这个模式的代价是延迟和成本，但当质量比速度重要时，这种交换通常是合理的。

图2：验证器的可靠性分层——最底层的确定性检查最可靠，中间层为模型自评，最上层为两者结合的混合策略。

闭环为什么需要控制面

模型生成有随机性，工具调用可能失败，外部环境的状态不可预测。一个没有控制面的闭环，本质上就是一个不知道什么时候会停下来的循环。

这里有四个必须设计的控制面：

最基础的是“所有测试通过”或“无工具调用”。但实际场景里还需要“连续两次迭代没有任何实质变化”的收敛判断，以及“同一验证反馈重复出现N次”的停滞检测。停止条件不应该只依赖模型自述“已完成”，而应该来自环境中的客观证据或人类确认。

最大迭代次数、最大推理成本、截止时间——三者至少需要两个。OpenAI的Agent SDK用max_turns做硬边界，Anthropic也指出“停止条件（如最大迭代次数）是维持控制的关键”。预算耗尽时应该给出清晰的降级行为，而不是静默返回一个错误。比如：预算耗尽后冻结当前状态，给出最后一次的验证结果和已消耗资源，让人类决定是否继续。

如果当前迭代的验证反馈和前一次完全一致，说明循环已经不再进步。此时应该记录停滞次数，达到阈值后升级策略——换上下文、换方法、或者升级到人类。停滞检测的实现通常很简单：对验证反馈做哈希比较，连续命中三次就触发升级。

建议采用一个四阶升级：先带明确反馈重试，反馈重复则带精简摘要换上下文重试，再失败则要求换方案，最后升级到人类。资源消耗大的尝试在早期就应该被拦截，不要放任模型在同一个错误路径上反复尝试。这个升级阶梯应该对团队可见，帮助团队逐步收紧闭环的行为边界。

可观测性决定你能改进多快

没有记录就等于没有调试手段。每次迭代的输入、输出、工具调用结果、验证反馈和耗时都应该被记录下来。LangChain的hill-climbing loop概念讲的就是这个道理：分析生产轨迹，发现模式，然后改进harness配置。

需要注意的是，可观测性不等于把所有上下文永久保存。更可行的分层方式是：低风险任务只记录状态转换、成本和最终结果；关键任务额外记录工具调用、验证反馈和版本信息；涉及敏感数据时对内容脱敏，只保留调试所需的最小字段。记录越多，存储、查询和隐私成本越高，粒度应该由任务的风险等级来决定。

闭环的产物也应该是持久化的。任务定义、信号文件、交接记录——这些工件让多个Agent可以协调，也让人类可以理解到底发生了什么。更重要的是，它们把循环状态从模型上下文中剥离出来：即使上下文重置、模型切换或任务由另一个Agent接手，工作也不必从头开始。

可观测性的价值最终体现在改进速度上。如果你只知道一次运行失败了，下一次只能继续调整提示词；如果你能看到它在哪一步调用了错误工具、验证器返回了什么、预算消耗在哪里，就可以准确修改工具定义、任务拆分或停止规则。

人类应该留在哪个环

Martin Fowler网站上Kief Morris的一篇文章提出了一个简洁的分工：

。人类定义目标、价值和约束条件，Agent在框架内执行实现。

具体到落地，有三个建议的人类介入点：

第一，

“为什么做这件事”和“做成什么样才算好”不是技术问题。

第二，

OpenAI的建议很明确：超过失败阈值、涉及敏感或不可逆操作（如取消订单、授权退款、付款），在系统成熟前应保持人类审批。

第三，

Kief Morris把这种位置称为：人不必检查每一次工具调用，但要观察系统运行的结果，并改进承载循环的harness。Agent可以分析轨迹、提出改进方案，但改动harness（提示词、工具配置、验证标准）的决策需要人类确认。这不是因为人类更擅长写提示词，而是因为改变harness意味着改变整个系统的行为边界。

“完全自动化”不是目标。

这条分工在实践中意味着：人类不应该在每次迭代里逐行审批，但也绝不应该完全消失。一个健康的Agent系统，人类介入频率应随着系统成熟度下降，但介入权始终保留。如果系统在同一个任务上连续升级到人类三次，说明外层的harness需要调整——可能是验证标准不够精确、工具定义有歧义，或者任务超出了Agent的合理能力边界。这时候不是让人类继续“救火”，而是应该修改系统本身。

图3：人类与Agent的角色划分——人类负责最外层的why loop（目标定义）和最内层的on the loop（系统改进），Agent负责中间的how loop（执行）。

什么任务应该做闭环

不是所有任务都需要Loop Engineering。有几条判断标准：

• 任务需要多步工具调用或外部反馈 → 值得做 • 错误会累积且不可逆 → 必须做 • 有可靠的可验证信号（测试、Schema、结构化输出）→ 适合做 • 单次问答或低风险文案草拟 → 不要为了形式而引入循环

落地检查清单

如果你正在把现有Agent改造成可控闭环，或者计划设计一个新的Agent系统，可以逐项检查：

1. 是否定义了明确的完成条件（测试通过、Schema校验、rubric阈值）——不只是“模型觉得完成了” 2. 验证器是否与生成分离，确定性检查是否优先于模型自评 3. 失败反馈是否结构化为可作用于下一轮迭代的输入，而不是“不行，重试” 4. 是否设置了迭代次数、推理成本和截止时间中的至少两项预算边界 5. 每次迭代的轨迹是否可回放，是否存在停滞检测或重复反馈识别 6. 高风险和重复失败场景是否有人类升级路径，而不是让模型无限循环

从单次生成到可控闭环，不是让Agent多跑几轮那么简单。它要求我们把工程关注点从“让模型回答得更好”转移到“让系统在真实环境中可靠地交付结果”。验证器、停止条件、预算边界、可观测性、人类分工——这些才是下一阶段AI工程的核心命题。