★ FEATURED ARTICLE 1. 从一条热搜说起AI助手替人干活这件事到底走到哪一步了最近技术圈里讨论度很高的一件事就是一类能直接操作电脑的AI助手开始大规模出圈。它和过去那种只会聊天的对话机器人完全不是一回事——你给它一个目标它会自己打开浏览器、点击按钮、填写表单、切换窗口、读取屏幕内容像一个坐在电脑前的真人一样把活干完。这类东西被叫做“数字员工”或者“电脑操作型智能体”核心能力就是接管图形界面代替人完成重复性的桌面操作。我最早接触这类工具是在做数据采集和流程自动化的场景里当时用的还是基于脚本的方案维护成本高得离谱页面一改版就得重写。后来这类视觉加推理的智能体出来之后我花了不少时间实测发现它确实能把“写脚本”这件事的门槛降下来一大截。你不需要知道元素选择器怎么写只要用自然语言描述任务它自己看屏幕、自己判断下一步点哪里。这篇文章我想聊的不是某一个具体产品的使用教程而是围绕“AI助手替人干活”这个方向把背后的技术逻辑、算力消耗机制、实际落地时的坑以及为什么这类应用会带动底层算力需求完整地拆一遍。适合两类人看一类是想把这类工具用到自己工作流里的实操派另一类是关心AI应用和算力之间传导关系的观察者。不管你是哪种我都会尽量把“为什么”讲清楚而不是只丢结论。2. 这类AI助手到底是怎么“看见屏幕、动手操作”的2.1 从“对话”到“操作”能力边界的一次跃迁传统对话式AI的输入是文字输出也是文字它的世界是一个纯文本的封闭空间。而操作型智能体的输入变成了屏幕截图或者可访问性树输出变成了鼠标坐标、键盘事件、点击动作。这个转变看起来只是换了个输入输出格式实际上对模型能力的要求完全不一样了。对话模型答错一句话用户重新问一遍就行。但操作型智能体点错一个按钮可能就把一封邮件发给了错误的人或者把一笔订单提交了。所以它对“理解当前界面状态”和“预测动作后果”的要求高得多。我实测下来一个成熟的操作型智能体通常要同时具备几种能力视觉理解看懂截图里有什么、空间定位知道按钮在哪个坐标、任务规划把大目标拆成小步骤、状态记忆记住上一步做了什么、异常恢复点错了能退回来。这几种能力里视觉理解和空间定位是最吃算力的。因为每一轮操作都要重新截屏、重新推理而不是像对话那样一次生成一大段文字就完事。2.2 屏幕理解的技术路线截图推理 vs 结构化解析目前主流有两条路线。一条是纯视觉路线直接把屏幕截图丢给多模态模型让模型输出下一步该点哪里。另一条是结构化路线读取界面的可访问性树或者DOM结构把界面元素解析成结构化数据再喂给模型。纯视觉路线的好处是通用性强不管什么软件、什么系统只要能截屏就能操作不依赖软件本身是否暴露了接口。坏处是算力消耗大因为图像token比文本token贵得多。一张1080P的截图经过分块和编码之后可能产生上千个视觉token而一段描述同样界面的文本可能只要一两百个token。结构化路线的好处是省算力、定位准坏处是很多老旧软件、游戏、远程桌面场景根本不暴露结构信息这时候就抓瞎了。我实际用下来比较稳的方案是混合优先读结构读不到再退回视觉。这样在大多数办公软件场景里能把算力消耗压下来只在必要的时候才动用视觉推理。2.3 动作空间设计为什么“点哪里”比“说什么”难得多对话模型的动作空间是词表几万个token里选一个。操作型智能体的动作空间是屏幕上的像素坐标理论上有一百多万个可能的位置。这个搜索空间大了好几个数量级。所以实际操作型智能体不会直接输出原始坐标而是先做一层抽象。常见做法是把屏幕划分成网格或者先检测出可交互元素按钮、输入框、链接然后让模型在这些候选元素里做选择。这样一来动作空间就从“百万级像素”缩小到了“几十个候选元素”推理难度和算力消耗都大幅下降。但这里有个坑候选元素检测本身也会出错。我遇到过好几次某个按钮因为颜色和背景接近检测模型没识别出来智能体就卡在那里反复截屏、反复推理token消耗直接飙升。所以一个健壮的系统必须有“卡住检测”机制连续几轮动作没进展就主动换策略或者报错退出而不是无限循环烧算力。3. 算力消耗到底花在哪里一次任务背后的token账本3.1 单步操作的算力拆解很多人以为操作型智能体的算力消耗主要在“生成动作”那一下其实大头在“理解当前状态”。我拿一个典型的网页表单填写任务做过粗略统计单步操作的算力分布大概是这样的环节算力占比说明屏幕截图与编码约35%图像转视觉token分辨率越高越贵界面元素检测约20%定位可交互区域可用轻量模型分担状态推理与规划约30%大模型判断当前该做什么动作生成与执行约10%输出坐标和事件本身很轻结果校验约5%确认上一步是否生效可以看到和“看”相关的环节加起来占了超过一半。这就解释了为什么操作型智能体比纯对话应用费算力——它每一轮都要重新“看”一遍世界。3.2 多轮循环带来的乘数效应对话应用通常一轮就结束用户问一句答一句。操作型智能体完成一个任务往往要几十步甚至上百步。每一步都要截屏、推理、执行、再截屏确认。假设单步消耗500个token一个50步的任务就是25000个token。如果任务中途遇到弹窗、加载延迟、元素错位步数还会翻倍。我实测过一个自动整理文件的任务把一批图片按内容分类到不同文件夹。听起来简单但因为要逐个打开预览、判断内容、拖动文件实际跑了将近80步。如果换成人工可能五分钟就干完了但智能体花了更长时间而且消耗的算力折算成成本比人工时薪还高。所以现阶段这类工具适合的是“高频、规则明确、人工做起来很烦”的任务而不是“低频、复杂、需要创造力”的任务。3.3 为什么说“大量消耗token”会传导到算力需求这里就是标题里提到的传导逻辑。操作型智能体的普及意味着AI从“偶尔问一句”变成了“持续干活”。一个数字员工一天工作8小时可能产生几十万甚至上百万token的消耗相当于几百个普通对话用户。当这种应用规模化之后对底层推理算力的需求是指数级上升的。而且这种需求有个特点它是持续性的、可预测的。对话应用的流量波动很大白天多晚上少。但数字员工是7×24小时干活的算力需求曲线更平稳对算力供应商来说这种负载更友好利用率更高。这也是为什么这类应用被看作算力需求的重要增量来源。4. 实际部署时怎么把算力成本压下来4.1 模型分层不是所有步骤都要用大模型我踩过最大的坑就是一开始所有步骤都调最大的模型结果成本高得吓人。后来改成分层架构成本直接降了六成以上。具体做法是简单的界面元素检测用轻量视觉模型甚至可以用传统CV方法状态判断和任务规划用中等规模模型只有在遇到复杂决策、异常恢复的时候才调用大模型。这样大部分步骤走的是便宜通道只有少数关键步骤走贵通道。提示分层的关键是设计好“升级条件”。比如连续两轮动作没有进展、或者检测到未知弹窗就自动升级到大模型处理。条件设得太松会频繁调用大模型设得太紧又容易卡死。4.2 缓存与复用相同界面不要重复推理很多任务会在相似的界面之间来回切换。比如批量处理订单每个订单的页面结构几乎一样只是数据不同。这种情况下可以把界面特征缓存下来下次遇到相似界面直接复用之前的动作策略跳过推理环节。我做过一个批量录入的任务用缓存之后从第二步开始每步的token消耗降到了第一步的十分之一。因为第一步已经识别出了“这个界面的提交按钮在右下角”后续只要数据变了动作位置不变就不需要重新推理。4.3 分辨率与截屏策略的取舍截屏分辨率直接影响视觉token数量。4K截屏的token量大概是1080P的四倍但实际任务里很多细节并不需要那么高的分辨率。我的经验是先用低分辨率做整体判断定位到大致区域后再对局部做高分辨率截取。这样既保证了精度又控制了token总量。另外截屏频率也可以优化。不是每一步都要全屏截取有时候只需要截取变化区域。比如填写表单时焦点在输入框里只需要截取输入框附近区域确认输入是否成功不需要每次都截全屏。5. 落地过程中最容易踩的五个坑5.1 坑一把智能体当成万能脚本新手最容易犯的错是觉得有了智能体就不用写任何自动化逻辑了什么任务都丢给它自己摸索。结果就是简单任务被复杂化本来三行脚本能搞定的事智能体跑了三十步还没完成。我的建议是确定性的、规则清晰的步骤用脚本不确定的、需要判断的步骤才交给智能体。两者结合效率和成本都最优。比如打开软件、登录账号这种固定动作脚本几秒钟搞定没必要让智能体去“看”和“想”。5.2 坑二忽略异常处理导致无限循环前面提过智能体卡住之后如果没人管会一直截屏推理token哗哗地烧。我见过最夸张的一次一个弹窗没被识别出来智能体在弹窗后面反复点击跑了两个小时消耗了几十万token。所以部署的时候一定要设“最大步数”和“无进展退出”机制。超过步数上限或者连续N步动作结果没变化就强制终止并报警。这个机制看起来简单但能省下大量冤枉钱。5.3 坑三界面变化导致策略失效软件更新、网页改版、系统主题变化都可能让之前调好的策略失效。我遇到过系统自动更新后按钮位置偏移了十几个像素智能体就找不到按钮了。所以生产环境里要么锁定软件版本要么定期做回归测试确认关键任务的策略还有效。5.4 坑四权限给得太大数字员工要操作电脑就得有相应的权限。但权限给太大风险很高万一它误操作删了重要文件或者发了不该发的消息后果严重。我的做法是最小权限原则只给它完成任务必需的权限敏感操作加人工确认环节关键步骤留操作日志。5.5 坑五只看单次成本不看整体收益算力成本高不高不能只看单次任务花了多少token要看它替代了多少人工、减少了多少错误。有些任务单次算力成本不低但因为它能7×24小时干活、不会疲劳、不会情绪化整体算下来还是划算的。反过来有些任务看起来省了算力但错误率高、返工多综合成本反而更高。常见坑表现应对策略万能脚本思维简单任务复杂化脚本与智能体分工无异常退出无限循环烧token设步数上限和无进展检测界面变化策略突然失效锁版本加定期回归权限过大误操作风险最小权限加人工确认只看单次成本忽略综合收益算整体投入产出比6. 这类应用对算力市场意味着什么6.1 从“偶尔用”到“持续用”的需求质变对话式AI的算力需求是脉冲式的用户想起来才用一下。数字员工的需求是持续式的只要任务在跑算力就在消耗。这个转变对算力市场的影响是结构性的——它把AI算力从“可选消费”变成了“生产性投入”。生产性投入的特点是只要产出大于投入需求就会持续增长。企业算一笔账雇一个数字员工的算力成本如果低于雇一个真人的成本而且还能24小时干活那就有动力持续投入。这种经济账一旦算通需求增长会非常快。6.2 推理算力与训练算力的比例变化过去几年算力市场的大头在训练各家都在堆大模型。但随着应用侧铺开推理算力的占比在快速上升。操作型智能体是推理算力的重度消费者因为它每一步都要推理而且步数多、循环多。这个趋势对算力基础设施的要求也不一样。训练任务可以容忍一定的延迟跑几天几夜都行。但推理任务对延迟敏感用户等着智能体干活不能等太久。所以推理算力更看重响应速度和稳定性对机房的位置、网络条件、散热都有不同要求。6.3 算力消耗的“长尾效应”还有一个容易被忽略的点操作型智能体的任务种类极其繁多长尾效应明显。有的任务消耗大有的任务消耗小但加起来总量惊人。而且随着用的人越来越多任务种类会越来越丰富算力需求的长尾会越来越长。这种长尾需求对算力供应商来说既是机会也是挑战。机会在于需求总量大且持续挑战在于需求波动和分布难以精确预测需要更灵活的调度能力。7. 我个人的一些实操体会折腾这类工具这段时间最大的感受是它确实能干活但离“开箱即用”还有距离。你得花时间调策略、设边界、做监控才能让它稳定跑起来。那些宣传里说的“一句话就让AI帮你干完所有事”目前还只是理想状态。另一个体会是算力成本是这类应用能不能规模化的关键变量。我见过不少团队技术方案很漂亮但一算算力账就发现跑不起。所以做这类项目从一开始就要把成本模型建起来每一步消耗多少、一天跑多少任务、一个月花多少钱心里要有数。最后分享一个小技巧如果你刚开始尝试别一上来就搞复杂任务。先从一个步骤少、界面稳定、容错率高的任务入手比如定时截图保存、批量重命名文件这种。跑通了、摸清了它的脾气再逐步加复杂度。这样踩的坑少信心也建立得快。至于这类应用后续会怎么演进我觉得方向是更省算力、更稳、更懂上下文。现在很多团队在做的模型压缩、缓存复用、分层推理都是在往这个方向走。等这些技术成熟了数字员工的成本会进一步下降到时候能干的活就更多了。
阅读完成 · 觉得有帮助？
