1. 项目缘起浏览器代理基准测试的“不可能三角”如果你最近在折腾浏览器自动化测试或者研究基于大模型的Web智能体那你大概率听过一个词“基准测试”。听起来很高大上但说白了就是得有个公平的“考场”和一套标准的“考题”才能知道谁家的“学生”代理更厉害。然而这个“考场”的搭建在Web领域却一直是个老大难问题业内普遍认为存在一个“不可能三角”真实性、可复现性和可扩展性三者难以兼得。让我用大白话解释一下这个三角困境。真实性指的是测试环境要和真实用户访问的网站一模一样包括动态加载的内容、复杂的交互逻辑、甚至反爬虫机制。你总不能在“Hello World”页面上测出一个代理的“智能”吧可复现性意味着每次测试的结果必须稳定一致。今天跑分90明天因为网站改了个按钮位置或者服务器抽风跑分直接掉到60这种测试结果谁敢信可扩展性则要求这个测试框架能轻松地覆盖成千上万个不同的测试用例比如测试电商下单、社交发文、信息查询等不同任务并且成本可控。传统的做法往往是“三选二”。比如直接用Selenium或Playwright驱动真实浏览器去访问线上网站真实性拉满但可复现性极差——网站随时在变网络也不稳定。另一种思路是搭建一个本地的、静态的模拟网站环境可复现性好了但真实性又大打折扣代理学到的“经验”可能无法迁移到真实世界。至于可扩展性无论是维护海量真实网站的测试脚本还是构建逼真的模拟环境人力和算力成本都高得吓人。WebForge这个项目瞄准的就是打破这个“不可能三角”。它的核心思路不是去“模拟”一个网站而是去“记录”并“重放”一个真实的网站交互过程并在此基础上进行可控的“变异”和“扩展”。这就像不是去搭建一个假的城市来训练司机而是把真实城市的交通录像拿过来让AI司机在录像里“开车”并且我们可以随意修改录像里的红绿灯、行人位置创造出无数种新的驾驶考题。接下来我就结合当前热门的Playwright、Cursor等工具以及自动化测试框架的搭建经验来深度拆解WebForge是如何实现这一目标的以及我们如何借鉴其思想来构建自己的、更实用的浏览器代理测试环境。2. WebForge的核心架构记录、重放与程序化生成要理解WebForge如何破局我们得先钻进它的“引擎盖”下面看看。它的架构设计非常巧妙可以概括为“一个核心两个阶段无限衍生”。一个核心是浏览器交互轨迹的记录与抽象。WebForge不是简单地录屏它使用类似Playwright这样的现代化浏览器自动化框架在真实网站上执行一系列任务比如“在电商网站搜索商品并加入购物车”。在这个过程中它会以极高的粒度记录下一切每一次网络请求URL、方法、载荷、响应、每一个DOM节点的变化通过Mutation Observer、每一次用户交互点击、输入、滚动的精确坐标和目标元素。最终它生成的不是视频文件而是一个结构化的、包含完整页面状态序列的“轨迹文件”。这个文件就是那个被“定格”的真实世界快照。两个阶段指的是记录阶段和重放/评估阶段的彻底分离。这是保证可复现性的关键。在记录阶段工程师或标注人员像正常用户一样操作确保轨迹的质量和真实性。这个阶段不关心代理只关心把“标准答案”完美地录下来。到了重放阶段这个轨迹文件被加载到一个受控的、隔离的“沙盒”环境中。这个沙盒能完全复现记录时的网络响应和初始DOM状态。然后才把待测试的代理比如你的AI模型放进来让它基于当前页面状态去决策下一步动作。代理的每一个动作都会与轨迹中记录的“标准动作”进行比对和评估。注意这里沙盒的实现是技术难点。WebForge很可能采用了服务端拦截和响应复现技术。例如使用一个本地代理服务器当重放时浏览器发起请求代理服务器不是去访问真实的线上接口而是从轨迹文件中取出当时记录下的响应数据直接返回。这就完全屏蔽了网络波动和线上API变更的影响。无限衍生则是解决可扩展性问题的法宝。有了一个高质量的原始轨迹WebForge可以对其进行程序化变异自动生成大量新的、但同属一个任务范畴的测试用例。举个例子原始轨迹是“在亚马逊搜索‘无线鼠标’并购买第一个结果”。程序化变异可以内容变异把搜索关键词“无线鼠标”替换为“机械键盘”、“蓝牙耳机”同时利用大语言模型LLM或规则相应地修改轨迹中后续涉及商品标题、描述的断言点。结构变异模拟网站UI改版。比如把“加入购物车”按钮从页面右侧移到左侧或者把单列布局改成网格布局。这可以测试代理对页面布局变化的鲁棒性。交互逻辑变异引入干扰。比如在点击“结算”按钮前突然弹出一个“优惠券弹窗”测试代理是否能处理这种预期外的中断。通过这种方式从一个手工记录的真实任务轨迹可以自动化衍生出成百上千个测试用例极大地提升了基准测试的覆盖面和效率。3. 从理论到实践借鉴WebForge思想搭建自己的测试框架WebForge是一个学术研究项目提供了很好的范式。但对于我们一线开发者和测试工程师来说更关心的是如何将这种思想落地构建一个服务于具体业务的、高效的浏览器自动化测试或智能体评估框架。下面我将以“搭建一个用于测试电商购物车流程自动化脚本的评估框架”为例手把手拆解实现路径。这里我会重点用到Playwright和Pytest因为它们是目前最主流、最强大的组合之一。3.1 环境准备与核心工具选型为什么是PlaywrightPytest首先Playwright相比Selenium在速度、稳定性、功能丰富性如自动等待、网络拦截、移动端模拟上都有显著优势并且对现代Web框架React, Vue等的支持更好。它的录制功能playwright codegen虽然不能直接生成WebForge那种高保真轨迹但作为一个快速的“记录”起点非常有用。Pytest则是Python生态下最强大的测试框架其夹具fixture系统、参数化测试等功能非常适合用来构建结构化的测试套件和实现“重放”逻辑。第一步初始化项目并安装依赖# 创建项目目录 mkdir web-agent-benchmark cd web-agent-benchmark # 创建虚拟环境推荐 python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate # 安装核心依赖 pip install playwright pytest pytest-asyncio # 安装Playwright浏览器 playwright install chromium这里选择Chromium而非全套浏览器是为了在保证环境一致性的前提下提高测试速度。在基准测试中一致性远比浏览器多样性重要。3.2 实现“记录”阶段生成高保真轨迹在WebForge中记录是精细活。我们可以设计一个Recorder类利用Playwright的API来捕获关键信息。# recorder.py import asyncio import json from datetime import datetime from playwright.async_api import async_playwright class InteractionRecorder: def __init__(self): self.trace { metadata: {start_url: , created_at: , task_description: }, steps: [] # 记录每一步操作和页面状态 } self.current_step 0 async def start_recording(self, url, task_description): 启动浏览器并开始记录指定任务 self.trace[metadata][start_url] url self.trace[metadata][created_at] datetime.utcnow().isoformat() self.trace[metadata][task_description] task_description playwright await async_playwright().start() # 使用无头模式记录更稳定快速 browser await playwright.chromium.launch(headlessTrue) context await browser.new_context( viewport{width: 1920, height: 1080}, record_har_pathnetwork.har # 同时记录HAR文件用于网络重放 ) page await context.new_page() # 关键监听网络请求和DOM变化 page.on(request, lambda request: self._capture_request(request)) page.on(response, lambda response: self._capture_response(response)) # 这里需要注入脚本监听DOM变化简化起见我们主要依赖快照 await page.goto(url) await self._capture_page_snapshot(page, initial_state) return browser, context, page async def _capture_page_snapshot(self, page, step_name): 捕获页面关键状态快照 snapshot { step: step_name, index: self.current_step, timestamp: datetime.utcnow().isoformat(), url: page.url, # 获取核心区域的HTML或可访问性树而非全量HTML main_content_html: await page.locator(main).inner_html() if await page.locator(main).count() 0 else await page.content()[:5000], # 限制大小 screenshot: await page.screenshot(typejpeg, quality70), # 二进制数据存储时可Base64编码 } self.trace[steps].append(snapshot) self.current_step 1 def _capture_request(self, request): # 记录关键请求如API请求过滤掉图片、字体等静态资源 if any(api_keyword in request.url for api_keyword in [/api/, /graphql, ajax]): print(fRecorded request: {request.method} {request.url}) def _capture_response(self, response): # 关联记录关键响应 pass async def record_action(self, page, action_description, action_func, *args, **kwargs): 记录一个用户动作如点击、输入 # 执行动作前状态 await self._capture_page_snapshot(page, fbefore_{action_description}) # 执行动作 await action_func(*args, **kwargs) # 等待页面稳定可根据实际情况调整 await page.wait_for_load_state(networkidle) # 执行动作后状态 await self._capture_page_snapshot(page, fafter_{action_description}) def save_trace(self, filepathtrace.json): 保存轨迹文件 with open(filepath, w, encodingutf-8) as f: # 注意screenshot二进制数据需要Base64编码后再存入JSON import base64 trace_to_save self.trace.copy() for step in trace_to_save[steps]: if screenshot in step and step[screenshot]: step[screenshot] base64.b64encode(step[screenshot]).decode(utf-8) json.dump(trace_to_save, f, indent2, ensure_asciiFalse) print(fTrace saved to {filepath})使用这个记录器来录制一个“加入购物车”的任务# record_demo.py import asyncio from recorder import InteractionRecorder async def record_shopping_cart_flow(): recorder InteractionRecorder() browser, context, page await recorder.start_recording( https://demo.e-commerce.com, Search for laptop and add the first product to cart. ) try: # 1. 搜索商品 search_box page.locator(input[nameq]) await recorder.record_action(page, type_search, search_box.fill, laptop) await recorder.record_action(page, press_enter, search_box.press, Enter) # 2. 点击第一个商品 first_product page.locator(.product-item:first-child a).first await recorder.record_action(page, click_first_product, first_product.click) # 3. 加入购物车 add_to_cart_btn page.locator(button:has-text(Add to Cart)).first await recorder.record_action(page, click_add_to_cart, add_to_cart_btn.click) # 4. 验证购物车 cart_icon page.locator(#cart-icon) await recorder.record_action(page, view_cart, cart_icon.click) # 最终状态快照 await recorder._capture_page_snapshot(page, final_state) finally: await context.close() await browser.close() recorder.save_trace(shopping_cart_trace.json) asyncio.run(record_shopping_cart_flow())这个记录器生成的trace.json文件就包含了页面状态序列和动作上下文是我们评估的“标准答案”。3.3 实现“重放”与评估阶段构建沙盒化测试有了轨迹文件下一步是构建一个Pytest测试夹具用于重放环境并评估代理。# conftest.py import pytest import json import base64 from playwright.async_api import async_playwright, Page import asyncio pytest.fixture(scopesession) def event_loop(): 为异步测试创建事件循环 loop asyncio.get_event_loop_policy().new_event_loop() yield loop loop.close() pytest.fixture(scopefunction) async def trace_context(request): 加载轨迹文件并为每次测试提供独立的浏览器上下文 trace_path request.param # 通过参数化传入不同的轨迹文件 with open(trace_path, r, encodingutf-8) as f: trace_data json.load(f) playwright await async_playwright().start() browser await playwright.chromium.launch(headlessTrue) # 关键创建上下文时加载记录的网络HAR文件以实现网络重放 context await browser.new_context( viewport{width: 1920, height: 1080}, # 这里需要实现一个自定义路由根据trace_data中的请求记录返回响应 # 简化示例我们使用一个静态的、记录时的初始页面 ) # 注入初始状态将记录的第一个快照的HTML设置到页面中 initial_snapshot trace_data[steps][0] page await context.new_page() await page.route(**/*, lambda route: route.abort()) # 拦截所有请求模拟离线环境 await page.set_content(initial_snapshot[main_content_html]) await page.goto(trace_data[metadata][start_url]) # 设置URL但内容已加载 yield { page: page, trace: trace_data, context: context, browser: browser, playwright: playwright } # 清理 await context.close() await browser.close() await playwright.stop() # 评估函数 def evaluate_action(actual_action, expected_step_index, trace_data): 评估代理的实际动作是否符合轨迹中的预期。 这是一个简化的示例实际评估可能涉及视觉相似度、DOM元素匹配等。 expected_step trace_data[steps][expected_step_index] # 示例检查页面关键文本是否出现如“已加入购物车” # 实际中你需要更复杂的逻辑比如对比动作后的页面截图与预期快照的相似度 evaluation_result { step_index: expected_step_index, action_match: manual_check_required, # 需根据实际逻辑判定 state_similarity_score: None, # 可引入图像对比库计算分数 passed: False } return evaluation_result然后我们可以编写一个参数化的测试用例用不同的代理或同一代理的不同配置来跑同一个轨迹任务# test_agent_on_trace.py import pytest import asyncio # 假设我们有两个待测的自动化脚本代理 from my_agents import rule_based_agent, llm_based_agent # 参数化同时测试不同的代理和不同的轨迹 pytest.mark.parametrize(trace_context, [./traces/shopping_cart_trace.json], indirectTrue) pytest.mark.parametrize(agent, [rule_based_agent, llm_based_agent]) pytest.mark.asyncio async def test_agent_on_shopping_task(trace_context, agent): page trace_context[page] trace trace_context[trace] # 代理开始执行任务 # 这里agent.execute应该接受page对象和任务描述返回其执行的动作序列 task_description trace[metadata][task_description] actual_actions_log await agent.execute(page, task_description) # 评估将代理的动作序列与轨迹中的标准步骤进行比对 total_steps len(trace[steps]) # 我们假设轨迹中每两个状态快照之间是一个标准动作 evaluation_results [] for i in range(1, total_steps, 2): # 粗略比对实际逻辑更复杂 # 这里需要根据actual_actions_log和页面状态变化来评估 result evaluate_action(actual_actions_log.get(i-1), i, trace) evaluation_results.append(result) # 断言例如要求80%的关键步骤匹配 passed_steps sum(1 for r in evaluation_results if r[passed]) success_rate passed_steps / len(evaluation_results) assert success_rate 0.8, fAgent success rate ({success_rate:.2%}) below threshold 80%. print(fAgent {agent.__name__} passed with success rate {success_rate:.2%}.)3.4 实现“程序化变异”扩展测试用例这是体现可扩展性的关键。我们可以编写一个TraceMutator类基于原始轨迹生成新变体。# mutator.py import copy import random import json from faker import Faker # 用于生成假数据 class TraceMutator: def __init__(self, original_trace): self.trace copy.deepcopy(original_trace) self.fake Faker() def mutate_search_keyword(self, new_keyword): 变异搜索关键词 # 1. 找到包含搜索输入动作的步骤 for step in self.trace[steps]: if before_type_search in step.get(step, ): # 2. 修改该步骤快照中搜索框的HTML这里需要解析和修改HTML简化示意 # 假设我们记录的是输入后的状态这里需要更精细的DOM操作模拟 pass # 3. 修改任务描述 old_desc self.trace[metadata][task_description] # 简单替换更智能的做法可以用LLM重写描述 if laptop in old_desc: new_desc old_desc.replace(laptop, new_keyword) self.trace[metadata][task_description] new_desc return self def mutate_ui_layout(self, mutation_typeswap_button_position): 模拟UI布局变化 # 这是一个概念性实现。实际需要操作步骤快照中的HTML/CSS。 # 例如通过解析HTML找到“加入购物车”按钮的父容器修改其CSS样式如float, position # 或者交换两个主要UI组件的位置。 print(fApplying UI mutation: {mutation_type}) # 在实际中这里会调用一个HTML解析和修改库 return self def add_distractor_popup(self, popup_html): 在特定步骤插入干扰弹窗 # 选择一个步骤如点击“结算”前在其快照的HTML body末尾插入弹窗HTML target_step_index 5 # 示例索引 target_step self.trace[steps][target_step_index] # 拼接弹窗HTML target_step[main_content_html] popup_html return self def save_mutated_trace(self, filepath): with open(filepath, w, encodingutf-8) as f: json.dump(self.trace, f, indent2, ensure_asciiFalse) print(fMutated trace saved to {filepath}) # 使用示例 with open(./traces/shopping_cart_trace.json, r) as f: original json.load(f) mutator TraceMutator(original) # 生成10个变体 for i in range(10): new_keyword random.choice([wireless mouse, mechanical keyboard, bluetooth speaker]) mutator.mutate_search_keyword(new_keyword) # 随机决定是否添加UI变异或干扰 if random.random() 0.7: mutator.mutate_ui_layout() output_path f./traces/mutated/shopping_cart_variant_{i}.json mutator.save_mutated_trace(output_path) # 重置为原始轨迹以便进行下一次独立的变异 mutator TraceMutator(original)通过这种方式我们就将一个手工记录的轨迹扩展成了一个包含大量变异用例的测试集。在CI/CD流水线中可以自动运行所有变体测试全面评估代理的鲁棒性。4. 避坑指南与实战心得在将WebForge理念付诸实践的过程中我踩过不少坑也总结出一些能让框架更稳健、更高效的经验。4.1 轨迹记录的保真度与性能平衡最初尝试记录时我恨不得把每一次网络请求、每一个DOM节点的每一次属性变化都记下来。结果就是轨迹文件巨大动辄几百MB重放时加载缓慢甚至内存溢出。教训是记录要有选择性。网络请求只记录对页面状态有决定性影响的XHR/Fetch请求如API接口忽略图片、字体、CSS等静态资源。可以利用Playwright的route功能进行过滤。DOM快照不要保存完整的document.innerHTML。对于复杂的单页应用SPA这会导致文件臃肿。改为记录可访问性树Accessibility Tree或仅记录关键交互区域通过CSS选择器定位如#main, .product-list的HTML。这样既能保留语义信息又大幅减小体积。截图保存全屏截图作为视觉基准很重要但可以降低分辨率和质量如70% JPEG。甚至可以只截取“视口区域”或“变化区域”。4.2 网络请求的精准重放与“时间旅行”重放阶段最棘手的问题之一是如何完美复现记录时的网络状态。简单地使用记录的HAR文件通过Playwright的routeFromHAR重放有时会遇到问题比如请求顺序依赖、请求参数带有时间戳等。解决方案实现一个轻量级的本地Mock服务器。在记录阶段不仅保存请求和响应还记录下请求之间的相对时序和依赖关系。在重放阶段启动这个Mock服务器并让浏览器通过一个代理如--proxy-server将所有请求指向它。Mock服务器根据请求的URL和特征如请求体哈希返回记录的响应。对于带时间戳或随机数的请求需要实现请求的“规范化”匹配逻辑。“时间旅行”调试一个高级技巧是在重放时如果代理动作偏离了轨迹可以随时将页面状态“回滚”到轨迹中的任何一个历史快照点。这需要你在重放框架中维护一个页面状态栈。当评估失败时不是让整个测试用例失败而是回滚状态让代理重试或记录下这个分叉点这对于分析代理的失败原因极具价值。4.3 评估指标的设计超越简单的“通过/失败”不要只用一个二元的“任务是否完成”作为评估指标。对于智能体或复杂脚本我们需要更细粒度的评估。步骤完成度代理是否按正确顺序执行了所有关键步骤如先登录再搜索再添加。效率指标完成整个任务用了多少步动作次数总耗时是多少与最优路径轨迹的偏差有多大鲁棒性指标在面对变异用例如UI变化、弹窗干扰时成功率下降了多少哪些类型的变异最容易导致失败自然度指标针对AI代理代理的动作序列是否像真人操作例如是否在点击前有合理的悬停或等待输入速度是否均匀这可以通过与记录的人为轨迹进行序列比对来计算某种“行为相似度”。4.4 与现有CI/CD流程的集成这个框架的最终价值要体现在持续集成中。我的做法是容器化将整个测试环境包括浏览器、依赖、Mock服务器打包进Docker镜像。确保在任何CI Runner上环境完全一致。测试结果可视化不要只输出“PASSED/FAILED”。利用Pytest的插件如pytest-html生成详细的测试报告附上失败时的页面截图、DOM状态和代理动作日志。这能极大提升调试效率。性能基准在CI中不仅运行功能测试也运行性能基准测试。例如监控在N个并行任务下测试套件的平均执行时间和内存占用防止框架本身引入性能瓶颈。5. 面向未来从自动化测试到智能体评估的演进我们目前搭建的框架主要还是服务于确定性自动化脚本的评估和回归测试。但WebForge的野心显然更大——它旨在评估非确定性的AI智能体。要朝这个方向演进我们的框架还需要在以下几个关键点上进行强化第一从“动作匹配”到“意图实现”的评估转变。对于规则脚本我们可以严格比对点击了哪个按钮、输入了什么文本。但对于AI智能体它可能通过不同的路径达到相同的目的。比如要关闭一个弹窗脚本可能精准点击“X”按钮而AI智能体可能点击了弹窗外的遮罩层或者按了ESC键。我们的评估系统必须能理解“关闭弹窗”这个意图是否被实现而不是拘泥于具体的动作。这需要引入更高级的页面状态理解能力比如利用视觉模型VLM对比动作前后的页面截图判断干扰是否消失或者利用大语言模型LLM分析动作后的DOM语义判断目标状态是否达成。第二构建更丰富、更具挑战性的任务库。单一的电商购物流程远远不够。我们需要收集和记录涵盖不同领域、不同复杂度的真实用户任务轨迹形成一个基准任务库。例如信息聚合任务在旅游网站上对比三家不同航空公司的机票价格和时段。多步骤表单填写完成一个复杂的银行开户或保险申请流程。异常处理任务在操作过程中故意触发“库存不足”、“网络超时”等错误看代理如何应对。 这些轨迹将成为训练和评估AI智能体的宝贵数据集。第三引入人类反馈的循环。完全自动化的评估有其极限。对于一些模糊或创造性的任务如“为我策划一个周末活动方案”最终的好坏可能需要人类来判断。可以在框架中集成一个简单的反馈界面当自动化评估置信度较低时将测试案例和代理的执行录像提交给人工进行评分。这些人类评分数据反过来又可以用于优化自动评估模型。第四拥抱开源生态与标准化。WebForge本身是一个研究项目。我们可以关注其后续发展并尝试与现有的开源测试生态集成。例如考虑将生成的轨迹文件格式与pytest-bdd行为驱动开发的feature文件结合或者开发插件让我们的评估结果能输出为通用的基准测试格式如用于机器学习社区的JSON格式。标准化能让我们更容易地对比不同团队、不同方法的结果。构建这样一个框架绝非一日之功它更像是一个随着项目迭代而不断演进的“基础设施”。从确保一个按钮点击脚本的稳定到评估一个AI智能体在复杂Web环境中的生存能力其核心思想一脉相承将不可控的真实环境通过记录和程序化控制转化为一个既真实、又可复现、还可大规模测试的评估场。从这个角度看WebForge不仅是一个基准测试工具更为我们提供了一套应对Web自动化领域核心挑战的方法论。 
长河君 · 2026/8/22 3:58:41 · 阅读 1.2k WebForge破局浏览器代理基准测试：记录重放与程序化变异实践
1. 项目缘起浏览器代理基准测试的“不可能三角”如果你最近在折腾浏览器自动化测试或者研究基于大模型的Web智能体那你大概率听过一个词“基准测试”。听起来很高大上但说白了就是得有个公平的“考场”和一套标准的“考题”才能知道谁家的“学生”代理更厉害。然而这个“考场”的搭建在Web领域却一直是个老大难问题业内普遍认为存在一个“不可能三角”真实性、可复现性和可扩展性三者难以兼得。让我用大白话解释一下这个三角困境。真实性指的是测试环境要和真实用户访问的网站一模一样包括动态加载的内容、复杂的交互逻辑、甚至反爬虫机制。你总不能在“Hello World”页面上测出一个代理的“智能”吧可复现性意味着每次测试的结果必须稳定一致。今天跑分90明天因为网站改了个按钮位置或者服务器抽风跑分直接掉到60这种测试结果谁敢信可扩展性则要求这个测试框架能轻松地覆盖成千上万个不同的测试用例比如测试电商下单、社交发文、信息查询等不同任务并且成本可控。传统的做法往往是“三选二”。比如直接用Selenium或Playwright驱动真实浏览器去访问线上网站真实性拉满但可复现性极差——网站随时在变网络也不稳定。另一种思路是搭建一个本地的、静态的模拟网站环境可复现性好了但真实性又大打折扣代理学到的“经验”可能无法迁移到真实世界。至于可扩展性无论是维护海量真实网站的测试脚本还是构建逼真的模拟环境人力和算力成本都高得吓人。WebForge这个项目瞄准的就是打破这个“不可能三角”。它的核心思路不是去“模拟”一个网站而是去“记录”并“重放”一个真实的网站交互过程并在此基础上进行可控的“变异”和“扩展”。这就像不是去搭建一个假的城市来训练司机而是把真实城市的交通录像拿过来让AI司机在录像里“开车”并且我们可以随意修改录像里的红绿灯、行人位置创造出无数种新的驾驶考题。接下来我就结合当前热门的Playwright、Cursor等工具以及自动化测试框架的搭建经验来深度拆解WebForge是如何实现这一目标的以及我们如何借鉴其思想来构建自己的、更实用的浏览器代理测试环境。2. WebForge的核心架构记录、重放与程序化生成要理解WebForge如何破局我们得先钻进它的“引擎盖”下面看看。它的架构设计非常巧妙可以概括为“一个核心两个阶段无限衍生”。一个核心是浏览器交互轨迹的记录与抽象。WebForge不是简单地录屏它使用类似Playwright这样的现代化浏览器自动化框架在真实网站上执行一系列任务比如“在电商网站搜索商品并加入购物车”。在这个过程中它会以极高的粒度记录下一切每一次网络请求URL、方法、载荷、响应、每一个DOM节点的变化通过Mutation Observer、每一次用户交互点击、输入、滚动的精确坐标和目标元素。最终它生成的不是视频文件而是一个结构化的、包含完整页面状态序列的“轨迹文件”。这个文件就是那个被“定格”的真实世界快照。两个阶段指的是记录阶段和重放/评估阶段的彻底分离。这是保证可复现性的关键。在记录阶段工程师或标注人员像正常用户一样操作确保轨迹的质量和真实性。这个阶段不关心代理只关心把“标准答案”完美地录下来。到了重放阶段这个轨迹文件被加载到一个受控的、隔离的“沙盒”环境中。这个沙盒能完全复现记录时的网络响应和初始DOM状态。然后才把待测试的代理比如你的AI模型放进来让它基于当前页面状态去决策下一步动作。代理的每一个动作都会与轨迹中记录的“标准动作”进行比对和评估。注意这里沙盒的实现是技术难点。WebForge很可能采用了服务端拦截和响应复现技术。例如使用一个本地代理服务器当重放时浏览器发起请求代理服务器不是去访问真实的线上接口而是从轨迹文件中取出当时记录下的响应数据直接返回。这就完全屏蔽了网络波动和线上API变更的影响。无限衍生则是解决可扩展性问题的法宝。有了一个高质量的原始轨迹WebForge可以对其进行程序化变异自动生成大量新的、但同属一个任务范畴的测试用例。举个例子原始轨迹是“在亚马逊搜索‘无线鼠标’并购买第一个结果”。程序化变异可以内容变异把搜索关键词“无线鼠标”替换为“机械键盘”、“蓝牙耳机”同时利用大语言模型LLM或规则相应地修改轨迹中后续涉及商品标题、描述的断言点。结构变异模拟网站UI改版。比如把“加入购物车”按钮从页面右侧移到左侧或者把单列布局改成网格布局。这可以测试代理对页面布局变化的鲁棒性。交互逻辑变异引入干扰。比如在点击“结算”按钮前突然弹出一个“优惠券弹窗”测试代理是否能处理这种预期外的中断。通过这种方式从一个手工记录的真实任务轨迹可以自动化衍生出成百上千个测试用例极大地提升了基准测试的覆盖面和效率。3. 从理论到实践借鉴WebForge思想搭建自己的测试框架WebForge是一个学术研究项目提供了很好的范式。但对于我们一线开发者和测试工程师来说更关心的是如何将这种思想落地构建一个服务于具体业务的、高效的浏览器自动化测试或智能体评估框架。下面我将以“搭建一个用于测试电商购物车流程自动化脚本的评估框架”为例手把手拆解实现路径。这里我会重点用到Playwright和Pytest因为它们是目前最主流、最强大的组合之一。3.1 环境准备与核心工具选型为什么是PlaywrightPytest首先Playwright相比Selenium在速度、稳定性、功能丰富性如自动等待、网络拦截、移动端模拟上都有显著优势并且对现代Web框架React, Vue等的支持更好。它的录制功能playwright codegen虽然不能直接生成WebForge那种高保真轨迹但作为一个快速的“记录”起点非常有用。Pytest则是Python生态下最强大的测试框架其夹具fixture系统、参数化测试等功能非常适合用来构建结构化的测试套件和实现“重放”逻辑。第一步初始化项目并安装依赖# 创建项目目录 mkdir web-agent-benchmark cd web-agent-benchmark # 创建虚拟环境推荐 python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate # 安装核心依赖 pip install playwright pytest pytest-asyncio # 安装Playwright浏览器 playwright install chromium这里选择Chromium而非全套浏览器是为了在保证环境一致性的前提下提高测试速度。在基准测试中一致性远比浏览器多样性重要。3.2 实现“记录”阶段生成高保真轨迹在WebForge中记录是精细活。我们可以设计一个Recorder类利用Playwright的API来捕获关键信息。# recorder.py import asyncio import json from datetime import datetime from playwright.async_api import async_playwright class InteractionRecorder: def __init__(self): self.trace { metadata: {start_url: , created_at: , task_description: }, steps: [] # 记录每一步操作和页面状态 } self.current_step 0 async def start_recording(self, url, task_description): 启动浏览器并开始记录指定任务 self.trace[metadata][start_url] url self.trace[metadata][created_at] datetime.utcnow().isoformat() self.trace[metadata][task_description] task_description playwright await async_playwright().start() # 使用无头模式记录更稳定快速 browser await playwright.chromium.launch(headlessTrue) context await browser.new_context( viewport{width: 1920, height: 1080}, record_har_pathnetwork.har # 同时记录HAR文件用于网络重放 ) page await context.new_page() # 关键监听网络请求和DOM变化 page.on(request, lambda request: self._capture_request(request)) page.on(response, lambda response: self._capture_response(response)) # 这里需要注入脚本监听DOM变化简化起见我们主要依赖快照 await page.goto(url) await self._capture_page_snapshot(page, initial_state) return browser, context, page async def _capture_page_snapshot(self, page, step_name): 捕获页面关键状态快照 snapshot { step: step_name, index: self.current_step, timestamp: datetime.utcnow().isoformat(), url: page.url, # 获取核心区域的HTML或可访问性树而非全量HTML main_content_html: await page.locator(main).inner_html() if await page.locator(main).count() 0 else await page.content()[:5000], # 限制大小 screenshot: await page.screenshot(typejpeg, quality70), # 二进制数据存储时可Base64编码 } self.trace[steps].append(snapshot) self.current_step 1 def _capture_request(self, request): # 记录关键请求如API请求过滤掉图片、字体等静态资源 if any(api_keyword in request.url for api_keyword in [/api/, /graphql, ajax]): print(fRecorded request: {request.method} {request.url}) def _capture_response(self, response): # 关联记录关键响应 pass async def record_action(self, page, action_description, action_func, *args, **kwargs): 记录一个用户动作如点击、输入 # 执行动作前状态 await self._capture_page_snapshot(page, fbefore_{action_description}) # 执行动作 await action_func(*args, **kwargs) # 等待页面稳定可根据实际情况调整 await page.wait_for_load_state(networkidle) # 执行动作后状态 await self._capture_page_snapshot(page, fafter_{action_description}) def save_trace(self, filepathtrace.json): 保存轨迹文件 with open(filepath, w, encodingutf-8) as f: # 注意screenshot二进制数据需要Base64编码后再存入JSON import base64 trace_to_save self.trace.copy() for step in trace_to_save[steps]: if screenshot in step and step[screenshot]: step[screenshot] base64.b64encode(step[screenshot]).decode(utf-8) json.dump(trace_to_save, f, indent2, ensure_asciiFalse) print(fTrace saved to {filepath})使用这个记录器来录制一个“加入购物车”的任务# record_demo.py import asyncio from recorder import InteractionRecorder async def record_shopping_cart_flow(): recorder InteractionRecorder() browser, context, page await recorder.start_recording( https://demo.e-commerce.com, Search for laptop and add the first product to cart. ) try: # 1. 搜索商品 search_box page.locator(input[nameq]) await recorder.record_action(page, type_search, search_box.fill, laptop) await recorder.record_action(page, press_enter, search_box.press, Enter) # 2. 点击第一个商品 first_product page.locator(.product-item:first-child a).first await recorder.record_action(page, click_first_product, first_product.click) # 3. 加入购物车 add_to_cart_btn page.locator(button:has-text(Add to Cart)).first await recorder.record_action(page, click_add_to_cart, add_to_cart_btn.click) # 4. 验证购物车 cart_icon page.locator(#cart-icon) await recorder.record_action(page, view_cart, cart_icon.click) # 最终状态快照 await recorder._capture_page_snapshot(page, final_state) finally: await context.close() await browser.close() recorder.save_trace(shopping_cart_trace.json) asyncio.run(record_shopping_cart_flow())这个记录器生成的trace.json文件就包含了页面状态序列和动作上下文是我们评估的“标准答案”。3.3 实现“重放”与评估阶段构建沙盒化测试有了轨迹文件下一步是构建一个Pytest测试夹具用于重放环境并评估代理。# conftest.py import pytest import json import base64 from playwright.async_api import async_playwright, Page import asyncio pytest.fixture(scopesession) def event_loop(): 为异步测试创建事件循环 loop asyncio.get_event_loop_policy().new_event_loop() yield loop loop.close() pytest.fixture(scopefunction) async def trace_context(request): 加载轨迹文件并为每次测试提供独立的浏览器上下文 trace_path request.param # 通过参数化传入不同的轨迹文件 with open(trace_path, r, encodingutf-8) as f: trace_data json.load(f) playwright await async_playwright().start() browser await playwright.chromium.launch(headlessTrue) # 关键创建上下文时加载记录的网络HAR文件以实现网络重放 context await browser.new_context( viewport{width: 1920, height: 1080}, # 这里需要实现一个自定义路由根据trace_data中的请求记录返回响应 # 简化示例我们使用一个静态的、记录时的初始页面 ) # 注入初始状态将记录的第一个快照的HTML设置到页面中 initial_snapshot trace_data[steps][0] page await context.new_page() await page.route(**/*, lambda route: route.abort()) # 拦截所有请求模拟离线环境 await page.set_content(initial_snapshot[main_content_html]) await page.goto(trace_data[metadata][start_url]) # 设置URL但内容已加载 yield { page: page, trace: trace_data, context: context, browser: browser, playwright: playwright } # 清理 await context.close() await browser.close() await playwright.stop() # 评估函数 def evaluate_action(actual_action, expected_step_index, trace_data): 评估代理的实际动作是否符合轨迹中的预期。 这是一个简化的示例实际评估可能涉及视觉相似度、DOM元素匹配等。 expected_step trace_data[steps][expected_step_index] # 示例检查页面关键文本是否出现如“已加入购物车” # 实际中你需要更复杂的逻辑比如对比动作后的页面截图与预期快照的相似度 evaluation_result { step_index: expected_step_index, action_match: manual_check_required, # 需根据实际逻辑判定 state_similarity_score: None, # 可引入图像对比库计算分数 passed: False } return evaluation_result然后我们可以编写一个参数化的测试用例用不同的代理或同一代理的不同配置来跑同一个轨迹任务# test_agent_on_trace.py import pytest import asyncio # 假设我们有两个待测的自动化脚本代理 from my_agents import rule_based_agent, llm_based_agent # 参数化同时测试不同的代理和不同的轨迹 pytest.mark.parametrize(trace_context, [./traces/shopping_cart_trace.json], indirectTrue) pytest.mark.parametrize(agent, [rule_based_agent, llm_based_agent]) pytest.mark.asyncio async def test_agent_on_shopping_task(trace_context, agent): page trace_context[page] trace trace_context[trace] # 代理开始执行任务 # 这里agent.execute应该接受page对象和任务描述返回其执行的动作序列 task_description trace[metadata][task_description] actual_actions_log await agent.execute(page, task_description) # 评估将代理的动作序列与轨迹中的标准步骤进行比对 total_steps len(trace[steps]) # 我们假设轨迹中每两个状态快照之间是一个标准动作 evaluation_results [] for i in range(1, total_steps, 2): # 粗略比对实际逻辑更复杂 # 这里需要根据actual_actions_log和页面状态变化来评估 result evaluate_action(actual_actions_log.get(i-1), i, trace) evaluation_results.append(result) # 断言例如要求80%的关键步骤匹配 passed_steps sum(1 for r in evaluation_results if r[passed]) success_rate passed_steps / len(evaluation_results) assert success_rate 0.8, fAgent success rate ({success_rate:.2%}) below threshold 80%. print(fAgent {agent.__name__} passed with success rate {success_rate:.2%}.)3.4 实现“程序化变异”扩展测试用例这是体现可扩展性的关键。我们可以编写一个TraceMutator类基于原始轨迹生成新变体。# mutator.py import copy import random import json from faker import Faker # 用于生成假数据 class TraceMutator: def __init__(self, original_trace): self.trace copy.deepcopy(original_trace) self.fake Faker() def mutate_search_keyword(self, new_keyword): 变异搜索关键词 # 1. 找到包含搜索输入动作的步骤 for step in self.trace[steps]: if before_type_search in step.get(step, ): # 2. 修改该步骤快照中搜索框的HTML这里需要解析和修改HTML简化示意 # 假设我们记录的是输入后的状态这里需要更精细的DOM操作模拟 pass # 3. 修改任务描述 old_desc self.trace[metadata][task_description] # 简单替换更智能的做法可以用LLM重写描述 if laptop in old_desc: new_desc old_desc.replace(laptop, new_keyword) self.trace[metadata][task_description] new_desc return self def mutate_ui_layout(self, mutation_typeswap_button_position): 模拟UI布局变化 # 这是一个概念性实现。实际需要操作步骤快照中的HTML/CSS。 # 例如通过解析HTML找到“加入购物车”按钮的父容器修改其CSS样式如float, position # 或者交换两个主要UI组件的位置。 print(fApplying UI mutation: {mutation_type}) # 在实际中这里会调用一个HTML解析和修改库 return self def add_distractor_popup(self, popup_html): 在特定步骤插入干扰弹窗 # 选择一个步骤如点击“结算”前在其快照的HTML body末尾插入弹窗HTML target_step_index 5 # 示例索引 target_step self.trace[steps][target_step_index] # 拼接弹窗HTML target_step[main_content_html] popup_html return self def save_mutated_trace(self, filepath): with open(filepath, w, encodingutf-8) as f: json.dump(self.trace, f, indent2, ensure_asciiFalse) print(fMutated trace saved to {filepath}) # 使用示例 with open(./traces/shopping_cart_trace.json, r) as f: original json.load(f) mutator TraceMutator(original) # 生成10个变体 for i in range(10): new_keyword random.choice([wireless mouse, mechanical keyboard, bluetooth speaker]) mutator.mutate_search_keyword(new_keyword) # 随机决定是否添加UI变异或干扰 if random.random() 0.7: mutator.mutate_ui_layout() output_path f./traces/mutated/shopping_cart_variant_{i}.json mutator.save_mutated_trace(output_path) # 重置为原始轨迹以便进行下一次独立的变异 mutator TraceMutator(original)通过这种方式我们就将一个手工记录的轨迹扩展成了一个包含大量变异用例的测试集。在CI/CD流水线中可以自动运行所有变体测试全面评估代理的鲁棒性。4. 避坑指南与实战心得在将WebForge理念付诸实践的过程中我踩过不少坑也总结出一些能让框架更稳健、更高效的经验。4.1 轨迹记录的保真度与性能平衡最初尝试记录时我恨不得把每一次网络请求、每一个DOM节点的每一次属性变化都记下来。结果就是轨迹文件巨大动辄几百MB重放时加载缓慢甚至内存溢出。教训是记录要有选择性。网络请求只记录对页面状态有决定性影响的XHR/Fetch请求如API接口忽略图片、字体、CSS等静态资源。可以利用Playwright的route功能进行过滤。DOM快照不要保存完整的document.innerHTML。对于复杂的单页应用SPA这会导致文件臃肿。改为记录可访问性树Accessibility Tree或仅记录关键交互区域通过CSS选择器定位如#main, .product-list的HTML。这样既能保留语义信息又大幅减小体积。截图保存全屏截图作为视觉基准很重要但可以降低分辨率和质量如70% JPEG。甚至可以只截取“视口区域”或“变化区域”。4.2 网络请求的精准重放与“时间旅行”重放阶段最棘手的问题之一是如何完美复现记录时的网络状态。简单地使用记录的HAR文件通过Playwright的routeFromHAR重放有时会遇到问题比如请求顺序依赖、请求参数带有时间戳等。解决方案实现一个轻量级的本地Mock服务器。在记录阶段不仅保存请求和响应还记录下请求之间的相对时序和依赖关系。在重放阶段启动这个Mock服务器并让浏览器通过一个代理如--proxy-server将所有请求指向它。Mock服务器根据请求的URL和特征如请求体哈希返回记录的响应。对于带时间戳或随机数的请求需要实现请求的“规范化”匹配逻辑。“时间旅行”调试一个高级技巧是在重放时如果代理动作偏离了轨迹可以随时将页面状态“回滚”到轨迹中的任何一个历史快照点。这需要你在重放框架中维护一个页面状态栈。当评估失败时不是让整个测试用例失败而是回滚状态让代理重试或记录下这个分叉点这对于分析代理的失败原因极具价值。4.3 评估指标的设计超越简单的“通过/失败”不要只用一个二元的“任务是否完成”作为评估指标。对于智能体或复杂脚本我们需要更细粒度的评估。步骤完成度代理是否按正确顺序执行了所有关键步骤如先登录再搜索再添加。效率指标完成整个任务用了多少步动作次数总耗时是多少与最优路径轨迹的偏差有多大鲁棒性指标在面对变异用例如UI变化、弹窗干扰时成功率下降了多少哪些类型的变异最容易导致失败自然度指标针对AI代理代理的动作序列是否像真人操作例如是否在点击前有合理的悬停或等待输入速度是否均匀这可以通过与记录的人为轨迹进行序列比对来计算某种“行为相似度”。4.4 与现有CI/CD流程的集成这个框架的最终价值要体现在持续集成中。我的做法是容器化将整个测试环境包括浏览器、依赖、Mock服务器打包进Docker镜像。确保在任何CI Runner上环境完全一致。测试结果可视化不要只输出“PASSED/FAILED”。利用Pytest的插件如pytest-html生成详细的测试报告附上失败时的页面截图、DOM状态和代理动作日志。这能极大提升调试效率。性能基准在CI中不仅运行功能测试也运行性能基准测试。例如监控在N个并行任务下测试套件的平均执行时间和内存占用防止框架本身引入性能瓶颈。5. 面向未来从自动化测试到智能体评估的演进我们目前搭建的框架主要还是服务于确定性自动化脚本的评估和回归测试。但WebForge的野心显然更大——它旨在评估非确定性的AI智能体。要朝这个方向演进我们的框架还需要在以下几个关键点上进行强化第一从“动作匹配”到“意图实现”的评估转变。对于规则脚本我们可以严格比对点击了哪个按钮、输入了什么文本。但对于AI智能体它可能通过不同的路径达到相同的目的。比如要关闭一个弹窗脚本可能精准点击“X”按钮而AI智能体可能点击了弹窗外的遮罩层或者按了ESC键。我们的评估系统必须能理解“关闭弹窗”这个意图是否被实现而不是拘泥于具体的动作。这需要引入更高级的页面状态理解能力比如利用视觉模型VLM对比动作前后的页面截图判断干扰是否消失或者利用大语言模型LLM分析动作后的DOM语义判断目标状态是否达成。第二构建更丰富、更具挑战性的任务库。单一的电商购物流程远远不够。我们需要收集和记录涵盖不同领域、不同复杂度的真实用户任务轨迹形成一个基准任务库。例如信息聚合任务在旅游网站上对比三家不同航空公司的机票价格和时段。多步骤表单填写完成一个复杂的银行开户或保险申请流程。异常处理任务在操作过程中故意触发“库存不足”、“网络超时”等错误看代理如何应对。 这些轨迹将成为训练和评估AI智能体的宝贵数据集。第三引入人类反馈的循环。完全自动化的评估有其极限。对于一些模糊或创造性的任务如“为我策划一个周末活动方案”最终的好坏可能需要人类来判断。可以在框架中集成一个简单的反馈界面当自动化评估置信度较低时将测试案例和代理的执行录像提交给人工进行评分。这些人类评分数据反过来又可以用于优化自动评估模型。第四拥抱开源生态与标准化。WebForge本身是一个研究项目。我们可以关注其后续发展并尝试与现有的开源测试生态集成。例如考虑将生成的轨迹文件格式与pytest-bdd行为驱动开发的feature文件结合或者开发插件让我们的评估结果能输出为通用的基准测试格式如用于机器学习社区的JSON格式。标准化能让我们更容易地对比不同团队、不同方法的结果。构建这样一个框架绝非一日之功它更像是一个随着项目迭代而不断演进的“基础设施”。从确保一个按钮点击脚本的稳定到评估一个AI智能体在复杂Web环境中的生存能力其核心思想一脉相承将不可控的真实环境通过记录和程序化控制转化为一个既真实、又可复现、还可大规模测试的评估场。从这个角度看WebForge不仅是一个基准测试工具更为我们提供了一套应对Web自动化领域核心挑战的方法论。