判断“智能体能不能操作计算机”最忌讳只看演示视频。演示视频里的鼠标移动再流畅也只能证明一个受控环境下的单次结果真正能支撑结论的是把任务、动作、观察、中间状态和最终结果都保存下来的操作数据。Computer Use 类智能体要像人一样读屏幕、找元素、点按钮、填表单、翻页面每一步都会在操作系统和浏览器里留下痕迹这些痕迹就是评估它的数据基础。本文从数据视角讨论同一个问题当我们说“Weve Got the Data”时这份数据应该包含什么、怎么采集、怎么统计以及它能回答和不能回答什么。1. 先拆清楚智能体“用计算机”到底在测什么1.1 三种常见的操作路径Computer Use 类智能体也叫 GUI Agent、操作型智能体在公开评测和工程实现里通常走三条技术路径。路径智能体看到什么智能体怎么操作数据采集重点视觉路径屏幕截图像素输出坐标点击、拖拽、键盘输入截图、坐标、动作前后帧差异语义路径DOM 或可访问性树选择元素并调用点击、输入、滚动可访问性树、选择器、动作参数API 路径操作系统 UI 自动化接口通过系统级接口发送动作系统事件、窗口句柄、控件树实际项目里更多是混合路径视觉模型负责理解界面语义结构负责精确定位动作生成阶段再把两者结合。这里的“计算机”既包括桌面系统也包括浏览器和移动设备不同载体需要采集的数据不一样。浏览器环境最容易落地因为 DOM、URL、截图都能稳定获取桌面应用则要依赖操作系统提供的辅助功能接口移动端还要处理屏幕旋转、虚拟键盘、系统弹窗等问题。数据采集时必须覆盖“智能体实际依赖的信号”。如果模型主要靠截图理解界面评测数据里却没有截图后续复现就会缺关键上下文。1.2 能力分层感知、决策、执行、校验要判断“能不能用计算机”只记录最终成功或失败不够还要看失败发生在哪一层。常见分层如下。感知层从截图或 DOM 中识别按钮、输入框、弹窗、页面状态。决策层根据任务目标选择下一步动作处理歧义、异常和多步规划。执行层把决策转成可靠动作包括坐标偏移、元素不可点击、页面未加载完等执行问题。校验层执行后检查页面状态是否符合预期决定继续、回退还是停止。分层价值在于数据不仅要回答“做没做成”还要能回答“卡在哪一层”。一次点击没有生效可能是感知把按钮识别错了可能是决策选错了元素也可能是执行时元素被遮挡或被 iframe 拦截。同一份轨迹里截图、动作、页面状态三类数据放到一起才能定位层级。因此轨迹记录不是简单的“动作日志”而是每一层留下的可观测信号。1.3 为什么“有没有数据”决定结论可信度“Can Agents Use a Computer Yet”这类问题的难点是答案高度依赖测试样本。同一个模型在 20 个任务上成功 18 个和在 2000 个任务上成功 60%听上去是两种结论后者才更有统计意义。数据的作用体现在三方面。第一把“感觉能用”变成“在定义好的任务集合上达到某个指标”。第二把“成功案例”背后的偶然因素暴露出来比如环境是否重置、页面是否稳定、是否允许试错。第三让不同智能体的结果可横向对比而不是各说各话。同时要清醒有数据不等于结论无偏。任务难度分布、环境复杂度、允许尝试次数、人工标注是否一致都会影响最终结论。所以后面的每个环节都要强调“记录口径”只有口径统一数据才有资格回答问题。2. 评测数据的三件套任务、轨迹、标注2.1 任务记录目标、起点、成功标准、终止条件一条任务不能只写一句话。至少要包含任务 ID、指令、起始环境、成功标准、最大步数、超时时间、运行次数。下面是一个最小任务定义示例。{ task_id: shop_price_sort_001, instruction: 在搜索框输入“笔记本电脑”按价格从低到高排序输出第一件商品的名称和价格, env: { base_url: https://demo-shop.example/, viewport: [1440, 900], seed_data: seed_20250101, locale: zh-CN }, success_criteria: [ 搜索框内出现关键词“笔记本电脑”, 列表已按价格升序排列, 最终输出包含商品名称, 最终输出包含商品价格 ], max_steps: 40, timeout_seconds: 600, repeat_times: 5 }成功标准要尽量可自动判定例如检测 URL、DOM 状态、输出内容。环境字段保证别人能复现repeat_times 提醒我们单条任务也要多跑几次不能只取一次运行的结果。终止条件同样重要最大步数和超时时间决定哪些轨迹算失败。2.2 轨迹记录每个动作都要有观察上下文轨迹是评估数据里最核心的部分。每步至少记录时间戳、动作类型、动作参数、动作前观察、动作后页面状态、模型消耗。下面是一条轨迹记录示例。{ task_id: shop_price_sort_001, run_id: run_20250201_0003, step: 7, timestamp: 2025-02-01T10:12:07.000Z, action: { type: click, target: { selector: button[data-testidsearch-submit], bbox: [820, 241, 46, 26], text: 搜索 } }, observation_before: { screenshot: shots/run_20250201_0003_step07_before.png, accessibility_snapshot: snapshots/run_20250201_0003_step07.json, url: https://demo-shop.example/search?keyword }, observation_after: { screenshot: shots/run_20250201_0003_step07_after.png, url: https://demo-shop.example/search?keyword%E7%AC%94%E8%AE%B0%E6%9C%AC }, model_metrics: { prompt_tokens: 8120, completion_tokens: 342, latency_ms: 1890 } }每一类字段都有固定用途。截图用于回放视觉可访问性树用于定位语义前后 URL 用于判断页面跳转token 与延迟用于成本评估。动作的 target 里同时保留 selector、bbox、text这样回放时可以交叉验证坐标点击失败时看 selector 是否还能命中。2.3 标注记录成功、效率、安全、体验分开看自动判定只能覆盖部分任务例如最终 URL、DOM 状态、输出内容。很多任务需要人工二次标注。建议把标注维度拆开不要只打一个“成功/失败”。标注维度要回答的问题说明是否成功最终结果是否满足全部成功标准主结果可采用二值或部分分效率是否用合理步数完成可设置人类基准对比安全性是否出现危险操作删除、覆盖、外发敏感信息等必须单列用户体验结果是否符合人类直觉主观标注需多人一致性标注不一致时不要直接平均要保留原始判断并统计一致性。例如同一任务跑 5 次3 次成功应该记录成“5 次里 3 次成功”而不是一句“成功率 60%”带过。安全维度尤其重要一个任务即使最终成功如果过程中出现不应有的删除操作也应该单独标记。2.4 数据分布的坑难度分级与可复现性评测数据不是越多越好。20 万条全部是“点击一个按钮”的任务说明不了复杂操作能力。设计上要覆盖难度梯度。单步任务定位一个元素并点击。多步表单填写表单、上传文件、提交。跨页面任务搜索、筛选、进入详情、回退、再操作。异常处理任务弹窗、错误提示、网络超时。可复现性方面每次运行前要重置环境。常见做法是刷新测试数据库、恢复初始 cookie、重跑种子脚本并在运行记录里保存环境版本号。缺少环境重置同一任务的成功率会因为上次运行留下的脏数据而波动结论完全不可信。3. 最小闭环采集一条可用的操作轨迹3.1 怎么构造可控评测环境如果只是想验证采集思路可以先用本地浏览器加一个测试站点。实际项目里建议做到四点。使用固定版本浏览器避免浏览器升级导致行为变化。页面数据用种子数据初始化避免依赖外部接口。把页面加载、动画、请求延迟控制住减少时序抖动。每次运行前执行 reset 脚本恢复初始状态。生产环境评估则完全不同。真实页面有登录态、多租户、验证码、动态内容采集轨迹前要确认是否具备授权不能绕过任何安全机制。评测环境的结论只能在评测环境内使用不能直接外推到生产可用性。3.2 采集脚本示例记录截图、页面结构和动作下面用 Playwright 演示采集骨架。代码只负责记录观察真正的 agent 决策循环可以在同一个位置调用模型并追加动作。import hashlib import json import time from playwright.sync_api import sync_playwright def capture_observation(page, task_id, run_id, step): screenshot page.screenshot() snapshot page.accessibility.snapshot() return { task_id: task_id, run_id: run_id, step: step, timestamp: time.time(), screenshot_sha256: hashlib.sha256(screenshot).hexdigest(), accessibility_snapshot: snapshot, url: page.url, } def run_one_task(): task_id shop_price_sort_001 run_id run_demo_001 records [] with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page(viewport{width: 1440, height: 900}) page.goto(https://demo-shop.example/, wait_untilnetworkidle) for step in range(1, 41): obs capture_observation(page, task_id, run_id, step) records.append(obs) # 这里应调用 agent 决策模块得到 action 后再执行。 # 示例只展示观察记录所以第一步后直接退出。 break browser.close() with open(f{task_id}_{run_id}.json, w, encodingutf-8) as f: json.dump(records, f, ensure_asciiFalse, indent2) run_one_task()截图在内存里是字节串这里先记录哈希实际项目应把图片按 run_id 和 step 落盘保存。accessibility snapshot 提供页面语义结构这样分析时不需要从像素猜测按钮含义。观察记录必须动作前抓一次、动作后再抓一次才能对比页面状态变化。3.3 日志落盘格式与命名规范逐条记录建议使用 JSONL每行一个 JSON便于增量写入和后续用 DataFrame 分析。命名建议如下。{task_id}_{run_id}_{start_timestamp}.jsonl目录结构示例。eval/ tasks/ task_definitions.json runs/ shop_price_sort_001_run_20250201_0003.jsonl shots/ shop_price_sort_001_run_20250201_0003_step07_before.png shop_price_sort_001_run_20250201_0003_step07_after.png任务定义、轨迹、截图分离分析时用 run_id 关联。截图文件不要放在轨迹文件内部否则 JSON 文件会迅速膨胀读取和检索都很慢。3.4 采集完成后先做三轮自查采集脚本跑完并不意味着数据可用。建议先做三轮自查。完整性每条轨迹是否有动作、前后观察、模型指标缺失字段占比多少。时序timestamp 是否单调递增截图与动作是否对应同一页面状态。可复现同一任务重复运行两次起始环境 hash 是否一致。这三轮自查不通过后续统计都不可信。宁可重采也不要带着脏数据给出“能用”的结论。4. 用数据回答“能不能用”主指标与统计口径4.1 成功率的分母怎么定“能不能用”最常被引用的指标是任务成功率。但这个指标非常依赖分母。任务集合是否提前固定是否在出结果后增删。每个任务重复几次是否只取最好一次。部分完成算不算成功例如找到了商品但价格排序写成了降序。建议在评测开始前把任务、重复次数、判定逻辑写入任务定义文件统计时按固定口径执行。对需要人类判断的任务采用多人标注并报告一致性。分母不固定成功率就没有可比性。4.2 过程指标比只看成功率更能说明问题任务成功率之外还建议统计以下指标。指标计算方式说明中位步数所有成功任务步数取中位数越短通常越接近人类操作习惯回退率同一动作重复出现或撤销次数占比反映决策稳定性每任务 token 成本总 token 除以任务数生产上线必须关注安全违规率触发危险动作的任务占比安全违规不能算入成功稳定性同一任务多次运行的结果方差方差大说明结果不可信这些指标应当与成功率一起发布。否则“成功率 70%”无法判断是靠稳定能力达到还是靠多次重试和重复采样堆出来的。4.3 一份最小分析脚本用 pandas 读取 JSONL可以快速算基础统计。import json import pandas as pd records [] with open(runs/shop_price_sort_001_run_20250201_0003.jsonl, encodingutf-8) as f: for line in f: records.append(json.loads(line)) df pd.DataFrame(records) actions df[action].dropna() # 动作类型分布 print(actions.apply(lambda a: a.get(type)).value_counts()) # 每步模型延迟 print(df[model_metrics].apply(lambda m: m.get(latency_ms) if m else None).describe()) # 按 run_id 分组的步数统计 print(df.groupby(run_id)[step].max())真实分析中还要把结果标注表合并进来才能计算成功率。这里只演示数据读取和基础统计不构成完整评估报告。4.4 结论表达评测内有效不等于生产可用数据结论的边界要写清楚。“在 500 个固定任务上成功率为 68%”是合理表达“智能体已经能操作计算机”属于过度外推。发布结论时建议附上以下信息。任务范围和难度分布。环境版本、浏览器版本、模型版本。重试策略与采样次数。人工标注规范与一致性。这样读者才能判断你的 68% 和他自己的场景是否可比。同一个指标换到另一批任务上可能完全失效。5. 失败轨迹里藏着的四类问题5.1 定位失败感知层的坐标偏差现象是点击后页面没有变化或点到了相邻元素。这类失败在数据上的特征是动作里记录的 bbox 与真实元素 bbox 不重合动作前后截图差异很小。检查方式是把动作坐标叠加到截图上人工抽查统计“点击后 URL 或 DOM 是否变化”。处理建议是动作记录里同时保存 selector 和坐标复现时优先用 selector坐标点击类操作要增加命中校验点击后确认目标元素状态是否改变。5.2 循环空转决策层没有记住做过的事现象是连续多步反复点击同一个按钮或反复滚动同一区域。数据特征是动作序列重复度高相同 action key 占比持续上升。检查方式是按动作类型和目标元素去重计算最长重复片段。处理建议是在模型提示中显式引入“已完成动作”记忆并加入循环检测检测到同一动作重复超过阈值时强制触发人工中断interrupt而不是让智能体继续空转。5.3 上下文丢失长任务后半段的漂移现象是任务前期正常到第 20 步以后开始点击无关元素或访问 URL 偏离目标路径。数据特征是后段动作与任务指令的相关性明显下降。检查方式是把轨迹按阶段切分比较前后阶段的动作类型和访问页面分布。处理建议是长任务先拆子目标在轨迹数据里记录子目标状态一旦某个子目标长期未达成就触发重新规划。5.4 停止条件误判不知道什么时候算做完现象是任务已经完成但智能体继续操作或没完成就输出结论。数据特征是最终状态已经满足 success_criteria但末尾几步仍在产生动作或者最终输出缺少成功标准要求的关键字段。检查方式是把末尾 5 步动作与成功标准逐条比对。处理建议是在评测中增加“无动作奖励”让模型学会及时停止最终输出必须单独校验不能只依赖动作过程。6. 常见问题排查与实践清单6.1 从数据异常反推采集问题问题现象常见原因检查方式处理建议同一任务成功率波动很大环境未重置或页面有随机内容比较起始截图哈希和 URL每次运行前执行 reset记录环境版本轨迹里缺少观察字段采集脚本在动作前后没有都抓快照检查 observation_before/after 是否存在动作执行前后各抓一次并落盘截图与动作不对应截图延迟导致拍到旧页面比较时间戳与页面 loading 状态使用显式等待记录等待状态回放无法复现只存了坐标没存选择器和 DOM检查 target 字段是否完整同时保存 selector、text、bbox成本数据缺失模型调用外层没有传 token 统计检查 model_metrics 字段在调用模型处统一统计并写入排查顺序建议从最简单的问题开始先确认文件路径和字段是否完整再看环境是否重置最后检查模型调用是否记录了成本数据。不要一上来就怀疑模型能力。6.2 学习环境与生产环境要分开评估学习环境追求快速跑通和可复现可以用固定页面、种子数据、headless 浏览器。生产环境面对的是真实用户系统至少还需要考虑以下问题。登录态、多因素认证和权限范围必须走合规流程必要时引入人工接管。危险动作删除、覆盖、转账、发消息必须二次确认并保留审计日志。高频操作需要限速和配额防止智能体失控影响线上系统。长任务执行要支持中断和人工接管很多问题发生在智能体执意继续、而不是停下来请求帮助时。数据层面生产轨迹要额外记录操作者身份、授权范围、审批记录。评测环境的结论不能直接换算成生产可用性两者之间还有很长的工程化距离。6.3 上线一套评测前可以复用的检查清单任务定义。[ ] 每条任务都有 instruction、env、success_criteria、max_steps。[ ] 任务难度分布覆盖单步、多步、跨页、异常处理。[ ] 任务集合在评测前冻结不在出结果后增删。数据采集。[ ] 动作前后都保存截图与页面结构。[ ] 动作同时记录坐标、选择器、文本。[ ] 记录模型 token 与延迟。[ ] 运行 ID 能关联任务、环境版本、模型版本。结果统计。[ ] 成功率按固定分母统计任务重复多次。[ ] 报告成功率之外的中位步数、回退率、成本、安全违规率。[ ] 人工标注任务报告一致性。数据质量。[ ] 起始环境可重置。[ ] 时间戳单调递增。[ ] 截图、DOM、动作三者可对齐。6.4 从操作数据走向自我改进采集下来的轨迹不只是用来写评测报告。高质量轨迹可以进一步用于三个方向。构造偏好数据相同任务上的成功轨迹与失败轨迹配对用于训练奖励模型或做强化学习。失败样本增强把定位失败、循环空转的轨迹整理成负样本帮助模型学会更稳的停止策略。回归测试集新版本模型上线前先跑同一批任务用数据确认没有能力回退。这也是 self-improving agents 方向的一种落地路径让智能体在真实操作中积累经验再用经验改进自身。但要注意轨迹数据包含页面内容和业务信息进入训练集前必须做脱敏和权限审查。不要因为数据是自动采集的就忽略合规要求。判断一个 Computer Use 智能体能不能用答案应该写在数据里而不是写在宣传页上。构建任务定义、采集轨迹、统计指标、分析失败模式是一条可工程化的路径。真正值得花时间的不是跑通采集脚本而是把“成功标准、环境重置、失败分类”这三件事定义清楚。只有这些口径统一了数据才有资格回答“Can Agents Use a Computer Yet”。