跳到正文

FULL-TEXT RESEARCH AUDIT · 2026.07.27

# Agent 到底凭什么说
“完成了”

完成不是 Agent 的一句话，也不是 benchmark 里的一个绿色勾。 它是关于外部世界的证据合同：目标效果发生了、禁止效果没有发生、 必要过程没有被绕过，证明不到的部分仍被诚实保留。

先读八条结论 直接核查证据
一条可信的完成声明 Completion claim
01
目标效果 required effects
已观察
02
禁止副作用 forbidden effects
未发现
03
必要过程 procedure / evidence
可追溯
04
剩余未知 residual uncertainty
已声明

缺少任意一层，都只能说“部分可证”，不能用自信语气补齐。

全文池
  40
问题驱动，不是标题投票
证据账本
  37
核过结果、消融或限制
核心证据
  26
直接承担一般结论
自有跑分
  0
本页是研究，不是 benchmark

01 · 先读结论

## 八条可以带走的判断

先建立判断框架，再进入论文、数字和例外。

1. 01 完成是外部证据，不是最终文本 Agent 自述、测试通过和状态成功都只覆盖一部分。
2. 02 Agent 能力不能压成一个总分 结果、过程、协作、恢复和可靠性是不同能力。
3. 03 不存在一个通用 verifier 规则、轨迹 judge、模型 judge 和人各有盲区。
4. 04 行动者不能批准自己 独立环境、权限和重放证据比更多 reasoning 更关键。
5. 05 验证效果，不要写死实现路径 等价路径应被允许，必要程序仍必须被证明。
6. 06 验证失败不等于会恢复 发现、定位、选路、恢复和复验会分别失败。
7. 07 没有固定的恢复阶梯 重试、修复、重规划、回滚和升级依赖当前状态。
8. 08 更多轮次可能主动破坏结果 没有新证据的 verify-repair loop 只会稳定偏差。

02 · 能力拆解

## 大家究竟在评价 Agent 的什么

“题有没有做完”只是结果位。真正可诊断的评估，需要知道哪一段能力发生了变化。

A / INTENT

### 理解与约束

- 目标理解做的是用户真正要的事吗
- 限制识别权限、范围、预算是否被保留
- 必要澄清意图不完整时是否停止猜测

B / ACTION

### 执行与环境

- 路径选择计划是否可达、代价是否合理
- 工具契约工具、参数、顺序是否正确
- 状态改变外部世界是否真的发生变化

C / CONTROL

### 过程与副作用

- 副作用控制是否只改变允许的对象
- 程序合规确认、授权、读取是否被绕过
- 协作能力能否指导用户或其他 Agent

D / RECOVERY

### 失败与恢复

- 失败检测是否知道当前结果不可信
- 根因定位哪一步让任务注定失败
- 恢复执行新动作是否真的恢复目标状态

E / TRUST

### 收尾与可靠性

- 诚实收尾最终声明是否与证据一致
- 重复可靠多次运行是否仍然成立
- 效率边界用了多少时间、调用和权限

> 更严格的问题

> 在任务、环境、工具、权限和预算固定时，这个系统在哪一种能力上比基线更好； 它带来了哪些收益、回归和新的不可判定项？

03 · 研究模型

## 完成证明与失败恢复，是两条相连但不同的链

验证器负责拒绝没有证据的成功；恢复系统负责决定拒绝之后怎样继续。

A · CLOSURE / 完成证明

1. 01
   Effect 目标效果是否发生
2. 02
   Invariant 禁止副作用是否出现
3. 03
   Procedure 必要过程是否合规
4. 04
   Residual 剩余语义与未知是否声明

结果状态 PASS · FAIL · AMBIGUOUS · UNVERIFIABLE
B · RECOVERY / 失败恢复

1. 01
   Detect 发现当前结果不可信
2. 02
   Localize 定位责任步骤和最后可信状态
3. 03
   Route 选择重试、修复、重规划或升级
4. 04
   Restore 执行恢复并处理已有副作用
5. 05
   Re-verify 从独立状态重新证明

关键边界 检出失败，只是把“假成功”变成“明确失败”
确定性状态检查

负责机器可观察的效果和禁止副作用。精确、可复现，但合同昂贵且覆盖有限。

轨迹与程序规则

负责确认、授权、顺序和禁止动作。能看过程，但过严时会拒绝合法路径。

LLM / Agent judge

负责剩余语义、等价路径和部分进展。适合辅助判断，不适合独立发布认证。

人工复核

负责高风险、冲突、不可观察和价值判断。不是无限资源，应由明确异常触发。

04 · 逐条论证

## 结论为什么成立，又在哪里停止

每一条都同时保留直接证据和不能外推的边界。

01

COMPLETION

### 完成是证据合同，不是最终文本

Agent 的语言只能报告完成，不能构成完成。可相信的对象是外部状态、禁止副作用、 必要过程和仍未被观察的部分。

45% / 48%tau2 airline / retail 失败轨迹中的假完成
75.8%AppWorld 明确声称完成的失败轨迹子集
7.8%已通过 SWE-bench 的补丁被额外开发者测试直接判错
证据与边界

