先说结论
手机 AI Agent（能自己操作 App 的智能体）真正难的不是「能不能点」，而是「养不养得起」。每说一句话都要过一遍大模型，把单次操作成本压下来，是这类产品从 Demo 走向商用的分水岭。侠客工坊的做法是端云分工：能本地做的坚决不上云，云上只保留不可替代的规划能力。
一次「帮我点杯美式」的成本链条
用户对手机说「帮我点一杯之前常喝的美式外卖」，Agent 实际要完成六件事：
- 屏幕感知：看懂当前界面（截图 + 视觉理解，或无障碍事件解析）
- 意图解析：把口语翻译成「用 XX 外卖 App、选美式、默认地址、老账号」
- 任务规划：拆成一步步可执行的操作序列
- 操作执行：逐步骤点击、填充、滑动
- 状态校验：确认每一步真的点到了
- 风险确认：付款、发消息前弹窗让人点头
把成本摊到这张表上：
| 环节 | 跑在哪 | 成本性质 |
| 屏幕感知 | 端侧 | 算力为主，可复用缓存 |
| 意图解析 | 云端 | LLM API，单次大头 |
| 任务规划 | 云端 | LLM API，单次大头 |
| 操作执行 | 端侧 | 接近零 |
| 状态校验 | 端侧 | 接近零 |
| 风险确认 | 端侧 | 接近零 |
结论很直接：钱几乎全部花在云端的大模型调用上，一次复杂任务可能吃掉 1500~3000 token 的输入 + 几百 token 的输出。真正高频、重复的感知和执行环节，反而几乎不花钱。
四种把成本压下来的做法
一、能本地做的不上云。 屏幕理解、点击执行、状态校验这些环节，端侧的轻量模型 + 无障碍事件足够胜任，完全不必每步都问云端。侠客工坊把这类操作全部留在端侧，云上只管「下一步该干什么」这一个问题。
二、意图解析分层。 高频指令（点外卖、查社保、发红包）用可复用的模板和短提示词命中，只有复杂、没见过的新指令才走完整长上下文规划。实测下来，八成的日常指令根本不需要长上下文。
三、敏感操作本地化。 通讯录、支付确认、账号密码这类数据不离开手机——成本上是省了，更重要的是信任问题解决了：用户不需要把自己的隐私交给第三方，Agent 只在必要时刻把「已完成、请确认」的结果展示出来。
四、缓存与批处理。 常驻场景（比如每天同一家店）的规划结果可以缓存复用，同类任务的系统提示词也共用一份，避免每次重复支付大段上下文费用。
端云分工：哪部分该上云，哪部分该留在端侧
端云分工不是「越大模型越聪明就越好」，核心原则是把不可替代的智能放云上，把可以本地化的一切留在本地：
- 端侧负责：视觉感知、指令与执行的闭环、状态校验、关键操作确认。特点：确定性高、重复性强、涉及隐私。
- 云端负责：开放式意图理解、跨 App 的复杂任务编排。特点：需要大模型的抽象能力，且不涉及用户敏感数据本身。
这样分工后，单次操作成本能压到本地化的水平，同时保留了大模型带来的泛化能力。对开发者来说，这个原则比「端侧部署一个大模型」或「全部上云」都更实用——前者成本低但能力有限，后者能力强但养不起用户。
一个可落地的参考
侠客工坊目前的 Android 版就是按这套思路做的：约 10 分钟一键部署，装好后用户用自然语言指挥手机，覆盖点外卖、订高铁票、发红包、查社保这类日常高频场景；付款、发消息等关键操作会停下来等人工确认。它的取舍很明确：不追求「全自动无人干预」的噱头，而是把「AI 干活快 + 人来把关少」做成可运营的组合。
给开发者的建议
- 上线前先算一笔单用户日成本账，别等用户量上来再改架构
- 大量小操作优先走端侧轻量方案，云端只做「决策」
- 隐私与成本往往同方向：数据不出端，既省钱又解决信任
- 用「人工确认关键操作」换运营合规，也是换成本天花板
手机 Agent 的竞争，最后会从「谁更聪明」卷到「谁更便宜还更靠谱」。端云分工，是当前技术条件下最现实的答案。
