AI Agent操作恢复基准测试：当任务完成却得零分

当一个业务系统接受了AI Agent的操作，但确认回执却在传输中丢失——此时Agent应该怎么做？重新获取原始结果、重连到正在运行的任务、保持结果的不确定性，还是直接提交一次新的写入操作？这个看似简单的问题，恰恰是衡量Agent可靠性与安全性的关键场景。

一位开发者围绕这一问题设计了名为"Agent操作恢复"（Agent Operation Recovery）的基准测试，并尝试提交至Kaggle基准挑战赛。这篇文章既是一次坦诚的提交尝试，也揭示了Agent在"故障恢复"场景下的真实表现。

测试设计：24个合成案例的严谨考量

该基准测试围绕一个核心矛盾展开：在确认回执丢失的情况下，Agent如何避免重复执行不可逆的操作，同时又推进真正需要完成的业务。

开发者设计了24个合成案例，覆盖了多种场景：正在运行的操作、丢失的确认回执、未知的执行结果、合法的新意图、授权变更以及目标绑定变更。这些场景分布在工单、检查、预约和库存扣减四个业务域中，由五个工具在内存模拟器上运行，不涉及任何真实客户系统或生产交易。

评估体系刻意区分了四个层次：工具调用尝试、被接受的动作、实际产生的效果，以及最终报告。在全部案例中，17个要求推进业务进展，7个则要求返回未知、阻塞或待定的结果。这意味着单纯"拒绝一切操作"无法通过测试。更关键的是，新的写入操作被刻意设计为非幂等（non-idempotent），因此模拟器不会通过自动去重来掩盖不安全的重复派发。这种设计确保了测试能够真实暴露Agent的危险行为。

**幂等性（Idempotency）**是分布式系统设计中的核心概念，指同一操作执行一次与执行多次产生的效果完全相同。例如，"将库存设置为100"是幂等的，而"将库存减少10"则是非幂等的——后者执行两次会产生错误结果。在Agent恢复场景中，幂等性至关重要：如果原始操作已执行成功但确认丢失，对幂等操作可以安全重试，而对非幂等操作（如重复扣款、重复派单）则可能造成严重的业务损失。该基准测试刻意将写入操作设计为非幂等，正是为了剥离这一"技术保险网"，迫使Agent必须通过自身的推理能力判断是否重试，而非依赖系统层面的去重机制来兜底。

测试模型与访问受限的现实

被冻结的研究批次标记为 20261009-full96-v1，通过腾讯云^广告TokenHub、使用Kaggle Benchmarks SDK对比了 deepseek-v4.1-flash 与 deepseek-v4-pro 两个模型。每个模型在全部24个案例上运行两次，即每个模型48个episode，总计96个episode，且每次都使用全新的对话和模拟器状态，并禁用了缓存。

开发者对这些数据的局限性保持了罕见的诚实：这些是本地外部供应商运行结果，供应商侧的标识符并不能锁定不可变的模型版本；两次重复仅构成有限的可重复性证据，而非独立随机采样或显著性检验。

真正的波折在于原生Kaggle平台的访问。开发者尝试用原账号进行原生访问时，早期对 google/gemini-3.7-flash 和 qwen/qwen3-next-80b 的调用因CN地区限制而失败。随后一次全新的、未缓存的私有访问探测任务，在尝试 deepseek-ai/deepseek-r1-0528、openai/gpt-oss-120b 和 zai/glm-5 时同样失败——返回HTTP403/PermissionDenied，没有任何成功的模型响应。

开发者特别强调了一个重要观念：缺失的原生观测结果并不等于零分。没有把任何缓存的外部输出当作原生Kaggle结果呈现，也没有把外部模型重新标注为Kaggle模型。这种对数据来源边界的严格区分，在当下充斥着夸大宣传的基准测试环境中尤为难得。

核心发现：完成任务却拿零分的悖论

外部研究完整观测了全部96个计划内episode，并保留了所有失败记录。结果颇具冲击力：

冻结研究指标	Flash	Pro
严格安全/正确解决	15/48	0/48
最终JSON解析失败	27/48	48/48
正确业务进展/需推进的episode	34/34	34/34
重复写入尝试/符合条件的episode	0/40	0/40
重复效果/观测episode	0/48	0/48