tau-bench、AppWorld 和 OSWorld 把完成落到数据库、文件或桌面状态； AppWorld 还检查允许集合之外是否出现额外变化。Procedure-Aware Evaluation 又证明，状态成功仍可能绕过必要确认和策略。

这些比例来自不同子集，不能直接互比。结论不是“形式化一切”，而是系统只能在 证据覆盖范围内声称完成；开放任务需要保留 `AMBIGUOUS` 和 `UNVERIFIABLE`。

02

PROTOCOL

### 评估对象是整个运行协议，不只是模型

一个 Agent 分数实际衡量的是模型、prompt、orchestrator、工具、环境、用户模拟器、 verifier、预算和版本的乘积。

    model × prompt × orchestrator × tools × environment
    × user/simulator × verifier × budget × version

证据与边界

DynamicMCPBench 的 126 次 live 重放中，只有 36% 返回完全相同，33% 漂移， 32% 已损坏。AgentLens 的 provider 工具参数解析故障，也会被误读成模型能力差。

因此每个结果都要携带模型版本、prompt、工具、环境快照、validator、预算和种子。 没有 manifest，跨版本分数没有稳定含义。

03

VERIFIER

### 不存在一个通用 verifier

规则判分更容易漏报，模型 judge 更容易误报。可靠方案不是让两者投票， 而是让它们承担不同责任。

官方规则 evaluator 83.8% precision 55.9% recall
最佳 LLM judge < 70% precision 更高 recall
证据与边界

AgentRewardBench 给出了 precision/recall 对照；AJ-Bench 中让 judge 使用工具 虽然明显改善判断，不同任务域 false-positive rate 仍为 8.77%-56.60%。 AgentLens 的两个 judge 在 23% 比较上选择不同赢家。

LLM judge 可以处理规则未覆盖的语义等价，也可以提出异常；它不应单独把一个 确定性失败降级为成功。

04

INDEPENDENCE

### verifier 必须与 actor 分权

同一个 Agent 同时行动、解释和批准自己，会形成最危险的确认偏差闭环。 verifier 应拥有 actor 无法伪造的状态、权限和重放环境。

同模型自评 10 / 27 真实 XSS 报告
→
隔离重放 + 角色分离 30 / 30 作者报告真阳性
证据与边界

RECEIPT 的消融说明，关键变化来自浏览器判决、隔离、可重放 PoC 和角色分离， 不是让 judge 再思考一轮。

这是单模型、白盒 XSS 和特定 harness 的结果，不能当通用精度保证；它支持的是 分权原则，而不是那组绝对分数。

05

EQUIVALENCE

### 验证效果，不要要求复制 gold path

实现路径原则上可以等价；授权、确认、来源和不可逆操作如果属于任务义务， 则必须被证明。两者不能混为一谈。

可以变化 implementation path 工具选择、步骤拆分、等价实现
不能绕过 causal / procedural obligation 授权、确认、来源、不可逆动作
证据与边界

AppWorld 用状态测试允许多个合法实现；DynamicMCPBench 采用 path-agnostic effect scoring，并发现 reference answer 完全正确的比例只有 79%。 ToolSandbox 则用 milestone DAG 与 minefield 同时保留弹性和禁止动作。

06

RECOVERY

### 验证失败不等于会恢复

发现错误、定位原因、选择响应、执行恢复、再次证明，是五个不同的能力。 只展示最终分数，会隐藏增益究竟来自诊断、更多尝试还是更强 fallback。

17.58%ToolMaze 隐式永久故障的平均恢复率，即使提供 hint
28.8%AgentDebugX 严格 agent + exact-step 根因定位
13 / 73 定位后在 GAIA 失败集上的一次重跑恢复
证据与边界

Hell or High Water 保证存在短替代路径，模型仍下降约 22-30 个成功率点。 R2Act 中根因服务定位可达 91.4%-99.7%，恢复动作有效率却只有 36.8%-60.3%。

AgentDebugX 的 GAIA 对照比较的是完整 recipe，且可见参考答案，不能把全部增益 归因于定位方法。

07

ROUTING

### 恢复策略必须依赖失败状态

重试适合瞬时且幂等的错误；局部修复适合已定位错误；重规划适合路径失效； 回滚处理已有副作用；升级和停止处理权限、能力与不可逆风险。

retry 超时、限流、偶发工具错误动作必须幂等
repair 错误局部且责任步骤可信保留仍有价值的状态
replan 原路径失效但目标仍可达先处理已有副作用
rollback 变更可撤销或补偿依赖完整变更账本
escalate 权限、能力、意图或证据不足交给人或更强系统
stop 风险不可逆、预算耗尽诚实保留未完成
证据与边界

CodeRescue 的固定 reflect / replan / escalate 恢复率分别为 27.5% / 45.3% / 68.6%，学习 router 为 81.7%。可恢复失败中， 28% 只能由便宜策略解决，45% 只能升级解决，27% 两者均可。

这是代码任务、特定模型和单次路由结果；它支持“策略依赖状态”， 不证明该 router 可以直接进入生产。

08

