当Web任务测试框架中的假设不再成立时，其评估的稳健性如何？

你的基准测试结果可能反映的是测试框架，而非模型本身

Web-agent基准测试中最大的隐含假设是，模型是性能的主要驱动因素。但一篇2026年的立场论文对长时程任务提出了相反的观点：即“框架”（harness）——负责管理上下文、工具和验证的代码——往往比它所包裹的模型更重要[5]。他们用控制理论对此进行了形式化，表明框架的作用类似于控制器，而模型则类似于其所辖的策略。在他们的受控方差分解中，框架引起的方差超过了模型引起的方差，在某些情况下，更换框架甚至逆转了哪个模型表现更优的结果[5]。因此，如果你在比较两个智能体，而它们使用了不同的框架，那么你测量的可能其实是框架，而非模型。

这不仅仅是理论。在一项2026年的研究中，一个较小的模型（Gemini-2.5-Flash）自动合成了一套代码框架，成功阻止了145种不同游戏中的所有非法操作，使其表现超越了Gemini-2.5-Pro等更大的模型[4]。类似地，一种自我改进的框架方法在单轮优化中，将软件工程基准测试的通过率从59%提升到了78%，且无需任何外部评分[2]。这些结果表明，框架的改动可以带来性能上的显著变化，其影响甚至超过直接更换模型本身——因此，如果你的基准测试没有对框架进行控制，那么你关于模型质量的结论就站不住脚。

当评估框架的假设失效时会发生什么？攻击与失败

Web-agent的防护框架同样对安全性和可靠性做出了假设，而这些假设在实际应用中可能失效。一项2026年的基准测试HarnessRisk对六种语言模型上的三种防护框架进行了测试，发现攻击成功率介于12.6%至80.9%之间——这意味着在最坏情况下，嵌入工作流程中的对抗性指令每五条就有四条能够成功[1]。最脆弱的环节是防护框架的配置阶段，攻击者在此处篡改了本已授权工作流程中的安全敏感参数[1]。更令人担忧的是，研究发现检测到风险并不总能可靠地转化为安全行动：某些配置在超过90%的运行中能检测到风险，但攻击成功率仍然相当高[1]。因此，认为防护框架必然能捕获并阻止攻击的假设并不总是成立。

另一个假设是，测试平台的运行机制是静态的且已被充分理解。但平台本身会不断演化，而这种演化可能引入新的故障模式。一项2026年关于自我改进型测试平台的研究发现，在过去的运行轨迹上优化平台，能在九个模型-基准组合中将留出任务上的性能提升高达132%[3]。然而，该研究同时指出，保留下来的机制主要针对基准测试特有的瓶颈，这意味着平台可能过度拟合基准测试的某些特性[3]。这是一把双刃剑：平台优化可以提升分数，但也可能使评估结果对真实世界任务的代表性下降。关键在于，关于测试平台的假设——涉及安全性、稳定性和泛化能力——往往会被打破，而忽视这一点的评估是不完整的。

比较智能体时该怎么做？要求公开测试框架（harness）信息

鉴于测试框架可能主导性能表现，实际建议很明确：不要相信未披露测试框架的排行榜对比。2026年立场文件提出了一项披露标准和方差分解协议，并指出在测试框架规格公开之前，针对长周期智能体的排行榜对比应被视为不完整且可能具有误导性[5]。这是对基准创建者和使用者共同发出的行动呼吁。

对于你自己的评估，证据表明你应当要么统一所有模型上的测试框架，要么明确衡量其贡献。HarnessRisk研究表明，安全结果会随测试框架配置的不同而出现巨大差异，因此你需要测试多种配置才能获得全貌[1]。而自我改进研究[2][3]则表明，测试框架优化可以成为强大的工具，但这也意味着你的基准测试结果具有时效性——今天表现良好的框架，明天可能就不适用了。简而言之，应将网络代理基准测试结果视为依赖于测试框架的，并始终追问：“使用的是哪种测试框架？”

关于这些资料来源

WisPaper

原文