Agent 操作电脑能力评测与实战：从原理到数据

从“会聊天”到“会用电脑”：Agent 的 Computer Use 能力到底行不行？我们拿数据说话

最近和几个做 AI 应用的同学聊到一个很现实的问题：大模型驱动的 Agent 已经能写代码、能查资料、能调 API，但让它像一个真人一样“操作电脑”——打开浏览器、点击按钮、填表单、拖文件——结果往往不太稳定。有人开玩笑说，现在的 Agent 就像一个刚学会用鼠标的新员工，动作慢、容易点错、偶尔还会对着弹窗发呆。

这个现象背后其实是一个很值得认真对待的问题：Agent 到底能不能真正“使用计算机”？如果能，做到什么程度？如果不能，瓶颈又在哪里？与其靠感觉争论，不如看数据、跑评测、拆链路。

这篇文章我想围绕 “Computer Use”（计算机使用）这个方向，系统梳理 Agent 操作电脑的基本原理、主流评测方法，并带大家从零搭建一个最小可运行的 Computer Use Agent 实验环境，用真实的数据观察 Agent 的表现。文章不会只停留在概念层面，而是会把代码、评测指标、常见问题和工程建议都展开，适合正在做 Agent 应用、或者准备往 Computer Use 方向切入的开发者参考。

1. 从“大模型能聊天”到“Agent 会操作电脑”

1.1 Computer Use 是什么

Computer Use，直译过来就是“计算机使用”。在 AI Agent 的语境下，它指的是大模型驱动的智能体直接操作图形界面（GUI）或命令行界面，像人类一样完成一系列计算机任务，例如：

• 打开浏览器访问某个网站，搜索信息并整理成文档；
• 在操作系统中创建文件夹、复制文件、修改配置；
• 在办公软件中录入数据、生成图表；
• 在开发工具中执行命令、修改代码、运行测试。

传统自动化工具如 Selenium、PyAutoGUI 也能做类似的事情，但它们的逻辑是“写死流程”：每一步做什么、点击哪个坐标、等待多长时间，全部由开发者预先定义。Computer Use Agent 则不同，它依赖大模型的推理能力，在运行时理解屏幕内容、判断当前状态、决定下一步动作，形成“感知-决策-执行”的闭环。

用一句话概括：传统自动化是“照着剧本演戏”，Computer Use Agent 是“看着屏幕临场发挥”。

1.2 Agent 操作计算机的基本链路

不管底层用的是什么模型，一个典型的 Computer Use Agent 都遵循类似的链路：

1. 观察（Observation）：获取当前计算机界面的状态。最常见的方式是截屏，也可以结合 DOM 树、辅助功能接口（Accessibility Tree）、命令行输出等。
2. 理解（Understanding）：模型分析截图或结构信息，识别按钮、输入框、菜单、弹窗等界面元素。
3. 决策（Decision）：模型根据用户的目标和当前状态，选择下一个动作，例如点击某个按钮、输入一段文字、按下某个快捷键。
4. 执行（Action）：通过工具或 API 将决策转化为真实的计算机操作。
5. 反馈（Feedback）：执行后再次获取界面状态，与目标对比，判断任务是否完成，如果没完成则继续循环。

这个链路可以用一个非常朴素的伪代码来表示：

while not task_done: state = observe() action = model.decide(task, state) execute(action) task_done = check(task, state)

看起来很简单，但每一个环节都有不少坑。观察环节可能遇到遮挡、模糊、多显示器；理解环节可能认错按钮；决策环节可能陷入死循环；执行环节可能因为权限不足或页面加载慢而失败。这些坑正是后面我们要用数据来量化的东西。

1.3 为什么现在需要关注 Agent 的 Computer Use 能力

过去两年的 Agent 应用大多集中在 API 可编程的领域，比如调用大模型接口、操作结构化数据、执行代码。原因很简单：API 是“规范化”的接口，参数明确、返回结构清晰，模型只需要学会调用函数，不需要理解复杂的图形界面。

但现实世界的大量软件并没有开放 API，或者 API 能力不完整。比如一个只有网页端的内部管理系统、一个只能在 Windows 桌面上运行的旧业务软件，这些场景天然依赖 GUI 操作。Computer Use Agent 要解决的正是这类问题，它让 AI 能进入那些“没有 API 的存量软件系统”。

从工程角度看，这也意味着 Agent 的“最后一公里”从 API 调用走向了真实的计算机环境，复杂度同时来自模型能力、环境适配、稳定性和安全性，不再是“发个请求等返回”那么简单。

2. 如何衡量 Agent 的“电脑操作能力”

