Loop 工程与过早终止

过早终止有哪三种形态？

• 定义: 对等协作最经典的用途是解决 Agent"活干到一半就停"的失败，即过早终止;

形态	表现	例子
偷懒式假完成	只做了一部分就宣称全部做完	Coding Agent 没跑测试、没试部署就报告"任务完成"；Pine AI 办完第一件就汇报"都办好了"
过早放弃	一条路走不通就宣布整件事办不成	Pine AI 打了一个电话被拒绝，就告诉用户"这事办不了"，其实还可填表单、发邮件
假成功	以为办成了，实际闭环没走完	电话里对方口头同意退款，但用户还需在 App 上确认一步，Agent 却报告"已办妥"

• 共同根源: 在验证之前，"完成"只是模型的一句宣称，不是证明;

Loop 工程要解决什么？

• 定义: Loop 工程（Loop Engineering）指设计一个让 Agent 持续运转的循环——发现下一件该做的事、执行、验证、记录进度;
• 判定权: 由验证器而不是模型自己判定"是否真的可以停";
• 人的角色转变: 从"给 Agent 写提示词的操作者"变成"设计循环的工程师";
• 命名来源: 2026 年 6 月由 Addy Osmani 总结提出；Claude Code 负责人 Boris Cherny 的说法是"我已经不再直接 prompt Claude 了，我的工作是写 loop";
• 核心共识: 循环的瓶颈在验证器，而不在模型——验证不可靠时，循环转得再快也只是把劣质产出更快地标记为完成;
• 命名与历史: 实践在前、命名在后，包括 Pine AI 在内的头部团队早已用"循环加验证"解决过早终止;

LoopX 如何把循环变成可检查的系统不变量？

• 定位: 把循环从模型的提示词与聊天历史中抽离出来，放进一个与 Agent 运行时无关的持久控制面;
• 四类要素: 目标与边界说明"为什么做"，门禁和待办决定"现在能做什么"，证据与配额决定"是否继续"，移交让下一轮或另一个 Agent 接着工作;
• 决策流:

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

• 职责边界: Agent 仍负责推理、调用工具与生成候选成果；LoopX 不替代 Agent 运行时，而是管理跨轮次的连续性;
• 写入条件: 只有通过独立验证的结果才能写入持久进度并消耗配额；验证失败进入修复或重规划；人工门禁、等待状态与预算上限在执行前阻止循环继续;
• 不变量: 模型可以提出"完成"，但不能批准自己的"完成";
• 证据强度: LoopX v0.4.0 的受控 Turn 路径仍标为实验性，因此它只是"循环 + 验证 + 终止条件"的具体框架，不是一般任务质量提升的证据;

LongHorizon-Harness 如何处理长程连续执行？

• 问题: 同一任务跨越 GUI、CLI、多个桌面应用与多次上下文刷新时的连续执行;
• 重构: 把长程执行重新表述为任务状态管理，循环实现为 Manage–Execute–Audit（MEA）;
• 三角色: Manager 根据原始目标、已核实进展、失败证据与剩余工作生成下一项有界子任务；Executor 在全新上下文中通过 GUI 或 CLI 改变环境；Auditor 以只读方式检查真实结果;
• 状态写入: 只有审计通过的内容才能进入下一轮任务状态，失败则被保留为恢复与重规划的依据;
• 后端复用: 通过适配层复用 Claude Code、Codex CLI 等执行后端，而不改写后端内部的 Agent loop;
• 对照结果（保持 Qwen 3.7-Plus 与 Claude Code 后端相同，只改变外层 loop）:

基准	基线	MEA	代价
WeaveBench PassRate	51.8%	80.7%	基线 2.3 倍总 token
OSWorld 2.0 二元完成率	2.8%	8.3%	基线 3.6 倍输出 token
Terminal-Bench 2.1 成功率	69.7%	77.2%	减少 24%

• 机制价值: 把任务连续性从不断增长的执行历史中分离出来——上下文可以刷新、界面操作可能失败，但下一轮仍能从最近一次核实的状态继续;
• 单轨迹对照: WeaveBench WEB_task_16_webrtc_simulcast_layer_audit 中，基线在 Wireshark 交互卡住后反复尝试、得分 0.59；MEA 把失败与未满足的证据项写回任务状态，后续轮次只处理缺口、得分 0.92;
• 部署注意: 需处理外部环境或用户要求变化造成的旧状态失效，并用轮数、时间与费用预算防止恢复循环无限运行;