AI操作手机三层架构：感知、决策、执行与闭环校验

手机上那些枯燥的重复操作——每天签到、批量改设置、跨应用搬数据、把一串固定流程走完——一直卡在一个尴尬的位置。写脚本吧应用一改版选择器全废用现成的自动化工具吧碰上自绘界面、WebView 混合渲染、动态弹窗就直接歇菜。最近社区里讨论得挺热的一套 AI 操作手机方案把这个事拆成了三层来做感知、决策、执行。我第一眼看到这个分层时的感觉是“朴素得有点过分”但真照着复现了一遍才发现它的价值不在于用了多大的模型而在于每一层都给自己留了退路——感知看不懂就换另一条通道决策不确定就多问一次执行没生效就重来一轮。这篇文章就把这三层掰开讲清楚包括每一层具体在干什么、为什么这么切、参数怎么定、坑在哪。不管你是想自己搭一套还是只想搞明白这类工具背后的逻辑看完应该都能有收获。1. 先把“三层”这个切法讲透1.1 为什么不是“一个大模型端到端搞定”很多人第一反应是既然有多模态大模型直接把截图丢进去让它输出“点哪里”不就行了为什么要分三层我一开始也这么想直到实测跑了一周才发现问题。端到端最大的毛病不是能力不够而是不可观测。任务失败了你不知道是模型没看清屏幕、还是看清楚了但决策错了、还是决策对了但点击没落到位。这三种故障的修复手段完全不同混在一起就是一个黑盒调都没法调。分层之后每一层都有明确的输入输出契约。感知层吐出来的是“结构化元素列表”决策层吐出来的是“结构化动作指令”执行层回报的是“动作是否生效”。任何一步出问题你在日志里一眼就能定位到是哪一层掉了链子。这就像修车你不会只被告知“车坏了”而是知道是油路、电路还是传动的问题。另一个更现实的原因是可替换性。多模态模型的迭代速度太快了三个月换一代很正常。如果模型和操作逻辑揉在一起换模型等于重写。分层之后决策层换模型只需要保证输入输出的 schema 不变感知层和执行层完全不用动。我实际做过一次替换测试从一个小参数量的视觉模型换到一个更大的改动量控制在提示词和两个字段映射上半天搞定。1.2 三层各自的边界与职责划定这三层的职责边界我习惯用一句大白话概括感知层负责“现在屏幕上有啥”决策层负责“下一步该干啥”执行层负责“怎么把手伸过去”。听起来简单但边界划不清就会互相甩锅。感知层的输出必须是与业务无关的客观描述。它不该判断“这个按钮该不该点”只负责告诉上层“这里有个按钮文字是‘确定’可点击位置在屏幕下方”。一旦感知层开始做价值判断后面就没法复用了。决策层是唯一知道“任务目标”的一层。它接收任务描述、当前屏幕状态、历史动作记录输出下一步动作。它不关心动作怎么实现只说“点这个元素”或者“往上滑一屏”。执行层是纯体力活不做任何判断。给它一个动作它执行然后回报成功或失败、耗时多少、屏幕有没有变化。它也不知道自己在干什么任务。这个划分有个好处每层都可以单独做单元测试。感知层可以用一批固定截图做回归决策层可以用固定的历史序列测输出稳定性执行层可以在固定设备上测动作成功率。这种可测试性在调试阶段省的时间比架构设计本身花的时间多得多。1.3 三层之间靠什么串起来串起来的是一个循环不是一条直线。完整的链路是截图 → 感知解析 → 决策推理 → 执行动作 → 再截图 → 校验结果 → 判断是否完成。这个闭环是整个方案的骨架任何一步省略都会导致错误累积。我见过有人为了省时间做完动作不重新截图直接让模型基于上一帧继续决策理由是“反正我知道点了会跳转”。这个做法在前三步可能没问题到第五步就开始漂移因为页面加载有快慢、弹窗会随机出现、列表滚动位置会变。实测下来省略重新感知的版本任务成功率大概在四成左右老实做闭环的能到八成五以上。循环还需要一个终止条件通常是两个任务判定完成或者达到最大步数。最大步数我一般设 40复杂任务设 60。设太小会导致长流程被截断设太大则单次失败要等很久才报错体验很差。2. 感知层让 AI 知道屏幕上有啥2.1 无障碍树与截图两条腿走路感知层最核心的选择是用无障碍节点树还是用截图做视觉理解。这两个方案各有各的死角成熟的做法是两个都用按优先级降级。无障碍树的优势是精确、轻量、语义清晰。系统提供的节点树里每个元素带着文本、描述、资源 ID、类名、是否可点击、是否可滚动、边界坐标这些属性拿到就是结构化的不需要模型去猜。一个中等复杂度的页面节点数在 200 到 800 之间裁剪之后喂给模型的信息量很小推理也快。但无障碍树有三个死穴。第一自绘界面的节点是空的很多用跨平台框架渲染的页面整棵树只有一个大节点里面啥也没有。第二WebView 里的内容经常只暴露一个容器节点具体按钮拿不到。第三游戏和视频类界面基本没有可用节点。这三种情况只能退回截图走视觉路线。视觉路线的流程是截图 → 元素检测或 OCR → 得到候选区域和文字。OCR 负责把界面上的文字提取出来加位置元素检测负责找出按钮、输入框、图标这些可交互区域的轮廓。两条信息合并之后输出和节点树尽量保持一样的格式这样上层的决策逻辑不用改。我自己实测的经验是能用树就用树树拿不到再退视觉因为视觉路线的坐标误差和识别漏检明显更多。判断“树能不能用”有个简单阈值一次 dump 下来可点击节点数量少于 3 个或者页面根节点的子节点数少于 5 个就判定这棵树不可用直接切视觉。2.2 元素索引法给模型一份“可点清单”这里有个特别值得说的实现细节。让模型直接输出坐标还是让它输出元素编号我两种都试过编号法的准确率明显高。具体做法是感知层把当前屏幕上所有可交互元素整理成一个列表每个元素给一个从 1 开始的编号附带文字、类型、大致位置描述。截图上也把这些编号画上去或者直接把编号和描述以纯文本形式喂给模型。模型只需要回一个编号剩下的坐标换算由代码来做。{ screen_id: step_07, elements: [ {id: 1, text: 搜索, type: input, bounds: [0.06, 0.08, 0.94, 0.14], clickable: true}, {id: 2, text: 推荐, type: tab, bounds: [0.0, 0.16, 0.33, 0.21], clickable: true}, {id: 3, text: 关注, type: tab, bounds: [0.33, 0.16, 0.66, 0.21], clickable: true}, {id: 4, text: 消息列表, type: list, bounds: [0.0, 0.22, 1.0, 0.95], scrollable: true} ] }为什么编号法更稳因为坐标是个连续的回归问题模型很容易输出一个“看起来合理但偏了几十像素”的值而编号是个离散的分类问题只要元素在列表里选错的概率低得多。另外坐标法还有个隐患模型对归一化坐标的理解不稳定有时候给你 0 到 1 的小数有时候给你 0 到 1000 的整数格式一乱就全废。编号法要注意的是列表长度。元素太多会撑爆上下文也会让模型选择困难。我的做法是设一个上限一般 60 到 80 个超了就按“是否可点击 是否有文字 面积大小”排序截断。同时在提示词里明确告诉模型如果目标不在列表里返回 -1 表示需要滚动或换页面不要让它在列表里硬选一个最像的。2.3 坐标归一化与多机型适配坐标这块踩过的坑最多单独拎出来讲。不同设备的分辨率从 720×1280 到 1440×3200 都有还有各种刘海、挖孔、曲面屏如果直接用绝对像素换台设备就全乱。解决方案是全链路归一化。感知层输出坐标时除以当前屏幕的宽高统一成 0 到 1 的浮点数。决策层拿到的、输出的都是归一化值。执行层在真正点击前再乘回当前设备的实际分辨率。这样一套逻辑可以在任意设备上跑不需要为每台机器单独调。# 感知层绝对坐标转归一化 def to_normalized(x, y, screen_w, screen_h): return round(x / screen_w, 4), round(y / screen_h, 4) # 执行层归一化转绝对坐标并做越界保护 def to_absolute(nx, ny, screen_w, screen_h): x int(nx * screen_w) y int(ny * screen_h) x max(0, min(x, screen_w - 1)) y max(0, min(y, screen_h - 1)) return x, y这里有个容易忽略的细节截图区域和屏幕区域可能不一致。如果截图只截了应用区域、去掉了状态栏那么截图坐标系的原点比屏幕坐标系低了状态栏的高度。这个偏移量必须记录下来在计算点击位置时补回去否则所有点击都会整体上移几十像素表现为“总能点到上面那个元素”。我第一次遇到这个现象时排查了很久因为点击是“成功”的只是点错了东西。还有一个坑是缩放。为了减少传输和推理开销截图经常会被压缩比如原图 1080 宽压到 720 宽。如果压缩后的坐标没有反算回原始尺寸误差会按比例放大。我的做法是截完图立刻记录缩放因子后面所有坐标处理都带上这个因子参与换算。2.4 感知层的三个典型翻车现场第一个是动画未结束就截图。页面跳转有过渡动画列表滚动有惯性这时候截到的图是模糊的、元素位置是中途的。解决办法是在执行动作后等一个稳定信号或者退而求其次固定等 600 到 1000 毫秒。我一般两个都上先监听界面内容变化事件静默超过 500 毫秒就认为稳定同时设一个 3 秒的上限兜底防止某些页面一直有动画比如轮播图导致永远等不到静默。第二个是浮层遮挡。弹窗、广告、权限请求、通知横幅这些东西出现在截图里会让模型误以为它们是主界面的一部分。感知层要做一层简单过滤检测是否有覆盖面积超过屏幕 30% 的浮层节点如果有把它单独标记出来并优先处理通常是找个关闭按钮点掉。第三个是长列表的可见性判断。屏幕上只显示 8 条实际列表有 200 条模型看到的是 8 条但它可能以为这就是全部。感知层需要告诉模型“当前是列表的第几屏是否还有更多内容”这个信息可以从滚动容器的属性里拿到拿不到就用截图边缘有没有被“切一半”的元素来判断。3. 决策层把一句话翻译成一串动作3.1 动作空间怎么设计才不容易出岔子动作空间就是模型能输出的指令集合。设计原则是够用就好越少越稳。我见过把动作设计成二十几种的方案结果是模型经常选错因为它分不清“长按”和“按住拖拽”的区别。我自己用的最小集合是八种动作参数说明tap元素编号点击某个元素input元素编号 文本向输入框填内容swipe方向 距离比例上下左右滑动back无返回上一级home无回桌面wait毫秒数等待加载scroll_to元素编号滚动直到某元素可见done结果描述任务完成关键点是每个动作的语义要互斥。比如“点击”和“长按”必须明确区分成两个动作不能让模型在参数里写个时长自己决定。因为模型对“多久算长按”没有稳定概念一会儿给你 300 毫秒一会儿给你 2000 毫秒行为完全不可控。另一个设计要点是done这个动作必须有。很多方案只让模型输出操作完成判断靠外部逻辑结果就是模型在一个已经完成的页面上反复找事做直到撞上最大步数。让模型自己说“我干完了”配合一个校验逻辑比如检查某个预期元素是否存在成功率会高很多。3.2 提示词里的四个固定槽位决策层的提示词我固定成四块角色约束、动作规范、当前状态、历史动作。这四块缺一块都会出问题我分别说一下。角色约束这块要写清楚“你是一个手机操作助手你的任务是通过一系列动作完成用户目标你不做任何与目标无关的操作”。这句话看着废话但能有效降低模型乱点的概率。我做过对照实验去掉这句之后模型在等待加载时会“顺手”点一些看起来相关的元素导致流程跑偏。动作规范就是上面那张表要写得非常明确包括参数格式、取值范围、什么情况下用哪个动作。我建议把 JSON schema 直接写进提示词比自然语言描述准确。当前状态包括任务目标、当前屏幕的元素列表、当前页面的大致描述可以用节点树的路径概括比如“设置 显示 亮度”。这个路径信息特别有用能给模型一个“我在哪”的定位感。历史动作是最近 5 到 8 步的动作记录格式是“第几步、做了什么、结果如何”。这块的作用是防止死循环。没有历史记录的时候模型在一个加载不出来的页面上会不停地重复同一个动作因为它每次看到的都是同一帧。加上历史之后它能看到“我已经点了三次这个按钮都没反应”就会倾向于换策略比如等待或者返回。3.3 上下文与记忆别让模型忘了自己在哪任务步数一多上下文就会变长。全量塞进去既慢又贵还可能超出窗口限制。我的处理是滑动窗口 关键节点摘要。滑动窗口保留最近 6 步的完整信息动作、结果、当时的元素列表摘要。更早的步骤压缩成一句话比如“第 1-8 步从桌面进入设置依次点击了 WLAN、高级设置当前处于高级设置页”。这个摘要在每次窗口滑动时更新一次用一个轻量调用生成成本很低。摘要里必须保留三类信息已经走过的页面路径防止绕回原点、已经确认无效的操作防止重复尝试、已经填过的内容防止重复输入。第三点特别重要一个表单分好几屏填如果模型忘了前面填过什么会在返回上一屏时把已填内容覆盖掉。3.4 闭环校验模型说点了不代表真点了这是整个方案里我认为最关键的一条经验。模型的输出是意图不是结果。它说“点击了搜索框”实际的执行可能是失败的——元素被其他东西挡住、坐标算错了、应用响应慢没接住。所以每一步执行完必须重新感知一次然后做一次轻量校验。校验逻辑分三级成本从低到高第一级是结构校验比较动作前后的元素列表差异。如果点击了一个“进入下一级”的按钮元素列表应该有明显变化超过 30% 的节点不同。如果完全没变八成是没点中。第二级是预期校验让模型在输出动作时顺便给一个预期结果比如“点击后应该出现搜索输入框”。执行完检查这个预期是否成立。第三级是模型复核把执行后的截图再丢给模型问一句“刚才那个操作生效了吗”。这一级最贵只在前后差异模糊的时候才触发。三级校验下来误判率能压得很低。我统计过一段时间的日志纯靠第一级能拦住大约七成的失败加上第二级能到九成第三级补上剩下的。4. 执行层动作怎么稳稳落到屏幕上4.1 三种注入方式的选择执行层要把“点击坐标 (540, 1200)”变成真实的触摸事件。常见的有三条路各有适用范围。第一条是系统调试通道的命令注入直接发一条点击指令。优点是接入最简单不需要应用配合几乎所有场景都能用。缺点是延迟稍高单次大概 50 到 150 毫秒而且不支持多点触控和复杂手势。第二条是无障碍服务的事件注入通过节点直接触发点击动作。优点是不依赖坐标元素移动了也能点中而且更“像”真实用户操作。缺点是对自绘界面无效因为压根没有节点。第三条是底层事件注入构造触摸事件序列直接投递。优点是能力最全能模拟长按、拖拽、多指手势。缺点是需要更高的权限接入成本也最高。我的策略是按元素是否有节点来决定走哪条路有节点优先走第二条没节点退回第一条需要复杂手势时才用第三条。这样能在成功率、速度和适配性之间拿到一个比较好的平衡点。4.2 中文输入这个老大难输入文字这块英文和数字相对简单中文是个专门要处理的问题。原因是最常见的命令式输入方式只支持 ASCII 字符中文直接发过去会变成一堆问号或者干脆没反应。我试过三种方案按推荐程度排方案一是走无障碍的文本设置接口。找到输入框节点直接设置它的文本属性。这个方案最快最干净但兼容性一般原生输入框通常没问题跨平台框架渲染的输入框经常不生效设置完界面上还是空的。方案二是临时切换输入法。装一个支持外部指令输入的输入法把当前输入法切过去发指令让它把文字“打”进去完事再切回来。这个方案兼容性最好什么输入框都能用代价是要多装一个组件而且切换输入法本身有几百毫秒开销。方案三是剪贴板加粘贴。先把文字写进剪贴板然后长按输入框触发粘贴菜单再点粘贴。这个方案不用装额外组件但流程长、容易在长按菜单那步出岔子。我实际用下来方案二做主力方案一作为快速路径。先试方案一检查输入框内容有没有变成目标文字没变就切方案二。这个兜底逻辑写起来不复杂但能省掉大量“输入失败”的排查时间。还有个小细节输入完成后要主动收起键盘否则键盘会遮挡下半屏影响下一步的感知和点击。收起的方式通常是发一个返回键事件但要注意有的页面返回键会直接把页面也退掉所以更稳的做法是点击键盘外的空白区域。4.3 动作后的等待策略等待策略看起来是个小问题实际对成功率影响巨大。等太短页面没加载完就截图模型基于半成品做决策等太长整个任务耗时翻倍。我用的是一套组合等待事件监听为主固定时长兜底元素探测为辅。主逻辑是监听界面内容变化事件。动作发出后开始计数每收到一次内容变化事件就重置计时器连续 500 毫秒没有新事件就认为页面稳定。这个策略对大部分页面都有效平均等待时间在 600 到 900 毫秒。兜底逻辑是设一个最长等待上限一般 3 秒。有些页面有持续的动画视频播放、轮播图、进度条事件永远不会静默这时候到点就继续不能无限等。辅助逻辑是关键元素探测如果知道下一步大概率要找某个元素可以轮询检查这个元素是否已经出现出现了立刻继续不用等满静默时间。这能把常见场景的平均等待压到 400 毫秒以内。4.4 失败重试与降级路径执行失败是常态关键是失败之后怎么处理。我的策略是同一动作最多试两次两次都失败就换策略。第一次失败通常重试原动作因为可能是偶发的响应延迟。重试前会重新感知一次确认坐标或元素编号还是有效的。如果元素已经消失或者位置变了就不重试直接进入换策略。换策略的顺序是先尝试滚动一下看目标是不是在屏幕外再尝试按返回键看是不是进了错误的页面最后才判定这一步失败并向用户报错。这个降级链条覆盖了我遇到的大部分失败场景。另外有个容易被忽略的点重试要有间隔。连续快速重试两次中间只隔几十毫秒对于响应慢的应用来说等于只试了一次。我一般第一次重试间隔 300 毫秒第二次间隔 800 毫秒给应用足够的反应时间。5. 一次完整任务的链路实录5.1 任务下发与首帧感知拿一个具体例子走一遍任务描述是“把系统的字体大小调到最大”。这个任务有明确的终点步骤数中等适合用来观察链路。第一步是回桌面保证起点一致。发一个 home 动作等 800 毫秒截第一帧。感知层解析出桌面上的元素列表大概 20 到 30 个可点击项包括各个应用的图标和底部的搜索栏。决策层拿到任务和元素列表判断需要先打开设置应用输出{action: tap, target: 12, expect: 进入设置页面}其中 12 是设置图标的编号。执行层换算坐标调用点击回报成功等待 900 毫秒系统设置启动稍慢然后重新截图。5.2 逐步推进与耗时拆解进入设置页之后感知层解析出列表能看到“网络”“显示”“声音”“存储”这些条目。决策层判断字体大小属于显示相关点击“显示”。这里有个细节设置页的列表可能需要滚动才能看到目标项如果当前屏没有“显示”模型应该输出滚动动作而不是硬选一个最像的。这就是前面说的“目标不在列表返回 -1”机制起作用的地方。进入显示页之后找到“字体大小”或者“文字大小”这一项点进去通常会看到一个滑块或者一组单选按钮。滑块类控件的处理比较特殊节点树里它可能只是一个 seekable 节点没有具体的档位信息。这时候要么用滑动动作按比例拖动要么先截图看当前滑块位置再计算需要滑动的距离。这一步的耗时明显比其他步长因为多了两次感知和一次坐标计算。我把单步耗时拆开统计过平均情况是这样的环节平均耗时截图与压缩120 ms感知解析节点树60 ms决策推理1800 ms坐标换算与执行90 ms等待页面稳定750 ms校验与重新感知150 ms单步合计约 2.9 s一个 12 步的任务总耗时大概 35 秒。听起来不快但对比人工操作其实差不多而且它能挂着跑人去干别的。5.3 收尾校验与结果确认最后一步是把滑块拖到最右端。执行完之后不能直接说“完成”要做一次确认重新感知检查滑块的位置属性或者旁边显示的档位文字是不是已经是最大值。确认无误后输出done动作附带一句结果描述。如果校验发现没到位会再补一次滑动最多补两次。两次还不行就报错把当前的截图和元素列表存下来方便事后排查。这个“失败也留证据”的习惯很重要我早期没做这个出了问题只能靠回忆复现效率极低。6. 问题排查速查表与避坑心得6.1 高频故障对照表跑了一段时间之后我把遇到的问题整理成了一张表。这张表基本覆盖了九成以上的故障遇到问题先对着查一遍能省不少时间。现象大概率原因处理方式点击总是偏移固定距离截图区域与屏幕区域不一致缺状态栏偏移记录截图区域偏移量点击时补回换设备后全部点偏坐标没做归一化用了绝对像素全链路改成 0 到 1 归一化中文输入变成问号命令式输入不支持非 ASCII切换输入法方案或走剪贴板模型反复点同一个位置缺历史动作记录或校验没生效补历史动作加前后帧差异校验卡在加载页不动等待策略只等固定时长没等稳定信号加事件监听和最长超时兜底无障碍树几乎为空自绘界面或 WebView 混合渲染降级到视觉感知路线弹窗打断流程感知层没识别浮层检测大面积覆盖节点优先关闭长任务后期开始乱操作上下文超长早期信息丢失加滑动窗口和路径摘要输入框填完内容又被清空重复输入或页面重新渲染输入后校验内容避免重复操作任务判定完成但其实没完成只信模型输出没做结果校验加终点元素探测6.2 几条踩出来的经验第一条日志一定要存全链路快照。我一开始只存文本日志出问题只能看到“第 7 步点击失败”完全不知道当时屏幕长什么样。后来改成每步都存一份截图加元素列表的 JSON排查效率提升了不止一个档次。存储成本其实不高一次任务 40 步压缩后的截图总共也就几兆。这些数据还能反过来做优化比如统计哪些页面耗时最长、哪些动作失败率最高。第二条别让模型做它不擅长的事。模型擅长语义理解和模糊匹配不擅长精确计算。所以坐标换算、距离计算、滚动比例这些全部放到代码里做模型只负责“选哪个”。我早期让模型直接输出滑动距离的像素值结果它给的数字完全没法用一会儿 200 一会儿 800毫无规律。改成让它输出“滑动半屏”这种相对描述代码再换算成具体像素稳定性立刻上来了。第三条给每个应用设一个包名白名单。这套东西跑起来之后最怕的是误操作——本来想点自己应用里的按钮结果跳到了别的应用里乱点一通。加一个包名检查发现当前前台应用不在白名单里就立刻停下并回桌面。这个检查成本极低但能避免很多尴尬。第四条最大步数和单步超时都要设。任务卡死的时候如果没有超时保护整个流程会一直挂着占着设备不说日志还会疯狂增长。单步超时我设的是 15 秒包含模型推理和等待整体超时按任务复杂度设 3 到 5 分钟超了就中断并保存现场。6.3 关于模型选型的一点实际感受最后聊聊选型。这类任务对模型的要求其实挺特殊的不需要它有很强的知识储备但需要它对界面元素的空间关系和语义关系判断准确还需要它的输出格式极其稳定。我试过用参数量很大的模型效果确实好一些但单步推理从 1.8 秒涨到 4 秒以上一个 30 步的任务要跑两分多钟实用性大打折扣。反而是中等参数量的模型配合精心设计的提示词和元素索引法在成功率只差几个百分点的情况下速度能快一倍多。另一个感受是输出格式的稳定性比理解能力更重要。一个理解能力稍弱但每次都能严格按 schema 输出的模型实际可用性远高于一个聪明但经常给你加两句解释、格式跑偏的模型。所以在选型阶段我会专门跑一批固定输入看输出的 JSON 解析成功率这个指标不过关的直接排除不管它理解能力多强。还有一个能显著提升稳定性的技巧把温度参数调到很低。这类任务不需要创造性需要的是可重复性。同样的屏幕状态下模型应该给出同样的决策这样出问题才能复现。温度调高之后同一个页面两次决策不一样排查起来就是噩梦。这套三层架构跑下来我最大的体会是AI 操作手机这件事难点从来不在“AI”两个字上而在工程细节里。坐标偏移几十像素、输入法不支持中文、等待少了两百毫秒、历史记录少存了三步任何一个细节出问题整体成功率就会掉一大截。分层的好处就是把这些细节拆开让每一层的问题都能被单独发现、单独修复。至于后面还能怎么扩展我最近在试的是把成功任务的完整轨迹存下来下次遇到同类任务直接检索复用跳过一部分推理步骤——这个方向看起来挺有戏等跑一段时间有数据了再单独写一篇。