2007 星手机 Agent：能干活，但商用先签许可

上个月本站拆过一个手机 Agent，走的是 iPhone 路线：phone-harness 让 Mac 上的 Claude Code 操控一台真实 iPhone，Mac 充当整条传输层。这次看另一边：不靠电脑当宿主，agent 本体就装在你的 Android 手机里。项目是 omnimind-ai/OmniBot，README 里多处自称 OpenOmniBot，仓库名与自述名不一致，这点我们如实写出，不做统一。

它的一句话定位是：直接运行在 Android 设备上的端侧 AI Agent，把聊天、Agent 工具、本地工作区与系统级集成整合进一个应用。但对技术选型的人来说，真正需要先看清的不是能力清单，而是它的许可条款。所以我们先把账算清楚，再谈它能干什么。

一、仓库实核：2,007 星，且当天仍在提交

下面全部数据来自 GitHub API，快照时间为 2026-09-23。星标、fork、issue 数每天都在变，请只当作当日截面，不要当成长期结论：

仓库 topics 覆盖 agent、ai、alpine、android、automation、codex、gui、linux、on-device、skills，这串标签基本就是它的能力地图。

几点提醒。第一，主语言写 Dart，是 Flutter UI 层占大头的结果，它其实是 Android 原生 Kotlin 加 Flutter 的混合栈，另有 React 加 TypeScript 的 WebUI，只看语言条会误判。第二，创建于 2026-03-18、最近 push 就在快照当天，说明这是一条活跃主线，不是挂机仓库。第三，2,007 星属于「有一定关注度」，本站不做排名式表述，也不建议把星标当质量证明。

二、它到底是什么：端侧 Agent，不是又一个聊天框

OmniBot 的自我定义是「端侧 AI Agent」，关键在端侧两字。它和云端 SaaS 型 agent 的根本区别是：推理之外的执行环也发生在手机上。它有自己的工作区、终端与文件读写权限，而不是只把指令转发到某个服务器。

技术栈是 Flutter 加 Android 原生 Kotlin 的混合，WebUI 走 React 加 TypeScript、由 Vite 构建后打进 APK。README 划了与普通 AI Chat 的界线：它关注的不是一轮问答，而是从理解到决策到执行再到反馈的完整闭环。多数手机端 AI 应用只做到「理解」，最多加一个「决策」，把执行交给用户自己点按钮；OmniBot 声称要把执行和反馈也包进来。这也决定了它必然是一个重权限应用，点击、读屏、控制系统能力都要靠无障碍与系统级权限，这是路线本身的代价，第七节展开。

一句话概括：它不是消费级应用，不是云端 SaaS，也不是 iOS 方案（那是兄弟项目 ViaVera 的领域），它就是一个把执行能力装进 Android 手机的本地 agent 运行时。

三、核心能力拆解：四个方向

README 把能力分成四组。

第一组，工具生态扩展。 包含 Skills、Alpine 环境、浏览器、MCP、安卓系统级工具。信息量最大的是 Alpine 环境：不是模拟出来的终端界面，而是在手机上真实跑起一套 Alpine Linux。加上 Skills 与 MCP 两条扩展通道，意味着工具箱可以被外部持续注入，而不是出厂写死的若干个函数。

第二组，系统级能力。 支持定时任务、闹钟提醒、日历的创建查询修改、音频播放控制。README 特意说明分工：定时任务用于执行 subagent 流程，闹钟仅用于提醒。你可以把一个完整任务交给 subagent，它会像完整 agent 那样执行。

第三组，记忆系统。 支持短期与长期记忆嵌入。短期记忆负责会话上下文，长期记忆通过 embedding 落到本地，这也是它要把数据留在本机的技术前提。

第四组，生产力工具。 支持读写文件、浏览工作区、调用浏览器、调用终端。这给的不是「手机 App 的能力」，而是接近一台迷你工作站：有文件系统、有工作目录、有浏览器、有 shell。

四、三个技术看点

看点一：端侧一体，手机不需要电脑当宿主。 这是它与多数手机自动化方案最大的分野。很多方案的实质是「电脑跑 agent，手机当被操控的外设」，phone-harness 就是典型。OmniBot 反过来：应用直接跑在手机上，Agent 编排、系统能力、MCP、前台服务都在本机完成。好处很直接，不依赖同一局域网、不依赖电脑开机；坏处也直接，手机的性能、电量与后台存活策略会成为执行链路的瓶颈。

看点二：Alpine 加终端加 ReTerminal，让手机具备真正的命令行工作区。 README 的架构目录里有一项 ReTerminal/core/，标注为内嵌终端体验相关模块，并在致谢里列出了上游项目 RohitKushvaha01/ReTerminal。这件事的意义不在于「手机上能敲命令」的猎奇感，而在于它把 agent 的工作面和人类的工作面统一了：agent 在同一个文件系统里读写文件、跑脚本、装工具，你随时可以打开终端看它到底做了什么。可审计性，是本地 agent 相比云端 agent 最实的一块优势。

