← 返回 2026-04-02

Vision2Web：基于代理验证的视觉网站开发层次化基准测试 Vision2Web: A Hierarchical Benchmark for Visual Website Development with Agent Verification

Zehai He, Wenyi Hong, Zhen Yang, Ziyang Pan, Mingdao Liu, Xiaotao Gu, Jie Tang 📅 2026-03-27 👍 46 2026-07-13 08:36

代码生成基准测试多模态模型网站开发自动化评估

arXiv HuggingFace PDF

提出一个三层级、自动化评估的视觉网站开发基准，揭示当前多模态编码代理在长周期任务中的系统性不足

前置知识

多模态大型语言模型

能够同时处理文本、图像等多种输入形式的大型语言模型，通过视觉编码器将图像转换为特征表示，与文本特征融合后在统一的 Transformer 架构中进行推理。典型的如 GPT-4V、Claude 3.5 Opus、Gemini Pro 等。

本文核心是评估多模态模型在视觉网站开发任务中的能力，理解其工作原理对于评估结果的分析和后续改进方向的设计至关重要。

工作流验证（Workflow Verification）

一种结构化的测试范式，将复杂的端到端测试过程分解为有依赖关系的验证节点序列。每个节点包含明确的目标、引导动作和验证标准，通过控制代理执行路径来保证评估的可重复性和稳定性。

本文的核心创新之一，解决了传统无约束评估不稳定的问题，需要理解其设计原理才能评估基准的有效性。

全栈网站开发

涵盖前端（HTML/CSS/JavaScript、用户界面）、后端（API设计、业务逻辑、数据库管理）以及两者集成的完整软件开发流程。典型技术栈包括 React/Vue 前端框架、Node.js/Python 后端、以及 PostgreSQL/MySQL 等数据库。

本文最高难度的任务层级，需要掌握前后端概念才能理解任务的复杂性和代理面临的挑战。

Spearman秩相关系数

一种衡量两个变量之间单调关系的非参数统计量，取值范围在 $[-1, 1]$，1 表示完全正相关，-1 表示完全负相关，0 表示无相关性。公式为 $\rho = 1 - \frac{6\sum d_i^2}{n(n^2-1)}$，其中 $d_i$ 是秩次差。与 Pearson 相关不同，它不假设变量呈线性关系或正态分布。

本文用于验证 VLM 判别器与人工判断一致性的关键指标（$\rho = 0.66$），理解该指标才能评估验证器的可靠性。

响应式网页设计

一种网页设计方法，使同一套代码能够在不同设备尺寸（桌面、平板、手机）上自动调整布局和样式。通过 CSS 媒体查询（如 @media (max-width: 768px)）实现，确保用户体验的一致性。

本文静态网页任务要求同时满足桌面、平板、手机三种设备的显示效果，这是评估的维度之一。

研究动机

现有编码代理评估基准存在三个根本性缺陷：任务形式化范围有限，SWE Bench 及其变体仅关注增量式的 issue 修复，只能评估局部开发技能而无法覆盖端到端的软件工程全流程；多模态覆盖不匹配，虽然有 VIBE Bench 和 WebGen Bench 等开始探索端到端开发场景，但多模态基准大多局限于 Design2Code 这类静态单页面重现任务；验证机制不足，尽管已有端到端开发的初步尝试，但由于任务定义不够明确、验证流程约束不足，可靠且可复现地评估复杂交互和长周期系统结果仍然极具挑战性。

本文的目标是本文旨在构建一个全面评估多模态编码代理在视觉网站开发任务中能力的层次化基准，通过自动化的代理验证机制实现功能正确性和视觉保真度的可靠测量，系统性地揭示当前模型在跨模态推理、长周期任务规划和多页面协调方面的能力差距，为未来研究方向提供客观依据。

与已有工作不同的是，本文的独特切入角度在于将网站开发任务形式化为三个递进的难度层级，从静态网页生成到交互式前端开发再到全栈网站构建，使得能力分解成为可能；采用基于工作流的代理验证范式，通过结构化的测试工作流和明确的验证节点平衡了代理交互的灵活性和评估的可重复性；数据构建采用现实世界的公开网站而非合成任务，通过多阶段流水线确保质量和多样性，既反映了真实的工程场景又避免了数据污染问题。

