wuyang
143 lines
6.8 KiB
Markdown
143 lines
6.8 KiB
Markdown
# 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. 最后让网页呈现证据、争议和失败分支，而不是展示一个总分。
|