最近半个月我至少有四位做SaaS的朋友问同一个问题那个能自己点鼠标的AI是怎么回事我能用它跑通我们家的业务流程吗他们说的东西就是前段时间被反复刷屏的CUAComputer-Using Agent。说老实话这个概念刚出来的时候我第一反应是这不就是套了层壳的RPA吗直到自己动手做了个Demo、又在一个内部项目里试了一轮才意识到这玩意儿和传统自动化在思路上根本是两码事。这篇文章就从我的视角从头理一遍CUA到底解决什么问题、系统架构长什么样、怎么用最小的成本搭一个能跑起来的Demo、以及实测中那些文档不会告诉你的坑。如果你正在做AI应用开发、自动化测试或者公司里有一堆没有API的旧系统等着提效这篇文章应该能帮你省下不少调研时间。我把话说在前头CUA不是万能药它有自己的适用边界但搞清楚边界在哪里恰恰是把它用好最关键的一步。1. CUA概念拆解AI从对话到动手的分水岭1.1 从ChatBot到CUA到底改变了什么CUA的全称是Computer-Using Agent说白了就是一个能像人一样操作电脑的AI智能体。它不看API文档不调后端接口而是用眼睛看屏幕、用大脑做判断、用手去点鼠标敲键盘。过去几年我们说的AI自动化绝大多数是下面这条路ChatBot你问它答输出文本能力停留在嘴上。Function Calling / Tool Use模型根据用户意图调用预先定义好的API函数能力从嘴上延伸到后台。CUA模型直接操作GUI点击、输入、滚动、拖拽能力覆盖到所有人类能在电脑上做的事。一个我经常用的类比以前的AI像你给物业打电话说麻烦叫师傅来修一下电闸CUA是AI自己带着工具箱上门看着墙上的配电箱亲手去扳那个开关。前者依赖物业的系统里有修电闸这个标准服务后者只需要AI看得懂配电箱长得什么样。这个差别在真实业务里非常大。你有多少系统是完全没有API的我见过不少公司核心业务跑在一套十年前的三方系统上供应商早就不维护了数据导出来靠人工操作流程靠肌肉记忆。这种场景下RPA的脚本写起来痛苦不堪页面一改版就报废因为传统RPA的核心是按固定的选择器找元素而CUA的核心是理解当前屏幕状态再动态决定下一步动作。1.2 为什么cua这个词在最近突然火了技术圈的热词很少是凭空冒出来的。CUA能被推到台前背后是三个技术里程碑在同时逼近临界点第一个是视觉大模型的进步。GPT-4V、Claude 3.5/3.7、Qwen2.5-VL这一代模型都能把一张截图里的像素信息抽象成按钮、输入框、文字、图标这些人类语义。要知道在2022年之前让AI看截图然后精确告诉我登录按钮在坐标(500, 380)这件事简直是天方夜谭。现在视觉模型的截图理解能力已经稳定到可以支撑实际生产。第二个是Agent工程化的成熟。推理、规划、工具调用、反思Reflection这些模式被沉淀成了稳定的Agent框架和最佳实践。CUA不是一个模型而是一套模型编排逻辑执行器的系统。工程上的成熟让这套系统的开发门槛从需要一个算法团队攻坚降到了一个熟悉Python的后端工程师就能搭起来。第三个是需求端的真实痛点。RPA十几年都没能完全解决的问题——长尾、变化、跨平台、无API——恰恰是CUA最适合的领域。大家发现与其针对每个系统写一套自动化脚本不如训练一个通用的操作员让AI自己适应各种界面。1.3 一个容易被误解的点CUA不是截图调大模型我见过太多人刚开始做CUA时以为它等于把屏幕截图发给大模型让模型返回一个坐标然后点一下。这个理解方向没错但离能稳定工作差了十万八千里。真实世界里的CUA是一个循环而且每一步都不是单一的模型调用我先不展开把这个循环放到下一章讲架构时一起说。这里你只需要记住一个核心观点CUA最大的价值不是它会点鼠标而是它能在点错之后自己发现并修正。这种闭环能力才是它和传统自动化的本质区别。2. CUA系统四层架构一份可落地的技术地图我在实际项目中把CUA系统拆成了四层感知层、决策层、执行层、记忆与反馈层。这个分层不是学术上的分类而是我在调试Bug时实实在在感受到的四个事故高发区。每一层单独看都不复杂但层与层之间的衔接才是真正容易出现鬼故事的地方。2.1 感知层AI是怎么看屏幕的感知层的任务只有一个把当前屏幕上的信息变成模型能理解的输入。目前主流有三种做法方案原理优点缺点纯视觉截屏后直接把图片喂给多模态模型通用性强什么软件都能用推理慢、坐标可能不准、token成本高结构化提取读取网页DOM、桌面应用的无障碍树Accessibility Tree信息精确、token成本低依赖应用对外开放这些数据混合方案先用结构化提取失败时回退到纯视觉兼顾通用性和精度实现复杂度高我自己在网页自动化里90%的场景用结构化提取DOM Accessibility Tree因为网页和很多桌面框架比如Electron应用、Windows的UIA都能拿到语义树比让模型去猜按钮位置可靠得多。但遇到远程桌面、云桌面、某些重绘的软件界面时拿不到语义树就只能切到纯视觉通道。这里有个关键的工程细节坐标对齐。结构化提取拿到的是DOM元素在页面里的逻辑位置而执行层做鼠标点击时用的是屏幕坐标两者之间隔着一个浏览器视口偏移和操作系统缩放比。Windows系统如果开了125%或150%的缩放坐标会整体漂移这是新人最容易踩的坑。我的做法是在做CUA之前先把整个链路截图→语义→点击通跑一遍用一个固定的1280x720无缩放的测试环境验证坐标再逐步放开环境限制。2.2 决策层决定下一步做什么的大脑决策层是整个CUA系统的核心也是和传统RPA差别最大的地方。RPA是流程图CUA是决策链。决策层要做的事有三件任务拆解Task Decomposition把整理这个月的销售报表拆成打开系统→进入报表模块→选择时间→点击导出→处理下载的文件这样的子步骤。这一步通常由大模型基于对任务的语义理解来完成。下一步动作预测Next Action Prediction拿到当前屏幕的观察结果后决定是点击这个按钮、在输入框填写内容、滚动页面还是结束任务。完成状态判断Task Completion Judgement怎么判断任务做完了是页面上出现了预期的结果还是已经执行了N个动作现在工业界主流的做法是让大模型每次只输出一个或几个动作而不是让它一次把整个计划都列出来。原因是长计划的准确率会随步骤数量指数级下降走一步看一步反而更稳。你可以把决策层理解成一个不断看路、不断纠偏的自动驾驶而不是设定好路线后一动不动地开到底。2.3 执行层把想法变成动作执行层负责把模型决策出的动作翻译成真实的GUI事件。网页自动化我优先用Playwright它比Selenium更现代自带等待机制事件模型也更好用桌面自动化则看操作系统网页Playwright / PuppeteerWindows桌面PyAutoGUI UI AutomationUIAmacOS桌面Accessibility API PyAutoGUI远程桌面/虚拟桌面图像识别 PyAutoGUI或者虚拟机内的Agent方案执行层最容易忽略的是动作的容错。比如模型决定点击输入框但页面上有多个输入框模型没指定是哪一个。这时候执行层需要有兜底策略先激活页面上最可能的输入框根据焦点状态判断如果没有焦点再解析坐标实在不行就重新截图让模型确认。我的原则是执行层永远不假设模型的输出100%正确它应该是一个能处理多种歧义的手。2.4 记忆与反馈层让Agent记住自己做过什么这一层是很多开源Demo里最薄弱的部分。没有记忆的CUA是一个每次决策都失忆的Agent——它连续点击同一个按钮十次因为它不记得自己已经点过九次了。记忆与反馈层至少要做三件事短期记忆保存当前任务的上下文包括已经执行过的动作序列、截图历史、中间结果。一般用队列或者列表存着作为决策层的上下文传入。状态感知判断上一步动作是否成功。比如模型点击了下一步按钮页面有没有进入到下一个步骤如果页面没有变化就要标记这个动作为失败。循环检测如果连续N步的动作哈希值相同并且屏幕状态没有变化自动终止任务并告警。在Agent圈这个能力常被叫做Self-Correction或Reflection。没有这一层CUA就是三秒记忆的金鱼有了这一层它才像一个正常的人类操作员——知道自己刚才做到哪一步了也知道自己卡住了。3. 手写一个最小可用的CUA以Playwright 视觉模型为例理论讲再多不如一个能跑的Demo。我下面给的例子是一个最小可行的CUA让AI打开浏览器在搜索框输入关键词点击搜索然后把结果页的标题打印出来。代码是我实际跑过并反复调整过的你可以直接照着搭。3.1 为什么选这个技术组合选型之前我列了几个候选方案纯Python GUI自动化PyAutoGUI全局坐标点击不依赖浏览器但不知道页面元素状态像个盲人点击器。Selenium老牌网页自动化库但API设计老等待机制弱写起来啰嗦。Playwright现代API内置自动等待、事件驱动、截图方便跨浏览器代码简洁。唯一的缺点是只聚焦浏览器场景桌面应用得另想办法。视觉模型我选用Qwen2.5-VL这一档的开源视觉模型因为它在屏幕截图理解和GUI Agent任务上表现很好而且可以本地部署数据不出内网。这个组合的核心思路是用Playwright管手用视觉模型管脑。这里为了Demo简单我直接用截图视觉模型的方式做感知层不引入DOM结构化提取。你别觉得这不是最稳的方案吗纯粹是因为这个Demo的目标是把CUA的主干逻辑讲清楚结构化提取是加在上面的锦上添花不是主干。3.2 环境准备与模型接口封装先装依赖pip install playwright httpx playwright install chromium如果你是在内网环境没有外网访问权限把playwright install chromium的下载源换成内网镜像即可。视觉模型我用的是一个HTTP服务接口假设你已经在127.0.0.1:8000上起了一个兼容OpenAI格式的视觉模型服务。这个接口的作用是接收一张截图和一段任务指令返回一个JSON格式的动作描述。import base64 import json import httpx # 视觉模型的HTTP调用封装按你实际可用的服务地址修改 VISION_MODEL_URL http://127.0.0.1:8000/v1/chat/completions def call_vision_model(image_path: str, prompt: str) - dict: 输入截图路径和任务指令返回动作JSON。 期望格式{action_type: click | input | scroll | finish, text: 搜索内容input时用, x: 123, y: 456, selector: input#kw可选优先于坐标} with open(image_path, rb) as f: image_b64 base64.b64encode(f.read()).decode() payload { model: qwen2.5-vl-7b, messages: [ { role: user, content: [ {type: text, text: prompt}, { type: image_url, image_url: {url: fdata:image/png;base64,{image_b64}}, }, ], } ], temperature: 0.1, } resp httpx.post(VISION_MODEL_URL, jsonpayload, timeout120) resp.raise_for_status() content resp.json()[choices][0][message][content] # 实际使用中模型可能返回带 json 包裹的内容需要清洗后解析 content content.strip() if content.startswith(): content content.split()[1].strip() if content.startswith(json): content content[4:].strip() return json.loads(content)这段代码里有几个细节是很多人第一次写容易忽略的一个是temperature设成0.1。CUA这种操作型任务需要的是稳定输出同一个标准格式不是有创意地输出五花八门的格式温度必须压低。另一个是返回JSON的解析。实际使用中模型经常会在JSON外面包一层Markdown代码块标记json.loads之前必须先清洗。最后一个是timeout设置120秒。视觉模型推理一张高清截图有时候确实会比较慢超时设短了你只会看到一个莫名其妙的ConnectionError。3.3 主循环逻辑观察→决策→执行现在写CUA的主循环。我用async_playwright启动一个固定窗口大小的浏览器然后循环执行截图→模型决策→执行动作直到模型输出finish或者步数用尽。import asyncio from playwright.async_api import async_playwright async def run_cua(): async with async_playwright() as p: browser await p.chromium.launch( headlessFalse, args[--window-size1280,720], ) page await browser.new_page( viewport{width: 1280, height: 720} ) await page.goto(https://www.baidu.com) max_steps 10 for step in range(max_steps): print(f----- step {step 1} -----) # 1. observe截取当前浏览器视口 screenshot_path fstep_{step 1}.png await page.screenshot(pathscreenshot_path) # 2. decide让视觉模型决定下一步做什么 action call_vision_model( screenshot_path, 当前任务是在搜索框输入cua并点击搜索按钮。 你已经完成了一部分操作请根据截图决定下一步动作 输出JSON格式动作。, ) print(模型决策:, action) # 3. act执行动作 action_type action.get(action_type, ) if action_type finish: print(Agent 判断任务完成退出循环) break elif action_type input: # 输入前先确保点击了输入框否则可能出现焦点不在输入框的问题 selector action.get(selector) if selector: await page.locator(selector).click() await page.locator(selector).fill(action.get(text, )) else: x, y action.get(x, 0), action.get(y, 0) await page.mouse.click(x, y) await page.keyboard.type(action.get(text, )) await page.keyboard.press(Enter) elif action_type click: selector action.get(selector) if selector: await page.locator(selector).click() else: await page.mouse.click(action.get(x, 0), action.get(y, 0)) elif action_type scroll: await page.mouse.wheel(0, action.get(dy, 300)) # 4. 等待页面响应避免动作后立刻截图导致状态未更新 await asyncio.sleep(2) # 打印最终页面的标题作为任务结果验证 print(最终页面标题:, await page.title()) await asyncio.sleep(3) await browser.close() if __name__ __main__: asyncio.run(run_cua())跑这个Demo的正确姿势是先把模型服务启动起来然后再运行上面的脚本。你观察运行过程会发现Agent有时候会先点击搜索框再输入再按回车这个先点击再输入的顺序就是我自己在测试中踩坑后加的——模型经常只输出填内容但不会自动帮你点一下输入框抢焦点。3.4 从Demo到真实项目你还要补三个模块上面的代码能跑通但离生产可用还差得远。如果要在公司内部用起来我建议至少再补三个模块上下文缓冲模块。上面代码每次调用模型都只传了当前截图模型不知道之前执行过什么很容易出现反复执行同一个动作。我给你一个简单做法维护一个history列表每次把(step, action_type, text, success_flag)追加进去调用模型时把最近的5条历史拼接成文本一起传过去。有了历史Agent的决策准确率会明显上升这个提升是我实测里最显著的。动作去重模块。给每个动作生成一个哈希比如action_type selector text存到一个集合里新动作执行前先检查是否在集合里。如果同一个动作出现两次且屏幕没有变化直接判定为Agent卡住了终止任务并抛出告警。人工确认模块。这一步必须做尤其当Agent要处理的是删除文件提交订单发送邮件这类不可逆操作时。实现上很简单执行前弹一个确认框把Agent打算做的动作和理由展示给用户用户点了允许才真正执行。4. 实测中的翻车现场五个最容易栽的坑4.1 坐标漂移同一个页面换台电脑就点偏了这个坑几乎每个做CUA的人都会遇到。同样的网站在你的电脑上模型输出坐标(500, 380)换一台屏幕分辨率不一样的机器那个坐标指向的位置就完全变了。原因不复杂模型是根据截图里的像素关系推断坐标截图尺寸变了像素坐标自然全变。我的解法分两层。第一层是治标固定运行环境浏览器窗口和视口都设成1280x720系统缩放比统一设成100%第二层是治本能拿到DOM元素或无障碍树的地方优先让模型输出selector而不是x/y坐标因为selector是语义化的、跟屏幕分辨率无关的定位方式。只有在纯视觉场景远程桌面、云桌面才退回到绝对坐标。4.2 模型的幻觉坐标凭空出现的按钮我遇到过一个最离谱的情况模型在页面右下角的空白区域看到了一个确认按钮于是输出一个坐标让我去点。那个位置实际上什么都没有点击当然无效。这个问题的根源是视觉模型在截图信息不充分时会基于常见界面经验脑补不存在的元素。在CUA场景里这种幻觉的破坏力很大因为Agent会自以为点了按钮然后拿着一个没变化的屏幕继续下一步决策整个任务就开始失控了。应对思路是三层在Prompt里强制要求模型只能基于截图中真实存在的元素做出判断并让它输出置信度字段。执行层在点击后检查页面状态是否有变化没有变化就标记该动作为失败。连续出现多次点击无反应后直接让Agent回退到上一步重新观察并换一种策略。4.3 动作死循环Agent反复刷新同一个页面没有记忆机制的CUA翻车方式非常统一它会不停地重复失败的操作。比如点一个下拉菜单第一次点击后弹出了选项但模型在截图里没看出来于是又点了一次菜单收起再点一次菜单展开……来回折腾直到步数耗尽。我在线上环境里专门加了一个连续重复动作检测统计最近5个动作如果其中有3个以上是相同的哈希值系统自动暂停把Agent的完整上下文发到日志平台让开发人员来看。这个检测代码不到二十行但救了我无数次。4.4 输入框焦点与输入法问题模型说输入内容但它默认你已经在输入框里了实际上焦点可能还在地址栏或者页面上根本没有可聚焦的输入框。我在Demo代码里已经写了先点击输入框再输入算是一道保险。但真实场景还有更麻烦的中文输入法。用keyboard.type(cua)输入英文字符没问题一旦要输入中文Playwright的type方法是直接注入字符事件不经过输入法有些网页接收不到。我后来改成用page.locator(...).fill(text)这个方法直接设置输入框的值并触发input事件对中文更友好。当然如果你坚持要模拟真实的键盘输入路径可以结合系统级输入法工具但那个复杂度不值得绝大多数网页用fill就够了。4.5 性能瓶颈完成一个任务要一分钟我测过一个真实场景让CUA在一个企业后台里完成筛选数据→导出报表→下载文件三个步骤总共用了78秒。而一个熟练的人类员工只需要15秒。这里面的时间主要耗在截图生成、视觉模型推理、页面等待、网络通信。优化方向我整理了一个优先级清单亲测有效优化手段效果实现成本用结构化提取Accessibility Tree替代纯视觉截图推理速度提升2-3倍坐标准确率大幅上升中缩小截图分辨率只截取当前操作区域视觉模型推理token减少延迟降低低引入OpenAI/兼容接口的流式输出首包返回速度快感觉上更跟手低历史动作缓存避免重复推理对稳定流程可以省去多轮模型调用高用轻量模型做预分类重量模型只处理模糊场景综合成本最优但工程复杂高4.6 安全边界给Agent的权限再收一收最后单独说安全。CUA天然拥有操作电脑的能力等于说你把一把锋利的刀交给了AI。我在内部项目里定了几条红线操作白名单Agent只能访问白名单内的域名和软件其他一律拒绝。高危动作拦截删除文件、卸载软件、支付、发送邮件、修改系统设置这些操作必须经过人工二次确认。步数与时间配额单个任务最多执行20步超过即终止单次会话最长运行10分钟。全量审计日志每张截图、每个动作、每次模型决策都要落库出事的时候可以完整回溯。有人觉得这些限制会让CUA不够智能但我的观点恰恰相反边界清晰的权限体系才是让CUA敢在生产环境里放开手脚的前提。你越能控制风险业务方就越愿意给你更大的操作空间。5. 从一个踩坑案例看CUA的边界不是所有任务都适合它为了不让你觉得我只会讲理论我把最近一个真实的踩坑案例拿出来说说。我们要做的任务是让CUA自动登录公司的一个老旧CRM系统把当天的新增客户列表导出。这个系统用的是二十年前的ActiveX控件没有APIIE时代的老架构登录甚至要装插件。第一版方案我用了Template计划视觉识别Macro搞掂其中Macro用文本命令把任务流程写死。结果上线第三天就翻车了CRM系统悄悄更新了页面布局登录按钮往下移了50个像素整个流程失效。后来改用纯视觉CUA方案之后CUA竟然自己适应了变化——它通过视觉观察找到了登录按钮的新位置顺利完成任务。这件事给我最直观的感受是CUA的价值不在快而在面对变化时的自适应能力。但与此同时我也知道了哪些场景不该用CUA绝对性能敏感的场景毫秒级高频操作比如在UI自动化测试里重复点击几千次还是用传统脚本吧CUA太慢了。纯确定性的批量任务每天跑一样的流程、完全不会变的场景传统RPA的维护成本其实很低没必要上CUA。需要极强数据安全保证的任务所有数据都不能出系统边界AI模型和服务都只能在内网运行。如果你的内网环境不支持本地部署视觉大模型这个场景就先别碰了。任务结果要求绝对唯一的场景比如财务对账每一笔分录都要求精确到小数点后两位CUA目前的非确定性本质决定了它不适合这种场景。6. 写在最后一些实操层面的经验如果让我给准备上手做CUA的人一个建议浓缩成一句话就是先想清楚你要解决的最后一公里到底是什么再决定要不要上CUA。我在实际项目里体会最深的一点是CUA和RPA不是替代关系而是互补关系。RPA适合业务规则完全明确、流程固定的场景优点是快、确定、便宜CUA适合规则语义化、界面不稳定、没有API的长尾场景优点是自适应、泛化、能自己纠错。你让CUA跟RPA拼速度是必输的但让CUA去做RPA一改版就崩掉的页面它反而能稳稳接住。第二个经验是关于团队配置的。一个CUA项目的最小团队除了后端工程师之外最好有一个熟悉目标业务的人还有一个懂得怎么调prompt的算法工程师。很多人在项目里死磕模型效果结果发现卡点根本不在模型而是在业务需求的描述上——把这个报表导出来这句话本身就有很多歧义按什么时间段导出成什么格式最后一个技术上的建议先跑通一个单步循环再上完整任务。所谓单步循环就是只让Agent执行一个动作你人工确认这个动作对不对对了再放开下一步。把循环一步步调稳比一口气测试一个10步完整任务调试效率高得多。CUA是个很有意思的方向但别把它神化。它本质上是让AI学会使用人类世界的工具这条路还很长值得早早下场试水。希望这篇手记能帮你少走几条弯路有想法的话去搭一个属于你自己的Demo吧。
最近半个月我至少有四位做SaaS的朋友问同一个问题那个能自己点鼠标的AI是怎么回事我能用它跑通我们家的业务流程吗他们说的东西就是前段时间被反复刷屏的CUAComputer-Using Agent。说老实话这个概念刚出来的时候我第一反应是这不就是套了层壳的RPA吗直到自己动手做了个Demo、又在一个内部项目里试了一轮才意识到这玩意儿和传统自动化在思路上根本是两码事。这篇文章就从我的视角从头理一遍CUA到底解决什么问题、系统架构长什么样、怎么用最小的成本搭一个能跑起来的Demo、以及实测中那些文档不会告诉你的坑。如果你正在做AI应用开发、自动化测试或者公司里有一堆没有API的旧系统等着提效这篇文章应该能帮你省下不少调研时间。我把话说在前头CUA不是万能药它有自己的适用边界但搞清楚边界在哪里恰恰是把它用好最关键的一步。1. CUA概念拆解AI从对话到动手的分水岭1.1 从ChatBot到CUA到底改变了什么CUA的全称是Computer-Using Agent说白了就是一个能像人一样操作电脑的AI智能体。它不看API文档不调后端接口而是用眼睛看屏幕、用大脑做判断、用手去点鼠标敲键盘。过去几年我们说的AI自动化绝大多数是下面这条路ChatBot你问它答输出文本能力停留在嘴上。Function Calling / Tool Use模型根据用户意图调用预先定义好的API函数能力从嘴上延伸到后台。CUA模型直接操作GUI点击、输入、滚动、拖拽能力覆盖到所有人类能在电脑上做的事。一个我经常用的类比以前的AI像你给物业打电话说麻烦叫师傅来修一下电闸CUA是AI自己带着工具箱上门看着墙上的配电箱亲手去扳那个开关。前者依赖物业的系统里有修电闸这个标准服务后者只需要AI看得懂配电箱长得什么样。这个差别在真实业务里非常大。你有多少系统是完全没有API的我见过不少公司核心业务跑在一套十年前的三方系统上供应商早就不维护了数据导出来靠人工操作流程靠肌肉记忆。这种场景下RPA的脚本写起来痛苦不堪页面一改版就报废因为传统RPA的核心是按固定的选择器找元素而CUA的核心是理解当前屏幕状态再动态决定下一步动作。1.2 为什么cua这个词在最近突然火了技术圈的热词很少是凭空冒出来的。CUA能被推到台前背后是三个技术里程碑在同时逼近临界点第一个是视觉大模型的进步。GPT-4V、Claude 3.5/3.7、Qwen2.5-VL这一代模型都能把一张截图里的像素信息抽象成按钮、输入框、文字、图标这些人类语义。要知道在2022年之前让AI看截图然后精确告诉我登录按钮在坐标(500, 380)这件事简直是天方夜谭。现在视觉模型的截图理解能力已经稳定到可以支撑实际生产。第二个是Agent工程化的成熟。推理、规划、工具调用、反思Reflection这些模式被沉淀成了稳定的Agent框架和最佳实践。CUA不是一个模型而是一套模型编排逻辑执行器的系统。工程上的成熟让这套系统的开发门槛从需要一个算法团队攻坚降到了一个熟悉Python的后端工程师就能搭起来。第三个是需求端的真实痛点。RPA十几年都没能完全解决的问题——长尾、变化、跨平台、无API——恰恰是CUA最适合的领域。大家发现与其针对每个系统写一套自动化脚本不如训练一个通用的操作员让AI自己适应各种界面。1.3 一个容易被误解的点CUA不是截图调大模型我见过太多人刚开始做CUA时以为它等于把屏幕截图发给大模型让模型返回一个坐标然后点一下。这个理解方向没错但离能稳定工作差了十万八千里。真实世界里的CUA是一个循环而且每一步都不是单一的模型调用我先不展开把这个循环放到下一章讲架构时一起说。这里你只需要记住一个核心观点CUA最大的价值不是它会点鼠标而是它能在点错之后自己发现并修正。这种闭环能力才是它和传统自动化的本质区别。2. CUA系统四层架构一份可落地的技术地图我在实际项目中把CUA系统拆成了四层感知层、决策层、执行层、记忆与反馈层。这个分层不是学术上的分类而是我在调试Bug时实实在在感受到的四个事故高发区。每一层单独看都不复杂但层与层之间的衔接才是真正容易出现鬼故事的地方。2.1 感知层AI是怎么看屏幕的感知层的任务只有一个把当前屏幕上的信息变成模型能理解的输入。目前主流有三种做法方案原理优点缺点纯视觉截屏后直接把图片喂给多模态模型通用性强什么软件都能用推理慢、坐标可能不准、token成本高结构化提取读取网页DOM、桌面应用的无障碍树Accessibility Tree信息精确、token成本低依赖应用对外开放这些数据混合方案先用结构化提取失败时回退到纯视觉兼顾通用性和精度实现复杂度高我自己在网页自动化里90%的场景用结构化提取DOM Accessibility Tree因为网页和很多桌面框架比如Electron应用、Windows的UIA都能拿到语义树比让模型去猜按钮位置可靠得多。但遇到远程桌面、云桌面、某些重绘的软件界面时拿不到语义树就只能切到纯视觉通道。这里有个关键的工程细节坐标对齐。结构化提取拿到的是DOM元素在页面里的逻辑位置而执行层做鼠标点击时用的是屏幕坐标两者之间隔着一个浏览器视口偏移和操作系统缩放比。Windows系统如果开了125%或150%的缩放坐标会整体漂移这是新人最容易踩的坑。我的做法是在做CUA之前先把整个链路截图→语义→点击通跑一遍用一个固定的1280x720无缩放的测试环境验证坐标再逐步放开环境限制。2.2 决策层决定下一步做什么的大脑决策层是整个CUA系统的核心也是和传统RPA差别最大的地方。RPA是流程图CUA是决策链。决策层要做的事有三件任务拆解Task Decomposition把整理这个月的销售报表拆成打开系统→进入报表模块→选择时间→点击导出→处理下载的文件这样的子步骤。这一步通常由大模型基于对任务的语义理解来完成。下一步动作预测Next Action Prediction拿到当前屏幕的观察结果后决定是点击这个按钮、在输入框填写内容、滚动页面还是结束任务。完成状态判断Task Completion Judgement怎么判断任务做完了是页面上出现了预期的结果还是已经执行了N个动作现在工业界主流的做法是让大模型每次只输出一个或几个动作而不是让它一次把整个计划都列出来。原因是长计划的准确率会随步骤数量指数级下降走一步看一步反而更稳。你可以把决策层理解成一个不断看路、不断纠偏的自动驾驶而不是设定好路线后一动不动地开到底。2.3 执行层把想法变成动作执行层负责把模型决策出的动作翻译成真实的GUI事件。网页自动化我优先用Playwright它比Selenium更现代自带等待机制事件模型也更好用桌面自动化则看操作系统网页Playwright / PuppeteerWindows桌面PyAutoGUI UI AutomationUIAmacOS桌面Accessibility API PyAutoGUI远程桌面/虚拟桌面图像识别 PyAutoGUI或者虚拟机内的Agent方案执行层最容易忽略的是动作的容错。比如模型决定点击输入框但页面上有多个输入框模型没指定是哪一个。这时候执行层需要有兜底策略先激活页面上最可能的输入框根据焦点状态判断如果没有焦点再解析坐标实在不行就重新截图让模型确认。我的原则是执行层永远不假设模型的输出100%正确它应该是一个能处理多种歧义的手。2.4 记忆与反馈层让Agent记住自己做过什么这一层是很多开源Demo里最薄弱的部分。没有记忆的CUA是一个每次决策都失忆的Agent——它连续点击同一个按钮十次因为它不记得自己已经点过九次了。记忆与反馈层至少要做三件事短期记忆保存当前任务的上下文包括已经执行过的动作序列、截图历史、中间结果。一般用队列或者列表存着作为决策层的上下文传入。状态感知判断上一步动作是否成功。比如模型点击了下一步按钮页面有没有进入到下一个步骤如果页面没有变化就要标记这个动作为失败。循环检测如果连续N步的动作哈希值相同并且屏幕状态没有变化自动终止任务并告警。在Agent圈这个能力常被叫做Self-Correction或Reflection。没有这一层CUA就是三秒记忆的金鱼有了这一层它才像一个正常的人类操作员——知道自己刚才做到哪一步了也知道自己卡住了。3. 手写一个最小可用的CUA以Playwright 视觉模型为例理论讲再多不如一个能跑的Demo。我下面给的例子是一个最小可行的CUA让AI打开浏览器在搜索框输入关键词点击搜索然后把结果页的标题打印出来。代码是我实际跑过并反复调整过的你可以直接照着搭。3.1 为什么选这个技术组合选型之前我列了几个候选方案纯Python GUI自动化PyAutoGUI全局坐标点击不依赖浏览器但不知道页面元素状态像个盲人点击器。Selenium老牌网页自动化库但API设计老等待机制弱写起来啰嗦。Playwright现代API内置自动等待、事件驱动、截图方便跨浏览器代码简洁。唯一的缺点是只聚焦浏览器场景桌面应用得另想办法。视觉模型我选用Qwen2.5-VL这一档的开源视觉模型因为它在屏幕截图理解和GUI Agent任务上表现很好而且可以本地部署数据不出内网。这个组合的核心思路是用Playwright管手用视觉模型管脑。这里为了Demo简单我直接用截图视觉模型的方式做感知层不引入DOM结构化提取。你别觉得这不是最稳的方案吗纯粹是因为这个Demo的目标是把CUA的主干逻辑讲清楚结构化提取是加在上面的锦上添花不是主干。3.2 环境准备与模型接口封装先装依赖pip install playwright httpx playwright install chromium如果你是在内网环境没有外网访问权限把playwright install chromium的下载源换成内网镜像即可。视觉模型我用的是一个HTTP服务接口假设你已经在127.0.0.1:8000上起了一个兼容OpenAI格式的视觉模型服务。这个接口的作用是接收一张截图和一段任务指令返回一个JSON格式的动作描述。import base64 import json import httpx # 视觉模型的HTTP调用封装按你实际可用的服务地址修改 VISION_MODEL_URL http://127.0.0.1:8000/v1/chat/completions def call_vision_model(image_path: str, prompt: str) - dict: 输入截图路径和任务指令返回动作JSON。 期望格式{action_type: click | input | scroll | finish, text: 搜索内容input时用, x: 123, y: 456, selector: input#kw可选优先于坐标} with open(image_path, rb) as f: image_b64 base64.b64encode(f.read()).decode() payload { model: qwen2.5-vl-7b, messages: [ { role: user, content: [ {type: text, text: prompt}, { type: image_url, image_url: {url: fdata:image/png;base64,{image_b64}}, }, ], } ], temperature: 0.1, } resp httpx.post(VISION_MODEL_URL, jsonpayload, timeout120) resp.raise_for_status() content resp.json()[choices][0][message][content] # 实际使用中模型可能返回带 json 包裹的内容需要清洗后解析 content content.strip() if content.startswith(): content content.split()[1].strip() if content.startswith(json): content content[4:].strip() return json.loads(content)这段代码里有几个细节是很多人第一次写容易忽略的一个是temperature设成0.1。CUA这种操作型任务需要的是稳定输出同一个标准格式不是有创意地输出五花八门的格式温度必须压低。另一个是返回JSON的解析。实际使用中模型经常会在JSON外面包一层Markdown代码块标记json.loads之前必须先清洗。最后一个是timeout设置120秒。视觉模型推理一张高清截图有时候确实会比较慢超时设短了你只会看到一个莫名其妙的ConnectionError。3.3 主循环逻辑观察→决策→执行现在写CUA的主循环。我用async_playwright启动一个固定窗口大小的浏览器然后循环执行截图→模型决策→执行动作直到模型输出finish或者步数用尽。import asyncio from playwright.async_api import async_playwright async def run_cua(): async with async_playwright() as p: browser await p.chromium.launch( headlessFalse, args[--window-size1280,720], ) page await browser.new_page( viewport{width: 1280, height: 720} ) await page.goto(https://www.baidu.com) max_steps 10 for step in range(max_steps): print(f----- step {step 1} -----) # 1. observe截取当前浏览器视口 screenshot_path fstep_{step 1}.png await page.screenshot(pathscreenshot_path) # 2. decide让视觉模型决定下一步做什么 action call_vision_model( screenshot_path, 当前任务是在搜索框输入cua并点击搜索按钮。 你已经完成了一部分操作请根据截图决定下一步动作 输出JSON格式动作。, ) print(模型决策:, action) # 3. act执行动作 action_type action.get(action_type, ) if action_type finish: print(Agent 判断任务完成退出循环) break elif action_type input: # 输入前先确保点击了输入框否则可能出现焦点不在输入框的问题 selector action.get(selector) if selector: await page.locator(selector).click() await page.locator(selector).fill(action.get(text, )) else: x, y action.get(x, 0), action.get(y, 0) await page.mouse.click(x, y) await page.keyboard.type(action.get(text, )) await page.keyboard.press(Enter) elif action_type click: selector action.get(selector) if selector: await page.locator(selector).click() else: await page.mouse.click(action.get(x, 0), action.get(y, 0)) elif action_type scroll: await page.mouse.wheel(0, action.get(dy, 300)) # 4. 等待页面响应避免动作后立刻截图导致状态未更新 await asyncio.sleep(2) # 打印最终页面的标题作为任务结果验证 print(最终页面标题:, await page.title()) await asyncio.sleep(3) await browser.close() if __name__ __main__: asyncio.run(run_cua())跑这个Demo的正确姿势是先把模型服务启动起来然后再运行上面的脚本。你观察运行过程会发现Agent有时候会先点击搜索框再输入再按回车这个先点击再输入的顺序就是我自己在测试中踩坑后加的——模型经常只输出填内容但不会自动帮你点一下输入框抢焦点。3.4 从Demo到真实项目你还要补三个模块上面的代码能跑通但离生产可用还差得远。如果要在公司内部用起来我建议至少再补三个模块上下文缓冲模块。上面代码每次调用模型都只传了当前截图模型不知道之前执行过什么很容易出现反复执行同一个动作。我给你一个简单做法维护一个history列表每次把(step, action_type, text, success_flag)追加进去调用模型时把最近的5条历史拼接成文本一起传过去。有了历史Agent的决策准确率会明显上升这个提升是我实测里最显著的。动作去重模块。给每个动作生成一个哈希比如action_type selector text存到一个集合里新动作执行前先检查是否在集合里。如果同一个动作出现两次且屏幕没有变化直接判定为Agent卡住了终止任务并抛出告警。人工确认模块。这一步必须做尤其当Agent要处理的是删除文件提交订单发送邮件这类不可逆操作时。实现上很简单执行前弹一个确认框把Agent打算做的动作和理由展示给用户用户点了允许才真正执行。4. 实测中的翻车现场五个最容易栽的坑4.1 坐标漂移同一个页面换台电脑就点偏了这个坑几乎每个做CUA的人都会遇到。同样的网站在你的电脑上模型输出坐标(500, 380)换一台屏幕分辨率不一样的机器那个坐标指向的位置就完全变了。原因不复杂模型是根据截图里的像素关系推断坐标截图尺寸变了像素坐标自然全变。我的解法分两层。第一层是治标固定运行环境浏览器窗口和视口都设成1280x720系统缩放比统一设成100%第二层是治本能拿到DOM元素或无障碍树的地方优先让模型输出selector而不是x/y坐标因为selector是语义化的、跟屏幕分辨率无关的定位方式。只有在纯视觉场景远程桌面、云桌面才退回到绝对坐标。4.2 模型的幻觉坐标凭空出现的按钮我遇到过一个最离谱的情况模型在页面右下角的空白区域看到了一个确认按钮于是输出一个坐标让我去点。那个位置实际上什么都没有点击当然无效。这个问题的根源是视觉模型在截图信息不充分时会基于常见界面经验脑补不存在的元素。在CUA场景里这种幻觉的破坏力很大因为Agent会自以为点了按钮然后拿着一个没变化的屏幕继续下一步决策整个任务就开始失控了。应对思路是三层在Prompt里强制要求模型只能基于截图中真实存在的元素做出判断并让它输出置信度字段。执行层在点击后检查页面状态是否有变化没有变化就标记该动作为失败。连续出现多次点击无反应后直接让Agent回退到上一步重新观察并换一种策略。4.3 动作死循环Agent反复刷新同一个页面没有记忆机制的CUA翻车方式非常统一它会不停地重复失败的操作。比如点一个下拉菜单第一次点击后弹出了选项但模型在截图里没看出来于是又点了一次菜单收起再点一次菜单展开……来回折腾直到步数耗尽。我在线上环境里专门加了一个连续重复动作检测统计最近5个动作如果其中有3个以上是相同的哈希值系统自动暂停把Agent的完整上下文发到日志平台让开发人员来看。这个检测代码不到二十行但救了我无数次。4.4 输入框焦点与输入法问题模型说输入内容但它默认你已经在输入框里了实际上焦点可能还在地址栏或者页面上根本没有可聚焦的输入框。我在Demo代码里已经写了先点击输入框再输入算是一道保险。但真实场景还有更麻烦的中文输入法。用keyboard.type(cua)输入英文字符没问题一旦要输入中文Playwright的type方法是直接注入字符事件不经过输入法有些网页接收不到。我后来改成用page.locator(...).fill(text)这个方法直接设置输入框的值并触发input事件对中文更友好。当然如果你坚持要模拟真实的键盘输入路径可以结合系统级输入法工具但那个复杂度不值得绝大多数网页用fill就够了。4.5 性能瓶颈完成一个任务要一分钟我测过一个真实场景让CUA在一个企业后台里完成筛选数据→导出报表→下载文件三个步骤总共用了78秒。而一个熟练的人类员工只需要15秒。这里面的时间主要耗在截图生成、视觉模型推理、页面等待、网络通信。优化方向我整理了一个优先级清单亲测有效优化手段效果实现成本用结构化提取Accessibility Tree替代纯视觉截图推理速度提升2-3倍坐标准确率大幅上升中缩小截图分辨率只截取当前操作区域视觉模型推理token减少延迟降低低引入OpenAI/兼容接口的流式输出首包返回速度快感觉上更跟手低历史动作缓存避免重复推理对稳定流程可以省去多轮模型调用高用轻量模型做预分类重量模型只处理模糊场景综合成本最优但工程复杂高4.6 安全边界给Agent的权限再收一收最后单独说安全。CUA天然拥有操作电脑的能力等于说你把一把锋利的刀交给了AI。我在内部项目里定了几条红线操作白名单Agent只能访问白名单内的域名和软件其他一律拒绝。高危动作拦截删除文件、卸载软件、支付、发送邮件、修改系统设置这些操作必须经过人工二次确认。步数与时间配额单个任务最多执行20步超过即终止单次会话最长运行10分钟。全量审计日志每张截图、每个动作、每次模型决策都要落库出事的时候可以完整回溯。有人觉得这些限制会让CUA不够智能但我的观点恰恰相反边界清晰的权限体系才是让CUA敢在生产环境里放开手脚的前提。你越能控制风险业务方就越愿意给你更大的操作空间。5. 从一个踩坑案例看CUA的边界不是所有任务都适合它为了不让你觉得我只会讲理论我把最近一个真实的踩坑案例拿出来说说。我们要做的任务是让CUA自动登录公司的一个老旧CRM系统把当天的新增客户列表导出。这个系统用的是二十年前的ActiveX控件没有APIIE时代的老架构登录甚至要装插件。第一版方案我用了Template计划视觉识别Macro搞掂其中Macro用文本命令把任务流程写死。结果上线第三天就翻车了CRM系统悄悄更新了页面布局登录按钮往下移了50个像素整个流程失效。后来改用纯视觉CUA方案之后CUA竟然自己适应了变化——它通过视觉观察找到了登录按钮的新位置顺利完成任务。这件事给我最直观的感受是CUA的价值不在快而在面对变化时的自适应能力。但与此同时我也知道了哪些场景不该用CUA绝对性能敏感的场景毫秒级高频操作比如在UI自动化测试里重复点击几千次还是用传统脚本吧CUA太慢了。纯确定性的批量任务每天跑一样的流程、完全不会变的场景传统RPA的维护成本其实很低没必要上CUA。需要极强数据安全保证的任务所有数据都不能出系统边界AI模型和服务都只能在内网运行。如果你的内网环境不支持本地部署视觉大模型这个场景就先别碰了。任务结果要求绝对唯一的场景比如财务对账每一笔分录都要求精确到小数点后两位CUA目前的非确定性本质决定了它不适合这种场景。6. 写在最后一些实操层面的经验如果让我给准备上手做CUA的人一个建议浓缩成一句话就是先想清楚你要解决的最后一公里到底是什么再决定要不要上CUA。我在实际项目里体会最深的一点是CUA和RPA不是替代关系而是互补关系。RPA适合业务规则完全明确、流程固定的场景优点是快、确定、便宜CUA适合规则语义化、界面不稳定、没有API的长尾场景优点是自适应、泛化、能自己纠错。你让CUA跟RPA拼速度是必输的但让CUA去做RPA一改版就崩掉的页面它反而能稳稳接住。第二个经验是关于团队配置的。一个CUA项目的最小团队除了后端工程师之外最好有一个熟悉目标业务的人还有一个懂得怎么调prompt的算法工程师。很多人在项目里死磕模型效果结果发现卡点根本不在模型而是在业务需求的描述上——把这个报表导出来这句话本身就有很多歧义按什么时间段导出成什么格式最后一个技术上的建议先跑通一个单步循环再上完整任务。所谓单步循环就是只让Agent执行一个动作你人工确认这个动作对不对对了再放开下一步。把循环一步步调稳比一口气测试一个10步完整任务调试效率高得多。CUA是个很有意思的方向但别把它神化。它本质上是让AI学会使用人类世界的工具这条路还很长值得早早下场试水。希望这篇手记能帮你少走几条弯路有想法的话去搭一个属于你自己的Demo吧。