看点三：Remote Codex bridge，把电脑上的 Codex 接到手机端。 这是 README 里最有意思的设计，也最容易被误读。流程是：在一台已安装并登录 Codex CLI 的电脑上启动 bridge：

npx @thuocean/codex-bridge

终端交互里选择监听的局域网地址与 token 模式，然后在应用的 Codex 设置里扫码连接。它并不需要在手机上重跑一套 Codex，而是把电脑已经具备的 Codex 执行能力桥接到手机这个前端上。

安全含义必须说清楚：这个 bridge 走的是局域网，靠 token 模式做认证。它适合「自己的电脑加自己的手机在同一可信网络下」，而不是把它暴露到公网。README 也提示电脑与设备应处于同一个可信局域网。把这类 bridge 对外映射，等于把一台电脑的代码执行能力挂到别人能碰到的地址上，不值得。

五、上手路线：从设置页到装技能

跑起来的路径很短：

1. 从左侧栏打开设置页，先配 AI 能力与 AI 提供商，再配场景模型。
2. Memory embedding 必须使用嵌入模型，没有替代方案；其余场景建议优先用多模态或视觉模型。
3. Alpine 环境通常启动时自动初始化，也可在设置里自行管理，不需要手工装 Linux。
4. Skills：把 skills 仓库链接直接发给助手（README 里叫「小万」）让它帮忙安装，官方推荐 https://github.com/OpenMinis/MinisSkills，装完可在技能仓库里逐项开关。

另外两点值得记：应用内有本地服务，在「设置 > 本地服务」里启用后可拿到地址与 Token，默认端口 8899（以应用实际显示为准），WebUI 本地开发靠 VITE_WEBCHAT_PROXY_TARGET 指到设备的局域网地址；架构目录划分见下：

OpenOmniBot/
├── app/                        # Android 主宿主：入口、Agent 编排、系统能力、MCP、前台服务
├── ui/                         # Flutter Android UI：聊天、设置、任务和记忆
├── webchat/                    # React + TypeScript WebUI，Vite 构建后打包进 APK
├── baselib/                    # 基础核心库：数据库、存储、网络、模型配置、权限
├── assists/                    # 公共任务生命周期与聊天/模型协调
├── uikit/                      # 原生浮层 UI：悬浮球、覆盖层面板、半屏界面
└── ReTerminal/core/            # 内嵌终端体验相关模块

想自己改代码的话，开发环境要求是 Flutter SDK 3.47.2+、JDK 17+、Node.js 20.19+ 或 22.12+、pnpm 10.28.0（最后两项是给 WebUI 用的）。构建安装的主命令是：

./gradlew :app:installDevelopStandardDebug -Ptarget=lib/main_standard.dart

版本门槛不低：Flutter 3.47 与 JDK 17 的组合意味着要先把本地工具链对齐，否则第一步 flutter pub get 就可能卡住。它按工程项目的标准在做，而不是按「下载一个 APK 就能玩」的标准。

六、许可证红线：AGPL v3 只覆盖非商业，商用必须先签约

OmniBot 不是那种「随便用」的开源项目。

仓库根目录的 LICENSE 原文（592 字符）开门见山写的是：本项目采用**用户分段双重许可（Segmented Dual Licensing）**模式。它的结构是这样的：

开源侧是 GNU AGPL v3，但只在特定条件下免费。 条件是：使用场景为非商业用途；或者用于个人、教育、研究目的，且禁止用于任何组织。注意这个组合逻辑，它不是宽松写法，而是明确把组织排除在免费范围之外。并且即便落在 AGPL v3 的适用范围内，你仍需承担 AGPL 的开源义务，例如按协议公开源代码。

商业侧是 Commercial License，必须事先签署。 触发条件有两个，满足任一即需要：一是用于商业用途（任何直接或间接产生商业利益的服务或产品）；二是你希望避免 AGPL v3 的源代码开源义务。也就是说，一家公司哪怕只是内部用、不想把自己的修改开源出去，同样需要商业许可。申请入口是 https://omnimind.com.cn。此外，维护者明确保留更新许可政策的权利，更新会通过代码仓库或官网等官方渠道通知。

把它做成一张判断表更清楚：

由此有三个结论必须说白，这也是本篇最容易被二手转述搞错的地方：

第一，不能把它简写成「AGPL 开源软件」就完事。 它的 AGPL 是有前置条件的，条件之外的部分由商业许可接管，两者并存而不是二选一。

第二，不能说它「免费可商用」。 商用需要事先签署商业许可，这是许可原文的直接要求，不是解读。

第三，组织即便做研究也不在免费范围内。 原文写的是「或者用于个人/教育/研究目的，禁止用于任何组织」，这一句把组织整体排除掉了。