STOPPING

### 没有新证据的恢复循环会开始破坏结果

重复询问同一个有偏 judge，只会得到更稳定的偏差。只有新增独立证据或改变恢复策略， 下一轮才有信息价值。

初始正确率 0.700 stress 设置
→
固定五轮修复 0.116 正确计划被反复改坏
→
带停止规则 0.722 在该 stress 条件下
证据与边界

VRR-Stop 的巨大差值来自刻意制造的 verifier/repair mismatch，不能解释成一般收益。 但 Reflexion、CRITIC 和 AgentLTL 也分别观察到无测试反思、错误修改和强制终止回归。

停止条件至少要问：有没有新独立证据、失败类型是否变化、状态是否改善、 下一步是否可逆、预期收益是否仍大于成本和风险。

05 · 发展脉络

## 最近的进步，主要是把失败说清楚

这不是一条成功率持续上涨的曲线，而是研究对象逐步被拆开。

2023

### 让模型根据反馈自我修正

Reflexion、CRITIC、自调试证明外部执行反馈有用。

仍会误改正确答案，自我反馈很弱。
2024

### 检查 Agent 是否真的改变环境

WebArena、SWE-bench、tau-bench、AppWorld、OSWorld 引入状态、轨迹与 `pass^k`。

evaluator 昂贵、不完备，过程和副作用覆盖不足。
2025

### 开始审计 evaluator 和故障恢复

AgentRewardBench、SWE 测试审计、tau2、AgentDebug、替代路径 benchmark。

judge 假阳性高，恢复仍与一般求解能力混在一起。
2026

### 验证过程、隔离证据、路由并停止

PAE、AgentLTL、RECEIPT、ToolMaze、CodeRescue、VRR-Stop、DynamicMCPBench。

多数仍是单域 preprint，真实回滚和开放任务没有解决。
已经进步 测量与分解

假完成、程序违规、副作用、根因定位、恢复路由和停止条件开始被单独测量。

局部有效 可判定门禁与独立重放

对高价值规则做前置 gate，对高风险结果做隔离重放，有直接对照支持。

尚未证明 通用可靠 Agent

隐式语义故障、开放目标、真实服务漂移和不可逆副作用仍缺强证据。

06 · 系统推论

## 证据共同约束出的候选系统

这是跨论文综合出的推论，不是任何一篇论文已经证明的架构，也不是本项目已完成的实现。

1. 01
   Task Contract

   效果、禁止项、必要过程、权限、预算、可逆性与可观察边界。

2. 02
   Mutation Gate

   写操作执行前检查授权、对象、参数、幂等、回滚和确认。

3. 03
   Trace + Change Ledger

   保存原始返回、状态快照、变更、错误、证据版本和恢复分支。

4. 04
   Independent Closure

   效果、禁止副作用、程序和剩余语义依次判断。

5. 05
   Failure Object

   违反条款、期望与观察、最后可信状态、变更、重试性和缺失证据。

6. 06
   Recovery Router

   选择 retry、repair、replan、rollback、clarify、escalate 或 stop。

7. 07
   Completion Certificate

   说明改变了什么、通过哪些检查、什么未检查、还剩什么不确定。

COMPLETION CERTIFICATE / 示例结构 PARTIALLY VERIFIED

Observed change
  目标状态已由独立读取确认
Passed checks
  效果 4/4 · 禁止副作用 3/3 · 程序 2/2
Not checked
  外部第三方系统的最终同步状态
Residual risk
  结果可能在服务刷新后漂移
Recovery history
  1 次瞬时工具重试，无写入回滚

07 · 证据账本

## 37 篇全文，按支持范围而不是标题排列

每条记录同时保留直接数字、能支持的判断和不能外推的部分。 `context` 只作历史背景。

搜索证据
级别
主题

载入证据账本…

没有符合当前条件的证据。

08 · 未知与预测

## 研究结束在这里，不用架构图填补空白

下面的问题仍没有被解决；四条预测以后可以被实验反驳。

### 仍然不知道

1. 01

   开放任务如何低成本写合同，而不把维护成本推给人。

2. 02

   怎样发现合同中没有预先列出的未知副作用。

3. 03

   怎样判断替代路径真的语义等价，而不是不安全捷径。

4. 04

   数据库、消息、付款和外部 API 如何真实回滚或补偿。

5. 05

   长轨迹根因如何可靠定位，最新严格准确率仍低于 40%。

6. 06

   verifier 在分布漂移和被优化攻击后怎样保持可信。

7. 07

   用户满意、部分帮助与客观效果如何放在同一合同里。

8. 08

   恢复策略能否跨代码、客服、安全、桌面和真实业务泛化。

### 可反驳的预测

1. P1

   mutation gate + effect check 会减少假完成，但过宽 gate 会增加拒绝。

2. P2

   基于 failure object 的路由会在永久故障和隐式语义故障上优于固定 retry/replan。

3. P3

   独立 verifier 的最大收益会体现在 false-success 下降，而不一定是平均成功率上升。

4. P4

   当恢复轮次不产生新独立证据时，边际收益会迅速归零并开始制造回归。