最近“cua”这个词在AI Agent开发圈里频繁刷屏。我第一次看到的时候第一反应是有人把CUDA打错了点进去读了几篇文章才确认大家说的是Computer-Using Agent——能像人一样操作计算机的智能体。如果你搜的是N卡编程框架那可以直接关页面了这里聊的不是它。这篇文章不打算做概念科普而是把这个热词拆开揉碎从原理讲到最小原型实现再把我实际调试中踩过的坑一并列出来。适合正在做Agent开发、准备把RPA升级成AI自动化、或者只是好奇“AI怎么自己用电脑”的朋友阅读。1. 先搞清楚CUA到底在说什么从“会聊天”到“会动手”1.1 一句话定义与三个核心组件CUA全称Computer-Using Agent直译过来就是“使用计算机的智能体”。它和普通聊天机器人的本质区别在于它能越过对话界面直接操作操作系统里的各种软件——移动鼠标、点击按钮、输入文字、滚动页面、按下快捷键像一位真实员工那样把电脑当成工具用。拆开来看一个完整的CUA系统由三个核心组件组成。第一是感知组件。它通过截图、屏幕录制或系统辅助功能接口把当前屏幕状态变成模型可以理解的数据。大多数实现里就是一张高分辨率截图让视觉语言模型“看”屏幕。第二是决策组件。这是整个系统的“大脑”通常是一个多模态大模型。它根据用户下达的任务目标、当前截图内容和历史操作记录推理出“下一步该做什么”。这一步不是自由对话而是输出一个严格定义的动作指令。第三是执行组件。它负责把模型输出的动作落到真实环境里可以是模拟鼠标键盘操作也可能是调用浏览器自动化接口。执行之后系统会再次截取屏幕把新的状态反馈给模型形成循环。1.2 这场爆发背后的三个技术突破CUA这个概念其实不新2020年前后就有研究者尝试用多模态模型操作网页。但当时做出来的东西基本没法用原因很简单识别不准、决策不稳、执行一会儿就崩。为什么最近这两年突然爆发了我个人理解是三个技术条件的成熟。第一个是视觉理解能力的质变。现在的视觉语言模型不仅能描述图片内容还能精确理解UI界面里的元素层级、按钮状态、文字内容和空间关系。截一张后台管理系统的截图模型能准确告诉你“右上角有个蓝色的提交按钮当前处于可点击状态”。这在三年前是很难想象的。第二个是指令遵循能力的大幅提升。CUA要求模型输出的是标准化JSON动作而不是一长段自然语言分析。新一代模型的指令遵循能力足够稳定能够严格遵循“只输出一个动作”“坐标使用整数”“不能编造元素”这类约束。第三个是长上下文窗口和工具调用机制。一次真实操作任务动辄十几步、几十步模型需要同时记住当前状态、任务目标、已经完成的操作和失败原因。长上下文解决了“记忆”问题工具调用机制则让模型的行为可以和真实系统安全地对接。1.3 CUA与RPA、传统脚本的本质差别很多人听到CUA第一反应是“这不就是RPA吗”。这个误解需要澄清。RPARobotic Process Automation和CUA表面上都是自动化操作计算机但底层逻辑完全不同。RPA的核心是“规则固定”。你通过录制器录制一套操作流程脚本会严格按照录制的坐标和控件路径执行。页面如果变了流程就断了。而CUA的核心是“视觉驱动决策”。它不关心按钮在哪个固定位置而是每次看截图、理解当前界面、动态决定操作方式。页面改版了它换个按钮也能继续完成目标。传统自动化脚本更不用说了本质是程序员预先编写好的确定性步骤。CUA则是让模型实时理解环境和任务具备面对异常情况时的应变能力。我做一个简单对比维度传统脚本RPACUA驱动方式代码逻辑录制规则视觉模型推理环境变化直接失效需要重新录制大多数情况可自适应错误处理无崩溃即停一般靠异常捕获模型观察状态后自我修正适用复杂度低中中高上手门槛需要编程能力业务人员可学需要模型和工程基础CUA并不是来取代RPA的它更像是给自动化系统装上了一双“眼睛”和一个“会思考的脑子”让原本脆弱易断的自动化流程变得更接近人类的操作方式。2. CUA的核心工作循环截图、决策、动作、验证2.1 感知层模型看到的不是屏幕是一张图几乎所有CUA系统的第一步都是把屏幕变成图像。听起来很简单实际操作细节非常多。首先要解决截图的分辨率和清晰度问题。我在实测中发现高分屏截图如果不做缩放直接把4K分辨率的图丢给模型不仅视觉Token消耗巨大模型对小元素的识别率反而会下降。我一般会把截图统一缩放到1280像素左右的宽度在保证可读性的前提下压缩Token成本。其次是截图的时机。一次操作完成后页面上可能还有动画、loading状态、局部刷新如果立刻截图会截到中间态。我通常在执行完动作后等待500到1000毫秒或者监听网络空闲事件再截图。这一点在后续踩坑章节会详细展开。然后是给模型提供界面的“辅助标注”。我常用的做法是在截图前给所有可见的可交互元素注入编号标签元素旁边显示E0、E1、E2这样的红色标记。模型在截图里直接看到这些编号输出动作时就可以直接用“点击E3”这种精确表达避免坐标偏移和幻觉描述。2.2 决策层把“下一步做什么”压缩成有限动作决策层是CUA最核心的部分。模型接收到的输入通常包含三块系统预定义的行动规则、用户的任务描述、当前截图以及最近几步的历史记录。行动规则的设计非常关键。很多初学CUA的人会犯一个错误就是让模型自由地“思考”和“输出”结果模型返回一长段文字分析还要靠正则解析才能提取出动作。正确做法是把动作空间压缩成一个枚举集合强制模型在固定类型里选择。我常用的动作集合只有六个click点击某个元素type在某个输入框填入文本scroll滚动页面press按键比如Enter、Tabwait等待一段时间通常是页面加载done任务已完成结束循环模型输出的格式是严格的JSON。我用结构化输出或JSON Schema来约束保证每次返回的字段都完整、类型都正确省去了解析容错的烦恼。2.3 执行层从JSON动作到真实鼠标键盘决策出来后执行层负责把它变成真实操作。这一步又要分为两类环境。一类是浏览器环境。我用Playwright居多它能把“点击E0”翻译成真实的DOM元素定位、坐标点击还能处理页面跳转和等待逻辑。浏览器自动化最大的好处是可观测性高每一步之后都能拿到页面状态方便验证。另一类是桌面环境。操作任意Windows或macOS应用程序通常用PyAutoGUI、uiautomation或者系统的辅助功能接口。桌面环境的问题在于没有“DOM”可以直接定位模型输出的坐标和操作需要更精细的校准这也是为什么目前真正稳定的CUA产品大多先落地在浏览器场景。执行层还有一个隐藏职责它要在动作执行失败时提供反馈。比如模型点击了E5但E5不可见或者被遮挡执行层应该捕获异常把错误信息返还给模型让模型在下一次决策中调整策略。2.4 验证层CUA为什么需要自我纠错传统脚本执行完一个动作后会自动执行下一个整个过程是线性的不回头检查。CUA则不同每执行完一个动作系统都会重新截图让模型判断“刚才的操作是否达到了预期效果”。这个验证机制让CUA在复杂环境中有了自我纠错能力。比如模型原本打算点击“下一步”按钮结果点到了旁边的“重置”表面上动作执行成功了但页面状态变成了空白表单。如果没有验证层系统会继续往错误方向走。有了验证层模型看到新的截图发现表单被清空了就会意识到刚才的操作是错误的从而调整策略。验证层还可以用来自动确认任务完成模型通过比较截图上的表单内容填充情况判断是否满足任务目标如果满足就输出done终止循环。这一步是整个闭环的心理闭环缺少验证CUA就只是一个“盲操作脚本”和传统自动化的差距就消失了。3. 手写一个最小可用的CUA原型20分钟跑通表单自动化3.1 环境准备Python Playwright 多模态模型理论铺垫再多不如直接跑一个能用的原型。我选择的技术栈是Python Playwright 多模态大模型API。选择Python的原因很简单生态最全无论是调用模型还是处理图像都有成熟的库。Playwright负责浏览器自动化它比Selenium更现代自带有等待、截图、录制等功能。模型端我建议你准备一个视觉语言模型的接口可以用云端的多模态API也可以用Ollama或vLLM在本地部署的Qwen2.5-VL之类的模型。本地方案的好处不用多解释不需要纠结网络和环境问题。安装依赖就三条命令的事pip install playwright pillow openai playwright install chromium模型接口我习惯用OpenAI兼容格式调用这样无论后面换哪个模型服务商代码都不用大改。3.2 关键设计先把动作空间定义清楚动手写代码前先把动作空间用JSON Schema固定下来。为什么这一步要放在最前面因为模型行为的高度不确定性一旦脱离了约束框架就会分不清边界。我定义一个最小但完整的动作Schema{ type: object, properties: { action: { type: string, enum: [click, type, scroll, press, wait, done] }, target: { type: string, description: 截图里可见的元素标签如 E0、E12 }, value: { type: string, description: 需要输入的文本、按键名或滚动距离 }, reason: { type: string, description: 当前动作的理由方便调试审计 } }, required: [action, target, reason] }这里的关键点是每个动作都必须带原因。我一开始不太在意这个字段后来排查模型乱操作问题时全靠reason日志还原当时的决策逻辑。现在我的每个原型里都会保留它。3.3 核心实现截图、注入标签、调用模型、执行下面这段代码是我做过精简之后的最小可运行版本。它实现了一个完整的感知-决策-执行循环核心逻辑大约60行。import base64 import json import time from io import BytesIO from PIL import Image from openai import OpenAI from playwright.sync_api import sync_playwright client OpenAI(base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY) MODEL qwen2.5-vl-7b-instruct MAX_STEPS 15 def screenshot_b64(page): raw page.screenshot(typejpeg, quality70) img Image.open(BytesIO(raw)) img.thumbnail((1280, 720)) buf BytesIO() img.save(buf, JPEG, quality70) return base64.b64encode(buf.getvalue()).decode() def mark_elements(page): page.evaluate(() { const selector a, button, input, select, textarea, [rolebutton], [rolelink], [roletab]; const els document.querySelectorAll(selector); els.forEach((el, i) { const id E i; el.setAttribute(data-cua-id, id); const r el.getBoundingClientRect(); if (r.width 0 || r.height 0) return; const marker document.createElement(div); marker.textContent id; marker.style.cssText position:absolute;z-index:999999;background:#ff5722;color:#fff; font-size:12px;padding:2px 5px;border-radius:3px;pointer-events:none; left: (r.left window.scrollX) px; top: (r.top window.scrollY - 20) px;; document.body.appendChild(marker); }); }) def decide(task, history, b64_img): system_prompt ( 你是计算机操作智能体。根据任务、历史动作和当前截图决定下一步动作。 必须只输出JSON对象格式: {\action\: \...\, \target\: \...\, \value\: \...\, \reason\: \...\}。 action只能是 click/type/scroll/press/wait/done。 target优先用截图里可见的元素标签如E0、E12。 不要操作假设中存在的元素只能操作截图里看得到的元素。每次只执行一个动作。 ) response client.chat.completions.create( modelMODEL, messages[ {role: system, content: system_prompt}, {role: user, content: [ {type: text, text: f任务{task}\n历史动作{json.dumps(history[-5:], ensure_asciiFalse)}\n请输出下一步动作。}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{b64_img}}} ]}, ], temperature0.2, response_format{type: json_object}, ) return json.loads(response.choices[0].message.content) def execute_action(page, action): act action.get(action) if act click: page.locator(f[data-cua-id{action[target]}]).click() elif act type: page.locator(f[data-cua-id{action[target]}]).fill(action.get(value, )) elif act scroll: page.mouse.wheel(0, int(action.get(value, 300))) elif act press: page.keyboard.press(action.get(value, Enter)) elif act wait: time.sleep(float(action.get(value, 1))) def run_task(url, task): with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page(viewport{width: 1280, height: 720}) page.goto(url) history [] for step in range(MAX_STEPS): mark_elements(page) time.sleep(0.3) b64 screenshot_b64(page) action decide(task, history, b64) history.append(action) print(f[step {step}] action{action}) if action[action] done: print(任务完成) return True, history try: execute_action(page, action) time.sleep(0.8) except Exception as exc: history.append({error: str(exc)}) print(f[step {step}] 执行异常: {exc}) print(达到最大步数任务未完成) return False, history这段代码用了OpenAI兼容接口base_url指向本地的vLLM或Ollama服务你换成任何兼容接口都行。mark_elements会往页面上注入一个红色标签让模型看到元素的编号。执行动作之后循环回到顶部重新截图决策。3.4 实战效果自动完成一个带输入框、下拉框和按钮的表单我用一个本地HTML表单当作测试目标。页面很简单有一个姓名输入框、一个城市下拉框、一个提交按钮。给CUA下达任务“在姓名栏填入张三城市选择上海然后点击提交”。第一次跑这个任务时我已经做好它失败的准备了但实际结果比预期好。模型第一轮就锁定了E0是姓名输入框填入“张三”第二轮识别出城市下拉框并点击第三轮截图中出现了四个城市选项模型定位并点击了“上海”第五轮点击提交按钮页面出现提交成功提示模型输出了done。整体花了7步耗时约40秒。这个速度当然比不上写死的脚本但关键点在于整个过程没有一行针对这个表单的硬编码逻辑。我把任务描述换成“填一个随便的城市再提交”它也能自己调整操作。这就是CUA的核心价值。要注意的是我的原型里没有做严格的验证层模型判断“任务完成”仅凭截图中“提交成功”的文字。如果你的业务流程对正确性要求高建议在执行done之前增加一个独立验证提示词让模型对最终状态做二次确认。4. 实测中影响成败的参数与选型4.1 视觉大模型选型原生实测结论原型跑通以后我开始在不同模型之间对比测试。这里先说一句各家模型迭代速度很快我的实测结论只能代表当前版本的感受但选择模型时的判断维度是可以通用的。我测试了四个模型类别GPT-4o系列、Claude Sonnet系列、Qwen2.5-VL系列和GLM-4V。测试任务是同一套表单和多任务页面操作。模型UI理解指令遵循单步延迟实测感受GPT-4o很强强中等综合最稳偶尔有幻觉点击Claude Sonnet系列很强强中等对界面的语义理解最自然适合原生CUA思路Qwen2.5-VL-7B中等中低本地部署首选简单页面够用GLM-4V中等中中等表现中规中矩适合做备选我的建议是如果你想要快速验证业务场景直接上能力最强的云端模型。如果对数据隐私有要求希望在本地跑那Qwen2.5-VL-7B是目前性能够用、部署成本最低的选择之一。极小模型我劝你放弃了我用过一两款压缩版本的模型UI理解能力低到连输入框和按钮都分不清。4.2 两条技术路线纯视觉标注 vs 可访问性树原型阶段我用的方法叫“纯视觉元素标注”也就是往界面上注入标签让模型根据标签定位。这个方案在开发调试时很直观能看到模型眼中的世界但它在复杂页面上会漏掉一些元素而且标签块本身可能遮挡原界面。另一条路线是给模型提供可访问性树Accessibility Tree。可访问性树来自浏览器辅助功能模块它把页面上所有可交互元素用结构化的文本方式表示出来包含元素类型、名称、状态、层级关系。模型拿到这份树再结合截图就能精确理解界面。我实测下来纯文本的可访问性树有三个明显优势一是token消耗比截图低很多二是不会遮挡页面三是不存在像素坐标漂移问题。缺点则是部分动态绘制的界面尤其是Canvas渲染的应用可访问性树可能是空的必须退回纯视觉方案。生产环境里可以两个方案结合优先看可访问性树信息不足时再补充截图。我的原型里选择了纯视觉标注主要为了演示起来直观高效。4.3 提示词与温度把模型的“手”管住CUA的提示词设计和普通对话有本质区别。普通对话答案可以长篇大论CUA的提示词核心是“做减法”。我积累了三个原则。第一动作类型必须枚举。不给模型自由发挥的空间在提示词里明确列出所有可选动作并说明每个动作的用途。这能减少模型输出“分析文字”或者“自定义函数调用”的情况。第二元素引用必须基于截图所见。我反复在提示词里强调“只能操作截图里看到的元素不允许凭记忆猜测”。没有这句约束模型会经常幻觉出一个登录按钮来点击。第三单步只输出一个动作。很多模型具备规划多步的能力但在CUA场景里让模型一次规划十步反而容易在后半程偏离。让模型“看一步走一步”每一步都对当前屏幕负责稳定度明显更高。温度设置在0.2到0.4之间。温度太高会让动作分布产生随机性比如同一种情况模型有时候点击按钮A有时候点击按钮B温度太低又可能导致重复输出上一步的动作。0.2是我常用的起步值。4.4 截图质量和token成本之间的平衡CUA依赖视觉模型Token成本集中在截图序列上。一张1280x720的JPEG截图经视觉编码后通常消耗900到1500个Token。一个15步的任务仅截图就要消耗约2万Token再加上历史动作文本成本并不低。我常用的成本控制手段有三个。一是截图前固定浏览器窗口尺寸。我在代码里把窗口固定在1280x720这样截图尺寸稳定不会因为用户手动拖拽窗口导致画面比例变化模型的理解也能保持连贯。二是降低截图频率。对于页面跳转这种需要等待的场景不要连续截图而是先等待动作生效确认页面稳定后再截。三是限制历史动作的保存数量。模型不需要记住全部历史只需要最近3到5步就能保持上下文连贯再往前的内容可以压缩成一句摘要。这样能在长任务中显著降低Token消耗。5. 踩坑实录五类最常见的失败模式与修复思路5.1 卡死循环同一错误动作反复执行我在测试中遇到最多的问题是模型进入无限重试循环。现象非常典型模型对同一个错误位置连续点击了三次每一次reason都写着“需要聚焦输入框”但点击之后页面毫无响应然后模型还是重复同样的动作。排查时我翻开了历史日志发现问题的根源是模型只看到了“点击”这个动作被执行了但没有看到页面状态的因果变化。它没有意识到“这个位置根本点不中”于是机械地重试。修复思路是在决策循环里加入“连续相同动作检测”。记录最近3步的动作类型和目标元素如果完全相同就强制要求模型更换策略或者直接停止等待人工介入。我在系统提示词中加了一句话“如果同一个元素的同一个动作已经执行过两次且未改变页面状态必须换一种方式操作。”这一条把死循环问题的发生率压低了至少一半。5.2 幻觉点击模型操作了不存在的元素有一类问题我称之为“幻觉点击”模型基于先验知识猜页面上有某个元素但实际上根本没这个元素。一次测试中任务要求“登录后进入个人中心”。模型在登录页截图上自作聪明地标记了一个“登录按钮”但那个位置其实是背景装饰图案。点击后没有任何反应模型又尝试点击别处整个流程彻底跑偏。后来我仔细检查了一下发现原因是模型输出里的target并不是截图里真实注入的编号而是它自己想象的编号。为了堵住这个口子我在执行层加了一道校验target必须是截图时真实存在的元素编号否则直接报错并反馈给模型。这个校验让幻觉点击几乎绝迹。5.3 异步加载导致的状态漂移页面加载的异步特性是CUA最让人头疼的问题之一。点击一个按钮后页面往往会有一个loading过程比如重新渲染表格、加载接口数据。如果模型在页面还没稳定时截了图看到的就是残缺的中间状态决策自然就偏了。一次多步任务中模型点击“查询”后紧接着就截图并判断页面上某条数据出现了。但实际那次查询还没返回结果模型看到的只是上一页的残留状态。它基于错误状态执行了下一步整个后续流程全部错位。修复方法看起来很笨但非常有效在每个动作执行后固定等待800毫秒以上同时监听网络空闲状态截图前再主动等待页面关键字出现在界面上。宁可慢一点也不能让模型在错误的状态下做决策。后续我还把“wait”动作纳入了模型的可选项让模型自己判断是否需要在某一步多等一会儿。5.4 长任务中的上下文遗忘与累积错误任务步骤一旦超过15步模型会开始“忘记”最初的完整目标。我在测试一个包含填写、上传附件、切换标签页、提交、确认五个环节的任务时模型在第12步突然开始执行一个与任务无关的操作仿佛把任务目标搞丢了。我用的是历史动作文本最近5步截图的方式组织上下文早期历史被压缩后会丢失部分信息模型对“原始任务”的感知越来越弱。解决办法是在每一轮决策请求里都重复完整任务描述并且引入一个“checklist”机制把任务拆成子步骤每完成一步就在文本列表里标记为已完成。这样即使上下文窗口再长模型也能随时看到“任务目标”和“当前进度”两个核心信息不容易偏航。5.5 成本与限流失控CUA单任务调用的模型次数远高于普通聊天。以我的原型为例一个任务平均要调用8到12次模型接口每次还包含图片输入。如果不加控制一个简单任务也能在短时间内消耗大量配额甚至触发限流。我经历过一次这样的情况测试一个失败任务时模型在一个报错页面上反复尝试了15步最大值而每一步都携带高分辨率截图最终这个任务消耗了三倍于正常任务的Token还因为接口并发请求触发限流导致后续任务全部排队。从那以后我给所有CUA原型加了三道闸门。第一单任务最大步数默认15步超过后强制终止并输出“需要人工介入”的结论。第二单步最大Token数限制防止模型输出超长JSON。第三按天设置总体预算达到阈值自动暂停并要求人工复核。6. 从原型到真实产品安全、审计与评测不能省6.1 给“有手”的AI划定安全边界如果说普通AI助手的风险是“说错话”那CUA的风险就是“做错事”——它真的会操作你的电脑。安全设计不再是加分项而是上线前的强制要求。我建议无论如何都要做到以下几点。CUA运行环境必须和业务系统隔离最好是独立虚拟机或容器即使操作出错也不会影响核心数据。它能访问的域名或应用列表必须白名单化防止模型被恶意网页诱导进入危险站点。凡是涉及删除、提交订单、发送消息、支付之类的敏感操作必须增加人工确认环节模型只能“发起请求”而不能“直接执行”。还要留一个键盘急停快捷键发现模型行为异常时立即终止循环。老牌AI公司在发布类似功能时也反复强调过权限控制是最重要的一环。一个能自由操作计算机的Agent本质上相当于一个拥有系统用户权限的机器人你平时不会让自己的实习生裸奔式操作生产系统那就别让CUA这么做。6.2 审计回放每一步都要可追溯原型阶段模型操作出错了大不了重跑一遍。但生产环境里一次错误操作的后果可能是订单发错、数据写错、客户信息泄露。这时候如果没有审计能力连追责和恢复都会变得异常困难。我的做法是在每轮循环中把截图、模型返回的JSON、执行结果、页面状态变化全部记录成结构化日志并在任务结束后生成一个按时间排列的“操作轨迹”。排查问题时我可以像看录像一样逐帧回放模型当时看到了什么、做了什么决策、为什么这样决策、实际结果如何。这个回放机制还有一个额外价值就是能积累微调数据。每次人工介入后被修改的错误动作可以沉淀成一个训练样本。CUA模型越用越聪明靠的就是这套持续的日志积累和修正。6.3 用评测基准代替“好像能跑”自己做Demo的时候很容易陷入“有个任务跑通了就觉得很不错”的错觉。但真实业务里有大量边界情况页面弹窗、空状态、网络超时、文案变更每一个都可能让成功率断崖式下跌。现在学术界和工业界已经有一些公共评测基准比如WebArena、OSWorld这些覆盖浏览器和桌面操作场景的测试集。如果你想评估自己CUA系统的能力上限这些基准值得花时间跑一遍。不过公共基准只能作为参考业务场景差异很大。我更推荐自己在核心流程里抽取10个典型任务建成一个回归测试集。每次模型版本升级或代码改动后都跑一遍这套回归记录成功率、平均步数、平均耗时、单位成本四个指标。只有这套数据集上的指标变好了我才敢说系统真的有进步。6.4 务实的试点路线先做单屏高频流程很多人一看CUA的概念就立刻想做一个“全自动无人值守”的超级Agent。我劝你放弃这个想法至少第一版不要这么做。我的经验是CUA最适合切入的场景有三个特点流程业务在单屏或少数几个页面内完成、任务环节都是固定高频重复操作、流程允许在出错后人工修正。举个例子企业内部每天要填写的报表、客服后台的工单信息录入、电商后台的批量状态更新这些就是非常好的试点场景。先在小范围跑通两三个这样的流程把稳定性打磨到90%以上再慢慢向更开放、跨应用的场景扩展。CUA的落地本质上是一个从“可控”到“更复杂”的渐进过程跳级是很危险的。7. 几个立刻能用的调试小技巧最后分享几个我在实际调试中总结的小技巧不算系统性的方法论但每一个都帮我省过不少时间。第一打开浏览器自动化工具的慢动作模式。Playwright里可以设置slow_mo参数让每个操作执行得慢一点。调试时能看到模型动作和页面变化的过程比看冰冷的日志直观得多。第二固定浏览器视口尺寸。这个在前面提过但值得再强调视口不一致会导致截图比例变化、元素错位也会让模型在不同尺寸截图上表现不一致。把视口固定成1280x720少掉一半玄学问题。第三在提示词里加一条“如果上一个动作没有改变页面状态不要重复同样的动作”。这一句针对死循环问题的效果立竿见影。第四优先用headful模式调试headless留到稳定之后再切。headless模式省资源但发生诡异问题时排查效率极低你先能看得见才可能想明白。第五模型反复失败时先看截图不要急着换模型。我遇到过很多次“模型能力有问题”的误判结果发现是截图时页面玻璃拟态效果太重、背景和文字混在一起模型根本看不清边界。换一张清晰、干净的截图同一个模型立刻就能正确操作。第六把常用操作抽成工具不全都走模型调用。比如“点击按钮”“填写输入框”“按下回车”这些底层动作可以封装成稳定的工具函数让模型通过函数调用骨架来组合这些能力。这样既能降低模型的自由度也能显著提升执行稳定性。CUA离完美还远得很但它已经从实验室玩具变成了一个真正值得投入的方向。这套最小原型只是起点后面还有长任务规划、多应用协同、安全护栏、模型微调这些硬骨头要啃。我自己也在一步步摸索如果你也在做类似的东西希望这篇文章里那些踩过的坑能帮你少走几条弯路。