最近半年我一直在折腾一个叫 CUA（Computer Use Agent，计算机操作智能体）的项目，简单说就是让 AI 像人一样看着屏幕、移动鼠标、敲键盘，把日常在电脑上干的活儿自动干了。你给它一句“把这份表格里所有客户的联系方式整理成文档”，它自己去开软件、找数据、填内容，全程不用人盯着。这个方向这两年特别热，从最早的那批实验室原型到现在的开源方案，已经能跑出不少能用的东西了。这篇就聊聊我自己从零搭一套 CUA 踩过的坑、理清的思路，以及最后跑通的完整链路。如果你也想做类似的东西，或者正纠结机器人能不能替你操作软件，这文章应该能帮你省不少时间。
1. CUA到底解决了什么问题
1.1 传统自动化的痛点
先说清楚 CUA 这个赛道为什么会火起来。之前做自动化，主流方案无非两条路：一是 RPA，靠录制鼠标坐标、抓界面控件 ID、模拟键盘输入来跑固定流程；二是写脚本调用 API，让程序按接口去操作数据。这两条路都行，但都有个拧巴的地方——它们太“死”了。
RPA 录好的流程，窗口分辨率变了、界面改版了、弹窗换了个样式，脚本就崩。API 方案更脆，对方系统不给你接口，数据就只能干瞪眼。我见过不少公司的自动化项目，前期投入巨大，最后败给了“系统改版频率”。本质上，这些都是把流程写死成“固定剧本”，剧本一有出入，演员全乱套。
1.2 CUA的核心思路：把“自动化”变成“协作”
CUA 换了个思路：不写剧本，而是让 AI 充当一个长了眼睛的“实习生”。它通过截图理解屏幕上有什么，通过视觉和目标识别判断下一步该点什么、输入什么，然后直接操作真实的鼠标键盘。整个过程和人的操作习惯几乎一样——看到、想到、做到。
这样一来，界面改版不再致命。AI 能识别出“左上角那个搜索框”，而不是记住“坐标(120, 340)那个元素”。弹窗出现时，它能读里面的文字内容，决定是点“确定”还是点“取消”。这种从“固定流程”到“动态决策”的转变，才是 CUA 真正的价值所在。它不替代 RPA，而是把 RPA 覆盖不了的、需要临场判断的活儿接了过来。
2. 完整链路拆解：从截图到点击，AI 是怎么“看懂”屏幕的
2.1 第一步：屏幕感知与页面理解
CUA 的第一环节是感知。这个环节要解决的核心问题是：屏幕上到底有什么？
具体做法并不复杂——定时截取整个屏幕或指定窗口的画面，把这张图交给一个多模态大模型，让它用视觉能力去“看”这张图。这里有个容易踩的坑：直接把整张截图扔给模型，效果往往很差。原因有两个，一是分辨率太高，模型在处理时为了适配输入尺寸会压缩图像，小字根本看不清；二是信息太多，界面里的广告、侧边栏、无关按钮都会干扰模型的注意力。
我的实践经验是，先做一步裁剪，把操作区域缩小到目标窗口内，再做一次缩放，控制在模型比较舒服的分辨率范围内。同时，把界面里能拿到的文本信息（比如浏览器的标题栏、按钮 label、输入框 placeholder）作为辅助文本一起喂给模型。多模态模型虽然能读图，但纯视觉读文字还是容易出错，有原生文本辅助时识别准确率能提升不少，特别是在处理表单、表格这种密集文本的场景下。
2.2 第二步：目标定位与动作规划
看懂了屏幕之后，就得决定“下一步怎么办”。这一步是整个 CUA 的核心，业内一般叫它 grounding，也就是把“我要点什么”翻译成“屏幕上哪个位置”。
这里有两种流派。第一种是把整张截图切分成网格，让模型输出目标所在网格的坐标。简单直接，但精度受网格密度限制，小按钮经常点不准。第二种是让模型输出目标元素在屏幕上的相对坐标或边界框（bounding box），配合视觉 grounding 模型来做精确定位。我最终采用的是第二种，因为实际跑起来，只靠网格粗定位，点击率很难看，而框级别输出结合热力图，能做像素级的点击点确定。
动作规划层面，我会把一次复杂的任务拆成多步决策。模型每一步只做一次动作，这个动作可能是“点击某个位置”“输入一段文字”“滚动屏幕”或“按下某个键”，然后我再截图给模型看执行后的效果，让它决定下一步。这种“一步一停”的模式虽然慢一点，但可控性会好很多。我还构造了一套结构化的动作指令格式，让模型输出类似 JSON 的动作消息——包含动作类型、目标描述、坐标或参数，这样程序解析起来非常省心。
2.3 第三步：执行与反馈闭环
有了动作指令，下一步就是执行。这一步看起来最机械，但实际上最容易出问题。你让 AI 点了“下一步”，执行完毕后马上截图，结果界面还在加载，或者弹窗还没完全显示出来，模型就会误判当前状态。
所以执行后的反馈环节得加一个“稳定判断”机制。我通常的做法是连续截两次图，对比两帧之间的差异，如果画面还在明显变化，就说明界面还在渲染，需要再等一会儿。这个逻辑很像人类操作时等网页刷新的过程，只不过机器更需要显式的等待逻辑。等画面稳定下来，再重新进入“感知-规划-执行”的循环，这就构成了一个完整的闭环。
这个闭环是整个 CUA 系统的命脉。闭环越稳健，系统在复杂场景下的存活率就越高。反过来说，如果每一轮都跳步，AI 很容易在真实软件环境里迷失方向。
3. 我的实践方案：基于开源模型搭一套可用的 CUA
3.1 技术选型：为什么最终选了视觉理解加GUI grounding的组合
搭这个项目之前，我先把市面上的方案扫了一遍。闭源 API 方案，比如部分厂商提供的 computer use 能力，效果确实好，但有几个绕不开的问题：一是按调用量计费，一个多步任务要调几十上百次模型接口，成本相当可观；二是数据隐私，我是要操作内部系统，屏幕截图频繁发给外部 API，合规上不放心；三是延迟，每轮决策多一次网络往返，用户体验会打折扣。
所以我的路线选了开源模型来跑。具体的组合是——用一个小尺寸的视觉语言模型做界面理解和动作生成，再配套一个 GUI grounding 模型负责把目标描述转成屏幕上的坐标。这样整个链路完全本地化部署，成本可控，延迟也更低。整体实测下来，在不追求极端画质的情况下，识别准确率能达到能用的水平。
如果你也想复刻这套方案，关键并不在于选哪个具体模型，而在于理解“视觉理解”和“坐标定位”这两个环节的微妙关系。视觉理解回答“这是什么”，grounding 模型回答“这个东西在哪”，两者配合，缺一不可。
3.2 工作流设计与关键参数
整个工作流可以用下面几条规则来概括：
- 每一次模型调用只得出一个动作，不贪多。
- 每次执行完动作，必须重新截图确认状态，不盲目相信上一次的判断。
- 动作类型保持在有限集合内，点击、输入、滚动、按键、等待、结束，覆盖面足够。
- 设置最大步数上限，防止任务失控死循环。
- 所有动作记录进入日志，方便事后回顾和回溯排查。
这里面最关键的参数是“最大步数上限”和“等待稳定判定时间”。步数上限设得太小，复杂任务会被中途掐断；设得太大，模型一旦绕圈子，资源消耗就很夸张。我一般按任务复杂度估算基准步数，再乘上 1.5 到 2 的安全系数。等待时间就更有讲究了，太短会误判界面未加载完，太长又拖慢整体速度，一个比较舒服的起步值是单帧稳定判断 500 毫秒。
3.3 一个最小可运行的实现示例
下面这张精简版架构图描述了我的核心循环，虽然不涉及具体代码实现，但足够说明整体逻辑：
┌──────────┐ 截图 ┌──────────────┐ 结构化动作 ┌──────────────┐ │ 屏幕/窗口 │ ──────> │ 视觉理解+grounding │ ──────────> │ 动作执行器(鼠标键盘) │ └──────────┘ └──────────────┘ └──────────────┘ ^ │ └────────────── 重新截屏确认状态 <──────────────────┘如果你只是想快速验证可行性，有一个非常朴素的办法：用现成的视觉语言模型服务，加上 pyautogui 这类库做鼠标键盘控制。代码逻辑大概长这样：
import pyautogui import time from PIL import ImageGrab # 截图 def take_screenshot(): img = ImageGrab.grab(bbox=(0, 0, 1920, 1080)) img.save("screen.png") return "screen.png" # 模拟人眼：读取屏幕，交给模型，让模型返回动作描述 def model_decision(screenshot_path, task): # 这里是模型调用环节，把截图和任务描述发给模型 # 模型返回类似：{"action": "click", "target": "搜索框", "coordinate": [860, 240]} return {"action": "click", "target": "搜索框", "coordinate": [860, 240]} # 模拟人手：执行模型给出的动作 def execute_action(action): if action["action"] == "click": x, y = action["coordinate"] pyautogui.click(x, y) time.sleep(0.5) elif action["action"] == "type": pyautogui.typewrite(action["text"], interval=0.05) # 其他动作类似 # 主循环：一个任务循环执行，直到模型输出结束标志或步数超限 def run_task(task, max_steps=20): for step in range(max_steps): screenshot_path = take_screenshot() action = model_decision(screenshot_path, task) if action["action"] == "finish": print("任务完成") break execute_action(action)这个版本虽然简陋，但已经具备了 CUA 的基本骨架——截图、决策、执行、再截图。如果你想在真实业务里用，还需要在这个基础上加上窗口管理、稳定性判断、错误恢复等机制，整体架构会复杂一个量级，但核心原理就是这个循环。
4. 实操过程记录：让它“自己”把任务跑完
4.1 场景：给定网址，自动完成信息收集
为了验证这套方案是不是真的能干活，我设计了一个相对完整的测试任务：让智能体打开浏览器，访问一个给定的信息页面，在里面找到某个表格，提取出所有价格数据，并汇总成一份文本报告。
这个任务看起来简单，但拆解下来需要模型具备几项能力：能够识别浏览器的地址栏并输入网址，能够识别页面上的表格结构，能够滚动页面查看表格下方被折叠的数据，最后把内容整理输出。任何一个环节出错，整个任务都会失败。
我先手动跑了一遍，记录下正常操作大概需要 12 步。然后在配置里把最大步数设成 25，给它 2 倍的冗余空间。初始任务描述写得很短，只说“打开浏览器，访问这个网址，找到价格表，提取所有价格，整理成报告”，没有额外提示。第一次运行结果在意料之中——模型在识别表格某一列时，把表头当成了数据，导致输出数字出现错位。
4.2 关键节点的调试记录
第一次跑失败之后，我没有急着调模型，而是先把失败时的截图日志翻了一遍。发现模型在读取表格内容时，因为表格列比较多，压缩后的图像里部分文字已经模糊成一团，模型开始靠“猜”来补全内容。
针对这个问题，我做了两步调整。第一步，在截图给模型之前先做局部放大，把目标区域裁剪出来，再送进模型，相当于让 AI “凑近看”；第二步，在提示词里增加一条强制规则：如果界面文字看不清，必须滚动页面放大或调整缩放比例后再尝试，不允许直接猜测。这个改动跑下来，表格数据读取准确率立刻提升了一大截。
另外一个常见坑是模型在页面动作完成之后，没有等页面跳转就急着做下一步操作。页面加载中的白屏被截进图里，模型以为页面就是空白的，于是开始发起无意义的查找操作。后来我加了前面提到的稳定判断逻辑，这个问题也基本绝迹。
4.3 运行效率与成本实测
跑通之后，我对整套系统做了个粗测。一个包含 20 步操作的任务，纯模型推理时间大约 40 到 60 秒，加上每步之间的等待稳定时间和动作执行时间，总耗时在 90 秒左右。对比人手工操作，需要 30 秒左右，AI 目前是慢一点的，但它的优势在于可以同时开多个实例，并行处理多个任务。
成本方面，纯本地推理时主要开销是显卡电费和模型推理占用的显存。如果是调用云 API，一个 20 步的任务大概消耗 15 万到 25 万 token，按市场价估算一次任务成本在几毛到几块不等。这个量级对外包服务或批量处理场景来说是可以接受的。我目前的建议是，如果你只是自己试用，用云 API 最省事；如果要长期跑批，还是得考虑本地部署。
5. 常见问题与避坑指南
5.1 坐标偏移：DPI缩放与多显示器
这是整个项目里最让人头疼的问题，没有之一。Windows 系统默认的 DPI 缩放、显示器的缩放比例、多显示器不同分辨率，都会导致同一个元素在不同机器上呈现不同的像素位置。模型给出的坐标是截图内容里的坐标，而 pyautogui 操作的是实际屏幕坐标，两者一旦没对齐，点击就会偏。
我的解决办法是统一截图坐标空间。截图之前先获取当前屏幕的缩放比例，把所有坐标换算成逻辑坐标再执行。多显示器环境下，还需要明确智能体的操作范围，否则它可能把目标应用在其他屏幕上，而截图只截了主屏幕，导致模型“看不见”目标窗口，陷入疑惑循环。这个问题没有银弹，只能靠环境初始化时检测参数，并在系统运行日志里显式打印出这些坐标参数，方便排查。
5.2 页面未加载完成就操作
这个在网页场景里特别常见。模型的判断依据是截图内容，但页面加载是异步的，很多时候表格区域还是空白，或者按钮还没变成可点击状态，模型就已经输出了点击动作。点击之后，页面上自然什么都没发生，模型会感到困惑，进而重复操作或者误判。
除了前面提到的两帧对比稳定判断法，我还有一个技巧：在提示词里加一条“如果动作执行后截图内容没有变化，不要重复执行相同动作，优先等待或尝试其他可行方案”。这条规则能显著降低模型在页面加载过渡期的无效操作次数。另外，对于一些加载时间长的页面，还可以在动作执行器里加入针对特定界面的等待逻辑，比如检测到加载动画图标时强制等待。
5.3 模型陷入死循环
模型在某个步骤上重复执行相同或类似的动作，是第二个常见问题。这通常会出现在界面状态没有按预期变化时，模型不知道怎么往下走，就开始机械重复。最烦的是，有时候它会换个坐标反复点击同一个位置，看似在“尝试”，实际毫无进展。
要遏制这个问题，一是靠最大步数上限强行掐断，二是给模型注入“短期记忆”——把最近 5 步的动作历史一起提供给模型，让它参考“我之前已经试过点击左上角按钮但没反应，所以这次不能重复”。有了这个“记忆”之后，模型跳出死循环的概率会高很多。更加复杂一点的方案，是引入一个独立的巡检器，专门检测连续重复动作，如果识别到重复模式，自动打断并给模型发送提示。
5.4 安全与权限控制
这一点我想特别强调。CUA 意味着 AI 有了操作电脑的权限，它可以直接改动文件、发送消息、删除数据。一旦提示词构造不当，或者模型出现误判，后果可能比普通的代码 bug 严重得多。
我的做法是，在系统设计上限定智能体只能操作指定目录下的文件，不允许访问系统关键设置区域，涉及删除、覆盖等高风险操作时，必须执行二次确认。同时，所有动作记录都保留完整日志，并支持按时间回放，方便定位是哪一步出了问题。
我在实际使用中还有一个体会：CUA 真正适合的场景，是那些规则清晰、操作重复、但又不值得写死脚本的“中间地带”。比如整理多来源报表、批量处理文档格式、在老旧系统里录入数据——这些活让 RPA 写选择器太费劲、让 API 做又没接口，交给 CUA 刚刚好。它的扩展方向也很有想象空间，比如让智能体同时控制多个桌面环境做分布式处理，或者结合语音输入做成真正的“你说它做”。我目前这套虽然还有很多粗糙的地方，但至少证明了这条路是走得通的。后面我计划把它的操作范围再扩大一些，尝试接进更多日常软件，让 AI 真正成为我的“数字助手”。
