1. CUA到底要解决什么从“会聊天的AI”到“会干活的AI”最近在技术社区里“cua”这个缩写出现的频率明显高了起来很多朋友第一次看到它时都以为是拼写错误其实它指的是 Computer-Using Agent也就是“计算机使用智能体”。如果你看过网上那些“让AI自己打开Excel处理数据”“让AI帮忙登录系统、导出报表”的演示视频那背后的主角基本都是这类技术。在我看来CUA最大的价值不是多了一个新名词而是把AI从“只能在一个对话框里输出文字”的状态往前推了一大步推到了“可以直接坐在电脑前操作软件”的状态。这篇文章我想围绕CUA把我自己动手搭建、实测、踩坑的过程完整拆出来给正在做AI Agent、RPA替代方案或者想给办公自动化场景找一条新路子的朋友做一个参考。要理解CUA得先回到一个老问题上AI到底能替人干什么过去很长一段时间大语言模型能做的只是“生成内容”——写邮件、写代码、总结文档这当然很有用但用户真正消耗时间的地方很多是发生在软件操作层面的。比如从ERP里导出数据、在OA里走一个审批流程、把PDF里的表格粘贴到Excel里重新排版。这类工作的共同特点是操作路径明确、重复度高、没有创造性但又必须有人坐在电脑前一步步点。过去我们对付这种场景靠的是脚本和RPA为什么CUA会成为一个更值得关注的解法我下面把这两种传统思路的边界说透。1.1 传统API方案和RPA各自卡在哪里先看API方案。它的逻辑很干净软件方开放接口你用代码直接调。问题在于真正承载业务的一堆老系统根本没有API或者API覆盖的操作范围非常有限。我有一次想自动化一个内部客户管理系统的“导出客户列表”功能翻了几十页文档发现这个接口根本没有对外暴露最后只能回到“模拟人点鼠标”这条路。API方案还有一个隐性成本你每对接一个新软件就要重新读一遍对方文档这些工作量一点不比人工操作省。再看传统RPA。它的思路是“录制一套动作脚本然后回放”这在界面结构非常稳定的场景下确实能跑比如固定的网页表单、固定的Windows窗体。但一旦界面改版、分辨率变化、弹窗时机不对脚本就会成片地失灵。更麻烦的是很多老系统用的是非标准控件、图片按钮、嵌入式PDFRPA的选择器根本抓不到。我见过一个团队维护了上百条RPA流程每个季度光修选择器就要花掉两个人一周的时间。这说明RPA本质上是在“预设界面”的前提下做自动化它缺少对界面内容的理解能力。1.2 CUA换了一个全新的解题角度CUA的思路其实特别朴素人是怎么操作电脑的人看屏幕理解界面上有什么然后决定点击哪里、输入什么操作完再看一眼屏幕确认结果。那如果给AI接上“眼睛”和“手”让它也走一遍这个循环呢CUA的核心闭环就是四步截图感知界面内容多模态模型理解当前状态并做决策输出一个具体的鼠标键盘动作执行动作后再次截图验证结果。这个闭环不断重复直到完成用户给定的目标。和传统RPA相比CUA最大的差异在于它不预设界面的结构而是把“理解界面”这件事交给视觉模型实时完成。也就是说哪怕软件换了皮肤、按钮位置变了只要屏幕上的信息还能被模型看懂它就有机会重新规划路径。从理论上讲只要一个软件是人能操作的CUA就能操作——只要这个软件的操作本质是“看屏幕鼠标键盘”。1.3 CUA和当前主流“Agent”的区别现在市面上很多Agent产品本质是“调用工具型Agent”你给模型一把计算器工具、一个数据库查询工具、一个发邮件的函数模型根据用户指令决定调用哪个。这种Agent依赖的是预先封装好的接口。CUA则完全面向图形界面它不依赖后端接口也不依赖开发者的工具schema它把所有软件都还原成“屏幕像素操作事件”。我把三者的能力特征整理成一张表方便对比参考维度工具调用型Agent传统RPACUA依赖条件需要开放API或预置工具界面结构稳定、选择器可用软件能在屏幕上渲染感知对象结构化数据DOM元素/控件坐标整张屏幕画面泛化能力受工具范围限制较差改版即失效理论较强取决于模型能力使用门槛需要开发接入需要录制和维护流程需要配置模型和运行环境典型场景数据查询、文本生成高频表单批量提交跨应用、跨系统的复杂操作从这张表能看出来CUA并不是要取代所有方案而是把“无法用API自动化、又无法用RPA稳定自动化”的那部分场景补上了这正是它热度持续走高的根本原因。2. 拆开CUA的黑盒感知、规划、执行三个组件一个都不能少如果只是把CUA当作一个“截图模型鼠标键盘”的三件套那做出来的东西大概率只能在演示视频里跑。真正能稳定完成的CUA项目至少要把感知、规划、执行三个环节各自的工程难点想清楚。下面我逐层拆解。2.1 感知层把一整个屏幕变成模型真正“看得懂”的信息感知层的第一件事是截图但截图远没有想象中那么简单。首先是分辨率问题一台普通的1080p显示器一帧画面大约是200万像素直接塞给视觉语言模型做全图理解token消耗非常高而且很多模型的视觉编码器对超大图片的处理并不可靠。实际工程里通常需要先做降采样或者把屏幕切成若干区域分别理解再或者先让OCR提取出屏幕上的文字和坐标作为图像的补充输入进行整合。第二个坑是系统缩放。Windows系统默认的“显示缩放”往往是125%或150%这会导致截图尺寸和实际鼠标坐标对不上。比如屏幕物理分辨率是1920×1080但系统按125%渲染那么逻辑坐标和物理坐标之间就差了1.25倍。这个问题我在后文会专门展开因为它是新手最容易踩的第一个坑。第三个坑是动态界面很多页面在加载中、动画播放中、弹窗淡入中这三种状态下的画面差异很大如果模型看到的是“半成品”截图它给出的操作指令也必然失真。所以感知层不能只做“截一张图”而是要连着做“截图—判断画面是否稳定—稳定后再理解”。2.2 规划决策层把大目标拆成一步一步的实时决策规划层负责回答“下一步做什么”。早期我做这种自动化时总想让模型在一开始就把所有步骤一次性规划出来比如“第一步打开浏览器第二步访问网址第三步点击登录……”实践证明这条路行不通。原因是真实环境充满意外弹窗可能挡住按钮、密码输入框可能提前出现、网络可能变得很慢。一旦实际情况和规划不一致整条前置规划就全废了。因此现在主流的做法是走ReAct循环也就是“推理→行动→观察”交替进行模型只决定当前这一小步执行后立刻通过截图观察结果再根据新状态重新决策。这种机制下上一步的失误并不会导致全局崩溃模型有机会在下一步修正回来。上下文记忆也属于规划层的关键内容。超过十五步的操作任务模型必须记住自己从哪来、已经完成了什么、当前卡在哪一步。工程上通常把完整的多轮交互历史喂给模型但代价是token量持续膨胀。更经济的方式是维护一个结构化的“任务进度摘要”每一轮结束后让模型用一段话总结当前状态下一轮只带这个摘要而不是把所有历史截图全部重新喂一遍。实测下来这样的方案在保持一定成功率的前提下能把长任务的token成本压缩将近一半。2.3 执行层模型的动作空间如何定义反馈闭环怎么建立执行层直接影响CUA能不能“落得下手”。目前主流有两种动作空间一种是像素坐标级模型直接输出目标位置的x、y坐标然后由自动化框架执行移动和点击另一种是语义级模型输出“点击名称为‘保存’的按钮”这类指令由底层的UI理解模块把指令转换成一个控件位置。像素级的好处是逻辑简单、不需要适配不同应用的控件树但坐标一旦因为窗口移动、界面变化而偏移就很容易点错。语义级更稳定但工程实现成本高尤其面对非标准自绘控件时底层模块可能根本识别不出“保存”按钮在哪里。我个人的建议是项目初期先做像素级把模型本身的逻辑能力验证通过再考虑是否引入语义级定位。闭环验证环节也必不可少通常的做法是记录动作执行前后的两张截图计算它们之间的差异程度结合OCR识别结果判断界面是否产生了预期变化。比如点击一个“下一步”按钮后如果截图上出现了“请填写邮箱”的提示系统就知道动作生效了如果两张截图几乎没变化那就说明点击可能落在了一个无效区域需要触发重试或者上报错误。没有这层反馈验证CUA就只是一个“盲操作的机械手”出错了根本不知道。3. 从零搭一个最小可用的CUA Demo选型、代码与运行流程这一节我给出一个能够完整跑通的CUA最小实现路径不依赖任何商业产品。核心思路是用一个Python主循环串联“截图→调模型→解析动作→执行→再截图”这几个步骤让AI在一台Windows虚拟机上完成“打开计算器并计算2468×1357”这个小任务。麻雀虽小五脏俱全跑通它之后换到其他应用和任务只是改目标描述的问题。3.1 环境准备与基础技术选型先列一下我用的技术栈都是公开通用的方案你也可以根据自己的实际情况替换。视觉理解部分用的是当前主流的视觉语言模型支持图片文本输入能输出格式化内容即可例如GPT-4o、Gemini、Qwen-VL等。桌面控制部分用Python结合pyautogui和pynput这两个库前者负责定位鼠标、点击、滚轮和键盘输入后者负责监听全局按键事件方便随时中断自动化流程。运行环境我强烈建议放在Windows虚拟机里而不是直接跑在主力开发机上。原因很朴素自动化程序一旦因为模型误判而疯狂点击你能一键恢复虚拟机快照而不是眼睁睁看着自己的开发环境被弄得一团糟。为了更好地模拟真实办公环境我建议在虚拟机里固定显示分辨率为1920×1080并把Windows显示缩放设置为100%。这一步能规避大多数坐标偏移问题。同时安装一个常用输入法和计算器应用方便后续扩展任务。3.2 主循环代码的结构与运行流程下面是一个最小可用的Python主循环代码不长但已经包含了一个CUA系统的骨架import time import json import pyautogui import base64 from io import BytesIO from PIL import Image # 这里替换为你选择的视觉语言模型的调用封装 from vlm_client import request_vlm TARGET 打开Windows计算器计算 2468×1357并读出结果 ACTION_PROMPT 你是计算机操作助手。你可以看到屏幕截图。 你的任务目标是{target} 可用动作每次只能输出一个 - click x y : 点击屏幕坐标(x, y) - input text : 输入文本 - key key_name : 按下快捷键key_name如 win, enter, esc - wait : 等待界面稳定 - done : 任务已完成 输出必须是严格的JSON {{action: click, params: {{x: 960, y: 540}}}} 约束 1. 只根据当前截图上的真实内容行动不要假设界面上存在某个按钮。 2. 每次只执行一个动作不要连续点击。 3. 执行完动作后系统会自动截图供你观察结果。 4. 如果同一动作连续失败3次输出 {{action: error}}。 MAX_STEPS 40 def take_screenshot_bytes(): img pyautogui.screenshot() buf BytesIO() img.convert(RGB).save(buf, formatJPEG, quality80) return buf.getvalue() def execute_action(action, params): if action click: pyautogui.click(params[x], params[y]) elif action input: pyautogui.typewrite(params[text], interval0.02) elif action key: pyautogui.hotkey(*params.get(modifier, []), params[key]) elif action wait: time.sleep(0.8) return time.time() def run_cua(targetTARGET, max_stepsMAX_STEPS): history [{role: user, content: f任务目标{target}}] step 0 while step max_steps: step 1 screen take_screenshot_bytes() # 将截图、动作约束和历史上下文一起交给模型 response request_vlm(screen, ACTION_PROMPT.format(targettarget), history) try: parsed json.loads(response) except json.JSONDecodeError: parsed {action: wait, params: {}} action parsed.get(action) params parsed.get(params, {}) if action done: print(任务完成模型认为已经达到目标状态) break if action error: print(模型报告连续失败需要人工介入) break execute_action(action, params) # 动作后留出渲染时间再进入下一轮截图判断 time.sleep(0.5) if __name__ __main__: run_cua()这段代码的核心逻辑就是那个while循环。每一轮循环系统做三件事截图发给模型、模型返回一个动作、系统执行动作。前面提到的“反馈闭环”靠的是每一轮循环都会重新截图让模型看到执行动作后的真实界面状态。注意我在代码里加了一个MAX_STEPS的上限防止模型陷入无限循环。这类保护机制在真正跑起来的时候比任何优化都重要。3.3 任务执行过程中模型最可能的走法跑起来后整个执行路径大致是这样的第一轮模型看到当前桌面截图判断出需要打开开始菜单于是按下Win键第二轮截图显示开始菜单搜索框模型输入“计算器”第三轮截图显示搜索结果模型点击“计算器”应用图标第四轮截图显示计算器窗口模型逐个点击数字键2、4、6、8、乘号、1、3、5、7、等号最后一轮模型从屏幕上的结果区域识别出计算结果输出done。整个过程可能稳定地在10步左右跑完。但这里必须说明上面这个路径是“理想状态”。实际执行时模型可能会点错、输入法可能没有切换成英文、计算器窗口可能没有出现在最前面这些都会导致路径偏离。设计CUA系统的一个重要心态就是“接受每步都有误差”依靠循环反馈来不断修正而不是指望模型每一步都对。后面我会具体讲几个我真实踩过、也真实花时间排查过的坑这些比顺利的流程更有参考价值。3.4 为什么prompt要这样设计给模型的prompt不是随便写的我试过好几版最后固定成上面那套模板原因有三点。第一动作空间必须收敛。如果不明确告诉模型只能用这几种动作它会自由发挥输出一些无法执行的指令。第二界面交互必须闭环。prompt里反复强调“执行后系统会自动截图”是为了让模型理解它处于一个连续的决策环境中每一次动作都会带来新的观察而不是一次性做完所有事。第三触底保护必须内建。明确要求连续失败3次就输出error这个规则极大地降低了模型在异常状态下反复折腾同一个无效动作的概率。4. 实测中的翻车记录三个典型问题与完整排查过程光讲顺利路径对实际做项目帮助不大。这一节我按“现象→排查链路→修复方案”的方式把我印象最深的三个CUA实测问题完整写出来这些都是常规文档里不会讲的细节。如果你正在做类似项目大概率会碰到其中至少一个。4.1 坐标偏移屏幕缩放与坐标系不一致导致的幽灵Bug第一次跑通demo的第二天我把同样的代码放到另一台笔记本上运行结果模型开始“胡乱点击”它明明在截图上看到了按钮点击位置却总是偏到按钮下方。我最初以为是模型能力问题后来静下来做了两步排查才定位到根因。第一步我打印出截图尺寸和pyautogui返回的鼠标坐标范围发现截图是1920×1080鼠标坐标范围也是1920×1080看起来没有矛盾。第二步我把模型点击前的截图和点击后的截图叠在一起对比发现同样的逻辑坐标第一台机器点准了第二台机器偏了大概四分之一屏幕。这时候我才想到去查Windows显示缩放果然第二台笔记本默认是125%倍率。也就是说截图是以物理像素绘制的而鼠标坐标系统经过了系统缩放层的换算两者不在同一个坐标系里。修复方案是双管齐下在虚拟机里直接把显示缩放改为100%让逻辑坐标和物理坐标一致同时我在代码里加了一个环境检测函数启动时自动读取当前系统的缩放比例如果非100%则把所有点击坐标除以缩放因子后再传给pyautogui。从那以后坐标偏移动的问题基本消失了。这个排查过程看起来简单但新手往往会在“模型理解错界面”这个方向上浪费大量时间实际上问题在操作系统层面。4.2 加载时序模型总是点在半成品页面之上第二个高频问题出在页面或应用加载的异步过程上。模型看到一个窗口正在打开就立刻自信地输出了点击指令但此刻窗口内容还在渲染按钮根本没出现在目标位置。于是点击落空下一轮模型看到画面没有变化又尝试点击同一个位置连续几次后就彻底乱了流程。排查时我发现问题不在模型而在于“截图时机”。动作执行后系统立刻截屏画面上可能还停留着上一个窗口的半透明残影或者loading动画模型无法判断界面是否已经稳定。修复思路也不复杂在每轮动作执行后增加固定等待时间给应用留出渲染窗口同时给模型提供wait动作选项让它自己决定是否需要等待。工程上还加了一个简单检测——截图中如果识别到“加载中、请稍候、spinner动画”这类典型加载信号系统直接拦截并延迟到信号消失后再进入决策轮。这个坑给了一个很深刻的经验CUA的很多问题并不是模型不够聪明而是交互链路中缺少“帧率控制”。人操作电脑时会本能地等界面稳定但模型没有这个本能它只能依赖我们给它设计的节奏。4.3 模型幻觉一本正经地点击一个根本不存在的按钮第三个问题最危险模型“看见”了一个界面上根本不存在的按钮。现象是截图里明明没有“确认”按钮模型却输出点击坐标而且是在一个空白区域点了一下。最开始我百思不得其解后来把模型的完整思考过程打印出来才明白它的文本先验太强当任务涉及“提交订单”时模型“猜”界面上应该有一个“提交”按钮于是它选择性地忽略了截图里没有这个按钮的事实直接编了一个坐标出来。这是大模型在视觉任务上的典型幻觉问题文字先验压过了视觉输入。针对这个情况我改了三层。第一层是prompt硬约束明确写“只基于截图里真实可见的元素行动看不到就是看不到不要猜”。第二层是要求模型先描述界面再给动作——这一步不能省让模型先输出它在图中识别到的一组控件名称和坐标然后再基于这些控件决定动作相当于加了一道“视觉校验”。第三层是设置失败重试上限同一个动作连续失败三次系统就不再让模型自行尝试而是把现场截图和过程日志保存下来转交人工处理。加了这三层之后幻觉点击的情况大幅下降但并没有完全消失这也是目前CUA落地时仍然需要人工兜底的主要原因。5. 从Demo到交付可靠评测、成本控制和安全边界一个都不能少跑通一个demo和交付一个能用的CUA项目之间距离比大多数人想象的要大。如果只是内部自用前面几章的流程已经足够。但要是想把CUA作为一种能力接入业务流程有几件“看不到的功课”必须提前做我在这章把最重要的三块讲清楚。5.1 先搭评测集再谈优化我和不少同行交流过CUA项目的失败案例发现高度一致的问题大家一上来就追求“把复杂任务跑通”跑通了就开始欢呼然后发现下一次运行成功率忽高忽低根本不敢上线。问题的根源是缺少一个可量化的评测集。正确的做法是在项目启动的第一周就建立20到30个真实任务的评测集合覆盖不同软件、不同难度每个任务记录五个核心指标任务成功率、任务平均步数、单步操作错误率、平均耗时、以及人工介入次数。后续每换一次模型、每改一次prompt都拿这套评测集跑一遍对比前后数据再决定是否上线。这套评测集的建立会让CUA的开发方式发生质变。原来是在“感觉它的表现变好了”之后是在“数据告诉我它变好了”。我自己的项目里有一版prompt改动让成功率从58%提到76%靠的正是这种量化评测否则那版改动可能就埋没在各种主观感受里了。5.2 成本与响应速度的平衡CUA的运行成本比普通对话Agent高出一个量级。普通对话一次可能只消耗几百个tokenCUA一个任务几十步每一步都要传截图给视觉模型一张图可能上千个token整个任务下来几万token是家常便饭。如果业务量每天上千次成本会迅速变成一个需要认真规划的问题。控制成本有三个常用手段。第一个是任务分层先用一个便宜的小模型判断“当前界面属于什么状态”再决定是否需要调用强模型做完整推理。很多界面状态是稳定的不需要大模型每次从头理解。第二个是技能缓存如果某个操作路径被成功执行过系统可以把路径保存下来下次遇到相同任务时直接回放固定步骤只在出现异常时才切换回模型推理。第三个是模型选型的梯度化简单任务用轻量级视觉模型只有在复杂任务中才启用更强的模型。这三个手段组合使用能把单位成本压到原来的40%左右同时保持大部分任务成功率不下降。5.3 安全与权限让AI操作电脑之前先想好怎么叫停CUA让模型直接控制鼠标键盘本质上是把关机、删文件、发邮件这些操作能力都交给了模型。没有边界控制一旦模型误判或幻觉后果可能是灾难性的。我在自己项目里建立了三层防护分享出来供参考。第一层是环境隔离所有CUA任务默认跑在独立的虚拟机或远程桌面环境中与生产网络、核心数据存储都做严格隔离即使模型把整个虚拟机折腾崩溃也只影响这一个隔离实例。第二层是动作白名单对敏感操作进行系统级拦截比如访问特定目录、执行命令行、调用删除类快捷键一律禁止即使模型发出了这些指令执行层也会直接拒绝。第三层是人工接管机制系统检测到高频点击、非预期弹窗、长时间重复动作等异常信号时自动暂停并请求人工确认。我甚至加了一个全局急停快捷键任何时刻按下就能终止整个自动化进程。这三层防护合在一起才让我敢把CUA从实验环境推向相对正式的内部流程。落到最后一句话上我个人的体会是CUA最让人兴奋的地方不是它现在的成功率已经超过人类而是“通用计算机操作”第一次变成了一个可以通过数据持续优化的机器学习问题。这个方向还远没到开箱即用的成熟期但如果你愿意从单应用、单任务、固定环境开始老老实实搭评测集、跑真实验证、维护反馈闭环你手上这个不起眼的demo会一步步长成真正替你省时间的自动化能力。