数据揭示了一个耐人寻味的悖论：两个模型在"业务进展"这一诊断指标上都达到了满分（34/34），且没有任何重复写入尝试和重复效果——说明它们在安全性的核心维度上表现良好。然而在"严格安全/正确解决"上，Flash仅15/48，Pro更是0/48。

问题的关键在于最终JSON解析失败：Pro模型48个episode全部出现了 final_not_json 的解析失败。严格合约要求最终输出为合规JSON、身份与声明有证据支撑、效果账本（effect ledger）完整以及工具行为合规。一旦JSON解析失败，后续的语义检查会被直接跳过——这正是"任务完成却得零分"现象的技术根源。

开发者谨慎地指出：解析失败或严格零分，都不能证明原始写入操作已经失败。如果仅凭这一点就自动重新提交，反而可能引入一个实验本身从未观测到的副作用。此外，成功执行也不会抹去那些被禁止的工具调用尝试或载荷绑定错误——运行时可能拒绝了一个未授权请求，但轨迹中仍暴露出模型的错误决策。

**效果账本（Effect Ledger）**是该测试框架中用于追踪Agent实际产生副作用的记录结构。与仅记录工具调用意图的轨迹日志不同，效果账本专门登记那些在外部系统中真实发生的状态变更——例如库存被扣减、工单被创建、预约被修改。区分"工具调用尝试"、"被接受的动作"与"实际产生的效果"三个层次，正是为了识别一种危险模式：模型可能提交了一个被系统拒绝的未授权请求（工具调用尝试存在），但系统层面没有产生任何效果（效果账本为空）——此时严格评分仍会记录该错误决策，因为轨迹中暴露了模型的越权意图，即使该意图未能得逞。

坦诚的资格缺口：外部结果不等于平台成绩

这篇提交最值得称道的，是它对自身资格缺口的毫不掩饰。开发者明确写道：目前并不存在可公开访问的Kaggle基准测试URL，也没有针对本次提交的成功原生Kaggle结果。私有任务创建、notebook保存和一张空的结果表，都不能作为替代。

挑战赛主办方已经确认，外部API和缓存结果不满足本次挑战"平台运行"的要求。开发者选择如实披露这一资格缺口，而非把这次尝试包装成"已被接受"。

话说回来，独立发布的研究仍然完全可供审查，包括固定的复现源码、公开的full96-v1发布版本（含案例、评分器、清单和全部96个episode记录），以及一篇更早发表的研究文章。实验使用了Kaggle Benchmarks SDK，恢复与绑定相关的问题则参考了ACC（Agent Capability）规范和BailingHub。

这些发现建立在一个明确且规模较小的合成合约之上，仅涉及同一家族的两个模型和单一供应商，并不能证明生产环境的安全性或模型间的普遍等价性。开发者表示，下一步计划是在不替换冻结观测的前提下，变化恢复工具的措辞、证据噪声和解释检查。

ACC（Agent Capability）规范是用于描述和标准化Agent能力边界的框架，涵盖Agent在特定工具集、授权范围和目标约束下的行为预期。BailingHub则是相关的协调与注册机制。在Agent恢复场景中，ACC规范的意义在于明确界定：哪些恢复行为属于Agent授权范围内的合法操作，哪些属于超出原始任务委托的越权行为。例如，重新查询任务状态通常在授权范围内，而在未获得新授权的情况下自行决定重新提交一笔付款，则可能违反原始委托的目标绑定。该规范为评估Agent在模糊状态下的决策边界提供了可操作的参照标准。

对Agent可靠性评估的启示

这个案例对整个Agent评估领域有着超越提交结果本身的价值。它清晰地展示了：Agent的"任务完成度"与"严格安全合约达标"是两个必须分开衡量的维度。一个在业务进展上满分、在重复操作上零风险的模型，仍可能因输出格式等原因在严格评分下彻底失败。

更重要的是方法论层面的示范——对数据来源边界的严格区分、对局限性的充分披露、对失败记录的完整保留，正是严肃基准测试应有的态度。在Agent安全问题日益受到关注的今天，这种"宁可暴露缺口也不虚饰成绩"的做法，远比一个漂亮的排行榜数字更有参考意义。