最近我所在的好几个技术交流群里有人冷不丁甩出一个词“cua”。第一次看到时我以为又是哪个圈子的新梗结果翻了两屏讨论才发现大家聊的是 Computer Use Agent——一种让大模型像人一样看着屏幕、进行判断、再操作鼠标键盘的智能体。这个方向最近热度涨得很快但网上讨论大多停留在“AI 能自己操作电脑了”的震惊层面很少有人讲清楚它到底怎么落地会遇到哪些问题。我自己把一个最小可用的 CUA 流程跑通后踩了不少文档里根本不写的坑。这篇文章就把整个链路拆开从概念、架构、代码到生产环境必须考虑的稳定性、权限和审计问题一条一条说清楚。1. “cua”到底是什么从一句黑话到 AI 操作电脑的新范式1.1 一句“黑话”背后的完整技术链条在不同圈子“cua”可能有不同含义但在 AI 应用圈它基本指 Computer Use Agent中文可以理解为“计算机使用智能体”。它做的事情听起来很朴素把鼠标移动到某个位置、点击按钮、输入文字、滚动页面、切换窗口像人类员工一样操作桌面软件或者网页系统。我记得第一次听到这个概念时下意识觉得这不就是 RPA 换个马甲吗后来深入一看差别非常大。RPA 的核心是“脚本 控件定位”需要你告诉它按钮的坐标、窗口的标题、元素的 ID而 CUA 的核心是“视觉理解 自主决策”模型直接看屏幕截图自己判断现在是什么状态、下一步该做什么。它的工作链路可以拆成四步感知、决策、执行、校验。感知层负责截图或者读取界面信息决策层由多模态大模型完成它把截图和用户目标放在一起推理输出“我看到了什么应该做什么动作”执行层把模型输出的动作转成真实的鼠标键盘操作校验层在动作完成后再次截图判断刚才的操作是否生效。这个循环会一直重复直到任务完成。1.2 和 RPA、浏览器插件自动化有什么本质区别为了不让自己把概念搞混我做了一张对比表平时团队内部讨论也一直用这个框架维度传统 RPACUA交互方式控件 ID、选择器、固定坐标屏幕截图、视觉理解环境适应性界面一变脚本基本就要改允许一定的视觉变化开发成本每个流程都要单独写脚本用自然语言描述目标稳定性成功率高但非常脆弱有幻觉风险需要校验机制适用任务重复、规则明确的流程开放、跨应用、需要判断的流程用生活化的类比来说RPA 像一位只照着剧本演戏的演员剧本里写了“第 3 行第 5 列按钮亮起时点击”那它就只认这个位置CUA 更像刚入职的新员工虽然不熟悉系统但会看、会猜、会试你告诉它“帮我把上个月的数据导出来”它能根据界面上的文字和图标自己找入口。这个区别也决定了它们的适用场景完全不同。RPA 适合流程极其稳定、每天跑几百次的场景比如银行对账、ERP 数据录入CUA 适合那些流程非标准化、界面经常调整、甚至历史遗留系统里找不到控件的场景。很多老企业的核心业务系统是上世纪开发的没有 API也没有现代 UI 自动化接口传统方案根本无从下手但 CUA 只需要一张截图。2. 搭一个能跑的最小 CUA选型、架构与第一个 Demo2.1 基础架构感知-决策-执行-校验的闭环我先声明一下我搭的是真正“最小可跑通”的版本不追求工程上的完美目的是验证这条路能不能走通。整体架构只有 4 个模块截图模块定时或按需截取当前屏幕保存为图片感知模块把图片交给多模态模型让模型描述界面内容决策模块结合用户的目标让模型输出下一步动作执行模块解析模型输出调用系统接口完成鼠标键盘操作。但只看这 4 个模块是不够的必须在执行后再加一步校验重新截图看界面是否发生了变化。这个闭环是所有稳定性的根基。2.2 我用的技术选型和理由技术栈上我选择了 Python 3.10 pyautogui 国内主流多模态大模型 API。截图我用了系统自带能力Windows 上可以用Pillow的ImageGrabmacOS 上直接调screencapture命令行工具。选 pyautogui 纯粹是因为它跨平台、API 简单几行代码就能移动鼠标、点击、输入文字。权限方面有两个地方特别容易忽略。macOS 上需要在“系统设置-隐私与安全性-辅助功能”里给 Python 进程授权否则鼠标和键盘操作会被系统直接拦截Windows 上如果使用虚拟桌面或者远程桌面环境要确认当前会话是交互式会话否则 pyautogui 操作的是不可见的会话完全无效。多模态模型的选型我没有过度纠结核心看三点截图理解能力、中文界面识别能力、坐标回归准确度。我用了一个比较笨但有效的测试方法把一张复杂的业务系统截图发给模型让它说出界面上的按钮名称和大致位置。如果模型总是把“查询”看成“搜索”或者对密集表格里的数字瞎编那这个模型就暂时不适合做 CUA 的底层。2.3 最小 Demo 的核心代码逻辑下面是我跑通的最小版本核心逻辑为了方便展示我做了精简。整个循环可以理解成截图 → 让模型看屏幕 → 模型给出动作 → 执行动作 → 重新截图验证。import pyautogui import json import time import requests from PIL import ImageGrab def take_screenshot(): # Windows 环境直接截取整个屏幕 img ImageGrab.grab() img.save(screen.png) return screen.png def ask_model(screenshot_path, user_goal, history): # 构造发送给多模态模型的 prompt prompt f 你是一个能操作电脑的智能体。请观察当前屏幕截图完成用户目标{user_goal}。 请只输出 JSON不要输出其他内容格式如下 {{ action: click | type | scroll | done, target: 你要操作的元素描述, coordinate: [x, y], reason: 为什么执行这个动作 }} # 这里用 requests 调用多模态 API具体参数按所选平台调整 resp requests.post( https://your-llm-api.example/v1/chat/completions, json{...}, # 传入截图像 base64 和 prompt timeout30 ) result resp.json() return json.loads(result[choices][0][message][content]) def execute_action(action): if action[action] click: x, y action[coordinate] pyautogui.click(x, y) elif action[action] type: pyautogui.write(action.get(text, )) elif action[action] scroll: pyautogui.scroll(-int(action.get(clicks, 3))) time.sleep(1) # 留出页面响应时间 def run_task(user_goal): history [] for step in range(20): # 最多执行 20 步防止死循环 screenshot take_screenshot() action ask_model(screenshot, user_goal, history) history.append({ step: step, screenshot: screenshot, action: action }) if action[action] done: print(任务完成) break execute_action(action) if __name__ __main__: run_task(打开记事本输入hello world)这段代码很粗糙但它能说明 CUA 的最小闭环长什么样。模型并不需要接入任何 API 就能“看懂”界面它只需要截图和用户目标就能逐步推进。但真实世界里20 步任务至少会有五六次失败需要重试所以后面我会重点聊稳定性问题。3. 稳定性才是真问题坐标漂移、幻觉和状态不同步的实测记录3.1 首个翻车现场分辨率不一致导致的坐标漂移我的第一个 CUA 流程是在开发机上跑的外接一台 2K 显示器分辨率 2560×1440系统缩放 125%。开发时一切正常模型输出的坐标基本都能点中目标。后来我把脚本放到笔记本上执行屏幕分辨率变成了 1920×1080同时系统缩放是 150%结果几乎所有点击都偏了。这就是经典的坐标漂移问题。模型看到的截图尺寸和实际屏幕物理像素不是一回事缩放比例一变同样的坐标就指到了别的位置。更麻烦的是在多显示器环境下Windows 坐标系统允许出现负值有的屏幕在左边有的在右边模型看到的是拼接后的截图输出坐标时很容易混乱。我最终的解决办法是统一坐标系把输入给模型的截图统一缩放到固定分辨率然后要求模型输出归一化坐标也就是 0 到 1 之间的比例值执行端再把归一化坐标映射回当前屏幕的实际像素。这样无论是 1080p 还是 2K无论是 100% 还是 150% 缩放逻辑都保持一致。这个改动虽然简单却让跨设备稳定性提升了非常多。3.2 模型“幻觉点击”它以为自己在点实际没有坐标问题只是表层真正的深层问题是模型的“幻觉”。有一次我在测试一个网页表格自动筛选流程页面加载比较慢表格数据还没渲染出来模型已经“看到”了上一轮截图残留的表头果断点击了“排序”按钮。结果是排序根本没生效后续动作也跟着全乱。更危险的一次是弹窗处理。模型在一个删除确认窗口前本应该点击“确认”但因为窗口加载动画还没结束截图里只有半个弹窗模型自作主张认为页面已经清空直接输出了“done”。如果不是我在校验阶段发现界面并没有变化这个任务就算“假完成”了。静止截图无法表达动态加载状态模型会自动脑补画面里没有的信息。这是 CUA 与人类操作最大的差别人会等页面加载完会看到转圈动画会感知到按钮灰掉的状态但模型只看一帧截图它天然缺少时间维度。3.3 一个可行的稳定性增强方案踩过这些坑之后我总结了一套稳定性增强方案实测下来效果很明显动作前校验截图后先让模型判断目标元素是否存在。如果不存在就只做观察不输出点击动作。动作后校验执行完动作后再次截图判断界面有没有发生预期变化。如果连续两次截图内容完全相同基本可以判定操作无效。坐标与描述双重约束模型不仅要输出坐标还要输出目标元素的文字描述。执行端先按描述做一次粗略的文本匹配再用坐标去点避免坐标漂移导致点错。归一化坐标模型直接输出像素坐标很容易受分辨率影响改成 0 到 1 的相对坐标后不同设备之间的迁移性会好很多。失败重试与旁路一个动作最多重试 3 次如果仍然失败不要继续硬试而是把错误信息返回给任务调度器由上一层决定是换策略还是人工介入。校验逻辑在代码上并不复杂核心就是多截一张图、多问一次模型。但它的价值怎么强调都不过分因为 CUA 的失败模式跟传统程序不一样传统程序要么成功要么抛异常而 CUA 会“假装成功”只有回读界面状态才能识破。4. 从 Demo 到生产任务拆解、权限管控与审计4.1 把大任务拆成小步骤比给模型更大的上下文更划算在 Demo 阶段我习惯把用户目标直接丢给模型让它自由发挥。但一到生产环境这种“一条提示词走天下”的方式很快就崩了。原因很简单大模型处理的上下文越长注意力就越分散越容易在中间步骤迷失而且每次调用要把前面的截图和动作历史都带上token 消耗巨大延迟也高到不可接受。我后来改成任务拆解模式。比如“生成季度对账单”不要直接丢给 CUA而是先用一个规划器把它拆成几个子任务打开对账系统、选择季度、导出原始数据、用办公软件打开文件、插入汇总页。每个子任务都是一个独立的 CUA 任务各自维护自己的截图和动作历史。这样做的另一个好处是可控。某个子任务失败了可以只重跑那一段不用从头再来。而且子任务的目标越具体模型越容易判断“完成”的边界。我建议一个 CUA 子任务的生命周期控制在 10 步以内超过 10 步还结束不了大概率是任务粒度太粗了。4.2 权限隔离CUA 不是“越权助手”如果你只是在本地玩给足权限问题不大。但一旦部署到生产环境CUA 的权限问题就非常严峻。它拥有真实的鼠标和键盘控制能力这相当于把一个能操作任何界面的员工放进了系统但它没有人类的判断力。我的建议是始终用最小权限账户运行 CUA。不要以管理员身份跑更不要在真实业务账号下直接操作。我在测试环境里专门准备了一个低权限用户这个用户只能访问测试系统无法读取生产数据库也不在管理员组里。另外一个实践是应用白名单。CUA 运行的工作站只允许安装并打开白名单内的应用其他程序一律封禁。同时对危险动作做“人工确认”机制当模型计划执行删除、发送消息、提交订单、转账这类不可逆操作时系统会暂停并弹窗给操作员由人工确认后才会继续。这个机制牺牲了一点自动化率但换来了基本的安全底线。4.3 审计日志给 AI 的每个动作留痕生产级 CUA 和 Demo 的另一个区别是审计。我见过很多团队只看“任务完成率”这个指标忽略了记录过程的重要性。实际上CUA 出错后的复盘几乎完全依赖日志。我的日志方案是给每一步动作都记录以下信息输入截图、模型输出的推理内容、实际执行的动作、动作后的结果截图、耗时、重试次数。所有日志统一保存到按日期命名的目录里方便回放。回放的时候我会把每一步的截图拼成视频看起来就像在回放一个远程操作录屏能非常直观地定位是哪一步出了问题。如果业务涉及敏感数据审计日志还需要考虑合规要求。比如操作了哪些文件、访问了哪些页面、是否有导出行为都要记录在案。不要等到出事了才去补日志那样不仅成本高而且往往已经拿不到原始数据了。5. 给想上手的人一份路线图和我的忠告5.1 三条学习路径按你自己的目标选CUA 这个方向还在快速演变不同背景的人切入方式完全不同我梳理了三类人群和对应的学习路径只想快速验证的人找一个已经提供 Computer Use 能力的多模态 API结合 pyautogui 搭一个最小闭环选一个你日常反复做的流程跑起来比如自动查快递、自动整理报表。你不需要深入模型训练重点是理解感知-决策-执行-校验这个循环。想做产品的人重点放在任务拆解引擎和状态管理上。产品层面真正难的不是让模型看懂某个按钮而是如何把一个复杂业务流程稳定地拆成若干可执行子任务并处理模型失败后的恢复逻辑。想做底层模型的人需要收集大量 GUI 操作轨迹数据做偏好数据集和微调。目前开源社区已经有不少屏幕操作轨迹数据可以基于视觉语言模型做指令微调让模型在特定软件上的操作准确率更高。5.2 评估一个 CUA 用什么指标别只看成功率很多人评估 CUA 时只问一句“成功率多少”这个指标太粗了。同样是“成功率 80%”一个任务可能 5 步完成另一个可能 50 步才完成中间经历了多少次瞎点消耗了多少 token完全不一样。我建议至少关注以下 4 个指标指标说明端到端任务成功率完整完成任务的占比是最基础的指标单步动作准确率所有动作中有效动作的占比反映模型的基础能力平均重试次数每个任务中平均每个动作被重试了多少次越高说明越不稳定单任务成本与延迟每次任务消耗的 token 数和总时长决定是否值得落地这 4 个指标要放在一起看。比如某个模型端到端成功率很高但平均重试次数也高说明它是靠“蒙对”的真实效率可能并不好。我建议每个人都在自己的业务场景里至少准备 20 个真实任务的测试集每周跑一次回归单独记录失败案例。5.3 几句掏心窝的忠告第一不要用真实账号、真实数据跑 CUA 实验。它操作的是真实界面一旦模型判断失误后果可能是删除数据、发出错误消息甚至修改生产配置。宁可多花半天搭测试环境也不要为了图省事直接上生产账号。第二不要追求“一步到位全自动”。我见过太多团队一开始就想着让 AI 独立处理整个流程最后卡在安全审核和异常处理上。先做“人机协同”模式AI 操作人在旁边监看保留人工确认节点跑通一个季度后再逐步放开自动化比例这条路反而更快。第三失败样本比成功样本值钱得多。我现在的习惯是每次跑完一轮实验都把失败截图按任务类型、错误阶段、失败原因三个维度归档。一个月后回看能清楚看到模型在哪些界面反复犯错这些样本也成了我自己微调和验证模型的基础。第四这个领域变化太快三个月前的结论可能已经过时。不要迷信某篇文章说“CUA 已经能干所有事”自己动手在不同的软件上多测几次比追着每个热点看都有用。我现在仍然会在每次模型版本更新后用同一批历史失败任务做回归。看着以前完全跑不通的流程一点点变稳定那种感觉比任何宣传话术都真实。CUA 远没到成熟的阶段但它确实已经能从一个玩具变成可用的生产力工具关键是你要理解它的能力边界并且愿意在稳定性和安全上多花点功夫。