核心方法

方法整体思路是首先构建一个包含真实网站的多层次任务数据集，然后将端到端测试过程形式化为有向依赖图，其中每个节点代表一个独立的验证子过程，边编码顺序依赖和共享状态。通过将图实例化为可代理执行的子图集合（称为测试工作流），并设计两种互补的验证器——GUI 代理验证器负责功能正确性，VLM 判别器负责视觉保真度，在统一的框架下实现自动化、实现无关的评估。

核心创新在于提出工作流代理验证范式，它保留了代理交互的灵活性和与人类视觉偏好的对齐，同时通过结构化的测试工作流和明确验证节点的约束实现可重复性。每个验证节点被明确定义为三元组 $n_i = \langle O_i, A_i, V_i \rangle$（功能节点）或 $n_i = \langle P_i \rangle$（视觉节点），通过显式建模引导动作 $A_i$ 防止代理探索不必要的模块或执行意外的动作，从而提高评估的可复现性。此外，将任务分解为三个递进层级使得可以明确地将失败归因到特定的开发阶段，这是对现有整体评估方法的本质改进。

方法步骤详情

方法步骤包含数据构建和评估两个主要部分。数据构建通过三阶段流水线完成：结构评估阶段分析 DOM 级别属性（HTML 标签分布、DOM 树深度、token 长度），过滤掉过于简单或结构不良的页面，得到 63,515 个候选网站；内容筛选阶段使用基于 VLM 的评分对候选网站的内容和设计质量进行过滤，仅保留 7,391 个展示功能丰富性、模块清晰性和视觉一致性的页面；人工审查阶段由 PhD 研究人员和 Claude Code 协作完成，基于页面一致性、实现难度、交互功能清晰度和丰富度等标准进行评审，并确保四大类网站和 16 个子类别的平衡覆盖。评估阶段执行工作流代理验证算法：初始化历史 $H$、功能分数 $F$ 和视觉分数 $V$ 为空；对工作流中的每个节点 $n_i$，如果是功能验证节点则调用 GUIAgentVerifier 执行并更新 $F$，如果是视觉验证节点则调用 VLMBasedJudge 评分并更新 $V$；最终返回聚合的功能和视觉分数。

技术新颖性

技术新颖性体现在四个方面：一是首次将网站开发任务系统性地分层为三个递进难度层级，实现了能力的显式解耦和归因；二是提出的基于工作流的代理验证范式通过结构化约束平衡了灵活性和可重复性，这为端到端软件系统的自动化评估提供了新范式；三是测试工作流的设计遵循解耦依赖节点和集成相关节点的原则，既避免了误差积累又减少了冗余设置；四是验证器的组合使用（GUI 代理验证器 + VLM 判别器）实现了功能和视觉两个维度的客观评估，且验证器与人类判断的一致性分别达到 87.2% 和 Spearman 相关系数 0.66，证明了可靠性。

**Figure 1**: Overview of Vision2Web, a hierarchical benchmark for visual website development.

**Figure 2**: Task distribution of Vision2Web across four major categories and 16 subcategories.

**Figure 6**: Comparison of task complexity metrics between Design2Code-Hard and Webpage tasks of Vision2Web.

**Figure 7**: Cross-device responsive static webpage task example.

实验结果

实验在 OpenHands 和 Claude Code 两个框架下评估了 8 个最先进多模态模型，揭示了六个关键发现：第一，代理性能在三个任务层级上持续下降，Gemini-3-Pro-Preview 在 OpenHands 框架下静态网页桌面布局得分为 63.3，但全栈任务视觉得分仅 11.7、功能得分仅 22.6，部署成功率从 95% 降至 77.8%；第二，代理性能在适应较小设备因素和更复杂的原型图像时系统性下降，桌面界面保真度最高，平板和手机布局得分低 10-20%；第三，Claude-Opus-4.5 在所有评估代理中性能最强，在 OpenHands 框架下静态网页桌面得分 58.9、交互式前端 VS/FS 为 46.5/66.7、全栈 VS/FS 为 38.4/57.6；第四，代理性能因框架而异，OpenHands 框架下性能普遍高于 Claude Code，表明模型和代理框架的联合优化有提升空间；第五，全栈编码性能因网站类别而系统性差异，公共服务网站（简单结构、有限交互）表现最强（VS 56.9 / FS 60.0），SaaS 平台（多页面导航、复杂交互）表现最弱（VS 22.9 / FS 39.9）；第六，在功能类别层面，导航与路由和认证与授权是最可靠的能力，Claude-Opus-4.5 和 GPT-5 通过率一致较高，但在状态管理、CRUD 操作和文件媒体操作方面性能显著下降。

