提示词越来越长，但效果并没有线性提升。一个需要多步工具调用、外部数据反馈、有条件分支的 AI 任务，靠单次生成几乎不可能稳定交付——哪怕写了 5000 字的 prompt 。
问题不在提示词的长度，而在工程对象本身变了。我们需要设计的不是"更好的一次提问"，而是一个能让 Agent 行动、验证、纠错并适时停止的闭环。这就是 Loop Engineering 正在解决的问题。
什么是 Agent 闭环
Anthropic 在《 Building effective agents 》里给过一个简洁的定义： Agent 是"在循环中基于环境反馈使用工具的 LLM"。把工程过程展开，可以分成六个环节：
目标 → 行动 → 环境反馈 → 验证 → 重试 → 停止
Agent 先接收一个目标，调用工具或生成输出，从环境中获取反馈（代码执行结果、 API 返回、检索到的文档），然后验证结果是否符合预期——不符合就重试，符合就停止，多次失败则升级。
这六个环节里，目标来自人类，行动是模型调用工具或生成内容，环境反馈是外部系统返回的结构化信号——比如编译器的错误输出、搜索引擎的返回结果、数据库的写入确认。验证是区分可靠闭环和死循环的核心：它决定结果是否被接受，以及后续迭代应该往哪个方向调整。重试把验证反馈变成下一轮输入，停止则负责在结果合格或预算耗尽时退出。
这个模式看起来像一个简单的 while 循环，但每一环都有工程选择：目标应该多精确才能被模型理解，行动结果应该怎样捕获才算完整，环境反馈是否有足够的信噪比，验证通过和失败的标准分别是什么。
这看起来很简单，但我认为大部分团队低估了"验证"和"停止"这两个环节的设计难度。生成已经越来越便宜，真正稀缺的是"怎么判断做完了"和"怎么在失控前停下来"。
图 1 ： Agent 闭环由六个环节构成，其中「验证」和「停止」是可靠性的关键控制点。
验证器是真正的瓶颈
OpenAI 的 Agent 实践指南里提到一个关键判断：只有当你能够用评估建立基线之后，才应该开始优化成本与延迟。放在闭环语境下，这句话的意思是——先定义 "好" 的标准，再让 Agent 去跑。
验证器有三种常见形态：
确定性检查最可靠。测试通过、类型检查通过、 lint 错误清零、 Schema 校验通过——这些都是硬信号，没有歧义。如果任务能用这些信号定义完成，就不应该依赖模型自评。
模型自评（ LLM-as-a-judge ）是降级选项。 Anthropic 的 evaluator-optimizer 模式用一个模型生成、另一个模型评估，在输出可以清晰表述反馈时有效。但它的可靠性取决于评估标准和模型本身的判断能力，同一个输出在不同上下文里可能被给出不同分数。
混合策略是最实用的路径：用确定性检查覆盖可以编程验证的部分，用模型自评覆盖剩下的主观判断，并且把每次验证结果作为结构化反馈传给下一轮迭代。
验证结果必须能驱动下一步行动。 "不够好"不是有效反馈，"第 3 个接口缺少错误处理，新增的边界条件没有测试覆盖"才是。验证器输出越结构化，下一轮迭代越不容易退化成盲目重试。
还要避免生成器和验证器共享完全相同的盲点。如果同一个模型在同一上下文中先生成、再自评，它很容易沿用原来的错误假设。更稳妥的做法是分离上下文，或者至少让验证器使用独立的 rubric 和证据。对于代码任务，测试运行结果、类型系统和静态分析应该成为第一层，而不是把所有判断交给另一个模型。
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 的一篇文章提出了一个简洁的分工：人类运行 why loop ， Agent 运行 how loop 。 人类定义目标、价值和约束条件， Agent 在框架内执行实现。
具体到落地，我建议三个人类介入点：
第一，目标定义和验收标准必须由人类确认。"为什么做这件事"和"做成什么样才算好"不是技术问题。
第二，高风险操作必须有人类闸门。 OpenAI 的建议很明确：超过失败阈值、涉及敏感或不可逆操作（如取消订单、授权退款、付款），应在系统成熟前保持人类审批。
第三，外层改进环需要人类参与。 Kief Morris 把这种位置称为 on the loop：人不必检查每一次工具调用，却要观察系统结果并改进承载循环的 harness 。 Agent 可以分析轨迹、提出改进方案，但改动 harness （提示词、工具配置、验证标准）的决策需要人类确认。这不是因为人类更擅长写提示词，而是因为改变 harness 意味着改变整个系统的行为边界。
"完全自动化"不是目标。可靠交付才是。
这条分工在实践中意味着：人类不应该在每次迭代里逐行审批，但也绝不应该完全消失。一个健康的 Agent 系统，人类介入频率应随着系统成熟度下降，但介入权始终保留。如果系统在同一个任务上连续升级到人类三次，说明外层的 harness 需要调整——可能是验证标准不够精确、工具定义有歧义，或者任务超出了 Agent 的合理能力边界。这时候不是让人类继续"救火"，而是应该修改系统本身。
图 3 ：人类与 Agent 的角色划分——人类负责最外层的 why loop （目标定义）和最内层的 on the loop （系统改进）， Agent 负责中间的 how loop （执行）。
什么任务应该做闭环
不是所有任务都需要 Loop Engineering 。我有几条判断标准：
落地检查清单
如果你正在把现有 Agent 改造成可控闭环，或者计划设计一个新的 Agent 系统，可以逐项检查：
从单次生成到可控闭环，不是让 Agent 多跑几轮那么简单。它要求我们把工程关注点从"让模型回答得更好"转移到"让系统在真实环境中可靠地交付结果"。验证器、停止条件、预算边界、可观测性、人类分工——这些才是下一阶段 AI 工程的核心命题。
