Loop 工程设计：验证器、停止条件与预算

先看清循环的结构

一个生产级的 Agent Loop 大致长这样：

触发（调度）→ 执行一轮（Agent 自主决定动作）→ 验证
  ├─ 通过 → 是否满足停止条件 → 是 → 交付
  ├─ 不通过 → 分支：修改 / 换方案 / 重试（有限次）
  └─ 预算耗尽 → 停止 → 兜底

与确定性工作流的本质区别：每一轮里「做什么」由 Agent 根据当前上下文自主决定，工程者不编排步骤，只设计循环的骨架。下面逐件拆解。

调度：循环的生命从哪开始

三种基本触发方式：事件触发（用户发消息、收到邮件，像「助手」）、定时触发（每日巡检、每周周报，像「员工」，对可靠性与汇报的要求高得多）、级联触发（上游循环的产出触发本循环，适合多阶段流水线）。调度入口决定用户心智，这是循环设计的第一格。

验证器：整个循环的瓶颈

Loop Engineering 的第一共识：循环的上限不取决于模型多聪明，而取决于你多快多准地判断「这轮干得好不好」。验证缺失的循环只有两种结局：过早停止（拿到半成品）或永不停止（烧钱空转）。

验证器的四档强度，按成本从低到高：

验证方式	做法	适用
规则校验	正则、schema、断言：格式对不对、字段全不全	结构化输出
自我校验	让模型按检查清单审查自己的产出	快速反馈、低风险场景
执行校验	跑测试、跑编译、真调 API 看返回	代码与工具类任务
人工抽检	抽样人审 + 阈值放行	高风险、难量化的产出

产品决策提示：设计任何 AI 工作流前，先回答「这个任务的『完成』能不能被机器判定」。能——放心建长循环；不能——要么把任务改造成可判定的形态（拆成可校验的子任务），要么缩短循环、把人放进环里。验证器是产品定义，不是工程实现：它编码的是你对「什么叫好」的业务理解。

分支与重试：失败之后走哪条路

验证不通过时，最差的设计是无脑重试——同样的输入换不来不同的结果。分支逻辑应区分三种失败：

1. 产出瑕疵（方向对、细节差）→ 反馈验证结果，让模型修改；
2. 方案错误（方向就错了）→ 触发换路：携带失败教训重新规划；
3. 环境故障（工具超时、网络抖动）→ 原样重试，但要有限次、有退避。

关键工程件是把验证结果转化为有效的下一轮输入：告诉循环「哪里错了」比「错了」值钱得多。

预算与停止条件：循环的刹车系统

预算回答「最多花多少」，停止条件回答「什么时候算完」。缺了刹车的自主循环，最坏情况是失控烧钱（无限重试）或过度打磨（边际收益趋近于零，成本照付）。

产品侧必须显式定义的三类阈值：

• 成本预算：单次任务最多多少 token / 多少美元，超出即熔断；
• 轮次上限：最多迭代 N 轮，防止空转；
• 收敛判定：验证连续通过 K 轮、或指标达到阈值即停——「够好就停」比「做到最好」更经济。

停止有两种出口，都要设计：正常停止（完成，交付）与异常停止（预算耗尽，转兜底：降级方案、转人工、如实报告进度）。「跑了 40 分钟最后什么都没说地失败了」是最伤信任的产品事故。

透明化：让用户看见循环在呼吸

长循环必须解决「黑箱等待」问题，三条实现思路：

1. 过程日志：把每轮的动作与验证结果记录成可读的时间线；
2. 阶段播报：向用户暴露里程碑——「已定位问题 → 正在修复 → 验证中」；
3. 可介入点：在关键分支（如高成本重试前）允许用户说「停」或「换个方向」。

透明化不止是体验，还有信任与调试：循环失败时日志就是归因材料，直接反哺验证器与预算的调优。

失败模式清单与兜底

失败模式	症状	对策
空转循环	反复修改同一处，无进展	轮次上限 + 换路分支
目标漂移	循环越跑离原始目标越远	每轮重申目标 + 阶段性收敛校验
过度打磨	长期占用资源、边际收益趋零	收敛判定 + 预算熔断
验证器过松	明明不合格却宣布完成	抽检机制 + 验证阈值分级
静默失败	预算耗尽后无交代	异常停止必须触发兜底与报告

产品决策提示：上线前做一次「最坏情况演练」：故意给循环一个不可能完成的任务，观察它是否在预算内停住、是否清楚汇报了失败原因、用户能否理解发生了什么。三个问题任何一个不过关，都不要放开自主性。

本节要点

• Agent Loop 的六个工程件：调度定生命、验证定质量、分支定路径、重试定韧性、预算与停止定边界；步骤本身交给模型自主。
• 验证器是瓶颈：循环上限取决于「完成」能否被快速准确判定；四档验证强度按任务风险组合使用，验证器本质是产品定义。
• 失败要分型处理：瑕疵走修改、错误走换路、故障才重试，并把验证结果有效回灌下一轮。
• 预算、轮次、收敛判定是三重刹车，正常与异常两个停止出口都必须有兜底与汇报。
• 透明化（过程日志、阶段播报、可介入点）同时服务用户信任与循环调优；上线前用「不可能任务」演练最坏情况。