ComponentBench: 诊断计算机使用代理中的组件级故障

# ComponentBench：诊断计算机操作代理的组件级故障
来源：https://arxiv.org/html/2608.18307
作者：Xinlei Lin、Royce Cheng-Yue、Xiangjun Wang（均隶属于Amazon AGI SF Lab），Shuyan Zhou、Tianchen Guan（隶属于杜克大学，邮箱：{tianchen.guan, shuyan.zhou}@duke.edu）

###### 摘要
当前对计算机操作代理的评估分为两类：长时程工作流基准测试与原子级GUI定位测试。这导致中间层缺乏有效工具：既需要足够简短以便诊断，又要足够丰富以捕捉现代界面复杂性的、以组件为中心的现实交互（例如切换按钮组）。我们提出ComponentBench，这是一个用于评估现代网页UI计算机操作代理组件级表现的基准测试与诊断流水线。ComponentBench围绕一个与库无关的本体构建，包含97种规范UI组件，在Ant Design、MUI和Mantine等主流组件库中实例化为2,910个经过程序化验证的任务，并配对清理后的人类参考轨迹，以同时评估任务成功率和交互效率。除任务收集外，我们还引入了一套可扩展的流水线，用于在实现后审计实际结构难度，并跨任务和组件族合成结构化故障分析。通过评估七种模型（GPT-5.4、Gemini 3 Flash、GPT-5.4 mini、GPT-5 mini、Gemini 3.1 Flash-Lite、Qwen3-VL-235B和UI-TARS-1.5-7B）在四种观察与行动空间中的表现，我们证明这些设计选择对性能有关键影响。在单一集成环境中，仅改变观察与行动空间就能使同一模型的任务成功率变化超过30%：GPT-5 mini在使用无障碍树观察时成功率为83.1%，而切换为仅坐标像素控制后降至48.9%。此外，即使最快的配置也比匹配的人类参考轨迹慢3.7倍，而对人类轻而易举的空间操作对当前代理仍具挑战。

## 1 引言
计算机操作代理正从研究原型转向通过人类使用的相同界面操作网站和软件的用户级系统。OpenAI的Operator (OpenAI 2025b)和Computer Use API (OpenAI 2026a)，以及Anthropic的computer-use工具 (Anthropic 2026a)，使得渲染界面本身——通常是截图加鼠标键盘操作——成为首要控制面。这使得全视觉评估日益核心。随着截图原生代理能力增强，关键问题不再仅仅是代理能否偶尔完成浏览器任务，而是哪些渲染后的UI组件仍会阻碍部署中的可靠高效使用。当前评估范式仍强调两个极端。长时程基准测试如WebArena、VisualWebArena、OSWorld、WebVoyager和Online-Mind2Web测量真实任务的端到端能力，但难以归因故障：当代理错过工作流时，根本原因可能在于规划、状态跟踪、定位或埋藏在更大任务中的某个脆弱交互。另一个极端，定位基准测试如ScreenSpot和ScreenSpot-Pro隔离了定位能力，但止步于现代小部件通常所需的短暂多步骤交互。介于两者之间的努力——MiniWoB++的合成微环境、Mind2Web的离线真实站点轨迹，以及WebSuite、WARC-Bench和OpenApps的网络动作分类、归档GUI子任务和外观变化——对我们而言仍不完整：据我们所知，没有一项围绕现代UI组件的广泛跨库本体、程序化终态验证、人类参考轨迹和渲染后难度审计来组织。这一缺失层之所以重要，是因为现代网络软件由生产UI库大规模暴露的重复组件原语构成。一个长工作流可能失败，并非因为代理误解了用户目标，而是因为它错误处理了某个日期选择器、多选框、分割器或拖拽目标。长任务的可靠性仅等同于其包含的组件交互可靠性：在简单的独立性近似下，五个可靠性80%的关键交互仅意味着约33%的端到端成功率上限。且通过率本身不足以评估。近期研究显示，即使强大的计算机操作代理也常比人类消耗更多步骤，这在实际部署中带来重大延迟和成本影响。我们提出ComponentBench [1]，一个用于通过现代网页UI组件中心任务评估计算机操作代理的基准测试与诊断流水线。ComponentBench围绕97种规范组件类型、14个交互族和24种任务模板组织评估，实例化为2,910个主要在Ant Design、MUI和Mantine上经过程序化验证的任务（三十个Markdown编辑器任务使用外部实现；附录A.5）。每个任务锚定于单一主要组件，即使需要现实的承载上下文。该基准在四种观察与行动空间下评估代理——AX树、标记集、像素和浏览器使用——并通过基于人类参考轨迹的重放审计区分设计意图难度与渲染UI实际呈现的难度。ComponentBench还旨在评估效率而非仅最终完成度。由于我们收集了所有任务的清理后人类参考轨迹，我们不仅能询问组件是否可解，还能询问其解决方式是否足够直接以可用——这对全视觉代理至关重要，因为每个额外步骤都意味着更多延迟、更多令牌成本和更多偏离机会。为支持更快的压力测试，我们进一步提取了ComponentBench-Core，一个精炼的912个仅困难任务子集，专注于完整套件中未解决的区域。我们在ComponentBench-Full上对七种模型和四种观察/行动空间的实验揭示了四个主要发现。第一，观察/行动空间可在单一模型内使通过率变化超过30%，且标记集的优势是模型依赖而非普适。第二，效率仍是主要部署瓶颈：即使最快的配置也比匹配的人类参考轨迹慢3.7倍，且最强模型最终解决的任务数量远超人类步骤预算。第三，几个人类可在1-2步内完成的空间操作组件——包括滑块、拖放列表和分割器——在所有测试代理中平均通过率仍低于60%。最后，难度强烈受视觉上下文影响，在杂乱和紧凑间距下AX树与像素之间的差距显著扩大。基于轨迹的故障分类法（第4.4节）将这些发现与具体机制关联。总之，这些结果表明组件级评估暴露了在长时程任务分数和单步定位基准中大多不可见的故障模式。

