agent/research/completion-verification/findings.md

# 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)。