1. 手机端 AI Agent 的选型困局与破局思路手机 AI Agent 这个赛道从 2024 年下半年开始明显升温到 2025 年已经从一个“能不能跑通”的验证阶段进入“到底选哪个”的工程决策阶段。我过去大半年时间先后在几台真机上折腾过 AutoGLM、DroidRun、MobileAgent、iEasyRun 这四个开源方案踩过的坑从 ADB 断连、无障碍服务被杀、截图延迟到模型幻觉导致误点几乎每个环节都翻过车。这篇文章不打算写成产品说明书而是把我实际选型、部署、调试、对比过程中积累的判断依据和操作细节摊开来讲给正在纠结“开源手机 AI Agent 怎么选”的朋友一个可参考的决策框架。先说清楚这四个东西各自是什么定位。AutoGLM 是智谱推出的手机智能体方案核心思路是用视觉语言模型理解屏幕内容再输出点击、滑动、输入等操作指令走的是“截图-理解-执行”的闭环。DroidRun 更偏向一个轻量级的 Android 自动化 Agent 框架强调用自然语言驱动 UI 操作工程结构相对简洁适合二次开发。MobileAgent 则是一个更偏研究性质的手机操作智能体强调多步推理和任务规划能力论文色彩更浓。iEasyRun 的定位介于工具和框架之间主打低门槛快速跑通对新手相对友好。这四个名字经常被放在一起比较但它们解决的问题层次其实不完全一样选型时如果只看“谁更火”很容易选错。我写这篇东西的出发点很简单网上关于这四个方案的对比要么是官方宣传口径要么是浅尝辄止的“跑了个 demo 就下结论”真正从工程落地角度讲清楚“什么场景选什么、为什么这么选、选了之后怎么调”的内容太少。所以下面我会从架构设计、核心能力、实操部署、常见故障、选型决策几个维度把我知道的、试过的、踩过的都讲出来。适合正在做手机端 AI Agent 技术选型的开发者、想基于开源方案做二次开发的产品团队以及单纯想在自己手机上跑一个能自动操作 App 的智能体的技术爱好者。2. 四个方案的核心架构与设计哲学拆解2.1 AutoGLM视觉理解驱动的端到端操作闭环AutoGLM 的技术路线很明确它把手机屏幕当成一张图片来处理用视觉语言模型直接理解当前界面然后输出结构化的操作指令。这个设计的好处是通用性强不依赖 App 的内部接口理论上任何能在屏幕上看到的东西它都能操作。坏处也很明显每一步都要截图、推理、执行延迟和 token 消耗都不低。我实测下来AutoGLM 在单步操作上的准确率确实不错尤其是对按钮、输入框、列表项的识别视觉模型的 grounding 能力比较扎实。但它的短板在于长任务规划比如“帮我在外卖 App 里点一份昨天吃过的那家店”这种需要跨页面记忆和推理的任务它容易在中途迷失。这跟它的架构有关AutoGLM 更偏向反应式操作每一步基于当前屏幕做决策全局规划能力相对弱一些。从工程角度看AutoGLM 的部署门槛中等。它需要一台能跑视觉模型的机器可以是本地 GPU也可以是远程推理服务。手机端通过 ADB 或者无障碍服务接收指令并执行。我建议如果要做生产级应用推理侧最好单独部署手机只做执行端这样稳定性和可维护性都好很多。2.2 DroidRun轻量框架派的工程友好选择DroidRun 给我的第一印象是“干净”。它的代码结构清晰模块划分合理没有太多历史包袱。核心逻辑是把自然语言指令解析成一系列 UI 操作动作然后通过 Android 的无障碍服务或者 ADB 执行。它不像 AutoGLM 那样强依赖视觉模型而是可以结合 UI 树解析和视觉理解两种方式灵活性更高。这个方案最适合的场景是二次开发。如果你想做一个垂直领域的手机 Agent比如专门处理某个电商 App 的自动下单DroidRun 的框架能让你快速接入自己的业务逻辑。它的插件机制和动作抽象层设计得比较合理改起来不痛苦。但它的缺点是开箱即用的能力不如 AutoGLM你需要自己配置模型、自己写一些适配代码对新手不算特别友好。我试过用 DroidRun 做一个自动整理相册的小工具整体开发体验不错。它的动作定义很直观比如 click、swipe、input_text 这些组合起来就能完成大部分操作。但 UI 树解析在有些 App 上会失效尤其是那些用 Flutter 或者游戏引擎渲染的界面这时候就得回退到视觉方案而 DroidRun 的视觉能力相对 AutoGLM 要弱一些。2.3 MobileAgent研究导向的多步推理智能体MobileAgent 的学术气息最浓它的核心卖点是多步推理和任务分解。它会把一个复杂任务拆成多个子任务然后逐步执行每一步都有反思和修正机制。这个思路在论文里很漂亮但实际跑起来推理链越长出错累积的概率越大。我在测试 MobileAgent 时发现它在简单任务上表现稳定比如“打开设置把亮度调到最高”这种两三步就能完成的操作它做得很好。但一旦任务超过五步比如“帮我在购物 App 里搜索一个商品对比三家店的价格选最便宜的加入购物车”它在中途就很容易因为某个页面元素没识别对而卡住。这不是 MobileAgent 独有的问题所有基于视觉的手机 Agent 都有这个毛病只是 MobileAgent 的推理链更长暴露得更明显。从选型角度MobileAgent 更适合做研究和实验不太适合直接拿来做生产工具。它的代码可读性好适合学习手机 Agent 的推理机制但工程化程度和稳定性还有提升空间。2.4 iEasyRun低门槛快速验证的入门之选iEasyRun 的定位很清晰就是让新手能最快跑起来。它的安装配置流程相对简单文档也比较友好不需要太多前置知识就能在手机上跑通一个自动操作的任务。我拿它给一个完全没接触过 Android 自动化的朋友试过大概半小时就能跑通一个自动发消息的 demo。但低门槛的代价是灵活性和深度。iEasyRun 的定制能力有限如果你想接入自己的模型或者做复杂的任务编排会发现它的扩展点不够多。它更适合做概念验证和简单自动化比如定时打卡、自动回复这类固定流程的任务。对于需要复杂推理和动态决策的场景iEasyRun 就力不从心了。2.5 四者架构对比与选型逻辑把这四个方案放在一起看它们其实覆盖了不同的需求层次。AutoGLM 是能力最全面的视觉理解强适合做通用型手机 Agent但对资源和部署要求高。DroidRun 是工程友好度最高的适合二次开发和垂直场景定制。MobileAgent 是研究价值最大的适合学习和实验。iEasyRun 是入门门槛最低的适合快速验证和简单自动化。选型时我建议先问自己三个问题第一你的任务复杂度有多高是固定流程还是需要动态决策第二你的团队技术栈是什么有没有 Android 开发和模型部署的经验第三你是要做产品还是做研究对稳定性和可维护性的要求有多高这三个问题的答案基本就能锁定方向。3. 真机部署实操从环境准备到跑通第一个任务3.1 环境准备与依赖安装的通用流程不管选哪个方案手机端 AI Agent 的部署都绕不开几个基础环节Android 设备准备、ADB 调试环境、Python 运行环境、模型推理服务。我下面按通用流程讲一遍然后针对每个方案补充差异点。首先是 Android 设备。我建议用一台专门的测试机不要用主力机因为 Agent 操作过程中可能会误点、误删风险不小。设备需要开启开发者选项和 USB 调试如果是通过 ADB 连接还要确保电脑能识别到设备。我遇到过好几次 ADB 设备列表为空的情况大部分是驱动问题或者 USB 线质量太差换根线就好了。Python 环境建议用 3.10 或 3.11太新的版本有些依赖包还没适配。虚拟环境一定要建这四个方案的依赖冲突不算严重但混在一起装还是容易出问题。模型推理服务这块如果你本地有 GPU可以用 vLLM 或者 Ollama 部署一个视觉语言模型如果没有就得考虑用远程 API但要注意延迟和成本。# 通用环境准备示例 conda create -n mobile-agent python3.10 conda activate mobile-agent pip install adbutils pillow opencv-python # 根据具体方案安装对应依赖ADB 连接稳定性是个大坑。我试过用 USB 连接跑长任务中途断连导致任务失败的情况不少。后来改用无线 ADB稳定性反而更好但需要确保手机和电脑在同一网络下而且手机不能锁屏。这里有个细节很多手机在锁屏后会限制 ADB 操作所以要么设置常亮要么用无障碍服务方案绕过。3.2 AutoGLM 部署要点与模型配置AutoGLM 的部署核心是模型服务。官方提供了推理代码你需要准备一个能跑视觉语言模型的 GPU 环境。我用的是一张 24G 显存的卡跑 7B 级别的视觉模型基本够用但如果要更高的准确率可能需要更大的模型显存需求也会上去。配置模型服务时要注意推理框架的选择。我试过用 vLLM 部署吞吐量不错但视觉模型的图片预处理部分需要自己处理。AutoGLM 的输入是截图输出是操作指令这个链路里图片编码的质量直接影响识别准确率。我建议截图分辨率不要太高1080P 左右就够了太高反而增加推理时间而且模型对过大图片的细节识别不一定更好。手机端执行部分AutoGLM 支持 ADB 和无障碍服务两种方式。ADB 方式部署简单但依赖电脑中转不适合独立运行。无障碍服务方式可以在手机上独立跑但需要安装一个辅助 App而且不同厂商的省电策略可能会杀掉服务。我在小米和华为上都遇到过无障碍服务被系统清理的情况需要在设置里把 App 加入白名单。3.3 DroidRun 的框架接入与动作扩展DroidRun 的部署相对轻量它不强制要求视觉模型可以先从 UI 树解析入手。安装完依赖后你需要配置一个 LLM 来做指令解析这个可以用 API 也可以用本地模型。我建议先用 API 跑通流程再考虑本地化。DroidRun 的动作扩展是我最喜欢的地方。它把每个操作抽象成一个 action你可以在配置文件里定义新的 action比如“滚动到指定元素”、“等待某个文本出现”等。这个设计让复杂任务的编排变得很直观。我做过一个自动填写表单的任务就是把 input_text、click、wait 这几个 action 组合起来写成一个 YAML 配置跑起来很稳。但 DroidRun 的 UI 树解析有个坑不同 App 的 UI 树结构差异很大有些 App 会把关键元素藏在很深的层级里解析起来很慢。我建议在配置里加上超时和重试机制避免某个元素找不到就整个任务卡死。3.4 MobileAgent 的推理链配置与调试MobileAgent 的部署重点在推理链的配置。它需要一个能支持多步推理的 LLM而且对模型的指令遵循能力要求比较高。我用 GPT-4 级别的模型跑过效果明显比小模型好但成本也上去了。如果要做本地部署建议至少用 13B 以上的模型7B 的模型在多步推理上容易跑偏。调试 MobileAgent 时日志是关键。它会把每一步的推理过程打出来包括当前屏幕理解、子任务分解、动作选择等。我建议把这些日志保存下来任务失败时回看能很快定位是哪一步出了问题。我遇到过好几次是模型对某个按钮的功能理解错了导致后续步骤全错这种问题看日志一眼就能发现。3.5 iEasyRun 的快速上手与限制iEasyRun 的部署是最简单的基本就是下载、安装、配置模型 API、跑 demo。它的文档里有一个快速开始指南跟着做半小时内能跑通。但它的限制也很明显任务编排能力弱不支持复杂的条件分支和循环只能做线性的操作序列。我用 iEasyRun 做过一个自动签到任务流程是打开 App、点击签到按钮、关闭 App这种固定流程它做得很好。但我想加一个“如果已经签到就跳过”的逻辑就发现它不支持条件判断只能通过外部脚本来控制。所以 iEasyRun 适合做最简单的自动化复杂一点的需求就得换方案。4. 性能、稳定性与成本的真实对比4.1 任务成功率与响应延迟实测我在同一台测试机上用相同的网络环境和模型服务对四个方案做了对比测试。测试任务是十个常见的手机操作包括打开 App、搜索、点击、输入、滑动等。每个任务跑十次统计成功率和平均响应时间。方案简单任务成功率复杂任务成功率平均单步延迟部署难度AutoGLM92%65%1.8s中高DroidRun88%58%1.2s中MobileAgent85%52%2.5s中高iEasyRun90%35%0.9s低这个数据只是我个人的测试结果不代表绝对水平但能看出一些趋势。AutoGLM 在简单任务上成功率最高视觉理解确实有优势。DroidRun 延迟最低因为 UI 树解析比视觉推理快。MobileAgent 延迟最高多步推理的代价。iEasyRun 简单任务不错但复杂任务掉得厉害。响应延迟这块除了模型推理时间还要算上截图、ADB 传输、动作执行的时间。我实测下来截图和传输大概占 300-500ms模型推理占大头。如果模型服务在远程网络延迟也要算进去整体延迟会明显上升。4.2 资源占用与运行成本分析资源占用方面AutoGLM 和 MobileAgent 对 GPU 的要求最高因为视觉模型和多步推理都需要算力。DroidRun 如果只用 UI 树解析CPU 就能跑成本最低。iEasyRun 依赖外部 API本地资源占用少但 API 调用成本要考虑。我算过一笔账如果用 API 跑 AutoGLM一个中等复杂度的任务大概消耗 5000-10000 token按当前价格算单次任务成本在几分钱到一毛钱之间。如果任务量大这个成本会累积。本地部署的话主要是 GPU 折旧和电费长期看更划算但前期投入高。DroidRun 如果用 UI 树解析加小模型成本可以压得很低。我试过用本地 7B 模型跑 DroidRun单次任务成本几乎可以忽略但准确率会下降一些。这是个典型的成本与效果的权衡。4.3 稳定性与异常恢复能力稳定性是手机 Agent 最头疼的问题。我遇到过的情况包括ADB 断连、无障碍服务被杀、截图黑屏、模型返回格式错误、App 弹窗干扰等。四个方案里DroidRun 的异常处理机制相对完善它有重试和超时配置任务失败后能给出比较清晰的错误信息。AutoGLM 的异常恢复能力一般出错后往往需要人工介入。MobileAgent 因为推理链长出错点更多。iEasyRun 基本没有异常恢复出错就停。我建议不管选哪个方案都要加一层外部的监控和重启机制。比如用一个脚本定时检查 Agent 进程是否存活挂了就自动重启。还有就是任务级别的重试单个任务失败后不要直接放弃可以重试两到三次很多时候重试就能成功。5. 常见问题排查与避坑经验实录5.1 ADB 连接类问题速查ADB 问题是最高频的故障。我整理了一个速查表覆盖大部分场景。问题现象可能原因解决方法设备列表为空驱动未安装或 USB 线故障重装驱动换线换 USB 口设备显示 unauthorized未授权调试手机上确认授权弹窗连接频繁断开USB 供电不足或线材质量差换高质量线用无线 ADB无线 ADB 连不上网络不通或端口未开检查同一网段重新配对截图返回黑屏权限不足或屏幕未亮检查权限唤醒屏幕无线 ADB 的配对流程稍微麻烦一点但稳定性确实更好。配对时需要先在手机上开启无线调试拿到配对码和端口然后在电脑上执行配对命令。配对成功后就可以拔掉 USB 线了。注意手机重启后无线 ADB 会失效需要重新配对。5.2 无障碍服务被杀与保活技巧无障碍服务被系统杀掉是另一个高频问题。不同厂商的省电策略不一样小米、华为、OPPO 都比较激进。我的经验是把 Agent App 加入电池优化白名单然后在最近任务里锁定能大幅降低被杀的概率。另外有些系统会在锁屏后限制无障碍服务所以测试时最好设置屏幕常亮。如果还是被杀可以考虑用 ADB 方式替代无障碍服务。ADB 方式不依赖手机端的服务只要电脑连着就能跑。但 ADB 方式不能独立运行必须有一台电脑做中转。如果要做独立运行的 Agent无障碍服务是绕不开的只能在保活上下功夫。5.3 模型幻觉与误操作的防范模型幻觉导致的误操作是手机 Agent 的固有风险。我遇到过模型把“删除”按钮识别成“确认”按钮结果把数据删了。防范措施有几个一是关键操作加确认机制比如删除前先截图给用户确认二是限制 Agent 的操作范围比如只允许在特定 App 内操作三是做好数据备份尤其是涉及文件和数据修改的任务。还有一个技巧是在 prompt 里加约束明确告诉模型哪些操作是危险的需要谨慎。比如“不要点击任何包含删除、清空、重置字样的按钮”。这个不能完全避免误操作但能降低概率。5.4 任务卡死与超时处理任务卡死的原因很多可能是元素找不到、页面加载慢、模型返回格式错误等。我的处理方式是给每个步骤加超时超时后截图保存现场然后跳过或重试。DroidRun 在这方面配置比较灵活可以针对每个 action 设置超时时间。AutoGLM 和 MobileAgent 需要自己在代码里加超时逻辑。截图保存现场这个习惯很重要。任务失败时看一眼失败瞬间的截图基本就能判断是识别错了还是页面没加载出来。我调试的时候会开一个目录专门存失败截图积累多了就能发现规律比如某个 App 的某个页面总是识别失败那就针对性地优化。6. 选型决策框架与场景化建议6.1 按任务复杂度选型如果你的任务主要是固定流程的自动化比如定时打卡、自动回复、批量操作iEasyRun 或 DroidRun 就够了没必要上 AutoGLM 这种重方案。固定流程的任务对推理能力要求低用轻量方案成本更低、稳定性更好。如果任务需要动态决策比如根据屏幕内容判断下一步操作那就需要视觉理解能力强的方案AutoGLM 是首选。如果任务还需要多步规划和反思MobileAgent 的推理链设计更合适但要接受更高的延迟和更低的稳定性。6.2 按团队技术栈选型团队如果有 Android 开发经验DroidRun 的接入会很顺它的框架设计对 Android 开发者友好。如果团队更偏 AI 和模型方向AutoGLM 和 MobileAgent 的模型配置和调优会更顺手。如果团队没有太多技术储备只是想快速验证一个想法iEasyRun 是最低门槛的选择。6.3 按部署环境选型本地有 GPU 的话AutoGLM 和 MobileAgent 可以本地部署数据不出内网适合对隐私要求高的场景。如果没有 GPUDroidRun 可以纯 CPU 跑或者用 API。iEasyRun 依赖 API适合能接受外部服务的场景。6.4 混合方案的可能性实际项目中不一定只选一个方案。我试过用 DroidRun 做框架接入 AutoGLM 的视觉模型做屏幕理解效果比单用 DroidRun 好。这种混合方案的好处是取长补短坏处是集成复杂度高。如果团队有精力可以尝试如果追求快速落地还是选一个方案深耕更实际。7. 手机 Agent 后续扩展与个人经验分享手机 AI Agent 这个方向目前还处于快速迭代阶段四个方案都在持续更新。我个人的判断是未来一两年内视觉理解和 UI 树解析会逐渐融合单纯依赖一种方式的方案会慢慢失去优势。另外端侧模型的能力在快速提升未来手机本地跑一个轻量视觉模型做 Agent 推理不是不可能的事。我在实际使用中最大的体会是不要追求一步到位。先跑通一个最简单的任务比如自动打开一个 App 并点击某个按钮然后再逐步增加复杂度。每增加一个步骤都要重新测试稳定性。很多问题是在复杂度上升后才暴露出来的一开始就跑复杂任务调试起来会很痛苦。还有一个经验是日志和截图一定要留好。手机 Agent 的调试不像传统软件很多问题是视觉层面的没有截图很难定位。我现在的习惯是每个任务都开日志和截图记录失败时回看效率高很多。最后分享一个小技巧如果任务涉及多个 App 的切换建议在每个 App 的操作完成后加一个“回到桌面”的动作这样能避免 App 之间的状态干扰。这个细节看起来不起眼但能明显提升多 App 任务的稳定性。