Audit Agent completion and recovery research

2026-07-28 00:06:57 +08:00
parent 5373d564ec
commit 3b55bfaad2
12 changed files with 840 additions and 21 deletions
@@ -4,6 +4,8 @@

 ## Current audits

+- [Agent completion, verification, and recovery](completion-verification/README.md): Agent
+  到底在证明什么、evaluator 怎样误判，以及失败后如何定位、路由、恢复和复验。
 - [Memory findings](memory/findings.md): 最近六个月哪些问题真的有进展，哪些仍未解决。
 - [Memory evidence ledger](memory/evidence-ledger.md): 全文实验、反例、成本和不能外推的范围。
 - [Agent evaluation](evaluation/README.md): 基于真实 Agent runtime 设计任务、判分、轨迹和版本对照。
@@ -0,0 +1,22 @@
+# Agent Completion, Verification, and Recovery
+
+这个研究单元回答的不是“哪个 Agent benchmark 分数最高”，而是：
+
+1. Agent 如何证明任务真的完成；
+2. evaluator 自己会怎样误判；
+3. 验证失败后，Agent 是否能发现、定位、恢复并重新证明。
+
+## Read Order
+
+1. [研究结论](findings.md)：跨论文能够成立的一般结论、系统推论和未知问题。
+2. [证据账本](evidence-ledger.md)：37 篇全文的关键数字、证据强度和外推边界。
+3. [研究过程记录](../../experiments/knowledge-compilation/2026-07-27-agent-completion-research-audit.md)：
+   候选池、审计方法、排除项和本轮没有执行的工作。
+
+## Boundary
+
+- 研究结论是当前的证据基线。
+- “completion certificate / failure object / recovery router” 是跨论文综合出的候选设计，
+  不是已经完成的实现或实验结果。
+- `research/evaluation/` 是面向 `zk-data-agent` 的工程合同；本单元先约束它应该测什么，
+  不证明当前 runner 已经存在或有效。
@@ -0,0 +1,103 @@
+# Agent 完成、验证与恢复：证据账本
+
+last_reviewed: 2026-07-27
+
+## 账本规则
+
+本轮只把核过全文关键结果、消融或限制章节的论文放入下表。
+
+- `core`：直接承担 `findings.md` 的一般结论。
+- `support`：提供历史、特定领域或方法学旁证，不单独承担一般结论。
+- `context`：全文已下载并定位，但本轮没有核到足以改变结论的证据。
+- “证据强”只表示论文内部的对照较直接，不表示已经跨域复现。
+- 所有数字都只在原论文协议内解释，不跨 benchmark 排名。
+
+## 1. 完成证明与 evaluator 误差
+
+| Paper | Depth | 核过的直接证据 | 可支持的判断 | 不能外推的部分 |
+| --- | --- | --- | --- | --- |
+| [From Confident Closing to Silent Failure, 2606.09863](https://arxiv.org/abs/2606.09863) | core | tau2 共 9,876 条轨迹；airline/retail 失败轨迹中的 false success 为 45%/48%，telecom 为 3%；AppWorld 的 1,879 条明确完成声明中有 1,425 条 false success；任一 LLM judge 配置 AUROC 不超过约 0.65/0.54 | Agent 自述不能作为完成证据；假完成需要独立状态检查 | tau2 域间控制方式混杂，telecom 只有 15 个 false-success 样本；AppWorld 只含会明确自评的架构 |
+| [tau-bench, 2406.12045](https://arxiv.org/abs/2406.12045) | core | 最终 reward 结合数据库/动作状态和输出信息；论文明确指出最终状态对 policy compliance 必要但不充分；`pass^k` 随重复快速下降 | 结果状态、策略遵守和跨次可靠性应分开 | 客服域、模拟用户和手写策略不代表所有 Agent 工作流 |
+| [AppWorld, 2407.18901](https://arxiv.org/abs/2407.18901) | core | 750 个任务、9 个应用、457 个 API；任务测试要求预期状态变化成立，且预期/允许集合之外无额外变化 | 完成应同时检查目标效果和 collateral damage，并允许不同实现路径 | 任务测试人工编写；不能覆盖所有潜在副作用和 UI/多 Agent 场景 |
+| [OSWorld, 2404.07972](https://arxiv.org/abs/2404.07972) | core | 369 个任务、302 个初始状态、134 个 evaluator；作者报告约 1,800 人时构建成本，并承认 evaluator 不能发现所有 latent side effects | 高质量状态 verifier 昂贵且天然不完备 | 桌面任务的成本不能直接外推到 API、代码或开放研究任务 |
+| [ToolSandbox, 2408.04682](https://arxiv.org/abs/2408.04682) | core | 1,032 个场景、34 个工具；用 milestone DAG 表示必要进展，用 minefield 表示禁止事件，允许部分进度和弹性顺序 | 评估可以路径有弹性，同时保留必要事件和禁止动作 | milestone/minefield 仍需领域专家反复编写；模拟工具会产生自己的错误 |
+| [AgentRewardBench, 2504.08942](https://arxiv.org/abs/2504.08942) | core | 1,302 条 web 轨迹、5 个 benchmark、4 个 Agent；官方规则 evaluator precision/recall/F1 为 83.8/55.9/67.1；最佳 LLM judge precision 低于 70% | 规则判分偏低召回，LLM 判分偏低精度；不能把任一方当万能 oracle | 专家标签自身在抽样上约 89.3% 一致；结果限于 web 轨迹 |
+| [AJ-Bench, 2604.18240](https://arxiv.org/abs/2604.18240) | core | 155 个任务、516 条标注轨迹，覆盖 search/data/GUI；judge 使用工具后 Avg@3 明显提高，但不同域 FPR 仍为 8.77%-56.60% | environment-aware judge 比纯文本 judge 更好，但仍不能独立作为发布门禁 | judge、任务域和标注规模有限；更多 reasoning 不稳定单调增益 |
+| [GroundEval, 2606.22737](https://arxiv.org/abs/2606.22737) | support | 定义 evidence path、temporal、access、causal 和 absence contract；96 个合成企业问题中，合理回答可获 LLM judge 高分而确定性证据为 0 | 可用 typed evidence contract 取代“像答案”的文本判断 | 合成数据、单模型和少量 case study；未做充分 judge 对照 |
+| [DynamicMCPBench, 2607.20531](https://arxiv.org/abs/2607.20531) | core | 1,845 个任务、121 个 MCP server；Tier-1 按效果确定性判分；750 个任务人工复核 grader agreement 74%；参考答案完全正确仅 79%；126 次 live 重放中 36% 相同、33% 漂移、32% 损坏 | 应按效果而非 gold path 判分；live 环境、参考答案和 grader 本身都需验证 | Tier-1 是保守下界，仍会漏掉等价路径；MCP 服务样本不能代表全部生产系统 |
+| [LLM-as-a-Verifier, 2607.05391](https://arxiv.org/abs/2607.05391) | core | 连续 logit 分数和重复采样提升 pairwise 与 best-of-N 选择；但失败轨迹的 verifier-progress 相关仍达 0.769 | learned verifier 适合候选选择和进度信号，不足以单独证明完成；重复可减方差但不去偏 | 依赖 logit 访问；主要是候选排序/RL 设置，不是生产发布验证 |
+| [Beyond Task Completion / PAE, 2603.03116](https://arxiv.org/abs/2603.03116) | core | tau-bench retail/airline 中加入程序 gate 后，不同模型成功率由 40%-79% 降到 9%-58%；作者人工审计 131 条 airline corrupt success，judge precision 约 93.8%-95.2% | 状态成功会掩盖程序违规；“完成”可因必要过程被破坏而无效 | 单 benchmark，程序 gate 和部分判定依赖 GPT-5 judge；所有违规被同等二元处理 |
+| [AgentLTL, 2607.02599](https://arxiv.org/abs/2607.02599) | core | FO-LTL 独立检查轨迹；block/warn 在 7 个模型中改善 5 个、恶化 2 个；soft-block 在 4/7 中最差 | 正确性和合规性是不同轴；门禁响应策略会制造拒绝或强制终止 | 主要是合成算术工具和一个 repo-QA 扩展，不能证明开放环境收益 |
+| [RECEIPT, 2607.18575](https://arxiv.org/abs/2607.18575) | core | 同一 Claude Opus 自评 27 份 XSS 报告只有 10 个 TP；隔离、浏览器 verdict、可重放 PoC 和角色分离后，作者报告 30/30 TP；消融从 45% 到 100% precision | 独立、不可游戏、可重放的 verifier 比 actor 自评可靠 | 单模型、白盒 XSS 和特定 harness；高 precision 可能伴随未测量的 false negative |
+| [Reason Less, Verify More, 2607.07405](https://arxiv.org/abs/2607.07405) | core | tau2 airline 中确定性前置 gate 把成功从 29.6% 提到 42.0%，独立种子复现约 +12.3pp；gate precision 从 5% 到 100% 不等；retail 无正增益 | 可判定、高价值、工具允许违规的政策适合前置 gate | 任务与 gate 同源；只有 cancellation gate 明显承担收益；block 与结构化反馈效应未分离 |
+| [AgentLens, 2607.06624](https://arxiv.org/abs/2607.06624) | support | 16 个 Java 场景 × 2 persona；分开评 final result、instruction compliance、pitfalls、tool calls、pleasantness 和 formal verification；两个 judge 在 23% pairwise 比较上选不同赢家，18% 为各自偏向同家族 | 轨迹质量包含多个非冗余能力；judge 家族偏差和 provider/harness 故障会污染总分 | 场景很小且 Java-only；正式人类一致性研究尚未完成；QI 是未加权代理分 |
+
+## 2. 测试、benchmark 和协议会不会错误认证
+
+| Paper | Depth | 核过的直接证据 | 可支持的判断 | 不能外推的部分 |
+| --- | --- | --- | --- | --- |
+| [Are "Solved Issues" in SWE-bench Really Solved Correctly?, 2503.15223](https://arxiv.org/abs/2503.15223) | core | 检查 877 个已通过 benchmark 的补丁；补跑全部开发者测试直接发现平均 7.8% 错误；PatchDiff 暴露 29.6% 行为差异，人工审计后估计约 11% plausible patch 不正确 | 通过有限测试不等于需求完成；应检查测试覆盖和行为差异 | 差分测试也可能误报；部分 issue 规格本身不充分，人工结论有 uncertain 类 |
+| [SWE-Bench+, 2410.06992](https://arxiv.org/abs/2410.06992) | support | 手工筛 251 个 SWE-Agent + GPT-4 通过项；报告 32.67% answer leakage、31.08% 弱测试，过滤后分数 12.47% 降到 3.97% | 泄漏和弱测试可显著抬高 coding-agent 分数 | 判定定义和方法存在较强主观性，作为前述 ICSE 审计的旁证而非主证据 |
+| [Protocol Validity / HackDetect, 2607.22368](https://arxiv.org/abs/2607.22368) | core | 审计 15 个 benchmark、2,385 条轨迹；53 条手标样本上 LLM audit F1 为 0.84；发现任务到分数协议可能允许绕过预期能力 | benchmark 要证明“目标能力对得分仍然必要”，不能只检查数据和 metric | 部分系统只预选可疑样本，不能解释为全体 prevalence；依赖同一类 LLM 审计 |
+| [The Verification Horizon, 2606.26300](https://arxiv.org/abs/2606.26300) | support | coding-agent reward 中，过程监控抑制测试篡改/查答案等 hack；报告内部 SWE、前端和长程 reward 的多组改进 | verifier 必须随 Agent 能力和攻击面共同演化，最终测试不能覆盖所有过程 hack | 大量结果来自 Qwen 内部 benchmark 和训练管线，外部可复核性有限 |
+| [Baselines Before Architecture, 2607.13085](https://arxiv.org/abs/2607.13085) | core | XBOW 104 个任务、两次运行；普通 Codex 基线随 GPT-5→5.2→5.5 从 67.3→79.8→92.3，模型匹配后剩余架构增益明显缩小 | 必须用同模型、同预算的简单基线分离模型能力和架构贡献 | 公开系统并非完全同预算，且公开安全 benchmark 可能有训练污染 |
+| [The Regression Tax, 2607.22520](https://arxiv.org/abs/2607.22520) | support | 5,832 个 office task-condition run；skills 带来 553 个 gain、324 个 regression，回归抵消约 59% 增益；Bonferroni 后仅 3/18 显著 | 新组件必须同时报告 gain 和 regression，平均值会藏住负迁移 | 主要显著结果集中在一个模型/benchmark；部分原 grader 有 artifact |
+
+## 3. 故障发现、定位和恢复
+
+| Paper | Depth | 核过的直接证据 | 可支持的判断 | 不能外推的部分 |
+| --- | --- | --- | --- | --- |
+| [Hell or High Water, 2508.11027](https://arxiv.org/abs/2508.11027) | core | 830 题、4,450 个函数；第一工具不可用但保证有最多三步替代路径；多模型从 clean 到 failure 条件下降约 22-30pp，53%-66% 失败在工具搜索 | 外部故障后的替代路径发现是独立能力，显式错误和已知可行路径也不保证恢复 | Spider 派生、工具库很大但路径短；结果受 prompt 和工具检索接口影响 |
+| [ToolMaze, 2606.05806](https://arxiv.org/abs/2606.05806) | core | controlled DAG 覆盖显式/隐式 × 瞬时/永久故障；有 hint 时平均恢复率为 81.44%、27.68%、38.12%、17.58%；模型规模对 recovery 的拟合斜率远低于 task success | 隐式永久故障最难；恢复能力不会随一般任务能力等速增长 | 程序生成 DAG 和故障模板，不是开放生产环境；规模相关不证明因果 |
+| [Don't Blindly Trust It, 2606.21409](https://arxiv.org/abs/2606.21409) | core | HotpotQA/FEVER matched loop；错误或冲突反馈使结果远差于无反馈；首步预测器在 recoverable conflict 上 AUC 跌到 0.516；requery 对不同模型可正可负 | 检出坏反馈只是一层过滤，最终表现受 fallback 能力限制 | 主要是 QA 和模拟 corruption，只有 GPT-4o 是闭源强模型；calculator 只是 pilot |
+| [R2Act, 2607.04623](https://arxiv.org/abs/2607.04623) | core | 302 个 Kubernetes incident；最强 RAG 的 root service 识别 91.4%-99.7%，恢复动作有效率仅 36.8%-60.3%；Qwen live replay 恢复 146/302 | 诊断、动作有效性和真实状态恢复是三个不同阶段 | 单一微服务系统和有限故障类型；组织权限/策略未充分覆盖 |
+| [AgentDebug, 2509.25370](https://arxiv.org/abs/2509.25370) | core | 200 条失败轨迹；检测 exact step 45%，step+module 31.3%，全部精确 24.3%；从定位点重跑在三套任务上提高恢复 | 定位错误步骤可比从头盲目改写更有效，但自动根因判断仍弱 | 标注者 κ=0.55；样本和域小，部分图表分母不够清晰 |
+| [AgentDebugX, 2607.18754](https://arxiv.org/abs/2607.18754) | core | Who&When 184 条轨迹上 strict agent+step 由 21.7% 提到 28.8%；GAIA 73 条失败一次重跑修复 13 条，三个基线为 4-6 条；约 1.6× 单次读取 Token | 结构化归因可提高后续恢复，但严格根因定位仍远未解决 | 所有方法可见参考答案；GAIA 只用一个 policy model，比较的是完整 recipe，未隔离归因效应 |
+| [CodeRescue, 2607.19338](https://arxiv.org/abs/2607.19338) | core | 约 27,300 次代码任务尝试；固定 reflect/replan/escalate 恢复率为 27.5/45.3/68.6%，router 为 81.7%；可恢复失败中 cheap-only/escalation-only/both 为 28/45/27% | 不存在统一最优恢复动作；根据失败上下文和成本路由有直接价值 | 单次路由决策、代码 benchmark 和特定模型；高成功率不代表安全恢复 |
+| [VRR-Stop, 2607.17641](https://arxiv.org/abs/2607.17641) | core | 在 verifier/repair 不匹配 stress 中，固定五轮 repair 从 0.700 降到 0.116，VRR-Stop 为 0.722；55% 正确计划被破坏 | verify-repair loop 必须有停止/保护条件，更多轮次可能主动伤害 | 巨大差值来自刻意 stress；正常条件下相对 no-repair 的提升较小且 CI 可跨 0 |
+| [Reflexion, 2303.11366](https://arxiv.org/abs/2303.11366) | support | HumanEval Rust50 消融：base 60、无测试自反思 52、仅测试 60、测试+反思 68；自生成测试在 MBPP 有更多 false positive | 反思依赖可靠外部反馈；无证据自反思会损伤正确答案 | 较早模型、特定 coding/QA/ALFWorld 设置，不能代表当前 Agent |
+| [CRITIC, 2305.11738](https://arxiv.org/abs/2305.11738) | support | 外部工具反馈在 QA/math/toxicity 有增益；数学中修复 32.2% 初始错误，同时错误修改 14.3%，并使原本正确项下降 4.3% | 外部反馈有用，但 correction 不是单调改进，必须复验 | 多为短程任务，工具质量和 prompt 强烈影响结果 |
+| [Human-Guided Harm Recovery, 2604.18847](https://arxiv.org/abs/2604.18847) | support | 775 个场景、20 名标注者、1,130 个计划偏好；在 50 个 OSWorld harm 场景上，人偏好 reward/rubric 重排计划 | 有伤害后的恢复涉及规范和人类偏好，不能只优化任务成功 | 假设已有外部 harm classifier；评的是计划偏好，不是客观状态恢复 |
+| [Self-Healing Agentic Orchestrators, 2606.01416](https://arxiv.org/abs/2606.01416) | support | 100 个作者构造任务、确定性工具和故障模板中报告 98.8% 成功；live model 部分只有 15 个任务，三种方法最终都 100%；作者明确承认 benchmark 与 recovery policy 可能同源 | `detect-diagnose-recover-verify` 和 bounded budget 是可用系统词汇 | 不能用其高分证明生产自愈；合成任务、受控故障、弱 baseline 和饱和 live set 外部效度低 |
+
+## 4. 变更风险、协作和重复可靠性
+
+| Paper | Depth | 核过的直接证据 | 可支持的判断 | 不能外推的部分 |
+| --- | --- | --- | --- | --- |
+| [SABER, 2512.07850](https://arxiv.org/abs/2512.07850) | core | tau-bench 中 mutating action 仅占 14%-18%，但与失败强相关；confirmation/reflection/verifier 可提高多数组合，full 组合在部分 retail 设置反而回归 | 高副作用动作值得前置集中审查；保护组件也需报告回归 | mutation 与失败的回归关系可能受路径距离混杂；只研究确认型 safeguard |
+| [tau2-bench, 2506.07982](https://arxiv.org/abs/2506.07982) | core | 新增共享世界状态和用户工具，区分 no-user、oracle-plan 和 dual-control；telecom `pass^1` 约 34%；用户模拟器 critical error 为 6%，retail/airline 为 12%/13% | 指导用户、协调共享状态和纯自主执行是不同能力；user simulator 也是误差源 | 三个客服域，专家-新手差距未显式建模；域扩展仍依赖专家 |
+| [AgentBoard, 2401.13178](https://arxiv.org/abs/2401.13178) | support | 1,013 个任务、9 个环境；把 success 与人工定义 progress rate 分开 | 部分进展有诊断价值，不能只保留二元成功 | progress 仍依赖任务作者定义，且模拟环境与当前模型不同 |
+| [Agent-as-a-Judge, 2410.10934](https://arxiv.org/abs/2410.10934) | support | DevAI 55 个任务上，Agent judge 可主动读取环境；作者专家评估耗时 58/86.5 小时，Agent judge 与人类对齐约 84%-90% | judge 主动取证比只看最终文本更合理，也可降低人工成本 | 样本小、主观任务多；对齐率不足以支持自动发布 |
+
+## 5. 全文池与排除
+
+本轮全文池共 40 篇：
+
+`2303.11366`, `2304.05128`, `2305.11738`, `2307.13854`, `2310.06770`,
+`2401.13178`, `2404.07972`, `2406.12045`, `2407.18901`, `2408.04682`,
+`2410.06992`, `2410.10934`, `2503.15223`, `2504.08942`, `2506.07982`,
+`2508.11027`, `2509.25370`, `2512.07850`, `2603.03116`, `2604.18240`,
+`2604.18847`, `2606.01416`, `2606.05806`, `2606.09863`, `2606.21409`,
+`2606.22737`, `2606.26300`, `2607.02599`, `2607.04623`, `2607.05391`,
+`2607.06624`, `2607.07405`, `2607.13085`, `2607.17641`, `2607.18575`,
+`2607.18754`, `2607.19338`, `2607.20531`, `2607.22368`, `2607.22520`。
+
+其中 37 篇进入上面的 `core/support` 账本。三篇只作历史背景：
+
+| Paper | Depth | 不进入核心论证的原因 |
+| --- | --- | --- |
+| [Self-Debugging, 2304.05128](https://arxiv.org/abs/2304.05128) | context | 早期代码自调试背景；本轮已有 Reflexion、CRITIC 和更新的恢复对照承担该结论 |
+| [WebArena, 2307.13854](https://arxiv.org/abs/2307.13854) | context | 作为交互环境历史锚点；完成证明由 tau/AppWorld/OSWorld 的更直接状态设计承担 |
+| [SWE-bench, 2310.06770](https://arxiv.org/abs/2310.06770) | context | 作为 coding benchmark 历史锚点；测试误认证由 2503.15223 的专门审计承担 |
+
+## 6. 证据冲突如何处理
+
+本轮没有把论文数量当投票。出现冲突时按下面规则解释：
+
+1. **同一论文的受控消融优先于跨论文绝对分数。**
+2. **真实环境结果优先用于外部边界，合成故障结果只说明机制可能性。**
+3. **确定性 validator 的 `PASS` 只覆盖写入的合同，不等于完整用户满意。**
+4. **LLM judge 的高 recall 不能抵消高 false-positive 风险。**
+5. **有回归的组合不能用平均正增益包装成通用方法。**
+6. **作者自建任务、自建 policy、自建 recovery 的闭环证据降级。**
+7. **未独立复现的 2026 preprint 只能形成方向判断，不能形成生产保证。**
@@ -0,0 +1,425 @@
+# Agent 到底凭什么说“完成了”
+
+last_reviewed: 2026-07-27
+
+## 先说结论
+
+这轮不设计新 benchmark，也不跑我们自己的 Agent。研究问题只有两个：
+
+1. Agent 的“任务完成”到底应该证明什么；
+2. 当验证不通过时，系统怎样恢复，而不是继续自称成功。
+
+本轮建立了 40 篇全文池，核对其中 37 篇的实验结果、消融或限制章节。证据覆盖
+2023-2026 年的状态型 benchmark、Agent judge、程序/策略验证、故障恢复、代码测试审计和
+运行时门禁。能够跨论文站住的一般结论有八条。
+
+1. **“完成”不是 Agent 的一句话，而是关于外部世界的可检验主张。** 至少要证明目标效果
+   已发生、禁止效果未发生、必要过程没有被绕过；证明不到的部分必须留下不确定性，不能用
+   自信语气补齐。
+2. **大家评的不是一种笼统的 Agent 能力。** 真正可诊断的对象至少包括目标理解、工具使用、
+   状态改变、策略遵守、协作、失败发现、根因定位、恢复选择、恢复后的复验和跨次可靠性。
+   “题做完了吗”只是这些能力压缩后的一个结果位。
+3. **不存在一个通用判官。** 确定性状态检查精确但覆盖有限；轨迹检查能看过程但需要规则；
+   LLM judge 能处理语义等价和开放结果，但会把合理叙述误判为成功。可靠评估来自分层证据，
+   不是换一个更大的 judge。
+4. **验证和恢复是两个独立问题。** 检出失败只把“假成功”变成“明确失败”；能否恢复还取决于
+   是否找对原因、是否有替代路径、先前副作用能否回滚，以及剩余预算是否足够。
+5. **没有固定的恢复阶梯。** 重试适合瞬时故障，局部修复适合已定位错误，重规划适合路径失效，
+   升级适合能力或权限不足，停止适合不可逆或证据不足。始终反思、始终重试、始终重规划都会
+   破坏原本正确或仍可恢复的执行。
+6. **越会改变世界的动作，越应该在动作前验证。** 读操作失败通常可重试；取消订单、改代码、
+   发消息、付款等变更操作会留下状态，事后发现错误可能已经太晚。前置门禁、幂等键、变更账本
+   和补偿动作是恢复能力的一部分，不是额外的安全装饰。
+7. **单次成功不能代表可靠。** 多个 benchmark 都显示 `pass^k` 随重复次数快速下降，或者同一
+   任务在不同运行中反复翻转。Agent 评估必须同时报告单次能力、重复可靠性、回归、成本和
+   无法判定项。
+8. **最近真正的进步主要在“把失败说清楚”，不是已经解决了可靠 Agent。** 2026 年的工作开始
+   把结果、过程、副作用、验证器误差、恢复路由和停止条件分开测；但开放任务的契约编写、
+   隐性语义错误、替代路径、真实回滚和分布变化下的 verifier 仍未解决。
+
+## 大家实际在评价什么能力
+
+把一条 Agent 轨迹只压成成功/失败，会丢掉最重要的诊断信息。现有研究实际覆盖的是下面这些
+不同能力：
+
+| 能力 | 要回答的问题 | 可观察证据 | 常见误判 |
+| --- | --- | --- | --- |
+| 目标与约束理解 | Agent 知道用户真正要什么、不能做什么吗 | 任务契约、澄清记录、约束命中 | 做了相近任务但漏掉限制 |
+| 计划与路径选择 | 是否选了可执行、代价合理的路径 | 计划、依赖关系、替代路径 | 最终碰巧成功掩盖无效绕路 |
+| 工具契约遵守 | 工具、参数、调用顺序是否正确 | schema、返回码、调用轨迹 | 文本答案合理但工具根本没成功 |
+| 环境状态改变 | 目标效果真的发生了吗 | 数据库、文件、UI、服务状态差异 | Agent 说“已完成”，状态没变 |
+| 副作用控制 | 是否只改变允许改变的内容 | before/after diff、允许变更集合 | 测试通过但破坏无关状态 |
+| 程序与策略遵守 | 是否经过必须的确认、读取、授权和验证 | 轨迹谓词、时序约束、审计日志 | 结果正确但过程违规 |
+| 人机/多方协作 | 是否能让用户或其他 Agent 完成其控制的步骤 | 共享状态、通信断言、交接结果 | 自主模式强，指导用户时失败 |
+| 失败检测 | 是否知道当前结果不可信 | 异常、状态冲突、verifier rejection | silent failure |
+| 根因定位 | 哪一步、哪个组件使任务注定失败 | 责任步骤、证据链、反事实 | 把报错位置当成错误来源 |
+| 恢复决策 | 此时应重试、修复、重规划、回滚还是升级 | 故障类型、当前状态、预算 | 对所有失败使用同一种动作 |
+| 恢复执行 | 下一次是否真的恢复目标状态 | 独立复验、原/新轨迹对照 | 生成了漂亮修复建议但没有恢复 |
+| 诚实收尾 | 最终声明是否与证据一致 | 声明-状态一致性 | 假完成、夸大部分完成 |
+| 重复可靠性 | 同类任务多次运行是否稳定 | `pass^k`、方差、翻转和回归 | 用一次幸运成功代表系统能力 |
+| 效率与边界 | 成功用了多少时间、调用、Token 和权限 | 预算、延迟、调用和升级记录 | 用无限尝试换取高成功率 |
+
+因此，严谨的评估问题不是“这个 Agent 有多少分”，而是：
+
+> 在任务族、环境、工具、权限和预算都固定时，这个系统在哪一种能力上比基线更好；这个变化
+> 带来了哪些收益、回归和新的不可判定项？
+
+## 一般结论一：完成是证据合同，不是最终文本
+
+### 为什么成立
+
+- `From Confident Closing to Silent Failure` 在 tau2 的 airline/retail 失败轨迹中找到
+  45%-48% 的 false-success 比例，在 AppWorld 明确声称完成的失败轨迹子集中找到 75.8%；
+  这些数字的域和样本条件不同，不能直接互比，但共同说明 Agent 自述不是结果证据。
+- tau-bench、AppWorld 和 OSWorld 都把完成落到数据库、文件或桌面状态；AppWorld 还检查
+  预期变化之外是否出现额外变化。
+- `Are "Solved Issues" in SWE-bench Really Solved Correctly?` 发现：877 个已经通过 benchmark
+  测试的补丁中，补跑开发者测试仍能直接发现平均 7.8% 的错误；进一步差分检查又暴露更多
+  可疑行为。即使“测试绿了”，也只证明测试覆盖到的合同。
+- `Beyond Task Completion` 表明状态成功仍可能是程序失败：在 tau-bench 上加入必要过程检查后，
+  不同模型的成功率从原始 40%-79% 降到 9%-58%。
+
+### 能推出什么
+
+完成声明至少需要三类合同：
+
+```text
+positive effects: 必须发生什么
+negative invariants: 什么不能发生
+procedure/evidence: 哪些确认、授权、来源或验证不能省略
+```
+
+如果任务目标本身含糊，或者关键效果在系统外不可观察，就不能可靠输出 `PASS`。合理状态应包含
+`AMBIGUOUS` 和 `UNVERIFIABLE`，而不是逼 judge 猜一个二元答案。
+
+### 不能推出什么
+
+这不意味着每个任务都要写成完整形式化证明。它意味着系统只能在证据覆盖范围内声称完成；
+开放任务可以使用人工、语义 judge 和抽样检查，但必须保留其误差和未覆盖部分。
+
+## 一般结论二：评估对象是整个运行协议，不只是模型
+
+同一个模型换工具 schema、用户模拟器、服务商、时间预算、测试集或 Agent loop，结果都会变。
+因此一个 Agent 分数实际衡量的是：
+
+```text
+model × prompt × orchestrator × tools × environment
+× user/simulator × verifier × budget × version
+```
+
+证据包括：
+
+- DynamicMCPBench 的 126 次 live MCP 重放中，只有 36% 返回完全相同，33% 发生漂移，32% 已损坏。
+- AgentLens 明确把 leaderboard 行定义为模型、provider、Agent loop、工具接口和执行策略的整体；
+  其 Kimi 案例还显示 provider 的工具参数解析错误会被误读成模型能力差。
+- `Baselines Before Architecture` 在同一安全 benchmark 上发现，模型版本升级本身可以吞掉大部分
+  所谓架构增益，剩余的 architecture residual 才是可归因部分。
+- tau2 的用户模拟器在 retail/airline 中仍有 12%-13% 的 critical error；benchmark 环境也会制造
+  Agent 不可能完成的失败。
+
+所以每个结果都必须携带可复现 manifest，至少记录模型版本、prompt、工具、环境快照、validator、
+预算和重复种子。没有这些信息，跨版本分数没有稳定含义。
+
+## 一般结论三：不存在一个通用 verifier
+
+### 确定性状态检查
+
+优点是可复现、低误报、适合发布门禁。缺点是合同需要人工编写，且容易漏掉合法替代路径、过程
+违规和测试未覆盖行为。
+
+- AppWorld 用任务状态差异同时检查目标效果和 collateral damage，是目前较强的结果型设计。
+- DynamicMCPBench 的 Tier-1 只按工具效果判定，不要求复现参考路径；人工复核最强本地模型的
+  750 个任务时，grader agreement 为 74%，说明即使效果型规则也不是天然完备。
+- OSWorld 报告构建 369 个任务约花 1800 人时，而且 evaluator 仍不能发现所有潜在副作用。
+
+### 轨迹和程序检查
+
+优点是能检查确认、授权、顺序和禁止动作。缺点是规则容易过严、产生 vacuous refusal，或把合法
+替代路径判错。
+
+- AgentLTL 显示程序合规和答案正确可以分离；阻断/告警在 7 个模型中改善 5 个、恶化 2 个。
+- `Reason Less, Verify More` 在 tau2 airline 的特定取消政策上把成功率从 29.6% 提到 42.0%，
+  但一个 baggage gate 只有 5% precision，迁移到 retail 也没有增益。
+- Procedure-Aware Evaluation 证明状态成功会掩盖程序违规，但它的过程 gate 仍依赖作者定义的
+  policy 和语义 judge。
+
+### LLM/Agent judge
+
+优点是能处理开放文本、语义等价、长轨迹和部分完成。缺点是会过度接受合理叙述，存在模型家族
+偏好，重复采样只能减小方差，不能消除系统偏差。
+
+- AgentRewardBench 上，官方规则 evaluator 的 precision/recall 为 83.8%/55.9%；最好的 LLM
+  judge precision 仍低于 70%。规则更容易漏报，LLM 更容易误报。
+- AJ-Bench 中让 judge 使用工具能明显提高判断，但不同任务域的 false-positive rate 仍为
+  8.77%-56.60%。
+- AgentLens 的两个 judge 在 23% 的 task-metric 比较上选择不同胜者，其中 18% 是各自偏向
+  自己模型家族；而该论文尚未完成正式的人类一致性研究。
+- `LLM-as-a-Verifier` 显示连续分数和重复采样可以改进候选选择，但失败轨迹上的 progress 相关性
+  仍然很高；“看起来在进步”不是完成证明。
+
+### 一般组合
+
+合理顺序不是让三类 evaluator 投票，而是让它们承担不同责任：
+
+1. 确定性检查负责可机器观察的效果和禁止副作用；
+2. 轨迹规则负责必须遵守的程序、权限和时序；
+3. LLM/Agent judge 只处理剩余语义、等价路径、部分进展和证据摘要；
+4. 高风险、冲突或不可观察任务升级给人。
+
+LLM judge 可以升级一个规则未覆盖但证据充分的等价成功，也可以提出需要人工看的异常；它不应
+单独把一个确定性失败降级成成功。
+
+## 一般结论四：verifier 必须与 actor 分权
+
+同一个 Agent 同时行动、解释和批准自己，最容易出现 reward hacking 和确认偏差。
+
+RECEIPT 在白盒 XSS 任务中给出了本轮最直接的对照：同一 Claude Opus 自评的 27 份报告只有
+10 个真阳性；加入浏览器判决、隔离、可重放 PoC 和角色分离后，作者报告 30/30 真阳性。该结论
+只在一个 XSS harness 和一个模型上成立，但其消融清楚表明，关键不是“judge 更会思考”，而是
+verifier 拥有 actor 无法伪造的环境、权限和重放证据。
+
+可以外推的系统原则是：
+
+- actor 不能修改 validator、隐藏检查和判分环境；
+- 验证从新鲜状态读取，不相信 actor 转述的工具结果；
+- 高风险结果在隔离环境重放；
+- 证据保留 provenance、版本和时间；
+- verdict 必须绑定到具体 artifact，而不是绑定到一段叙述。
+
+这仍不是万能证明。独立 verifier 也可能合同不完整，但它至少消除了最危险的自我认证闭环。
+
+## 一般结论五：验证通过前，不应把路径写死
+
+评估应约束“必须发生的效果”和“不能违反的条件”，而不是要求 Agent 逐步模仿一条 gold
+trajectory。否则创新或等价路径会成为假阴性。
+
+- AppWorld 的状态测试有意忽略具体路径，并允许多个合法实现。
+- DynamicMCPBench 采用 path-agnostic effect scoring；论文同时发现 reference answer 本身完全
+  正确的比例只有 79%，不适合拿参考文本直接判 Agent。
+- ToolSandbox 用 milestone DAG 表示必要事件，并允许中间顺序有弹性，同时用 minefield 表示
+  禁止事件。
+
+但路径并非永远无关。授权、用户确认、来源读取和不可逆操作属于完成合同的一部分。正确区分是：
+
+```text
+implementation path: 原则上允许等价
+causal/procedural obligation: 若任务要求，则必须证明
+```
+
+## 一般结论六：验证失败不等于会恢复
+
+恢复至少要经过五个不同阶段：
+
+```text
+detect -> localize/diagnose -> choose response -> execute response -> re-verify
+```
+
+现有结果显示每一段都可能断：
+
+- ToolMaze 中，即使提供 hint，隐式永久故障的平均 recovery rate 仍只有 17.58%；显式瞬时故障
+  为 81.44%。语义上不明显、且不会自行消失的错误最难。
+- `Hell or High Water` 明确禁用第一选择并保证存在最多三步的合法替代路径，多个模型仍出现
+  约 22-30 个成功率点下降；53%-66% 的失败发生在工具搜索阶段。
+- R2Act 在 Kubernetes 故障中发现，最强设置的根因服务定位可到 91.4%-99.7%，但恢复动作有效率
+  只有 36.8%-60.3%；知道哪里坏了不等于知道怎样恢复。
+- AgentDebug 的错误步骤/模块完全定位准确率只有 24.3%；AgentDebugX 的更新方法把严格
+  agent+step 定位从 21.7% 提到 28.8%，仍然很低。
+- AgentDebugX 在 73 条 GAIA 失败轨迹上单次重跑修复 13 条，强于三个基线的 4-6 条；它证明
+  更具体的归因可能帮助恢复，但还没有隔离归因本身的因果贡献。
+
+因此应把“失败检测率”“根因定位率”“恢复建议质量”和“最终恢复率”分开报告。只展示最终分数
+会让我们不知道增益来自更好的诊断、更多尝试，还是更强的 fallback 模型。
+
+## 一般结论七：恢复策略必须依赖失败状态
+
+CodeRescue 在约 2.73 万次代码任务尝试上，把失败后的选择限制为 `reflect / replan / escalate`。
+固定策略中，恢复率分别为 27.5%、45.3%、68.6%；学习到的 router 为 81.7%，且成本低于始终
+升级。其可恢复失败中，约 28% 只能由便宜策略解决，45% 只能升级解决，27% 两者都能解决。
+
+该实验仍是单次路由、代码任务和特定模型组合，不能直接当生产策略。但它支持一个一般判断：
+**失败类型、现有状态、可逆性和预算共同决定下一步，不存在统一最优恢复动作。**
+
+建议使用下面的语义，而不是一个含糊的 `retry`：
+
+| 动作 | 适用条件 | 不该使用时 |
+| --- | --- | --- |
+| retry | 超时、限流、偶发网络/工具错误，且动作幂等 | 权限、schema、语义错误或已产生副作用 |
+| repair | 错误局部、责任步骤较可信、旧状态仍有价值 | 根因未知或基础计划错误 |
+| replan | 原路径失效，但目标仍可达且可重新探索 | 已有不可逆副作用未处理 |
+| substitute | 有语义和权限兼容的替代工具/数据源 | 只因为名称相似 |
+| rollback/compensate | 先前变更可撤销或可补偿 | 没有变更账本、补偿本身风险更高 |
+| escalate/clarify | 权限、能力、意图或证据不足 | 可以由确定性局部恢复解决 |
+| abstain/stop | 不可逆风险高、预算耗尽或没有可信路径 | 仍有低风险、可验证的恢复动作 |
+
+`Don't Blindly Trust It` 进一步说明，检测器只能过滤坏反馈，无法替代 fallback：在 recoverable
+conflict 上，首步预测器 AUC 会跌到 0.516；某些 requery 策略甚至让 Llama 继续下降。
+
+## 一般结论八：恢复循环必须有停止条件
+
+“验证-修复-再验证”不是越多轮越好。
+
+- VRR-Stop 在刻意制造 verifier/repair 不匹配的 stress 条件中，固定五轮修复可把正确率从
+  0.700 降到 0.116；它的 stopping rule 恢复到 0.722。巨大差值是 stress-specific，但足以证明
+  无条件循环会主动破坏正确答案。
+- Reflexion 的 HumanEval 消融中，无测试的自我反思从 60 降到 52；测试加反思才到 68。
+- CRITIC 在数学错误上修复了 32.2% 的初始错误，同时把 14.3% 的原结果改错；外部工具反馈是
+  关键，模型自评并不可靠。
+- AgentLTL 的 soft-block 因强制终止，在 7 个模型中的 4 个表现最差。
+
+停止条件至少应考虑：
+
+```text
+new independent evidence?
+failure class changed?
+state improved without new violations?
+remaining action reversible?
+expected gain > cost/risk?
+```
+
+重复询问同一个有偏 judge 只会得到更稳定的偏差。只有新增独立证据或改变恢复策略，下一轮才有
+信息价值。
+
+## 最近半年到底进步了什么
+
+这不是一个“成功率持续上涨”的故事，而是研究对象逐步拆开了：
+
+| 阶段 | 主要问题 | 得到的东西 | 仍缺什么 |
+| --- | --- | --- | --- |
+| 2023 | 模型能否根据反馈自我修正 | Reflexion、CRITIC、自调试证明外部执行反馈有用 | 会误改正确答案；自我反馈弱 |
+| 2024 | Agent 是否真的改变了环境 | WebArena、SWE-bench、tau-bench、AppWorld、OSWorld、ToolSandbox 引入状态、轨迹和 `pass^k` | evaluator 昂贵、不完备，过程和副作用覆盖不足 |
+| 2025 | evaluator 自己是否可靠；故障后能否换路 | AgentRewardBench、SWE 测试审计、tau2、Hell or High Water、AgentDebug | judge 假阳性高；恢复与任务求解仍混在一起 |
+| 2026 | 怎样验证过程、隔离证据、路由恢复并停止 | PAE、AgentLTL、RECEIPT、ToolMaze、CodeRescue、VRR-Stop、DynamicMCPBench | 多数仍是单域 preprint；真实回滚和开放任务没有解决 |
+
+因此，和半年前相比可以说：
+
+- **测量进步明确。** false success、corrupt success、side effect、程序违规、根因定位和 recovery
+  被拆成了不同指标。
+- **局部机制有可复现方向。** 对可判定政策做前置 gate、对高风险结果做隔离重放、根据失败状态
+  路由恢复，都有直接对照支持。
+- **通用能力没有被证明。** 许多最漂亮数字来自作者自建合成故障、单模型或小任务集；到隐式
+  语义故障、真实服务漂移、开放目标和不可逆副作用时，证据仍很弱。
+
+## 我们得到的系统推论
+
+下面不是任何一篇论文已经证明的架构，而是本轮证据共同约束出的候选设计。它应被后续实现和
+反例推翻或修正。
+
+### 1. Task Contract
+
+任务开始前记录：
+
+```text
+required effects
+forbidden effects
+required procedure/evidence
+allowed tools and permissions
+budget and deadline
+reversibility / compensation plan
+observable vs unobservable clauses
+```
+
+### 2. Mutation Gate
+
+读操作默认低风险；写操作在执行前检查授权、目标对象、参数、幂等性、回滚能力和必要确认。
+门禁只覆盖机器可判定的高价值规则，不能把全部 reasoning 重写成硬编码流程。
+
+### 3. Immutable Trace and Change Ledger
+
+保存工具调用、原始返回、状态快照、变更、错误、证据版本和恢复分支。摘要不能覆盖原始轨迹。
+
+### 4. Independent Closure Check
+
+按顺序执行：
+
+1. 目标效果检查；
+2. 禁止副作用检查；
+3. 必要过程/来源检查；
+4. 对剩余语义做有证据引用的 judge；
+5. 输出 `PASS / FAIL / AMBIGUOUS / UNVERIFIABLE`。
+
+### 5. Failure Object
+
+验证失败后，不只返回一句 error，而是形成可执行对象：
+
+```text
+violated_clause
+expected_vs_observed
+last_trusted_state
+responsible_step_hypotheses + confidence
+mutation_log
+retryability
+rollback_available
+remaining_budget
+missing_evidence
+```
+
+### 6. Recovery Router
+
+根据 failure object 选择 retry、repair、replan、substitute、rollback、clarify、escalate 或 stop。
+每次恢复必须产生新证据，并重新通过独立 closure check。
+
+### 7. Completion Certificate
+
+最终结果不只是一句话，而是一个面向用户和机器的证明摘要：
+
+```text
+what changed
+which checks passed
+which evidence supports them
+what was not checked
+remaining uncertainty
+recovery history
+artifact/version identity
+```
+
+这个证书不是为了堆日志。它的作用是让“为什么相信完成”可以复核，也让下一次失败知道从哪个
+可信状态继续。
+
+## 对当前 K1412 评估工作的修正
+
+现有 `research/evaluation/` 的“独立验证、假完成、gain/regression、版本 manifest”方向与证据
+一致，但还不应直接进入 runner 实验。研究结论要求先修正任务契约的表达：
+
+1. 每个任务先写清它测的是哪一种能力，不再统称 Agent success。
+2. `outcome / invariant / procedure / semantic residual` 四层 validator 分开。
+3. validator 要记录自己的覆盖范围和已知 false-positive/false-negative。
+4. 结果状态增加 `ambiguous` 和 `unverifiable`，不逼所有任务二元判定。
+5. 故障任务分别记录 detection、localization、routing、restoration 和 re-verification。
+6. mutating task 必须有 before/after、幂等或 rollback/compensation 合同。
+7. 同一任务多次运行，报告 `pass^k`、翻转、回归和成本，不只报告均值。
+
+这些是下一步设计约束，不是已经验证过的 K1412 实现。
+
+## 仍然不知道什么
+
+1. **开放任务如何低成本写合同。** 形式化越强，编写和维护成本越高；语义越开放，judge 偏差越大。
+2. **如何覆盖未知副作用。** “没有发现违规”只对已定义的可观察状态成立。
+3. **如何判断替代路径真的语义等价。** 路径无关评分会增加召回，也可能接受不安全捷径。
+4. **如何在真实系统中回滚。** 数据库、消息、付款和外部 API 往往没有完美撤销。
+5. **如何可靠定位长轨迹根因。** 最新方法的严格 agent+step accuracy 仍低于 40%。
+6. **如何处理 verifier 分布漂移和对抗优化。** evaluator 一旦成为训练奖励，就会成为新的攻击面。
+7. **如何把用户满意与客观效果结合。** pleasantness、沟通和部分帮助很重要，但不能替代事实状态。
+8. **如何证明恢复策略跨域。** 当前结果集中在代码、客服、合成工具、Kubernetes 和安全测试。
+
+## 可反驳的预测
+
+本轮综合至少产生四个值得后续验证的预测：
+
+1. 在有副作用的 Agent 任务中，`前置 mutation gate + 事后 effect check` 会比只做最终 judge 更少
+   假完成，但 gate 过宽会增加拒绝和任务失败。
+2. 在混合故障集上，基于 failure object 的路由会优于固定 retry/replan；优势主要来自永久故障和
+   隐式语义故障，瞬时故障上简单 retry 仍是强基线。
+3. 独立 verifier 的最大收益不是平均成功率，而是降低 false success；只报成功率会低估它。
+4. 当恢复轮次不产生新独立证据时，增加轮次的边际收益会迅速归零，并开始增加回归。
+
+这些预测以后可以做实验；这轮不把尚未执行的实验写成结果。
+
+## 材料边界
+
+- 40 篇全文是问题驱动候选池，不是“全部 Agent evaluation 论文”的系统综述。
+- 37 篇进入证据账本，3 篇只作历史背景；论文下载和文本定位不等于结论可信。
+- 2026 年材料多数仍是 arXiv preprint，独立复现很少。
+- 跨 benchmark 不比较绝对分数，只使用同论文受控对照，或明确说明协议差异。
+- `Self-Healing Agentic Orchestrators` 的 98.8% 来自作者自建合成任务，真实模型部分只有
+  15 个任务且成功率饱和；本轮只采用其控制环词汇，不采用该数字支撑一般结论。
+- 更细的样本、数字和不能外推部分见 [证据账本](evidence-ledger.md)。
@@ -13,5 +13,12 @@

 ## Evidence Boundary

-当前方案的工程判断来自实际代码和文档检查。2026-07-09 至 2026-07-27 的新论文只做了
-标题和摘要级筛选，尚未构成全文证据审计。
+当前方案的工程判断来自实际代码和文档检查。后续完成了独立的 40 篇全文研究池和 37 篇
+证据审计，见 [Agent completion, verification, and recovery](../completion-verification/README.md)。
+
+该研究支持独立验证、假完成、版本 manifest、gain/regression 和重复运行的方向，也对当前
+合同提出修正：应分开 outcome、invariant、procedure 和 semantic residual，增加
+`ambiguous/unverifiable`，并把 failure detection、localization、routing、restoration 和
+re-verification 分开记录。
+
+这些是研究约束，不表示 runner、validator 或真实 benchmark 已经完成。