loop-engineering

# Loop 工程与提议者-审核者 ## 何时使用 - Agent 干到一半就停：写完代码不跑测试就报"完成"、用户交代两件事只办一件就汇报"都办好了" - 需要判断 Agent 说的"已完成"是否可信，要设计验证器与终止条件 - Agent 遇到一次失败就宣布整件事办不成（过早放弃），或误以为办成了实则闭环没走完（假成功） - 实现提议者-审核者循环（PPT/网页生成、代码生成、视频剪辑、安全与内容审查） - 需要跨上下文刷新、跨 GUI/CLI 的长程任务连续性管理 - 循环停不下来、token 失控，需要预算与轮数上限 ## 核心原则 - **在验证之前，"完成"只是模型的一句宣称，不是证明。** 把宣称变成证明，正是 Loop 工程的课题：设计一个让 Agent 持续运转的循环——发现下一件该做的事、执行、验证、记录进度。人的角色从"给 Agent 写提示词的操作者"变成"设计循环的工程师"。 - **循环的瓶颈在验证器，而不在模型。** 验证不可靠，循环转得再快，也只是把劣质产出更快地标记为完成。 - **模型可以提出"完成"，但不能批准自己的"完成"。** 这是 Loop 工程最核心的可检查不变量：只有通过独立验证的结果才能写入持久进度并消耗配额。 - **审查必须引入新信息。** 让同一个 Agent 生成后再自己审查，等于"让模型再想一遍"——ICLR 2024 的研究表明无外部反馈时 GPT-4 自我纠错反而把更多正确答案改错。有效的审查读的是执行反馈（测试通过/失败）、视觉反馈（渲染截图）、工具反馈（外部验证输出）。 - **审核者必须读独立证据。** 不是复述提议者的解释，而是看渲染结果、执行结果、外部事实。 - **退回必须可定位。** 审核意见要能指向具体修复条件（哪一页、什么 issue_type、什么严重度、怎么改），而非"看起来不太好"。 - **人的门禁在执行前拦截。** 人工门禁、等待状态和预算上限应在循环继续之前就阻止它，而不是事后补救。 ## 实践模式 ### 1. 先识别：你的失败属于哪一种过早终止 | 形态 | 表现 | 根因 | |---|---|---| | 偷懒式假完成 | 只做一部分就宣称全部做完：代码写完测试没跑、部署没试就报"任务完成"；交代两件事只办一件就汇报"都办好了" | 缺少覆盖全部验收项的验证清单 | | 过早放弃 | 一条路走不通就宣布整件事办不成：打了一个电话被拒就告诉用户"办不了"，其实还有表单、邮件等渠道 | 未枚举替代路径，无重规划机制 | | 假成功 | 以为办成了，实际闭环没走完：对方口头同意退款，但用户还需在 App 确认一步，Agent 却报"已办妥" | 把中间确认当最终状态，缺端到端闭环校验 | 三种形态指向同一根源：完成的标准由模型自述，而非由验证器判定。 ### 2. 最小循环骨架（提议者-审核者） ```python 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：把循环从聊天历史抽到持久控制面 ```text 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`「对等协作模式」→「提议者-审核者范式」