**Table 1**: Comparison of Existing Benchmarks for Software Engineer and Web Development Tasks.

**Table 2**: Average prototype images, test cases, and input text tokens for Vision2Web across three task levels.

**Table 3**: End-to-end performance of multimodal coding agents on Vision2Web across three task levels.

**Table 4**: Performance (Visual Score / Functional Score) of selected coding agents across different website categories under the OpenHands framework.

**Table 5**: Performance of selected coding agents under the OpenHands framework on Vision2Web, reporting category-wise functional scores (average test-case pass rates).

**Table 6**: Website categories in Vision2Web, subcategory definitions, and representative examples.

**Table 7**: Distribution of tasks across website categories and development levels in Vision2Web.

**Figure 3**: Distribution of test cases across website-level tasks in Vision2Web.

**Figure 4**: Distribution of Visual Scores (VS) across prototype heights for representative models under the OpenHands framework.

查看结构化数据

任务	指标	本文	基线	提升
静态网页（桌面）	Visual Score	Gemini-3-Pro-Preview: 63.3	Design2Code: ~70-80	略低但任务更复杂（DOM深度 22 vs 10，标签数 1385 vs 251）
静态网页（桌面）	Visual Score	Claude-Opus-4.5: 58.9	Design2Code: ~70-80	略低但任务更复杂
交互式前端	Visual Score / Functional Score	Claude-Opus-4.5: 46.5 / 66.7	WebGenBench: ~40-50	可比较但更注重多页面导航
全栈网站	Visual Score / Functional Score	Claude-Opus-4.5: 38.4 / 57.6	WebGenBench: ~20-30	显著提升（约 1.5-2 倍）
全栈网站（公共服务）	Visual Score / Functional Score	Claude-Opus-4.5: 56.9 / 60.0	无直接可比	新基线
验证器可靠性	准确性 / 相关性	GUI Agent: 87.2%, VLM Judge: $\rho=0.66$	无标准	新基线

局限与改进

作者承认的局限性包括：VLM 判别器与人工判断的 Spearman 相关系数为 0.66（中位数 0.80），虽然接近人类间一致性 0.78，但在困难情况下仍有提升空间；GUI 代理验证器 87.2% 的节点级准确率中剩余不准确主要归因于模型内在推理幻觉；基准目前仅覆盖网站开发领域，虽然具有代表性但不能完全代表所有软件工程场景；评估环境配置了有限的基础工具，虽然确保了代理依赖自身能力，但与实际开发环境可能有差异。此外，观察到：Seed-1.8-VL 在全栈任务上完全失败（VS = 0, FS = 0），Qwen3-VL-32B/8B 基本无法完成多模态编码任务，暴露了模型能力差距；复杂网站类型（如 SaaS 平台）的性能明显低于公共服务类网站，表明当前代理对多页面导航和复杂交互模式的处理能力仍不足。

独立分析的弱点

独立分析的弱点包括四个方面：一是精细视觉对齐能力不足，代理经常无法重现精细的视觉细节，包括错位布局、错误尺寸和颜色不匹配，特别是对规则排列的组件，资源处理尤为脆弱，代理过度依赖文件名而缺乏稳健的多模态基础；二是跨模块视觉理解能力有限，虽然首页通常能合理重现，但后续页面的视觉保真度下降，出现缺失或错位组件、功能失常的交互元素和损坏的导航链接，反映了跨视图保持连贯视觉和功能推理的困难；三是长周期规划和执行能力缺失，编码代理缺乏可靠的自主验证机制，在扩展上下文中功能实现经常偏离规范，导致全栈项目无法启动、执行期间崩溃或出现普遍功能错误；四是状态依赖操作处理不力，在状态管理、CRUD 操作和文件媒体操作等需要持久状态跟踪、组件间正确数据流或前端逻辑与系统级资源协调的任务中表现明显不足。改进方向：增强多模态基础能力，特别是组件级视觉到代码的精确对齐；开发跨页面状态追踪机制；集成自主验证和调试工具；优化长周期任务规划和分解能力。

