CUA计算机使用代理：从界面自动化到AI操作电脑的工程实践

1. 从“cua”这个标题说起：一个被低估的缩写背后藏着什么

第一次看到“cua”这个标题的时候，我脑子里蹦出来的第一反应是——这大概率又是一个圈内人才懂的缩写。做技术的人有个习惯，喜欢把长名字砍成三四个字母，方便在命令行里敲、在聊天里打、在文档里写。cua 就是这样一个典型的存在。它不是一个完整的单词，而是一个被压缩过的代号，背后指向的是一类非常具体的技术实践：计算机使用代理，也就是让 AI 像人一样去操作电脑界面，点击按钮、填写表单、切换窗口、完成一整套跨应用的流程。

这个方向最近一年热度涨得非常快。原因也不难理解：过去我们讲自动化，讲的是脚本、是 API、是 RPA 工具，但这些东西都有一个共同的软肋——它们依赖稳定的接口或者固定的界面结构。一旦目标系统改了个按钮位置、换了个弹窗样式，脚本就废了。而 cua 的思路完全不同，它不要求目标系统提供任何接口，也不依赖 DOM 结构或者控件 ID，它直接看屏幕、理解屏幕、操作屏幕。换句话说，它把“人怎么用电脑”这件事本身当成了接口。

我之所以对这个方向特别有感触，是因为过去大半年里我断断续续在几个内部项目上试过类似的东西。有的是为了把重复的报表整理流程自动化，有的是为了在多个后台系统之间做数据搬运，还有的是想看看能不能让 AI 帮忙处理一些零碎的桌面操作。踩过的坑不少，但跑通的场景也确实省下了大量人力。所以这篇内容我打算把 cua 这个方向从头到尾拆一遍：它到底解决什么问题、核心技术点在哪、实操的时候怎么搭、哪些地方最容易翻车、以及我实测下来比较稳的几种做法。

适合谁来读？如果你是做自动化的、做 AI 应用的、或者单纯被重复性电脑操作折磨得不行的人，这篇应该都能给你一些可以直接抄作业的东西。如果你完全没接触过这个方向，也没关系，我会尽量用生活化的类比把原理讲清楚，保证你能看懂它在干什么、为什么这么干。

2. cua 到底在解决什么问题：从“接口自动化”到“界面自动化”的范式转移

2.1 传统自动化的三条路，以及它们各自的死穴

要理解 cua 的价值，得先看清楚它替代的是什么。过去我们做自动化，基本上走的是三条路。

第一条路是API 自动化。这是最理想的情况，目标系统提供了 HTTP 接口或者 SDK，你直接调就行。稳定、快、可控。但现实是，大量内部系统、老旧软件、第三方后台根本不给你接口，或者接口要申请权限、要走审批、要付费。你拿不到，就只能干瞪眼。

第二条路是DOM/控件级自动化。网页用 Selenium、Playwright 去定位元素，桌面软件用 WinAppDriver、pywinauto 去抓控件。这条路比 API 灵活一些，但它的命门在于“结构必须稳定”。我印象特别深的一次，某个后台系统升级，把提交按钮从<button id="submit">改成了<div class="btn-primary">，整个脚本当场报废。更别提那些用 Canvas 画的界面、用 Flash 做的老系统，控件树里根本抓不到东西。

第三条路是坐标级自动化。就是记录鼠标点哪个位置、键盘敲什么，然后回放。这条路最原始，也最脆弱。换个分辨率、换个窗口位置、系统字体变一下，全乱套。它唯一的优势是不挑目标，什么都能点，但维护成本高得吓人。

这三条路的共同问题是：它们都在试图绕过“人看屏幕”这个环节，直接去操作底层结构。可现实世界里，大量系统的底层结构要么不开放，要么不稳定，要么根本不存在。这时候，cua 的思路就显得特别自然——既然人看着屏幕就能操作，那让 AI 也看着屏幕去操作不就行了？

