AI Agent 在手机上的竞争已经从“语音助手能回答什么”转向“L3 级跨应用执行能不能稳定落地”。行业里把 L3 当作国标讨论的时候很多人以为这是一个很高的能力等级其实它只是在说在某些受控场景里手机 AI 可以代替用户连续操作多个应用并且每一步都处在用户监督之下。这个定位很关键。它不能像科幻片里那样完全接管手机也不需要做到因为真正难的不是让 Agent 更自主而是让它在“自主”和“可信任”之间找到平衡。下面按实际落地顺序拆一遍适合正在做手机端 Agent 的产品经理、开发以及准备把手机自动化能力接入自己业务的工程师。1. 手机 AI Agent 为什么偏偏拿 L3 当分水岭1.1 L2 是脚本L3 才是“会自己想办法”的 AgentL2 级别的自动化本质上还是规则脚本。用户设定好条件手机按固定路径执行比如“每天 8 点打开新闻 App”“到公司附近自动关闭铃声”。这些能力很稳定但可扩展性很差因为每增加一个场景就要重新写一套逻辑。L3 的关键变化是模型参与决策。用户用自然语言表达需求模型结合当前屏幕内容、应用状态和上下文生成一段可执行的动作序列再通过系统能力去操作多个 App。它不依赖事先写死的规则而是“看情况决定下一步做什么”。这才是 Agent 和普通自动化的本质区别。所以把 L3 当成手机 AI Agent 的分水岭不是因为 L3 的数字好听而是它第一次把“动态决策”引入了手机端。L0 到 L2 还可以靠工程师堆代码实现L3 开始必须依赖模型对界面、意图和工具调用的综合理解工程链路的复杂度完全不同。1.2 手机上做 L3难在系统和权限的碎片化手机端的 L3 比网页端 Agent 更难落地。网页端只需要控制浏览器DOM 结构相对稳定API 也统一。手机端要面对 Android、iOS、HarmonyOS 三套系统每套系统对跨应用控制的能力不一样第三方 App 是否开放接口也完全不可控。Android 有 AccessibilityService 和无障碍节点树可以读取界面元素并执行点击、输入、滚动等操作。iOS 只能依赖 App Intents、SiriKit 这类系统级意图通道规则严格很多。HarmonyOS 有意图框架和服务卡片但生态成熟度也还在发展。更现实的问题是很多头部 App 并没有为自动化控制预留接口Agent 只能退回到“读控件树 模拟点击”这条保守路线。控件树方案最大的问题是脆弱。App 一次 UI 升级控件 ID 可能全变之前跑通的 Agent 流程立刻失效。很多团队在 Demo 阶段没意识到这一点等真正上线才发现稳定维护一个跨应用执行器比训练模型还要耗时。这也是为什么手机厂商做 Agent 有先天优势系统级 API 是自己家的不需要绕过复杂边界。2. 跑一个 L3 级手机 Agent 前先确认这几项条件2.1 系统能力无障碍、Intent、App 内协议缺一不可L3 Agent 要操作手机前提是系统或者应用层给了“操作入口”。不同入口的稳定性排序大致是这样操作入口典型场景稳定性适用方系统级 API / Intent日历、闹钟、剪贴板、系统设置高手机厂商、系统应用App 官方接口 / 协议企业内部自研 App 的自动化较高企业开发者无障碍控件树操作第三方 App 的通用控制中低第三方 Agent 开发方坐标点击特殊情况兜底低不宜作为主要方案如果你的 Agent 主要依赖无障碍服务第一件事就是确认目标 App 的控件树是否完整。可以先用adb shell uiautomator dump导出一份当前界面 XML看看关键按钮有没有text、content-desc或resource-id。如果这些属性都很空说明后续操作识别会非常困难建议尽早换一个场景或寻找 API 路径。做多设备调试时我会优先用 scrcpy 配合 ADB 管理多台手机。它能实时投屏、录制屏幕也能通过端口区分不同设备。多台机器并行时要给每台设备独立端口和独立日志目录不然跑完一轮很难判断某个动作到底是在哪台手机上执行的。2.2 权限模型第一次做宁可多确认不要偷懒L3 Agent 需要读取屏幕、执行点击还可能读取通知、剪贴板、通讯录等敏感信息。权限设计如果一开始就没想清楚后面要么被应用商店拒审要么被用户卸载要么被系统限制。我的建议是第一版遵循“最小授权 动作前确认”两条原则。最小授权指只在需要时申请对应权限不搞“一进来就全要”。动作前确认指每个跨应用动作执行前都弹出一个“下一步要做什么”的确认提示。尤其是涉及发送消息、创建日程、删除内容这类不可逆或影响较大的操作确认步骤不能省。不要为了追求演示效果好把确认环节全部砍掉。L3 的语义本身就是用户监督下的自主执行不是后台静默控制。用户授权、可撤销、可审计这三条是底线。日志里也不要记录密码、验证码、完整聊天内容这些敏感字段只要记录动作类型、目标应用、操作结果和耗时就够了。2.3 模型与工具链模型负责决策执行器负责落地L3 Agent 的架构通常由四部分组成模型、执行器、工具集和编排层。模型负责把用户意图变成结构化动作执行器负责把动作落到系统操作上工具集是模型可以调用的能力集合编排层管理任务状态、失败重试和上下文传递。在 Hugging Face 的 Agent 术语里模型、工具、执行器这几个概念分得很清楚。很多人容易混淆的是“AI Skill”和“Agent”的区别。Skill 是一个单一能力比如“识别屏幕上的验证码”“把一段文本转成日历事件参数”Agent 是一个完整的决策循环它要决定什么时候用哪个 Skill、用完之后下一步做什么。Skill 是零件Agent 是装配流程。模型侧有两种路线。端侧模型延迟低、隐私好适合做意图识别和轻量工具调用云端模型推理能力强适合做复杂任务拆解和异常情况处理。混合路线比较常见端侧先做第一步意图判断拿不准再请求云端。如果模型只能输出自然语言不能输出结构化的工具调用 JSON那它还不适合做 L3 Agent只能做聊天助手。工具链方面UI Automator、Appium 这类工具可以承担执行层的自动化操作Charles、Fiddler、Reqable 可以抓包调试帮助确认 App 是否真正发生了正确的接口请求n8n 这类工作流工具可以放在后端承接 Agent 事件回调把模型调用、数据库写入、消息通知串起来。3. 把一个真实任务拆成 L3 流程并跑通最小闭环3.1 场景示例从备忘录提取待办并创建日程选第一个真实场景时不建议直接做“自动帮用户发消息”这种高风险任务。误操作成本太高一旦发错很难撤回。更合适的起步场景是“从备忘录提取待办事项创建日历日程”。这个任务涉及到读取文本、抽取时间、调用日历、校验结果链路完整而且创建错了也能修改用户接受度高。用户输入可以是这样一句话“帮我把会议纪要里的明天上午十点评审任务加到日历。” Agent 需要先确认有没有读取备忘录的权限再提取“明天上午十点”“评审”这些关键信息然后生成日历事件最后校验是否创建成功。为什么优先选这类场景因为它的失败是可见、可恢复的。用户能看到 Agent 到底有没有理解文本、有没有填错时间。如果第一步就做“静默跨 App 转账”一旦参数抽取错误损失不可控。做 Agent 产品第一版不是展示上限而是控制风险下限。3.2 任务执行链路意图、拆解、确认、执行、校验最小闭环建议拆成六个环节意图识别把自然语言转成结构化意图比如create_calendar_event。参数抽取从上下文中提取时间、地点、标题、参与人等关键字段。权限检查确认日历写入权限是否已授权没有就引导用户授权。执行前确认向用户展示即将创建的日程内容等待用户确认。系统调用通过日历 API 或无障碍操作创建日程。结果校验重新读取日历状态确认日程是否真的创建成功。这里最容易忽略的是第 6 步。很多 Demo 只做到“模型说执行成功”就结束了但执行器调系统接口之后App 不一定真的完成了操作。手机界面是异步加载的操作完要等 1 到 2 秒再去读取结果否则容易拿到旧页面。校验这一步没做Agent 的“完成率”就是虚的。工具描述可以按这个思路配置{ model: your-model, tools: [ { name: calendar_create_event, description: 在系统日历中创建一条日程, parameters: { title: string, start_time: string, end_time: string } }, { name: memo_read_content, description: 读取指定备忘录的内容, parameters: { doc_id: string } } ], policy: confirm_before_cross_app_execution }这段只是示例配置实际接入模型时参数格式要以所用模型为准。关键是让模型知道有哪些工具、每个工具做什么、参数需要满足什么格式。没有工具定义的模型只是一个文本生成器不是 Agent。3.3 单条任务验证先看操作序列再看结果第一轮测试不要批量跑先跑一条最简单输入观察三个东西模型输出的动作序列是否正确执行器是否把动作映射到了正确的系统操作操作完成后手机界面状态是否符合预期。如果动作序列对但执行失败问题大概率在执行层去看权限、控件 ID、API 返回。如果动作序列本身就是错的说明模型提示词或工具定义有问题不要急着调执行器。用一张表把失败场景记录清楚场景预期结果排查点日历创建成功日历出现一条日程无日历权限未授权提示用户授权权限弹窗是否被拦截控件 ID 失效找不到按钮导出当前控件树对比时间格式不匹配模型输出时间无法解析抽参规则和提示词样本App 未启动直接卡住增加启动前置检查验证时可以把任务跑 10 次记录成功次数、平均耗时、用户确认次数。不要只看一次成功就认为流程稳定。手机上 UI 变化、网络延迟、系统弹窗都可能让同一个任务走出完全不同的分支。4. 从单条任务到批量场景编排、记忆与评测4.1 任务编排不是简单的步骤列表当任务从一个动作变成多个动作时编排层就要上场了。比如“明天出差帮我查高铁班次、订闹钟、把行程发给同事”。这三个动作之间有依赖关系先查高铁确定出发时间再根据时间订闹钟最后把完整行程发出去。如果第一步失败后面的动作就没有意义。编排层要维护一个任务状态机至少包含pending、running、waiting_confirmation、succeeded、failed这几个状态。任务执行过程中如果某个动作失败先做一次轻量重试再降低操作粒度再不行就回到用户确认环节。不要一失败就从头开始跑那样既浪费时间也可能产生重复操作。批量场景下还要考虑队列和超时。比如同时给 10 台手机下发任务每台设备的网络条件、App 版本、权限状态都不一样。需要给每个任务设置超时时间超时就记录失败并进入下一个。日志里每一条都要带task_id、设备 ID、当前步骤、执行时间、错误码否则排查时只能靠猜。n8n 在批量场景里可以做后端编排。手机 Agent 把任务事件通过 Webhook 发给 n8nn8n 负责调用模型、写数据库、触发通知。这样做的好处是手机端只负责执行复杂的重试策略和状态管理放在服务端更容易横向扩展。4.2 记忆和反馈闭环L3 阶段做到什么程度比较合适很多团队一上来就想做长期记忆希望 Agent “越来越懂用户”。但在 L3 阶段记忆做太重反而容易出问题。短期记忆一定要做好。当前任务里已经执行过哪些步骤、每个步骤的结果是什么、用户刚刚确认了什么这些信息必须完整传给模型上下文否则任务中途中断后无法恢复。长期记忆可以只存用户明确授权的偏好比如“会议提醒提前 15 分钟”“常用日历是工作日历”。不要自动学习用户的私人聊天内容也不要偷偷记录用户屏幕上的敏感信息。更重要的反馈闭环是“用户修正后的学习”。当用户在执行前修改了参数或者在执行后手动撤销了某个动作系统应该把这个修正记录到任务日志里用来定位模型抽参错误、执行器操作错误、还是场景设计本身不合理。先做可观测再做自动学习顺序不要反。4.3 用评测指标判断“能不能放开给用户”判断 L3 Agent 能不能面向真实用户不能只看“能不能完成”还要看完成过程中的稳定性和安全性。我一般会用这几个核心指标指标含义参考判断任务完成率成功完成的任务 / 总任务数低于 90% 不宜大规模放开用户干涉次数完成一个任务平均需要用户确认/修正几次越高越说明模型理解不准确误操作率执行了用户没有要求的敏感动作必须趋近于 0平均耗时从接收指令到完成任务的时长超过用户容忍范围需要优化链路失败可恢复率失败后能否自动恢复或给出可操作反馈决定用户是否愿意再次使用社区里也有人拿 Harvey benchmark 这类公开 Agent 评测集做参考但手机端 Agent 和网页端 Agent 的差异很大。公开基准集往往基于浏览器和 API 任务手机端还要考虑控件树、系统弹窗、网络切换、权限回收这些问题。建议在公开基准之外自建 20 到 50 个真实手机场景覆盖不同系统版本、不同分辨率和不同 App 版本每次发版都跑一遍回归。5. 手机 Agent 落地最容易踩的坑和排查顺序5.1 UI 变化、权限回收、无障碍服务被杀手机端 Agent 的报错很多时候不是模型问题而是运行环境问题。最常见的三个坑第一个是 UI 版本升级。App 更新后之前能识别的资源 ID 失效控件树结构完全变化。解决办法是优先用语义属性定位比如text、content-desc实在不行再通过控件树层级结构做兜底尽量不要直接依赖屏幕坐标。第二个是权限回收。Android 系统会对长期不用的权限自动回收也可能在用户清理后台时关闭无障碍服务。Agent 每执行一个任务前都要先检查权限状态不能假设用户上一次授权就永远有效。第三个是无障碍服务被杀。很多手机厂商的后台管理策略很激进会杀掉长期在后台运行的辅助服务。做 Demo 时可以通过设置白名单规避但面向普通用户时这就成了一个真实的教育成本和体验成本。如果你的目标用户不是极客就要考虑降低对无障碍服务的依赖尽量走系统级 API 或 App 协议。5.2 调试时用抓包和自动化工具注意边界开发调试阶段抓包工具几乎是必须的。Charles、Fiddler、Reqable 都能查看手机 App 与服务器的请求和响应判断 Agent 某个动作到底有没有把参数正确传出去。调试完成后要记得关闭调试配置不要在生产环境保留抓包通道。抓包主要用于验证自己的接口和 Agent 行为不应该绕过证书校验也不应该收集非授权用户的数据。如果你做的是自动化测试工具也要在专用测试设备上运行不要拿真实用户手机做实验。多台手机并行测试时scrcpy 配合 ADB 是很好用的组合。它可以同时投屏多台设备也可以命令行控制方便复现某个特定机型的失败。建议每台设备建立独立 ADB 端口日志文件命名带上设备 ID 和时间戳避免多设备日志混在一起。5.3 排查链路现象、输入、环境、参数、模型碰到问题时我建议按固定顺序排查不要一上来就调模型提示词先看现象是报错、卡住、无反应还是输出了错误结果再看输入用户指令是什么当前屏幕在哪个页面权限是否正常再看环境系统版本、App 版本、网络状态、后台限制是否符合预期再看参数模型温度、超时时间、控件过滤规则、重试次数是不是设置得过于激进最后再看模型输出和执行器日志模型给出的动作序列对不对执行器实际执行了哪一步很多问题看起来像模型理解不了实际是控件树没有正确传给模型或者是网络请求超时导致界面没有加载完成。先看日志再改参数比反复改提示词高效得多。6. 给做手机 Agent 的团队先跑稳 L3再谈更高等级6.1 场景、用户确认、日志这三件事先做扎实团队资源有限时最该花时间的地方不是模型参数调优而是三层基础建设。第一层是场景选择。选一个高频、低风险、可校验的场景跑通完整闭环。不要同时铺十几个场景也不要只做“看起来炫但没法验收”的跨多 App 长链路。第二层是用户确认机制。第一版默认每个关键动作前都确认等误操作率稳定降到阈值以下再逐步放宽。确认弹窗本身也是产品体验的一部分文案要清楚说明“接下来要做什么”不要只给一个笼统的“是否授权”。第三层是结构化日志。每一条任务日志都应该记录任务 ID、步骤名称、操作内容、执行结果、耗时时长、错误信息。没有日志Agent 永远只能停留在“能跑”阶段无法进入“可维护”阶段。6.2 L3 只是起点真正的护城河是稳定性和体验闭环把 L3 写入国标讨论核心价值是让行业先对齐“什么算可用”。但达到 L3 不等于做好了一款手机 Agent 产品。从 L3 到真正好用中间还隔着稳定执行、异常恢复、用户信任和生态适配。手机厂商做 Agent 的优势在于能拿到系统级能力第三方开发者受限于系统接口往往只能在受限范围里实现 L3。如果拿不到系统级入口可以先从企业内部 App 自动化或者工具类 App 的控制能力切入先把执行器的稳定性打磨出来再寻找更开放的生态机会。L4 和 L5 的核心指标是“用户干涉率显著下降”和“复杂任务自主完成率提升”。这些方向值得关注但前提是现有 L3 任务已经连续跑了很多次失败可恢复率足够高。否则地基不稳再往上盖楼也没有意义。6.3 普通用户和开发者应该怎么理解这个“国标”对普通用户来说L3 更多是一个能力参考。看到某款手机宣传“支持 AI Agent”可以先确认它到底是只能聊天还是能真的创建日程、跨应用执行任务、并且每一步都给你确认机会。能确认、能撤销、能审计比宣传口号更重要。对开发者来说L3 是一个实际的技术门槛。它要求你同时处理模型、工具、执行器、权限、日志和评测六条链路缺一不可。如果团队资源有限我建议先别急着同时做模型、编排、执行器和记忆先把一条任务跑稳意图识别、参数抽取、权限检查、执行确认、结果校验、失败回滚。这六个环节跑通L3 就有了地基。手机 AI Agent 的下半场比的不是谁的概念更超前而是谁能在真实手机上把同一件事连续稳定地做一百遍。L3 是起点但真正拉开差距的是起点之后的稳定性、信任感和体验闭环。