1. 先拆掉那层聊天框套壳再谈 AI 助手这年头市面上叫AI 助手的东西很多但绝大多数你点进去本质还是一个聊天框。你问一句它答一句顶多再帮你调几个 API、查个天气、生成张图片然后就没有然后了。这样的产品我习惯叫它聊天框套壳——底层塞一个大语言模型外面包一层 UI对话体验再顺滑也改变不了一个事实它只有一张嘴没有眼睛也没有手。所以当我看到多模态视觉 云端真机实操这个方向时第一反应是这才是 AI 助手该走的路。这件事的核心不是让 AI 变得更会聊天而是让它真正看懂你屏幕上的内容并且代替你在真实的 App 里把事办完。我理解中的这条新路径就是把感知能力多模态视觉和执行能力云端真机实操拼在一起构成一个完整的闭环看见界面、理解任务、动手操作、确认结果。这篇文章我想把它掰开揉碎讲清楚——它到底解决什么问题、技术链路怎么设计、落地时有哪些坑以及为什么说它不是简单的套壳升级。如果你在做 AI 应用产品、Agent 类工具或者你只是一个对AI 到底能不能帮我把事办了感兴趣的人这篇内容都值得看完。我会把我自己踩过的坑、验证过的做法毫无保留地写出来。2. 为什么会聊天解决不了真实问题2.1 套壳产品缺的是眼睛和手先明确一个前提大语言模型本身的强项是文本理解与生成。你给它一段话它给你一段话这在信息获取、文案撰写、头脑风暴这类场景里已经很好用了。但现实世界的任务绝大多数不是说出来的而是做出来的。比如帮用户把手机里的照片整理成相册、在某个购物 App 里完成下单、把后台系统的表单逐项填写并提交——这些操作都有着强烈的空间属性和界面属性你要知道按钮在哪里、输入框在哪里、当前页面处于什么状态然后才能执行点击、输入、滑动。这些信息纯文本根本承载不了。你可能会说那我们可以让模型调用 API 啊对接业务系统不就行了这句话看起来有道理但落到现实就尴尬了。API 本质上是系统预先开放给你的一段入口你只能在它允许的范围内操作。一个外卖 App 如果不给你开放自动下单的接口你的 AI 助手就算再聪明也没法替用户点餐。而真机实操走的是另一条路我不需要你开放接口我像人一样通过屏幕看到按钮、模拟点击绕过接口限制直接在界面层完成任务。这就是眼睛和手的价值——也是它和套壳产品的第一道分水岭。2.2 没有执行闭环一切都是建议聊天框套壳的另一个问题是它永远停在建议层。你说帮我处理一下这个表格它只能回你你可以打开 Excel选中数据点击排序……但真正把表格处理完的是谁是你自己。AI 没有参与到操作过程中它既不知道你屏幕上的表格长什么样也无法验证自己说的步骤是否执行成功。说白了它就是个只会纸上谈兵的军师发号施令却从不上战场。而多模态视觉 云端真机实操要做的恰恰是把军师变成士兵。AI 通过屏幕截图理解当前状态然后直接输出操作动作真实地点击、输入、滑动执行完再截图反馈给模型让它确认这一步是否达到预期。整个过程形成循环感知 → 决策 → 执行 → 校验 → 重新感知。这个闭环一旦建立AI 才真正从给建议的人变成了办事的人。我自己在测试这类方案时第一次看到 AI 自己去点击搜索框、输入关键词、按下搜索按钮并且真的跳出了结果页时那种冲击感其实很强——它不再只是一个对话框而是一个能动手的智能体在替你把事情走完了。3. 多模态视觉不是看图说话而是看懂界面3.1 从识别像素到理解布局很多人一听到多模态视觉就想到AI 能识别图片里有没有猫或者AI 能描述一张风景图。这些确实属于多模态的范畴但放到AI 助手实操场景里视觉要做的事情要复杂得多。它需要回答四个层面的问题第一界面里有什么。比如当前屏幕上有搜索框、返回按钮、商品卡片、广告位这些元素分别是什么。第二步这些东西在什么位置。一个按钮的语言描述哪怕是右上角的搜索图标落到执行层也需要转成具体坐标因为你的点击动作是物理层面的模型必须要理解空间关系。第三当前页面处于什么状态。是在加载中、已经弹窗、还是空数据这个判断直接影响下一步是该等等还是该返回。第四元素之间的逻辑关系。比如登录按钮和输入框属于同一个表单模块这种结构化的理解才能支撑模型做出合理的操作规划。所以对 AI 助手来说多模态视觉不是看图说话这种锦上添花的能力而是刚需——它是模型获取真实世界状态、把对话转化为行动的基础接口。没有这个能力AI 就是瞎子在屋里乱撞嘴上说得再好听落到动作就是瞎猜。我在实际搭建这类系统时最直观的感受是把一张屏幕截图喂给模型比喂给它几十轮人工转述的状态描述都管用。因为界面上的信息密度太高了——控件文案、图标状态、列表内容、弹窗层级全部浓缩在一张图里。你与其设计一堆复杂的 JSON 结构去描述界面不如直接把截图丢给多模态模型让它自己去理解。这也是现在 Agent 做 UI 操作任务普遍采用的技术路线之一。3.2 光看还不够把看到的东西变成可执行的动作理解界面只是第一步最终目的是生成动作。这里就涉及到模型的输出设计。以我常用的方案为例会让多模态模型输出一个结构化的动作指令而不是让模型直接写一句自然语言请点击右上角那个按钮。结构化指令长这样{ action: click, target: 搜索框, coordinates: [540, 320], reason: 任务第一步需要先定位搜索入口, completed: false }这里有几个关键字段action 是动作类型包括 click点击、input输入文本、swipe滑动、back返回、wait等待等target 是模型自己给目标元素命名的中文描述coordinates 是归一化坐标reason 是模型解释自己为什么这么做completed 则表示是否认为这一步已经达成子目标。我特别说一下 coordinates。同一个 App在不同分辨率的手机上同一个按钮的像素位置是完全不同的。所以我会统一把截图缩放到一个标准尺寸比如 1000x2200然后让模型输出在这个标准画布上的坐标执行层再根据当前设备的实际分辨率做反向换算。这套设计本质上就是把空间理解和物理执行解耦——模型只需要理解标准画布执行层负责适配具体设备。这也是整个链路里很容易被忽略但很重要的细节。3.3 别把每帧截图都喂给大模型要学会做减法这里插一个成本警告。很多人初跑通多模态视觉 Agent 时会觉得每步截图喂给模型这个方案很完美然后跑几个任务之后直接被账单吓到。原因是一张高分辨率截图的 token 消耗通常相当于几千个文本 token而且进入模型的图片尺寸越大、细节越多成本越高。如果你执行一个 20 步的操作任务每步都要上传一张完整截图token 消耗会非常可观响应时间也会拉长。我自己的优化做法是在靠近数据源的地方加一个轻量的预处理模块通常是一台本机或边缘设备上的小模型做三道工序第一道做感知压缩。把截图缩放、降噪去掉状态栏等无关区域只保留与应用内容相关的部分。第二道做变动检测。让本机模型对比上一步和当前截图如果界面没有任何实质变化就不需要重新请求云端大模型直接沿用上一步的判断。第三道做敏感区裁剪。比如截图里出现了用户输入的私密信息就在上传前用本地模型把它马赛克掉只保留模型做决策必须看到的界面结构。说到这里就顺带回应一下最近行业内比较热的那个说法——AI 智能体助手加本地模型。我自己对这句话的理解是本地模型不是用来替代云端大模型的而是用来当看门人和预处理工的。云端的大模型负责全局理解与复杂决策本地的小模型负责隐私过滤、差异化裁剪、轻量 OCR、界面变动检测这类杂活。两边分工协作既能保住决策能力又能守住隐私和成本。别把云端和本地对立起来它们解决的是不同层面的问题。4. 云端真机实操从帮你想到帮你做4.1 真机实操和串 API 的根本差别如果说多模态视觉解决的是AI 怎么看世界那云端真机实操解决的就是AI 怎么动手改变世界。为什么强调真机因为这直接决定了 AI 能做到什么深度。API 调用方案下AI 能做的事完全取决于接口开放清单。接口里有发送消息AI 就能发消息接口里没有批量删除联系人AI 就永远做不到。而真机实操方案的思路是我给 AI 一台真实跑着的设备——它就是一台手机或者一台电脑AI 通过屏幕截图了解状态然后像人一样在屏幕上点击、滑动、输入。凡是人能在界面上做的事AI 都能学着做。不需要对方开放任何专用接口App 的界面本身就是 API而且是一个覆盖所有功能、永远不过期的通用 API。这让我想起一个类比API 集成像是你去餐厅买套餐只能点人家配好的几样真机实操像是你直接走进后厨窥探界面看菜下刀想怎么操作就怎么操作。当然后者对技术的要求更高因为它要处理的不是稳定的接口文档而是每天都在变的真实界面。4.2 云端设备池里AI 到底是怎么动手的很多人会好奇AI 没有实体手它怎么在真机上点击这里其实是靠设备自动化层来完成的这块技术在软件测试行业已经非常成熟AI 要做的只是接管方向盘。以 Android 设备为例底层链路大致是这样设备接入云平台后通过 adbAndroid Debug Bridge建立连接。执行层可以调用 adb 命令模拟点击比如adb shell input tap x y这就是一次真实的触摸事件App 收到的是和人类手指一模一样的信号。为了更精确地识别界面元素我们还会结合 UIAutomator 这类系统级 UI 解析框架拿到每个控件的 bounds 位置和控件属性。也就是说不是单纯靠像素坐标猜而是有系统层面的界面结构数据做辅助当结构数据拿不到时再退回纯视觉方案靠多模态模型从截图里识别目标位置。两条路互相兜底稳定性会好很多。iOS 设备上稍有不同系统管控更严格常用的思路是通过 XCTest 框架把设备包成一个可执行自动化用例的运行环境或者使用云端真机平台提供的无障碍通道来下发操作指令。桌面端则简单一些Windows 上可以用 WinAppDrivermacOS 上有 AppleScript 配合辅助功能接口。不管你用哪套底层执行框架对上层 AI 助手来说逻辑都一样发出一条点击坐标、输入文本、滑动方向的指令执行框架把指令翻译成系统级动作作用到设备上。4.3 为什么要强调云端而不做纯本机方案这里有一个方向选择问题AI 助手也可以直接跑在用户本机上为什么文章标题要强调云端真机实操我个人的理解是云端不是端的选择而是规模化的选择。首先是一个可用性问题。如果想做一款覆盖大量用户的 AI 助手产品你不可能在每个用户的手机里都预埋一个可被 AI 自由调度的自动化框架。iOS 上个人开发者搞不定权限企业设备又涉及繁琐的 MDM 准入流程安卓机型更是一千台有一千个兼容性问题。但云端设备池不一样设备在机房统一部署、统一镜像、统一控制AI 面对的是标准化的执行环境这比处理用户手里的杂牌真机要省心太多。其次是并发和隔离。云端设备池可以同时扩张到几十上百台设备同一个任务可以并行分发到多个设备上测、跑、比对每台设备之间又是完全隔离的这台任务跑崩了不影响另一台。这对于需要批量处理的任务非常友好。比如做一个批量巡检任务AI 每天自动登录 80 个不同账号检查一遍主页状态如果靠单本机方案光是排队就要耗一整夜云端设备池可以开 80 台设备并行跑几分钟就完事。最后是隐私边界的考量。本机方案要读用户屏幕、模拟用户触控数据在用户设备上过水敏感度高而且一旦误操作影响的是用户的真实账号和真实数据。云端方案可以把这些操作隔离在专用测试设备和测试账号里即使出了错遭殃的也只是云端沙盒不会波及用户的主设备和主账号。5. 完整链路复盘从一张截图到一次成功执行5.1 整条链路四个层我一般这么划分我自己在搭建这类系统时习惯把多模态视觉 云端真机实操拆成四个逻辑层感知层、理解层、执行层、校验层。感知层负责从设备拿到图像快照和控件结构树理解层由云端多模态模型消化这些信息结合任务目标输出下一步动作指令执行层收到指令后调用自动化框架在真实设备上完成点击、输入等物理操作最后回到校验层重新截图让模型判断执行是否产生了预期变化。四个层循环往复地跑直到任务到达终态。听起来像流水线但这个流水线不是死的。真正跑起来你会发现每个环节都可能失败所以校验层才是整个闭环的灵魂。没有校验的 Agent 是盲目的它点了按钮就算完成任务至于按钮点没点进去、弹窗有没有挡住内容一概不管。加入校验层之后AI 才有机会在错的时候自我修正——发现这一步没效果就换一个坐标再点一次或者改一种操作策略。5.2 AI 智能体助手 本地模型的在链路里的落位这个架构落到实际操作里怎么编排本地模型和云端模型的分工我举个具体例子就拿AI 帮我在某 App 里查询并记录电费账单这个任务来说。第一步云端 Agent 先接收用户的自然语言任务通过一个规划模块拆成子任务比如打开电费 App → 进入账单页 → 滑动到出账月份 → 截图读取金额 → 填入表单。然后感知层把当前屏幕截图发到本地小模型本地模型先做一件事批量裁剪隐私处理比如把账号信息、头像区域打码再把界面缩小。接着云端大模型拿到处理完的图看清楚当前页面结构输出第一步动作点击 App 图标。第二步执行层在云端设备上真的点击了图标App 开始启动。这时候我故意做了个反直觉的设置不让系统立刻截图而是让本地小模型等待一秒并监听屏幕变化。当屏幕出现了首页加载完成的特征后才触发新一轮截图。这一步很关键它可以明显减少无效截图和误判次数也是本地模型看门人最典型的应用场景。第三步进入业务操作后任务的每一步几乎都是上面循环的重复。遇到需要输入的场景云端大模型生成文本执行层用输入法注入遇到需要滑动的场景云端模型输出方向和距离执行层用 adb 手势模拟。直到最后填完表单云端模型对比最终截图发现保存成功文案出现给整个任务打上终态标记。这套本地小模型管杂活云端大模型做决策的搭配是我目前跑下来体验最稳的组合。你当然也可以让云端大模型直接处理原始截图但等你看到响应延迟和账单数字的时候大概率会回头把本地模型加回来。5.3 指令协议统一别让每一层说不同的语言这里还有一个容易被新手忽略但做系统时必须提前规划的问题链路里每个模块的数据格式必须统一。比如感知层拿到的是图片和 XML 结构树理解层输出的是 JSON 动作指令执行层要求的是 adb 命令校验层又需要图片对比结果。如果每一步都单独设计数据结构整个系统很快就会变成一团乱麻。我建议从第一天就定一套统一的任务描述协议。核心字段至少包括task_id任务标识、step_index步骤序号、action动作类型、payload动作参数、expectation预期结果描述、status当前状态。说白了每个环节的输入输出都是同一张工单只是在不同环节填充不同的字段。这样出问题时你能很快定位是感知层给的数据不对还是理解层生成的坐标偏了还是执行层根本没执行成功。6. 实操现场我踩过的四个高频坑6.1 时序坑页面还没加载完就截图模型只能瞎猜如果一个任务失败八成以上的原因可以追溯到截图时机不对。App 的页面是有加载过程的从点击图标到页面完全渲染快的零点几秒慢的几秒钟。如果在加载中途截了图模型看到的是一半白屏一半骨架屏它再聪明也无法判断页面结构只能靠记忆猜。可问题是不同网络环境下加载时间完全不可控死等固定秒数又大大拖慢效率。我的解决方案是引入预期状态等待机制。在执行每次点击前让上游模型顺便输出一句对点击后画面的预期特征比如预计出现灰色加载动画2 秒后变成账单列表。执行层点完之后本地小模型持续监听新截图一旦识别到账单列表出现立刻触发下一步如果超过 10 秒还没出现就上报超时让 Agent 决定是重试还是放弃。这个方法实测下来能把无效截图率从三成压到一成以内。6.2 坐标坑分辨率不一致模型点到了空气上我用多模态模型输出坐标的时候一开始直接让它输出原始屏幕像素坐标。结果换了一台不同分辨率的测试设备后同样的任务在旧设备上运行顺畅在新设备上疯狂点错位置。原因不难理解同一个按钮在 1080P 屏和 2K 屏上的像素位置不一样模型训练时看到的界面比例可能也不一样。后来我把整个流程改成所有截图先缩放成统一的 1000x2200 标准画布模型只输出标准画布上的坐标执行层拿到坐标后乘以一个比例系数换算到目标设备的实际分辨率再执行。项目里我会在设备初始化时算好这个系数并且每次点击前再做一次边界检查防止坐标超出屏幕范围。这一改之后跨设备迁移的稳定性提升非常明显。6.3 假成功坑模型以为点到了其实屏幕毫无反应这是最容易让 AI 助手看起来很聪明但其实没用的坑。模型在思考链里写了已点击搜索框执行层也确实执行了一次 tap 命令逻辑上一切正常但真实设备上那个 tap 没起任何作用。原因可能是App 实际弹了一个蒙层拦截了触摸事件或者 tap 坐标落在了控件之外的点击死区或者 App 未响应界面卡死。我的排查策略是三步验证法第一步对比点击前后的截图用基础像素差来判断界面是否发生变化如果一模一样说明点击动作大概率没生效第二步如果画面变了再查看变化是否符合预期的状态变化比如是否进入了下一页、是否出现了键盘第三步极少数情况下画面变了但参数不对这时候就需要让模型再读一次截图判断当前页面是否符合预期状态而不是只看有无变化。记住一个原则动作执行不等于动作生效只有校验层确认了才叫成功。6.4 成本坑截图比你想的贵得多最后说钱的事。我早期跑一个 30 步的任务全程使用完整截图喂云端多模态模型一轮跑下来光视觉 token 的费用就抵得上几十万字文本。尤其在遇到页面没变化的重复轮次时每次都上传一张几乎一样的截图纯粹是烧钱。应对办法有三条本机做相似度去重截图没变就不请求对截图做区域裁剪只上传与任务相关的那一块降低截图分辨率让模型在够识别的前提下使用更小的图。三条叠起来成本至少降一半响应也快很多。7. 新路径适合做什么以及现在的边界在哪7.1 这几个场景我建议优先尝试把多模态视觉 云端真机实操落到产业里有几个场景是我认为当下最值得投入的App 自动化回归测试测试是这套技术最成熟的应用方向。AI 读取 UI 界面并自动生成测试步骤改动界面后自动回归确实能省下大量人力和时间。复杂表单与业务流程代办比如财务系统里重复录入报销单、后台系统里批量修改配置。这些业务 API 往往老旧或不全人又不得不天天在界面里点来点去正好是 AI 真机操作的用武之地。适老化和无障碍辅助很多老年人不会操作智能手机AI 助手可以变成一双无形的手根据视觉理解替他们完成操作比如拨号、调大字体、打开健康码。这类场景温暖且刚需。RPA 升级传统 RPA 依赖界面选择器界面一变脚本就废。用多模态视觉替代选择器后抗界面变化的能力会有质的提升。7.2 现在还没解决好的硬边界先别把这条路吹上天我和它缠斗了小半年深知它还有几个让人头疼的短板。第一是长任务的记忆一致性。一个 50 步的任务跑到第 30 步时模型很容易忘记最初的目标或者被中间的干扰信息带偏。目前业界的主流方案是外挂独立的记忆模块或任务清单让它随时回顾目标但效果并不稳定尤其当任务中出现了计划外的弹窗时模型经常不知所措。第二是错误恢复能力。人类操作时误点了一个页面会看一眼然后返回继续操作。AI 做真机实操时一旦执行了一个与预期不符的操作整个链条就会开始连锁出错。如果要让 AI 学会发现走错路之后自己导航回正确的路径这需要非常强的环境理解能力和规划能力现在的模型还远远谈不上可靠。第三是跨 App 连续协作。虽然单 App 内的操作已经能跑通不少但现实中的复杂任务往往要跨多个 App从短信里复制验证码、跳到银行 App 转账、再回到记账 App 记录每一步都是体系和权限的跨越。目前的自动化底层对这种跨 App 任务支持得并不顺滑需要额外的系统级权限和状态管理。7.3 给准备上手的团队一个建议从最小可闭环开始我在跟不少朋友聊这套方案时经常听到一句我们想做一个全能的 AI 手机管家。我的反应都是先别。把一个具体场景、一个具体 App、一个 10 步以内的任务跑通闭环远比一开始就想覆盖所有 App 要重要得多。因为这个领域真正的复杂度不来自模型本身而是来自真实世界的长尾情况。每处理一种异常分支你的系统就会变厚一点而这些经验是通用的——今天你在 A 场景里踩过的坑明天在 B 场景里会原样回报给你。不妨从这样一个任务开始让 AI 自动登录一个 Web 后台找到昨天的销售报表把关键几个数字填入一个固定的表单点击提交再截图确认提交成功。这个任务小但它覆盖了感知、动作、校验、异常处理全链路做完之后你自然知道下一步该补哪块能力。我自己迭代这套架构的节奏就是从这类有点用但还不复杂的小任务起步一点点把边界往外推的。真要说个人体会我现在最深的感受是多模态视觉 云端真机实操这条路最大的价值不是造出一个什么都会的终极助手而是让 AI 第一次真正承担起了执行人的角色。它不再是给你出主意的那种军师而是那个帮你把事跑完的同事。在这个角色转变里技术难点很多方向却很清晰——让 AI 能看得见真实界面、能动手操作真实设备、能在出错时自我纠正这三件事每往前推进一寸都意味着 AI 应用又往深处走了一步。