最近大模型圈子里除了MCP聊得最多的缩写就是CUA了。CUA全称是Computer-Use Agent中文直接翻译过来叫“计算机使用智能体”通俗点说就是让AI直接接管鼠标键盘、看着电脑屏幕完成任务的那种智能体程序。它不是又一个大模型聊天窗口而是一个真真切切能“动手干活”的AI——帮你在老旧的业务系统里录入数据、替你跑一遍软件测试流程、甚至在浏览器里把一套完整的售后工单处理完。这篇文章不是来科普概念的而是我想把这半年做CUA相关项目的全过程复盘出来。从最开始的方案选型到核心代码怎么写再到真实场景落地时踩过的一堆坑都会一条条讲清楚。如果你准备做AI Agent、测试自动化或者正在评估要不要用CUA替换传统的RPA机器人这篇内容能省你不少试错时间。1. CUA是什么从“会聊天”到“会操作电脑”1.1 为什么偏偏是这两年CUA突然成了热门方向过去大家用大模型最多就是写文案、改代码、做翻译本质上还是在“文本世界”里打转。可现实中的大量工作比如财务对账、ERP录入、客户信息管理全都依赖图形界面。按钮在屏幕的哪个位置、弹窗里的提示是什么、下拉菜单要选第几项——这些事情传统编程非常不擅长毕竟老系统的API接口要么没有、要么贵得离谱。CUA解决的就是这个“最后一公里”的问题。它不再逼着你去调API也不再要求你给每个按钮写定位表达式而是像人一样看着屏幕理解当前状态然后用鼠标键盘去操作。我见过最直观的一个比喻普通AI是“读过很多书但不会开车的人”而CUA是“坐在驾驶位上能自己看路、打方向盘、踩油门的司机”。路况会变、按钮会换位置但它能根据眼前画面重新判断这就是和传统RPA最本质的区别。1.2 三大核心模块感知、规划、执行一条链做CUA项目别一上来就想着找个大模型硬怼。拆开看它一定包含三个环环相扣的模块。第一个是视觉感知模块。电脑上的信息都在屏幕上Agent第一步得知道“现在屏幕长什么样”。最常用的做法是截图然后把截图交给多模态模型或者OCR识别从像素里提取出“有哪些窗口、哪些按钮、哪些文字”。这一步的难点不是“能不能识别”而是“识别出来的信息准不准、坐标对不对”。第二个是任务规划模块。感知到屏幕状态之后Agent要把用户的大目标拆成一步步的小动作。比如“填完并提交这个表单”这个任务拆开就是“点击用户名输入框→输入用户名→点击密码框→输入密码→点击登录→等待新页面出现→再找到提交按钮”。这部分通常靠大模型的推理能力加一套约束规则防止它东点一下西点一下。第三个是动作执行模块。决策规划做完了最终要落到鼠标点击、键盘输入、滚轮滚动这些真实操作上。项目里一般用pyautogui这类库把模型输出的指令翻译成操作系统事件。执行完之后还要再截一次图跟操作前的截图做对比确认动作是不是真的生效了。这三块串起来才是一个完整的CUA。少任何一个环节要么就是“瞎操作”要么就是“光看不做”都不能真正落地。2. 核心技术点拆解CUA怎么理解屏幕又怎么动手2.1 GUI理解纯截图、无障碍树还是混合输入这是做CUA项目第一个要拍板的技术选型。目前主流做法有三条路各有各的适用场景。第一种是纯截图交给多模态大模型。像GPT-4o、Gemini这类支持视觉的模型可以直接把截图丢进去让它描述界面元素甚至让它直接输出下一步动作。好处是通用性极强什么软件都能处理不需要软件方配合坏处是贵、慢而且模型偶尔会“看错”——把界面上不存在的按钮说得跟真的一样。第二种是走浏览器DOM或系统无障碍树Accessibility Tree。在网页里可以拿到HTML结构在原生应用里可以借助Windows UI Automation、macOS Accessibility API拿到控件和坐标。这算是“作弊”式的准确因为拿到的信息本身就是结构化的。但这仅是浏览器或某些标准桌面生态能用一遇到自绘控件、老系统、远程桌面里的软件就基本抓瞎。第三种是混合方案也是我在项目里最终采用的整屏截图给OCR识别文本和按钮位置同时用一些轻量级视觉目标检测模型辅助找图标再把这些“文本坐标”信息喂给大模型做决策。这种做法成本可控通用性也比纯无障碍树好很多。实际研发时还建议加一个步骤把截屏图片按Retina屏和DPI缩放调整坐标再送进去否则你拿到了元素在图片上的坐标也没法准确对应到屏幕物理坐标。2.2 动作空间设计给Agent一份能直接照抄的JSON规范很多初学者做CUA最常犯的错误是让模型“自由发挥”——想输出什么就输出什么。结果就是模型生成了一段“把鼠标移到左上角然后双击”的自然语言代码逻辑根本没法解析。正确做法是把动作空间收窄成一套固定的JSON协议让模型只能从这个协议里选动作。我项目里用的是一套非常精简的动作规范大概长这样{ thought: 用户当前在登录页需要先输入用户名, action: click, x: 320, y: 280 }完整动作类型我控制在7个以内务求让模型好理解同时覆盖日常操作动作类型参数说明clickx, y, button?单击鼠标左键或右键double_clickx, y双击typetext在焦点处输入文本hotkeykeys组合键比如ctrlsscrollx, y, direction, amount在指定区域滚动waitseconds等待页面加载finishresult任务完成附带结果摘要这种限制动作空间的做法看起来是在给模型“套枷锁”实际上是在帮它。动作类型少了模型犯错的概率指数级下降出bug时也更容易回溯到底是哪一步掉链子。而且这套JSON协议天然方便记录日志你在排查“Agent为什么点错”的时候翻历史日志一眼就能看出问题出在感知还是规划。2.3 反馈闭环Agent如何判断自己“点对了没”CUA跑任务的时候有个特别容易被人忽略的问题它怎么知道自己点没点对大模型不像人有“手感”它没有鼠标按下的物理反馈。所以必须靠“视觉回环”来确认。我的做法是每次执行完动作后等待一小段时间通常500毫秒到2秒然后重新截屏拿当前截图和动作前的截图做对比。如果界面发生了变化——比如弹出了新窗口、输入框里有文字了、按钮颜色变了——就说明刚才的动作很可能生效了如果两张图几乎一模一样那就判定动作失败进入重试逻辑。这里有两个细节值得说一下。第一对比不一定要用多模态模型“看”工程上更稳的是算图像差异区域的百分比或者提取DOM/OCR结果做文本差异。第二要防止“操作生效了但界面没变”的场景比如鼠标本来就在目标按钮上点击后没有任何视觉变化。这种情况下可以结合业务状态判断例如等待某个接口返回或者读取系统剪贴板不要只依赖截屏。我常跟团队讲CUA项目的稳定性不在模型选得多大而在反馈闭环做得有多狠。感知、动作、再感知这个循环越严密任务成功率越高。3. 实操从零搭建一个本地CUA原型3.1 技术选型为什么是“截图OCRLLMpyautogui”如果你只是想快速验证CUA的可行性没必要上谷歌那套多模态Agent框架也别想着从头训练一个GUI定位模型。我的建议是直接搭一套最小原型截图用PIL的ImageGrabOCR用PaddleOCR或者RapidOCR决策用任意一个支持工具调用的LLM API动作执行用pyautogui。这样选择的第一理由是成本低。整套环境在普通笔记本上就能跑起来OCR部分可以用CPU推理不需要昂贵的显卡大模型用API按量付费调一次几厘钱。第二个理由是模块之间解耦清晰。哪一步出问题都方便单独调试——OCR识别不准就换OCR模型决策不行就换模型完全不用推翻重来。第三个理由是它最接近真实工业落地方案的形态。即便后面接入了更专业的UI-TARS等GUI模型整体架构也不用大改。3.2 关键代码截图、OCR、动作执行三步走下面这段代码是我项目早期尝试验证链路时写的结构很清晰直到现在我都还在用它的变体做调试。import time import pyautogui from PIL import ImageGrab def capture_screen(): 截图当前主屏幕保存为PIL Image img ImageGrab.grab(all_screensTrue) return img def ocr_get_text_positions(img): 对截图做OCR返回文本内容和中心坐标 # 这里用RapidOCR模型小、速度快适合中文界面 from rapidocr_onnxruntime import RapidOCR ocr RapidOCR() result, _ ocr(img) items [] if result: for box, text, score in result: x1, y1 box[0] x2, y2 box[2] cx int((x1 x2) / 2) cy int((y1 y2) / 2) items.append({text: text, x: cx, y: cy, score: score}) return items def execute_action(action): 根据模型输出的动作JSON执行操作 act action[action] if act click: pyautogui.click(action[x], action[y]) elif act double_click: pyautogui.doubleClick(action[x], action[y]) elif act type: pyautogui.typewrite(action[text], interval0.05) elif act hotkey: pyautogui.hotkey(*action[keys]) elif act scroll: pyautogui.scroll(action[amount], xaction[x], yaction[y]) elif act wait: time.sleep(action[seconds]) time.sleep(0.5)这段代码的核心思路很容易理解截图看屏幕OCR把“图”转成“文字坐标”执行函数把模型决定变成真实操作。注意截图的坐标坐标系和pyautogui的屏幕坐标系要保持一致不然会出现“模型看到的是图片坐标实际点击却偏到一边”的问题。在Windows上如果遇到高分屏需要先调用ctypes.windll.shcore.SetProcessDpiAwareness(1)让进程感知DPI否则截图尺寸和鼠标移动范围对不上。接下来是决策部分的封装。我的prompt不会让模型直接看整张截图那样又慢又贵而是把OCR识别出的文本清单拼成一段结构化文本再让模型输决策JSON当前任务登录系统并提交请假申请。 屏幕上识别到的可操作元素如下 0: 用户名 at (320, 280) 1: 密码 at (320, 360) 2: 登录 at (300, 440) 3: 记住密码 at (420, 360) 请基于任务和元素列表输出下一个动作只输出JSON格式为 {action: click | type | hotkey | scroll | wait | finish, ...}模型返回的结果再喂给execute_action整个循环就闭环了。这里有一个工程心得prompt里给每个元素编号而不是直接把坐标暴露给模型模型更不容易出错因为数字编号比大段的坐标值好理解得多。拿到编号后你在代码里查表换成坐标相当于把“精度”这件事从模型手里夺了回来。3.3 实战任务用原型自动完成一个网页表单光说代码不跑任务等于白搭。我当初为了验证整条链路设计了一个非常典型的测试场景自动打开一个本地网页管理系统输入账号密码进入业务页面提交一张报销申请单。任务流程是这样的。第一步程序先截屏OCR识别出浏览器地址栏位置和输入框然后模拟输入本地网页地址按回车打开页面。第二步等页面加载2秒后再次截屏通过OCR找到“用户名”“密码”两个输入框以及“登录”按钮。第三步驱动模型生成动作序列——依次点击用户名框、输入内容、点击密码框、输入内容、点击登录。第四步等待页面跳转后重新截屏确认页面上出现了“新建申请”按钮如果没有出现就触发重试机制重新点击一次登录。整个过程中最值得注意的坑在第三步和第四步之间。很多新手在点了登录之后不等待马上截屏结果截到的是登录页旧界面然后误以为登录失败不停重复点击。这个问题的解决办法很简单在点击动作之后加一个条件等待循环每500毫秒截一次屏直到检测到目标元素出现或超过15秒就放弃。这也算是最朴素的“任务状态机”实现。我当时用这个原型连续跑了30遍同样的流程成功率从最初的50%主要是DPI坐标问题调到了90%以上。剩下的失败大多来自OCR把“登录”识别成“登录”之外的字换用更准的OCR模型后这个比例就下来了。关于OCR识别不准的这个问题后面第5章会专门展开聊。3.4 参数与打磨延时、坐标换算和失败重试原型能跑通之后真正耗时间的不是“写代码”而是“调参数”。CUA项目里有几个参数是必须反复试的。第一个是动作间隔。pyautogui里typewrite的interval参数如果设成0.05秒输入速度很快但某些系统或者网页会因为输入太快丢字符。我实测下来中文界面稳妥的做法是interval在0.05到0.1之间肉眼看着舒服速度也能接受。点击动作之后至少要留0.5秒给系统响应留出时间。第二个是OCR的阈值和区域裁剪。整屏OCR不仅慢还容易识别出大量无用的边栏、菜单文字。优化方法是对关键区域做裁剪比如只对登录框区域做OCR。代码里可以用ImageGrab.grab(bbox(x1, y1, x2, y2))这个区域可以通过窗口句柄实时获取而不是写死坐标。第三个是失败重试策略。我做过统计单步动作失败率即使只有5%一个30步的任务成功率也不到50%。所以一定不能给整个任务只留一次机会。我的策略是给每个关键动作设置2次重试并且每次重试前先重新截屏因为界面可能已经变化旧坐标已经失效。整体任务还要设一个最大轮数比如50轮超过就强制终止防止Agent陷入死循环把系统点烂。4. 应用场景与影响范围CUA能落地在哪4.1 办公自动化传统RPA之后的下一个形态过去几年企业上RPA最大的痛点不是RPA执行得慢而是机器人太“脆”。业务系统随便改个按钮位置RPA脚本就要跟着维护因为传统RPA依赖的是固定控件坐标或者选择器。CUA完全不吃这一套它的截图理解能力让它可以像人一样适应界面变化。我接触过一个财务共享中心的场景每天要从几十个邮件附件里提取信息再录入到两个不同的内网系统里。这两个系统都没有开放API而且它们各自的页面每隔几个月就有改动。如果用传统RPA每调整一次要花一到两周用CUA原型模型看到了新界面的截图自己就会重新定位输入框维护成本几乎为零。虽然单次执行速度比RPA慢一点但算上维护成本CUA的综合账是划算的。需要注意的一点是办公自动化场景里的准确性要求通常很高财务数据录错一个数字可能引发连锁问题。所以CUA产品落地时不能让它“盲干”至少要结合业务返回结果做二次校验比如录入完成后读取页面上的汇总金额和原始单据做一致性比对。4.2 软件测试从脚本录制走向意图驱动测试领域是我认为CUA最快能产生实际价值的场景之一。传统UI自动化测试用Selenium、Playwright这类框架写用例每一条用例都要写很长的元素定位代码而且前端一改版定位器就失效。CUA让测试脚本从“定位元素”变成了“描述行为”——给Agent一句“点击左侧导航上的订单管理然后验证页面表格中至少有3条记录”它自己搞定剩下的操作步骤。我在一个内部管理系统的回归测试里试过这条路。把之前用Playwright写的30多条测试用例改成CUA的意图式驱动前期开发时间缩短了60%因为不用再纠结于CSS选择器。后期维护成本也显著降低前端开发改版之后Agent照样能通过界面文字和图标找到入口。当然CUA测试的缺点也很明显就是每次跑例子的时间比脚本长不适合需要秒级反馈的冒烟测试。更合理的用法是让它接管那些“脚本维护成本极高、改动频繁”的长流程用例留下稳定的核心用例继续用传统方式写。4.3 个人助理与无障碍辅助安全边界必须想清楚当CUA跑在普通人的个人电脑上它的想象空间和风险同时被放大了。想象一下AI帮你在本地软件里整理文件、批量重命名、在聊天软件里回复客户并发送——这已经不只是“看屏幕操作”而是拥有了你数字身份的一部分操作权。这个时候权限边界和审计机制是绝对底线不能省略。我的建议是凡是CUA能执行的操作都要做到“权限最小化”。能只读就不写入能只发给指定窗口就不全局广播快捷键。同时在代码层增加操作白名单比如允许点击浏览器窗口但禁止触发系统关机指令。所有动作日志要落盘方便出现异常时回溯。如果操作涉及账号密码、密钥等敏感信息更不能把明文放在prompt里让模型读取而应通过变量占位符传给执行函数。5. 踩坑实录CUA项目最常见的四个问题与排查技巧5.1 坐标漂移窗口移动、DPI缩放和多显示器CUA最容易翻车的问题就是坐标漂移。模型说“点击(500, 320)这个按钮”但实际执行时鼠标落点却偏了之所以偏是因为截图坐标系、图像缩放坐标系和屏幕物理坐标系三者不是总是一一对应的。排查看起来狼狈其实有套路。先看Windows的“显示缩放”如果系统设置了125%、150%缩放而你的Python进程没有设置DPI感知那么pyautogui的坐标和PIL截图坐标会完全对不上。解决方法是程序启动时加上ctypes.windll.shcore.SetProcessDpiAwareness(1)让系统按物理像素给你返回尺寸。窗口移动导致坐标失效更需要警惕我的办法是每次决策前先通过窗口标题栏重新定位窗口左上角坐标所有控件坐标都换算成相对于窗口的偏移再转成全局坐标这样即使窗口被拖动位置也不会偏。多显示器环境是另一个隐藏坑。ImageGrab.grab()默认截主屏而鼠标可能在副屏操作。处理方式很简单截屏时指定all_screensTrue同时用pyautogui.size()获取真实的总分辨率把坐标换算统一到多屏拼接坐标系里来。5.2 模型幻觉AI说点了一个按钮实际没点大模型自己“脑补”出一个不存在的按钮是CUA项目里让人头疼的性能杀手。我在早期实验时遇到过模型一本正经地输出“点击页面右下角的确认按钮”但OCR结果里根本没有这个按钮。原因是模型从训练数据里见过大量“确认”按钮就下意识补充到了当前场景里。对这个问题的根治方法不只是换更强的模型更重要的是控制输入和输出。输入控制上我给模型喂的是OCR列表而不是整张原图模型只能基于它看到的文字做决策脑补空间被大幅压缩。输出控制上严格限定动作JSON格式凡是xy值不在屏幕范围内、或者是纯属编造的动作代码直接拒绝执行并让模型重新决策。我还加了一个“信息来源校验”字段要求模型在输出坐标时一并说明这个坐标来自列表里哪个元素编号代码里核对不上就判为无效。5.3 成本与延迟跑一次任务要多久、多贵CUA项目跑起来之后第二个现实问题就是成本。整屏截图丢给一个大型多模态模型一次好几美分跑一个20步的任务可能就是几块钱人民币。延迟也同样感人大模型推理要几秒OCR又要一秒多一个任务下来几十秒很正常。我的优化思路分三堵墙。第一堵墙是减少发给大模型的视觉信息能不用视觉模型就不用改用OCR结构化文本第二堵墙是缩小OCR区域只识别与任务相关的弹窗和按钮区域把整屏的OCR时间从两秒降到一秒以内第三堵墙是合并连续动作。像“输入用户名”之后的点击和输入密码如果位置相对固定就把它合并成一步连招减少模型调用的轮数。实践下来这三招能把单任务的模型调用次数从平均15次压到7次左右单次任务成本直接降一半。如果你的场景量非常大可以考虑在本地部署小尺寸VLM做初筛只有遇到复杂情况才调用云端大模型这个混合路由方案我强烈建议做CUA长期运营的人考虑。5.4 环境一致性与安全限制同一个CUA原型在A机器上能稳定跑搬到B机器上就各种失灵几乎是必然的。原因通常是分辨率不同、系统主题不同、浏览器默认字体大小不同。为了不让环境差异成为埋给自己的雷我规定所有测试环境统一用一台配置固定的虚拟机或者Docker容器跑屏幕分辨率锁死在1920x1080系统缩放锁100%输入法切到英文模式。如果读者准备在云上大批量跑CUA强烈推荐用虚拟化环境不仅因为环境统一而且即便Agent意外触发关闭系统这类破坏性操作也不会影响宿主机。安全限制这块一定要在项目初期就设计好。首要是不能把大模型的API Key硬编码在代码里尤其在团队协作的项目里应该用环境变量或者密钥管理服务。其次所有执行动作必须写审计日志点击了什么、输入了什么、退回了什么结果全都记录。有些CUA场景会涉及自动登录内部系统账户口令的托管也要单独处理千万不要为了图省事把明文密码直接放进prompt里那样日志一旦泄露后果不堪设想。我在实际项目里还有一个执念任何CUA原型都必须有一个“急停开关”。键盘上设置一个组合键热键Agent失控时按一下立刻终止所有任务并释放鼠标控制权。你别觉得这东西多余等你在演示现场碰上一次Agent疯了一样反复点击弹窗的经历你就会把急停开关当成项目的基本盘。最后分享一个实操小技巧给Agent每一步操作都留下前后对照截图。我做了这么久CUA之后最深的体会是与其费尽心思让模型更聪明不如把每一步的“预期—结果”截图存好出了问题看截图往往比看代码更直观、更接近问题的真相。只要把这个“操作前后对照验证”的习惯养成你的CUA项目成功率至少能再上一个台阶。