Audit Agent completion and recovery research

This commit is contained in:
wuyang
2026-07-28 00:06:57 +08:00
parent 5373d564ec
commit 3b55bfaad2
12 changed files with 840 additions and 21 deletions
@@ -0,0 +1,142 @@
# 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. 最后让网页呈现证据、争议和失败分支,而不是展示一个总分。