3-4 Loop 的成本控制与失效模式
成本重心的转移
用 Claude Code 做单次对话，成本模型很简单：一次请求，一张账单。
上了 loop 之后，成本模型变了——单次调用的成本不再是重心，loop 管理才是。
一个设计糟糕的 loop，10 分钟能烧掉你本来预算用一周的额度，而且什么有用的东西都没产出。
成本控制不是省钱技巧，是 loop 工程的基础设施。
三个必须有的控制手段
一、限制迭代次数（硬上限）
最简单也最重要。任何 loop 都必须有一个 MAX_ITER，到了就停，不管任务有没有完成。
MAX_ITER = 20
for i in range(MAX_ITER):
result = run_agent_tick()
if is_done(result):
break
else:
# 达到上限，报警，不要静默退出
alert("loop 达到最大迭代次数，需要人工介入")
这个上限的值怎么定？先在开发环境跑几次，看一个正常完成的任务需要多少轮，然后设成 2-3 倍。不要设成 1000 "以防万一"——那和没有上限没区别。
二、检测无进展（卡死检测）
loop 有时不会报错，而是在兜圈子：反复尝试同样的操作，反复失败，反复重试。每轮都在消耗 token，但没有任何实质进展。
检测方式：比较相邻两次 tick 的状态变化。
def has_progress(before_hash, after_hash, consecutive_no_progress):
if before_hash == after_hash:
consecutive_no_progress += 1
else:
consecutive_no_progress = 0
if consecutive_no_progress >= 3:
return False, consecutive_no_progress
return True, consecutive_no_progress
git commit hash、文件 checksum、测试通过数量——任何可以量化的状态指标都可以用来检测进展。连续 N 个 tick 没有变化，就认定卡死，停下来。
三、设 Dollar Budget
迭代次数是间接控制，dollar budget 是直接控制。每次 tick 记录 token 消耗，累计超过阈值就停。
DOLLAR_BUDGET = 5.0 # 单次任务最多 5 美元
total_cost = 0.0
for i in range(MAX_ITER):
result, tick_cost = run_agent_tick()
total_cost += tick_cost
if total_cost > DOLLAR_BUDGET:
alert(f"超出预算 ${DOLLAR_BUDGET}，已消耗 ${total_cost:.2f}")
break
if is_done(result):
break
Dollar budget 在多 agent 场景里尤其重要——orchestrator 启动多个 sub-agent，每个都在并发消耗，没有总量控制很容易失控。
最大的错误：在 Gate 可信之前启动 Loop
这是整门课最重要的一个工程判断，值得单独说清楚。
Loop 是放大器，不是修复器。
- verification gate 可信 → loop 更快地产出正确结果
- verification gate 不可信 → loop 更快地产出错误结果，而且你不知道
一个 verifier agent 总是回答"通过"，loop 会在 1 分钟内跑完所有迭代，每轮都"成功"退出，最终交付一堆没经过真正检验的产出——比手动慢慢做更糟糕，因为你以为它被验证过了。
正确的顺序：
1. 先单独测试 verification gate
├── 给它一个明确错误的输入，它能识别出来吗？
├── 给它一个明确正确的输入，它会放行吗？
└── 边界情况怎么处理？
2. gate 可信了，再启动 loop
3. loop 跑起来后，抽样人工复查几次 gate 的判断
└── gate 的准确率会随任务复杂度变化，要持续监控
不要跳过第一步。
失效模式图谱
Loop 失效的方式是有规律的，提前认识它们，出了问题能快速定位。
失效模式一：无限兜圈（Infinite Spin）
症状：loop 在跑，git 有 commit，但测试一直不过，每轮改动基本相同。
原因：模型陷入局部解，每次修复引入新问题，新问题的修复方式又和上次相似。
处理：卡死检测 + 强制停止。把当前状态和失败历史交给人工，或者换一个更高能力的模型重新启动。
失效模式二：Gate 腐化（Gate Rot）
症状：loop 稳定通过，但实际产出质量越来越差。
原因：verifier agent 的判断标准在长时间运行后发生漂移，或者任务复杂度超出了 gate 设计时的预期范围。
处理：定期人工抽查 gate 的判断，把 gate 的判断结果本身也记录到日志里，便于复盘。
失效模式三：成本爆炸（Cost Explosion）
症状：账单突然暴增，loop 还在跑。
原因：通常是某个 tick 产生了异常大的 context（比如意外读入了一个几十万行的文件），导致单轮成本极高，然后 loop 继续跑。
处理：dollar budget 硬控制 + 单 tick token 上限。超过单 tick 阈值就停，不要让异常的单轮拖垮整体预算。
失效模式四：幽灵成功（Ghost Success）
症状：loop 正常退出，报告任务完成，但实际上什么都没做对。
原因：termination condition 设计有漏洞。比如"exit code 为 0 就算成功"，但 agent 把测试文件删掉了，自然全绿。
处理：termination condition 要多层验证。光看退出码不够，还要检查产物是否存在、关键文件是否被修改、输出内容是否符合预期结构。
多 Agent 监督结构：三角模型
把前面几节的内容整合成一个完整的结构：
┌─────────────────────────────────────────┐
│ Orchestrator │
│ - 拆任务、分配、汇总 │
│ - 管迭代次数和 dollar budget │
│ - 权限：只读 + 调度，不写文件 │
└──────────────┬──────────────────────────┘
│
┌──────────┴──────────┐
▼ ▼
┌────────┐ ┌──────────┐
│ Writer │ │ Verifier │
│ Agent │ │ Agent │
│ 执行 │ │ 独立检查 │
└────────┘ └──────────┘
三角结构的核心原则：
- orchestrator 管调度，不执行具体操作
- writer 和 verifier 用不同 prompt，避免共享偏见
- verifier 的结论要有具体依据，不能只是"通过/不通过"
- orchestrator 根据 verifier 的反馈决定继续、停止、还是升级人工
这个结构不是银弹——它本身也有成本（多跑了一个 agent），也有失效模式（verifier 本身可能犯错）。但对于非确定性 loop，这是目前工程上最可靠的结构。
整门课的核心脉络
到这里，四个模块全部讲完。回头看一下整体结构：
Context Engineering 解决的是：给模型什么信息，信息怎么组织。
Harness Engineering 解决的是：模型的行为怎么被约束、被观测、被强制控制。
Loop Engineering 解决的是：怎么让 agent 自主地、持续地、可靠地完成一个目标，而不需要人全程盯着。
三层是递进关系。没有好的 context，模型判断就会漂移；没有好的 harness，loop 跑起来就没有安全网；没有好的 loop 设计，前两层再好也只是单次任务的工具，不是系统。
本节核心一句话
Loop 是放大器——gate 可信之前不要启动，启动之后要有迭代上限、卡死检测、dollar budget 三道防线。