2.2 cua 的核心逻辑：把“屏幕”当成唯一的接口

cua 的本质，是把计算机的图形界面当作一个可以被感知和操作的环境。它的工作循环非常像人：看屏幕 → 理解当前状态 → 决定下一步动作 → 执行动作 → 再看屏幕。这个循环不断重复，直到任务完成。

拆开来看，它包含四个核心能力。第一是屏幕感知，也就是截图或者录屏，把当前界面变成一张图像。第二是界面理解，用视觉模型或者多模态模型去识别图里有什么——按钮在哪、输入框在哪、当前在哪个页面、有没有弹窗。第三是动作决策，根据任务目标和当前界面状态，决定下一步该点哪里、输入什么、还是滚动。第四是动作执行，通过系统级的输入模拟，把点击、输入、拖拽这些动作真实地作用到界面上。

这个逻辑听起来简单，但它的意义非常大。因为它意味着：只要人能用鼠标键盘操作的东西，cua 理论上都能操作。不需要接口，不需要控件树，不需要目标系统配合。这对那些“没有 API 的老系统”“结构混乱的内部后台”“需要跨多个软件协作的流程”来说，几乎是唯一的自动化出路。

2.3 为什么是现在：三个条件同时成熟了

cua 这个概念其实不新，早几年就有人尝试过用图像识别做界面自动化。但那时候效果很差，原因很简单：视觉模型不够强，看不懂复杂界面；决策逻辑太死，遇到没见过的状态就卡住；执行环节不稳定，点偏一点就失败。

现在情况变了。多模态模型的能力上来了，它能比较准确地理解一张界面截图里各个元素的功能和关系，甚至能读懂按钮上的文字、表单的标签、弹窗的提示。推理和规划能力也上来了，模型可以根据任务目标拆解步骤，遇到意外状态时还能调整策略。系统级输入模拟的工具链也成熟了，不管是桌面端还是浏览器端，都有比较稳定的方案去执行点击和输入。

这三个条件凑齐，cua 才真正从“玩具”变成了“能干活的工具”。我自己的体感是，一年前做类似的东西，成功率可能只有三四成，现在在受控环境下能做到七八成甚至更高，剩下的失败主要来自一些边界情况和界面本身的歧义。

3. 核心技术点拆解：cua 的四个关键环节

3.1 屏幕感知：截图这件事比你想的讲究

屏幕感知听起来就是截个图，但实操里细节很多。首先是截图频率。截太快，浪费算力，而且相邻帧几乎一样，没有信息增量；截太慢，动作执行完了界面还没更新，模型会基于旧状态做决策，直接跑偏。我的经验是，在动作执行后留一个短暂的等待，等界面稳定下来再截下一帧，这个等待时间根据目标系统的响应速度来调，一般几百毫秒到一两秒不等。

其次是截图范围。全屏截图信息量大，但噪声也多，模型容易被无关区域干扰。有些实现会只截当前活动窗口，或者只截感兴趣的区域。我试过全屏和窗口两种，实测下来，如果任务集中在单个应用内，截窗口更稳；如果任务需要跨应用切换，那还是得全屏，否则模型看不到任务栏和切换动作。

还有一个容易被忽略的点是分辨率。截图分辨率太高，模型处理慢，而且很多视觉模型会把图缩放到固定尺寸，细节反而丢了；分辨率太低，小按钮、小字看不清，模型识别不准。我一般会把截图控制在 1080p 到 1440p 之间，既能看清细节，又不至于太慢。如果目标界面字体特别小，我会单独把关键区域放大后再送给模型。

提示：截图前最好确认目标窗口处于激活状态，并且没有被其他窗口遮挡。我踩过一次坑，模型对着一个被弹窗盖住的界面做决策，结果点了个寂寞。

3.2 界面理解：让模型“看懂”屏幕上的东西

