1. 从桌面到口袋：AI Agent 移动化的临界点在哪
过去一年，我身边不少做 AI 应用的朋友都在反复讨论同一个问题：AI Agent 到底什么时候才能真正脱离浏览器标签页，变成一个随时能掏出来用的东西。桌面端跑得再流畅，场景始终被锁在工位上。你出门买个咖啡、挤个地铁、在超市货架前比价的时候，桌面 Agent 帮不上任何忙。而移动端不一样，它天然带着摄像头、麦克风、GPS、陀螺仪、通讯录、日历、支付能力，这些传感器和系统级权限组合起来，才是 Agent 真正能“替你办事”的物理基础。
这次引发讨论的焦点，是 OpenAI 的 dots 移动端上线。从公开信息来看，它上线五天就冲进了手机应用市场的头部位置，这个速度本身就说明了一件事：用户对“能动手的 AI”需求是真实存在的，而且远比我们这些从业者预估的要强烈。注意，这里说的不是那种只会聊天、写诗、总结文档的对话机器人，而是具备任务拆解、工具调用、跨应用操作能力的 Agent 形态。它从桌面走进口袋，意味着交互范式要从“你问我答”切换到“你说我做”。
为什么这个转变如此关键？因为桌面端的 Agent 本质上还是一个“信息处理器”，你给它一段文字、一个文件、一个网页链接，它帮你分析、归纳、生成。但移动端的 Agent 必须变成“任务执行器”，它要能打开某个应用、填写表单、比价下单、发送消息、设置提醒。这中间的技术鸿沟不是简单的界面适配，而是整个架构要从“请求-响应”模式转向“感知-规划-执行-反馈”的闭环。我实测过不少号称移动端 Agent 的产品，大部分卡在“执行”这一步——要么权限拿不到，要么跨应用操作被系统拦截，要么执行到一半状态丢失。
dots 移动端能快速起量，我判断核心原因有三个。第一，它把 Agent 的入口做得足够轻，不是让你打开一个复杂的控制台，而是像发消息一样自然。第二，它在系统权限和隐私边界之间找到了一个可用的平衡点，具体怎么做的后面会展开讲。第三，它把“任务完成率”这个指标真正当成了核心 KPI，而不是只盯着对话轮次和停留时长。这三点听起来简单，但每一点背后都是大量的工程取舍。
如果你正在做 AI 应用、移动端产品，或者单纯想搞清楚这波 Agent 移动化浪潮到底意味着什么，接下来的内容会从架构、权限、交互、落地场景、避坑经验几个维度拆开讲。我不打算复述新闻稿，而是从一个实际动手做过类似东西的人的角度，把这件事的技术骨架和实操细节摊开来说。
2. dots 移动端的任务执行链路拆解
2.1 从“对话”到“代办”的架构切换
传统聊天机器人的架构很简单：用户输入文本，模型生成回复，前端渲染。整个链路是线性的，状态管理几乎不存在。但 Agent 移动端完全不同，它需要维护一个持续的任务状态机。用户说“帮我订明天下午三点去某地的票”，这句话背后涉及意图识别、时间解析、地点确认、应用选择、参数填充、支付确认、结果回传等多个环节。每个环节都可能失败，每个失败都需要有回退策略。
dots 移动端在这块的做法，我观察到的核心思路是“分层规划 + 原子执行”。上层是一个规划器，负责把自然语言指令拆成可执行的步骤序列；下层是一组原子能力，每个能力对应一个具体的系统操作或应用调用。规划器不直接操作 UI，而是输出结构化的任务图，原子执行器再根据任务图逐步调用。这样做的好处是，规划逻辑和执行逻辑解耦，模型升级不影响执行层，执行层增加新能力也不需要重新训练规划器。
我实际复现过类似的架构，踩过最大的坑是“状态同步”。移动端应用随时可能被系统杀掉、被用户切走、被来电打断。如果任务状态只存在内存里，一切换就全丢了。dots 的做法应该是把任务状态持久化到本地数据库，同时用系统级的后台任务机制保活关键步骤。这一点在 Android 上尤其重要，因为不同厂商的后台管理策略差异极大，有的允许长时间后台运行，有的几分钟就清理。我试过用 WorkManager 加前台服务的方式保活，实测下来在主流机型上能撑住大部分短任务，但超过五分钟的长任务还是需要用户手动确认继续。
2.2 工具调用与函数注册的工程细节
Agent 要执行任务，必须能调用外部工具。在桌面端，工具调用通常走 HTTP API 或者本地函数。但在移动端，工具的定义更宽泛：可能是打开某个 App、可能是读取剪贴板、可能是调用系统相机、可能是发送一条短信。dots 移动端应该维护了一个工具注册表，每个工具包含名称、描述、参数 schema、权限要求和执行函数。
这里有个容易被忽略的细节：工具描述的质量直接决定 Agent 的调用准确率。我做过对比测试，同一个功能，工具描述写得模糊和写得精确，模型选对工具的概率能差三成以上。比如“发送消息”这个工具，如果描述只写“发送消息”，模型可能在任何涉及沟通的场景都调用它；但如果描述写成“向指定联系人发送即时通讯消息，需要提供联系人名称和消息内容，不支持邮件和短信”，模型的选择准确率会明显提升。
另一个坑是参数校验。移动端工具的参数往往涉及用户隐私和资金安全，不能完全信任模型的输出。dots 应该在执行层做了二次校验，比如金额是否超过阈值、联系人是否在通讯录中、时间是否在未来。我自己的做法是在工具执行前加一层“守卫函数”，对关键参数做规则检查，不通过就返回错误让模型重新规划。这层守卫看起来增加了复杂度，但能避免很多灾难性的误操作。
2.3 移动端特有的中断与恢复机制
桌面端 Agent 可以假设网络稳定、电源充足、用户不会突然把窗口关掉。移动端完全相反：网络可能从 Wi-Fi 切到蜂窝再切到无信号，电量可能告急，用户可能突然接电话或者切到别的 App。dots 移动端要能处理这些中断，并且在恢复后继续任务。
我实测下来，最有效的策略是“检查点 + 幂等执行”。每个原子步骤执行前，先把当前状态写入检查点；执行后，再更新检查点。如果任务中断，恢复时从最后一个检查点继续。但这里有个前提：每个原子步骤必须是幂等的，也就是重复执行不会产生副作用。比如“发送消息”这个步骤，如果执行到一半中断，恢复后不能重复发送。解决办法是在发送前先查一次是否已经发送成功，或者给每条消息生成唯一 ID，服务端去重。
dots 在这块的具体实现我没有看到公开细节，但从它上线后的用户反馈来看，任务中断恢复的体验应该做得不错。我自己的经验是，移动端 Agent 的恢复逻辑要比桌面端复杂三到五倍，因为要处理的异常分支太多了。建议在做类似产品时，把中断恢复当成一等公民来设计，而不是事后补丁。
3. 权限、隐私与系统限制的实战博弈
3.1 移动端权限模型的硬约束
做移动端 Agent，第一道坎就是系统权限。Android 和 iOS 对应用能做什么有严格限制，尤其是涉及跨应用操作、后台运行、读取其他应用数据这些能力。dots 移动端要执行“帮我叫个车”这样的任务，理论上需要打开打车应用、输入目的地、选择车型、确认呼叫。但系统不允许一个应用直接操作另一个应用的界面，除非使用无障碍服务或者系统提供的特定 API。
无障碍服务在 Android 上是可行的，但 Google Play 对它的审核非常严格，必须证明用途合理且不滥用。iOS 上则几乎没有对应的开放能力，只能通过 URL Scheme 跳转或者 Share Extension 做有限交互。这意味着 dots 在 iOS 和 Android 上的能力边界可能完全不同。我推测它在 Android 上能做的事情更多，iOS 上则更依赖应用间的标准接口。
这里有个实操建议：如果你在做类似产品，不要试图绕过系统限制。我见过一些团队用模拟点击的方式强行操作其他应用，短期能跑通，但长期面临封号、下架、法律风险。正确的做法是把 Agent 的能力限制在系统允许的范围内，通过标准接口和用户授权来完成操作。虽然能力受限，但合规性有保障。
3.2 隐私数据的本地处理与云端边界
Agent 要替用户办事，必然要接触隐私数据：通讯录、位置、日历、消息记录、支付信息。这些数据哪些在本地处理、哪些上传云端，是产品设计中最敏感的决策。dots 移动端的做法应该是“敏感操作本地决策，复杂规划云端辅助”。比如“给张三发消息”这个任务，联系人匹配可以在本地完成，消息内容生成可以云端做，但最终发送动作必须在本地触发。
我自己的经验是，把隐私数据分成三类：第一类是绝对不出本地的，比如支付密码、生物识别信息；第二类是脱敏后可上云的，比如位置信息可以只上传城市级别；第三类是可以上云的，比如用户主动输入的指令文本。这个分类要在架构设计阶段就定好，不能等产品上线了再补。
另外，移动端 Agent 的日志记录也要特别注意。为了调试和优化，通常需要记录任务执行过程，但这些日志里可能包含隐私数据。我的做法是日志分级：调试日志只存本地且加密，运营日志脱敏后上传，错误日志只记录错误码和堆栈不记录具体内容。这样既能排查问题，又不会造成隐私泄露。
3.3 后台保活与电量消耗的平衡
移动端 Agent 执行长任务时，需要后台保活。但后台保活和电量消耗是一对天然矛盾。Android 上有多种保活方案：前台服务、WorkManager、JobScheduler、AlarmManager，每种方案的保活能力和耗电水平不同。iOS 上的后台限制更严，长时间任务基本只能靠后台刷新或者用户主动保持前台。
我实测过几种方案，总结下来是：短任务（30 秒内）用前台服务加通知，用户能看到进度，系统也不会杀；中等任务（几分钟）用 WorkManager 加前台服务组合，但要在通知里给用户取消选项；长任务（超过十分钟）最好拆成多个短任务，或者明确告诉用户需要保持应用在前台。dots 移动端的具体策略我不清楚，但从它上线后的表现看，应该在这块做了不少优化。
电量消耗方面，Agent 的规划过程如果频繁调用云端模型，网络请求和模型推理都会耗电。我的建议是把一些简单的意图识别和参数解析放在本地小模型上做，只有复杂规划才走云端。这样既能省电，又能降低延迟。本地小模型可以用量化后的轻量级模型，在移动端 NPU 上跑，实测下来功耗可以控制在可接受范围内。
4. 移动 Agent 真正能落地的场景与边界
4.1 高频短任务：比价、提醒、信息查询
移动 Agent 最容易落地的场景是高频短任务，这类任务的特点是步骤少、耗时短、失败成本低。比如“帮我查一下附近哪家咖啡店评分最高”“提醒我下午四点给某人回电话”“把刚才拍的照片发到某个群”。这些任务不需要复杂的规划，原子能力就能覆盖，用户预期也明确。
我实测过用 Agent 做比价，流程是：打开购物应用、搜索商品、读取价格、对比历史价格、给出建议。这个链路在 Android 上通过无障碍服务可以跑通，但速度比手动操作慢不少，因为 Agent 需要逐步解析界面元素。如果购物应用提供了标准 API，速度会快很多。所以我的判断是，移动 Agent 在短任务上的体验，很大程度上取决于目标应用是否开放了标准接口。封闭生态里的 Agent 只能做“慢速模拟”，开放生态里才能做“快速调用”。
4.2 跨应用长链路：订票、行程规划、多步操作
跨应用长链路任务是 Agent 真正体现价值的地方，也是技术难度最高的地方。比如“帮我订一张明天下午去某地的票，然后加到日历里，再通知同行的人”。这个任务涉及票务应用、日历应用、通讯应用，中间还有支付环节。每一步都可能失败，每一步都需要用户确认。
dots 移动端在这类任务上的表现，我推测是“半自动”模式：Agent 负责规划和填充，关键步骤由用户确认。这样做虽然不够“全自动”，但安全性和成功率更高。我自己的经验是，全自动的长链路任务在移动端几乎不可行，因为系统限制太多、异常分支太多。半自动模式反而是更务实的选择，用户只需要点几下确认，比手动操作还是省事很多。
这里有个设计技巧：把长链路任务拆成多个“可确认的原子步骤”，每个步骤完成后给用户一个明确的反馈，让用户知道进行到哪了。这样即使中途失败，用户也能理解原因，而不是面对一个莫名其妙的错误。
4.3 不适合移动 Agent 的场景
不是所有任务都适合交给移动 Agent。我总结了几类不适合的场景：第一类是涉及大额资金操作的，比如转账、投资，这类操作的风险太高，用户心理上也不愿意交给 AI；第二类是涉及复杂判断的，比如医疗诊断、法律咨询，这类任务需要专业资质，Agent 只能做信息整理不能做决策；第三类是涉及敏感隐私的，比如查看私密照片、读取私密消息，用户对这类操作的授权意愿极低。
dots 移动端在上线初期应该也划定了能力边界，不会什么都做。这个边界划得好不好，直接决定用户信任度。我的建议是，宁可少做几件事，也要把能做的事做稳。用户对 Agent 的信任是一次性的，一次严重失误就可能永久流失。
5. 从 dots 的快速起量看移动 Agent 的产品化经验
5.1 入口设计：为什么“像发消息”比“像控制台”更重要
dots 移动端能快速起量，入口设计功不可没。我观察到的核心逻辑是：它把 Agent 的交互做得像发消息一样自然，而不是让用户面对一个复杂的控制台。用户不需要学习新的交互范式，不需要理解“规划器”“执行器”这些概念，只需要像跟人说话一样说出需求。
这个设计选择背后有深刻的用户心理原因。移动端用户的使用场景是碎片化的，可能只有几十秒的注意力。如果打开应用还要配置参数、选择模式、确认权限，大部分用户会直接放弃。而“像发消息”这个交互，几乎零学习成本，用户第一次打开就知道怎么用。
我自己的产品经验也验证了这一点。之前做过一个工具类应用，功能很强但入口复杂，用户留存很差。后来把入口改成类似聊天框的形式，留存率明显提升。移动端产品的第一原则是“降低启动成本”，Agent 产品尤其如此。
5.2 任务完成率：比对话轮次更关键的指标
大部分聊天机器人关注的指标是对话轮次、停留时长、日活。但 Agent 产品应该关注的是任务完成率。用户说“帮我订票”，最终票订到了没有，这才是核心。对话轮次再多，任务没完成，用户下次就不会用了。
dots 移动端上线五天冲进头部，我推测它的任务完成率应该达到了一个可用的水平。这个水平具体是多少，行业里没有统一标准，但我的经验是，短任务完成率至少要 85% 以上，长任务完成率至少要 60% 以上，用户才会觉得“这东西能用”。低于这个水平，用户会很快失去耐心。
提升任务完成率的关键在于“失败后的恢复能力”。任务失败不可怕，可怕的是失败后用户不知道怎么继续。好的 Agent 应该在失败时给出明确的解释和可选的下一步，比如“订票失败，因为该车次已售罄，是否查看其他车次？”这样用户只需要点一下就能继续，而不是重新说一遍需求。
5.3 冷启动阶段的场景选择策略
新产品冷启动，场景选择至关重要。dots 移动端上线初期应该聚焦了几个高频场景，而不是一上来就什么都做。我推测它优先覆盖的是信息查询、提醒设置、简单消息发送这类低风险、高频次的任务。这些任务容易做稳，用户也容易建立信任。
我自己的经验是，冷启动阶段选场景要满足三个条件：第一，用户需求高频，每天都会用到；第二，技术可行性高，现有能力能覆盖；第三，失败成本低，做错了不会造成严重后果。满足这三个条件的场景，才是冷启动的最佳切入点。等用户信任建立起来，再逐步扩展到更复杂的场景。
6. 自己动手复现一个移动 Agent 的关键步骤
6.1 技术选型：本地模型还是云端模型
如果你要自己做一个移动 Agent，第一个决策是模型放在哪。本地模型延迟低、隐私好、不依赖网络，但能力有限、占用存储、耗电。云端模型能力强、更新方便，但延迟高、依赖网络、隐私风险。我的建议是混合方案：意图识别和简单参数解析用本地小模型，复杂规划和内容生成用云端大模型。
本地小模型的选择上，我实测过几个轻量级方案，参数量在 1B 到 3B 之间的模型在移动端 NPU 上可以跑到可接受的延迟。关键是做好量化，把模型压缩到合适的大小。云端模型则根据任务复杂度动态选择，简单任务用便宜的小模型，复杂任务用能力强的大模型。
6.2 工具注册与权限申请的最小闭环
移动 Agent 的最小可行产品，应该包含三个核心工具：打开应用、读取屏幕内容、模拟点击。这三个工具组合起来，就能完成大部分简单的跨应用操作。但要注意，模拟点击在 Android 上需要无障碍权限，在 iOS 上基本不可行。所以 iOS 版本可能需要依赖 URL Scheme 和 Share Extension 做有限交互。
权限申请的策略是“用时申请，逐步引导”。不要一打开应用就申请一堆权限，用户会反感。应该在用户第一次使用某个功能时，再申请对应权限，并解释清楚为什么需要。我实测下来，这种“场景化申请”的通过率比“一次性申请”高很多。
6.3 任务状态机的实现要点
任务状态机是移动 Agent 的核心。我的实现方式是：每个任务有一个状态对象，包含任务 ID、当前步骤、已完成步骤、待执行步骤、上下文数据、错误信息。状态对象持久化到本地数据库，每次步骤执行前后都更新。恢复时根据状态对象重建执行上下文。
这里有个关键细节：步骤之间的数据传递要设计好。比如第一步获取了用户的位置，第二步需要用这个位置搜索附近的店。数据传递不能靠全局变量，而应该显式地存在状态对象里。这样即使应用重启，数据也不会丢。
6.4 测试与灰度：怎么判断 Agent 真的可用
Agent 的测试比普通应用复杂得多，因为输入是自然语言，输出是任务执行结果，中间还有模型的不确定性。我的测试策略是三层：第一层是单元测试，测每个原子工具的执行逻辑；第二层是集成测试，测固定指令下的任务完成率；第三层是灰度测试，让真实用户使用并收集反馈。
灰度阶段要重点关注“失败案例”。每个失败案例都要分析原因：是模型规划错了，还是工具执行失败了，还是权限不够，还是用户中途取消了。把这些原因分类统计，才能知道下一步优化方向。我自己的经验是，灰度阶段前两周的失败案例密度最高，但也是最有价值的，因为能暴露大量边界情况。
7. 移动 Agent 接下来会往哪走
从 dots 移动端的快速起量来看，AI Agent 从桌面走进口袋这件事，已经不是“会不会发生”的问题，而是“多快发生”的问题。我判断接下来一年，移动 Agent 会在三个方向加速演进。
第一个方向是系统级集成。现在 Agent 还是作为一个独立应用存在，未来可能会深度集成到操作系统里，成为系统级的智能层。这样权限问题、后台保活问题、跨应用操作问题都会得到更好的解决。但这也带来新的挑战：系统级 Agent 的隐私边界怎么划，用户信任怎么建立。
第二个方向是垂直场景深耕。通用 Agent 能力有限，但在特定场景里可以做得非常深。比如出行场景、购物场景、办公场景，每个场景都有独特的需求和约束。我预计会看到一批垂直领域的移动 Agent 产品出现，它们不追求大而全，而是在一个场景里做到极致。
第三个方向是多 Agent 协作。一个 Agent 能力有限，多个 Agent 分工协作可能完成更复杂的任务。比如一个负责规划、一个负责执行、一个负责校验。这个方向在桌面端已经有探索，移动端可能会晚一些，但趋势是明确的。
如果你正在这个领域做产品或者做技术，我的建议是：不要等所有条件都成熟再动手。移动 Agent 的基础设施还在快速变化，早入场能积累大量一手经验。但也不要盲目追热点，要找到自己真正能做出差异化的场景。这个领域最终拼的不是模型能力，而是对用户需求的理解和对系统限制的驾驭能力。
