1. 项目概述为什么我们需要一个“接地气”的用户模拟器如果你在AI智能体Agent这个圈子里待过一段时间肯定会发现一个挺有意思的现象大家花在“炼丹”训练模型和“搭台子”设计架构上的精力可能远不如花在“怎么证明我的Agent更牛”上的多。这就是评测Benchmarking的现状。我们有一堆像HotPotQA、WebShop、ALFWorld这样的标准测试集Agent在这些精心设计的虚拟迷宫里跑得飞快分数刷得老高。但当你兴冲冲地把这个Agent丢到一个真实的电商网站、一个复杂的SaaS后台或者哪怕只是一个稍微有点反人类设计的政府办事网站时它很可能瞬间就“懵了”——找不到按钮、看不懂验证码、理解不了那些充满歧义和口语化的用户指令。这就是所谓的“现实鸿沟”Reality Gap。实验室里的测试环境太干净、太理想了而真实世界是混乱、模糊且充满不确定性的。为了解决这个问题我们团队动手搞了RealUserSim。这个项目的核心目标不是再造一个更难的虚拟迷宫而是想办法在实验室里尽可能真实地“模拟”出一个人类用户来跟Agent互动。我们管这叫“接地的用户模拟”Grounded User Simulation。这里的“接地”指的是模拟的行为必须根植于真实世界的交互逻辑、视觉界面和任务流程而不是凭空想象。简单说RealUserSim想干的事就是给Agent评测“注入现实”。它适合所有正在开发或研究任务导向型AI智能体比如网页自动化助手、桌面软件操作机器人、多模态交互Agent的工程师和研究员。通过它你可以在产品上线前就用接近真实用户的交互方式去“拷问”你的Agent提前发现它在理解、决策和执行环节的薄弱点。这比等到真实用户投诉或者AB测试数据惨不忍睹时再补救成本要低得多。2. 核心设计思路从“规则脚本”到“行为仿真”的范式转变传统的Agent评测大多采用“规则脚本”驱动。比如测试一个购物Agent脚本会写死“第一步搜索‘无线蓝牙耳机’第二步点击第一个商品第三步加入购物车”。这种方法的优点是可控、可重复但缺点也极其明显它假设用户行为是确定、线性且符合开发者预期的。真实用户会这么听话吗他们可能会打错字“无线兰牙耳机”、可能会中途改变主意看了耳机又去瞄一眼手机、可能会被页面上的弹窗广告吸引走、也可能因为页面加载慢而重复点击。RealUserSim的设计思路是彻底抛弃这种“上帝视角”的脚本转向“行为仿真”。我们不再直接给Agent发送精确的指令序列而是模拟一个具有认知局限、行为偏好和随机性的“虚拟用户”让它在一个高度仿真的环境比如一个真实的浏览器渲染出的网页中产生行为这些行为再转化为给Agent的观察和指令。2.1 仿真内核的三层建模为了实现这一点我们构建了一个分层的仿真内核第一层认知与意图模型。虚拟用户不是全知全能的。它有一个“任务目标”例如“为公司采购一批性价比高的办公椅”但这个目标在初始时可能是模糊的。它还有一个知识库但这个知识库可能不完整不知道某个品牌、有偏见认为某品牌质量不好或过时记得某个老型号。它的意图会在交互中动态演变。比如一开始想买“办公椅”浏览后发现“人体工学椅”更合适目标就发生了转移。我们采用了一个基于大语言模型LLM的轻量级决策模块来驱动这一层为虚拟用户注入“常识”和“个性”。第二层感知与交互模型。虚拟用户如何“看”界面我们不是直接给Agent提供结构化的HTML DOM树或完美的屏幕坐标而是为虚拟用户模拟了近似人类的视觉感知。这包括视觉焦点模拟视线不会均匀分布会首先被大图、鲜艳按钮、动态区域吸引。不完全信息虚拟用户可能“看不到”折叠起来的内容或者因为页面渲染问题漏掉某个元素。交互噪声点击不一定精准落在元素中心可能有微小偏移滚动可能过快或过慢在输入框打字时可能会打错、删除、犹豫。第三层环境与状态模型。这是“接地”Grounded的关键。虚拟用户不是在与一个抽象的API交互而是在一个尽可能真实的环境里。我们使用无头浏览器如Puppeteer、Playwright加载真实的网站捕获真实的像素渲染结果和DOM状态。环境状态会随着交互动态变化点击后页面跳转、异步加载内容出现、弹窗弹出、网络延迟导致加载圈转个不停。虚拟用户的每一个动作都基于当前时刻它所“感知”到的环境状态。这三层模型共同作用使得虚拟用户的行为轨迹不再是预设的而是涌现出来的。每一次测试运行即使任务目标相同虚拟用户的具体操作路径也可能不同因为它可能会遇到不同的网络状况、页面布局A/B测试版本或者它自己“临时起意”探索了别的选项。这种不可预测性正是对Agent鲁棒性的最佳考验。2.2 与Agent的交互协议RealUserSim 作为评测平台其与受测Agent的交互遵循一个清晰的协议环境初始化RealUserSim 启动一个真实浏览器实例导航到目标网站如电商首页并将初始的屏幕截图或可访问性树以及虚拟用户的“初始模糊指令”如“我想买张椅子”发送给Agent。Agent观察与决策Agent 分析当前界面和指令决定要执行的动作如点击某个位置、输入文字、滚动等并将这个动作返回给RealUserSim。环境执行与状态更新RealUserSim 在浏览器中执行这个动作并引入模拟的交互噪声如点击偏移。随后等待页面状态稳定处理完网络请求、JS动态渲染捕获新的环境状态。用户模拟器响应此时RealUserSim内部的“虚拟用户”开始工作。它基于新的环境状态、自身的历史记忆和任务目标生成一个“用户反馈”。这个反馈可能是自然语言指令“这个颜色我不喜欢看看黑色的。”非语言反馈长时间停留在某个区域模拟犹豫。任务成功/失败信号如果虚拟用户认为目标已达成或已不可能达成。循环将更新后的环境状态和虚拟用户的反馈一并作为下一轮的输入发送给Agent。如此循环直至任务终止成功、失败或超时。这个协议的关键在于Agent接收到的永远是“带噪的观察”和“可能模糊、可能变化的指令”这与真实人机交互场景高度一致。3. 核心模块实现与技术选型解析把设计思路落地需要拆解成几个核心模块来构建。这里我分享一下我们的技术选型和背后的考量这些都是踩过坑之后总结的经验。3.1 环境仿真引擎为什么是Playwright我们需要一个能无头运行、稳定控制、且能高度还原真实浏览器环境包括复杂的JavaScript和CSS渲染的工具。常见的候选有Selenium、Puppeteer和Playwright。Selenium老牌工具支持语言多但架构相对陈旧对现代Web应用尤其是大量异步加载和单页应用的支持有时不够稳定且执行速度较慢。Puppeteer由Chrome团队开发对Chromium系浏览器的控制力最强API现代。但它主要绑定Chrome。Playwright由微软开发支持Chromium、Firefox和WebKit三大浏览器引擎。这是我们最终的选择。选择Playwright的核心理由跨浏览器一致性评测Agent不能只针对Chrome优化。真实用户会用各种浏览器。Playwright能让我们用同一套脚本在三大引擎上测试Agent的兼容性这能暴露出很多基于DOM解析或视觉定位的Agent的潜在问题。自动等待与稳定性Playwright内置了智能等待机制能自动等待元素可交互、网络请求完成大大减少了因页面加载时序问题导致的测试脚本脆弱性。在长期运行的自动化评测中稳定性就是生命线。丰富的设备模拟可以轻松模拟手机、平板、不同屏幕尺寸下的交互这对于测试移动端适配的Agent至关重要。强大的录制与调试工具Playwright Test提供了出色的调试和追踪功能当Agent行为异常时我们可以快速录制下整个交互过程回放查看每一步的屏幕截图和DOM快照极大提升了排查效率。实现要点 我们封装了一个GroundedEnvironment类内部维护一个Playwright浏览器上下文Context。每个评测任务在一个独立的Context中运行隔离cookie、localStorage等状态。我们不仅捕获页面截图用于视觉型Agent也通过Playwright API获取完整的DOM序列化信息、可访问性树Accessibility Tree以及所有网络请求的日志。后者对于分析Agent为何失败比如是否调用了错误的API接口非常有帮助。3.2 虚拟用户大脑LLM的轻量化与可控化集成用大模型来驱动虚拟用户的“思考”是自然的想法但直接调用GPT-4这类通用大模型进行每一步决策成本高昂且延迟高更关键的是不可控、不可重复——同样的初始条件大模型可能给出截然不同的行为这不利于科学评测。我们的策略是“分层控制轻量微调”高层任务规划器使用一个经过特定任务领域如电商购物、旅游预订微调的中等规模模型如7B-13B参数的模型。它的输入是任务目标、当前页面内容的文本摘要从DOM和截图中提取、交互历史。它的输出是高层意图例如“比较商品A和商品B的价格与评价”、“寻找筛选功能以缩小范围”、“放弃当前商品重新搜索”。这个规划不需要每一步都调用只在任务阶段转换时触发。中层动作生成器这是一个规则与模型结合的部分。对于规划器输出的意图我们有一套“动作模板”库。例如意图“比较商品A和商品B”对应的模板可能是“提取商品A的[价格][评分]信息提取商品B的[价格][评分]信息将两者并列呈现”。这个模板会被一个更小、更快的模型或甚至是用传统NLP方法实例化结合当前页面具体信息生成具体的、可执行的动作描述如“点击商品A的详情链接”。底层指令与反馈生成虚拟用户需要把它的“内心活动”以自然语言形式告诉Agent。这里我们使用一个经过指令微调的小模型专门负责将动作描述和当前观察转化为符合虚拟用户“人设”如“价格敏感型用户”、“注重品质的用户”的自然语言反馈。例如动作是“滚动到差评区”生成的反馈可能是“我想看看大家最不满意的地方是什么。”这种架构既利用了LLM的语义理解和生成能力又通过规则和分层设计控制了其随机性保证了评测的可重复性同时大幅降低了单次交互的成本和延迟。3.3 观察空间构建多模态信息的融合Agent如何“看”世界我们为Agent提供了多层次的观察空间Agent可以根据自身架构选择使用哪一种或哪几种的组合原始视觉Raw Pixels完整的屏幕截图。这是最丰富但也最冗余的信息适合端到端的视觉-语言模型VLM类Agent直接处理。简化视觉Simplified Vision对截图进行预处理如通过目标检测框出所有可交互元素按钮、输入框、链接并附上类别标签。这降低了视觉处理的复杂度。DOM树与可访问性树将网页的结构化信息提供给Agent。这对于基于HTML解析的Agent是核心输入。我们特别重视可访问性树因为它包含了屏幕阅读器所“看到”的信息通常更简洁、更语义化。多模态摘要这是我们的一个创新点。我们使用一个轻量的VLM实时分析当前截图生成一个文本摘要描述“页面上有什么核心焦点是什么”。例如“当前页面是一个商品列表页展示了10个办公椅商品。顶部有搜索栏和价格筛选器。第三个商品正在促销有一个红色的折扣标签。” 这个摘要可以作为纯文本Agent的快速上下文结合DOM信息使其具备一定的“视觉常识”。注意提供多种观察空间并不意味着Agent会更强大。恰恰相反这暴露了不同类型Agent的弱点。一个只依赖DOM的Agent在面对大量Canvas或SVG绘制的界面时可能完全失效而一个只依赖视觉的Agent可能在处理密密麻麻的表格数据时效率低下。RealUserSim的评测报告会详细分析Agent在不同观察模式下的表现。3.4 评测指标设计超越“任务完成率”如果只关心任务最终是否完成成功/失败那损失了99%的价值。我们设计了一套多维度的评测指标指标类别具体指标说明与意义效率指标任务完成步数完成相同任务所需的交互步骤。步数越少通常意味着Agent越高效。任务完成时间从开始到结束的墙上时钟时间。综合反映了Agent决策速度和环境响应速度。路径最优度将Agent的操作路径与专家标注的最优路径或虚拟用户规划的理想路径进行比较计算编辑距离或其他相似度。鲁棒性指标异常恢复能力故意在环境中注入噪声如元素加载延迟、意外弹窗记录Agent能否识别并正确处理。指令模糊容忍度虚拟用户给出模糊或歧义指令时Agent通过主动询问或合理推测成功推进任务的比率。跨网站/跨任务泛化能力在一个网站如亚马逊上训练的Agent在另一个相似网站如京东上执行同类任务的表现。人机协作指标指令遵从度Agent的动作是否精确符合用户的最新指令。主动澄清频率当信息不足时Agent是否会主动、清晰地提出问题以澄清用户意图频率和提问质量都被记录。解释性Agent在关键决策点如选择某个商品是否能提供简短的理由可选项。这套指标能让我们像“体检”一样全方位评估一个Agent的健康状况。一个可能快速完成任务但频繁误解用户意图的Agent和一个速度稍慢但沟通顺畅、总能做出合理选择的Agent后者在实际应用中的用户体验可能要好得多。4. 实战搭建并运行一个RealUserSim评测任务理论说了这么多我们来点实际的。假设我们现在要评测一个“电商比价助手Agent”任务目标是“在京东上找到一款价格在500元以下、好评率高于95%的无线鼠标”。4.1 环境准备与配置首先你需要安装RealUserSim的核心库和依赖。我们提供了PyPI包和Docker镜像两种方式。方式一使用PyPI安装适合快速上手# 创建并激活虚拟环境推荐 python -m venv realsim_env source realsim_env/bin/activate # Linux/Mac # realsim_env\Scripts\activate # Windows # 安装RealUserSim核心包它会自动安装Playwright等核心依赖 pip install realusersim # 安装Playwright所需的浏览器内核 playwright install chromium firefox webkit方式二使用Docker适合生产环境或确保环境一致# 拉取官方镜像 docker pull realusersim/core:latest # 运行一个包含所有依赖的容器 docker run -it --rm -v $(pwd)/workspace:/workspace realusersim/core:latest /bin/bash接下来编写一个任务配置文件task_config.yaml。这是RealUserSim的核心它定义了虚拟用户、环境和任务。# task_config.yaml environment: name: jd_shopping type: web start_url: https://www.jd.com viewport: { width: 1280, height: 720 } browser: chromium # 可选 chromium, firefox, webkit user_simulator: profile: price_sensitive_shopper # 预定义的用户画像价格敏感型购物者 cognitive_model: llama3.1:8b # 使用的认知模型端点 instruction_generator: mistral:7b # 使用的指令生成模型端点 # 可以覆盖默认参数如增加犹豫概率 parameters: hesitation_probability: 0.1 typo_probability: 0.05 task: id: find_cheap_wireless_mouse goal: 在京东上找到并选择一款价格低于500元、好评率高于95%的无线鼠标。 success_criteria: - 成功进入一个符合条件的商品详情页 - 页面显示价格500 - 页面显示好评率95% max_steps: 50 # 最大交互步数防止死循环 agent: # 这里定义你的Agent如何被调用。可以是本地函数、HTTP接口或命令行。 type: http endpoint: http://localhost:8000/agent/action # 定义传递给Agent的观察空间格式 observation_space: [screenshot, dom_summary, accessibility_tree]4.2 编写你的第一个评测AgentRealUserSim通过HTTP API与你的Agent通信。你需要搭建一个简单的Web服务来接收观察、返回动作。下面是一个使用FastAPI的极简示例# my_agent.py from fastapi import FastAPI, Request from pydantic import BaseModel import httpx from PIL import Image import io import base64 app FastAPI() class AgentObservation(BaseModel): screenshot: str # base64编码的图片 dom_summary: str accessibility_tree: dict user_instruction: str step: int class AgentAction(BaseModel): action_type: str # 如 click, type, scroll, say parameters: dict # 如 {x: 100, y: 200} 或 {text: 无线鼠标} app.post(/agent/action) async def get_agent_action(obs: AgentObservation): 这里是你的Agent大脑。 根据观察obs决定下一步动作。 这是一个非常简单的启发式示例真实Agent会复杂得多。 # 1. 解析用户指令 instruction obs.user_instruction.lower() # 2. 简单的逻辑如果是初始指令或包含“搜索”则尝试在搜索框输入 if obs.step 0 or 搜索 in instruction or 找 in instruction: # 假设我们通过某种方式如CV或DOM分析定位到了搜索框的坐标 # 这里为了示例我们硬编码一个大概位置实际中需要动态分析 return AgentAction( action_typetype, parameters{text: 无线鼠标 500元以内 好评率95%以上, element_selector: #key} # 假设京东搜索框id是#key ) # 3. 如果页面标题或摘要显示是列表页尝试点击第一个符合条件的商品 if 列表 in obs.dom_summary or 商品列表 in obs.dom_summary: # 同样这里需要解析DOM或截图来精确定位商品元素 # 我们假设找到了一个商品链接 return AgentAction( action_typeclick, parameters{element_selector: .gl-item:nth-child(1) a} # 示例选择器 ) # 4. 默认情况滚动一下看看更多内容 return AgentAction( action_typescroll, parameters{delta_y: 300} )这个Agent非常简陋仅用于演示协议。一个真正的Agent可能会集成视觉模型来分析screenshot或用LLM来理解dom_summary和accessibility_tree做出更智能的决策。4.3 启动评测并分析结果首先启动你的Agent服务uvicorn my_agent:app --host 0.0.0.0 --port 8000然后使用RealUserSim命令行工具启动评测realsim evaluate --config task_config.yaml --output-dir ./results评测过程会在终端实时打印日志。完成后在./results目录下你会找到trajectory.jsonl每一步的详细记录包括观察、动作、环境状态。metrics.json计算出的各项评测指标。screenshots/每一步的屏幕截图。report.html一个可视化的HTML报告可以像看录像一样回放Agent的整个操作过程并高亮显示关键指标。分析报告时要重点关注以下几点失败步骤的截图Agent在哪一步卡住了页面当时是什么样子是没找到元素还是找到了但执行了错误操作用户指令与Agent动作的对应关系Agent是否准确理解了用户的每一次反馈有没有出现“答非所问”或“过度操作”效率分析Agent的搜索路径是否迂回有没有重复操作是否错过了页面上的高效筛选工具鲁棒性检查报告中是否有“异常注入”测试的结果Agent面对弹窗、加载失败时表现如何5. 避坑指南与进阶技巧在实际开发和部署RealUserSim进行大规模评测的过程中我们积累了不少血泪教训。这里分享几个关键的注意事项和进阶技巧。5.1 虚拟用户画像的精细打磨虚拟用户的“人设”不是摆设它直接影响评测的严苛度和针对性。不要只用一种用户至少定义3-5种典型用户画像。例如目标明确型指令清晰路径直接。犹豫不决型频繁对比来回浏览容易分心。新手小白型不熟悉界面可能产生错误操作如误点广告。暴躁老哥型操作快没耐心如果页面反应慢会频繁刷新或重复点击。如何定义画像除了在配置文件中设置参数如hesitation_probability更关键的是在“认知模型”的提示词Prompt中注入人格。例如给“价格敏感型用户”的提示词中加入“你非常关注价格和促销信息对‘满减’、‘折扣’、‘秒杀’等词汇敏感愿意为了更低价格花费更多时间筛选。”动态画像切换一个真实的用户其行为模式也可能随着任务进展而变化。可以设计规则让虚拟用户在任务中期如比价后从“目标明确型”切换到“犹豫不决型”以测试Agent的动态适应能力。5.2 环境噪声的真实性模拟“接地气”的关键在于环境噪声。我们模拟的噪声主要包括网络延迟与波动不要用恒定的延迟。使用一个符合真实世界分布如泊松分布的延迟模型并随机插入短暂的“网络卡顿”高延迟甚至“请求失败”。页面渲染差异同一网站在不同时间、不同地区其A/B测试版本、广告内容、推荐商品都不同。我们通过以下方式模拟使用代理IP池让评测任务从不同地理位置的IP发起。在页面加载后随机执行一些轻微的DOM修改通过Playwright脚本模拟CDN未完全加载或浏览器插件导致的页面微调。交互物理噪声点击偏移不要总是点击元素中心。按照二维高斯分布在元素区域内随机生成点击坐标。滚动惯性模拟人类的滚动不是匀速的而是有加速和减速的过程。输入错误与修正在输入文本时有概率插入错别字并在短暂停顿后“修正”它。重要提示噪声的引入必须是可配置和可度量的。在评测报告中需要明确标出哪些步骤注入了何种噪声以及Agent的反应。这有助于区分是Agent的能力问题还是极端环境导致的问题。5.3 评测任务设计的艺术设计一个好的评测任务比搭建平台本身更需要洞察力。从真实用户日志中挖掘如果你有产品的真实用户操作日志那是金矿。分析其中失败、迂回、中断的会话将其抽象为评测任务。例如你发现很多用户在办理某个业务时总是在第三步的某个复选框上困惑就可以把这个场景设计成任务。构建任务阶梯不要一上来就设计极其复杂的任务。应该构建一个从易到难的任务阶梯L1 基础导航在已知结构的页面上完成简单操作如点击首页的“登录”按钮。L2 信息检索在列表页中根据简单条件找到目标如找到“销量最高”的商品。L3 多步表单填写完成一个需要输入多项信息的表单。L4 模糊目标探索目标不明确需要与虚拟用户多轮对话澄清如“我想买个礼物送给我爱打游戏的男朋友预算1000左右”。L5 异常处理任务中预设障碍如中途弹出验证码、关键信息加载失败。设计“陷阱”主动在任务路径上设置一些合理但容易出错的“陷阱”。例如在比价任务中放置一个价格极低但运费很高的商品看Agent是只看单价还是能计算总价。5.4 大规模评测的性能与成本优化当你要对成百上千个任务或Agent变体进行评测时性能和成本成为瓶颈。并行化执行RealUserSim支持分布式任务队列如Celery Redis。每个评测任务在一个独立的Docker容器中运行使用独立的浏览器实例确保完全隔离。浏览器实例复用对于短任务序列可以复用浏览器实例但要注意状态清理清除cookies、localStorage避免任务间污染。LLM调用优化缓存对相同的或相似的页面观察和用户指令其对应的虚拟用户决策和反馈很可能是相同的。建立缓存层可以节省大量LLM调用。小模型优先在虚拟用户的中层动作生成和底层反馈生成环节优先使用7B甚至更小的模型它们速度更快成本更低且经过精调后效果足够好。异步与非阻塞Agent的决策和虚拟用户的“思考”可以异步进行利用等待网络响应的空闲时间。结果聚合与分析自动化不要手动看每一个报告。编写脚本自动从metrics.json中提取关键指标生成对比图表和排行榜。重点关注Agent的“短板指标”即那些得分普遍偏低或方差极大的指标它们指明了最需要改进的方向。RealUserSim不是一个一劳永逸的工具而是一个需要你持续喂养“真实场景”和“深刻洞察”的生态系统。它最大的价值在于迫使你和你的团队以用户的视角去审视Agent的每一个决策去感受那些在纯净实验室中永远无法体会到的、来自真实世界的混乱与挑战。开始用它来“折磨”你的Agent吧每一次测试失败都是让它变得更像人类、更值得信赖的一步。