2.1 评测基准与数据集：先有尺子，才能量高度

要回答“Agent 能不能用电脑”，不能只靠几个演示视频，需要借助基准测试（Benchmark）来量化。目前比较常见的评测基准包括：

这些基准有一个共同特点：它们模拟真实任务环境，而不是简单的问答。Agent 必须真正操作界面，完成后由系统自动判断结果是否正确。

需要强调一点，不同论文、不同厂商公布的基准分数差异很大，而且评测环境、模型版本、运行次数的不同都会影响结果。看评测数据时不要只盯着“多少分”，要看清楚它的任务定义、环境版本和评测口径。

2.2 评测指标的选取：不只是“任务成功率”

评测 Computer Use Agent 时，最直观的指标是任务成功率（Success Rate），即完成的任务数除以总任务数。但在工程实践中，还需要关注更多维度：

• 步骤效率：完成同一个任务，Agent 用了多少步？和人类操作相比差距多大？
• 时间成本：完成一个任务需要多少秒，或者消耗多少模型 Token？
• 稳定性：同一个任务跑 10 次，成功几次？失败的失败点是随机还是固定？
• 错误恢复能力：中间点错按钮后，Agent 能否自我纠正，还是直接死循环？
• 成本：调用模型 API 的费用，是否在业务可接受范围内？

这些指标综合起来，才能判断一个 Computer Use Agent 是否真的能落地。曾经有团队做了一个内部的表单填写 Agent，成功率到了 80%，看起来不错，但一算成本，平均每次任务要调用 50 轮模型接口，单次成本比人工填写还贵，这就很难上线了。

2.3 评测时容易踩的坑

给 Agent 做评测，最需要注意的是“数据泄漏”和“环境差异”。

数据泄漏指评测任务和模型训练数据高度重合。比如让 Agent 去操作一个知名网站，而这个网站的页面结构和操作路径已经在训练语料里出现过，模型很可能通过“背答案”而非真正的感知和决策来完成。为了减少这种情况，很多基准会搭建独立的测试网站，并规定评测期间不更新模型。

环境差异同样关键。Agent 在本地电脑上操作和在容器里操作，截屏分辨率、字体渲染、网络速度都可能不同，这些差异直接影响模型的识别准确率。评测环境必须和部署环境尽量一致，否则线上表现会和评测结果相差很大。

3. 从零搭建一个 Computer Use Agent 实验环境

了解概念之后，我们直接动手搭一个最小可运行的实验环境。目标不是做一个生产级的 Agent，而是跑通“观察-决策-执行”的链路，给后续评测和数据分析打基础。

3.1 环境准备

本文的示例以 Python 为主，代码思路同样适用于其他语言。你需要准备：

• 操作系统：Windows 10/11、macOS 或 Linux 均可，示例不依赖特定平台；
• Python 3.9 及以上版本；
• 浏览器：Chrome 或 Edge，用于网页自动化测试；
• 一个可用的 LLM API Key：可以是 OpenAI 兼容接口，也可以是国内大模型平台的接口，后面代码中我们会留出接口适配层；
• 基础 Python 包：playwright、pillow、requests。

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。

安装依赖：

pip install playwright pillow requests playwright install chromium

playwright的install命令会下载浏览器内核，这一步需要一定时间，请确保网络畅通。

3.2 项目结构

为了保持代码清晰，我们按模块拆分：

computer_use_demo/ ├── agent_loop.py # Agent 主循环 ├── browser_ops.py # 浏览器操作封装 ├── eval_run.py # 评测运行脚本 ├── tasks.json # 评测任务定义 └── logs/ # 运行日志与截图

3.3 核心依赖说明

• playwright：负责浏览器自动化，支持 Chromium、Firefox、WebKit，可以获取截图、模拟点击和输入；
• pillow：截图处理，用于裁剪、缩放、压缩图片，减少模型识别的输入量；
• requests：调用模型 HTTP 接口。

这里特别说明一下采用截图方案的原因。Computer Use Agent 的观察方式大致分为三种：

1. 纯截图（视觉方案）：模型直接看图片，理解界面并决策；
2. 纯 DOM 方案：将网页的 DOM 结构转成文本或 JSON，模型只看结构；
3. 混合方案：截图 + DOM 信息同时输入，模型综合判断。

纯截图方案通用性最好，因为不依赖网页内部的 DOM 结构，对桌面软件和浏览器都适用，但模型需要较强的视觉理解能力。纯 DOM 方案准确率高、Token 消耗少，但只能用于浏览器场景，无法覆盖桌面软件。我们示例选择纯截图方案，方便扩展到桌面环境。

