最近几个月AI 圈子里有一个问题被反复提起Agent 到底能不能像人一样直接操作电脑不是调用 API不是写脚本而是真的打开浏览器、移动鼠标、点击按钮、填写表单、滚动页面把一个真实任务跑完。这个问题之所以让人焦虑是因为它直接决定了“AI 自动化”能走多远。过去做自动化靠的是 API、脚本、RPA 录制如果 Agent 能直接操作电脑界面那意味着所有没有 API 的旧系统、网页甚至桌面软件都可能被 AI 自动化接管。但真正值得关注的信号不是某家公司的演示视频而是一句话“Weve got the data”。这句话背后是一个判断Agent 操作电脑这件事终于从概念演示进入了可评测、有数据、能横向比较的阶段。很多人还停留在“看个热闹”的层面而真正关键的问题只有一个——用数据说话Agent 到底行不行本文会拆解四件事Agent 是怎么“用”电脑的公开评测数据说明了什么你自己搭一套最小环境要怎么做以及最容易踩的坑和工程建议。1. 这篇文章真正要回答的问题先给结论当前的 Computer Use Agent操作电脑的智能体已经不是玩具但也没有到“可以放心把电脑交给它”的程度。它的真实水平可以概括为能看懂屏幕、能点击、能打字、能在一个受控的小任务里连续执行几步但在复杂页面、意外弹窗、长任务、需要纠错的场景下失败率依然很高。这篇文章适合三类读者第一类是正在做 Agent 应用开发的工程师。你可能正在纠结自己的产品到底应该走工具调用Tool Calling、MCP还是直接做 Computer Use本文会给出一个判断框架。第二类是技术决策者。你关心的是Agent 操作电脑的能力现在能不能支撑业务自动化投入产出比如何公开评测数据是最直接的参考。第三类是学习者。你想理解 GUI Agent、视觉 Grounding、屏幕理解这些概念到底在说什么以及为什么它们这么难。这篇文章的目标不是吹捧某个产品而是把“Agent 使用电脑”这件事的技术机制、数据表现和工程落地路径讲清楚让你读完能形成一个自己的判断而不是被演示视频带着走。2. 基础概念从“调用工具”到“操作电脑”要理解 Computer Use必须先分清三个经常被混为一谈的概念传统 RPA、工具调用Tool Calling、Computer Use Agent。2.1 传统 RPA 与 Agent 的本质区别传统 RPA机器人流程自动化做的事情也是“操作电脑界面”比如模拟点击、键盘输入、读取 Excel。但 RPA 的核心是确定性脚本每一步都是人预先写死的页面结构一变脚本就崩。Agent 的核心则是不确定性决策它没有一个写死的步骤序列而是每走一步都重新观察环境、判断下一步该干什么。这听起来更智能但也意味着每一步都可能错。2.2 工具调用Tool Calling是“间接操作”现在大多数 Agent 产品的底层是工具调用。模型在对话中输出一个结构化的调用请求比如{ tool: search_product, params: { keyword: 机械键盘, page: 1 } }然后由代码把它翻译成一次真实的 API 或数据库操作。这种方式的优点是可靠、可控、成本低缺点也非常明显前提是系统提供了 API 或结构化数据源。没有 API 的旧系统工具调用就无能为力。2.3 Computer Use 是“直接操作”Computer Use 指的是 Agent 像人一样通过屏幕截图或无障碍树Accessibility Tree感知界面然后输出“移动鼠标到某处点击”“输入文本”“按某个键”这类低级动作由执行层真正操作操作系统或浏览器。三者对比维度传统 RPA工具调用Computer Use Agent操作对象界面元素API / 数据源屏幕 键盘鼠标动作定义人写死模型选择工具模型实时决策对界面变化的鲁棒性很低与界面无关取决于模型视觉理解适用场景稳定、重复流程有 API 的业务系统无 API 的旧系统、跨应用操作成本开发成本高低高截图 多轮模型调用可靠性高但脆弱高目前偏低有一个很形象的类比工具调用相当于给 Agent 发了一张“员工卡”它走到指定窗口办指定业务Computer Use 相当于直接给 Agent 一台电脑让它自己找软件、自己点、自己试错。前者是标准化通道后者是自由操作——自由操作的代价就是容易出错。2.4 几个必须知道的术语GUI Agent能操作图形用户界面的智能体是 Computer Use 的概念外延。视觉 Grounding把模型看到的自然语言指令如“点击登录按钮”映射到屏幕上的具体坐标或元素。这是 Computer Use 的核心难点之一。屏幕理解Screen Understanding模型能否从截图中准确识别出按钮、输入框、弹窗等界面元素。无障碍树Accessibility Tree浏览器或操作系统暴露给外部的结构化 UI 信息包含元素类型、名称、状态等。很多 Computer Use 实现会混合使用截图和无障碍树而不是只靠视觉。Long-horizon Task长程任务需要多步、多次状态判断才能完成的任务。这类任务对 Agent 的规划和记忆能力要求更高。理解这些概念之后我们再来看数据——因为只有数据才能回答“Agent 到底行不行”。3. Weve got the data公开评测数据说明了什么“Weve got the data”这句话的核心含义是这个领域已经开始用标准化的评测数据来衡量 Agent 的操作能力了。过去谁也说不清一个 Agent 好不好用现在至少可以放在同一个基准上比一比。3.1 目前主流的评测基准当前用来衡量“Agent 会不会用电脑”的基准主要有三类第一类是桌面/操作系统级基准最典型的是 OSWorld。它让 Agent 在真实的 Windows/Ubuntu/macOS 虚拟机里完成一系列任务比如“在 LibreOffice 里把文档段落设置为双倍行距”“打开系统设置修改壁纸”等。这类基准最接近真实场景也最难。第二类是网页级基准比如 WebArena 和 VisualWebArena。Agent 需要在一个模拟电商、论坛、博客的网站上完成任务例如“把购物车里的商品结算”“在论坛发布一条评论”。这类环境相对可控但对 Agent 的页面理解要求很高。第三类是元素定位/视觉 Grounding 基准比如 ScreenSpot。这类基准不要求完整完成任务只要求模型在给定的截图中准确点中某个元素。它更像一个“单项能力测试”。3.2 数据透露的真实水平从公开评测数据看情况非常真实以 OSWorld 为参照人类完成同一批桌面任务的平均成功率大约在 70% 以上而早期视觉操控类 Agent 普遍在 10% 到 20% 之间徘徊。也就是说Agent 处于“会操作但十个任务里能做成一两个”的水平。即使是后续用更强模型、加自我纠错流程的 Agent公开数据中也没有稳定突破半数的记录。网页级基准的表现稍好一些。WebArena 上人类成功率在 75% 以上主流网页 Agent 则大致在 20% 到 40% 区间。换句话说在结构相对标准、页面相对稳定的网页环境里Agent 已经具备一定的实用价值但在桌面级、长任务、高不确定性的场景里它仍然处于早期阶段。这里要特别提醒一点不同产品的数据口径差异很大。有的团队用 10 个精心挑选的任务展示“成功率 80%”有的基准包含几百个随机任务成功率只有 15%。看数据时一定要先问清楚任务集是什么环境是否固定有没有人工筛选3.3 数据的意义能力的“及格线”正在被量化“Weve got the data”更深层的价值在于这个领域进入了可量化迭代的阶段。以前改进一个 Agent只能靠 demo 感觉得到现在可以拿 OSWorld 上的分数来对照模型升级、提示词优化、纠错机制是否有效一测便知。所以我的判断是不要因为“成功率不到 30%”就否定这个方向也不要因为“demo 看起来很牛”就高估它的成熟度。正确的态度是——把它当作一种值得投入的、有数据支撑的长期能力但在当前阶段只把它用在特定场景里。4. 技术原理拆解一个会操作电脑的 Agent 内部发生了什么一个 Computer Use Agent 的完整工作循环可以用四步概括感知Perception、规划Planning、动作Action、反思Reflection。4.1 感知Agent 怎么“看”电脑感知层负责把电脑屏幕转换成模型能理解的输入。主流方案有两种第一种是纯截图方案。系统定时截取屏幕或浏览器视口的 PNG 图像传给多模态模型。优点是通用不依赖任何 UI 框架缺点是图像 token 消耗大、模型对微小元素的识别可能不准。第二种是混合方案。除了截图还额外获取无障碍树或 DOM 结构把“图像 结构化文本”一起交给模型。这在浏览器场景里特别有效因为无障碍树直接给出了按钮名称、元素类型、坐标范围模型不需要靠视觉去“猜”按钮在哪。实际工程中混合方案往往比纯截图可靠得多。原因是让模型从像素里精确读出“这个元素是什么、坐标是多少”本身就是一个高难度任务而无障碍树恰好提供了这个信息。所以很多产品表面上是“Computer Use”实际底层是“视觉 结构化信息 低级操作”的组合。4.2 规划Agent 怎么决定下一步规划层决定 Agent 当前这一步应该做什么。它通常由一个多模态大模型完成输入是屏幕状态截图/无障碍树和任务描述输出是一个结构化的决策。这个决策包括两部分一个“思考”thought以及一个具体的动作action。动作一般局限在一个小型动作空间里比如{ thought: 当前页面是商品详情页需要把商品加入购物车, action: click, element_id: add_to_cart_button }这里的关键设计是动作空间一定是“小”而“稳”的而不是直接让模型输出自由文本去操作电脑。模型只负责决策真正的鼠标移动、键盘输入、点击事件由执行层完成。这个分层是 Computer Use 工程化的基础。4.3 动作模型决策怎么变成真实操作动作层把模型的 JSON 决策翻译成真实操作。在浏览器环境里通常用 Playwright 或 CDPChrome DevTools Protocol在桌面环境里可能用 PyAutoGUI、系统级 UI Automation 接口。这一层必须处理很多脏活元素找不到时怎么重试页面加载慢时等待多久弹窗挡住了目标元素时要不要先关闭弹窗。绝大多数 Computer Use 失败不是模型“想不到”而是动作层没有处理好真实界面的不确定性。4.4 反思做错之后怎么办反思层是 Agent 和脚本最大的区别之一。每执行一个动作之后系统会再次截图让模型判断“上一步操作是否生效、当前状态是什么、下一步怎么办”。一个成熟的 Computer Use Agent 循环会写成类似这样的伪代码while not task_done and step max_steps: state observe_screen() # 截图 a11y tree decision agent.plan(state) # 模型输出动作 execute(decision) # 执行层落盘操作 effect observe_screen() # 再次观察 if not is_expected(effect): recover(decision, effect) # 纠错或换策略这个循环看起来简单真正难的是is_expected和recover这两步——它们决定了 Agent 能不能从错误中恢复而这恰恰是当前评测数据里失分最严重的地方。5. 环境准备给 Agent 准备一台“安全可控”的电脑任何接触 Computer Use 的开发者第一个要解决的问题不是“模型选哪个”而是“让 Agent 在哪台电脑上操作”。直接在真实系统上跑一个会自己点鼠标的 Agent风险极大——它可能误点、误删、误提交。5.1 推荐的实验环境最稳妥的方案是虚拟机 快照或者 Docker 虚拟显示。这样 Agent 操作的是一台随时能重置的“一次性电脑”即使把系统搞坏恢复也只是恢复快照的问题。在浏览器场景里我建议直接用 Playwright。它自带浏览器控制能力既能截图也能执行点击、填表、滚动等操作还支持获取无障碍树非常适合做 Computer Use 实验。基础环境如下# 创建虚拟环境并安装依赖 python -m venv .venv source .venv/bin/activate # 安装核心依赖 pip install playwright openai # 安装 Chromium 浏览器 playwright install chromium如果你的项目需要操作本地截图、OCR 或无障碍树处理可以再补充安装pip install pillow pytesseract accessibility-tree-parser5.2 权限与安全边界在开发阶段就要想清楚安全边界而不是等上线再补只允许 Agent 访问白名单网站禁止访问含敏感操作删除、转账、发布的页面。给 Agent 单独的测试账号不要使用真实账号。浏览器使用独立的 user-data-dir避免残留登录态污染。所有动作必须写日志方便事后复盘和回滚。Windows 桌面级操作还需要注意如果使用 PyAutoGUI 等方案系统权限和缩放比例会影响坐标计算建议在固定的分辨率和缩放比例下测试。macOS 系统还需要在“辅助功能”里授权终端控制能力。6. 最小实现用 Playwright 视觉模型跑通“看屏—决策—点击”循环下面我们用 Python 写一个最小的 Computer Use Agent 骨架。它的工作方式是截取浏览器页面图片 → 交给视觉模型判断下一步动作 → 执行动作 → 再次截图判断是否完成。这是目前主流 Computer Use 架构的简化版重点是让你理解整体循环而不是追求生产级效果。6.1 系统提示词与动作协议首先定义模型的“工作说明”。关键是让模型只输出结构化 JSON并且动作空间要小、明确# 文件路径agent_prompt.py SYSTEM_PROMPT 你是一个只能通过屏幕截图观察浏览器页面、通过 JSON 动作操作 GUI 的智能体。 你只能使用以下动作 - click: 点击页面上文字匹配的元素target 填按钮或链接的文本。 - type: 在聚焦元素上输入文本target 填要输入的文本。 - scroll: 向下滚动页面。target 可省略。 - press_key: 按下一个按键target 填按键名例如 Enter。 - wait: 等待页面加载target 填等待毫秒数。 - finish: 任务完成role 填完成说明。 每次只输出一个 JSON 对象格式如下 {thought: 对当前屏幕的一句话判断, action: click, target: 登录按钮} 如果任务已经完成输出 {thought: 任务已完成, action: finish, target: } 注意不要输出任何 JSON 以外的内容。 .strip()6.2 核心循环下面是 Agent 的核心循环。我把它拆成几个函数方便你理解每一步# 文件路径computer_use_demo.py import base64 import json from openai import OpenAI from playwright.sync_api import sync_playwright client OpenAI() def take_screenshot(page) - str: 截取当前视口并转成 base64 png_bytes page.screenshot(typepng, full_pageFalse) return base64.b64encode(png_bytes).decode(utf-8) def ask_next_action(screenshot_b64: str, task: str) - dict: 把截图和任务交给多模态模型返回 JSON 动作 resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: SYSTEM_PROMPT}, { role: user, content: [ {type: text, text: f当前任务{task}}, { type: image_url, image_url: {url: fdata:image/png;base64,{screenshot_b64}} }, ], }, ], response_format{type: json_object}, ) return json.loads(resp.choices[0].message.content) def execute_action(page, action: dict) - bool: 把模型输出的 JSON 动作映射为实际的浏览器操作。 返回 False 表示任务结束。 name action.get(action) target action.get(target, ) if name click: page.get_by_role(button, nametarget).first.click() elif name type: page.keyboard.type(target) elif name scroll: page.mouse.wheel(0, 500) elif name press_key: page.keyboard.press(target) elif name wait: page.wait_for_timeout(int(target or 1000)) elif name finish: return False return True def run(task: str, start_url: str, max_steps: int 10): with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page(viewport{width: 1280, height: 800}) page.goto(start_url) for step in range(max_steps): screenshot take_screenshot(page) try: decision ask_next_action(screenshot, task) except Exception as e: print(f[步骤 {step}] 模型调用失败{e}) break print(f[步骤 {step}] thought: {decision.get(thought)}) print(f action: {decision.get(action)} - {decision.get(target)}) should_continue execute_action(page, decision) if not should_continue: print(Agent 判定任务完成) break # 固定等待给页面渲染留时间 page.wait_for_timeout(1500) browser.close() if __name__ __main__: run( task打开 GitHub 首页后点击右上角的 Sign in 链接, start_urlhttps://github.com, max_steps6, )6.3 关键逻辑说明这个 Demo 有几个设计点值得解释第一动作空间被刻意限制了。模型只能输出click、type、scroll、press_key、wait、finish这几种动作。这样执行层的代码逻辑简单模型也更容易生成合规输出。你可以在execute_action里通过try/except捕获点击失败并让模型重新决策。第二决策是逐轮的。每一步都重新截图、重新调用模型。这是 Computer Use 的基本模式——永远不会“一次规划到底”因为真实界面随时可能变化。第三硬性步数上限。max_steps6防止 Agent 陷入死循环。生产环境里步数上限和超时是必须有的兜底。6.4 运行前要做的准备由于这段代码需要调用视觉模型接口你需要配置 API Keyexport OPENAI_API_KEY你的Key然后运行python computer_use_demo.py如果模型选型不同只需要改ask_next_action里的model参数和客户端初始化代码。例如使用本地视觉模型时可以把 OpenAI 客户端替换为兼容 OpenAI 协议的服务地址其余逻辑保持不变。7. 运行结果与验证如何判断 Agent 真的在“用电脑”7.1 预期输出当你运行上面的 Demo控制台会逐行输出 Agent 的决策过程例如[步骤 0] thought: 当前是 GitHub 首页右上角有 Sign in 按钮 action: click - Sign in [步骤 1] thought: 已进入登录页需要点击 Sign in 按钮 action: click - Sign in最终如果 Agent 成功完成会输出Agent 判定任务完成7.2 怎么判断成功这里要区分两种成功过程成功Agent 每一步的动作都符合预期没有明显误操作。任务成功最终页面状态确实达到了任务目标比如跳转到了登录页。我的建议是验收必须以任务成功为准而不是以模型“说完成了”为准。一个可靠的验证方式是在 Agent 结束循环后额外检查页面状态。比如用page.url判断是否跳转到了预期地址或者用page.get_by_text(登录)判断关键元素是否存在。# 验证示例任务完成后检查页面 URL page ... # 在 run 函数内保留 page 引用 assert login in page.url, fAgent 未到达登录页当前 URL: {page.url}7.3 记录数据才是关键如果你要做正经评估不要只跑一两次。建议把每轮实验记录成结构化日志——任务名、是否成功、步数、耗时、每步的截图路径、模型输出、错误信息。后续要分析 Agent 为什么失败这些日志是唯一的依据。一个简单的日志结构{ task: open_github_signin, success: true, steps: 2, duration_sec: 18, actions: [ {step: 0, action: click, target: Sign in, thought: ...}, {step: 1, action: finish, target: , thought: ...} ] }当你把日志积累到几十条时就能看出 Agent 的系统性弱点是卡在弹窗上还是经常误点导航还是模型识别不了某种元素。评测数据的价值不在于一个总分而在于暴露失败模式。8. 常见问题与排查思路Computer Use Agent 的失败模式非常集中。下面这些是我认为最高频的问题问题现象可能原因排查方式解决方案模型说点击了按钮但页面没反应元素在屏幕外或被弹窗遮挡检查截图确认元素是否可见先滚动到目标区域或先关闭弹窗再执行点击点击坐标总是偏移浏览器缩放比例/系统 DPR 导致截图坐标和实际坐标不一致对比截图分辨率与视口设置固定 viewport 和缩放比例用无障碍树元素定位代替坐标Agent 反复执行相同动作陷入死循环缺少状态检测和去重打印每步动作检查是否有重复增加 max_steps 硬上限检测到相同状态时强制切换策略模型“幻视”认为页面存在不存在的按钮截图分辨率太低或模型能力不足放大截图人工查看模型看到的图片提高截图质量叠加无障碍树文本信息每步成本过高每轮都传完整高清截图统计 token 消耗压缩截图尺寸相同页面状态缓存减少无谓的重复询问页面加载慢导致误判Agent 在页面未就绪时执行操作观察截图时间点和页面加载状态增加 wait 动作使用显式等待条件模型频繁输出非法 JSON提示词约束不够强查看原始输出内容在提示词中强调“只输出 JSON”用 response_format 强制 JSON8.1 一个典型的排查路径当 Agent 失败时不要急着改代码。按这个顺序排查先看截图。把失败步骤的截图调出来确认模型看到的页面和你以为的一致。很多“模型不听话”其实是页面状态和预期不符。再看模型输出。确认模型给出的 JSON 是否合法、动作是否合理。如果模型判断错了说明感知或规划有问题如果模型判断对但执行失败说明动作层有问题。最后看动作层日志。点击是否报错、元素是否找到、是否被遮挡。这一步能区分“模型问题”和“工程问题”。这个顺序能帮你快速定位大部分问题而不是盲目换模型或者调提示词。9. 最佳实践与工程建议如果要把 Computer Use Agent 从 Demo 做成可用功能下面几条工程建议非常值得参考。9.1 API-first不要让 Agent 操作界面除非迫不得已这是最重要的一条。如果目标系统有 API优先用工具调用Computer Use 只应该用来处理“没有 API、没有结构化数据源”的场景。原因很简单Computer Use 每一步都可能失败而 API 调用是确定的。在架构设计上应该是“工具调用为主Computer Use 为兜底”。9.2 混合感知视觉 无障碍树纯截图方案成本高且不稳定。浏览器场景下强烈建议同时把无障碍树或 DOM 信息给模型。这样模型不必靠像素“猜”按钮而是可以直接拿到元素名称和坐标。公开评测数据也表明混合感知方案的准确率通常高于纯视觉方案。实现上Playwright 可以直接获取 accessibility snapshot示例思路如下snapshot page.accessibility.snapshot() # 将 snapshot 转成文本注入模型提示词9.3 动作空间要小执行层要稳不要直接让模型输出任意 JavaScript 或任意坐标它的自由度越高出错概率越大。建议把动作收敛到一个几十行代码就能实现的集合里点击、输入、滚动、按键、等待、完成。执行层需要做好异常兜底比如元素找不到时报告失败让模型重新决策而不是抛异常退出。9.4 强制人工审批凡是涉及不可逆操作的场景——提交订单、删除数据、发送消息、付款——必须加人工确认环节。即使失败率只有 20%一旦出错可能就是真实事故。可以做人机协同界面Agent 只有“操作权”没有“确认权”每次高风险动作先暂停由人审批后再执行。9.5 沙箱、快照、最小权限生产环境部署 Computer Use Agent至少要满足三个条件运行在虚拟机或隔离容器中操作目标是一台随时可以重置的“一次性电脑”使用独立的测试账号不携带真实登录态不使用管理员权限运行禁止访问系统关键目录。还要定期做快照。Agent 把系统搞乱后可以在几分钟内恢复而不是花一天时间手工修环境。9.6 成本控制截图是花钱的大头Computer Use 的真实成本往往不在模型推理本身而在图像 token。每轮决策都传一张完整截图几十步下来耗 token 会非常可观。控制成本的思路截图压缩到合理尺寸如 768 宽以内只有页面发生明显变化时才重新截图而不是每步都截对相同页面状态做缓存限制最大步数避免 Agent 在错误路径上反复试探。9.7 从窄场景切入不要一开始就做通用助手如果你的目标是落地请选择一个业务边界非常清晰的场景比如“登录内部后台后读取待办列表并导出为 Excel”“在指定网站上抓取特定商品价格”。这类窄场景的页面结构相对固定Agent 的成功率会显著高于随机的网页任务。先在一个窄场景里把成功率打到 80% 以上再扩展。9.8 关于后续学习方向如果你对 Computer Use 产生了兴趣建议按这个顺序往下深入深入了解无障碍树和 DOM 结构这是浏览器侧 Agent 的基石研究视觉 Grounding 模型和元素定位方法研究 Agent 评测方法论学会设计自己的任务集和指标关注 OSWorld、WebArena 等公开基准的更新用数据追踪技术进展。10. 总结现在要不要让 Agent 接管你的电脑回到标题的问题Can Agents Use a Computer Yet数据给出的答案是能用但只在一个很窄的边界内“可用”。它已经可以理解屏幕、点击按钮、完成简单的网页任务在特定的窄场景里甚至能跑出不错的效果但它还远没有达到“随便丢给它一个任务就能可靠完成”的程度。长任务、复杂界面、意外状态、错误恢复这些都是当前评测数据暴露出来的真实短板。所以我的建议是把 Computer Use 当作一种值得认真投入的能力但投入的方式要谨慎。优先用工具调用解决确定性问题用 Computer Use 解决“非它不可”的界面操作问题所有代码先跑通最小循环再逐步增加纠错、审批、日志和沙箱机制。不要把演示视频当成产品现状也别因为一次失败就否定整个方向——用数据说话这个领域才刚开始。