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. 审核者不能修改测试、证据采集器或发布门槛, , 否则"独立验证"退化成自我批准。