从 3 个月迭代到完整开源:Open Minis 的进化之路

2026 年 7 月,Open Minis 创始人 Ethan Wang 在 X 上宣布完整开源 iOS 和 Android 代码。这条推文迅速引爆开发者社区——"possibly the best Agent app on your phone",经过 3-4 个月的密集迭代,这款应用已服务数万用户的日常工作流。

截至 2026 年 8 月,Open Minis 在 GitHub 上已收获 3,900+ Star,457 Fork,成为手机端 AI Agent 领域最受关注的开源项目。MacStories 的 Federico Viticci 评价其为"the most impressive indie app I've seen in a while",知乎评测称其"在很大程度上实现甚至局部超越了 Apple Intelligence"。

Open Minis 不是又一个 ChatGPT 套壳应用。它的核心差异化在于:给 AI 模型一台真正的计算机——一个运行在手机上的完整 Linux 环境,加上浏览器自动化、设备深度集成和可扩展的技能系统。

为什么端侧 AI Agent 是下一个战场

云端 Agent 的天花板

当前主流的 AI Agent 框架——无论是 DeerFlow、CrewAI 还是 AutoGen——都运行在云端服务器上。这种架构有几个根本性限制:

  1. 隐私边界:用户的健康数据、日历、通讯录、照片必须上传到云端才能被 Agent 处理
  2. 延迟问题:每次交互都需要网络往返,无法做到即时响应
  3. 离线不可用:飞机上、地铁里、信号差的区域,Agent 完全瘫痪
  4. 成本线性增长:每个用户的每次调用都消耗云端算力,规模越大成本越高

端侧 Agent 的结构性优势

Open Minis 代表的端侧 AI 架构解决了上述所有问题:

维度 云端 Agent Open Minis(端侧)
数据隐私 数据离开设备 全部本地处理
延迟 100-500ms 网络往返 <10ms 本地调用
离线能力 完全不可用 核心功能可用
设备集成 需额外 API 对接 原生深度集成
成本模型 按 token 线性增长 一次性开发,边际成本趋零
系统权限 受限于 API 范围 完整设备能力

这不是说云端 Agent 没有价值——复杂的推理任务、大规模数据处理仍然需要云端算力。但对于日常个人助理场景,端侧 Agent 在隐私、延迟和用户体验上有结构性优势。

核心架构解析:iOS 与 Android 双端实现

整体架构

Open Minis 的代码库结构清晰:

src/ios/          iOS 应用(Swift / SwiftUI)+ Share Extension + Widget + File Provider
src/android/      Android 应用(Kotlin / Compose)+ JNI 原生代码
src/shared/       双平台共享资源
deps/             原生依赖构建脚本和供应商源码
docs/specs/       架构与接口规范
scripts/          根文件系统准备和开发者工具

项目采用 GPLv3 许可证,因为链接了 GPLv3 的 iSH(iOS)和 GPLv2 的 PRoot(Android)。

核心创新:设备内 Linux 沙箱

Open Minis 最核心的技术突破是在手机内运行一个完整的 Linux 环境。这不是简单的终端模拟器,而是一个功能完整的沙箱操作系统。

iOS 端:基于 iSH 项目的 ARM64 fork。iSH 实现了 Linux 用户态模拟,在 iOS 上运行 Alpine Linux。Agent 可以安装软件包、运行脚本、操作真实文件。

Android 端:基于 PRoot 的用户空间 chroot。PRoot 无需 root 权限即可创建隔离的 Linux 环境,同样运行 Alpine Linux。

构建过程相当复杂——首次构建需要 30-60 分钟,因为所有原生依赖都从源码编译:

# iOS 构建顺序很重要:FFmpeg 链接 LAME
./deps/build_lame.sh          # LAME 3.100 静态库
./deps/build_ffmpeg.sh        # FFmpeg 6.1.2 framework bundles
./deps/build_ish.sh           # iSH 内核库
./deps/prepare_alpine_rootfs.sh   # Alpine aarch64 minirootfs

# Android 需要 NDK r28+
./deps/build_proot.sh && ./scripts/prepare_android_sandbox.sh

技能系统(Skills)

Open Minis 的技能系统是其可扩展性的核心。一个 Skill 是一个包含 SKILL.md 文件的文件夹——包含指令、可选脚本、参考资料和资产。

关键设计决策:Open Minis 不要求专门为它编写技能。为 Claude Code、Codex、OpenClaw 或 Hermes Agent 构建的技能通常可以直接在 Minis 中运行。针对 Minis 工具适配的技能运行得更好——因为它们可以直接访问 Linux shell、设备集成和原生卸载。

# 示例 SKILL.md 结构
---
name: health-analyzer
description: 分析健康数据并生成报告
triggers: [健康, 运动, 睡眠]
---

## 指令
当用户询问健康数据时:
1. 通过 HealthKit/Google Fit API 获取数据
2. 在 Linux 沙箱中运行分析脚本
3. 生成 Markdown 格式报告

## 脚本
- scripts/analyze.py: 数据分析主脚本
- scripts/export_health.sh: 数据导出工具

