Agent 完成、验证与恢复研究审计

status: completed date: 2026-07-27 owner: Codex + user work_type: literature audit, no Agent experiment

触发原因

此前的 Agent evaluation 设计先搭了任务契约、scorer 和说明网页，但用户指出：做了很多工作，仍没有回答“大家到底在评 Agent 的什么能力，这套工作究竟有没有用”。继续实现 runner 或美化网页只会扩大未经研究支撑的设计。

用户决定先暂停实验，把研究结论整理清楚，再考虑新的网页形态。

研究问题

Agent 的“任务完成”应由什么证据支持？
状态成功、程序合规、工具使用、用户协作和副作用是什么关系？
确定性规则、LLM judge、Agent judge 和人工各自会怎样误判？
验证失败后，失败检测、根因定位、恢复选择和恢复成功是否是同一种能力？
最近半年相对早期 reflection / state benchmark 到底增加了什么？
哪些结论可以跨论文成立，哪些只是单个合成 benchmark 的机制演示？

候选池

候选围绕六组问题扩展：

false success / task completion / corrupt success
state and procedure verification / side effects / policy compliance
LLM-as-judge / agent-as-judge / evaluator validity
tool failure / dynamic replanning / recovery / stopping
failure attribution / debugging / post-failure routing
test adequacy / benchmark leakage / protocol validity / regression

最终下载并转成可检索文本的全文为 40 篇，时间范围为 2023-2026：

2023-2024 的 reflection、外部反馈和状态型环境作为历史基线；
2025 的 evaluator 审计、dual-control、测试充分性和恢复 benchmark；
2026 的过程验证、独立重放、故障路由、停止条件和 live-tool drift。

37 篇核过关键结果、消融或限制章节，进入证据账本；3 篇只作历史背景。完整 ID 与排除原因见 research/completion-verification/evidence-ledger.md。

审计方法

使用 arXiv 原始 PDF，不用搜索摘要直接形成结论。
先核实验设置、任务数、模型、比较基线和 evaluator，再读作者结论。
数字只在同论文、同协议内比较；不同 benchmark 不做横向排行榜。
同时记录正结果、负结果、回归、成本和不能外推的范围。
优先寻找能推翻设计的材料：
- 已通过测试但实际错误；
- Agent 自评成功但环境状态失败；
- verifier 重复调用仍保留偏差；
- reflection/recovery 破坏原本正确结果；
- 新组件带来 gain 同时制造 regression；
- 合成任务高分在真实模型小样本中饱和。
作者同时构造任务、故障、policy 和恢复策略时降低证据等级。
“提出了框架”与“证明了能力”严格分开。

证据强弱

本轮一般结论主要依赖下面几类直接证据：

程序或环境状态与 Agent 声明的冲突；
同任务下加入/移除 verifier、gate、repair 或 routing 的受控对照；
evaluator 与专家或独立执行结果的 precision/recall；
已通过 benchmark 的 artifact 经过额外测试后的反例；
同一失败集上不同恢复策略的最终 restoration；
重复运行的 pass^k、翻转、gain 和 regression。

下面材料只作旁证：

作者自建的合成 fault template；
只有标题或摘要的候选；
内部 benchmark 且无法复核的绝对分数；
只展示架构图、案例或“judge 看起来合理”的论文；
没有强 baseline 或变量同时改变的比较。

本轮没有做什么

没有实现或运行 K1412 Agent evaluation runner。
没有调用 Ollama 或公司 GPT-5.5 API 生成研究结论。
没有训练 verifier、recovery router 或 stopping policy。
没有修改或部署 evaluation-site/。
没有把 synthesis 中的 completion certificate 写成“已经验证的系统”。

PDF 和提取文本保存在临时研究目录，不提交仓库；可复现的 arXiv ID、关键数字和判断边界已经写入证据账本。

产物

research/completion-verification/findings.md
- 回答 Agent 实际评什么能力；
- 给出八条一般结论；
- 分析 2023-2026 的研究进展；
- 明确系统推论、未知问题和可反驳预测。
research/completion-verification/evidence-ledger.md
- 37 篇全文证据；
- 每篇的直接数字、支持范围和不能外推部分；
- 40 篇全文池与 3 篇 context 排除原因。
research/completion-verification/README.md
- 阅读顺序和与现有 evaluation contract 的边界。

得到的关键判断

完成是“任务合同相对于可观察世界是否成立”，不是最终回答的语言质量。
状态正确是必要层，但不能覆盖程序违规、未知副作用和规格缺失。
LLM judge 适合处理剩余语义和候选排序，不适合单独发布认证。
verifier 的独立权限、隔离环境和可重放证据比继续增加 judge reasoning 更重要。
验证把假成功变成明确失败；恢复需要另外测 detection、localization、routing、restoration。
不同故障需要不同动作；固定 reflection/retry/replan 都会产生回归。
变更操作需要前置 gate、变更账本和补偿语义。
评估本身要接受测试充分性、协议有效性、环境漂移和同模型基线审计。

有效经验

先找“已经被判成功但其实错误”的论文，比先收集新 benchmark 名称更快逼近评估本质。
读 recovery 论文时必须追到恢复后的外部状态；只看 diagnosis score 会严重高估价值。
最有信息量的数字通常是 false positive、严格根因定位、回归和 live drift，而不是平均成功率。
一个论文若同时掌握任务、故障和恢复策略，漂亮结果只说明内部一致，不说明外部泛化。
对一般结论使用“多种失败模式的共同约束”，而不是让论文数量投票。

仍有限制

40 篇是问题驱动的高价值样本，不是 PRISMA 式全量系统综述。
大量 2026 论文仍是 arXiv preprint，尚无独立复现。
安全、客服、代码、桌面和合成工具域的证据不能直接覆盖金融、医疗或真实业务审批。
开放任务的用户满意和语义正确仍缺少低成本、低偏差的外部 oracle。
本轮得到的候选系统设计尚未通过真实 Agent 反例测试。

后续门槛

只有在用户认可这套问题分解和一般结论后，才继续：

用研究结论重写一个最小任务合同；
选择一个 mutating task 和一个 semantic/open task；
先验证 completion certificate 是否让人更容易判断真假完成；
再决定是否实现 runner；
最后让网页呈现证据、争议和失败分支，而不是展示一个总分。

6.8 KiB Raw Blame History Unescape Escape