4. 动手实现一个最小可运行的 Computer Use Agent

4.1 构建 Agent 主循环

Agent 主循环的核心逻辑是：拿到任务 -> 截屏 -> 调用模型 -> 得到动作 -> 执行动作 -> 再次截屏 -> 判断是否完成。

先写一个简化的agent_loop.py：

import json import time import base64 import requests from io import BytesIO from PIL import Image from browser_ops import BrowserEnv class ComputerUseAgent: def __init__(self, api_key: str, model_name: str, headless: bool = False): self.api_key = api_key self.model_name = model_name self.browser = BrowserEnv(headless=headless) def observe(self) -> str: """获取当前屏幕截图，压缩后转 base64""" screenshot = self.browser.screenshot() image = Image.open(BytesIO(screenshot)) image.thumbnail((1280, 720)) buffer = BytesIO() image.save(buffer, format="PNG") return base64.b64encode(buffer.getvalue()).decode("utf-8") def decide(self, task: str, image_b64: str) -> dict: """调用多模态模型，根据截图决策下一步动作""" prompt = ( "你是一个电脑操作助手。请仔细观察当前屏幕截图，" "结合用户任务，确定下一个动作。\n" f"用户任务：{task}\n" "请只输出 JSON，格式如下：\n" '{"action": "click|fill|scroll|wait|finish", "selector": "", "text": "", "reason": ""}\n' "如果任务已完成，action 为 finish。" ) payload = { "model": self.model_name, "messages": [ { "role": "user", "content": [ {"type": "text", "text": prompt}, {"type": "image_url", "image_url": {"url": f"data:image/png;base64,{image_b64}"}} ] } ] } headers = { "Authorization": f"Bearer {self.api_key}", "Content-Type": "application/json" } response = requests.post( "https://api.openai.com/v1/chat/completions", headers=headers, json=payload, timeout=120 ) response.raise_for_status() content = response.json()["choices"][0]["message"]["content"] content = content.strip().strip("```json").strip("```").strip() return json.loads(content) def run(self, task: str, max_steps: int = 10): """执行任务，最多循环 max_steps 步""" self.browser.goto("about:blank") step_count = 0 while step_count < max_steps: print(f"----- Step {step_count + 1} -----") image_b64 = self.observe() action = self.decide(task, image_b64) print("模型决策:", action["reason"]) if action["action"] == "finish": print("Agent 判断任务已完成") return True self.browser.execute_action(action) time.sleep(2) step_count += 1 print("达到最大步数，任务未完成") return False

注意，这里使用的是 OpenAI 兼容的视觉接口格式，如果你的模型平台接口不同，需要按平台文档调整请求体。示例中的finish动作是让模型在认为任务完成时返回，评测脚本再根据结果判断是否真的完成，避免模型“自说自话”。

4.2 实现浏览器操作层

接下来封装浏览器操作。BrowserEnv类负责截图、执行点击、输入、滚动等动作。

编写browser_ops.py：

from playwright.sync_api import sync_playwright class BrowserEnv: def __init__(self, headless: bool = False): self.headless = headless self._playwright = None self.browser = None self.page = None self.start() def start(self): self._playwright = sync_playwright().start() self.browser = self._playwright.chromium.launch(headless=self.headless) self.page = self.browser.new_page(viewport={"width": 1280, "height": 720}) def screenshot(self) -> bytes: return self.page.screenshot() def goto(self, url: str): self.page.goto(url, wait_until="domcontentloaded", timeout=30000) def execute_action(self, action: dict): action_type = action.get("action") selector = action.get("selector") or "" text = action.get("text") or "" if action_type == "click": if selector: self.page.click(selector, timeout=10000) else: # 没有 selector 时尝试按坐标点击 x = action.get("x") y = action.get("y") if x is not None and y is not None: self.page.mouse.click(x, y) elif action_type == "fill": if selector: self.page.fill(selector, text, timeout=10000) else: self.page.keyboard.type(text, delay=50) elif action_type == "scroll": direction = text or "down" if direction == "down": self.page.mouse.wheel(0, 500) else: self.page.mouse.wheel(0, -500) elif action_type == "wait": self.page.wait_for_timeout(2000) def close(self): if self.browser: self.browser.close() if self._playwright: self._playwright.stop()

这个封装有两个关键点：

1. execute_action同时支持 selector 定位和坐标点击。这样模型既可以通过识别 DOM 给出选择器，也可以在纯视觉模式下输出坐标。
2. 每个动作都设置了超时时间，避免页面元素未加载时无限等待。

