从零搭建计算机使用代理(CUA)：让大模型像人一样操作电脑

1. 这届“会点鼠标的AI”到底是怎么工作的先说结论cua 不是某个具体产品的名字而是 Computer Use Agent计算机使用代理的通用缩写。简单来说它解决的是“AI 会聊天但不会干活”的问题——让大模型像人一样看着屏幕、握着鼠标、敲着键盘把任务从“你给我写个方案”变成“我直接帮你把方案填进后台系统并提交”。我第一次认真琢磨它是因为一个特别繁琐的内部流程每天要登录运营后台、点十几个菜单、填一张三十多行的表单、再截图留存。那会儿还流行写 RPA 脚本但业务部门隔三差五就调整页面结构脚本跟着改到崩溃。换 cua 这类方案以后维护成本反而降下来了因为模型是“看”界面不是“读死代码”页面微调只要不改变语义它基本能自适应。这个项目适合谁参考呢如果你正在做 AI Agent 相关研发或者你日常有大量重复性浏览器操作需要自动化再或者你好奇“大模型到底怎么操作电脑”这篇内容都能给你一条相对完整的实操路径。我会把架构拆解、核心实现、参数选择以及我踩过的一堆坑全部摊开讲代码也给到可复现程度。有一点先说明cua 类方案不等于“万能机器人”它在很多环节仍然受限于模型的理解能力、截图分辨率和执行环境的稳定性。与其把它想成科幻片里的 AI 助手不如把它当成一个“视力尚可但偶尔手滑的实习生”这样你对它的预期会更合理。2. 整体设计思路先搞清楚“看、想、动、验”四个环节2.1 cua 类项目都要面对的“感知-规划-执行”三角色问题任何一个 cua 项目逃不开这三层感知层模型怎么“看见”屏幕最常见方案是截图 可访问性树Accessibility Tree少数方案用视频流或录屏帧。规划层模型怎么决定下一步点哪里一般是把截图和任务描述喂给多模态大模型让它输出一个结构化动作指令比如click(x320, y480)或者type(textxxx)。执行层动作指令怎么落到真实环境通常是浏览器自动化框架如 Playwright或者操作系统级的 UI 自动化如 Windows UI Automation。这个三角色设计不是我发明的而是几乎所有计算机使用代理的通用范式。最早的一批学术项目比如“WebGUM”、“Mind2Web”就已经在探索“网页截图 动作序列生成”这条路。后来商业产品把这条路产品化才让 cua 从一个研究概念变成一个能落地的工程框架。我做这套系统时最大的感悟是感知层做得好的项目成功率远高于规划层做得好的项目。原因很简单——模型再聪明如果看错了坐标、读漏了按钮后续所有动作都是空中楼阁。2.2 为什么选择“截图可访问性树”而非纯视觉或纯 DOM很多初学者会问直接把网页 DOM 发给大模型不就行了吗为什么还要截图我早期也这么干过后来发现两个致命问题视觉信息确实有用很多按钮是 JS 动态渲染的DOM 里能看到但用户根本找不到反之也成立。模型需要理解“用户眼中的界面长什么样”才能做出符合直觉的操作决策。Token 成本爆炸一个典型的中型后台页面DOM 序列化成文本可能超过 5 万 token传给模型做实时决策延迟和费用都扛不住。截图压缩到 768p 宽一般只需要 1000~2000 token 左右。所以我的推荐方案是截图负责“看”可访问性树负责“精确点”两者互补而不是二选一。截图让模型理解整体布局可访问性树提供元素的精确坐标和标签。模型先看截图做粗规划再读取局部可访问性树做细动作效率和成功率都能上来。2.3 核心循环从“一句话任务”到“一连串操作”cua 的灵魂在于一个“感知-决策-执行-观察”的循环接收任务描述例如“把这份 Excel 中的数据导入后台系统”。截取当前屏幕状态。模型基于截图思考当前处于什么页面距离目标还差几步。输出一个结构化动作click、type、scroll、wait、finish。执行动作重新截图回到第 2 步。直到模型判断任务完成输出finish动作或达到最大循环次数。这个循环最微妙的地方在于“多少次合适”。我很早前用固定 30 次上限结果复杂的跨系统任务经常做到一半被截断。后来改成“动态上限 卡死检测”比如模型连续输出三次相同坐标的点击且界面没有任何变化就主动终止避免死循环烧钱。3. 最小可行实现直接从零跑通一个能点网页的 cua3.1 技术选型与环境准备基于“看截图做决策”这个思路我搭了一套最小实现组件如下组件选型说明多模态模型GPT-4o / Claude 系列任选支持视觉的模型负责“看”截图并输出动作浏览器自动化PlaywrightPython 版负责截图、点击、输入坐标解析正则或 JSON 模式从模型输出中提取动作指令任务编排Python 脚本 asyncio串起循环环境准备按常规操作就行pip install playwright playwright install chromium如果你在国内网络环境给 Playwright 装浏览器时可能要配镜像或离线包具体方式这里不展开遇到问题直接查官方文档都有解决方案。选 Python 是因为生态成熟调试方便选 Chromium 是因为它在自动化场景最稳定渲染一致性好。3.2 写一个最简循环体可直接复制的核心代码下面这段代码是一个最简 cua 循环核心逻辑就三件事截图、问模型、执行动作。import asyncio import base64 import json import re from playwright.async_api import async_playwright from openai import AsyncOpenAI client AsyncOpenAI() # 默认读取环境变量 API Key SYSTEM_PROMPT 你是一个计算机操作助手。我会给你一张当前屏幕截图和任务描述。 你只需要输出一个 JSON 动作格式为 {action: click, x: 100, y: 200} 或 {action: type, text: hello, x: 100, y: 200} 或 {action: scroll, direction: down} 或 {action: finish, reason: 任务已完成} 坐标是相对于图片宽高的像素坐标。 async def capture_screenshot(page): 截图并转成 base64 path /tmp/screen.png await page.screenshot(pathpath, full_pageFalse) with open(path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) async def ask_model(base64_img, task): 向多模态模型询问下一步动作 resp await 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,{base64_img}}} ]} ], temperature0, max_tokens300 ) return resp.choices[0].message.content def parse_action(raw): 从模型输出中提取 JSON 动作 match re.search(r\{.*\}, raw, re.S) if not match: return None return json.loads(match.group(0)) async def run_agent(url, task, max_steps20): async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) page await browser.new_page(viewport{width: 1280, height: 800}) await page.goto(url) for step in range(max_steps): img await capture_screenshot(page) raw await ask_model(img, task) action parse_action(raw) if action is None: print(f[Step {step}] 无法解析动作{raw}) break print(f[Step {step}] 执行动作{action}) if action[action] click: await page.mouse.click(action[x], action[y]) elif action[action] type: await page.mouse.click(action[x], action[y]) await page.keyboard.type(action[text]) elif action[action] scroll: await page.mouse.wheel(0, 300 if action.get(direction) down else -300) elif action[action] finish: print(f任务完成{action.get(reason, )}) break await asyncio.sleep(1) # 等待页面渲染 await browser.close() if __name__ __main__: asyncio.run(run_agent( urlhttps://example.com, task点击页面上的登录按钮 ))这段代码我故意写得非常直接没有做太多抽象目的就是让第一次接触 cua 的人能一次跑通。你换一个任意网页把任务描述改一下它就能开始干活。当然跑通只是第一步真正好用还差得远。3.3 为什么模型要输出坐标而不是“元素ID”一个重要设计决策让模型输出坐标还是输出元素语义比如“点击 id 为 login 的按钮”我测试下来纯坐标的优势是实现简单、动作丰富不依赖 DOM 解析任何界面都能用劣势是精度依赖截图分辨率而且模型偶尔会算偏移。纯语义输出的优势是稳定精准元素只要在可访问性树里就能精确命中劣势是依赖场景跨应用、跨网页时不同的 UI 框架生成的语义结构差异很大模型容易懵。我现在的方案是两阶段模型基于截图给坐标如果坐标周围的语义信息和预期不符就用 Playwright 的locatorAPI 做二次校验。这个“校验”环节能把点击成功率从 70% 拉到 90% 以上代价是多一次 DOM 查询非常值得。4. 实操过程中最容易被忽视的四个关键细节4.1 截图分辨率与坐标换算这是 cua 项目里翻车率最高的一环。Playwright 的page.screenshot()默认截的是视口大小但不同设备的 DPRDevice Pixel Ratio会导致物理像素和 CSS 像素不一致。模型看到的图是 1280×800而实际鼠标点击用的也是像素坐标两者如果不一致点击就会偏。解决办法统一用 CSS 像素坐标截图时强制指定viewport尺寸并检查截图实际输出尺寸与viewport是否一致。如果你用了full_pageTrue那坐标系统会变成整页高度注意区分视口坐标和页面坐标。我的调试技巧是在截图生成后用 OpenCV 画一个十字线网格覆盖在图上再让模型标注目标点位置肉眼对比模型给的坐标和实际按钮位置。这个“视觉校准”流程虽然土但非常管用。4.2 页面加载不完全导致的“假点击”动态网页最大的坑模型看到了按钮但按钮的点击事件绑定还没挂上或者弹窗遮罩已经盖住了按钮鼠标点下去“看似点击了实际没反应”。我总结了一个三层等待策略短等待200ms适应前端动画。元素等待最多 5s用 Playwright 的wait_for_selector确认关键元素存在。稳定等待500ms 连续截图无变化确认界面已经渲染稳定。注意稳定等待不能太长否则整个任务的耗时会被拖得非常严重。我一般只在登录跳转、表单提交这类关键节点后才启用稳定等待。4.3 Token 消耗与成本控制的平衡每次循环都要发一张截图给大模型这个成本很多人一开始没算清楚。一张 1280×800 的截图按中等质量压缩后单次调用成本大概在 0.01~0.05 元人民币取决于模型和供应商。一个 20 步的任务大约就要花 0.2~1 元。如果是高频任务这个费用会直线上升。控制成本的几个实操办法降低截图频率只在“动作执行后”截图不在“执行前”多截。减小图片尺寸我一般压到 768px 宽模型理解能力几乎不下降。用快慢模型组合简单动作点击、滚动用轻量模型判断复杂推理填表、判断才调用大模型。缓存中间状态如果页面没变化不重复向模型发请求。4.4 安全边界给 cua 上“护栏”模型具备操作电脑能力后安全边界是必须考虑的事。我给自己定的几条底线永远只在沙箱环境测试虚拟机或 Docker 容器中运行高风险操作。对模型输出的动作做白名单校验比如只能访问指定域名禁止访问系统文件。设置“人工确认”节点支付、删除、发送等不可逆操作前必须暂停。记录全部动作日志方便事后审计。这不是过度谨慎。在实际运行中cua 完全可能出现模型“理解偏差”导致的危险动作比如在错误输入框里填入敏感内容、误点删除按钮。没有护栏一次失误就可能造成严重问题。5. 典型问题排查与解决方案实录5.1 模型“睁眼瞎”看到了但点不对症状模型输出坐标和按钮位置有稳定偏差比如每次偏右 30px。原因排查截图尺寸和模型推理时假设的尺寸不一致。我会在截图时把实际尺寸通过文本字段告诉模型防止模型“猜尺寸”。浏览器缩放比例不是 100%。Windows 系统如果开启了 125% 缩放Playwright 的坐标系统会跟着变。解决办法是启动 Chromium 时加参数--force-device-scale-factor1。页面有横向滚动。模型没有意识到页面左边还有一块被截掉的内容也会造成判断错误。5.2 任务死循环同一个动作重复执行症状模型反复点击同一个位置界面没有任何变化但模型以为自己操作得很顺利。原因模型缺少“观察结果”的反馈。它点了按钮但没意识到点击后页面没有改变所以继续重复。解决办法在每轮循环里对比上一张截图和当前截图如果差异小于阈值就将“页面未变化”作为提示注入给模型。连续 N 次相同动作且页面无变化强制终止任务。这个“差异对比”功能我以前用 OpenCV 的compare_ssim做后来图省事直接用像素差值百分比效果也够用。5.3 模型输出格式不稳定症状模型偶发输出{action: click, x: 320, y: 480}字符串代替数字或者多出一些解释性文字。原因即使你拼命在 system prompt 里强调“只能输出 JSON”模型有时也会不听话。尤其是用户在 prompt 里添加了多余上下文之后格式约束会被稀释。解决办法使用支持 JSON Mode 的模型直接在 API 参数里强制response_format{type: json_object}。解析时不要贪多用正则抓取第一个{...}片段再走 JSON 解析解析失败就重试一次。如果对稳定性要求极高可以用 Pydantic 之类的工具定义输出 schema再加一次校验。5.4 多步骤任务中间失败后的恢复症状任务执行到第 15 步时页面突然弹出一个系统升级提示把后面的按钮全挡住了。模型不知道这个弹窗是什么也不确定该不该关掉它。原因cua 没有“异常恢复”能力它只会顺着当前画面往下走。我的解决方案是给 cua 增加“中断识别”逻辑截图后先用一个轻量图像分类器判断屏幕上是否出现“弹窗/遮罩层”特征。如果出现就先把弹窗区域的“关闭”按钮坐标交给模型判断或者强制走“按 ESC”动作。这个方法虽然不优雅但在大多数网页场景下都能把任务救回来。6. 从一个能跑的 demo到一个能用的 cua6.1 引入真正的任务记忆与子任务拆解到这一步你已经有了一个能点鼠标的 AI。但离“能干活的 AI”还差很远。核心差距在于复杂任务需要拆解成子任务每一步都心知肚明。我常用的方式是把任务拆成“阶段”登录阶段打开页面输入账号密码点击登录等待跳转。数据准备阶段读取 Excel整理成待填写字段列表。表单填写阶段遍历字段逐项填入对应输入框。提交阶段点击提交确认成功提示。这种阶段划分的意义在于如果某一步失败可以只重跑该阶段而不是整个任务从零开始。我用 dict 记录每个阶段的状态并输出到 JSON 文件里随时恢复。6.2 给 cua 配一个“人机协作”模式我踩过最大的坑是误以为“全自动”才是终极形态。后来发现在真实业务场景里全自动能跑通的任务 70%但有人机协作的任务能跑到 95%。具体做法是把高风险或易混淆动作标记为needs_human模型输出这类动作时暂停执行弹出人工确认框。人工确认通过后继续跑不通过则让模型重新规划。这个设计很轻量但能挡住大量低级错误。6.3 从“能点”到“能想”让 cua 具备自我纠错能力最后一步是为 cua 引入“自我检查”能力。具体是在每个动作执行完以后再截一次图让模型判断“上一步操作是否成功了”。这个“事后验证”非常反直觉因为大家都觉得会拖慢速度。但实测下来它带来的成功率提升远大于速度损失。原因很简单很多错误如果在发生后立刻被发现纠正成本极低如果整个任务跑完再检查往往已经找不到是在哪一步错的。验证方式可以很简单让模型输出一个布尔值和一句理由比如{success: false, reason: 按钮未出现可能点击未生效}如果连续三次验证失败cua 会选择回退到上一个成功阶段而不是继续硬扛。7. 写在最后的实操心得我个人从零搭完这套 cua 系统后最大的体会是技术上最难的其实不是模型而是“系统化地处理不确定性”。模型永远会给出预料之外的输出环境永远会出现预料之外的界面变化你的架构设计越宽容系统就越稳定。如果你也想尝试我建议从最简单的“点击网页按钮”开始先把循环跑通再逐步加入坐标校验、截图对比、异常恢复这些能力。不要一开始就贪多求全否则调试过程会让你非常痛苦。最后分享一个非常实用的小技巧给模型看截图时可以在图片上叠加一层网格线并把网格坐标直接标注在图上。这样模型输出的坐标精度会明显提升因为人和模型在有网格辅助的地图上找位置比在空白地图上找位置要准得多。就这一条能把你的 cua 点击准确率提升好几个百分点值得一试。