界面理解是 cua 里最核心也最难的一环。它的目标是把一张图像变成结构化的信息：有哪些可交互元素、它们分别是什么、当前界面处于什么状态。

常见的做法有两种。一种是纯视觉理解，直接把截图丢给多模态模型，让它输出元素的位置和功能描述。这种做法的好处是不依赖任何底层信息，通用性强；坏处是模型可能会看错、看漏，尤其是界面元素密集的时候。

另一种是视觉加辅助信息。比如在浏览器场景里，可以同时拿到 DOM 树，把 DOM 信息和截图对齐，帮助模型更准确地定位元素。在桌面场景里，可以拿到控件树或者无障碍信息作为补充。这种做法准确率更高，但实现复杂度也更高，而且不是所有目标都提供这些辅助信息。

我自己的做法是分场景。如果是浏览器内的任务，我会尽量用上 DOM 辅助，因为浏览器天然提供这些信息，成本低收益高。如果是桌面软件，尤其是那些老系统，我就纯靠视觉，但会在提示词里给模型更明确的指令，比如“只关注窗口中央的表单区域”“忽略顶部的菜单栏”。

这里有个实操心得：给模型的指令要具体到动作层面，而不是目标层面。比如说“点击登录按钮”就比“完成登录”要好，因为前者直接对应一个可执行动作，后者还需要模型自己去拆解。当然，如果任务本身就需要多步规划，那还是得给目标，但可以在提示里补充“先找到登录入口，再输入账号密码，最后点击提交”这样的步骤引导。

3.3 动作决策：从“看懂”到“知道该干什么”

看懂了界面，下一步是决定做什么。这一步的难点在于：同一个任务，在不同界面状态下，下一步动作可能完全不同。比如你要提交一个表单，如果表单还没填，你得先填；如果填好了，你得点提交；如果弹出了验证码，你得先处理验证码；如果提示错误，你得回去改。模型需要根据当前状态动态决策。

我的做法是把决策逻辑分成两层。上层是任务规划，把大任务拆成有序的子步骤，比如“打开系统 → 进入订单页 → 筛选今日订单 → 导出报表”。下层是动作选择，在每个子步骤内，根据当前界面决定具体动作。上层可以用比较强的模型来做，因为它只需要做一次；下层可以用轻量一些的模型，因为它要频繁调用，对速度要求高。

这里有个坑我踩过好几次：模型有时候会“想太多”。明明界面上就一个明显的按钮，它非要分析半天，或者给出一个很复杂的动作序列。后来我在提示词里加了一句“如果当前界面有明确的主操作按钮，优先执行该操作”，情况就好很多。另外，动作要原子化，一次只做一个动作，点完再看，不要一次性规划一串动作然后批量执行，因为界面随时可能变。

3.4 动作执行：点得准、输得对、不跑偏

动作执行是把决策变成现实的一步。常见的手段包括模拟鼠标移动和点击、模拟键盘输入、模拟滚动和拖拽。技术上有系统级 API 调用，也有通过驱动层注入的方式。

这一步最关键的是坐标映射。模型给出的坐标是基于它看到的截图的，而截图可能经过了缩放，实际屏幕坐标和截图坐标之间需要一个换算。如果这个换算错了，点击就会偏。我的做法是固定截图尺寸和屏幕尺寸的比例关系，在代码里做一次显式的换算，并且在实际点击前做一次校验，比如点击后截图确认界面确实发生了变化。

另一个关键是输入法问题。模拟键盘输入的时候，如果目标输入框对输入法有依赖，直接注入字符可能会失败。我遇到过中文输入框必须走输入法才能输入的情况，后来改成先点击输入框激活，再用剪贴板粘贴的方式，稳定很多。当然，剪贴板方式也有风险，比如会覆盖用户剪贴板内容，所以我会在操作前后做保存和恢复。

注意：动作执行后一定要留出足够的等待时间，并且做一次状态确认。我见过太多因为“点完立刻截下一帧，界面还没刷新”导致的误判。

