CUA智能体实战：让AI像人一样看屏幕操作电脑

如果你最近刷到“CUA”这个词别急着把它当成某个莫名其妙的网络梗。在 AI 圈子里CUA 指的是 Computer-Using Agent也就是能像人一样“看着屏幕、动手操作电脑”的智能体。2024 年底开始它频繁出现在各种技术分享里到 2025 年依然挂在热搜上原因是各家大模型厂商都在往“让模型替你把活干了”这个方向冲。CUA 解决的痛很直接过去我们让 AI 帮忙只能打字聊天、生成文字真正要“打开软件、填个表格、点几个按钮”还是得自己来。CUA 不一样你给它一句“把这封邮件转发给李经理”它能自己打开邮箱客户端、定位邮件、点击转发、输入收件人、发送全程不需要预先录制脚本也不需要人为固定每一步流程。这篇文章我会把 CUA 从原理到落地完整拆一遍包括它和传统 RPA 的区别、内部是怎么“看屏幕、做决策、执行动作”的再给出一套可以跑通的最小实现方案最后聊聊我实际使用过程中踩过的坑。想入局 AI Agent、做自动化测试、搞企业数字员工或者单纯好奇 AI 怎么操作电脑的读者都能从里面找到能直接用上的东西。1. CUA 到底是什么不是新 RPA而是会“看屏操作”的智能体1.1 从 ChatGPT 到 CUA多模态模型跨出了“对话”的边界大语言模型最初给人的能力是“对话”你问它答最多生成一篇文章或者一段代码。这种能力再强边界还是停留在“输出文字”它没法自己去点开浏览器、滚动页面、操作软件界面。CUA 的出现把这个边界往外推了一大步模型不仅理解你说了什么还能理解电脑屏幕上正在显示什么然后输出一个有实际意义的操作指令。CUA 之所以被称为“智能体”是因为它不再是单次问答而是处于一个完整的「观察-决策-执行-再观察」循环里。它能连续地看多轮截图每一步根据当前界面状态决定下一步点哪里、输入什么。这个过程中模型自己是“驾驶员”不是批处理脚本。类比一下传统聊天机器人像电话客服你问一句它答一句CUA 更像一个远程助理它坐在你的电脑前听着你的需求自己看着屏幕帮你把事情办了每做完一步还会回头确认效果。1.2 CUA 和 RPA、普通脚本的本质区别很多人听到 CUA 的第一反应是这不就是 RPA机器人流程自动化吗还真不是。RPA 的核心是把固定流程录制下来按照预设规则执行遇到界面变化往往就会崩CUA 的核心是“理解界面 动态决策”它没有一套写死的步骤。维度RPACUA界面适配依赖固定选择器、坐标、DOM 属性依赖模型对截图/可访问性树的语义理解流程变更需要人工修改脚本重新推理即可多数情况无需改代码异常处理靠预设异常分支靠模型观察新状态自主调整前期成本需要梳理流程、录制步骤需要设计 prompt、环境闭环、安全机制泛化能力一个流程一套脚本同一种操作可迁移到不同软件我见过不少团队用 RPA 做表单自动化最头疼的就是业务系统一改版选择器全失效脚本维护比新写还慢。CUA 的思路完全不同它基本是“看着界面操作”不依赖底层 DOM 选择器界面上按钮从左边挪到右边也没关系模型看一眼新截图就知道该点哪。它为什么现在才火核心原因是多模态大模型的成熟。模型要“看懂界面”不仅需要识别文字还需要理解按钮语义、布局结构、输入框状态这些在过去只能靠 CV 和 OCR 拼凑现在一个视觉语言模型就能搞定。算力、模型能力、指令跟随能力的同步提升让 CUA 从实验室走向了实际应用。2. 核心原理拆解CUA 是如何“看见”和“动手”的2.1 输入侧屏幕如何变成模型能理解的信息CUA 的第一步是“感知”。目前主流方案有两条技术路径很多实际产品是两条混合使用。第一条是纯视觉路径截取整个屏幕或指定窗口区域的截图把图片直接丢给视觉语言模型。这条路径普适性强不管什么操作系统、什么软件都能用微信、PS、浏览器、Excel 一视同仁。缺点是对截图清晰度敏感界面太复杂时模型偶尔会漏看关键区域。另外模型看到的是压缩后的图像小字号文本经常识别不准这个后面我会专门讲。第二条是可访问性树路径读取系统提供的 UI 结构信息比如 Windows 的 UI Automation、macOS 的 Accessibility API、浏览器的 DOM Tree得到类似 XML 的结构化内容里面包含了按钮名称、输入框状态、列表项层级等。可访问性树比纯截图更“干净”文字识别准确率很高还能得出精确坐标。缺点是很多应用没有完整实现无障碍接口拿到的东西残缺不全。我在实际验证时发现成熟的 CUA 产品通常会把两条路径拼接起来。例如大厂公开的 computer use 能力它会同时接收截图和可访问性树模型先基于结构化信息快速定位目标再用截图做视觉确认。这样既保证精度又不会因为缺少无障碍接口而瘫痪。2.2 决策侧多步任务怎么被拆解与执行CUA 的“大脑”和普通大模型没有本质区别区别在于输出格式被约束成“动作”。每一步模型接收到当前状态后会先生成文本推理再输出一个结构化的动作指令。一个典型的动作可能是{ reason: 任务需要打开邮件应用当前桌面没有邮件图标所以先点击启动台, action: click, x: 412, y: 856 }动作类型一般包括 click点击、type输入文本、scroll滚动、hotkey快捷键、wait等待等。这样就形成了一种“中间语言”把模型推理和真实操作系统连接起来。模型永远不用关心底层是怎么模拟鼠标的它只负责输出“该点什么、该打什么字”执行由工具层完成。CUA 的多步能力来自“子任务拆分”。模型目录里可以包含一个高层计划比如“先打开 Excel再找到销售数据表然后修改 B 列数据最后保存”。每一步执行完之后CUA 会截取新截图判断当前界面是否和预期一致。如果不一致它会根据差异调整下一步动作。这是 CUA 最有价值的地方它不是一个只执行一次命令的玩具而是能在一个任务上持续稳定“干活”的循环系统。我在设计自己的 demo 时专门会给模型一个“最大步数”限制避免它在一个错误状态里无限重复操作。2.3 反馈侧环境变化如何被感知CUA 的闭环不能只靠“发了指令就当完成”必须验证结果。最简单的验证方式就是对比执行动作前后的屏幕截图判断界面是否发生了变化。比如模型点击了“下一步”按钮如果新截图里没有出现预期的表单页就说明点击可能没生效或者点错了地方。很多早期实验都会遇到“任务根本没完成但模型觉得完成了”的情况。原因是模型只看了自己发出的动作序列没有认真解读最后一屏的状态。解决办法是让 prompt 明确要求每次结束任务前检查最后一张截图确认目标状态真的出现。为了减少误判还可以引入简单的状态向量比如检测目标窗口是否打开、目标元素是否存在、页面文字是否符合预期。这些轻量规则不是要替代模型而是充当“安全网”防止模型出现幻觉式完成。3. 自己动手实现一个迷你 CUA方案选型与落地步骤3.1 主流落地方案对比云端 API、开源模型、本地工具要跑一个 CUA 原型现在可选的路不少。我把常见的方案分成了三类分别对应不同需求。云端 API 方案直接使用大厂开放的 Computer Use 能力或视觉对话能力优点是开箱即用、模型能力强适合快速验证和做 PoC。缺点是单位调用成本相对高且把屏幕截图发送到云端会有数据隐私顾虑。适合业务数据不敏感、只想快速看效果的团队。开源模型方案基于 UI-TARS、OSWorld 这类开源模型或数据集搭建本地服务。优点是数据完全本地化可以私有化部署长期看成本更低。缺点是硬件门槛高推理速度不如云端而且开源模型的综合能力通常弱于商用大模型。自组装方案不去找专门的 CUA 接口而是拿一个支持视觉输入的多模态模型自己编写“截图-调用模型-执行动作”的循环。优点是灵活不绑定厂商好理解原理缺点是需要自己处理很多工程细节实际效果取决于模型基础能力。我自己验证时用的是第三种方案。先用一个视觉语言模型的 API 做原型等流程跑通后再考虑把模型替换成私有化部署版本。这样踩坑成本低迭代快而且每次换模型只要改一个 adapter不影响整体架构。3.2 最小可运行 Demo用 Python 让模型“看屏点按钮”下面这套脚本是 CUA 的最小闭环截取当前屏幕把截图发给多模态模型让模型返回一个动作 JSON然后用 pyautogui 执行点击。你可以把它当作一个可扩展的骨架。import os import base64 import json import pyautogui from openai import OpenAI client OpenAI(api_keyyour-api-key) def capture_screen(pathscreen.png): 截取当前屏幕并返回 base64 字符串 screenshot pyautogui.screenshot() screenshot.save(path) with open(path, rb) as f: return base64.b64encode(f.read()).decode() def ask_model_for_action(screenshot_base64, task): 让模型看截图输出一个动作 JSON response client.chat.completions.create( modelgpt-4o, # 换成你有权限访问的视觉模型 messages[ { role: user, content: [ { type: text, text: ( f任务{task}\n 请根据这张截图返回一个 JSON 动作格式如下\n {action: click|type|scroll|wait, x: 整数, y: 整数, text: 要输入的内容, reason: 简短说明}\n 坐标范围以图片实际尺寸为准。 ), }, { type: image_url, image_url: { url: fdata:image/png;base64,{screenshot_base64} }, }, ], } ], temperature0, max_tokens300, ) content response.choices[0].message.content # 清理模型输出中可能的代码块标记 if json in content: content content.split(json)[1].split()[0] return json.loads(content.strip()) def execute_action(action): 根据动作 JSON 执行真实操作 if action[action] click: pyautogui.click(action[x], action[y]) elif action[action] type: pyautogui.typewrite(action.get(text, )) elif action[action] scroll: pyautogui.scroll(action.get(clicks, -3)) elif action[action] wait: pyautogui.sleep(1) if __name__ __main__: task 打开电脑里的计算器应用 for step in range(5): # 最多执行 5 步 screenshot_b64 capture_screen() action ask_model_for_action(screenshot_b64, task) print(fStep {step 1}: {action}) execute_action(action) pyautogui.sleep(0.5)这段代码里有几个关键点需要说明。第一temperature必须设置得很低我通常直接设成 0因为动作输出需要确定性不需要创造性。第二坐标范围很重要模型是按它看到的图片尺寸输出坐标的如果截图是 1920x1080实际屏幕也是 1920x1080可以直接用如果你在代码里压缩了截图就必须把坐标按比例映射回真实屏幕否则会点偏。第三max_tokens不用太大动作 JSON 结构简单300 token 足够给多了反而容易让模型啰嗦。3.3 从 Demo 到可用系统权限、循环控制与任务状态机上面的 demo 只能算“能点”离“可用”还有距离。我在把它扩展成能处理真实任务的工具时加了三个关键设计。第一是任务状态机。把一次 CUA 执行过程切成几个状态INIT准备、RUNNING执行中、WAIT_CONFIRM等待人工确认、DONE完成、FAILED失败。模型每输出一个动作程序就进入 RUNNING执行完动作后重新截图判断是否达到目标如果连续多次没有状态变化就切换成 FAILED 并且停止。第二是人工审批闸门。对于删除文件、发送邮件、执行支付这类风险动作我在动作执行前加一道approval_callback只有通过审批才真正执行。这是非常实用的安全设计我后面会在踩坑部分详细解释为什么不能省。第三是完整 trace 日志。每轮循环的截图、动作 JSON、模型推理理由都存成文件。一来方便定位问题二来如果出了安全事故有完整的操作记录可以复盘。我见过一个团队跑 CUA 自动化时误操作导致文件被覆盖因为没有任何 trace完全说不清是哪一步出了问题最后只能自认倒霉。4. 踩坑实录我跑 CUA 时遇到的 5 个典型问题与排查方法4.1 截图分辨率低模型看不清小字怎么办模型对截图的识别能力和图片尺寸直接相关。我一开始图省事直接把 4K 屏幕截图压缩成 512 宽度再发给模型结果一个小按钮上的文字模型根本认不出来经常把“保存”看成“打开”。后来我调整策略不压缩整个屏幕而是让用户先用鼠标框选目标区域只对局部区域做高分辨率识别。系统会先做一次“全局视野”让模型确定目标大概在哪个区域然后放大该区域再做精细判断。两阶段识别后准确率提升非常明显。4.2 坐标偏移跨设备、跨分辨率带来的“点错”问题坐标偏移是 CUA 最容易踩的坑没有之一。模型输出坐标是相对于“输入图片”的如果你的代码对截图做了 resize但执行端 pyautogui 用的是真实屏幕坐标那么点击位置一定会偏。比如截图按 0.5 倍缩放发给模型模型说“点 (400, 300)”那真实屏幕坐标应该是 (800, 600)。这个问题在单机单分辨率下不容易发现一旦换电脑或者外接显示器偏移就会非常明显。排查办法是让模型顺手输出“图片尺寸”代码端再做一次比例换算宁可多传一个参数也不要默认两者一致。双屏环境更麻烦。副屏在屏幕左侧时坐标会存在负值很多模型的视觉编码器对负坐标支持很差。我的做法是把所有屏的截图拼成一张大图然后把副屏起点平移到正坐标执行时再映射回去。好在这个问题只在多屏场景出现普通用户较少遇到。4.3 动作死循环模型反复点同一个位置跑 CUA 时间长了你会发现一个典型现象模型卡在某一步反复点击同一个位置但界面没有任何变化。原因通常有两个。第一个是界面元素是动态加载的点击后内容需要时间渲染模型没等到加载完成就截图判断以为没点中。我加了wait动作和固定轮询间隔后这个问题少了很多。第二个是模型本身陷入了重复决策没有真正观察到界面变化。针对第二种情况我在调度层做了两个机制。一是动作去重如果一个完全相同的动作出现多次并且前后截图相似度超过阈值就强制终止当前任务并输出错误提示避免无限循环浪费 token。二是“无变化计数”每执行一步比较新截图和上一轮截图如果连续 3 轮没有实质变化就切换策略让模型尝试其他路径比如按 Tab 键代替直接点击。4.4 安全与权限让 AI 操作电脑最容易被忽视的坑只有亲手跑过才知道让 AI 直接操作真实电脑是一件多么“刺激”的事。有一次我的 demo 本来只是让它测试一个表单结果模型识别错了元素在桌面文件区域连续点了好几下差点把文件拖进错误目录。这给了我一个很重要的教训CUA 的安全问题不能靠模型自觉必须在系统层面强制。我现在坚持三个原则。第一默认不授权高风险操作删除、发送、付款、关闭未保存文件等动作全部必须人工确认。第二尽量在虚拟机或沙箱环境里做自动化测试虚拟机的系统恢复成本远低于实机。第三限制操作范围如果任务只需要操作某个浏览器窗口就把截图裁剪到该窗口并屏蔽其他区域减少误操作面。4.5 Token 开销与速度为什么一个简单任务也能烧掉很多钱很多人低估了 CUA 的 token 消耗。一张普通 1080p 截图缩小后视觉 token 通常在 1000 到 2000 之间一个界面复杂一点能到 3000 以上。一个 20 步任务跑下来光截图就可能消耗 4 万 token再加上模型推理输出的文本成本并不低。速度上一轮“截图推理执行”通常要 3 到 8 秒如果要操作 20 步整个任务可能要两三分钟。应对方法是“少看几次”。不是每步都必须把完整截图发过去如果界面没有变化可以复用上一轮的截图如果任务只需要某个区域的信息就只传裁剪后的局部截图。我还习惯把对话历史控制在最近 5 轮以内太早的截图和推理记录及时清理既能省 token也能减少模型注意力分散。对于高频重复任务我建议先跑一遍记录轨迹之后用固定脚本执行没必要让模型反复“重新发明轮子”。5. 下一步想象CUA 会怎么改变我们的工作方式5.1 从“聊天机器人”到“数字员工”CUA 真正值得期待的地方不是它能在你面前炫技点几个按钮而是它会重塑“人机协作”的边界。以前我们说数字员工本质上还是一堆 API 接口和定时任务的集合CUA 让数字员工第一次有了“肉眼可见的动手能力”。财务对账、客服查单、运维排查、测试回归这些依赖图形界面操作又重复枯燥的岗位都可能被它逐步渗透。我自己最看好的场景是“遗留系统自动化”。很多企业核心系统没有 API只有老旧图形界面RPA 脚本又脆弱CUA 反而显得异常合适。它不需要系统开放接口只要人能看屏幕操作它就能学着操作。这意味着大量被判定为“根本无法自动化”的流程现在有了重新评估的空间。5.2 给开发者的建议现在可以开始准备什么如果你想跟进 CUA 这个方向我建议不用等工具完全成熟再入场现在就可以做三件事。第一熟悉多模态模型的输入输出尤其是如何通过 prompt 约束模型输出结构化动作这是 CUA 的最核心技能。第二写一个最小闭环不需要复杂架构就像上面那套 Python 脚本一样先让自己对“截图-推理-动作-反馈”有体感。第三多关注事件驱动架构和无头浏览器CUA 只是决策层落地时仍然需要可靠的执行和监控底座。另外如果你要在团队里推 CUA别一上来就追求全自动。最稳打法是先用人工审批模式跑一个低频任务收集 trace 数据评估准确率、成本、速度再逐步放开权限。AI 自动化这件事步子迈太大会翻车小步快跑才符合实际。我个人在实际操作中的体会是CUA 的技术框架并不神秘真正的难点全在工程细节坐标精度、状态判断、安全闸门、成本控制。每一个细节单独拿出来都不难但组合在一起就筛掉了绝大多数半途而废的尝试。最近我跑通一个“自动整理下载文件夹”的流程后明显感觉到这类工具现在确实已经从概念验证走到了可以辅助干活的阶段只是需要我们在上层做好约束和引导。最后再分享一个小技巧所有 CUA 任务都从“最小可接受结果”开始定义比如“文件移到对目录”就算成功而不是等模型自己发挥成十全大补丸。这样你才有耐心把一个智能体调教到能稳定上班的状态。