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%。

能推出什么

完成声明至少需要三类合同：

positive effects: 必须发生什么
negative invariants: 什么不能发生
procedure/evidence: 哪些确认、授权、来源或验证不能省略

如果任务目标本身含糊，或者关键效果在系统外不可观察，就不能可靠输出 PASS。合理状态应包含 AMBIGUOUS 和 UNVERIFIABLE，而不是逼 judge 猜一个二元答案。

不能推出什么

这不意味着每个任务都要写成完整形式化证明。它意味着系统只能在证据覆盖范围内声称完成； 开放任务可以使用人工、语义 judge 和抽样检查，但必须保留其误差和未覆盖部分。

一般结论二：评估对象是整个运行协议，不只是模型

同一个模型换工具 schema、用户模拟器、服务商、时间预算、测试集或 Agent loop，结果都会变。 因此一个 Agent 分数实际衡量的是：

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 表示 禁止事件。

但路径并非永远无关。授权、用户确认、来源读取和不可逆操作属于完成合同的一部分。正确区分是：

implementation path: 原则上允许等价
causal/procedural obligation: 若任务要求，则必须证明

一般结论六：验证失败不等于会恢复

恢复至少要经过五个不同阶段：

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 个表现最差。

停止条件至少应考虑：

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

任务开始前记录：

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，而是形成可执行对象：

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

最终结果不只是一句话，而是一个面向用户和机器的证明摘要：

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 个任务且成功率饱和；本轮只采用其控制环词汇，不采用该数字支撑一般结论。
• 更细的样本、数字和不能外推部分见 证据账本。