opendroid
JMAN730/opendroid加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一个场景：下班路上突降暴雨，你腾不出手操作手机。以往的做法是艰难地单手解锁、找到天气应用、确认降雨概率，再打开微信给妻子发消息说会晚到家，最后还要记得设一个6点的闹钟提醒自己接孩子。
现在，如果手机能听懂这样一句话呢——
"帮我查一下明天天气，如果下雨就发微信告诉妻子我晚半小时到家，并设一个下午6点的闹钟。"
这就是 OpenDroid 正在做的事：不是回答问题，而是替你完成任务。
OpenDroid 不是一个聊天机器人，而是一个扎根在你 Android 手机里的自主行动型 AI 代理。它由印度开发者 yashab-cyber 构建，于 GitHub 开源，迄今已收获超过 1000 颗星，发布在 Product Hunt 首页，并在 Discord 上积累了活跃社区。
它的核心逻辑是「计划—执行—验证—适应」的闭环：用户给出一个模糊的高层目标，OpenDroid 自动拆解成多个子步骤，按依赖顺序执行，遇到失败就重新规划，全程无需人工介入。
例如，当你发出「帮我订明天早上8点去上海的火车票」这样的指令时，OpenDroid 会自动打开铁路订票 App、填入出发地和目的地、选择日期和班次、一步步完成支付流程——这一切都在后台透明完成，遇到验证码或付款失败，它会主动停下来等待你确认。
与那些「联网才能用」的 AI 助手不同，OpenDroid 支持本地模型推理。用户可以在手机上直接部署 Ollama 或 Google LiteRT 模型，让 AI 在完全离线环境下运行，通讯录、短信、照片等敏感数据永远不会离开设备。
LiteRT 模型管理器提供了完整的下载管理能力：后台 WorkManager 负责断点续传、支持 Wi-Fi 和移动网络切换、下载完成后自动 SHA-256 校验完整性，确保模型未被篡改才允许加载。Hugging Face 上的私有模型也可以通过 Android Keystore AES-GCM 加密的 Token 库安全拉取。
对于算力有限的老旧设备，OpenDroid 还支持远程 LLM 接入——Anthropic Claude、OpenAI GPT、Google Gemini、Groq、Mistral、DeepSeek 等主流模型均可动态切换，实时显示各提供商的延迟和 Token 消耗指标。
Android 的开放性给了 OpenDroid 两套互补的「感知—操作」手段：
**Accessibility Service（无障碍服务）**是它的主键盘。当系统 API 不足以完成任务时（如操作第三方 App），OpenDroid 通过无障碍服务读取屏幕节点树，定位按钮坐标，执行点击、滑动、输入文本等操作，相当于「盲操作」——即使 App 没有开放任何 API，OpenDroid 依然能操控它。这与 PC 上 AutoHotkey 的思路异曲同工。
视觉引擎则是它的眼睛。借助截图 + 多模态 LLM，OpenDroid 能够「看见」屏幕内容，提取截图中的结构化信息（会议标题、日期、地址、待办事项），存入个人知识图谱。当用户说「帮我记住这个航班信息」时，视觉引擎将图片中的文字抽取并持久化存储。
OpenDroid 构建了一套四层个人知识图谱，分层次管理不同敏感级别的信息：
| 层级 | 名称 | 特点 |
|---|---|---|
| Level 1 | 临时记忆 | 当前计划的上下文，任务结束即清除 |
| Level 2 | 长期记忆 | 用户明确告知的事实和偏好，如工作单位、家人名字 |
| Level 3 | 学习模式 | 从重复行为中推断出的习惯规律，如「每天9点会打开邮件」 |
| Level 4 | 敏感数据 | 密码、支付信息、身份证号等，用硬件级 Keystore AES-256-GCM 加密 |
第四层数据存储在 TEE（可信执行环境）中，即使手机被 root 提取了 SQLite 数据库，攻击者也无法解密这些信息。
OpenDroid 的设备控制能力几乎覆盖了 Android 手机的每一个角落：
此外，OpenDroid 还能主动发现你的习惯。系统会持续分析你的 App 使用时序，发现 Gmail → Calendar → Slack 这样的固定早间序列后，主动询问：「我注意到你每天9点都会做这几个操作，要我帮你自动化吗？」用户一键确认后，系统将这个序列固化为定时宏，每天自动执行并推送早间简报。
技术层面，OpenDroid 不是一个脚本或快捷方式集合，而是一个基于现代化 Android 架构构建的完整应用：
离线语音唤醒词检测是另一个亮点：用户说出「OpenDroid」即可激活，语音识别和合成完全在本地运行，结合 ElevenLabs 云端语音可选，实现全链路的本地化交互。
透明地讲，OpenDroid 也面临几类现实问题：
无障碍 API 的脆弱性。Google 每次更新 Android 系统都可能修改无障碍服务的行为节点，导致原本能点击的按钮位置偏移或节点名称变更。这类「自动化漂移」需要用户手动重新校准，增加了维护成本。
多模态 LLM 的速度瓶颈。屏幕截图 + 视觉模型的分析链路通常耗时 3-10 秒，在网速不佳或本地模型性能有限的情况下，体验会明显下降。OpenDroid 在 UI 上实时显示各提供商的延迟指标，让用户了解当前性能状态。
隐私边界需要用户主动把控。无障碍服务本质上授予了 App 极高的系统权限，用户需要在「功能强大」和「权限风险」之间做出判断。OpenDroid 的第四层加密机制缓解了数据泄露风险，但 App 本身的代码安全和权限最小化仍然需要持续审查。
社交媒体自动化平台政策风险。AI 代理批量操作 X、Instagram 等平台的账号，活跃频率如果接近或超出平台限制，可能触发封号。RELEASE 文档中提及了 3 档自动化级别（SAFE / APPROVAL / AUTONOMOUS），用户应从低档位开始评估。
2025-2026 年是 AI Agent 元年，但大多数 Agent 产品都以云服务形式运行，用户的数据和决策权被平台绑定。OpenDroid 的出现代表了一种对立的路线：完全运行在用户自己的设备上。
它的增长轨迹值得关注：从最初的简单自动化脚本，到 v1.0.7 版本的社交媒体管理矩阵，12 个月内完成了从「帮我查天气」到「帮我打理七个平台的内容运营」的能力跃迁。这种速度说明，开源社区的协作模式在 AI Agent 领域同样有效。
对于开发者而言，OpenDroid 的代码库本身也是一份高质量的 Android 架构参考——它展示了如何在大规模 Kotlin 项目中组织 Hilt DI、Room 多表迁移、Kotlin 2.x 协程与 Flow、以及 Jetpack Compose 响应式 UI。
数据来源：GitHub (stars=1083, updated=2026-09-04)，README.md v1.0.7，RELEASE.md，website docs。
