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
@@ -40,6 +40,11 @@ This is not merely a paper browser. The user wants a scaffold that turns a large

 The current Atlas is a corpus exploration prototype, not a validated solution to this goal. The user rated its practical learning value at effectively zero because browsing left no durable learning state. Do not spend the next iteration polishing the graph without addressing this gap.

+The current immediate research question is Agent completion, verification, and recovery. Read
+`research/completion-verification/findings.md` and `evidence-ledger.md` before extending the Agent
+evaluation work. Experiments and web redesign are intentionally paused until the user challenges and
+accepts or revises those conclusions.
+
 ## Truth Hierarchy

 Treat repository artifacts according to their evidence level:
@@ -56,6 +61,9 @@ The Agent evaluation design under `research/evaluation/` is an implementation co
 benchmark. Its task contracts explicitly mark which runners do not exist yet.
 `evaluation-site/` is a presentation layer for that contract. It must not introduce stronger claims than
 the research artifact or display simulation values as real benchmark results.
+The completion-certificate, failure-object, and recovery-router design in
+`research/completion-verification/findings.md` is a cross-paper inference, not a validated implementation.
+The existing evaluation contract must be revised against that research before runner work resumes.

 ## Repository Contracts

@@ -17,7 +17,9 @@
 `queued`，还没有完成“原始论文 -> 可比较知识单元 -> 领域结构 -> 个人判断”的知识漏斗。
 旧的 12 篇 Agent Memory 学习模块已判定失败；当前证据基线是
 [Memory findings](research/memory/findings.md) 和
-[evidence ledger](research/memory/evidence-ledger.md)。
+[evidence ledger](research/memory/evidence-ledger.md)。关于 Agent 到底如何证明任务完成、
+evaluator 如何误判以及失败后如何恢复，当前基线是
+[Agent completion, verification, and recovery](research/completion-verification/README.md)。

 ## Navigation

@@ -34,6 +36,8 @@
 - [Jobs](jobs/README.md): 北京大厂 Agent / LLM 相关岗位要求
 - [Papers](papers/README.md): Agent 相关论文、阅读队列和研究洞察
 - [Research](research/README.md): 跨论文时间对照、受控证据和领域判断
