CUA：让AI像人一样操作电脑——从RPA到AI Agent的下一代自动化

1. 同一个cua两种毫不相干的火法1.1 评论区里的cua一个自带速度感的拟声梗先说我最早碰到的场景。刷短视频有人展示猫从桌上跳下去评论区热评就是cua 一下就没了有人拍打不到蚊子弹幕飘过cua又跑了。我第一反应是大家怎么突然统一用这个词了。后来留意了一下这个用法其实从谐音和方言里一点点蔓出来的核心表达的是动作极快、非常突然一个短促的爆破音嘴型一收像什么东西从你眼前一闪而过。和duang强调撞击感、pia强调拍打感不一样cua 强调的更多是位移和速度。所以你会发现凡是物体快速消失、快速位移、快速切换的画面评论区都能看到 cua。这层用法目前没有任何官方定义就是网络语境的自然演化。它也没有固定字形有人写cua一下有人写CUA甚至还有人写成猝啊。反正读起来差不多意思也差不多都是形容快得猝不及防。这其实是很多网络热词的共同路径先有声音再有意思然后被越来越多的人在不同场景里反复使用。1.2 技术群里的CUA另一个世界的主角如果说评论区里的 cua 是娱乐向的那技术群里的 CUA 就是硬核向的。大写、缩略、三个英文字母全称叫 Computer-Using Agent中文直译是会使用计算机的智能体。2024 年底到 2025 年这个概念被国内外好几家 AI 公司反复推到台前让 AI 不只会聊天和生成文字而是直接像人一样操作电脑——看屏幕、挪鼠标、点按钮、填表单、切换窗口最后完成一个实际工作任务。到这里你会发现同一个字符串在两个语境里的气质完全不同。一个是拟声词 娱乐梗一个是人工智能 自动化但它们在网上几乎同步发酵导致很多人初次看到CUA三个字母时都挺懵包括我自己。这种词的双面性恰恰是它成为热词的原因你永远不知道对方发来 cua是在感叹快还是在聊 AI。1.3 为什么说CUA背后是 2025 年最值得盯的方向如果单纯把它当一个网络梗那看看热闹就行。但技术圈这个 CUA 的意义完全不一样。过去两三年大模型在理解语言生成图片写代码这些领域已经卷得很厉害了可大家逐渐意识到一个问题模型再聪明如果它不能直接帮你操作电脑很多活儿还是得人来干。CUA 就是冲着让 AI 真正做到电脑前动手去的。我个人的判断是CUA 是 AI Agent 从只能给建议走向替你执行的关键一步也是 AI 自动化继 RPA 之后的下一站。这篇文章后面几个部分我会把 CUA 的原理、技术难点、最小实现和真实落地的坑一次讲清楚。2. 从 RPA 到 CUA为什么说会用电脑才是真需求2.1 传统自动化的三条路各有什么天花板要理解 CUA 的价值得先看自动化的老前辈们。最经典的是 RPA也就是机器人流程自动化。它核心的思路是录下来照着回放你对着屏幕操作一遍RPA 记录你点过的按钮位置、输入的文字、选择的下拉框然后当你说开始它按原路再走一遍。问题在于一旦界面改版、按钮移动 20 像素脚本就断了。维护成本会随时间直线上升机器人变得极其脆弱。我见过不少团队 RPA 流程越跑越慢最后变成RPA 运维专员天天修脚本。第二条路是 API 集成。这个稳定得多两个系统都开放接口就能安全地传数据、触发操作。但 API 的前提是对方愿意开放很多老旧的业务系统是十几年前的产物根本没有 API甚至跑在虚拟机里连数据库都进不去还有一些 SaaS 产品只开放部分接口核心操作还是要人去网页上点。API 能覆盖的场景也就停留在头部系统之间。第三条路是现在的纯语言模型 LLM 应用。它了不起的地方是会说但不会做让模型总结文档、生成代码它输出的是文字可是让它帮我把这个 Excel 里的数据填进那个网页表单模型无能为力因为它没有手。这三条路各有各的局限而 CUA 想解决的正是这个最后一公里——通过屏幕视觉和鼠标键盘控制把 AI 的理解力直接接到真实世界的图形界面上。2.2 CUA 的工作循环看、想、动、验CUA 的运作方式其实不神秘核心是一个四步循环一直重复到任务完成观察捕获当前屏幕画面也可以同时读取操作系统的可访问性接口像窗口标题、按钮名这种结构化信息。决策把任务目标和当前画面一起送给多模态大模型让它判断现在这一步该做什么。执行把模型的判断翻译成具体动作比如移动鼠标到某个坐标、点击、输入文字、滚动页面。验证重新截图看上一动作是否产生了预期效果如果没有进入纠错分支。这个循环有点像人自己用电脑的过程你看一眼屏幕决定下一步动手再看一眼结果。只不过人靠的是眼睛和手CUA 靠的是截图、大模型、自动化脚本。理解了这个循环后面所有技术细节都会围绕一个核心问题展开怎么让第 2 步的决策既准又不乱来。2.3 CUA、RPA、API 到底怎么选很多朋友看到这里会问那我做自动化到底用哪个我给个直白的对照表维度RPAAPICUA依赖条件界面稳定、元素可识别双方开放接口屏幕可截图、可控鼠标键盘灵活性低改版即崩中受接口能力限制高能应对未预见的界面变化学习成本中需掌握平台高需懂 HTTP 与模型集成高需调模型和容错逻辑适用场景固定流程、高频简单操作高频数据交换、流程编排跨系统、老系统、弱结构化场景当前主要问题维护成本高覆盖范围窄可靠性还不够需人工监督一句话总结就是能用 API 的场景优先用 API因为最稳定界面常年不变且操作固定的RPA 还顶得住而 CUA 目前最该去啃的是那些 API 没有、RPA 又脆弱的场景比如老系统迁移、跨多个网站的流程操作。3. 让 AI 看懂屏幕为什么是当前最难攻的山头3.1 图形界面本来就不是给机器设计的很多人觉得看屏幕对大模型来说应该是小菜一碟毕竟多模态模型都能识别图片了。但现实是一个真实桌面界面和一张风景照片的信息密度完全不同界面里有图标、弹窗、浮层、超链接、加载动画还有乱七八糟的无障碍树结构。桌面上一个按钮在截图里可能只有 30 × 20 像素还要和周围的文字一起被理解图标之间长得又像分辨率还随系统缩放变来变去。这些对人类来说瞬间可解的信息对模型来说很容易产生定位偏差。更麻烦的是层级遮挡。实际应用操作过程中弹窗经常会压在主要内容上面截图里看起来应该点的按钮其实被盖住了有的页面元素要 hover 之后才出现不实际移动鼠标根本看不见。这种动态性让看一次截图就决策的传统思路经常翻车。3.2 视觉定位不看绝对坐标要看语义CUA 中模型的输出不能只是描述看到了什么还得具体到该点哪里。目前主流的做法有两种。一种是直接输出相对坐标类似鼠标移动到屏幕的 (0.45, 0.62) 位置另一种是输出界面元素的语义描述比如点击按钮 Save再由另一层逻辑把这个描述映射到实际坐标上。后者更稳因为图标的实际位置会变但Save 按钮的含义基本不会变。这引出一个重要概念界面解析screen parsing与视觉定位grounding。简单说就是把屏幕这张图片拆成有哪些元素、分别在什么位置、属于什么类型然后再把任务目标与这些元素挂钩。做得好的系统还会用类似矩形框标注的方式先把所有可交互元素标出来再让模型在这些候选框里选目标而不是让它在一整张图上猜像素坐标。这个先检测、后挑选的策略明显比一步到位的坐标预测靠谱得多。3.3 太难的不是单步动作而是从错误中恢复在我实际测试过的 CUA 流程里点错地方几乎不可避免。页面加载慢了 500 毫秒截图里按钮还没渲染出来模型就不管三七二十一地点了旧位置弹窗弹出来的时机不固定模型上一轮判断点下一步下一轮实际点的却是弹窗上的知道了。这些问题单独的每一步都算不上致命但如果一个任务需要 50 步完成每一步只有 99% 的准确率整体成功率就只有约 60%每一步有 98% 的准确率整体就只剩 36%。CUA 现在最大的技术瓶颈不是模型多聪明而是错误累积。所以现在的 CUA 工程里大家都在加各种防御性设计任务拆解成小步、每一步都做状态记录、连续两次截图差异很小就认为动作没生效、达到最大步数就自动停止、把操作日志完整保存以便回溯。这些内容官方论文里提得少但在真实项目中比模型选型还重要。4. 自己动手搭一个最小可用的 CUA 工作流4.1 开胃菜环境隔离与基础依赖如果你看完前面那些想真正上手试一把我的建议是先别碰真机。把待操作的系统放进虚拟机或 Docker 容器里通过 VNC 或 RDP 远程控制。这样做的原因很简单AI 操作电脑这几年还处于可能会误操作的时期万一它把生产系统里的数据改了风险全在你身上。用隔离环境翻车了随时快照恢复成本就是重启一个机器。基础依赖按你熟悉的操作系统来。Windows 的话可以用 pyautogui 控制鼠标键盘、Pillow 处理截图macOS 则需要给终端开辅助功能权限用 Quartz 事件接口模拟点击Linux 上可以用 pyautogui 搭配 X11或者直接上无头模式。需要注意pyautogui 只是个手眼睛和大脑还得靠多模态模型来当。4.2 最小循环代码骨架下面这段是我在本地实验时用的最小逻辑不代表生产环境只是帮你把截图→决策→执行→验证跑通import time import pyautogui def observe(): # 1. 截图当前屏幕 screenshot pyautogui.screenshot() return screenshot def decide(task, screenshot, history): # 2. 调用多模态模型让它返回一个动作 JSON # 这里以伪代码表示实际要替换成你用的模型接口 prompt ( f当前任务{task}\n 请根据截图输出下一步动作格式如下\n {action: click | type | scroll | hotkey, x: 0.45, y: 0.62, text: hello, key: enter}\n 注意坐标为相对屏幕宽高的比例范围 0~1。 ) # 假设模型返回一个字典 action call_multimodal_model(prompt, screenshot) # 伪代码 return action def execute(action): # 3. 把相对坐标转成绝对像素并执行 if action[action] click: screen_w, screen_h pyautogui.size() x, y int(action[x] * screen_w), int(action[y] * screen_h) pyautogui.click(x, y) elif action[action] type: pyautogui.write(action[text]) elif action[action] hotkey: pyautogui.hotkey(*action[key].split()) # 其它动作类似扩展 def verify(): # 4. 延迟后截一张新图供上层判断是否发生了变化 time.sleep(0.8) return pyautogui.screenshot() task 打开记事本输入 hello world 并保存 history [] max_steps 30 for step in range(max_steps): state observe() action decide(task, state, history) execute(action) new_state verify() history.append((state, action, new_state)) # 这里可以写一个判断如果 new_state 与 state 几乎一致说明动作无效进入纠错这段代码里最关键的是 decide() 内部的模型 prompt 设计。我强烈建议让模型输出相对坐标而不是绝对像素坐标因为机器分辨率一变绝对坐标就废了相对坐标只要按当前屏幕宽高换算就能跨环境复用。同时一次只让模型输出一个动作避免既点击又滚动这种组合动作调试时更好定位问题。4.3 动作空间一开始要克制新手最常犯的错是希望模型什么都能做一上来就允许它自由移动鼠标、执行任意组合键。结果往往是模型输出了一个奇怪的快捷键把整个环境搞乱。我的做法是先把动作空间收缩到一个资源有限的集合里click、double_click、type、scroll、key单个快捷键、hotkey组合键、wait等待。每个动作都通过一个校验函数检查字段完整性不合理就拒绝执行并让模型重新生成。在这个阶段你还需要定义好动作是否执行成功的判断标准。最简单的办法是每执行完一个动作等半秒到一秒截一张图和上一步的截图对比像素差异差异太小就说明动作大概率没生效需要进入重试或换个方案。这里要注意等待时间不能拍脑袋写死有些页面要加载几秒建议用一个可配置的轮询连续截图多次直到出现变化再继续。4.4 失败恢复CUA 最值钱的工程环节很多公开 demo 看起来流畅是因为它把成功路径演给你看。真正做产品八成工作量都在处理失败恢复。我总结了三类最常见的失败模式以及对应的处理策略。第一类是动作没生效界面没变化。原因是加载慢、元素不在预期位置、点击失灵。处理策略是重试一次 换方案同一个动作最多重试两次如果还没变化就尝试用键盘快捷键替代鼠标点击或者按 Tab 键在控件间跳转。第二类是动作生效了但方向错了比如本来想点 Save结果点到了 Cancel。这种很难用截图差异判断必须靠任务状态判断。所以我建议在系统里引入一个简单的状态检查器每完成一个阶段检查一个明确的结果比如当前窗口标题是否已变化某个提示是否出现。这比盯着截图靠谱得多。第三类是死循环Agent 重复做同一组动作永远没有进展。应对方法很直接设定最大步数上限默认给 20 到 50 步超过就直接停止并输出完整操作日志让人类来接管。很多人忽略日志的价值但在这类系统里日志就是唯一的黑匣子没有日志你根本不知道它怎么就跑到别的地方去了。我实测下来还有一个很反直觉的体会把任务拆小比换更强的模型更有效。同样一个整理文件夹并重命名多个文件的任务让模型的单次决策越简单、范围越窄整体成功率越高。和团队协作的道理一样安排的工作越明确每个人的失误就越少。4.5 从最小循环到真实任务还差哪几步在最小循环跑通之后你会发现它离能干活还有很远的距离。这是因为真实任务往往不是一步一动能完成的而是需要先规划、再执行、边执行边修正。普通的 Agent 框架通常会在模型外面再套三层第一层是任务规划。你可以设计一个单独的规划模块把用户的目标拆成可执行的子任务列表。比如把销售报表发给财务可以拆成打开报表文件、查最新数据、生成摘要、写邮件、添加附件、发送。每个子任务再进入 CUA 的看、想、动、验循环。这样做的好处是即使其中某一步失败也只需要重试对应子任务而不必让整个长流程从头再来。第二层是记忆。CUA 需要记住已经完成过哪些步骤哪些方案尝试过但失败了当前处于哪个阶段。最简单的做法是用一个历史列表把每次截图、动作、结果都放进去作为模型判断下一步的上下文。稍微进阶一点还能抽出关键信息存成结构化字段比如当前窗口标题当前文件路径已填写的表单项减少模型上下文负担。第三层是结果校验。在子任务结束时应该有一个独立的判断逻辑确认是否真的完成而不是让 Agent 自己觉得完成。例如保存成功后检查文件列表里是否出现了新文件邮件发送后检查已发送文件夹是否多了一条记录。这个校验模块可以是一项规则也可以是一个更小、更快的分类模型关键是它和决策模型分开避免同一个错误被掩盖。把这三层加进去之后你手里的系统才算有一点产品雏形。我见过很多团队把精力全砸在让模型更聪明上结果真实业务效果还是不稳定回头一看卡住的往往是这种规划、记忆、校验的工程细节。所以我的经验是CUA 项目的第一版模型占三成工程占七成第二版开始工程占比还会继续提高。5. 那些不会写在 Demo 里的边界、风险与心得5.1 权限设计别给 Agent 一把万能钥匙CUA 一旦接入真实系统安全就是第一优先级。我现在不管做实验还是做工具都坚持这几个原则用独立账号运行 Agent账号权限只给任务需要的最少部分不给管理员权限。把 Agent 放在虚拟机或容器里限制访问宿主机文件和网络共享。涉及删除、覆盖、转账、发送邮件这类不可逆操作一律做成需人工确认模式Agent 先执行到关键步骤前停下等人在界面上点确认。记录每一步操作的时间、截图、执行结果至少保留一段时间备查。这些原则不是空话是因为 CUA 的误操作不像普通程序那样可以穷举——你没法枚举它所有可能的动作序列所以只能用缩小影响面 事后可审计来兜底。5.2 当前最容易踩坑的三种真实场景场景一登录和验证码。银行系统、企业微信、ERP 这些通常会有二次验证CUA 没法自己收短信所以流程设计上要预留人工介入点。比如 Agent 把界面停在验证码输入框人在旁边把验证码填进去Agent 再继续后续操作。这个半自动模式在现阶段非常实用。场景二浏览器指纹和页面反爬。很多网页会检测鼠标轨迹、点击速度、操作间隔。CUA 的点击动作通常又快又直容易被判定为机器人。这时候需要在执行层加入一点不确定性比如点击前移动轨迹稍微绕一下动作之间加随机延迟。不过这个方法只建议用在确实有正当业务需求的内部流程里别拿去搞违规操作。场景三多显示器与高分屏。CUA 截图通常只截主屏可实际业务系统可能在副屏上Windows 的 DPI 缩放也会让坐标换算出现偏移。解决办法是固定环境统一分辨率、统一缩放比避免跨设备直接复用坐标。5.3 接下来的几个月真正值得关注的方向从产品发展角度CUA 会沿着两条线推进。一条是操作系统原生支持未来的操作系统可能会给 AI Agent 提供标准的、结构化的界面上下文接口而不是让模型全靠截图像素去猜另一条是跨设备、跨应用编排不只操作桌面还去操作手机、网页、各种小程序任务可以横跨多个端。这两条线会让 CUA 从实验室玩具逐渐变成真正的生产力工具。对开发者来说现在最值得积累的是三样东西一是多模态模型对图形用户界面的理解和定位能力二是工程上的状态管理与失败恢复经验三是你手头业务领域里的标准操作流程库。前两者是通用技能后者是你最核心的壁垒。等模型能力再上一个台阶最值钱的反而是那些能定义什么任务值得交给 Agent、每一步该怎么校准的人和团队。5.4 一个朴素的起步建议如果让我把自己的经验浓缩成一句话给你别急着追求全自动万能操作员先选三五个固定任务在隔离环境里跑通、跑稳再逐步扩大范围。我自己最开始的实验项目就是自动从 PDF 里提取信息填到固定的网页表单里打印每一步都又慢又笨但正是这个笨项目让我把所有坑都踩了一遍。踩完之后你再看 CUA 相关的文章和产品会明显感觉它们不再是宣传词而是一套看得见边界、也看得见未来的技术路径。最后再分享一个小技巧给每个任务都配一个操作轨迹回放。不只是记录日志而是在每次任务结束后把截图按时间顺序合成一段视频。这个视频既能用来调试也能用来向同事或者团队展示 Agent 到底做了什么效率比文字描述高得多。我现在每个实验任务都会自动录屏很多模型为什么突然走神的谜题都是一帧一帧看回放时才找到答案的。