★ FEATURED ARTICLE 最近两个星期我朋友圈和几个技术社群里全是CUA这三个字母。有人说是AI要取代程序员了有人说这不就是老掉牙的RPA套了层大模型皮吗还有人把Computer Use Agent念成“cua”说这玩意儿操作电脑跟嘴里喊一声“嗖”一样快。吵归吵我实际把好几款支持屏幕操作和桌面自动化的智能体方案跑了一遍也自己写了一个最小可用的Agent原型。这篇把CUA到底是什么、它能干什么、不能干什么、以及你自己怎么从零搭一个全部摊开讲清楚。想搞AI Agent落地的人、做自动化流程设计的朋友这篇应该能帮你少走不少弯路。1. CUA不是新概念但偏偏在2025年火了1.1 从“AI只能出嘴”到“AI可以出手”先回忆一个场景过去我们用ChatGPT或者各类模型助手最多是让它写一段代码、给一个方案然后我们自己复制粘贴到电脑里去执行。这个链路的瓶颈不在模型而在“最后一公里”。模型知道应该点哪个按钮、输入什么内容但它没有眼睛和手。CUA要补的正是这一段。我自己的体感是CUA这个词从2024年下半年开始密集出现在技术社区的分享里到2025年几乎成了AI Agent赛道的标配话题。核心原因是模型能力终于跨过了一个阈值它不仅能看懂自然语言还能把一张电脑截图里的按钮、输入框、菜单栏当成“视觉输入”来处理并且给出“该点哪里”的精确坐标。这个能力往前推三五年基本是做不到的。1.2 CUA到底是什么Computer Use Agent直译就是“计算机使用智能体”英文里也有Computer Using Agent的写法。它指的不是某个单一模型而是一套能观察图形界面、推理操作步骤、通过鼠标键盘输入与系统交互的智能体系统。它在技术上的核心组件有三个感知模块负责获取屏幕画面、窗口结构、UI元素信息决策模块通常由一个多模态大模型承担根据当前屏幕状态决定下一步做什么执行模块把决策转换成真实的鼠标移动、点击、键盘输入、滚动等系统事件这三个模块串起来就形成了一条“观察-思考-行动-再观察”的循环。你可以把它理解成给大模型装了一双眼睛和一双手让它能像人一样坐在电脑前干活。1.3 为什么偏偏是这两年爆发很多年前RPA机器人流程自动化就已经能做类似的事情但CUA的爆发有几个客观条件多模态模型成熟了。早期CV模型只能做物体检测、OCR识别出“这里有一个按钮”但理解不了“这是一个保存按钮点击后应该出现保存成功的提示”。现在的多模态大模型把视觉和语义理解揉在一起看到一个复杂界面能像人一样理解整体布局和交互关系。指令遵循和规划能力到了可用级别。一个CUA任务往往需要连续操作十几步甚至几十步模型必须记住目标是什么、当前做到哪一步、出错之后怎么回退。Instruction Following能力不够强的模型跑三步就忘了最终任务。各家厂商把基础能力开放出来了。底层模型、屏幕理解API、Agent框架陆续开放开发者不需要自己从零训练一个“会点鼠标”的模型直接调接口就能搭出一套可用的方案。开源生态也跟上了本地模型配合UI解析工具也能实现一个小规模CUA。成本曲线在往下走。视频视觉模型的单次调用价格比两年前低了一个数量级截图理解这种任务不再是大厂专属。再加上“cua”这个口语化的简称在网上越传越广术语本身也出圈了。2. CUA、RPA、浏览器自动化看着像其实不是一回事2.1 RPA的问题在于“菜单记忆”很多朋友一听到CUA就想到RPA这很自然。但这两者底层逻辑完全不同。传统RPA本质上是一个放映机你录一遍流程它以后按同样的轨迹播放。它靠的是固定坐标、控件选择器、窗口句柄这些“硬钩子”。问题就在于桌面软件改个版式弹窗位置变一下页面加了一个新的bannerRPA的流程就断了。我拿一个生活化的例子来讲RPA就像你每天去同一家餐厅照着上次点的菜单原封不动再点一遍。只要餐厅换个菜单版式、菜名改个字你就懵了CUA不一样它像是一个坐在餐桌前的人先看一眼当前菜单判断“我要的红烧肉这道菜在不在在哪里”然后才动筷子。这个差异决定了RPA适合极稳定的高频流程CUA适合有一定变化但目标清晰的长尾任务。2.2 浏览器自动化被限制在“浏览器容器”里再说浏览器自动化典型工具有Playwright、Selenium、Puppeteer。它们确实能做复杂的网页操作但工作范围被严格限制在浏览器内部通过DOM选择器找到元素再模拟点击、输入。一旦目标跳出浏览器范围比如需要从网页复制数据再填进一个桌面Excel表格或者网页弹出了操作系统级别的文件选择框浏览器自动化就无能为力了。而CUA工作在操作系统层面它像一个真实用户一样操作整个桌面环境。浏览器只是它要操作的对象之一文件管理器、办公软件、内部系统客户端只要屏幕上能显示、能用鼠标键盘交互的东西理论上它都能操作。这个范围上的差异是本质性的。2.3 用一张表看清三者差异维度传统RPA浏览器自动化CUA驱动方式录制脚本固定选择器DOM元素选择器多模态模型语义理解工作范围桌面/指定软件浏览器内网页整个操作系统界面抗界面变化能力差改版即失效中依赖选择器更新较强靠语义识别长尾任务处理差流程外情况无法处理差好可实时推理单次运行成本低低较高模型推理产生费用部署门槛中低中高需要模型API或本地算力2.4 我的判断不是替代是互补现在很多人讨论“CUA会不会干掉RPA”我的看法是短期内不会而且两者很可能长期共存。RPA在强规则、强审计、高稳定性的场景里依然有优势比如财务对账、批量报表这些流程不允许模型“临场发挥”。CUA更适合的是那些RPA写起来极其痛苦、规则极难穷举的场景比如不同界面的填表、数据搬运、界面巡检。更聪明的做法是把两者混编CUA负责判断和导航RPA负责执行已经被验证过的高频动作。这样既省了模型调用费用又提升了整体稳定性。3. 拆开一个CUA感知、规划、执行、验证四段闭环3.1 感知层截图只是最底层的方案CUA的感知层有两条技术路线实际项目里最好两条都上。第一条是纯屏幕截图。把当前屏幕或者指定窗口截下来交给多模态模型去理解。这条路最通用什么软件都适用因为人类能看的它就能看。缺点是截图分辨率高的时候token消耗大而且模型只能“看”到像素拿不到元素背后的属性信息比如一个按钮的控件ID、一个输入框的变量名。第二条是读取系统可访问性树Accessibility Tree。操作系统为了让辅助功能工具能读屏会暴露控件树信息每个按钮、文本、输入框叫什么、在什么坐标、当前是什么状态。访问可访问性树就像拿到一份带标注的地图比纯截图精确得多。我在自己的原型里采用的做法是优先读可访问性树拿到界面元素和坐标只有树拿不到关键信息时才补一张截图让模型判断语义。比如一个空白画布上没有可识别的按钮但模型通过截图能看出这是画布区域这时截图就很有用。纯截图相当于人眯着眼找按钮可访问性树相当于直接给按钮贴了坐标标签两者结合最稳。3.2 规划层模型怎么决定“接下来点哪儿”规划层是CUA的大脑通常由一个指令遵循能力强的大模型承担。它的输入是当前屏幕状态和用户目标输出是下一个动作。这里有一个关键设计不要让模型输出自然语言“你应该点击文件菜单”而是强制它输出结构化JSON。我在项目里给模型固定的输出格式{ thought: 当前页面有用户登录框需要先点击用户名输入框, action: { type: click, x: 320, y: 180 } }保留thought字段有一个额外价值审计。当Agent做错时你可以回看它当时的“思考过程”定位是哪一步理解出错了。这在调试多步任务时几乎是救命的功能。3.3 执行层把意图变成鼠标键盘事件执行层相对简单但坑不少。我最早用pyautogui做鼠标键盘模拟因为它跨平台、API简单。在Windows上直接能用在macOS上需要给终端开启辅助功能权限系统设置-隐私与安全性-辅助功能否则鼠标事件会被系统拦截。执行时有三个实操细节值得注意鼠标移动到目标坐标后不要立刻点击最好等0.2到0.5秒让系统完成界面渲染点击后不要马上进入下一步留出界面响应时间具体时长要看目标软件的反应速度输入中文文本时不要用keyboard.type逐字模拟中文输入法会捣乱正确做法是先把文本写入剪贴板再模拟CtrlV粘贴3.4 验证层动作做完必须确认“有没有生效”很多初版CUA原型最缺的就是验证层。模型说“点击下一步”系统也确实点击了但界面上弹了一个对话框挡住了下一步按钮此时Agent如果继续按照原计划操作就会一路点错。验证层的做法是每次执行完动作后截一张新图让模型判断界面是否发生了预期变化。比如“点击保存后是否出现了‘保存成功’的提示”。如果没出现就要走异常处理分支重试、截图分析原因、或者停下来请求人类帮助。在真实桌面环境里验证层比规划层更重要。因为错误总是发生在“你以为成功执行了”的时候。3.5 人的位置确认模式必须要做现阶段我不建议任何CUA系统全程完全无人监督。至少保留一个可配置的“确认模式”每执行一个关键动作之前先把动作展示给用户用户确认后才执行。比如Agent要点击“删除”按钮、要发送一封邮件、要提交一个表单这些都属于高风险动作必须经过确认。这不是保守而是CUA落地的底线。用户信任是在一次次“没有搞砸”中积累的一次乱点造成的损失可能让整条产品线被拉黑。4. 用Python手搓一个极简CUA原型让AI替你打开计算器算个加法4.1 环境准备既然要自己动手就上最简单的技术栈。我的原型依赖三个东西Python 3.10pyautogui截图和鼠标键盘模拟pillow图像处理一个可调用的视觉语言模型服务云端API或本地模型都可以以下代码以OpenAI风格的客户端示例安装命令pip install pyautogui pillow openai注意macOS用户需要先给终端/IDE开启辅助功能权限Windows用户一般直接就能跑。多显示器环境下建议先把分辨率固定下来或者在代码里指定操作主屏幕。4.2 核心代码截图、决策、执行下面是一段能跑的最小实现核心逻辑就是“截图-让模型决定动作-执行-循环”。你可以直接复制下来改成自己的任务。import json import time import io import base64 import pyautogui from PIL import Image from openai import OpenAI client OpenAI() # 需要提前配置好你的模型服务端点和密钥 # 截图并压缩降低token消耗 def capture_screen(max_size(1280, 720)): img pyautogui.screenshot() img img.resize(max_size) img img.convert(RGB) buffer io.BytesIO() img.save(buffer, formatJPEG, quality70) return base64.b64encode(buffer.getvalue()).decode() # 让模型基于当前屏幕输出一个动作 def ask_for_action(screen_b64, instruction, system_prompt): response client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: system_prompt}, {role: user, content: [ {type: text, text: instruction}, {type: image_url, image_url: { url: fdata:image/jpeg;base64,{screen_b64} }} ]} ], temperature0, ) return response.choices[0].message.content # 执行模型返回的结构化动作 def execute_action(raw): action json.loads(raw) print(思考过程, action.get(thought, )) act action[action] if act[type] click: pyautogui.click(act[x], act[y]) elif act[type] type: pyautogui.write(act[text]) elif act[type] scroll: pyautogui.scroll(act[clicks]) elif act[type] wait: time.sleep(act[seconds]) elif act[type] finish: print(任务完成) return False return True # 系统提示词约束模型只能输出结构化动作 SYSTEM_PROMPT 你是一个计算机操作智能体。你会收到一张当前屏幕截图。 你的目标是根据用户指令完成操作。 只能输出一个JSON对象格式如下 {thought: 你对当前界面的判断, action: {type: click, x: 0, y: 0}} action.type 可选值 - click: 必须提供x, y坐标 - type: 必须提供text内容 - scroll: 必须提供clicks数正数向上滚动 - wait: 必须提供seconds秒数 - finish: 表示你认为任务已完成 def run_task(task_description, max_steps15): instruction task_description for step in range(max_steps): screen capture_screen() raw ask_for_action(screen, instruction, SYSTEM_PROMPT) print(f第{step 1}步, raw) should_continue execute_action(raw) if not should_continue: break time.sleep(0.8) # 等待界面响应 else: print(达到最大步数限制停止。) if __name__ __main__: run_task(打开电脑上的计算器计算 7 5显示结果。)4.3 跑起来会发生什么第一次跑这个任务时你会看到Agent的行为不太像程序更像一个“人”第一次截图是完整桌面模型判断“需要先打开计算器”返回一个点击任务栏图标的坐标。执行后第二次截图显示计算器已经打开模型判断“现在需要依次点击7、、5、”于是连续返回几次点击动作。最后它看到结果“12”显示在屏幕上返回finish动作循环结束。这个流程里模型并没有任何“预先录制”的坐标它完全是依靠每次截图里的视觉信息现场推理。这就是CUA和传统RPA最不一样的地方——换一台电脑、换一个分辨率它依然能找到计算器的位置而RPA录好的坐标直接就废了。4.4 为什么必须用结构化JSON输出有人可能会想为什么不直接让模型用自然语言说“点击x坐标y坐标”非要套一个JSON原因有三个第一解析稳定。自然语言有无数种表达方式“点这里”“鼠标左键按在某个位置”“点一下那个按钮”每一样都要写正则去匹配迟早崩溃。JSON天然结构化json.loads一次解析字段缺失一眼就能发现。第二执行层可替换。模型层只产JSON执行层只消费JSON两个模块解耦。今天用pyautogui模拟鼠标明天换成系统级的UI Automation框架甚至换成网页自动化工具执行层改动很小模型层完全不用动。第三便于扩展。后面想增加双击、拖拽、右键菜单、复制粘贴等能力只需要在JSON的action.type里加枚举值然后在执行层加对应的分支函数模型会通过系统提示词学会新动作。4.5 离产品级还差多少上面这段代码只是一个“视觉-动作循环”的雏形距离真正能稳定跑业务还差很多东西长会话记忆任务一长多轮截图和动作结果会超出模型上下文窗口需要做历史信息压缩和摘要循环和退避同一个动作连续失败几次之后要继续尝试还是换一种方案需要一个决策机制局部截图不需要每次都截全屏往往只裁剪变化区域就能决策成本和延迟都会大幅下降异常恢复某一步出错后能否回退到上一个稳定状态而不是越走越偏沙箱隔离在不可控系统环境里跑操作最好指定一个虚拟桌面或者容器来兜底我在实际项目里是先跑通最小原型再逐步把这些工程问题加进去的。最忌讳一开始就把系统设计得像一个大而全的平台结果连一个最简单的任务都跑不稳。5. 什么场景值得交给CUA什么场景现阶段别碰5.1 真正值得做的三类场景根据我的实测下面三类场景CUA的效果最明显ROI也最高。第一类是跨系统数据搬运。典型场景是从网页后台导出数据填到本地Excel或者另一套业务系统里。这个过程往往涉及到字段对齐、格式转换、去重判断用RPA写规则极度痛苦用CUA反而简单——把数据源界面和目标界面截图给模型告诉它“把A系统这一行的名称、金额、日期填到B系统对应字段里”它能边看边搬。第二类是重复且需要判断的表单填报。比如每天根据一组邮件内容在不同的选项里勾选对应项并提交。判断条件一变RPA脚本就要改CUA靠语义理解描述变了也能处理。第三类是界面上巡检和数据看板摘要。每天早上打开几个软件截图让模型生成一份前一天的运营摘要。这种任务不要求极快的速度也不需要100%的确定性很适合Agent试水。5.2 现阶段别指望这些场景有一些场景现阶段把CUA硬塞进去会非常痛苦毫秒级交互操作。股票交易、竞技游戏、实时音视频控制这些对延迟极其敏感截图-推理-执行这个循环本身就跑不起来需要物理外设配合的场景。比如U盘插拔、扫码枪扫描、打印纸张分类CUA只能操作虚拟界面摸不到物理世界高风险系统管理操作。比如删库、批量改权限、生产环境配置变更这些应该走API加审批流而不是让Agent看着屏幕点鼠标涉及大量敏感数据的自动化。如果把客户个人信息、财务数据直接截图喂给外部模型API合规上会有很大问题需要先想清楚方案5.3 成本和安全用钱和隐私换效率要有边界CUA每一步操作都要带一张截图给模型一个30步的任务最坏情况下会产生30次视觉模型调用。我算过一笔账如果每步都用旗舰视觉模型的API一个复杂任务的成本可能在几元到几十元不等具体看截图大小和模型定价。批量跑还好一旦变成高频生产任务成本压力会很大。几个降本优化手段我实测有效优化方式效果截图压缩到1280x720以内转JPEG质量70token费用大约能降到原来的50%以内优先读可访问性树减少不必要的截图请求次数和整体延迟大幅下降简单界面用便宜小模型困难步骤才调旗舰模型总成本降一半效果不明显打折安全层面上最重要的是敏感数据的流向必须提前设计。如果业务文件包含客户信息、薪资、内部经营数据建议使用本地部署模型或者在私有网络环境内运行别想都不想就直接调外部API。这条路一旦走错后面补合规成本会非常昂贵。6. 实践中踩过的坑五条值得写进文档的教训6.1 分辨率一变坐标全是错的我在第二版原型里遇到了一个非常低级的错误开发机上跑得好好的Agent换到一台高分屏笔记本上就到处乱点点击位置明显偏了。原因是截图做了缩放处理而点击事件用的是截图缩放后的坐标没有做映射换算另外系统DPI缩放比例不同同样一个按钮在不同电脑上的屏幕坐标也不一样。现在的经验是要么在代码里把截图分辨率固定下来并让执行层基于同一坐标系计算要么直接用pyautogui提供的size()换算实际屏幕尺寸。如果是在虚拟机里跑直接把分辨率锁死能省掉一堆兼容麻烦。6.2 弹窗是所有Agent的杀手桌面软件比起网页更容易弹窗证书更新提示、广告弹窗、未保存修改提醒、Windows Defender提示任何一个弹出来都会挡住原本要点击的区域。更麻烦的是弹窗出现的位置和内容都具有随机性你没法提前预知。我的解法是在系统提示词里加一条硬规则“如果检测到未预期的弹窗先处理弹窗再继续原任务。”同时在验证层专门写了一个分支对比上一步截图和当前截图如果出现了新的大面积视觉变化且模型认为当前不是预期界面就先调用“关闭弹窗”动作。实测下来加上这条规则后连续任务的成功率能提升两成以上。6.3 Agent会陷入死循环有一次我测试一个数据录入任务Agent因为找不到一个隐藏菜单连续七次执行同一个点击动作每次的thought都是“点击菜单展开按钮”但菜单根本没弹出来。如果不加限制它能对着同一个坐标点到天荒地老。后来我在所有循环外面加了一个计数器超过15步就停下来把当前状态发给用户请求指导。这一步是保障系统可靠性的底线宁可停下来让人类接管也不能让错误动作无限重复。6.4 token消耗比想象中更快我第一次跑通完整流程后看API账单吓了一跳一个不到三十步的任务光截图理解就消耗了惊人的token。问题就出在全尺寸PNG截图一张图几MBbase64编码之后完全失控。后来做了三个改动截图前用Pillow把分辨率压缩到1280x720全部转JPEG格式quality设为70部分简单操作不再传截图直接根据可访问性树的坐标执行同样的任务成本直接降到原来的三分之一不到。6.5 敏感数据和外部模型之间要有一道墙这是我在项目上线前才发现的问题一个内部系统的数据搬运任务每天经过Agent处理的文件里包含客户合同信息而我的原型默认把全屏截图发给了外部API。这意味着合同里的金额、客户名、联系方式都可能被发送到第三方服务。发现问题后我们临时把方案改成了两步走先用本地小模型做敏感信息检测截图里如果出现疑似身份证号、手机号、金额等字段就裁剪掉对应区域或者打上马赛克再传给外部大模型。这当然增加了工程复杂度但这是必要成本。在合规这件事上越早考虑后面越省心。我实际用这套原型跑了两个多月的报表整理和界面巡检最大的感受是CUA并不是让人变懒而是把人和软件之间的“翻译成本”降下来了。以前我写一个RPA脚本要反复调试选择器现在只需要对着屏幕说清楚目标Agent自己理解界面、完成操作遇到不懂的还能停下来问我。最后分享一个小技巧每一轮把上一步操作后的截图和一句简短的环境描述一起传给模型比如“当前在计算器界面右上角有关闭按钮”成功率会比只丢一张裸截图高不少因为模型的注意力会被引导到关键区域。CUA现在还远不完美但方向已经明明白白AI不光会说话开始会“干活”了。
阅读完成 · 觉得有帮助？
