3-2 两种 Loop 类型
先说结论
Loop 设计的核心问题只有一个：你怎么知道这次 tick 成功了？
答案的性质，决定了你的 loop 属于哪种类型，以及需要什么配套工程。
确定性 Loop
定义：成功条件客观存在，pass/fail 信号由系统给出，不依赖模型判断。
典型例子：
- 测试全部通过（
pytest退出码为 0） - 代码编译成功（
tsc无报错） - 健康检查返回 200
- lint 零 warning
- diff 和预期输出完全一致
这类 loop 的 verification gate 是机器给的，不是模型自己说"我觉得完成了"。
tick → agent 修改代码 → 跑测试 → 全绿？
├── 是 → 退出，任务完成
└── 否 → 把失败信息喂回去，下一个 tick
为什么这是最安全的类型：
模型的判断会漂移，会自我安慰，会在长 session 里系统性地高估完成度。但 pytest 不会。测试要么过要么不过，这个信号是可信的，loop 可以完全依赖它来决定退出。
适合完全无人值守：只要测试集写得好，loop 跑多少轮都不需要人介入。成本控制也简单——最多跑 N 次，N 次没过就停下来报警。
非确定性 Loop
定义：成功条件模糊，没有客观的 pass/fail 信号，需要靠判断来评估。
典型例子：
- "这段代码够不够清晰"
- "这个方案合不合理"
- "这份文档有没有覆盖关键信息"
- "这个 UI 改得好不好"
这类任务没有一个确定的终止信号。你没法用退出码来判断"文档写得好不好"。
核心问题：谁来验证？
不能让写的 agent 自己验证自己。原因很直接——模型给自己打分会系统性偏宽。它写完一篇文档，让它自己评"写得好不好"，大概率回答"挺好的"。这是 AutoGPT 时代失败的根本原因之一。
解法是引入独立的 verifier agent：
orchestrator
├── writer agent：负责产出
└── verifier agent：负责评估
├── 通过 → 告知 orchestrator 退出
└── 不通过 → 给出具体反馈，writer agent 下一轮改
verifier agent 的关键设计要求：
- 和 writer agent 用不同的 prompt，最好不同的 context——避免两个 agent 共享同样的"偏见"
- verifier 的评估标准要尽量具体，不能是"评估整体质量"，要是"检查是否覆盖了 A、B、C 三个要点"
- verifier 也会犯错，所以非确定性 loop 通常需要设置最大迭代次数 + 人工兜底
两种类型的对比
| 确定性 Loop | 非确定性 Loop | |
|---|---|---|
| 终止信号 | 客观，系统给出 | 主观，需要判断 |
| 验证方式 | 工具/测试 | verifier agent |
| 无人值守 | 可以 | 需要兜底 |
| 失控风险 | 低 | 高 |
| 适用场景 | 代码、编译、测试 | 文档、方案、设计 |
怎么选
有明确 pass/fail 信号就用确定性 loop，这是首选。如果任务本身没有客观信号，优先想的不是"怎么设计 verifier"，而是：
能不能把任务改造成有客观信号的形式？
几个常见的改造方式：
- 文档质量评估 → 拆成"是否包含指定章节标题"（结构检查，可机器验证）
- 代码风格 → 跑 lint，不通过就是不通过
- API 接口是否正确 → 写集成测试，跑通就是跑通
很多看起来"需要判断"的任务，拆细之后是有客观子条件可以验证的。尽量把非确定性 loop 里的验证条件结构化，能客观化的部分交给机器。
实在无法客观化的部分，才上 verifier agent——但要清楚这时候你引入了一个新的不确定性来源，需要对应的工程保障（迭代上限、人工审批门）。
一个容易踩的坑
在 verification gate 可信之前，不要让 loop 跑起来。
这是 3-4 会重点讲的内容，但这里先说清楚为什么：
一个烂的 verification gate（比如 verifier agent 总是说"通过"），不会让 loop 停下来——它会让 loop 更快地 ship 烂东西。loop 的速度是优势，但也是放大器，好的判断被放大，坏的判断同样被放大。
先验证 gate 可信，再启动 loop。顺序不能反。
本节核心一句话
确定性 loop 靠机器信号退出，非确定性 loop 靠独立 verifier——能改造成确定性的，优先改造，别硬上 verifier。
