最近AI圈里最热闹的方向已经从让模型会说话变成了让模型会干活。Gemini 2.5 计算机使用模型登场之后我身边不少做自动化和Agent的开发者都在讨论这件事但说实话模型发布是一回事真正理解计算机使用模型是什么、能干什么、怎么接进自己的项目是另一回事。我最近把这套东西从头到尾过了一遍翻了官方技术说明、跑了几组典型任务、又拿它和RPA、UI自动化测试这些老方案做了对比踩了些坑也算理清了思路。这篇文章不打算复读公告我就把实际接触下来的理解写清楚重点回答四个问题它到底怎么工作、实测下来哪里强哪里弱、和现有自动化工具什么关系、真要落地需要准备什么。适合正在做AI Agent、自动化工具或者单纯好奇AI能不能替我操作电脑的开发者来读。1. 先弄明白计算机使用模型和普通大模型的本质区别1.1 输出不再是文字而是一串操作指令很多人的第一个误区是把AI操作电脑理解成AI生成一段文字然后由某个插件去执行。并不是这样。计算机使用模型是一个多模态大模型它输入的是屏幕截图加任务描述输出的是结构化的动作序列不是自然语言。举个直观的例子。你让普通聊天助手帮我打开设置里的网络页面并截图它只能回你一段文字告诉你怎么点或者最多写一段Python代码。而计算机使用模型直接输出类似这样的动作move_mouse(x820, y450)把鼠标移动到屏幕某个位置click_mouse(buttonLEFT)按下左键type_text(192.168.1.1)在输入框里打字press_key(keyENTER)回车提交wait(ms1200)等待页面加载done宣布任务完成这些动作不是自由文本而是模型在固定动作空间里的选择。搞清楚这一点很重要模型的职责非常明确它负责根据当前屏幕内容决定下一步该做什么至于谁去执行这些动作、怎么截屏、怎么把结果喂回去是开发者自己需要搭建的框架。它不是开箱即用的完整Agent而是一个会看会想但不会自己动手的决策引擎。1.2 为什么会看屏幕这件事本身就很难要理解这类模型的难度得先想清楚一个反直觉的事实图形界面是给人看的不是给程序用的。网页背后有DOM结构原生应用有控件树但在屏幕截图这个层面所有结构化信息都消失了只剩下像素。这就像让一个从没见过你们公司管理系统的人通过一张屏幕照片来帮你操作电脑。他需要同时做到四件事认出哪些是按钮、哪些是输入框、哪些只是装饰性文字判断当前界面处于什么状态弹窗、加载中、报错从一堆看起来差不多的确定按钮里选对那一个记住任务目标在多步操作中不被带偏。对模型来说第一、二、四点其实是多模态理解领域的老问题真正难的是第三点像素级定位。同一个按钮在1920×1080的屏幕上和1280×720的屏幕上坐标完全不同窗口被拖动过、页面滚动过坐标又变了。所以模型必须把看到的内容和当前画面尺寸结合起来推算坐标任何一边含糊点错位置的概率就会上升。这也是为什么实测里最常见的翻车方式不是看不懂界面而是看懂了但点歪了。1.3 哪些场景真能用哪些场景别硬上基于我自己跑下来的感受这类模型最适合的场景有这么几类老系统改造一堆跑了好多年的内部管理系统没有API改造成本极高。让模型直接看屏幕操作等于给老系统加了一个外挂的眼睛和手不动底层也能实现自动化。跨应用流程从A应用复制数据、切到B应用粘贴、再回A应用确认结果这种流程用RPA脚本写起来很繁琐用自然语言描述反而简单。界面不稳定的自动化前端隔三差五改版选择器天天失效像素级操作对界面变化没那么敏感改版后通常还能继续用。探索式测试让人工测试员随便点点看有没有bug的工作很难预先写脚本但很适合让模型去执行给它一个目标它就能自主乱逛。至于不适合的首当其冲是高频、超高确定性的任务。一个每天跑几千次的固定流程用脚本是毫秒级、零成本用模型是秒级、每次都烧token。其次是任何对延迟敏感的实时操作以及监管严格、每一步都必须有完整审计链路的场景。这两个边界想清楚后面选型才不会走偏。2. 拆开工作链路看从截屏到动作的完整闭环2.1 输入侧整块屏幕的像素而不是DOM结构计算机使用模型和市面上其他浏览器AI助手最大的不同在于它的输入是完整屏幕画面而不是网页源码。整套系统的工作逻辑是这样的配置好一个受控的浏览器环境并让配套的浏览器扩展处于激活状态系统按固定频率截取当前屏幕把截图作为视觉输入喂给模型模型理解画面内容产生下一个动作执行动作后系统再次截屏把新画面喂回去循环往复直到模型输出done。这里固定频率是个容易被忽略的工程细节。整个交互是流式的模型和屏幕之间维持着一个持续循环而不是每步重新发一次推理请求。好处是模型可以捕捉到异步加载的页面变化——比如查询结果慢慢渲染出来它能看到这个过程坏处是如果程序没在动作序列里加入合适的wait等待模型可能在一个动画还没播完的画面上做出错误判断。第二个必须留意的细节是分辨率。模型输出的动作坐标是和输入截图的分辨率一一对应的。如果你的电脑是4K屏开了缩放截图尺寸和物理像素并不是1:1动作坐标就需要换算。初期最容易翻车的坑就出在这截图尺寸设置错了所有点击位置整体偏移表现就是模型明明看懂了界面却一直点到空白处。踩过一次之后我的习惯是固定浏览器窗口大小、关掉系统界面缩放让截图和坐标始终处于同一套坐标系里。2.2 动作侧点击、输入、滚动、快捷键的全家桶模型的动作空间基本覆盖了一个人操作电脑需要的绝大多数动作整理成表格会更直观动作类型含义典型使用场景move_mouse移动鼠标到指定坐标悬停查看提示、准备点击click_mouse单击/双击/右键点击按钮、勾选复选框type_text连续输入一段文本填写表单、写代码press_key按键盘按键或组合键CtrlC复制、Enter提交scroll滚动窗口或元素翻阅长列表、加载更多wait等待一段时间页面加载、动画结束done结束任务任务完成输出总结这里想特别说一下type_text。很多失败的案例都不是打错字而是焦点不对模型以为光标在输入框A里实际上在B里于是一整段文本打到了错误的地方。这事的根因在于模型对当前焦点在哪里的感知是从截图里推断出来的而不是像浏览器扩展那样能直接读到。所以一个稳妥的写法是在打字之前先点击一次目标输入框确认焦点正确再执行type_text成功率会明显提升。另一个值得留意的动作是快捷键。跨应用流程里AltTab切换窗口、CtrlS保存这些动作效率远高于逐个点击按钮但模型对当前窗口是否激活焦点在哪个元素上的感知是滞后的。我的经验是遇到组合键场景先让它点击目标窗口的标题栏区域把窗口激活再发快捷键这一套下来成功率会高一大截。2.3 反馈侧每一小步之后都要重新睁眼这套链路里最核心的设计是动作—观察—再动作的闭环。模型不会依赖上一次的屏幕记忆去推下一步而是每次执行完动作后重新读取最新的屏幕截图再基于新画面做判断。这个设计和人类操作电脑的方式不太一样但恰恰是它的稳健性来源。第一它对意外弹窗的恢复能力比想象中强。比如任务进行到一半系统突然弹出一个更新提示如果模型能看到这个弹窗它就会在下一步动作里处理它而不是稀里糊涂继续原来的流程。第二代价是每次动作都有固定的推理延迟。我粗算了一下一个包含20个动作的中型任务每步平均1.5秒到3秒整个任务跑下来可能要一分钟这还没算页面加载时间。对比RPA脚本毫秒级的执行速度这个差距是数量级的。所以这里要提前给读者打个预防针用AI操作电脑从来不是要取代脚本它补的是脚本搞不定的那部分场景。理解了这个闭环后面所有工程问题都能顺着它推理出来。3. 三组实测任务的复盘强项、弱项和翻车现场3.1 表单录入类成功率最高的一类先跑的是一个很常规的内部模拟项目打开一个查询页面在筛选框里输入三个条件点击查询然后从结果列表里下载第一行的附件。这类任务模型完成得相当稳。输入框识别准确、打字没有错漏、按钮点击基本一次到位。中间有一小段翻车查询结果出来前有个约两秒的loading动画模型在动画没结束时就点了下载按钮结果点到的是上一页残留位置的空区域。后来我在指令里加了一句点击后等待页面加载完成再继续同一个任务连续跑五次全部通过。这个案例给我最大的启发是模型本身的能力是一方面怎么指挥它又是一方面。就像带一个很聪明但没什么经验的新人干活你要明确告诉它等加载完再动它就能表现得非常可靠。这类模型对自然语言指令的执行度高得惊人指令里多一句约束成功率立竿见影。所以写任务提示词的时候别怕啰嗦把那些人觉得不言自明的步骤也交代清楚。3.2 跨应用操作类能跑通但环境要求苛刻第二组任务跨了两个应用从本地表格软件里取出几行数据拼成一段格式化的文字粘贴到浏览器的在线编辑器里再保存并截图。跑的结果是能完成但毛刺很多。最大的问题出现在窗口切换模型准备切换到浏览器时它知道要点击浏览器的窗口但由于截屏里同时出现了两个应用窗口它的点击坐标偶尔会落在窗口边缘触发的是窗口缩放而非切换。后来我把两个窗口错开摆放、让目标窗口完整可见又把切换动作拆成点击窗口标题栏、等待、再执行粘贴任务就稳定了。这个翻车点其实很有代表性。计算机使用模型对屏幕上有什么理解得很清楚但对窗口层级、焦点、遮挡关系这类信息只能靠猜。所以跨应用任务有一个黄金法则尽量让当前需要的窗口完整、无遮挡地出现在屏幕中央。屏幕越干净模型越不容易出错。对于生产环境这意味着你需要一个专门用于跑任务的桌面环境而不是在共享的开发机上随意调度。3.3 长流程自主规划类规划能力在但纪律性不够第三组是最接近Agent形态的任务在几个商品页面里比价、筛选符合条件的选项、整理成对比表输出。模型在理解目标、拆解步骤上表现不错它自己规划出了逐个打开页面、提取价格、比对条件、生成表格的路径中间还主动滚动页面看了好几屏内容。但跑长流程时暴露了一个问题偶发自我感动式完成。任务要求筛选价格低于某个阈值且库存有货的选项模型在某些页面上漏看了缺货角标自己判断这个可以导致最终表格里混入了一项不合格数据。这类失误在长流程里很难完全避免因为每步推理都是基于当前截图的局部判断全局目标虽然在提示词里但模型走神的概率会随步骤数量积累。我的应对办法也是我建议所有做Agent的团队采纳的办法把长任务拆成多个短任务每个短任务结束后让另一轮独立推理或人工检查一下结果再进入下一段。宁可多几次调用也不要让错误滚雪球滚到最终输出里。4. 和RPA、UI自动化测试怎么共存而不是互相取代4.1 核心差异选择器逻辑和像素逻辑的碰撞决定在项目里引入计算机使用模型之前最好先搞清楚它和现有自动化方案的边界。传统RPA和UI自动化测试的核心是选择器通过DOM的id、XPath、CSS选择器或者录制好的控件坐标来定位元素。这套逻辑的前提是界面可控、结构可知。计算机使用模型走的是完全不同的路线像素逻辑。它不看DOM不看控件树只看截图。这带来一个很有意思的转变——从前端开发的角度看按钮的视觉样式是否规范不再重要重要的是按钮在屏幕的哪个位置、长得是否像按钮。UI怎么改版只要视觉上还是那个按钮模型就能认出来。说句玩笑话平时大家吐槽设计师乱改样式在像素逻辑下反而成了加分项界面越有辨识度模型越容易认。4.2 一个对比表看清各自性格维度RPA / 自动化脚本计算机使用模型开发成本写脚本、维护选择器成本较高写自然语言指令几乎零代码稳定性界面不变时极高有概率漂移需要重试机制执行速度毫秒级秒级每步1~3秒界面变化适应力差选择器失效就得改强视觉层面变化影响较小出错可解释性高日志完整中需要配合截图审计适用场景高频、固定、大量重复低频、复杂、多变化这张表不是要分高下。真实项目里的最优解恰恰是把两者混着用。我见过一些团队一开始抱着用AI全面替代RPA的心态结果在成本和稳定性上双双碰壁最后都回到了混合思路上来。替代论在这个领域是个危险的想法正确的姿势是给不同性格的工具安排不同的岗位。4.3 我建议的混合架构模型探路脚本固化我自己在实践中比较推崇的做法可以总结成八个字模型探路脚本固化。先用计算机使用模型跑通一个新流程确认步骤和界面状态把高频、稳定的核心步骤沉淀成RPA脚本或自动化测试用例让速度和成本跟上来只把界面常变、难以写选择器、偶尔才跑的边角步骤留给模型兜底。打个比方RPA像高铁固定线路、准时、运量大计算机使用模型像打车灵活、能去任何地方但每次都要重新规划。成熟的做法不是二选一而是主干用高铁、末梢用打车。这样组合下来高频任务跑得快、跑得便宜低频复杂任务又能做到什么界面都能接住两边的优势都保住了。5. 工程化接入的落地要点环境、参数、成本5.1 最简接入方式一个会话一个循环官方推荐的接入方式是Python SDK加实时会话模型名对应计算机使用预览版。核心代码结构大概是下面这个样子import asyncio from google import genai from google.genai import types async def run_computer_task(task: str): client genai.Client(http_options{api_version: v1alpha}) config types.LiveConnectConfig( response_modalities[MODALITY_AUDIO, MODALITY_VIDEO], system_instructiontypes.Content( parts[types.Part(text你是计算机操作助手按用户指令操作电脑。每一步先观察屏幕再决定动作。)] ) ) async with client.aio.live.connect( modelgemini-2.5-computer-use-preview, configconfig, ) as session: await session.send(inputtask) while True: response await session.receive() if response.server_content: # 模型给出的动作建议由本地浏览器扩展执行 suggestions response.server_content.suggestions results execute_in_browser(suggestions) # 把执行结果含最新截图回传给模型 await session.send(inputresults) if response.tool_call: # 浏览器扩展回传的动作执行反馈 await session.send(inputresponse.tool_call.function_response)这是一段示意性的骨架代码具体SDK版本和参数名后续会变动接入时以官方文档为准。我想强调的是那个循环本身模型不主动做任何事它只产生suggestions真正的执行者是浏览器扩展。你写的代码负责把suggestions翻译成真实的鼠标键盘事件再把新截图送回给模型。所有工程上的问题——重试、超时、并发——都能顺着这个循环去定位。5.2 环境配置里最容易出问题的地方我踩过、也见过别人反复踩的环境坑集中有这么几个分辨率不一致截图尺寸必须和模型输入一致否则坐标必然偏移。固定浏览器窗口大小、关掉系统的界面缩放是最省事的做法。多显示器模型看到的是主屏鼠标却有可能跑到副屏动作就全乱了。做自动化任务的机器老老实实单屏。屏保和锁屏长任务跑到一半锁屏直接前功尽弃。服务器环境用虚拟显示器本机跑就把电源设置里的睡眠和屏保全部关掉。剪贴板权限复制粘贴类动作依赖系统剪贴板在容器环境里要确保剪贴板服务可用否则type_text会莫名变成乱码。另外强烈建议用独立的浏览器配置文件跑任务别用你日常登录着各种账号的那个。一方面是为了不污染自己的数据另一方面是避免模型误操作你的真实账号。这属于花几分钟能省掉一晚上麻烦的事。5.3 成本账按每步算而不是按任务算很多人估算成本时会犯一个错以为一个任务就是一次API调用。实际上一个20步的任务是20次以上的推理循环每一步都带着一张新截图。成本的大头在图像输入不在文字。所以有几笔账要心里有数单步延迟1~3秒20步任务约1分钟总时长这是交互层面的物理约束优化空间有限截图分辨率越高token消耗越大但过低的截图又会影响定位精度。1280×720到1920×1080之间是个比较经济的区间具体值要拿真实任务压测并发多个会话成本线性增长团队做验证时建议先用小流量压测把单任务成本跑出来再谈规模。提示做POC时先选一个最典型的流程跑20遍统计成功率和平均步数。这两个数字直接决定这个场景值不值得上生产。成功率低于八成先别急着优化成本成本是后话。6. 让模型碰电脑之前先把安全和合规想清楚6.1 权限边界给它一个玩具账号操作真实电脑的AI权限边界怎么强调都不过分。哪怕官方已经做了不少安全设计比如对高风险动作要求人工确认你作为集成方也有责任把风险面缩到最小。我推荐的最低配置是在独立虚拟机或容器里运行和你的生产环境物理隔离使用权限受限的测试账号不开放管理员权限在系统层面禁止它访问文件系统敏感目录、支付类网站、邮箱等高风险目标所有外部动作发消息、提交订单、删除文件默认拦截走人工审批。这些说起来都是常识但我实际接触过的项目里不止一个团队把模型直接跑在开发人员的日常机器上连着公司内网和私人邮箱。这不是技术问题是流程问题。权限边界设计得再严格也架不住一开始就把工具放错了环境。6.2 数据暴露风险每一帧截图都在往外传计算机使用模型的工作原理决定了屏幕上显示的所有内容都会作为输入传给模型服务方。这意味着三件事要提前想清楚不要在自动化任务里处理含个人隐私、商业机密的数据除非你确认数据合规边界允许界面上的敏感字段能打码的先打码或者用遮挡层遮住再让模型看如果组织对数据留存有严格要求需要先确认模型服务商的数据处理条款是否满足内部合规要求。这个问题容易被技术团队忽略因为截图传给模型对做技术的人来说太自然了。但放到合规视角这就是未经许可把内部信息发给了外部服务。正式的商业项目建议把这个检查项写进上线清单和代码评审并列。6.3 人工确认机制该沉的成本不能省最后聊一下人工确认。很多人觉得加人工确认会拖慢自动化显得不够AI。但我的判断是计算机使用模型的正确用法恰恰是人机协同而不是全自动。具体设计上有两个粒度可以选动作级确认每个高风险动作点击支付、发送消息、删除文件执行前让模型先暂停把人放进决策环阶段级确认把一个长任务切成几个阶段每完成一个阶段人工看一下结果截图点头放行。阶段级确认的效率高得多也足够覆盖大多数真实场景。配合上完整审计日志——记录每一步的输入截图、模型输出动作、实际执行结果——出了问题能追溯这才是生产环境该有的样子。我在实际跑任务时发现一个规律凡是过程可审计、结果可回滚的自动化团队用得越来越放心凡是一股脑全自动的最后大概率会被业务方叫停。安全不是限制是让这类工具能长期用下去的前提。最后分享一个我在反复测试里总结的小技巧给模型的任务描述尽量用操作视角而不是结果视角说话。比如点击页面右上角的下载图标等文件出现在左下角下载栏后再继续就比帮我下载最新报表好用得多。模型对每步做什么的执行力远强于对抽象目标的领悟力你把路径掰碎了告诉它它就能稳定地替你干活。就我个人感受Gemini 2.5 计算机使用模型把AI自己操作电脑这件事从demo推进到了真正可以评估、接入、上线的阶段但它仍然是一个需要被严密看管的工具。想清楚边界、设计好流程再上它能让很多原本高成本的老场景一下子活过来反过来跳过安全设计直接丢进生产它也能让你一夜之间多出很多需要擦的屁股。