最后补一条容易坑到自动化合规检查的细节：GitHub API 返回的 license 字段是 NOASSERTION，不可信，识别器没能把这套分段双重许可归到标准 SPDX 标识上。任何基于 API 字段做许可筛查的工具在这类项目上都会失灵。本节结论全部来自 LICENSE 原文逐条阅读，请以仓库原文为准。

七、本站判断：手机从客户端变成执行宿主

把前面几节合起来看，OmniBot 真正的产品主张可以概括成一句话：它把「手机」从一个客户端变成一个执行宿主。

这句话的价值在于数据与执行都留在本机。文件、工作区、记忆嵌入、终端操作全发生在同一台设备上，不需要为了用上 agent 而把数据递给云端服务。这是端侧路线唯一真正不可替代的理由。

代价同样明确，有两条：

第一条是权限高度集中。读写文件、调用终端、控制日历与音频、操作界面，都要求很高的系统权限，包括无障碍与系统级能力。这是路线的固有属性，换成任何端侧方案都一样。要评估的是：你愿意把权限交给一个应用，并保持对它的行为有基本了解吗？不确定就先在备用机上跑。

第二条是**「手机上跑 agent」的稳定性还没有大规模验证**。Android 的后台存活策略、各家厂商的电量管理、前台服务的实际待遇，都会影响长任务能否跑完。2,007 星和 27 个 open issues 只说明它是活跃项目，不说明它已在各种机型上被充分验证。适合先作观察对象与副机实验，不要立刻放进生产链路。

与站内旧文的分工必须讲明： 本站 2026-08-22 的 phone-harness 拆解 讲的是 iPhone 经 Mac 上的 harness 被 AI 操控，宿主是电脑；本篇的 OmniBot 是 Android 端侧原生 agent，宿主就是手机本身。平台不同、架构不同、许可模式更是完全不同，两篇不重复，建议对照阅读：

如果你更关心这类能力在同类产品里处于什么位置，可以对照本站的 手机 AI Agent 五方横评；如果关心近期上游模型与平台侧的动向，阿里 Qwen Intelligence 发布热点 提供了另一条线；想自己动手把一台 Android 变成 agent 宿主，可以直接照 手机装 Agent 上手 SOP 走一遍。

一句话收尾：OmniBot 证明的是「手机可以当 agent 的宿主」，而不是「手机 agent 已经成熟到可以随便用」。前者是能力判断，后者是工程判断，中间还隔着一整套你自己的验收。

常见问题

Q1：OmniBot 是免费开源的吗？可以直接商用吗？ A1：它是用户分段双重许可，不是单一开源许可。免费范围仅限非商业用途，或个人、教育、研究目的，且明确禁止用于任何组织。商用、或想避免 AGPL v3 的开源义务，都必须事先签署商业许可（入口 omnimind.com.cn）。「免费开源、可商用」的说法是错的。

Q2：GitHub 页面上的 license 标注可信吗？ A2：不可信。GitHub API 的 license 字段是 NOASSERTION，因为这套分段双重许可不在它的标准标识库里。合规筛查必须以仓库根目录 LICENSE 原文（592 字符）为准。

Q3：它和 phone-harness 是同一类东西吗？会不会重复？ A3：不是。phone-harness 是 iPhone 经 Mac 上的 harness 被操控，电脑是宿主；OmniBot 是 Android 端侧原生 agent，应用直接跑在手机上。平台、架构、许可模式（MIT 对分段双重许可）都不同。

Q4：手机算力够吗？为什么还要 Remote Codex bridge？ A4：两者是补充关系。端侧跑的是 Agent 编排、工作区、终端与系统能力；Codex bridge 则是把电脑上已装好并登录的 Codex CLI 执行能力，通过局域网加 token 模式桥接到手机端扫码使用。它依赖同一可信局域网，不要对外暴露。

Q5：想本地跑起来，最容易卡在哪一步？ A5：两处。一是模型配置，Memory embedding 必须用嵌入模型，其余场景建议多模态或视觉模型；二是开发环境，Flutter SDK 需 3.47.2 以上、JDK 17 以上，WebUI 另需 Node 20.19+ 或 22.12+ 与 pnpm 10.28.0，版本对不上会在依赖安装阶段报错。

参考来源

• GitHub 仓库 omnimind-ai/OmniBot：README（中英文两版）与根目录 LICENSE 原文（592 字符）
• 仓库实核数据取自 GitHub API，快照日期 2026-09-23：2,007 星 / 144 fork / 主语言 Dart / 创建 2026-03-18 / 最近 push 2026-09-23 / 27 open issues
• 许可证结论以 LICENSE 原文为准，未采用 GitHub API 的 NOASSERTION 标注
• 关联阅读：本站 phone-harness 拆解、手机 AI Agent 五方横评、手机装 Agent 上手 SOP、阿里 Qwen Intelligence 发布热点

本文基于 README 与 LICENSE 原文梳理（截至 2026-09-23），星标等数字为当日 API 快照，每天都在变动，请以官方仓库为准。