On-Device Mobile Agent

What is it（这是什么）

On-Device Mobile Agent 指的是直接跑在手机本地、由端侧模型驱动、能代替用户操作 App 和网页的 AI 智能体。它和云端 Agent 的本质区别在于：推理和执行都在设备上完成，不上传屏幕内容、不依赖网络往返，用户数据不出手机。技术栈上以 Kotlin + Android 原生能力为主，通过无障碍服务（Accessibility Service）、屏幕理解、意图规划来"看懂界面、点对点操作"。商业意义在于：它把 AI Agent 从"聊天框"变成"操作系统级入口"，谁掌握了这个入口，谁就掌握了移动端流量分发的下一层。对独立开发者而言，这是一个尚未被大厂产品化的空白地带。

Why now（为什么现在出现）

三个条件在 2026 年同时成熟。第一，端侧模型能力跨过临界点：7B 级别量化模型在旗舰 Android 设备上可以做到 20+ tokens/s，足以支撑屏幕理解和多步规划。第二，Android 无障碍与自动化 API 长期存在但一直被"手动脚本"（如 Auto.js、Tasker）占据，缺少 LLM 驱动的通用层。第三，云端 Agent（如各家手机助手）因隐私和延迟问题在真实操作场景体验不佳，用户对"本地执行"的诉求被 Mika、Terminal Spike 这类项目验证。为什么不是一年前：2025 年端侧模型还跑不动复杂屏幕推理；为什么不是一年后：一旦 Google 在 Android 系统层内置 Agent 框架，第三方窗口立即关闭。当前处于"技术可行、生态未定"的 6-12 个月黄金窗口。

Market Evidence（市场证据）

信号层面：2 个独立信源（v2ex、github）产生 2 次提及，增长率 100%，首次发现于 2026-11-09，成熟度 nascent。这个数据量很小，必须诚实解读——它证明的是"有人在讨论并动手做"，而不是"市场已经形成"。信源质量上，v2ex 代表中文开发者社区的真实动手意愿，github 代表有可运行代码产出（Mika、Terminal Spike 均为实际项目），这比纯媒体报道或推特转发更有含金量。判断：这是真实的技术需求信号，但尚处极早期，属于"早期采用者在自建工具"阶段，距离大众市场还有 12-18 个月。机会分、市场分、竞争分、需求分均为 0/100，说明现有评估体系尚未捕捉到该品类的商业化数据，这正是独立开发者的信息差红利。

Who's Behind It（谁在推动）

推动方分三层。第一层是独立开发者与开源社区：Mika（Android 端侧 agent 操作 app/网页）和 Terminal Spike（Android 终端内置 AI Agent）是当前最直接的信号源，均来自 github/v2ex 生态，属于"个人或小团队自建"。第二层是端侧模型提供方：Gemma、Qwen 端侧版本、Llama.cpp 生态，它们提供了推理底座但没有做上层 Agent 产品。第三层是潜在"庄家"：Google（Android 系统级 Agent）、三星、以及国内手机厂商的 AI 助手团队。当前的"庄家"是开源社区——因为没有商业公司把端侧 Agent 作为独立产品推出。这意味着标准、协议、最佳实践都还没被定义，先定义者得利。

TAM & Market Size（市场规模）

潜在用户分两类。第一类是"自动化重度用户"：Tasker、Auto.js、快捷指令的存量用户，全球规模约 500 万-1000 万，付费意愿中等（愿为工具付 5-15 美元/月）。第二类是"效率型普通用户"：需要跨 App 完成重复任务（填表、比价、批量操作）的人群，规模上亿但付费意愿低。当前需求分 0/100 反映的是"需求尚未被验证和量化"，而非"没有需求"。市场规模判断：这是一个增长中的早期市场，2026 年可服务市场（SAM）约 1-3 亿美元（自动化工具 + AI 助手交叉地带），3 年后若端侧 Agent 成为标配入口，TAM 可达 50 亿美元以上。独立开发者应瞄准第一类用户，他们的预算明确、痛点清晰、愿意为"省时间"付费。

Competitive Landscape（竞争格局）

现有玩家分三类。第一类：脚本自动化工具（Tasker、Auto.js、MacroDroid），优势是生态成熟、用户基数大，劣势是无 LLM 理解能力、配置门槛高。第二类：云端手机助手（各家厂商 AI 助手），优势是资源充足，劣势是隐私顾虑、延迟高、操作能力弱。第三类：新兴端侧 Agent 项目（Mika、Terminal Spike），优势是原生 AI 驱动、本地执行，劣势是极早期、无产品化、无商业模式。竞争分 0/100 说明这个赛道还没有形成有效竞争。市场空白非常明确：面向普通用户的、开箱即用的端侧 Agent 产品尚不存在。大公司（Google）会在 12-18 个月内进入系统层，但系统层做的是"通用能力"，第三方做的是"垂直场景 + 更好体验"，时间窗口约 12 个月。

Business Model（商业模式）

推荐"免费增值 + 订阅制"组合。理由：端侧 Agent 是高频工具，用户需要先体验"它真能帮我操作 App"才会付费，纯买断制获客成本过高。定价建议：免费版限每日 20 次自动化任务、3 个预设流程；Pro 版 9.9 美元/月或 79 美元/年，解锁无限任务、自定义流程、多 App 编排；Team 版 19.9 美元/月/席位，面向小团队共享流程模板。依据：对标 Tasker（一次性 3.49 美元但用户抱怨更新慢）和 AI 工具订阅均价（10-20 美元/月），端侧 Agent 的价值高于脚本工具，定价可上探。

