Loop 工程与提议者-审核者

何时使用

• Agent 干到一半就停：写完代码不跑测试就报"完成"、用户交代两件事只办一件就汇报"都办好了"
• 需要判断 Agent 说的"已完成"是否可信，要设计验证器与终止条件
• Agent 遇到一次失败就宣布整件事办不成（过早放弃），或误以为办成了实则闭环没走完（假成功）
• 实现提议者-审核者循环（PPT/网页生成、代码生成、视频剪辑、安全与内容审查）
• 需要跨上下文刷新、跨 GUI/CLI 的长程任务连续性管理
• 循环停不下来、token 失控，需要预算与轮数上限

核心原则

• 在验证之前，"完成"只是模型的一句宣称，不是证明。 把宣称变成证明，正是 Loop 工程的课题：设计一个让 Agent 持续运转的循环——发现下一件该做的事、执行、验证、记录进度。人的角色从"给 Agent 写提示词的操作者"变成"设计循环的工程师"。
• 循环的瓶颈在验证器，而不在模型。 验证不可靠，循环转得再快，也只是把劣质产出更快地标记为完成。
• 模型可以提出"完成"，但不能批准自己的"完成"。 这是 Loop 工程最核心的可检查不变量：只有通过独立验证的结果才能写入持久进度并消耗配额。
• 审查必须引入新信息。 让同一个 Agent 生成后再自己审查，等于"让模型再想一遍"——ICLR 2024 的研究表明无外部反馈时 GPT-4 自我纠错反而把更多正确答案改错。有效的审查读的是执行反馈（测试通过/失败）、视觉反馈（渲染截图）、工具反馈（外部验证输出）。
• 审核者必须读独立证据。 不是复述提议者的解释，而是看渲染结果、执行结果、外部事实。
• 退回必须可定位。 审核意见要能指向具体修复条件（哪一页、什么 issue_type、什么严重度、怎么改），而非"看起来不太好"。
• 人的门禁在执行前拦截。 人工门禁、等待状态和预算上限应在循环继续之前就阻止它，而不是事后补救。

实践模式

1. 先识别：你的失败属于哪一种过早终止

形态	表现	根因
偷懒式假完成	只做一部分就宣称全部做完：代码写完测试没跑、部署没试就报"任务完成"；交代两件事只办一件就汇报"都办好了"	缺少覆盖全部验收项的验证清单
过早放弃	一条路走不通就宣布整件事办不成：打了一个电话被拒就告诉用户"办不了"，其实还有表单、邮件等渠道	未枚举替代路径，无重规划机制
假成功	以为办成了，实际闭环没走完：对方口头同意退款，但用户还需在 App 确认一步，Agent 却报"已办妥"	把中间确认当最终状态，缺端到端闭环校验

三种形态指向同一根源：完成的标准由模型自述，而非由验证器判定。

2. 最小循环骨架（提议者-审核者）

candidate = proposer(task, constraints)
evidence = execute_or_render(candidate)       # tests, state, screenshot, facts
review = independent_reviewer(candidate, evidence)

while review.veto and budget_remaining:
    candidate = proposer.repair(candidate, review.findings)
    evidence = execute_or_render(candidate)
    review = independent_reviewer(candidate, evidence)

if review.pass:
    publish(candidate, evidence, review)      # 连证据一起发布
else:
    escalate_or_reject(review)                # 预算耗尽则升级，不放水

三条最小不变量：

1. 审核者读取独立证据（执行结果、渲染截图、外部事实），而不是只复述提议者的解释；
2. 退回时给出可定位的修复条件（位置、问题类型、严重度、建议）；
3. 审核者不能修改测试、证据采集器或发布门槛——否则"独立验证"退化成自我批准。

3. 证据采集：为新信息设计通道

• 代码：跑测试与编译，把通过/失败与错误信息作为反馈。
• 前端 / PPT / 幻灯片：真渲染成 PNG 再交给 Vision 模型审查——截图承载着提议者写代码时完全无法获得的布局信息（溢出、拥挤、图片尺寸）。
• 视频：截取关键帧采样审查。
• 事实性内容：用外部工具（搜索、解释器、数据源）验证。
• 反面对照：只保留模型自我评估而移除工具验证，大部分提升随之消失。

