ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

手机自己把活干了

2026/9/30 19:36:36 拓冰建站 浏览量
手机自己把活干了 手机自己把活干了AutoGod自动化助手技术博客 · 端侧执行时代的第一支完整闭环2026 年的科技展会上智能体手机成了最拥挤的展台。厂商们热衷于演示一句话让手机订机票、点咖啡、发朋友圈可真把机器拿到手很多人发现它更像一个住在云端的话痨聊得头头是道真到了要点击、要滑动、要在断网时顶上的环节它就开始装聋作哑。行业终于看清了一件事——智能体的分水岭不在嘴上而在手上。AutoGod自动化助手要解决的正是把想明白变成做出来的这最后十厘米而且不需要你换一台新手机你抽屉里那台旧安卓今天就能上岗。云端聊得热闹手上没有动作过去两年我们习惯了把智能体想象成一个对话框你说需求它给答案。这种模式在信息检索、文案生成这类只动嘴的场景里确实好用可一旦任务需要跨应用操作它的短板就暴露无遗。云端的模型并不真正握着你的手机它要么依赖应用厂商开放的接口要么把屏幕画面一帧帧传回服务器去看前者意味着没有接口就寸步难行后者意味着每一步都要忍受几百毫秒甚至数秒的往返延迟还要按帧付费。更现实的问题是环境。手机常常出现在电梯、地铁、地下车库、车间和仓库这类网络时有时无的地方把每一步操作都绑定在一次稳定的网络请求上等于给自动化埋下一颗随时会响的雷。网络一抖正在进行的流程就僵在半空你甚至不知道上一笔操作到底有没有成功于是重复提交、重复下单、重复扣款的风险接踵而至。业界这一年喊得最响的端侧执行本质上就是在回答这个问题让思考可以在云端但让动作必须落在设备本地。AutoGod 选择了一条更务实的路。它不跟你争论大模型会不会取代脚本而是把一台安卓设备的感知能力、执行能力和网络能力统一收进一套脚本运行时让想和做可以自由组合。你可以把最聪明的判断交给云端大模型也可以把最确定的流程留给本地规则而无论决策来自哪里最终的点击、滑动、输入都在手机上完成不依赖某一台服务器是否在线。把闭环拆成三块骨头一个能真正干活的手机智能体说穿了就是三件事在循环先看懂屏幕上有什么再决定下一步做什么最后把动作落到屏幕上然后回到第一步直到任务结束。这三块骨头分别对应感知、决策和执行缺了任何一块智能体都不完整。感知这一环AutoGod 给了四条互相补位的通路。最结构化的是无障碍节点树它能直接读出屏幕上控件的文字、描述、资源标识和几何位置速度快、语义准当界面是自绘画面、节点树一片空白时端侧 OCR 可以把像素里的文字读出来再往深处本地目标检测能认出按钮图案、图标和弹窗最朴素也最可靠的找色则能锁定一个状态点。成熟的脚本不会在一棵树上吊死它会按成本从低到高逐级尝试。决策这一环你有两种选择。规则明确的场景用本地的条件判断就够了又快又稳还不要钱遇到没见过的弹窗、需要语义理解的岔路口再把结构化的现场信息打包发给大模型让它返回一个动作。执行这一环则由统一的动作模块承担无论背后走无障碍、Root 还是触摸驱动脚本层面都是同一套点击与手势接口调用者完全不用关心底层细节。先让屏幕开口说话闭环的第一步是把屏幕翻译成一段机器和模型都能读懂的描述。直接把整张截图丢给大模型是最省事却也最浪费的做法画面里大量像素是背景和装饰token 花了不少关键信息反而被淹没。更聪明的姿势是先在本地做一次结构化提取把可点击的元素、关键文本和当前界面收拢成简短的文字。// 感知把屏幕上可交互的元素收拢成一份清单functionreadScreen(){varitems[];// 优先走无障碍节点树取出所有可点击元素varnodes$act.selector().clickable(true).find();for(vari0;inodes.size();i){varnnodes.get(i);varlabeln.text||n.desc||n.id||;if(label!n.visibletrue){items.push({label:label,x:Math.floor(n.cx),y:Math.floor(n.cy)});}}// 节点树空空如也时用端侧 OCR 兜底全程离线if(items.length0){$ocr.v(mlkit);varwords$ocr.detect({gray:true});for(varj0;jwords.size();j){varwwords.get(j);items.push({label:w.text,x:Math.floor(w.cx),y:Math.floor(w.cy)});}}returnitems;}这个函数体现的是端侧执行的第一层价值感知在本地完成既不产生流量也不泄露画面。拿到的清单里每一项都带着文字和坐标既能直接喂给规则判断也能压缩成几行文字发给大模型。相比截全屏、传全图的粗暴方案结构化提取的成本往往只有十分之一准确率反而更高——模型最擅长处理的本来就是简洁的文本而不是模糊的像素。把决定外包给一个会思考的接口有了现场清单决策环节就可以按需引入大模型。这里的关键是约定一套稳定的动作协议让模型只返回结构化的 JSON明确告诉脚本要做什么动作、点哪个目标而不是返回一段需要再去猜测的自由文本。脚本拿到 JSON校验字段再交给动作模块执行。// 决策把现场清单发给大模型拿回一个结构化动作functiondecide(items,goal){varres$http.post({url:https://api.example.com/chat/completions,readTimeout:60,head:{Content-Type:application/json,Authorization:Bearer 你的密钥},data:{model:your-model,messages:[{role:system,content:你是界面决策助手只输出JSON格式为{action:click,label:按钮文字}},{role:user,content:目标goal当前可操作元素JSON.stringify(items)}],stream:false}});varcontentres.json().choices[0].message.content;returnJSON.parse(content);}注意这个设计里藏着的分层智慧发给模型的是结构化的元素清单而不是整张截图模型只负责选哪个真正的怎么点由本地动作模块完成。这样即使模型偶尔判断失误动作仍然落在脚本可控的范围内而不是让一个远程黑盒直接操控你的手机。本地优先、云端兜底整条链路的平均延迟和成本都被压到了最低。动作落地之后别急着下一轮很多初学者的脚本会在动作执行后立刻进入下一轮循环结果界面还在播放动画新的感知读到的是中间态一连串误判由此产生。正确的节奏是执行动作等待界面稳定重新感知并验证目标是否达成再决定是继续还是收尾。把感知、决策、执行和验证串成一个带终止条件的循环一支能自己干活的手机智能体就成型了。// 完整闭环看懂 → 决定 → 动手 → 验证直到任务完成functionrunAgent(goal,maxRounds){for(varround0;roundmaxRounds;round){varitemsreadScreen();// 本地规则能解决就不打扰云端vardone$act.selector().text(任务完成).findFirst();if(done!null){toast(目标已达成);returntrue;}varcmddecide(items,goal);if(cmd.actionclick){vartarget$act.selector().text(cmd.label).findFirst();if(target!null){$act.click(target);}}elseif(cmd.actionback){$act.back();}sleep(1200);// 等界面动画走完再验证}toast(超过最大轮次已停止);returnfalse;}$act.hasPermit()runAgent(完成每日签到并领取奖励,20);这二十几行代码就是手机自己把活干了的最小完整形态。它能在本地看懂屏幕能在岔路口请大模型拿主意能把动作稳稳落在设备上还能在每一步之后回头验证。网络好时它如虎添翼网络差时本地规则照样兜底不会因为一次断网就全盘瘫痪。旧手机才是最快落地的那台回到开头的智能体手机热。厂商们描绘的未来当然诱人但真正的自动化落地从来不靠等新硬件。AutoGod 的运行时可以跑在大量现存的安卓设备上ES5 的语法门槛低到任何写过几行 JavaScript 的人都能上手而感知、网络、动作、存储这一整套能力已经内置完毕你要做的只是把业务逻辑写清楚。对个人这意味着抽屉里那台吃灰的旧手机可以变成一个不知疲倦的助手定时签到、消息处理、资料采集、游戏挂机随叫随到。对团队和商家这意味着不必为每一个自动化任务采购昂贵的云服务或专用设备一台二手手机加一份脚本就能撑起一条 7×24 小时运转的流水线边际成本几乎为零。智能体的故事讲了两年真正的分水岭从来不是谁的对话更像人而是谁能在真实的设备、真实的网络、真实的应用面前把事情一件件做成。当别人还在等待下一台更聪明的手机发布时用 AutoGod 的人已经让手里这台旧手机自己把活干了。