未来方向

作者提出的未来研究方向包括：定期（每季度）使用最新的骨干模型更新 VLM 判别器和 GUI 代理，以维持评估器的可靠性；扩展基准覆盖更多软件工程领域和更复杂的应用类型；探索更精细的归因分析机制，将失败归因到更细粒度的能力子维度；研究模型和代理框架的联合优化方法，因为实验显示框架选择显著影响代理性能。基于成果可延伸的方向：将工作流验证范式推广到其他端到端软件系统评估场景，如移动应用开发、桌面软件开发等；开发自动化测试工作流生成工具，减少对人工标注的依赖；研究多模态代码生成的在线学习和持续改进机制；探索更高效的视觉-代码对齐算法和评估指标。

复现评估

复现评估：项目页面 https://vision2web-bench.github.io/ 提供了完整的信息，但开源情况论文中未明确说明是否已公开数据集和评估代码；数据来源为 C4 验证集的公开网站，共 193 个任务、918 个原型图像和 1255 个测试用例，涵盖 4 大类 16 子类网站，数据规模适中但覆盖全面；算力需求涉及模型推理（8 个多模态模型）和代理执行（容器化环境），具体 GPU 需求未说明，但从使用 GPT-5、Claude-Opus-4.5 等推断需要高端 GPU 集群；评估环境为容器化的 Ubuntu 22.04，预配置 Node.js 20.x、Python 3.12、Playwright、数据库客户端等，确保了环境一致性；评估协议标准化为最多三次迭代收集结果，超过 10 分钟或产生错误视为失败，增强了可复现性；难度较高，主要难点在于：需要集成多个不同的多模态模型 API（GPT-5、Claude、Gemini、Qwen 等），需要配置容器化评估环境，需要训练或部署 GUI 代理验证器和 VLM 判别器。建议团队具备多模态模型集成、自动化测试框架和容器化部署的经验。

论文图表

**Figure 10**: failure cases of static webpage tasks
该图展示了静态网页任务的失败案例，包括原型图像和 Claude-Opus-4.5、Claude-Sonnet-4.5、Seed-1.8-VL 生成的网页，显示代理在精细视觉对齐、布局复现和组件排列上的错误。

这张图对理解失败模式很重要，它用可视化方式展示了静态网页级别的典型错误，帮助读者理解为什么即使在这个最简单层级上性能也不完美。

**Figure 11**: failure cases of interactive frontend tasks
该图展示了交互式前端任务的失败案例，包括博客和日历的原型图像与 Claude-Opus-4.5 生成的网页对比，显示代理在跨页面导航、组件一致性和交互功能实现上的错误。

这张图对理解跨模块理解能力的局限性很重要，它展示了当任务范围扩展到多个页面时错误如何累积。

**Figure 12**: failure cases of full-stack website tasks
该图展示了四个全栈网站（agendrix、cognitoform、invoicera、sykescottages）的失败案例，显示代理在系统级集成、功能完整性和执行稳定性上的严重问题。

这张图对理解系统级规划的局限性至关重要，它展示了长周期任务中的典型失败模式，证明当前代理距离实用化还有很大差距。

Figure 8: Interative frontend task example.

该图展示了一个交互式前端任务示例，包括首页、服务页面和联系页面三个原型，显示代理需要实现多页面导航和一致的视觉风格。

这张图对理解第二层级任务很重要，它展示了交互式前端的核心挑战是多页面协调。

Figure 9: Full-stack website task example.

该图展示了一个全栈网站任务示例，包括首页、对话页面和登录页面三个原型，显示代理需要实现完整的业务流程（如 Airbnb 社区中心的帖子创建、浏览、回复等功能）。

这张图对理解第三层级任务很重要，它展示了全栈开发的核心挑战是集成前端、后端和数据库。