4. LoopX：把循环从聊天历史抽到持久控制面

LoopX 决策 → Agent 执行 → 独立验证器证明 → LoopX 提交

• 目标与边界说明"为什么做"；门禁和待办决定"现在能做什么"；证据与配额决定"是否继续"；移交让下一轮或另一个 Agent 接着工作。
• LoopX 不替代 Agent 运行时，而是管理跨轮次的连续性。
• 验证失败进入修复或重规划；只有通过独立验证的结果才写入持久进度并消耗配额。

5. LongHorizon-Harness：MEA 循环处理长程任务

把长程执行重新表述为任务状态管理，循环实现为 Manage–Execute–Audit：

• Manager：根据原始目标、已核实进展、失败证据和剩余工作，生成下一项有界子任务；
• Executor：在全新上下文中通过 GUI 或 CLI 改变环境；
• Auditor：以只读方式检查真实结果，只有审计通过的内容才进入下一轮任务状态；失败被保留为恢复和重规划的依据。

价值在于把任务连续性从不断增长的执行历史中分离出来：上下文可以刷新、界面操作可能失败，下一轮仍从最近一次已核实的状态继续。论文在模型与执行后端相同、只改外层 loop 的对照中，WeaveBench PassRate 从 51.8% 提升到 80.7%，OSWorld 2.0 二元完成率从 2.8% 到 8.3%，Terminal-Bench 2.1 从 69.7% 到 77.2%；代价不固定——前两个基准分别多耗 2.3 倍总 token 与 3.6 倍输出 token，第三个反而少 24%。部署时还需处理旧状态失效，并用轮数、时间、费用预算防止恢复循环无限运行。

6. 预算、终止与防失控

• 每轮设轮数/token/时间上限，耗尽即升级或拒绝，不放水通过。
• 终止条件由验证器判定，不由模型自述。
• 并行 worker 场景：结算点定义为"第一个已验证成功"，用幂等的锁认领胜者后广播取消其余 worker。
• 自主性强的 Agent 用独立 API key，防止子 Agent 爆炸式增长导致 token 开销失控。

7. 扩展到更多审查场景

同一范式适用于：安全审查（提议者生成操作方案，审核者查合规与风险）、内容审核（起草回复，审核者查业务规则与用语规范）、代码审核（写代码，审核者查安全与最佳实践）。变体还包括规划者–生成者–评估者三 Agent：先约定每轮完成标准，评估者操作真实应用并提交缺陷报告。

常见陷阱

• 自我批准：让生成者同时定义验收标准、执行验证并判定通过——独立验证退化成形式。
• 无新信息的审查：同一模型重读自己的输出，准确率反而下降；等同计算量下多 Agent 辩论与单 Agent 持平。
• 模糊退回："看起来不太好"式的意见无法定位修复，循环空转。
• 证据与候选不同步：审核者看的是上一轮证据或提议者的自述，而非当前候选的真实执行结果。
• 循环转不动与停不下来是两个极端：前者是验证缺失导致假完成，后者是缺少预算与轮数上限；两者都要靠显式的终止条件和配额解决。
• 理解债：循环交付越快，人对系统实际实现的理解落后越远。可以外包思考，不能外包理解——审查者与门禁的存在正是为了让人始终能理解并指导系统。

配套代码

• chapter5/paper-to-ppt/ — Proposer 写 Slidev 代码，Reviewer 逐页真渲染 PNG 并用 Vision LLM 给结构化意见（page/issue_type/severity/suggestion + 总分与 pass），双 Agent 峰值上下文 24,186 vs 单 Agent 自审 92,601 token
• chapter5/video-edit/ — 两步 Vision 定位（10s 粗扫 → 1s 精扫）封装为子 Agent，Proposer 生成 Blender bpy / ffmpeg 剪辑脚本，Reviewer 采样关键帧复审迭代

深度阅读

• book/chapter10.md「对等协作模式」→「Loop 工程」
• book/chapter10.md「对等协作模式」→「提议者-审核者范式」