最近在排查 Agent 自动化点击、填表、跨应用操作这类需求时经常遇到同一个问题模型在对话里说“我可以帮你操作电脑”但真正让它点击一个按钮、拖拽一个文件、读一段屏幕内容效果却很不稳定。这篇文章想围绕一个核心问题展开当我们在讨论 AI Agents 的 Computer Use 能力时我们到底在讨论什么以及支撑判断的“数据”从何而来、如何构建、如何评估。文章会先讲清楚 Computer Use 涉及的关键技术链路再重点拆解数据在 Agent 能力评估中的作用最后给出一个可运行的最小评估脚本并附上高频踩坑记录。无论是刚开始接触 Agent 开发的初学者还是在设计 Agent 评估体系的后端工程师都可以从中找到可落地的思路。1. AI Agents 的 Computer Use 究竟是什么1.1 从“对话助手”到“操作电脑的 Agent”传统意义上的聊天机器人做的事情可以概括为接收文本输入生成文本输出。它的能力边界在语言空间内。但 Computer Use 类型的 Agent 不同它的目标是直接操作图形界面完成真实任务。比如下面这些场景自动打开浏览器进入某个后台系统导出报表。在桌面应用中自动填写表单点击提交按钮。读取屏幕上的数据区域判断内容是否正常然后执行下一步操作。跨应用协同例如从邮箱中提取附件保存到本地再上传到另一个系统。这些任务的特点是输入不一定只有文本输出也不一定只是文本。Agent 需要“看”屏幕视觉感知需要“决定”下一步做什么决策规划需要“执行”点击、输入、滚动等操作动作执行还需要“验证”操作是否生效结果反馈。从工程角度理解Computer Use Agent 本质上是一个闭环控制系统屏幕感知 - 状态理解 - 目标规划 - 动作执行 - 再次感知 - 判断是否完成每一步都可能引入误差而数据在其中扮演的角色就是用来衡量这些误差到底有多大、出现在哪个环节。1.2 Computer Use 的技术链路拆解为了方便后面讨论数据和评估这里把 Computer Use 的核心链路拆成四层。第一层感知层Agent 需要感知当前计算机状态。常见方式有两种截屏图片 视觉模型Vision Language Model让模型理解屏幕上有什么。可访问性树Accessibility Tree 结构化数据从系统层面拿到界面元素列表。两者的区别在于屏幕截图更接近人类观察方式但受分辨率、遮挡、缩放影响可访问性树信息更结构化和精确但依赖系统和应用是否暴露了这些接口。实际工程中经常两者结合先用截图做整体理解再用可访问性数据定位精确坐标。第二层决策层拿到感知结果后Agent 需要决定“下一步做什么”。决策层通常构建在 LLM 之上模型会接收到当前任务描述、历史操作记录、当前界面状态然后输出下一个动作。动作通常是结构化的例如{ action: click, target: { element_id: submit-btn, coordinates: [860, 540] } }第三层执行层执行层负责把决策转成真实的系统操作。桌面端常见的是通过操作系统辅助功能接口模拟鼠标键盘事件浏览器端可以通过 DevTools Protocol 注入 JavaScript 执行 DOM 操作移动端则需要借助 ADB 等桥接工具。第四层验证层验证层常被忽略但非常重要。Agent 执行动作后需要再次感知屏幕判断“按钮是否真的被点击了”“页面是否跳转了”“错误提示是否出现”。如果缺少验证层Agent 很容易陷入“自我感觉完成任务实际上根本没成功”的状态。而这四层能力到底行不行不能靠感觉必须靠数据。2. 为什么说“数据”是评估 Computer Use 的关键2.1 没有数据就无法衡量“能用”还是“不能用”“Can Agents Use a Computer Yet?” 这个问题如果只靠人工观察几个案例很容易得出截然不同的结论。有人试了一个任务发现很顺畅就说 Agent 已经能操作电脑了有人试了一个复杂任务发现频繁失败就说 Agent 完全不行。这两种结论都存在问题因为它们依赖的样本量太小、任务覆盖面太窄。要客观回答这个问题需要一套数据驱动的评估体系用一批经过设计的任务、统一的判定标准、可重复的评估流程来量化 Agent 的成功率、耗时、错误类型和成本。我把这套数据体系称为“Computer Use 评估数据集”。它不只是给模型训练用的更是给 Agent 系统做能力体检用的。2.2 Computer Use 评估数据的五个维度构建 Computer Use 评估数据集需要考虑以下五个维度。维度一任务类型覆盖度不能只测“点击按钮”这种单一动作要覆盖日常操作中的常见类型。我把任务粗略分成几类任务类型示例难度导航类打开浏览器访问指定网址低填表类在表单中输入内容并提交中提取类从页面中读取指定数据中跨应用类从 A 应用复制数据到 B 应用高故障恢复类遇到弹窗后关闭并继续任务高多步规划类按照多步骤流程完成一个复杂操作很高维度二界面多样性同一个任务在不同应用、不同页面布局下的执行难度差异很大。评估数据中要包含不同的界面风格、不同的数据密度、不同的按钮位置。否则 Agent 可能只是“背下了测试页面的布局”而不是真正学会了操作计算机。维度三环境干扰项真实使用场景中存在大量干扰弹窗广告、系统通知、加载动画、权限申请弹窗。评估数据里需要加入这些干扰项观察 Agent 是否能排除干扰、坚持原定任务。维度四判定标准任务完成后如何判定成功常见判定方式包括最终界面状态是否符合预期例如特定元素出现。操作路径是否合理是否存在大量无效点击。是否在限定步骤内完成。是否产生负面影响例如误删了文件。单点成功的判定方式不够全面建议结合界面状态和操作过程一起评估。维度五成本指标除了把任务做完还要考虑效率。评估数据应该记录完成一个任务消耗了多少轮感知-决策-执行循环。消耗了多少 Token。耗时的瓶颈在模型推理、界面响应还是执行层。这些数据对于优化 Agent 架构非常关键。3. 环境准备与工具选型3.1 运行环境评估一个 Computer Use Agent并不一定需要完整的线上系统。最小环境可以这样搭建操作系统建议使用 Windows 或 macOS便于模拟桌面操作。如果使用 Linux可以通过浏览器自动化方案来完成部分评估。Python 版本3.10 或 3.11 都可以核心依赖是 openai、pyautogui、Pillow。浏览器Chrome 或 Edge使用浏览器自动化协议控制。屏幕环境建议固定分辨率保证截图的尺寸一致性。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示评估思路。3.2 常见的 Agent 框架与工具目前实现 Computer Use Agent 的常用工具链包括类型工具用途模型接口OpenAI GPT-4o / 其他多模态大模型理解截图、生成动作决策桌面自动化PyAutoGUI模拟鼠标键盘操作浏览器控制Playwright / Selenium浏览器内的元素定位与操作辅助功能数据Accessibility Tree获取界面结构化信息移动自动化ADBAndroid 设备控制Agent 编排LangGraph / 自研流程管理多轮感知-决策-执行循环如果你只做评估实验最轻量的组合是Python 多模态模型接口 PyAutoGUI Playwright。不需要一开始就上重型 Agent 框架先跑通闭环再逐步加复杂逻辑。4. 评估体系设计数据怎么构建4.1 任务集设计一个可落地的 Computer Use 评估任务集建议使用 JSON 或 YAML 格式来定义。每个任务至少包含以下字段id任务唯一标识。name任务名称。description给 Agent 的自然语言指令。type任务类型。start_url / start_state初始状态。success_criteria成功判定条件。max_steps最大操作步数。下面是一个最简单的任务定义示例{ tasks: [ { id: nav-001, name: 打开指定网址, description: 打开浏览器访问 https://example.com并确认页面标题中包含 Example, type: navigation, start_url: about:blank, success_criteria: { url_contains: example.com, title_contains: Example }, max_steps: 5 }, { id: form-001, name: 填写搜索框并提交, description: 在搜索框中输入 computer use data然后点击搜索按钮, type: form_filling, start_url: https://www.bing.com, success_criteria: { url_contains: search?qcomputerusedata }, max_steps: 8 } ] }4.2 成功判定有两种思路一种是指令式判定。评估脚本通过接口查询浏览器状态检查 URL、标题、DOM 元素是否存在。这种判定方式稳定、客观、适合自动跑量。另一种是视觉式判定。给评测模型一张目标界面截图让模型判断“当前状态是否达到任务目标”。这种方式更接近人的判断但在复杂界面上稳定性会差一些。生产级评估系统建议两种思路结合先用指令式判定做自动化和批量检查再用视觉式判定处理无法通过 DOM 结构判断的场景。4.3 评估执行流程完整的评估流程可以拆成下面几个步骤加载任务集。重置环境到初始状态。将任务描述发给 Agent。Agent 进入感知-决策-执行循环。每执行一个动作检查是否达到成功条件。如果达到记录成功记录步数和耗时。如果达到最大步数仍未成功标记失败如果出现严重异常标记错误。汇总所有任务的执行结果计算成功率、平均步数、平均耗时。上面的流程中Reset 是最容易被忽略的步骤。如果上一个任务在浏览器里留下了状态后一个任务的执行结果就会失真。在设计评估平台时必须确保每个任务运行前环境是干净的。5. 实战写一个最小的 Computer Use 能力评估脚本接下来用一个极简示例演示如何评估一个 Agent 的 Computer Use 能力。这个示例的重点是让读者理解评估闭环而不是实现一个生产级平台。5.1 项目结构先创建一个项目目录computer-use-eval/ ├── tasks/ │ └── demo_tasks.json ├── agent/ │ └── simple_agent.py ├── evaluator.py └── requirements.txtrequirements.txt内容如下openai1.0.0 pyautogui0.9.54 Pillow10.0.0 playwright1.40.05.2 编写任务定义文件在tasks/demo_tasks.json中加入两个简单任务{ tasks: [ { id: nav-001, name: 打开指定网址并检查标题, description: 打开浏览器访问 https://example.com检查当前页面标题是否包含 Example, type: navigation, start_url: about:blank, success_criteria: { title_contains: Example }, max_steps: 5 }, { id: type-001, name: 在搜索框输入关键词, description: 打开必应首页在搜索框中输入 computer use data然后按下回车键, type: form_filling, start_url: https://www.bing.com, success_criteria: { url_contains: search?qcomputerusedata }, max_steps: 10 } ] }5.3 编写一个简单 Agent 核心逻辑这里不调用真实付费模型而是模拟一个“如果识别到输入框就输入关键词并回车”的简单策略用来演示评估闭环。真实项目中这里的逻辑应替换为多模态模型的决策输出。# agent/simple_agent.py import time class SimpleAgent: 一个极简的 Computer Use Agent 示例。 真正的生产系统这里会调用多模态大模型 将屏幕截图 任务描述发送给模型由模型决策下一步动作。 def __init__(self, page, task_description: str): self.page page self.task_description task_description def get_screenshot(self, path: str screenshot.png): 截取当前页面保存为图片用于后续视觉分析。 self.page.screenshot(pathpath) return path def execute_action(self, action: dict): 执行一个动作。 这里仅做演示支持 goto、fill、press、click 四种基本动作。 action_type action.get(action) if action_type goto: self.page.goto(action[url], wait_untilnetworkidle) elif action_type fill: locator self.page.locator(action[selector]) locator.fill(action[value]) elif action_type press: self.page.keyboard.press(action[key]) elif action_type click: locator self.page.locator(action[selector]) locator.click() else: raise ValueError(fUnknown action: {action_type}) time.sleep(1) def run(self, start_url: str): 执行任务起始动作。 self.page.goto(start_url, wait_untilnetworkidle)5.4 编写评估器evaluator.py是整个评估流程的核心负责加载任务、调用 Agent、判断成功条件、汇总结果。# evaluator.py import json from playwright.sync_api import sync_playwright from agent.simple_agent import SimpleAgent def check_success(page, criteria: dict) - bool: 根据 success_criteria 检查任务是否成功。 支持 title_contains、url_contains 两种判定方式。 current_title page.title() current_url page.url if title_contains in criteria: expected criteria[title_contains].lower() if expected not in current_title.lower(): return False if url_contains in criteria: expected criteria[url_contains].lower() if expected not in current_url.lower(): return False return True def run_task(task: dict): 运行单个任务返回执行结果。 result { task_id: task[id], success: False, steps: 0, max_steps: task.get(max_steps, 10), error: None, } with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page(viewport{width: 1280, height: 800}) agent SimpleAgent(page, task[description]) agent.run(task[start_url]) # 模拟 Agent 决策循环 # 这里在最简单场景下通过判断当前页面状态来选择动作 current_step 0 while current_step result[max_steps]: current_step 1 result[steps] current_step # 检查任务是否已经成功 if check_success(page, task[success_criteria]): result[success] True break # 极简策略判断 URL 特征直接执行固定动作 # 真实场景应在这里调用多模态模型做决策 if task[id] type-001 and bing.com in page.url: agent.execute_action({ action: fill, selector: #sb_form_q, value: computer use data }) agent.execute_action({ action: press, key: Enter }) elif task[id] nav-001: agent.execute_action({ action: goto, url: https://example.com }) browser.close() return result def main(): with open(tasks/demo_tasks.json, r, encodingutf-8) as f: task_data json.load(f) results [] for task in task_data[tasks]: print(f正在运行任务: {task[id]}) result run_task(task) results.append(result) print(f任务 {task[id]} 结果: {成功 if result[success] else 失败}) # 汇总统计 success_count sum(1 for r in results if r[success]) total_steps sum(r[steps] for r in results) success_rate success_count / len(results) * 100 print(\n 评估汇总 ) print(f任务总数: {len(results)}) print(f成功数: {success_count}) print(f成功率: {success_rate:.1f}%) print(f平均步数: {total_steps / len(results):.1f}) if __name__ __main__: main()5.5 运行与验证安装依赖pip install -r requirements.txt playwright install chromium运行评估python evaluator.py预期输出类似正在运行任务: nav-001 任务 nav-001 结果: 成功 正在运行任务: type-001 任务 type-001 结果: 成功 评估汇总 任务总数: 2 成功数: 2 成功率: 100.0% 平均步数: 2.05.6 结果说明上面这个示例中Agent 的成功率是 100%因为任务非常简单而且评估脚本中写死了固定策略。真实场景不会这么顺利模型可能在执行过程中出现以下情况定位不到输入框一直停留在首页。点击了错误的按钮跳转到了不相关页面。在弹窗出现后停止了动作。所以要评估一个真实 Agent 的能力需要把任务集的规模和多样性提上来。把固定动作策略替换成真实的多模态模型。引入屏幕截图在每轮循环时把图片传给模型做决策。替换为多模态模型时核心代码看起来会是这样def get_model_action(screenshot_path: str, task_description: str) - dict: 将截图转换为 Base64调用多模态模型返回结构化动作。 注意这里的 client 需要根据你实际使用的模型服务来配置。 import base64 from openai import OpenAI client OpenAI() # 请替换为实际配置 with open(screenshot_path, rb) as f: image_base64 base64.b64encode(f.read()).decode(utf-8) response client.chat.completions.create( modelgpt-4o, messages[ { role: system, content: 你是一个计算机操作助手。根据截图和任务描述输出下一个动作。 }, { role: user, content: [ {type: text, text: task_description}, { type: image_url, image_url: {url: fdata:image/png;base64,{image_base64}} } ] } ], response_format{type: json_object} ) content response.choices[0].message.content return json.loads(content)接入后run_task中每轮循环的逻辑就变成截屏。调用get_model_action。解析模型输出的动作。执行动作。检查成功条件。6. 常见问题与排查思路问题现象常见原因解决思路Agent 一直在同一个页面重复点击决策循环中没有记录历史状态模型无法判断“点击没有效果”在决策输入中维护操作历史摘要设置连续相同动作次数上限Agent 看不到界面元素截图分辨率过低或界面元素太小固定 viewport 尺寸必要时进行图片裁剪放大注意力区域页面加载慢导致 Agent 提前操作网络波动或页面资源未加载完成使用更加稳健的等待策略例如等待元素出现而非固定 sleep任务间状态残留前一个任务没有清理浏览器缓存和登录态每个任务开始前启动全新的浏览器上下文结束后彻底关闭成功率评估不稳定成功判定条件不够明确增加结构化判定条件把“看起来差不多”改成可检查的状态模型频繁输出非法 JSON模型返回内容中出现多余文本或格式问题使用 response_format 约束 JSON 输出加入解析容错逻辑固定界面能过换网站就失败任务集多样性不足扩充评估数据增加不同 Web 站点和不同布局的任务如果系统经常出现“步骤数很少但任务失败”的情况优先检查成功判定条件是不是写得太苛刻如果步骤数很多但任务还是失败优先排查 Agent 是否一直在做无效操作决策层是否缺少“放弃”机制。在排查过程中日志非常关键。建议给每个动作记录下面这些信息{ step: 3, action: click, target: submit_button, screenshot: 20250214_153002_step3.png, model_response: {\action\:\click\, \target\:\submit\}, page_url_after: https://example.com/success, timestamp: 2025-02-14T15:30:03.000Z }有了这类日志才能回溯失败原因。没有日志的评估系统基本等于没有。7. 最佳实践与工程建议7.1 从“小闭环”开始再扩展不要一上来就构建覆盖几十个复杂任务的评估平台。先搭一个 5 到 10 个任务的闭环验证截图、推理、执行、判定这条链路能跑通再逐步加入跨应用任务、干扰弹窗和异常恢复场景。小闭环的好处是问题容易定位因为你很清楚每个环节的代码是怎么写的。7.2 数据管理要分版本Computer Use 评估数据本身需要版本管理。任务定义、界面截图、评估结果、模型版本、Agent 代码版本这些要素要对应起来。否则当评估结果波动时你无法判断是模型变差了、还是任务集被改过了、还是环境变了。建议在评估结果中记录评估数据集版本。模型名称和版本。Agent 框架代码版本。操作系统和浏览器版本。运行时间。7.3 成功判定要“双重验证”在真实项目中只靠 URL 判断成功往往不够。例如表单虽然提交了但页面弹出“提交失败”的提示此时 URL 可能已经变化。更稳的方式是同时检查 URL、页面标题、关键 DOM 元素或错误提示元素是否存在。def check_success_strict(page, criteria: dict) - bool: if url_contains in criteria: if criteria[url_contains] not in page.url: return False if title_contains in criteria: if criteria[title_contains] not in page.title(): return False if error_selector in criteria: error_count page.locator(criteria[error_selector]).count() if error_count 0: return False if success_selector in criteria: success_count page.locator(criteria[success_selector]).count() if success_count 0: return False return True7.4 安全边界必须提前设计Computer Use Agent 拥有操作系统级的操作权限这在带来便利的同时也引入了风险。在评估和生产环境中必须考虑以下安全措施使用独立虚拟机或容器运行 Agent避免直接操作生产环境的桌面。配置网页操作白名单默认禁止访问内网或敏感系统。设置动作频控避免 Agent 在异常循环中产生大量无效操作。对文件删除、数据提交等高风险动作增加二次确认机制。完整记录所有操作日志方便审计和回滚。在评估和测试环境中使用测试账号和测试数据绝对不能使用线上真实数据。7.5 定期回归评估Agent 系统会随着模型升级、依赖更新、界面改版而发生变化。上个月表现良好的 Agent这个月可能因为某个网站的 DOM 结构调整而失效。建议设置定期回归评估例如每周或每两周运行一次完整任务集。当评估结果出现明显波动时及时回溯模型版本和依赖变更记录。这不仅适用于 Computer Use Agent也是所有数据驱动评估系统的通用工程规范。7.6 性能开销要记录Computer Use Agent 的成本通常比普通聊天应用高很多因为每轮循环都要传递截图而截图带来的 Token 消耗远高于文本。评估时要记录每任务平均 Token 消耗、推理耗时、截图次数。这些数据能帮助你判断是否值得在感知环节引入图像压缩、是否应该用可访问性树替代部分截图。如果发现模型在每一步都传递整张 1280x800 截图但真正影响决策的区域只占画面的十分之一就要考虑加入目标区域裁剪功能这对降本增效帮助很大。8. 总结与下一步学习方向回到标题提出的问题Can Agents Use a Computer Yet? 能给出的可靠回答是部分可以但稳定性取决于任务类型、界面复杂度和评估数据的覆盖率。这不是一个可以用“能”或“不能”简单回答的问题而是一个需要通过数据持续度量、持续优化的工程问题。本文从 Computer Use Agent 的技术链路出发梳理了感知、决策、执行、验证四个环节重点介绍了评估数据的五个构建维度并给出了一个最小可运行的评估脚本。你可以把这份脚本作为起点逐步替换成真实的多模态模型、引入更多复杂任务、加入视觉判定逻辑慢慢搭建属于自己的 Agent 评估体系。下一步可以沿着这几个方向继续深入研究可访问性树Accessibility Tree与截图结合的双通道感知方案。尝试在决策循环中加入短期记忆记录历史操作减少重复动作。探索更细粒度的成功判定方式例如对页面 diff 进行视觉比对。学习和使用成熟的 Agent 编排框架在框架基础上做评估插件的二次开发。如果这篇内容对你有帮助可以收藏备用。后续我还会继续更新 Computer Use 相关的实战记录包括跨应用任务、弹窗干扰处理和评估平台搭建等内容。