4. 实操搭建：一个可跑的 cua 最小系统

4.1 整体架构与工具选型

要搭一个能跑的 cua 系统，不需要太复杂的架构。核心就四块：截图模块、理解与决策模块、执行模块、循环控制模块。我用 Python 做过一版，整体不到几百行，跑起来效果还不错。

工具选型上，截图我用的是系统自带的截屏能力，跨平台的话可以用一些通用的图像库。理解与决策我接的是多模态模型，具体用哪个看你的预算和延迟要求，强的模型准但慢，轻的模型快但容易出错，我一般会在关键决策点用强模型，常规动作选择用轻模型。执行我用的是系统级的输入模拟库，鼠标键盘都能覆盖。循环控制就是写个 while，直到任务完成或者达到最大步数。

这里要强调一点：不要一上来就追求全自动。我建议先做“半自动”，也就是模型给建议，人来确认执行。跑一段时间，积累一些成功和失败的案例，再逐步放开。这样既能快速验证可行性，又能避免全自动跑飞了造成不可逆的后果。

4.2 关键代码结构：循环、截图、决策、执行

下面是我用的一个简化版结构，核心逻辑都在这个循环里。

import time from screenshot import capture_screen from executor import click, type_text, scroll from agent import decide_next_action MAX_STEPS = 50 STEP_INTERVAL = 1.0 def run_task(task_description): history = [] for step in range(MAX_STEPS): screen = capture_screen() action = decide_next_action( task=task_description, screen=screen, history=history ) if action["type"] == "done": return True if action["type"] == "click": click(action["x"], action["y"]) elif action["type"] == "type": type_text(action["text"]) elif action["type"] == "scroll": scroll(action["direction"], action["amount"]) history.append(action) time.sleep(STEP_INTERVAL) return False

这段代码看起来简单，但有几个细节值得说。history 的作用是给模型提供上下文，让它知道之前做过什么，避免重复动作或者陷入死循环。STEP_INTERVAL 是动作后的等待时间，这个值要根据目标系统的响应速度调，太快容易误判，太慢效率低。MAX_STEPS 是安全阀，防止模型卡在某个状态里无限循环。

4.3 提示词设计：怎么让模型稳定输出可执行动作

提示词是 cua 系统里最容易被低估的部分。模型再强，提示词写得烂，输出也会乱七八糟。我的经验是，提示词要包含四块内容：任务描述、当前截图、历史动作、输出格式约束。

任务描述要具体，比如“在当前页面找到搜索框，输入订单号 12345，点击搜索按钮”。当前截图直接给图像。历史动作用简洁的文本列出，比如“已点击搜索框，已输入订单号”。输出格式约束最关键，我会明确要求模型输出 JSON，包含 action 类型和参数，并且给出几个示例。

{ "type": "click", "x": 320, "y": 480, "reason": "搜索按钮位于表单右下角" }

要求模型给出 reason 字段，一方面能帮助排查问题，另一方面也能让模型“想清楚再动手”，实测下来准确率会高一些。另外，我会在提示词里加一句“如果当前界面没有可执行的相关操作，输出 type 为 wait 或 done”，避免模型硬编一个动作出来。

4.4 实测记录：一个报表导出任务的完整跑通过程

我拿一个内部报表系统做过完整测试。任务是：登录系统 → 进入报表页 → 选择日期范围 → 导出 Excel。这个系统没有 API，界面是老式的表格布局，按钮很小，而且导出后会弹一个下载确认框。

第一次跑，卡在登录环节。模型把用户名输入框识别成了搜索框，输错了地方。后来我在提示词里补充了“登录页面的输入框通常成对出现，第一个是用户名，第二个是密码”，问题解决。

第二次跑，卡在日期选择。那个日期控件是个日历弹窗，模型看不懂日历结构，点错了月份。我改成让模型先点开日历，然后根据当前显示的月份和年份，计算目标日期需要点几次“下个月”，再点具体日期。这个逻辑我写在了提示词里，模型照着做就稳了。

