ComponentBench：97种UI组件全面诊断，GPT-5 mini成功率骤降34%！
ComponentBench: Diagnosing Component-Level Failures in Computer-Use Agents
随着 OpenAI Operator 和 Anthropic 计算机使用（Computer Use）API 的相继发布，能够直接操作网页和软件的计算机智能体（Computer-Use Agents）正迅速从实验室原型走向大规模商用。然而，当前业界对这些智能体的评估陷入了两个极端的泥潭：要么是像 WebArena 那样极其宏大的长周期工作流测试，要么是像 ScreenSpot 那样极其微观的原子级 GUI 定位测试。这导致了一个致命的盲区——当智能体在一个长流程中失败时，研究人员根本无法判断是因为规划能力不足，还是仅仅因为未能正确点击一个下拉菜单。
ArXiv URL：https://arxiv.org/abs/2608.18307v1
为了填补这一“缺失的中间层”，Amazon 与杜克大学的研究团队联合推出了 ComponentBench，这是一个专门针对现代 Web UI 中组件级交互进行诊断的评估基准与测试管道。该基准围绕 97 种典型的 UI 组件，构建了 2910 个经过代码验证的交互任务，并配备了经过清洗的人类参考轨迹。
这篇论文最值得记住的结论在于，它彻底打破了“大模型能力决定一切”的错觉：实验证明，对于同一个大模型而言，仅仅改变智能体的观察和动作空间（例如从可访问性树切换到纯像素控制），就能让 GPT-5 mini 的任务成功率暴跌超过 34%。此外，尽管顶尖模型在最终成功率上表现不俗，但即使是最快的配置，其耗时也达到了人类参考轨迹的 3.7 倍；而诸如拖拽滑块、调整窗口分割线等对人类来说只需一两秒的空间操作，依然是当前所有视觉大模型难以跨越的鸿沟。
缺失的中间层：为什么组件级评估至关重要？
在探讨 ComponentBench 的机制之前，有必要理清当前智能体评估框架的痛点。现代基于屏幕截图操作的智能体面临的核心问题，已经不再是“它能否偶尔完成一次网页操作”，而是“在真实的部署环境中，究竟是哪些渲染出的 UI 组件阻碍了它的可靠性与效率”。
当前的长周期基准测试（如 VisualWebArena 或 OSWorld）确实能够衡量端到端的真实任务能力。但这种宏观视角的代价是“错误归因”变得极其困难。如果一个智能体未能完成预订机票的复杂流程，开发者无法确定根本原因。因为现代 Web 软件本质上是由生产级 UI 库（如 React、Vue 的各类生态组件）批量构建的重复组件基元。一个长流程的失败，很可能只是因为智能体无法正确处理一个日期选择器、一个多选框或者一个拖拽目标。
作者在论文中提出了一个非常现实的近似计算：如果一个长周期任务包含 5 个关键的组件交互，而智能体对每个组件的处理可靠性为 80%，那么该任务端到端的成功率天花板就只有区区 33%。此外，仅看最终是否成功是远远不够的。在全视觉智能体的实际部署中，由于每一步都需要调用昂贵的多模态大模型，任何多余的操作步骤都意味着更高的延迟、更高的 Token 成本以及更大的状态偏移风险。
为了彻底摸清智能体在这些关键节点上的真实表现，ComponentBench 应运而生。它不是对完整网站的粗略扫描，而是对构成网站的基础砖块进行高强度的“破坏性测试”。
从本体库到程序化验证：ComponentBench 的硬核设计
ComponentBench 的核心设计理念是“系统化”与“确定性”。研究团队并没有随机抓取网页，而是建立了一个独立于具体前端库的“组件本体库”（Component Ontology）。
该本体库结合了 WAI-ARIA 官方指南和主流 React UI 库（如 Ant Design、MUI、Mantine 等）的生产级清单，最终确立了 97 种规范的组件类型，并将其划分为 14 个交互家族。基于这些本体，团队通过大语言模型辅助生成了 2910 个任务规范。这些任务不仅包含了基础的交互动作，还系统性地控制了 8 个场景因素（如主题、间距、布局、干扰物密度）和 7 个意图难度轴（如精度要求、目标获取难度、反馈动态等）。
在此基础上，ComponentBench 引入了三个极其关键的工程决策：
第一，采用程序化验证（Programmatic Verification）而非模糊匹配。在 ComponentBench 中，任务的成功与否不取决于智能体是否“短暂打开了正确的菜单”或“做出了正确的中间草稿选择”，而是取决于相关交互被真正提交后的“最终状态”。例如，某些任务不仅要求修改数据，还要求明确点击局部的“应用”或“保存”按钮。底层环境会在状态完全正确时弹出特定的成功横幅，这不仅为各种控制模式提供了统一的终止条件，还从根本上杜绝了智能体利用前端 DOM 属性进行作弊的可能性。
第二，引入真实的人类操作轨迹作为参照。每一个被实现为真实交互页面的任务，都由人类操作员执行两次，记录下低级的鼠标和键盘动作及时间戳。经过清洗后的最短人类轨迹，一方面用作确认任务可解性的绝对标准，另一方面则成为了衡量智能体操作效率（Latency/Steps）和重放分析实际结构难度的基准线。
第三，在统一的测试框架内支持多种观察与动作空间。本文设计了四个对比象限：可访问性树（AX-tree）、标记集合（Set-of-Marks, SoM）、纯像素（Pixel）以及作为工具丰富参照组的 Browser-Use。这使得研究人员能够将“模型内在的推理能力”与“暴露给模型的接口设计”彻底剥离。
在上面展示的 data_table_filterable 任务中，页面上存在三个视觉上高度相似的微型表格。智能体必须准确识别出“Invoices”表格，应用两项过滤条件，并点击该实例局部的“Apply”按钮。这种饱含干扰项和状态提交流程的设计，正是现代复杂企业级 SaaS 软件的真实缩影。
实验结果揭示的三大核心现象
在对七款不同规模和架构的大模型（涵盖 GPT-5.4、GPT-5 mini、Gemini 3 Flash、Qwen3-VL-235B 等）进行全面测试后，ComponentBench 的数据戳破了当前 UI 智能体的几个关键假象，揭示了真正制约其实用化落地的瓶颈。
交互接口的改变足以让成功率发生“雪崩”
研究团队发现，观察与动作空间（即智能体如何“看”和如何“指”）对任务成功率的影响，远远超出了业界的预期。在同一个测试框架内，仅仅改变交互接口，就可能导致同一个模型的表现出现超过 30% 的剧烈波动。
最极端的案例发生在 GPT-5 mini 身上。当使用结构化的可访问性树（AX-tree）作为观察空间时，该模型取得了 83.1% 的高成功率；但当切换到仅依赖坐标输出的纯像素控制（Pixel）时，其成功率断崖式暴跌至 48.9%。在所有被测试的模型中，无论其绝对能力强弱，最佳接口与最差接口之间的差距都极其显著。这一结果证明，当前计算机使用智能体的成功，在很大程度上仍然依赖于底层 HTML 结构的“作弊式”辅助，一旦脱离了结构化数据的庇护，纯视觉交互的鲁棒性依然极其脆弱。
标记集合（SoM）并非万能药，有时甚至适得其反
在过去的两年里，为截图上的可交互元素覆盖数字编号（Set-of-Marks）被普遍视为提升多模态模型 GUI 操作能力的黄金法则。然而，ComponentBench 的交叉对比给出了一份高度模型依赖的诊断报告。
对于视觉基础能力较弱的模型，SoM 确实提供了立竿见影的帮助。例如，GPT-5 mini 在 SoM 模式下比 Pixel 模式提升了 29.6%，Gemini 3.1 Flash-Lite 也有 10.2% 的增幅。但令人意外的是，对于视觉交互能力已经极强的前沿模型（如 GPT-5.4 和 GPT-5.4 mini），局面发生了逆转：它们的 Pixel 模式表现反而超越了 SoM 模式。对于 GPT-5.4 而言，纯像素模式达到了 83.8%，不仅以近 7 个百分点的优势击败了 SoM，甚至超越了获取了底层结构的 AX-tree 模式（81.5%）。
作者在论文中做出了明确的判断：结构化的视觉辅助叠加（如屏幕上的红框和编号）并不是普遍有益的。它们通过提供显式的锚点拯救了弱模型，但对于已经具备强大直接视觉定位能力的强模型而言，这些覆盖物不仅增加了视觉混乱度（Clutter），引入了额外的间接推理层，反而成为了干扰认知的中和剂甚至毒药。
效率危机：完成任务不等于“可用”
如果仅看最终成功率（部分模型高达 85% 以上），人们可能会误以为 UI 智能体已经可以完美替代人类操作。但时间效率和动作步数的数据却给出了截然不同的结论。
论文深入对比了智能体与人类参考轨迹的动作步数比例（效率差距）。在 Browser-Use 框架下，尽管 Gemini 3 Flash 的最终通过率高达 95.2%，但能在人类步骤预算内（≤H）完成的任务比例仅为 56.1%。而在较弱的模型配置下，情况更加惨烈：GPT-5 mini 在 Pixel 模式下虽然最终通过了 48.9% 的任务，但能在人类步数内完成的仅有 19.0%（平均耗费步骤是人类的 3.6 倍，90 分位耗时更是达到了惊人的 9.0 倍）。
从挂钟时间来看，这种低效更加致命。即使是表现最快的配置（GPT-5.4 mini SoM），完成任务的时间也是匹配人类参考轨迹的 3.7 倍；而最慢的配置（GPT-5 mini Pixel）则需要耗费人类 21.5 倍的时间，平均每个成功任务需要 71.8 秒。在每一步都需要昂贵 API 调用的现实场景中，这种依靠“无限重试”换取成功率的模式，根本无法达到工程部署及格线。
人机难度倒挂：空间操作成为模型死穴
ComponentBench 最具启发性的发现之一，是揭示了一种强烈的“难度倒挂”现象。研究团队发现，有九类特定的组件交互任务，人类操作员通常只需要不到两次动作即可完成，但所有被测智能体的平均通过率却不到 60%。
这些组件包括：可调整大小的列宽（24.4%）、窗口分割线（38.3%）、范围滑块（39.9%）等。对于人类来说，按住鼠标拖动滑块或调整窗口边缘，是一种已经内化为肌肉记忆的无意识操作，甚至不需要过多的视觉注意力。但对于智能体而言，这些“空间操作”却成为了不可逾越的高墙。
作者分析指出，诸如拖动窗口分割线的任务之所以困难，是因为它将“感知能力、运动控制和状态验证压缩在了一个极其狭窄的操作空间内”。智能体必须能够连续地预测正确的屏幕坐标，评估滑动过程中的相对位移反馈，并在毫厘之间停下。目前基于截屏帧输入和离散坐标输出的视觉语言模型，在处理这种需要连续反馈回路（Continuous Feedback Loop）的物理隐喻交互时，显得极其笨拙。在所有测试数据中，没有出现任何一种“对人类极其困难、但对智能体却非常简单”的组件类型。
失败归因：深究背后的底层机制
为了进一步搞清楚这些成功率数据背后的实际阻碍，研究团队建立了一个基于轨迹支撑的故障分类法（Failure Taxonomy）。他们解析了超过 8800 条失败的执行轨迹，揭示了几个极其高频且致命的故障机制。
其中最典型的就是“连续校准错误”（Continuous Calibration Errors）。在面对滑块或进度条时，智能体并非“不懂”任务指令，它们通常能够准确找到并点击对应的滑块控件。但一旦开始拖动，它们就无法将鼠标指针的位移与数值的增加建立正确的映射关系，导致在目标值附近不断地过度拉升或反向收缩，直到达到最大步骤限制被迫超时。这就解释了为什么投入更强推理能力的模型依然无法搞定这些“无需推理”的低级交互。
另一个高发问题是“瞬态状态丢失”（Transient State Loss）。在复杂的下拉菜单、悬停弹窗或编辑器模式中，智能体好不容易触发了隐藏的控件，却因为后续的一步误操作（如点击了空白区域或移动了焦点），导致整个弹窗关闭，被迫从头再来。
此外，论文还着重分析了视觉密度带来的影响。对于纯视觉代理（Pixel 模式）而言，视觉混乱度（Clutter）是致命的。当页面元素密度提升至中等干扰水平时，Pixel 模式的平均成功率下降了 14.3%，而依赖底层结构的 AX-tree 模式仅下降了 0.2%。这表明大量纯视觉代理的失败并非因为未能理解语义，而纯粹是因为在密集的像素海洋中“看花了眼”，点错了相近的元素。
总结与启示
通过严密的组件解构和多维度的交叉测试，ComponentBench 为计算机使用智能体的能力边界绘制了一幅迄今为止最清晰的诊断图。这篇论文的价值不在于提供了一个新的模型跑分榜单，而在于它像一把手术刀，精准切除了掩盖在宏大任务和高成功率表象下的技术顽疾。
实验数据向整个 AI 社区传递了一个明确的信号：要实现真正可商用、低延迟的 Web 智能体，单纯依赖扩大视觉语言模型（VLM）的参数规模和逻辑推理能力是不够的。行业迫切需要解决模型在连续运动控制、瞬态状态维持以及高密度视觉消歧方面的基础缺陷。只有当智能体在面对一个普通的滚动条或日期选择器时，也能展现出接近人类的利落与高效，那个人人拥有全自动数字助理的未来，才算真正拉开帷幕。