1. 从“cua”这个模糊词根说起它到底指什么第一次看到“cua”这个标题的时候我脑子里蹦出来的第一反应是——这大概率是个缩写而且是个被严重过度使用的缩写。在技术圈里混久了你会发现三个字母的组合几乎快被用烂了可以是某个框架的简称可以是某个协议栈的代号也可以是某个内部项目的花名。但结合“cua”这个拼写本身的发音特征和常见构词习惯我倾向于把它定位在计算机使用代理Computer-Use Agent这个方向上。为什么这么判断因为最近一两年整个AI应用层最热的一个细分赛道就是让模型直接操作图形界面——不是通过API调接口而是像人一样看屏幕、点鼠标、敲键盘。这个方向在英文社区里被反复讨论的一个核心缩写就是CUA。它解决的是一个非常实际的问题大量存量软件根本没有开放API或者API能力残缺你想让自动化流程覆盖这些软件唯一的办法就是模拟人的操作。而传统的UI自动化工具比如基于控件树的那套方案在面对Canvas渲染、游戏引擎界面、远程桌面画面时基本抓瞎。CUA的思路是用视觉理解加动作生成的方式绕开控件树直接从像素层面理解界面并决定下一步动作。所以这篇内容我打算围绕“cua”这个核心概念把它拆成几个层面来讲它到底解决什么场景的问题、底层依赖哪些关键技术模块、实际落地时怎么搭一个最小可用的原型、以及我在尝试过程中踩过的那些坑。适合谁看如果你正在做RPA相关的产品、在探索AI Agent的落地路径、或者单纯想搞清楚“让AI自己操作电脑”这件事到底靠不靠谱那接下来的内容应该能给你一些参考。我不会堆砌论文里的公式而是尽量用实际项目里的视角来讲清楚每个环节的取舍。提示本文讨论的“cua”特指计算机使用代理这一技术方向不涉及任何特定商业产品所有案例均为虚构的模拟场景。2. CUA要解决的核心矛盾为什么传统自动化方案在真实场景里不够用2.1 控件树方案的三个致命盲区做过桌面自动化的人对控件树这套东西应该不陌生。Windows上有UIAutomationmacOS上有Accessibility APIWeb端有DOM。这些方案的共同逻辑是通过操作系统或浏览器暴露的语义化接口拿到界面元素的层级结构然后定位到目标控件并触发操作。听起来很美好实际用起来你会发现三个绕不过去的坎。第一个坎是渲染方式与控件树脱节。很多现代应用的前端是用Canvas或WebGL整体绘制的比如在线设计工具、数据可视化大屏、游戏化的教学软件。这些界面在控件树里往往只有一个孤零零的顶层容器里面什么都没有。你拿不到按钮的位置拿不到输入框的句柄因为所有像素都是运行时画上去的操作系统根本不知道那里有个“按钮”。第二个坎是跨进程和跨设备的语义丢失。远程桌面场景下你本地看到的是一张视频流画面远端的控件树你根本访问不到。虚拟机、云手机、投屏操作全是同样的问题。控件树方案在这些场景下直接归零。第三个坎是动态布局和个性化配置带来的脆弱性。同一个软件用户改了主题、调了字号、换了语言控件树的结构可能就变了。你写死的选择器路径今天能跑通明天用户升级个版本就全断了。维护成本高得离谱。2.2 视觉方案为什么突然变得可行了视觉方案的想法其实很早就有人提——截屏、识别、点击。但为什么以前没成为主流因为识别环节太弱了。传统的模板匹配和特征点检测面对界面这种高度结构化但又千变万化的图像泛化能力极差。直到视觉语言模型的能力上来之后事情才起了变化。现在的视觉模型可以直接回答“这个界面上有哪些可交互元素”“要完成某个任务应该点哪里”这类问题。它不需要你预先定义控件类型不需要你标注训练数据给一张截图加一句自然语言指令它就能给出坐标级的动作建议。这就把视觉方案的短板补上了。再加上动作执行层本身并不复杂——移动鼠标、点击、输入文本这些操作在任何操作系统上都有成熟的接口。所以整个CUA的技术栈可以概括为视觉理解负责“看”语言模型负责“想”动作执行负责“做”。2.3 一个具体的对比场景举个我实际遇到过的例子。有个模拟项目需要在某个桌面端的数据分析工具里把一份表格数据导入后生成图表再把图表导出为图片。这个工具没有开放API界面是用自绘引擎渲染的。用控件树方案你连“导入”按钮都定位不到。用CUA方案流程是这样的截取当前窗口画面模型识别出菜单栏里的“文件”选项输出点击坐标执行点击后再次截屏识别下拉菜单里的“导入数据”继续点击弹出文件选择对话框后识别路径输入框输入文件路径点击确认等待数据加载完成后识别图表配置区域的各个下拉框和输入框依次设置参数最后识别导出按钮并点击。整个过程不需要任何控件句柄纯粹靠视觉反馈驱动。这个对比不是说CUA一定比控件树好而是说在控件树失效的场景下CUA提供了一条可行的兜底路径。实际项目中我倾向于把两者结合能用控件树的地方用控件树控件树覆盖不到的地方用CUA补位。3. 拆解CUA的技术栈从截屏到动作执行的完整链路3.1 屏幕捕获频率、分辨率与增量策略CUA的第一步是拿到当前屏幕的画面。这件事听起来简单但实际做起来有几个参数需要仔细权衡。捕获频率直接决定了Agent的反应速度。如果每做一步动作就截一次全屏在4K分辨率下单次截屏加编码可能就要几十毫秒再加上模型推理的时间整个循环的延迟会让人难以接受。我的做法是在动作执行后的等待期用较低的频率比如每秒2到3次做轮询式截屏检测画面是否稳定一旦画面稳定立即做一次高质量截屏送入模型。这样既不会漏掉界面变化又不会把算力浪费在无意义的重复截屏上。分辨率是另一个关键参数。直接把4K原图送给模型token消耗巨大且推理速度慢。但压缩得太狠界面上的小字和图标又看不清。实测下来把长边缩放到1280到1560像素之间是一个比较平衡的区间。对于需要识别细小文字的场景可以对局部区域做裁剪放大后再送模型。增量策略指的是只截取发生变化的部分。这个优化在界面大部分区域静止、只有小范围更新的场景下效果显著。实现方式可以是比较前后两帧的差异区域只把差异区域连同上下文一起送模型。不过这个优化会增加工程复杂度建议在原型验证阶段先用全屏截屏跑通流程后续再考虑优化。3.2 视觉理解模型看到了什么又该如何表达视觉模型在CUA里的角色是“把像素翻译成可操作的结构”。它需要完成几件事识别出界面上所有可交互的元素按钮、输入框、链接、菜单项等理解每个元素的语义功能以及根据当前任务目标判断下一步应该操作哪个元素。这里有一个容易被忽略的细节模型输出的坐标格式。不同模型对坐标的表示方式不一样有的输出归一化坐标0到1之间的小数有的输出绝对像素坐标有的输出的是边界框的四个角点。你在搭建流程时必须把模型输出的坐标统一转换到屏幕的实际像素坐标系否则点击位置会偏得离谱。我踩过的一个坑就是模型输出的是相对于截屏图片的坐标但截屏图片经过了缩放我忘了把坐标映射回原始屏幕尺寸结果所有点击都往左上角偏移了一大截。另一个细节是元素的描述粒度。模型可能会把整个工具栏描述成一个元素也可能把工具栏里的每个图标单独列出来。你需要通过提示词引导模型输出合适的粒度。我的经验是要求模型以“可点击的最小单元”为粒度来列举元素同时给每个元素附上简短的功能描述。这样后续做动作决策时模型可以基于功能描述来匹配任务需求而不是靠猜图标长什么样。3.3 动作空间设计点击之外还需要什么很多人一想到CUA的动作空间第一反应就是“点击”。但实际做下来你会发现只有点击是远远不够的。一个完整的动作空间至少应该包含以下几类指针移动与点击包括左键单击、右键单击、双击。右键菜单在很多桌面软件里是核心交互方式不能忽略。文本输入包括直接输入字符串和模拟按键组合。有些输入框需要先聚焦再输入有些则需要逐字符输入以触发联想搜索。滚动页面滚动、区域滚动、下拉列表滚动。滚动操作需要指定滚动方向和滚动量有时候还需要指定在哪个区域滚动。拖拽从A点拖到B点用于调整窗口大小、拖动滑块、移动文件等场景。等待显式地等待一段时间用于处理加载动画、网络延迟等异步情况。快捷键组合键操作比如复制粘贴、切换窗口、保存文件等。动作空间的设计直接影响到Agent的能力边界。动作类型太少很多任务做不了动作类型太多模型的选择空间变大出错概率也会上升。我的建议是从最核心的点击和输入开始根据实际任务需求逐步扩展。每增加一种动作类型都要配套相应的验证机制确保动作执行后界面确实发生了预期变化。3.4 循环控制什么时候继续什么时候停CUA的执行是一个循环过程截屏、理解、决策、执行、再截屏。这个循环什么时候结束有两种情况任务完成或任务失败。任务完成的判断通常由模型来做——在决策阶段模型可以选择输出一个“任务已完成”的信号。但模型判断自己完成了任务这件事并不可靠它可能会在界面还没更新的时候就宣布完成。所以我的做法是模型宣布完成后再截一次屏让模型确认最终状态是否符合预期。如果不符合继续循环。任务失败的判断更复杂一些。常见的失败信号包括连续多步动作后界面没有任何变化、模型输出的动作坐标超出了屏幕范围、模型陷入了重复动作的循环比如反复点击同一个位置。我通常会设置一个最大步数限制比如30步超过就判定失败并输出当前的截屏和动作历史方便人工排查。注意循环控制里最容易出问题的地方是“等待”逻辑。界面加载需要时间但等太久会拖慢整体速度等太短又会导致下一步操作基于过时的界面状态。我的经验是采用“稳定检测”策略连续两次截屏的差异小于某个阈值时认为界面已经稳定可以进入下一步。4. 搭建一个最小可用原型从零到跑通第一个任务4.1 环境准备与依赖选择要跑通一个CUA的最小原型你需要的核心组件并不多一个屏幕捕获模块、一个视觉模型接口、一个动作执行模块以及一个把它们串起来的控制循环。屏幕捕获方面Python生态里比较顺手的是mss库它跨平台且速度够快。动作执行方面pyautogui是最省事的选择它封装了鼠标和键盘操作支持跨平台。视觉模型方面你需要一个支持图像输入的模型接口能够接受图片和文本提示词并返回结构化的文本输出。这里有一个选型上的取舍是用本地模型还是调用远程接口本地模型的好处是延迟低、数据不出本地但需要你有足够的显存来跑视觉模型。远程接口的好处是模型能力强、无需本地算力但每次截屏都要上传网络延迟和隐私是需要考虑的因素。原型阶段我建议先用远程接口快速验证流程跑通之后再根据实际需求决定是否迁移到本地模型。4.2 提示词工程如何让模型稳定输出可解析的动作CUA的提示词设计和普通的对话提示词有本质区别。普通对话追求的是回答质量CUA追求的是输出格式的稳定性和可解析性。你需要模型每次都按照固定的JSON格式返回动作指令否则你的控制循环就没法自动解析。我的提示词模板大致是这样的结构先给模型设定角色你是一个界面操作助手然后给出当前截屏图片接着描述当前任务目标和已执行的动作历史最后给出输出格式要求。输出格式要求里要明确列出所有支持的动作类型及其参数结构并给出一个示例。这里有一个非常实用的技巧在提示词里加入“如果界面没有变化尝试其他操作”的指令。模型有时候会陷入局部最优反复点击同一个位置。明确告诉它“如果上一步动作没有产生预期效果请换一种方式”可以显著降低死循环的概率。另一个技巧是要求模型输出置信度。让模型对每个动作给出一个0到1之间的置信度分数当置信度低于某个阈值时控制循环可以暂停并请求人工介入。这在原型阶段特别有用可以帮你快速定位模型在哪些界面上表现不佳。4.3 动作执行与反馈验证动作执行模块的职责很明确接收模型输出的动作指令调用相应的系统接口执行然后等待界面稳定再截屏进入下一轮。但这里有一个容易被低估的环节动作执行后的验证。你不能假设动作一定执行成功了。比如模型说“点击坐标(500, 300)”但那个位置可能因为界面滚动已经变成了空白区域。所以每次动作执行后都需要通过截屏对比来验证界面是否发生了预期变化。如果连续两次动作后界面都没有变化就应该触发异常处理流程。验证的方式可以很简单计算动作前后两帧截屏的差异度。如果差异度低于阈值说明界面没变动作可能没生效。这时候可以让模型重新观察界面并给出新的动作建议。这个反馈闭环是CUA区别于“盲操作”的关键所在。4.4 一个完整的任务执行示例假设任务是在一个模拟的桌面端笔记软件里新建一篇笔记并输入标题。整个执行流程如下第一步截取当前屏幕模型识别出界面左侧的笔记列表、顶部的工具栏、以及工具栏上的“新建”按钮。模型输出动作点击“新建”按钮坐标(320, 85)置信度0.92。第二步执行点击等待500毫秒截屏。界面右侧出现了空白编辑区域顶部有标题输入框。模型识别出标题输入框输出动作点击标题输入框坐标(800, 120)置信度0.88。第三步执行点击截屏确认输入框已聚焦光标闪烁。模型输出动作输入文本“项目会议纪要”置信度0.95。第四步执行文本输入截屏。标题已显示在输入框中。模型判断任务完成输出“任务完成”信号。第五步控制循环收到完成信号再做一次截屏确认然后结束。这个流程看起来简单但实际跑的时候第二步和第三步之间可能会因为界面动画导致截屏时机不对模型看到的还是旧画面。所以等待策略和稳定检测在这个环节特别重要。5. 实际落地中绕不开的六个坑5.1 坐标偏移模型看到的和实际点击的不是同一个位置这是最常见也最让人头疼的问题。根源通常在于截屏图片的尺寸和屏幕实际尺寸不一致。比如你的屏幕是2560x1440但截屏后为了减少token消耗把图片缩放到了1280x720。模型基于缩放后的图片输出坐标比如(400, 300)但如果你直接把这个坐标传给鼠标点击接口实际点击的是屏幕上的(400, 300)而不是缩放前的(800, 600)。解决方案很简单在截屏时记录缩放比例在动作执行前把模型输出的坐标乘以缩放比例的倒数。但很多人会在多显示器或者高DPI缩放的场景下忘记这个转换导致点击位置偏移。我的建议是在代码里把坐标转换封装成一个独立的函数每次动作执行前都强制走这个函数不要在任何地方直接使用模型输出的原始坐标。5.2 界面动画导致的时序错乱现代界面大量使用过渡动画点击一个按钮后界面不是瞬间切换而是有一个几百毫秒的渐变过程。如果你在动画播放到一半的时候截屏模型看到的可能是一个半透明的中间状态识别结果会非常混乱。应对策略是基于稳定检测的等待而不是固定时长的等待。具体做法是动作执行后以较短间隔比如100毫秒连续截屏比较相邻两帧的差异。当连续两帧的差异小于某个阈值时认为动画已经结束界面进入稳定状态。这个策略比固定等待500毫秒要可靠得多而且在不同性能的机器上都能自适应。5.3 模型幻觉它说点了但其实没点视觉模型有时候会“脑补”界面上的元素。比如界面上其实没有“保存”按钮但模型因为任务描述里提到了保存就虚构出一个保存按钮的位置并输出点击动作。这种幻觉在界面元素密集或者文字较小的时候尤其容易出现。缓解办法有几个一是要求模型在输出动作前先描述它看到的界面元素列表然后再基于这个列表做决策。这样你可以通过检查元素列表来判断模型是否真的看到了目标元素。二是对模型输出的坐标做合理性校验比如坐标是否在屏幕范围内、该位置是否在之前的截屏中确实存在可交互元素。三是设置置信度阈值低置信度的动作不执行转而请求人工确认。5.4 长任务中的上下文膨胀当一个任务需要执行很多步时如果把每一步的截屏和动作历史都塞进提示词token消耗会迅速膨胀而且模型对早期步骤的记忆会变得模糊。我试过在一个需要20多步的任务里保留全部历史结果模型在第15步的时候开始重复第3步的动作完全忘记了中间已经完成的部分。解决方案是对历史做摘要压缩。不要保留每一步的完整截屏而是只保留最近两三步的截屏更早的历史用文本摘要代替。摘要内容包括已经完成了哪些子目标、当前处于哪个阶段、有哪些已知的界面状态。这样既控制了token消耗又让模型对任务进度有清晰的认知。5.5 多窗口和弹窗的干扰实际桌面环境里屏幕上可能同时存在多个窗口还有各种弹窗、通知、悬浮工具栏。模型在截屏时看到的是整个屏幕的画面它需要判断哪个窗口是当前任务相关的哪些弹窗需要先关闭。这个问题在原型阶段可以简化处理只截取目标窗口的区域而不是全屏。通过窗口标题或进程名定位到目标窗口获取其位置和尺寸然后只截取该区域。这样可以排除大部分干扰。但弹窗仍然可能覆盖在目标窗口上方所以还需要一个弹窗检测机制——当模型发现界面上出现了非预期的对话框时优先处理弹窗比如点击“取消”或“关闭”然后再继续原任务。5.6 动作执行权限与系统限制在某些操作系统上模拟鼠标和键盘操作需要特定的权限。比如在macOS上你需要给执行脚本的终端或IDE授予“辅助功能”权限否则pyautogui的点击和输入会被系统拦截。Windows上相对宽松但如果目标程序是以管理员权限运行的而你的脚本不是操作也会被拒绝。这个坑的排查成本很高因为程序不会报错只是动作静默失败。我的建议是在原型启动时先做一个自检尝试在一个已知位置执行一次点击并验证结果如果失败就明确提示权限问题。另外在CI/CD环境或者远程桌面会话里跑CUA时要特别注意会话是否处于活跃状态——锁屏状态下截屏和操作都会失败。6. 关于CUA落地节奏的一些个人判断我在多个模拟项目里尝试过CUA方案有一个很深的体会这项技术的demo能力和生产能力的差距比大多数AI应用都要大。做一个能跑通单个任务的demo可能一个下午就够了。但要让它稳定处理几十种不同的界面、应对各种异常情况、在无人值守的情况下持续运行需要投入的工程精力是demo阶段的十倍以上。所以如果你在考虑把CUA引入实际业务流程我的建议是先从高频、界面稳定、容错空间大的场景切入。比如某个内部工具每天要重复操作几十次界面几年没变过操作错了也能轻松回退——这种场景最适合用CUA做试点。跑通之后再逐步扩展到更复杂的场景。另一个判断是CUA不会完全取代传统的API集成和控件树自动化。它更像是填补空白的一种手段在那些没有API、控件树也覆盖不到的地方发挥作用。一个成熟的自动化体系应该是分层的优先用API其次用控件树最后用CUA兜底。把CUA当成万能方案在简单场景上硬上反而会增加不必要的复杂度和不确定性。最后分享一个我在调试CUA流程时的小技巧把每一步的截屏、模型输出、执行结果都落盘保存按时间戳命名。当任务失败时你可以回放整个执行链路精确看到是哪一步的识别出了问题、哪一步的坐标偏了、哪一步的等待时间不够。这个日志回放机制帮我省下了大量猜测的时间强烈建议在原型阶段就加上。