Agent Loop 的核心是触发条件、停止条件和验证标准

无法受控终止的 Agent 只是昂贵的状态污染机器；构建可靠系统的核心，是把触发条件、停止条件和验证标准显式编码进契约。

Claude Code 团队的技术分享《Getting started with loops》把 Loop 重新定义为一个受控的工作单元。我读这篇分享时，最认同的是这个定义，具体的命令行工具反倒在其次。

在刚接触 Agent 时，很多人容易有一种直觉：只要模型能自己一直跑、反复调用工具，系统就具备了「自主性」。我对这种直觉有疑虑：任何无法受控终止的 Agent，都会成为既昂贵又危险的状态污染机器。

如果一个系统只是盲目地把模型放进循环，没有明确什么时候该启动、什么时候该停下来、用什么客观指标验收，也没有失败后的熔断机制，它往往带不来生产力，反而会造成失控的额度消耗、被污染的工作区文件，以及难以排查的自动化噪音。

要把单次的 Prompt 升级为一个可复用、可交付的工作系统，我认为首要任务是把过去由人类凭感觉判断的环节，显式编码为系统的硬契约：触发条件、停止条件和验证标准。

构成受控 Loop 的三个核心问题

评估一个 Agent Loop 是否成熟，我觉得要看它如何回答这三个具体问题：

触发条件（Trigger）：系统靠什么启动？是用户在终端敲下的单次 prompt、固定时间间隔的定时任务（schedule/cron），还是外部系统（如 GitHub Webhook、PR 状态变更、消息队列）发出的事件通知？
停止条件（Stop Criteria）：系统凭什么停下来？是所有单元测试全绿、某项客观评分达到阈值、代码审查评论全部处理完毕，还是触碰了硬性的最大重试次数（turn cap）？
验证标准（Verification）：系统如何证明自己把事情做成了？是读取真实命令的返回值、通过浏览器执行交互并截图、由第二个独立的 Evaluator Agent 给出评审打分，还是必须等待人工确认？

如果这三个问题没有在代码和规则中被明确定义，所谓「Agent 自主闭环」在实际运行中就一定会退化成碰运气的概率游戏。

在《Getting started with loops》中，作者把工程中常见的 Loop 划分为了四类。结合我的理解，这四种形态代表了控制权从人类逐步向系统让渡的演进过程：

Loop 类型	交给系统的控制权	典型适用场景	主要工程风险
Turn-based（单轮次）	步骤内的局部执行与自检	方案探索、临时修补、短程任务	依赖人工肉眼把关，容易漏掉集成环境的真实问题
Goal-based（目标驱动）	终止条件的自主判断	具有明确验收断言的中长程任务	如果目标函数定义有偏差，Agent 会竭尽全力优化错误指标
Time-based（时间节拍）	触发节奏与轮询周期	监控 PR/CI、抓取数据源、同步工作区状态	轮询频率若高于外部信息更新频率，会空耗额度并产生冗余上下文
Proactive（自主长流程）	端到端完整工作流	依赖库升级、已知 Issue 修复、日常迁移	权限过大、上下文反复压缩失真、误操作对环境带来副作用

我不认为这四个层级越往后就越高级。在很多任务里，最稳妥的做法往往是从最简单的 Turn-based 开始；只有当某项任务的验收逻辑清晰、测试覆盖充分时，我才建议将其升级为 Goal-based 或 Time-based。

读这些方案时，我最担心的是过早设计复杂的调度逻辑，把底层的验证能力搁在一边。

Loop 本身没有判断力，它只会忠实地放大底座系统的既有特征。如果一个项目的代码库清晰、测试覆盖严密、规约文档健全，Loop 就能把这套确定性反复放大，省下很多时间；反之，如果一个项目的验收标准模糊、构建环境动辄报错、权限边界混乱，Loop 只会迅速把混乱扩散到整个工作区。

因此，我会在编写自动化调度之前，优先写好验证规范（Verification Skill）。

以常见的前端修改为例，我们不能仅仅要求 Agent「把按钮样式改好」就结束回合。一个可靠的验证流程应当是量化且可执行的：

验证逻辑越是能被机器客观执行并产出确定证据，Agent 就越不需要凭借自己的语义推测去猜「我是不是已经做完了」，进而可以在达到停止条件时果断退出。

适合优先做成自动化 Loop 的任务通常满足三个特征：

并不是所有的任务都适合被放进全自动的 Loop 之中。

我的看法是，在涉及以下几类场景时，必须在 Loop 中保留严格的熔断断点与人工裁决（Human in the loop）：

成熟的 Loop 系统应当接管大量机械、繁琐但验证标准清晰的重复工作，遇到需要价值判断的边界节点时，则带着完整的证据链停下来，交给人类做最终决策。人参与得少，并不能单独说明系统更成熟。