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

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

## 触发原因

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

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

## 研究问题

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

## 候选池

候选围绕六组问题扩展：

```text
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`。

## 审计方法

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

## 证据强弱

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

- 程序或环境状态与 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 的边界。

## 得到的关键判断

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

## 有效经验

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

## 仍有限制

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

## 后续门槛

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

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