技能仓库 OpenMinis/MinisSkills 已收录 TTS、搜索、媒体下载、健康分析、云 API 等多种技能。

设备集成层

Open Minis 将设备能力暴露为 Agent 可调用的工具:

集成项 iOS 实现 Android 实现
健康数据 HealthKit Google Fit / Health Connect
日历 EventKit Android Calendar Provider
提醒事项 Reminders AlarmManager
通讯录 Contacts framework ContactsContract
智能家居 HomeKit 待实现
蓝牙 CoreBluetooth BluetoothAdapter
剪贴板 UIPasteboard ClipboardManager
快捷指令 Shortcuts app 待实现

这种深度集成意味着 Agent 不只是聊天——它可以真正操作用户的设备。拍照识别食物并记录营养数据、从 Telegram 群提取任务并写入提醒事项、将网页内容整理到日历事件。

原生卸载(Native Offloads)

重计算或平台特定的工作被卸载到原生代码,而不是在沙箱内执行。这包括:

  • 媒体处理:FFmpeg 和 LAME 编译为原生 framework,MP3 编码、视频转码直接在原生层完成
  • 分词:cppjieba 中文分词库编译为原生库
  • 数学渲染:KaTeX 原生渲染
  • 语音识别:RealTimeCutVADLibrary 实现实时语音活动检测

这种混合架构让 Open Minis 在保持沙箱安全性的同时,不牺牲性能关键路径的效率。

端侧 AI 的技术挑战与解决方案

挑战 1:模型推理的算力限制

手机端无法运行 70B 参数的大模型。Open Minis 的解决方案是 Bring Your Own Model(BYOM)

  • 支持 Claude、GPT、Gemini 等主流提供商
  • 用户自带 API Key 或账号登录
  • 推理在云端完成,但数据通过设备本地处理

这不是纯粹的"on-device inference",而是"on-device orchestration"——Agent 的编排逻辑在本地,推理可以借用云端算力。这种务实的架构平衡了能力和可行性。

挑战 2:内存与存储管理

Linux 沙箱需要额外的内存和存储空间。Open Minis 的策略:

  • Alpine Linux minirootfs:最小化根文件系统,只包含必要工具
  • 按需安装:Agent 可以在沙箱内 apk add 安装所需软件包
  • 工作空间隔离:不同任务使用独立的工作空间,通过 minis://workspace/ 寻址

挑战 3:电池与热管理

持续的 Agent 活动会消耗电池并产生热量。Open Minis 通过以下方式缓解:

  • 原生卸载:重计算走原生代码,比沙箱内执行更高效
  • 后台限制:iOS 和 Android 的系统限制自然防止过度后台活动
  • 用户控制:用户可以设置 Agent 的活动权限和触发条件

挑战 4:安全沙箱逃逸

在设备上运行完整 Linux 环境带来安全风险。Open Minis 的多层防御:

  • 用户态模拟:iSH 和 PRoot 都不需要内核权限,无法直接访问硬件
  • 文件系统隔离:沙箱的文件系统与主系统隔离
  • 网络权限控制:Agent 的网络访问受应用权限约束
  • 开源审计:完整代码开源,安全社区可以审查

与云端 Agent 的对比

特性 DeerFlow CrewAI Open Minis
运行环境 云端服务器 云端服务器 手机设备
编程语言 Python Python Swift/Kotlin
多 Agent 协作 ✅ 支持 ✅ 核心特性 ❌ 单 Agent
设备集成 ❌ 无 ❌ 无 ✅ 深度集成
离线能力 ❌ 不可用 ❌ 不可用 ✅ 核心功能可用
隐私保护 ❌ 数据上云 ❌ 数据上云 ✅ 本地处理
复杂推理 ✅ 强 ✅ 强 ⚠️ 依赖外部模型
部署复杂度 中等 中等 高(需编译原生依赖)

Open Minis 不是要取代云端 Agent 框架,而是在个人助理场景下提供更优解。对于需要多 Agent 协作、大规模数据处理的场景,DeerFlow 或 CrewAI 仍是更好的选择。

开源代码结构深度分析

iOS 端架构

src/ios/
├── Minis.xcodeproj/          # Xcode 项目配置
├── Minis/                    # 主应用
│   ├── App/                  # 应用入口和生命周期
│   ├── Views/                # SwiftUI 视图
│   ├── Models/               # 数据模型
│   ├── Services/             # 业务逻辑服务
│   ├── Agent/                # Agent 核心逻辑
│   │   ├── Runtime/          # 运行时环境
│   │   ├── Tools/            # 工具定义
│   │   └── Skills/           # 技能加载器
│   └── Integrations/         # 设备集成
│       ├── HealthKit/
│       ├── Calendar/
│       └── Shortcuts/
├── MinisShare/               # Share Extension
├── AgentWidgetExtension/     # Widget
└── MinisFileProvider/        # File Provider

iOS 端使用 Swift 6.0 和 SwiftUI,目标版本 iOS 26.2。项目包含多个 target:主应用、Share Extension(用于接收其他应用的分享)、Widget 和 File Provider。

Android 端架构

