如果你最近刷到“CUA”这个词，别急着把它当成某个莫名其妙的网络梗。在 AI 圈子里，CUA 指的是 Computer-Using Agent，也就是能像人一样“看着屏幕、动手操作电脑”的智能体。2024 年底开始它频繁出现在各种技术分享里，到 2025 年依然挂在热搜上，原因是各家大模型厂商都在往“让模型替你把活干了”这个方向冲。
CUA 解决的痛很直接：过去我们让 AI 帮忙，只能打字聊天、生成文字，真正要“打开软件、填个表格、点几个按钮”还是得自己来。CUA 不一样，你给它一句“把这封邮件转发给李经理”，它能自己打开邮箱客户端、定位邮件、点击转发、输入收件人、发送，全程不需要预先录制脚本，也不需要人为固定每一步流程。
这篇文章我会把 CUA 从原理到落地完整拆一遍，包括它和传统 RPA 的区别、内部是怎么“看屏幕、做决策、执行动作”的，再给出一套可以跑通的最小实现方案，最后聊聊我实际使用过程中踩过的坑。想入局 AI Agent、做自动化测试、搞企业数字员工，或者单纯好奇 AI 怎么操作电脑的读者，都能从里面找到能直接用上的东西。
1. CUA 到底是什么：不是新 RPA，而是会“看屏操作”的智能体
1.1 从 ChatGPT 到 CUA：多模态模型跨出了“对话”的边界
大语言模型最初给人的能力是“对话”，你问它答，最多生成一篇文章或者一段代码。这种能力再强，边界还是停留在“输出文字”，它没法自己去点开浏览器、滚动页面、操作软件界面。CUA 的出现把这个边界往外推了一大步：模型不仅理解你说了什么，还能理解电脑屏幕上正在显示什么，然后输出一个有实际意义的操作指令。
CUA 之所以被称为“智能体”，是因为它不再是单次问答，而是处于一个完整的「观察-决策-执行-再观察」循环里。它能连续地看多轮截图，每一步根据当前界面状态决定下一步点哪里、输入什么。这个过程中模型自己是“驾驶员”，不是批处理脚本。
类比一下：传统聊天机器人像电话客服，你问一句它答一句；CUA 更像一个远程助理，它坐在你的电脑前，听着你的需求，自己看着屏幕帮你把事情办了，每做完一步还会回头确认效果。
1.2 CUA 和 RPA、普通脚本的本质区别
很多人听到 CUA 的第一反应是：这不就是 RPA（机器人流程自动化）吗？还真不是。RPA 的核心是把固定流程录制下来，按照预设规则执行，遇到界面变化往往就会崩；CUA 的核心是“理解界面 + 动态决策”，它没有一套写死的步骤。
| 维度 | RPA | CUA |
|---|---|---|
| 界面适配 | 依赖固定选择器、坐标、DOM 属性 | 依赖模型对截图/可访问性树的语义理解 |
| 流程变更 | 需要人工修改脚本 | 重新推理即可，多数情况无需改代码 |
| 异常处理 | 靠预设异常分支 | 靠模型观察新状态自主调整 |
| 前期成本 | 需要梳理流程、录制步骤 | 需要设计 prompt、环境闭环、安全机制 |
| 泛化能力 | 一个流程一套脚本 | 同一种操作可迁移到不同软件 |
我见过不少团队用 RPA 做表单自动化，最头疼的就是业务系统一改版，选择器全失效，脚本维护比新写还慢。CUA 的思路完全不同，它基本是“看着界面操作”，不依赖底层 DOM 选择器，界面上按钮从左边挪到右边也没关系，模型看一眼新截图就知道该点哪。
它为什么现在才火？核心原因是多模态大模型的成熟。模型要“看懂界面”，不仅需要识别文字，还需要理解按钮语义、布局结构、输入框状态，这些在过去只能靠 CV 和 OCR 拼凑，现在一个视觉语言模型就能搞定。算力、模型能力、指令跟随能力的同步提升，让 CUA 从实验室走向了实际应用。
2. 核心原理拆解：CUA 是如何“看见”和“动手”的
2.1 输入侧：屏幕如何变成模型能理解的信息
CUA 的第一步是“感知”。目前主流方案有两条技术路径，很多实际产品是两条混合使用。
第一条是纯视觉路径：截取整个屏幕或指定窗口区域的截图，把图片直接丢给视觉语言模型。这条路径普适性强，不管什么操作系统、什么软件都能用，微信、PS、浏览器、Excel 一视同仁。缺点是对截图清晰度敏感，界面太复杂时模型偶尔会漏看关键区域。另外，模型看到的是压缩后的图像，小字号文本经常识别不准，这个后面我会专门讲。
第二条是可访问性树路径：读取系统提供的 UI 结构信息，比如 Windows 的 UI Automation、macOS 的 Accessibility API、浏览器的 DOM Tree，得到类似 XML 的结构化内容，里面包含了按钮名称、输入框状态、列表项层级等。可访问性树比纯截图更“干净”，文字识别准确率很高，还能得出精确坐标。缺点是很多应用没有完整实现无障碍接口，拿到的东西残缺不全。
我在实际验证时发现，成熟的 CUA 产品通常会把两条路径拼接起来。例如大厂公开的 computer use 能力，它会同时接收截图和可访问性树，模型先基于结构化信息快速定位目标，再用截图做视觉确认。这样既保证精度，又不会因为缺少无障碍接口而瘫痪。
2.2 决策侧：多步任务怎么被拆解与执行
CUA 的“大脑”和普通大模型没有本质区别，区别在于输出格式被约束成“动作”。每一步模型接收到当前状态后，会先生成文本推理，再输出一个结构化的动作指令。一个典型的动作可能是：
{ "reason": "任务需要打开邮件应用，当前桌面没有邮件图标，所以先点击启动台", "action": "click", "x": 412, "y": 856 }动作类型一般包括 click（点击）、type（输入文本）、scroll（滚动）、hotkey（快捷键）、wait（等待）等。这样就形成了一种“中间语言”，把模型推理和真实操作系统连接起来。模型永远不用关心底层是怎么模拟鼠标的，它只负责输出“该点什么、该打什么字”，执行由工具层完成。
CUA 的多步能力来自“子任务拆分”。模型目录里可以包含一个高层计划，比如“先打开 Excel，再找到销售数据表，然后修改 B 列数据，最后保存”。每一步执行完之后，CUA 会截取新截图，判断当前界面是否和预期一致。如果不一致，它会根据差异调整下一步动作。
这是 CUA 最有价值的地方：它不是一个只执行一次命令的玩具，而是能在一个任务上持续稳定“干活”的循环系统。我在设计自己的 demo 时，专门会给模型一个“最大步数”限制，避免它在一个错误状态里无限重复操作。
2.3 反馈侧：环境变化如何被感知
CUA 的闭环不能只靠“发了指令就当完成”，必须验证结果。最简单的验证方式就是对比执行动作前后的屏幕截图，判断界面是否发生了变化。比如模型点击了“下一步”按钮，如果新截图里没有出现预期的表单页，就说明点击可能没生效或者点错了地方。
很多早期实验都会遇到“任务根本没完成，但模型觉得完成了”的情况。原因是模型只看了自己发出的动作序列，没有认真解读最后一屏的状态。解决办法是让 prompt 明确要求：每次结束任务前，检查最后一张截图，确认目标状态真的出现。
为了减少误判，还可以引入简单的状态向量，比如检测目标窗口是否打开、目标元素是否存在、页面文字是否符合预期。这些轻量规则不是要替代模型，而是充当“安全网”，防止模型出现幻觉式完成。
3. 自己动手实现一个迷你 CUA：方案选型与落地步骤
3.1 主流落地方案对比：云端 API、开源模型、本地工具
要跑一个 CUA 原型，现在可选的路不少。我把常见的方案分成了三类，分别对应不同需求。
云端 API 方案：直接使用大厂开放的 Computer Use 能力或视觉对话能力，优点是开箱即用、模型能力强，适合快速验证和做 PoC。缺点是单位调用成本相对高，且把屏幕截图发送到云端会有数据隐私顾虑。适合业务数据不敏感、只想快速看效果的团队。
开源模型方案：基于 UI-TARS、OSWorld 这类开源模型或数据集搭建本地服务。优点是数据完全本地化，可以私有化部署，长期看成本更低。缺点是硬件门槛高，推理速度不如云端，而且开源模型的综合能力通常弱于商用大模型。
自组装方案：不去找专门的 CUA 接口，而是拿一个支持视觉输入的多模态模型，自己编写“截图-调用模型-执行动作”的循环。优点是灵活，不绑定厂商，好理解原理；缺点是需要自己处理很多工程细节，实际效果取决于模型基础能力。
我自己验证时用的是第三种方案。先用一个视觉语言模型的 API 做原型，等流程跑通后再考虑把模型替换成私有化部署版本。这样踩坑成本低，迭代快，而且每次换模型只要改一个 adapter，不影响整体架构。
3.2 最小可运行 Demo：用 Python 让模型“看屏点按钮”
下面这套脚本是 CUA 的最小闭环：截取当前屏幕，把截图发给多模态模型，让模型返回一个动作 JSON，然后用 pyautogui 执行点击。你可以把它当作一个可扩展的骨架。
import os import base64 import json import pyautogui from openai import OpenAI client = OpenAI(api_key="your-api-key") def capture_screen(path="screen.png"): """截取当前屏幕并返回 base64 字符串""" screenshot = pyautogui.screenshot() screenshot.save(path) with open(path, "rb") as f: return base64.b64encode(f.read()).decode() def ask_model_for_action(screenshot_base64, task): """让模型看截图，输出一个动作 JSON""" response = client.chat.completions.create( model="gpt-4o", # 换成你有权限访问的视觉模型 messages=[ { "role": "user", "content": [ { "type": "text", "text": ( f"任务：{task}\n" "请根据这张截图返回一个 JSON 动作，格式如下：\n" '{"action": "click|type|scroll|wait", ' '"x": 整数, "y": 整数, "text": "要输入的内容", ' '"reason": "简短说明"}\n' "坐标范围以图片实际尺寸为准。" ), }, { "type": "image_url", "image_url": { "url": f"data:image/png;base64,{screenshot_base64}" }, }, ], } ], temperature=0, max_tokens=300, ) content = response.choices[0].message.content # 清理模型输出中可能的代码块标记 if "```json" in content: content = content.split("```json")[1].split("```")[0] return json.loads(content.strip()) def execute_action(action): """根据动作 JSON 执行真实操作""" if action["action"] == "click": pyautogui.click(action["x"], action["y"]) elif action["action"] == "type": pyautogui.typewrite(action.get("text", "")) elif action["action"] == "scroll": pyautogui.scroll(action.get("clicks", -3)) elif action["action"] == "wait": pyautogui.sleep(1) if __name__ == "__main__": task = "打开电脑里的计算器应用" for step in range(5): # 最多执行 5 步 screenshot_b64 = capture_screen() action = ask_model_for_action(screenshot_b64, task) print(f"Step {step + 1}: {action}") execute_action(action) pyautogui.sleep(0.5)这段代码里有几个关键点需要说明。第一，temperature必须设置得很低，我通常直接设成 0，因为动作输出需要确定性，不需要创造性。第二，坐标范围很重要，模型是按它看到的图片尺寸输出坐标的，如果截图是 1920x1080，实际屏幕也是 1920x1080，可以直接用；如果你在代码里压缩了截图，就必须把坐标按比例映射回真实屏幕，否则会点偏。第三，max_tokens不用太大，动作 JSON 结构简单，300 token 足够，给多了反而容易让模型啰嗦。
3.3 从 Demo 到可用系统：权限、循环控制与任务状态机
上面的 demo 只能算“能点”，离“可用”还有距离。我在把它扩展成能处理真实任务的工具时，加了三个关键设计。
第一是任务状态机。把一次 CUA 执行过程切成几个状态：INIT（准备）、RUNNING（执行中）、WAIT_CONFIRM（等待人工确认）、DONE（完成）、FAILED（失败）。模型每输出一个动作，程序就进入 RUNNING，执行完动作后重新截图判断是否达到目标，如果连续多次没有状态变化，就切换成 FAILED 并且停止。
第二是人工审批闸门。对于删除文件、发送邮件、执行支付这类风险动作，我在动作执行前加一道approval_callback，只有通过审批才真正执行。这是非常实用的安全设计，我后面会在踩坑部分详细解释为什么不能省。
第三是完整 trace 日志。每轮循环的截图、动作 JSON、模型推理理由都存成文件。一来方便定位问题，二来如果出了安全事故，有完整的操作记录可以复盘。我见过一个团队跑 CUA 自动化时误操作导致文件被覆盖，因为没有任何 trace，完全说不清是哪一步出了问题，最后只能自认倒霉。
4. 踩坑实录：我跑 CUA 时遇到的 5 个典型问题与排查方法
4.1 截图分辨率低，模型看不清小字怎么办
模型对截图的识别能力和图片尺寸直接相关。我一开始图省事，直接把 4K 屏幕截图压缩成 512 宽度再发给模型，结果一个小按钮上的文字模型根本认不出来，经常把“保存”看成“打开”。后来我调整策略：不压缩整个屏幕，而是让用户先用鼠标框选目标区域，只对局部区域做高分辨率识别。系统会先做一次“全局视野”，让模型确定目标大概在哪个区域，然后放大该区域再做精细判断。两阶段识别后准确率提升非常明显。
4.2 坐标偏移：跨设备、跨分辨率带来的“点错”问题
坐标偏移是 CUA 最容易踩的坑，没有之一。模型输出坐标是相对于“输入图片”的，如果你的代码对截图做了 resize，但执行端 pyautogui 用的是真实屏幕坐标，那么点击位置一定会偏。比如截图按 0.5 倍缩放发给模型，模型说“点 (400, 300)”，那真实屏幕坐标应该是 (800, 600)。这个问题在单机单分辨率下不容易发现，一旦换电脑或者外接显示器，偏移就会非常明显。排查办法是让模型顺手输出“图片尺寸”，代码端再做一次比例换算；宁可多传一个参数，也不要默认两者一致。
双屏环境更麻烦。副屏在屏幕左侧时，坐标会存在负值，很多模型的视觉编码器对负坐标支持很差。我的做法是把所有屏的截图拼成一张大图，然后把副屏起点平移到正坐标，执行时再映射回去。好在这个问题只在多屏场景出现，普通用户较少遇到。
4.3 动作死循环：模型反复点同一个位置
跑 CUA 时间长了你会发现一个典型现象：模型卡在某一步，反复点击同一个位置，但界面没有任何变化。原因通常有两个。第一个是界面元素是动态加载的，点击后内容需要时间渲染，模型没等到加载完成就截图判断，以为没点中。我加了wait动作和固定轮询间隔后，这个问题少了很多。第二个是模型本身陷入了重复决策，没有真正观察到界面变化。
针对第二种情况，我在调度层做了两个机制。一是动作去重：如果一个完全相同的动作出现多次，并且前后截图相似度超过阈值，就强制终止当前任务并输出错误提示，避免无限循环浪费 token。二是“无变化计数”：每执行一步，比较新截图和上一轮截图，如果连续 3 轮没有实质变化，就切换策略，让模型尝试其他路径，比如按 Tab 键代替直接点击。
4.4 安全与权限：让 AI 操作电脑最容易被忽视的坑
只有亲手跑过才知道，让 AI 直接操作真实电脑是一件多么“刺激”的事。有一次我的 demo 本来只是让它测试一个表单，结果模型识别错了元素，在桌面文件区域连续点了好几下，差点把文件拖进错误目录。这给了我一个很重要的教训：CUA 的安全问题不能靠模型自觉，必须在系统层面强制。
我现在坚持三个原则。第一，默认不授权高风险操作，删除、发送、付款、关闭未保存文件等动作全部必须人工确认。第二，尽量在虚拟机或沙箱环境里做自动化测试，虚拟机的系统恢复成本远低于实机。第三，限制操作范围，如果任务只需要操作某个浏览器窗口，就把截图裁剪到该窗口，并屏蔽其他区域，减少误操作面。
4.5 Token 开销与速度：为什么一个简单任务也能烧掉很多钱
很多人低估了 CUA 的 token 消耗。一张普通 1080p 截图缩小后，视觉 token 通常在 1000 到 2000 之间，一个界面复杂一点能到 3000 以上。一个 20 步任务跑下来，光截图就可能消耗 4 万 token，再加上模型推理输出的文本，成本并不低。速度上，一轮“截图+推理+执行”通常要 3 到 8 秒，如果要操作 20 步，整个任务可能要两三分钟。
应对方法是“少看几次”。不是每步都必须把完整截图发过去，如果界面没有变化，可以复用上一轮的截图；如果任务只需要某个区域的信息，就只传裁剪后的局部截图。我还习惯把对话历史控制在最近 5 轮以内，太早的截图和推理记录及时清理，既能省 token，也能减少模型注意力分散。对于高频重复任务，我建议先跑一遍记录轨迹，之后用固定脚本执行，没必要让模型反复“重新发明轮子”。
5. 下一步想象：CUA 会怎么改变我们的工作方式
5.1 从“聊天机器人”到“数字员工”
CUA 真正值得期待的地方，不是它能在你面前炫技点几个按钮，而是它会重塑“人机协作”的边界。以前我们说数字员工，本质上还是一堆 API 接口和定时任务的集合；CUA 让数字员工第一次有了“肉眼可见的动手能力”。财务对账、客服查单、运维排查、测试回归，这些依赖图形界面操作又重复枯燥的岗位，都可能被它逐步渗透。
我自己最看好的场景是“遗留系统自动化”。很多企业核心系统没有 API，只有老旧图形界面，RPA 脚本又脆弱，CUA 反而显得异常合适。它不需要系统开放接口，只要人能看屏幕操作，它就能学着操作。这意味着大量被判定为“根本无法自动化”的流程，现在有了重新评估的空间。
5.2 给开发者的建议：现在可以开始准备什么
如果你想跟进 CUA 这个方向，我建议不用等工具完全成熟再入场，现在就可以做三件事。第一，熟悉多模态模型的输入输出，尤其是如何通过 prompt 约束模型输出结构化动作，这是 CUA 的最核心技能。第二，写一个最小闭环，不需要复杂架构，就像上面那套 Python 脚本一样，先让自己对“截图-推理-动作-反馈”有体感。第三，多关注事件驱动架构和无头浏览器，CUA 只是决策层，落地时仍然需要可靠的执行和监控底座。
另外，如果你要在团队里推 CUA，别一上来就追求全自动。最稳打法是先用人工审批模式跑一个低频任务，收集 trace 数据，评估准确率、成本、速度，再逐步放开权限。AI 自动化这件事，步子迈太大会翻车，小步快跑才符合实际。
我个人在实际操作中的体会是，CUA 的技术框架并不神秘，真正的难点全在工程细节：坐标精度、状态判断、安全闸门、成本控制。每一个细节单独拿出来都不难，但组合在一起就筛掉了绝大多数半途而废的尝试。最近我跑通一个“自动整理下载文件夹”的流程后明显感觉到，这类工具现在确实已经从概念验证走到了可以辅助干活的阶段，只是需要我们在上层做好约束和引导。最后再分享一个小技巧：所有 CUA 任务都从“最小可接受结果”开始定义，比如“文件移到对目录”就算成功，而不是等模型自己发挥成十全大补丸。这样你才有耐心把一个智能体调教到能稳定上班的状态。