第三次跑，导出成功，但下载确认框没处理。模型看到弹窗后愣住了，不知道该点“保存”还是“取消”。我在提示词里加了“遇到下载确认框，默认点击保存或确认按钮”，之后就跑通了。

整个任务跑下来大概用了二十多步，耗时一分多钟。比起人工操作，速度上没有明显优势，但胜在可以无人值守、可以批量跑。我后来把这个流程挂到定时任务上，每天早上自动跑一遍，省下了不少重复劳动。

5. 常见问题与排查技巧实录

5.1 模型看错元素：定位偏移与误识别

这是最常见的问题。表现是模型说要点某个按钮，结果点到了旁边。原因通常有三个：截图缩放导致坐标换算错误、界面元素太密集模型分不清、或者模型对某个元素的功能判断错了。

排查的时候，我会先把模型看到的截图和它输出的坐标画个标记，看看它到底想点哪里。如果是坐标换算问题，修正换算逻辑就行。如果是元素密集，我会在提示词里让模型先描述目标元素的特征，比如“蓝色背景、白色文字、位于表单底部”，再给坐标，这样能逼它更仔细地看。如果是功能判断错，那通常是提示词不够明确，补充一些领域知识就能改善。

5.2 动作执行了但界面没反应

有时候模型点了按钮，但界面毫无变化。这种情况我遇到过几种原因。一是点击坐标虽然对，但目标元素需要先获得焦点才能响应，解决办法是先点一下空白处再点目标。二是目标元素被透明层遮挡，视觉上看得到但点不到，这种只能靠调整点击位置或者用键盘操作绕过。三是系统响应慢，点击其实生效了，只是截图截早了，解决办法是加长等待时间或者做轮询确认。

5.3 陷入死循环：模型反复做同一个动作

模型有时候会卡在一个状态里，反复点同一个按钮或者反复输入同样的内容。根本原因是它没有意识到这个动作已经做过了，或者它以为没生效。解决办法是在提示词里把历史动作列清楚，并且明确告诉模型“如果某个动作已经执行过且界面没有变化，尝试其他方式”。另外，循环控制里加一个检测，如果连续几步动作相同且截图相似，就强制中断或者换策略。

5.4 弹窗、验证码、意外状态的处理

弹窗和验证码是 cua 系统的大敌。弹窗还好，只要模型能识别出来，一般能处理。验证码就麻烦了，尤其是图形验证码，模型不一定认得出来。我的做法是，遇到验证码就暂停任务，发通知让人来处理，处理完再继续。这样虽然不够全自动，但至少不会卡死。意外状态比如网络错误页、系统维护提示，也是类似处理，先识别出来，再决定是重试还是暂停。

5.5 常见问题速查表

提示：这张表我建议打印出来贴在工位上，出问题的时候对着查，比从头调试快得多。

6. 影响范围与适用边界：cua 能干什么、不能干什么

6.1 最适合 cua 的三类场景

第一类是无接口的老旧系统操作。很多内部系统年久失修，没有 API，界面也老旧，但业务上又离不开。cua 几乎是唯一能自动化的方案。

第二类是跨应用的流程串联。比如从邮件里拿附件，打开本地软件处理，再上传到某个后台。这种跨应用的任务，传统自动化很难做，因为每个应用的技术栈都不一样。cua 统一用界面操作，反而简单。

第三类是低频但繁琐的重复操作。有些任务一个月才做一次，写脚本不划算，但每次做都很烦。cua 可以快速配置，用完就扔，成本很低。

6.2 不适合 cua 的情况

反过来，有些场景不适合用 cua。高频、大批量的任务，比如每秒要处理几百条请求，cua 的速度跟不上，还是得走 API。对准确性要求极高的任务，比如金融交易，cua 的失败率还是偏高，不适合直接上生产。界面变化极其频繁的任务，如果目标系统天天改版，cua 的维护成本会很高。