4.3 模拟“观察-思考-行动”流程

把这个流程形象地拆开看，每一轮循环就像一个人在电脑前工作：

• 观察：给电脑屏幕拍一张照，相当于人“看一眼屏幕”；
• 思考：把照片交给大模型，模型理解当前页面状态，决定下一步做什么；
• 行动：把模型输出的动作翻译成 Playwright 调用，真实操作浏览器；
• 再观察：操作完成后再次截屏，检查页面是否发生变化。

这是 Computer Use Agent 最核心的闭环。下面的流程简表可以帮助理解：

4.4 运行与验证

创建一个简单的评测任务文件tasks.json，先定义一个任务：

[ { "id": 1, "task": "打开必应搜索，搜索 Computer Use Agent，然后返回第一条结果的标题", "url": "https://www.bing.com" } ]

再写eval_run.py来批量跑任务：

import json import sys from agent_loop import ComputerUseAgent def main(): api_key = sys.argv[1] model_name = sys.argv[2] tasks = json.load(open("tasks.json", encoding="utf-8")) agent = ComputerUseAgent(api_key=api_key, model_name=model_name, headless=False) for task in tasks: print(f"任务 {task['id']}: {task['task']}") agent.browser.goto(task["url"]) result = agent.run(task["task"], max_steps=8) print(f"任务 {task['id']} 结果: {result}") agent.browser.close() if __name__ == "__main__": main()

运行命令：

python eval_run.py "你的API_KEY" "gpt-4o"

预期会看到 Agent 逐轮输出模型决策原因，并在若干步之后返回结果。如果模型能力不足或动作解析出错，程序会在达到最大步数后自动停止，不会死循环。

这里要特别注意：不同模型的动作格式偏好差异较大，有些模型倾向于输出坐标，有些倾向于输出选择器。要根据实际模型调整decide方法中的提示词和输出解析逻辑。

5. 数据分析：Agent 到底能不能“用电脑”

跑完评测之后，我们手里有了一批日志，包括每步的截图、模型决策、执行结果。接下来可以从数据角度观察 Agent 的真实表现。

5.1 从数据看任务完成度

在评估一个 Agent 时，我会先看三组数据：

1. 最终成功率：比如 20 个任务里完成 11 个，成功率 55%；
2. 平均步数：完成的任务平均用了多少步，超过某个阈值说明效率有问题；
3. 失败分布：是任务开头就失败，还是快要完成时失败。

失败分布能反映很多问题。如果大量失败发生在任务前半段，通常说明 Agent 的界面理解能力不足，认不出入口或按钮；如果失败集中在后半段，则可能是多步操作时状态管理出问题，比如点击后页面跳转、元素的坐标发生偏移。

5.2 失误类型归类

把失败日志翻一遍，常见失误往往可以归为这几类：

坐标映射问题在纯截图方案里特别常见。浏览器窗口大小和截图分辨率不一致时，模型看到的坐标和真实浏览器坐标会出现偏移。解决思路是在observe时固定 viewport 尺寸，并让截图尺寸与它一致，后面我们在最佳实践里再展开。

5.3 数据背后的瓶颈

有了数据之后会发现，Computer Use Agent 的瓶颈往往不是单一环节，而是多个环节叠加的结果。

首先是感知能力。模型的视觉理解决定了它能不能从屏幕中准确找到按钮、输入框和菜单。对复杂界面、弹窗、表格，目前很多模型还是会“看走眼”。

其次是决策能力。感知对了，决策也可能错。有些任务需要多步推理，比如“先登录、再进入设置、再修改参数”，模型容易在中途忘记目标，或者被页面上的其他元素干扰。

最后是执行稳定性。网络请求延迟、页面异步渲染、元素未加载完，这些工程层面的问题会导致即使模型决策正确，执行效果也不理想。

所以回到标题的问题：“Can Agents Use a Computer Yet？” 数据给出的答案是：能，但离稳定可靠还有明显距离。在受限环境、规范页面中，Agent 已经能完成不少真实任务；但在开放、复杂、动态变化的计算机环境中，它更像一个“需要监管的实习生”，还达不到“独立办公”的水准。

6. 常见问题与排查清单

6.1 常见报错现象

搭建和运行 Computer Use Agent 的过程中，最容易遇到的问题集中在环境、坐标、模型输出和浏览器状态几个方面。下面整理成一张表：

6.2 通用排查清单

如果你跑出来的效果不理想，可以按下面的顺序排查：