src/android/
├── app/                      # 主应用模块
│   ├── src/main/
│   │   ├── java/             # Kotlin 代码
│   │   │   └── app/openminis/
│   │   │       ├── ui/       # Compose UI
│   │   │       ├── agent/    # Agent 核心
│   │   │       ├── sandbox/  # PRoot 沙箱管理
│   │   │       └── tools/    # 工具和设备集成
│   │   └── jni/              # JNI 原生代码
│   └── build.gradle.kts
└── buildSrc/                 # 构建配置

Android 端使用 Kotlin 和 Jetpack Compose,JDK 17。JNI 层处理 PRoot 沙箱的原生交互。

跨平台共享

src/shared/ 包含双平台共享的资源,但核心逻辑是各平台独立实现的。这种"共享资源、独立逻辑"的策略比跨平台框架(如 React Native 或 Flutter)更适合需要深度系统集成的应用。

开发者如何基于 Open Minis 构建自己的手机 Agent

快速开始

# 克隆仓库(包含子模块)
git clone --recurse-submodules https://github.com/OpenMinis/OpenMinis.git
cd OpenMinis

# iOS 构建
./deps/build_lame.sh && ./deps/build_ffmpeg.sh
./deps/build_ish.sh && ./deps/prepare_alpine_rootfs.sh
open src/ios/Minis.xcodeproj

# Android 构建
./deps/build_proot.sh && ./scripts/prepare_android_sandbox.sh
cd src/android && ./gradlew :app:assembleDebug

自定义技能开发

  1. 创建技能文件夹,包含 SKILL.md
  2. 定义触发条件和指令
  3. 可选添加脚本和参考资料
  4. 提交到 MinisSkills 仓库

构建设置

首次构建前需要复制配置模板:

cp src/ios/Configs/ProviderCustomization.xcconfig.example \
   src/ios/Configs/ProviderCustomization.xcconfig

cp src/android/app/provider-customization.properties.example \
   src/android/app/provider-customization.properties

留空即可编译运行——API Key 方式的登录不需要任何自定义配置。

实际使用场景和用户体验

根据社区反馈和官方文档,Open Minis 的高频使用场景:

营养追踪:拍照识别食物,估算卡路里和宏量营养素,自动写入 Apple Health。

晨间简报:Shortcuts 触发 Minis 获取 X 时间线,生成摘要,合成语音,作为闹钟播放。

任务提取:从 Telegram 群拉取消息,提取 bug 和行动项,去重后写入 Apple Reminders。

笔记管理:挂载 Obsidian vault,研究、清理并写回 Markdown 笔记。

日历事件:通过 iOS Share Sheet 分享任何内容到 Minis,自动创建包含时间和地点的日历事件。

用户评价普遍积极——"这可能是近几年用过的最好的 app,每天都会用它来探索新的可能","很棒的产品!体验丝滑!"。

局限性和未来方向

当前局限

  1. 不支持 PR:仓库是私有开发树的镜像,不接受 Pull Request,只能通过 Issue 反馈
  2. 首次构建复杂:30-60 分钟的编译时间,多个原生依赖需要按顺序构建
  3. 非纯端侧推理:仍依赖云端模型 API,不是真正的 on-device inference
  4. 平台差异:部分功能(如 HomeKit、快捷指令)仅 iOS 支持,Android 端功能较少
  5. GPLv3 许可证:对商业使用有限制

未来方向

  • 更多原生卸载:将更多重计算迁移到原生代码
  • Android 功能补齐:HomeKit 对应物、快捷指令替代方案
  • 技能生态扩展:更多社区贡献的技能
  • 多 Agent 协作:可能引入类似 DeerFlow 的多 Agent 架构
  • 端侧小模型支持:集成 Phi-3、Gemma 等小型本地模型

总结评价

Open Minis 代表了手机端 AI Agent 的成熟架构。它不是简单的模型包装器,而是一个完整的端侧计算平台——给 AI 一台真正的计算机,让它能操作文件系统、浏览网页、集成设备能力。

优势: - 真正的端侧 Agent,隐私和延迟优势明显 - 深度设备集成,超越聊天机器人的范畴 - 可扩展的技能系统,兼容现有 Agent 生态 - 完整开源,社区可审计和贡献

不足: - 构建复杂度高,新手门槛较陡 - 仍依赖云端模型,不是纯端侧推理 - 不接受 PR 的开源模式有些非常规

适合谁: - 重视隐私的个人 AI 助理用户 - 想深度定制手机 Agent 的开发者 - 对端侧 AI 架构感兴趣的研究者

Open Minis 证明了一件事:在 AI 时代,技术设计和代码不再是产品优势所在。最好的 Agent 来自于与用户的紧密反馈循环——他们的期望和报告才是收敛于产品的力量。 这也是为什么团队选择完整开源——让社区共同塑造产品的未来。


参考链接: - GitHub 仓库:https://github.com/OpenMinis/OpenMinis - 官方网站:https://openminis.app - 技能仓库:https://github.com/OpenMinis/MinisSkills - AwesomeMinis:https://github.com/OpenMinis/AwesomeMinis