我的建议是，把 cua 当成一个“兜底方案”。有 API 的优先用 API，有稳定控件的优先用控件自动化，实在没辙了再用 cua。它不是要取代传统自动化，而是补上传统自动化覆盖不到的那块空白。

6.3 安全与合规的边界

用 cua 操作真实系统，有几个边界必须守住。不要用它去操作涉及敏感数据的系统，除非你有明确的授权和完整的审计。不要用它做批量注册、刷量之类的事情，这既不合规也容易出事。操作前要做好备份和回滚方案，尤其是涉及数据修改的任务，一旦跑飞了要能恢复。

我自己的原则是：cua 只用在内部、受控、可回滚的场景。对外部系统、生产系统、不可逆操作，一律先人工确认再执行。这个原则帮我避免了好几次潜在的事故。

7. 我踩过的坑与实测有效的几条经验

7.1 不要追求一步到位的全自动

这是我最大的教训。一开始我想做一个完全无人值守的系统，结果各种边界情况处理不过来，跑十次能成功三次就不错了。后来改成半自动，模型给建议、人点确认，成功率立刻上去了。再后来，我把那些已经稳定跑通的步骤逐步放开，最终才做到大部分自动、少数关键点人工介入。这个渐进的过程比一步到位靠谱得多。

7.2 截图质量和等待时间决定成败

很多人把精力花在模型选型上，却忽略了截图和等待这两个最基础的环节。我的实测是，把截图分辨率调对、把动作后的等待时间调够，成功率能提升一大截。这两个参数没有万能值，得根据目标系统和任务特点去调。我的做法是先用保守值跑通，再逐步压缩时间、提高效率。

7.3 提示词要像写给新人看的操作手册

提示词不是越短越好，而是要像写给一个刚入职的新人看的操作手册。告诉他任务是什么、当前界面长什么样、之前做过什么、遇到什么情况该怎么处理。我试过把提示词写得非常详细，模型的表现明显比简短提示词好。当然，太长了也会超出上下文限制，所以要抓重点，把最关键的约束和领域知识写进去。

7.4 做好日志和回放，方便复盘

cua 系统一定要有完整的日志：每一步的截图、模型的输出、执行的动作、执行后的状态。这样出问题的时候可以回放整个流程，快速定位是哪一步出的错。我一开始没做日志，出了问题只能靠猜，效率极低。后来加了日志，排查时间从半小时缩短到几分钟。

7.5 给任务设一个“放弃”机制

不是所有任务都能跑通，有些界面就是模型搞不定的。这时候要有一个放弃机制，比如达到最大步数、连续失败次数超限、或者检测到特定状态，就自动停止并通知人。硬撑下去只会浪费时间，还可能造成误操作。我一般会把最大步数设在正常步数的两到三倍，超过就停。

8. 后续可以怎么扩展

跑通基础版本之后，有几个方向可以继续深挖。一个是多模态模型的本地化部署，把延迟和成本降下来，适合高频场景。一个是动作库的积累，把常见操作封装成可复用的技能，减少模型每次都要重新决策的负担。还有一个是与现有 RPA 工具的融合，用 cua 处理那些 RPA 搞不定的界面，用 RPA 处理稳定的流程，各取所长。

我自己接下来想试的是把 cua 和语音控制结合起来，做一个“说一句话就能完成一串电脑操作”的东西。这个方向听起来有点远，但以现在的模型能力，我觉得是有机会跑通的。等有进展了再回来分享。

最后分享一个小技巧：如果你刚开始接触 cua，别急着搭系统，先拿一个最简单的任务练手，比如“打开记事本，输入一段文字，保存”。把这个跑通了，再逐步加复杂度。这个过程能帮你快速理解每个环节的坑在哪，比一上来就啃硬骨头高效得多。