## 2 基准构建
### 工作示例。在介绍基准模式前，我们先看一个具体任务。图2展示了data_table_filterable-mantine-T10。页面包含三个视觉相似的迷你表格，分别标记为“订单”、“发票”和“支付”。代理必须仅操作“发票”实例：将“支付状态”设为“延迟”，将“货币”设为“欧元”，然后点击本地“应用”按钮。这个例子已经体现了ComponentBench中几个反复出现的设计选择：每个任务针对一种主要组件类型；页面可能包含增加真实性的承载上下文而不改变测试内容；邻近实例可能产生消歧负担；成功由已提交的最终状态定义，而非草稿选择。
### 2.1 组件清单与任务规范
为系统覆盖现代网络交互，我们结合WAI-ARIA创作实践指南（记录通用小部件模式和行为）与主流React UI库（Ant Design、MUI、Mantine、Fluent UI、Chakra UI和Headless UI）的生产组件清单，构建结构化清单。由此产生的组件本体是一个与库无关的97种规范组件类型集合（如日期选择器），分为14个族（如拖放与工作区）。为实现，我们选择Ant Design、MUI和Mantine，因其全面覆盖和风格多样性，这也使跨库变体可作为分析中的受控因素。每个任务评估一种主要组件类型，即使渲染页面包含许多其他控件：在图2中，一个可过滤数据表是主要组件，外围的汇总表和相邻迷你表格作为承载上下文。任务以YAML指定，每个规范包括规范类型、实现源、任务模板（如打开并选择或拖放操作等可复用动作模式）、场景上下文（八个受控因素：主题、间距、布局、放置、缩放、实例数、引导、杂乱）、意图难度块（七个概念轴：精度要求、目标获取、密度/选择干扰、深度/层次、反馈动态、语义可观察性、消歧负担）、成功触发器和负面案例。完整套件包含24种规范任务模板（加一个用于单任务的临时变体）和2,910个任务；附录A.5总结了所有这些维度的实现多样性。
### 2.2 任务生成、实现与人工验证
ComponentBench通过结构化、LLM辅助流水线构建。首先，GPT-5.2 Pro在共享YAML模式下为每种规范类型生成30个任务规范，包括任务模板、场景因素、意图难度标签、成功触发器和负面案例。其次，Claude Code将这些规范实现为真实的交互式Next.js页面而非静态原型。第三，每个人工执行两次，记录为带时间戳的底层操作（点击、拖拽、键盘输入、滚动），经清理——合并连续击键并移除意外重置——保留较短的成功轨迹作为参考。人类记录有两个作用：构建时，它们是任务可解且忠于规范的决定性验证；后期，相同清理轨迹作为效率分析和基于重放的难度审计的参考轨迹。在所有2,910个任务中，清理轨迹平均为2.7个标准化步骤（中位数2），97.8%的任务可在10步内解决，平均完成时间为4.8秒。
### 2.3 程序化验证
每个任务配有一个检查已提交最终状态的程序化验证器。因此基准不询问代理是否短暂打开了正确菜单或草拟了正确中间选择，而是询问在相关交互实际提交后底层任务谓词是否满足。对某些任务，实时状态足够；对另一些，成功需要显式本地控件如应用、保存、确定或确认。对于图2中的示例，成功要求“发票”迷你表（而非相邻“订单”或“支付”表）的“支付状态=延迟”且“货币=欧元”，且这些选择已通过实例本地应用按钮提交。每个YAML任务还枚举负面案例，使邻近但不正确的状态不算成功。具体地，YAML指定规范成功谓词，页面实现提供评估此谓词的JavaScript检查器。在环境层面，终止是有意简单确定的：通过显示基准横幅（#cb-success-banner）表示成功。这为所有观察/行动空间提供相同终止条件，同时使检查器逻辑保持任务特定。重要的是，验证器状态与代理观察隔离。目标值和成功谓词位于React组件闭包中，从不暴露为DOM属性、无障碍树标签或页面文本；成功横幅仅在正确状态已达到后出现，因此不能用于绕过任务。在基准模式下，MutationObserver还实时剥离所有测试专用DOM属性（data-testid、data-cy等），CI就绪扫描器验证所有2,910页面中无此类属性残留。
### 2.4 观察与行动空间
ComponentBench核心目标是在不同观察与行动空间下评估同一底层任务。因此基准支持四种模式。
**AX树**。代理接收截图加无障碍树文本，通过元素ID操作。
**标记集（SoM）**。代理接收带有编号的截图...