+- [Agent Completion Research](research/completion-verification/README.md): 37 篇全文证据下的
+  完成合同、验证器边界、失败定位、恢复路由和停止条件
 - [Agent Evaluation v1](research/evaluation/k1412-agent-evaluation-v1.md): 面向
  `zk-data-agent` 的任务契约、独立判分、版本对照和发布门禁
 - [Agent Evaluation Report](https://agent-eval.k1412.top/): 中文交互式结论页、发布决策演算器、
@@ -1,7 +1,7 @@
 # Project Status

 last_reviewed: 2026-07-27
-baseline_before_update: `8e4ff37`
+baseline_before_update: `5373d56`
 branch: `main`
 remote: `https://git.k1412.top/wuyang/agent.git`

@@ -47,6 +47,21 @@ The memory research snapshot contains:

 The strongest current conclusion is that recent progress is concentrated in better diagnosis/evaluation and task-specific execution-state memory, not a universal memory architecture. Read `research/memory/findings.md` before making memory design claims.

+The Agent completion/verification research snapshot contains:
+
+| Stage | Count |
+| --- | ---: |
+| full-text problem-driven pool | 40 |
+| papers promoted into the evidence ledger | 37 |
+| historical context only | 3 |
+
+Its strongest conclusion is that Agent completion is an evidence contract over intended effects,
+forbidden effects, required procedure, and remaining uncertainty. State checks, trace rules, learned
+judges, and humans have different jobs; none is a universal oracle. Verification and recovery are
+separate capabilities, and recovery must distinguish detection, localization, routing, restoration,
+and re-verification. Read `research/completion-verification/findings.md` before extending the Agent
+evaluation contract.
+
 ## Artifact Map

 | Area | Source of truth | What it contains |
@@ -62,13 +77,13 @@ The strongest current conclusion is that recent progress is concentrated in bett
 | industry | `industry/` | official reports, blogs, products, benchmarks |
 | collection runs | `collection-runs/` | queries, scope, counts, method notes |
 | collection tools | `tools/collection/` | item creation, arXiv collection, promotion, indexing, URL checks |
-| research | `research/memory/` | field findings and evidence ledger |
+| research | `research/memory/`, `research/completion-verification/` | field findings and evidence ledgers |
 | Agent evaluation | `research/evaluation/` | executable design contract for task suites, validators, paired comparisons, and release gates |
 | evaluation data/tools | `data/evaluation/`, `tools/evaluation/` | versioned task contracts and JSONL result scorer |
 | evaluation report | `evaluation-site/` | Chinese interactive explanation of the contract, decision gates, tasks, and artifacts |
 | research data | `data/research/` | committed corpus, screening, landscape and CSV ledger |
 | research tools | `tools/research/` | paginated search, abstract fetch, screening, classification, landscape build |
-| experiments | `experiments/knowledge-compilation/` | failed pilot and completed field audit |
+| experiments | `experiments/knowledge-compilation/` | failed pilot and completed full-text research audits |
 | learning prototype | `learning/agent-memory/` | preserved failed 12-paper learning module |
 | web application | `web/` | Atlas, search agent, paper reader/chat, Ollama actions |
 | project integrity | `tools/check_project.py` | offline structural and data checks |
@@ -99,6 +114,20 @@ paginated arXiv queries + local memory-tagged papers

 Do not merge these two lines silently. The first is a broad browsing corpus; the second is an evidence audit with explicit boundaries.

+The Agent completion audit follows the same evidence discipline without a model-assisted screening
+stage:
+
+```text
+problem-driven arXiv candidates
+  -> 40 downloaded and text-located full papers
+  -> 37 audited experiment/ablation/limitation records
+  -> research/completion-verification/evidence-ledger.md
+  -> research/completion-verification/findings.md
+```
+
+The PDF and extracted-text working set was temporary. The committed evidence ledger preserves source
+IDs, key numbers, claim boundaries, and exclusions so another researcher can refetch the sources.
+
 The Agent evaluation design follows a third line:

 ```text
@@ -111,7 +140,10 @@ zk-data-agent runtime/events + Zero decision-loop constraints
 ```

 Only the task contracts and scorer exist in this repository. The reusable runner, fixtures, validators,
-and real-model comparison still need to be implemented in `zk-data-agent`.
+and real-model comparison still need to be implemented in `zk-data-agent`. That implementation is
+intentionally paused while the research findings are reviewed. Before implementation, task contracts
+need separate outcome/invariant/procedure/semantic-residual layers, non-binary
+`ambiguous/unverifiable` states, and explicit recovery-stage fields.

 `evaluation-site/` visualizes this contract but does not add evidence. Its adjustable decision values are
 explicitly labeled as a method simulation, not a real benchmark.
@@ -260,3 +260,41 @@ The report was deployed as immutable image
 `docker.k1412.top/wuyang/agent-eval:20260727T084425Z-cd1eacb` through Unraid Compose Manager on NAS port
 12005. NPM route and Let's Encrypt HTTPS were enabled for `https://agent-eval.k1412.top/`, and the site
 was registered in the k1412 homepage `projects` category.
+
+## 13. Stop Implementing, Research Completion First
+
+After reviewing the evaluation report, the user rejected the work as useful research. The failure was
+not that the site lacked another chart. The design had moved from code inspection to task contracts,
+scoring, and presentation without first establishing what current Agent research can actually prove
+about completion and recovery.
+
+The user explicitly paused experiments and requested general conclusions before any new web form.
+The project therefore audited a problem-driven 40-paper full-text pool spanning false success, state
+and procedure verification, evaluator validity, test adequacy, tool failure, root-cause attribution,
+recovery routing, and stopping. Thirty-seven papers entered an evidence ledger; three remained
+historical context.
+
+The main corrections are:
+
+- task completion is an evidence contract, not an Agent statement or one benchmark bit;
+- concrete capabilities include state change, side-effect control, procedure compliance, coordination,
+  failure detection, localization, recovery routing, restoration, re-verification, and repeated
+  reliability;
+- deterministic state checks, trace rules, learned judges, and humans have different responsibilities;
+- verification only creates an explicit failure; it does not provide diagnosis or recovery;
+- fixed retry, reflection, replanning, and repair loops all have documented regressions;
+- the benchmark protocol and verifier must themselves be audited for weak tests, leakage, drift,
+  model changes, and reward hacking.
+
+The cross-paper synthesis proposes a completion certificate, structured failure object, and
+state-dependent recovery router. These are marked as system inferences, not experimental results.
+
+Decision retained: do not implement the Agent evaluation runner or redesign its report until the user
+accepts the research decomposition. If implementation resumes, rewrite the task contracts around
+outcome, invariant, procedure, semantic residual, uncertainty, and explicit recovery stages.
+
+Current source of truth:
+
+- `research/completion-verification/findings.md`
+- `research/completion-verification/evidence-ledger.md`
+- `experiments/knowledge-compilation/2026-07-27-agent-completion-research-audit.md`
@@ -2,7 +2,29 @@

 last_reviewed: 2026-07-27

-## P0: Prove the Paper Compiler
+## P0: Challenge the Completion Research
+
+The immediate work is not an Agent experiment and not a new evaluation page. Review
+`research/completion-verification/findings.md` with the user and determine whether its problem
+decomposition is actually useful.
+
+The review should test whether the research can answer, without falling back to paper titles:
+
+1. what concrete capabilities an Agent evaluation is measuring;
+2. what evidence is sufficient to claim completion in different task types;
+3. where deterministic checks, trace rules, learned judges, and humans fail;
+4. why failure detection, diagnosis, routing, restoration, and re-verification differ;
+5. what has genuinely improved since reflection/state-only evaluation, and what remains unsolved.
+
+For every challenged conclusion, return to the full-text evidence ledger, add a counterexample or
+narrow the scope. Do not defend the synthesis by adding prose. The acceptance condition is that the
+user can use the model to diagnose an unfamiliar Agent design and identify what its claimed result
+does not prove.
+
+Only after this review should the candidate completion certificate, failure object, and recovery router
+be translated into task contracts. They are currently system inferences, not validated implementations.
+
+## P1: Prove the Paper Compiler

 The main project goal is now a high-efficiency knowledge funnel, not a paper browser and not a fixed
 course. It should let one person process a corpus on the scale of 1,000 papers while retaining the
@@ -95,12 +117,20 @@ The first vertical slice is successful only if:

 The frontend is optional. JSON/Markdown plus a rigorous review session is enough for the first proof.

-## P1: Implement the Agent Evaluation Runner
+## P2: Implement the Agent Evaluation Runner

-The design contract is complete at
+The first design contract exists at
 `research/evaluation/k1412-agent-evaluation-v1.md`. Implementation belongs in
 `https://git.k1412.top/wuyang/zk-data-agent.git`.

+Implementation is paused. Before resuming, revise the contract using the completion research:
+
+- separate outcome, forbidden-effect invariant, required procedure, and semantic residual;
+- add `ambiguous` and `unverifiable` result states;
+- model mutating actions, idempotency, rollback and compensation;
+- record detection, localization, routing, restoration and re-verification separately;
+- document validator coverage and known false-positive/false-negative boundaries.
+
 Implement in this order:

 1. extract a reusable runner from `scripts/eval-live-work.py`;
@@ -131,7 +161,7 @@ The report at `https://agent-eval.k1412.top/` explains the contract and simulate
 It is not evidence that any Agent variant passed. Future result views must consume the same validator
 JSONL instead of embedding numbers in frontend code.

-## P1: Continue Collection Through Questions
+## P2: Continue Collection Through Questions

 The corpus now contains 1,125 papers, 1,110 of them queued. More collection is useful only when paired
 with processing:
@@ -163,6 +193,11 @@ workflow:
 Avoid another graph or dashboard redesign until either the paper compiler or evaluation runner produces
 something the user repeatedly uses.

+For the completion research, a later web presentation should begin with a concrete claim or failure,
+then progressively reveal the completion contract, evidence, conflicting evaluator results, recovery
+branches and source papers. It should not lead with a benchmark hierarchy, architecture diagram,
+leaderboard or aggregate score.
+
 ## P2: Operations

 Still missing:
@@ -187,16 +222,16 @@ Still missing:

 For the knowledge-base repository:

-1. choose one bounded topic and enumerate the complete relevant corpus;
-2. define the fingerprint schema and evidence locators;
-3. compile and audit a representative batch;
-4. test whether research-move compression preserves important distinctions;
-5. run the result with the user before building UI.
+1. read `research/completion-verification/findings.md` with the user;
+2. collect objections, ambiguous terms and missing counterexamples;
+3. tighten or reject conclusions against the evidence ledger;
+4. only then convert the accepted model into a minimal task-contract schema;
+5. design the progressive web presentation after the knowledge shape is stable.

 For `zk-data-agent`:

-1. port the two currently runnable task contracts;
-2. extract the live runner and add one deterministic validator;
-3. export valid result JSONL;
-4. run a smoke comparison only after deterministic layers pass;
-5. record the decision and failures, not just the score.
+1. do not port or run tasks yet;
+2. wait for the completion-research review;
+3. revise the v1 contract before extracting a runner;
+4. retain the existing code inspection and scorer as historical implementation inputs;
+5. never present the current evaluation report as benchmark evidence.
@@ -8,6 +8,7 @@
 | --- | --- | --- | --- | --- |
 | KC-001 | 12 篇主题卷宗足以形成 Agent Memory 领域认知 | failed | 样本和归因不足，输出像讲课，用户认知没有提高 | [记录](knowledge-compilation/2026-07-10-agent-memory-pilot.md) |
 | KC-002 | 分页语料、受控对比和证据账本能支持领域进展判断 | completed | 建立 516 篇候选、32 篇全文池和 23 篇证据账本，得到可审计结论 | [记录](knowledge-compilation/2026-07-10-agent-memory-field-audit.md) |
+| KC-003 | 实现 Agent 评测前，先用全文证据明确“完成、验证、恢复”分别是什么 | completed | 建立 40 篇全文池、37 篇证据账本和八条一般结论；暂停 runner 与网页工作等待用户质疑 | [记录](knowledge-compilation/2026-07-27-agent-completion-research-audit.md) |
 | OPS-001 | 完整仓库交接可以让无会话上下文的 AI 继续工作 | completed | 增加状态、历史、下一步、完整性检查、模型校验和 systemd 服务管理 | [记录](operations/2026-07-12-project-handoff-audit.md) |
 | EVAL-001 | 现有运行事件和隔离工作区可扩展为可决策的 Agent 评测体系 | completed | 形成任务契约、分层评测、独立判分、gain/regression 对照和评分器；尚未运行真实模型 | [记录](agent-evaluation/2026-07-27-k1412-agent-evaluation-design.md) |
 | OPS-002 | 评估结论可以用交互报告展示而不伪装成真实跑分 | completed | 中文报告、决策演算器、任务筛选、响应式和镜像验证通过，已部署 HTTPS 并注册首页 | [记录](operations/2026-07-27-agent-eval-site.md) |
@@ -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. 最后让网页呈现证据、争议和失败分支，而不是展示一个总分。
@@ -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 已经完成。