從 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——都執行在雲端伺服器上。這種架構有幾個根本性限制：
- 隱私邊界：使用者的健康資料、行事曆、通訊錄、相片必須上傳到雲端才能被 Agent 處理
- 延遲問題：每次互動都需要網路往返，無法做到即時回應
- 離線不可用：飛機上、捷運裡、訊號差的區域，Agent 完全癱瘓
- 成本線性增長：每個使用者的每次呼叫都消耗雲端算力，規模越大成本越高
端側 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
自訂技能開發
- 建立技能資料夾，包含
SKILL.md - 定義觸發條件和指令
- 可選添加腳本和參考資料
- 提交到 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，每天都會用它來探索新的可能」，「很棒的產品！體驗絲滑！」。
侷限性和未來方向
當前侷限
- 不接受 PR：儲存庫是私有開發樹的鏡像，不接受 Pull Request，只能透過 Issue 回饋
- 首次建構複雜：30-60 分鐘的編譯時間，多個原生依賴需要按順序建構
- 非純端側推理：仍依賴雲端模型 API，不是真正的 on-device inference
- 平台差異：部分功能（如 HomeKit、捷徑）僅 iOS 支援，Android 端功能較少
- 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