12 个月收入预测：保守 3000 美元/月（300 付费用户 × 10 美元）；基准 1.2 万美元/月（1200 付费用户）；乐观 4 万美元/月（4000 付费用户，含企业版）。用户获取成本估算：ASO + 开发者社区内容营销，CAC 约 8-15 美元；按 10 美元/月订阅、月流失 8% 计算，回本周期约 2-3 个月，模型健康。

MVP Blueprint（MVP 蓝图）

核心功能（只做必须的）：1）基于无障碍服务的屏幕读取与点击执行；2）自然语言指令 → 多步操作规划的本地推理（接入端侧小模型或云端 API 兜底）；3）3 个内置高频流程模板（如"自动填写表单""批量比价""定时签到"）；4）执行日志与回放。砍掉：多设备同步、复杂条件分支、插件市场。

技术栈：Kotlin + Jetpack Compose（UI）、AccessibilityService（执行层）、MediaPipe/Gemma 端侧推理或 Qwen API 兜底、Room（本地存储）、Firebase（账号与订阅）。部署走 Google Play 内测轨道。

最快上线路径：用开源项目 Mika 的架构做参考（github 可查），3 天完成无障碍执行骨架，2 天接入模型规划，1 天做订阅墙（RevenueCat），1 天打磨 3 个模板，第 7 天发内测。建议产品类型为 Tool + API（后期开放流程编排 API 给开发者）。

Commercial Opportunities（商业化机会）

方向一：端侧 Agent 流程模板商店。 产品：预置"自动报销填单""跨 App 比价下单""社媒批量发布"等流程，用户一键启用。目标用户：行政、运营、电商从业者。预期月收入 5000-15000 美元（模板订阅 + 抽佣）。优于其他方向的原因：模板是即用型价值，降低用户学习成本，且可 UGC 扩展形成网络效应。

方向二：企业内自动化 Agent SDK。 产品：把端侧 Agent 能力封装成 API，供企业 App 集成（如自动处理客服工单截图）。目标用户：中小企业 IT 与 SaaS 厂商。预期月收入 3000-10000 美元。优势：B 端付费意愿强、粘性高，避开 C 端获客红海。

方向三：隐私优先的"本地自动化"卖点工具。 产品：强调"数据不出手机"的自动化助手，主打金融、医疗等敏感行业用户。预期月收入 2000-8000 美元。优势：差异化定位清晰，云端 Agent 无法复制。

Product Ideas（产品创意）

🥇 PocketPilot — 一句话价值主张："说一句话，手机自己把事办完。"目标用户：需要跨 App 重复操作的职场人（填表、报销、签到）。为什么现在：端侧模型刚够用，系统层 Agent 未落地，先发者定义体验。MVP 聚焦 5 个高频模板。

🥈 FlowKit — 一句话价值主张："把你的手机操作流程，变成可分享的自动化模板。"目标用户：自动化爱好者与运营人员。为什么现在：Tasker 用户苦于配置门槛，LLM 让"自然语言建流程"成为可能，模板社区可形成护城河。

🥉 AgentGuard — 一句话价值主张："全程本地执行的手机 AI 助手，屏幕内容永不上传。"目标用户：金融、法务、医疗等隐私敏感从业者。为什么现在：云端 Agent 的隐私争议正在放大，本地执行是唯一可信解法，且企业采购有明确合规预算。

SEO Opportunity（SEO 机会）

搜索量趋势：上升（新兴品类，搜索基数小但增速快）。有价值长尾词："Android 端侧 AI Agent""手机本地自动化 无需 root""on-device AI agent Android""手机自动操作 App 工具""隐私优先 手机 AI 助手"。竞争程度：SEO 难度 0/100，几乎无竞争内容。内容策略：优先做"教程型"页面（如何在 Android 上实现本地自动化）和"对比型"页面（端侧 vs 云端 Agent），这类页面转化意图强、易获排名，配合 github 项目页做外链。

Risk Assessment（风险评估）

判断可能出错的情形：端侧模型能力被高估（复杂屏幕理解仍不准），或 Google 提前在 Android 系统层内置 Agent 导致第三方无生存空间。

三大风险：技术风险——无障碍服务在不同厂商 ROM 上兼容性差、被系统限制；市场风险——用户对"AI 代操作"信任不足，付费转化低；执行风险——独立开发者难以维护多机型适配与模型更新。

最低成本验证：用 1 周做一个只支持 3 个模板、单机型的 demo，发到 v2ex 和 Reddit 的 r/androidapps，看 7 天内是否有 50+ 人主动索取内测资格。放弃信号：若 2 周内无 100 人等待名单、或 Google 发布系统级 Agent 框架的公开测试，立即转向垂直场景（如企业 SDK）。

Action Plan（行动建议）

第一步（今天）：clone Mika 或 Terminal Spike 的 github 仓库，在自己的 Android 手机上跑通一次"自动打开某 App 并点击某按钮"，确认无障碍链路可用。

低成本验证（第 1 周）：基于跑通的链路，做一个"自动填表"单模板 demo，录制 30 秒演示视频，发到 v2ex 和 Reddit，收集内测意向。目标：50 人留邮箱。

信号确认后第二步（第 2-4 周）：做 MVP（3 模板 + 订阅墙），上 Google Play 内测，目标 200 内测用户、10 个付费。

时间线：第一周完成技术验证与需求测试；第一个月完成 MVP 并上线内测；第三个月达到 300 付费用户、月收入 3000 美元，同时评估是否转向企业 SDK。若第三个月付费转化低于 1%，停止投入。

Related Terms（相关趋势）

• On-Device LLM — 底层依赖关系，端侧 Agent 的推理能力直接受端侧模型能力约束
• AI Agent — 父领域，On-Device Mobile Agent 是其在移动端的本地化子集
• Accessibility Service Automation — 互补关系，是端侧 Agent 执行层的技术基础，两者常一起出现