1. 环境是否一致：本地 Chrome 版本、视口大小、网络环境是否在多次运行时保持一致；
2. 观察是否充分：截图是否清晰、完整，截图中是否能看到任务需要的元素；
3. 提示词是否明确：有没有告诉模型“输出格式”“何时结束”“如何纠错”；
4. 动作参数是否正确：selector 在当前页面是否存在，坐标是否在当前页面范围内；
5. 反馈是否有效：执行动作后，模型能不能从新的截图中看到变化。

坚持“一次只改一个变量”的原则，定位问题会快很多。

7. 工程化最佳实践建议

7.1 环境隔离与沙箱化

Computer Use Agent 会真实操作系统或浏览器，一旦决策错误，可能产生不可逆的操作。比如删文件、发消息、提交订单，这些动作如果直接执行，后果很难挽回。

因此，工程化部署时强烈建议使用虚拟机、Docker 容器或独立的浏览器配置文件，把 Agent 操作环境与应用系统隔离。权限上遵循最小权限原则：Agent 只在必要范围内操作，不授予系统管理员权限，不访问无关目录或账户。

7.2 人工确认与打断机制

开发中很有必要引入“打断机制”。当 Agent 将要执行高风险动作时，暂停并请求人工确认。这个设计在多个大模型 Agent 产品中已经出现，核心思路是给 Agent 设置风险等级：

• 低风险动作（滚动、截图、阅读）自动执行；
• 中风险动作（输入文字、点击提交）自动执行但记录日志；
• 高风险动作（删除、支付、发送消息）必须人工确认。

这样既保留 Agent 的自动化效率，也避免不可控的后果。用数据的话说，不是所有失败都来自 Agent 能力不足，有相当一部分失败是因为没有设计好“安全刹车”。

7.3 数据采集与日志留痕

Computer Use Agent 的调试比普通后端接口难得多，因为每一步都是“图像 + 动作”的序列，问题可能出现在任意一环。因此日志系统必须包含：

• 每一步的截图或完整页面快照；
• 模型输入的 prompt 和输出的原始内容；
• 动作执行耗时和结果；
• 浏览器控制台日志；
• 网络请求异常信息。

有了完整的数据链，才能定位问题是感知错误、决策错误还是执行错误。

7.4 语义层的构建

如果把视野放大一些，Computer Use Agent 不止是操作浏览器。在数据领域，很多人也在讨论 Data Agent，即让 Agent 访问数据库、数据仓库来完成数据分析任务。

这类 Agent 通常需要构建语义层（Semantic Layer），把表名、字段名、业务口径映射成模型能理解的业务术语。比如数据库里有个字段叫user_cnt，语义层里对应的业务含义是“去重后的用户数”。如果没有这个映射，模型很可能把原始字段名误解为“用户总数”。

这个思路和 Computer Use 是互补的：Computer Use 解决“没有 API 的界面操作”，语义层解决“有数据但需要口径理解”的分析场景。两者结合，Agent 才能真正覆盖从数据获取、加工到界面输出的完整流程。

7.5 成本与性能优化

Computer Use Agent 的 Token 消耗通常比普通对话高出很多，因为每一轮决策都可能携带一张截图。优化方向如下：

1. 截图压缩：控制分辨率，将图片缩到合理尺寸；
2. 减少无意义轮次：如果页面没有变化，不重复调用模型；
3. 缓存常用页面状态：同一个页面重复出现时，可以复用之前的 DOM 或截图；
4. 模型分级：简单动作用小模型，复杂决策用大模型，成本可以显著下降。

8. 总结与下一步学习路线

回到最初的问题：Agent 能用电脑了吗？数据告诉我们，它已经跨过了“完全不能用”的阶段，但在真实、复杂、动态的场景里，距离“稳定可用”还有一段路。对开发者来说，这个阶段恰恰是机会最多的时候——评测方法、环境隔离、动作约束、数据采集，每一个环节都在等待更成熟的解决方案。

如果你打算深入研究这个方向，我建议按下面的顺序推进：

1. 先把本文的示例跑通，掌握“观察-决策-执行”的基本框架；
2. 找一套公开基准（比如 WebArena 的精简任务集），批量跑一批数据，观察 Agent 的失误模式；
3. 针对失误模式做针对性优化，比如调整提示词、增加坐标校正、加入人工确认机制；
4. 尝试把方案迁移到桌面软件或其他非浏览器环境，拓展应用范围。

动手跑一组真实任务，拿到自己的第一份评测数据，会比读十篇概念文章更有价值。希望这篇文章能帮你把 Computer Use Agent 从“听起来很酷”变成“我能测量、我能调试、我能优化”的工程实践。