Shell 早就有，Agent 才是新的：从 iSH 到 Open Minis

打开刚装好的 Open Minis，输入 uname -a，能看到 Linux 和 aarch64；跑的是 Alpine 用户态；执行 apk add python3 就能在用户态用 Python。工具目录里还有日历、健康、蓝牙、NFC 和浏览器等工具，等待模型调用。

Open Minis 在 2026 年春天发布并开源，第一眼看到这个界面，人的注意力会先落在那个画面上：一台未越狱的 iPhone 运行着一个 Linux 命令行环境，还能访问二十多个系统接口。第一反应是：这手机里怎么装个 Linux 虚拟机？苹果审核怎么会通过？继续看它的源码和应用历史，会发现其实我们盯着命令行这个沙箱看走眼了。

它不是虚拟机，Shell 也不是新东西

在 Open Minis 的开源仓库 里，点开底层目录，里面没有任何硬件虚拟化实现，也没有启动一个独立的客户机内核。相反，它拉取了开源项目 iSH 的 ARM64 分支 OpenMinis/ish-arm64，在一个普通的 iOS 应用进程内部跑起了 Alpine Linux 的用户态环境。Linux 里面的二进制程序每次做文件读写、网络请求等系统调用时，宿主应用内部的内核兼容层会半路拦截，实时翻译成 iOS 的原生调用；机器指令则交给一个叫 Asbestos 的线程化代码解释器来解释执行。

iOS版只能解释执行，速度代价躲不开，根源在苹果的平台规则。正如iSH关于JIT和欧盟规则的博客 所记录的，iOS不向普通第三方应用开放即时编译技术JIT，无法动态生成机器码，Linux环境只能退回解释器。再加上苹果App Store审核指南的自包含要求和模拟器例外，共同决定了今天这种解释执行形态，也划定了算力折损边界。

在手机里装命令行和脚本环境，已是十多年的旧闻。从 2015 年 Android 上的 Termux，到 2017 年的 iSH，2020 年 iSH 和 a-Shell mini 上架，一直到 2024 年通过的 UTM SE，以及 2026 年春季开源的 Open Minis，手机里的本地用户态与脚本环境已经演化了十多年。

如果把时间线排开，我们会发现命令行终端、Python 解释器和 Linux 用户态在手机上早就齐备了。让事情起变化的，是坐在那个黑底白字终端前面的角色换了。从 Termux 到 iSH 和 a-Shell，终端默认的服务对象一直都是人，每一条命令都得靠人用拇指在屏幕键盘上逐字敲入，盯着输出再手动敲下一行。Open Minis 则在旧有的 Linux 沙箱地基之上，新加了一层智能体运行时，把命令行环境、内置浏览器与系统级接口统一交给大语言模型，由模型自己决定先跑什么命令、怎么解析返回的数据、遇到报错如何调整参数，以及在哪个节点调起手机原生接口。底下的 shell 已经存在了十多年，上面新接上的这一层，才是接管了控制流的智能体运行时。

二十多个原生工具，真正的意义不在清单里

Open Minis 的 iOS 沙箱架构文档展示了这种原生桥接层如何站在 Linux 命令和 iOS 原生框架之间：智能体在终端使用已注册的命令，桥接层就把它转发到相应的 iOS 原生接口，并把执行结果以结构化形式返回给终端。对大模型而言，在沙箱中运行一段本地脚本和调用一个系统级 API，体验几乎一样。

这些命令里的日历、提醒、定位、天气与 HomeKit，和 iOS 自带的捷径、Siri 很贴近，只是换上了统一的命令行界面与结构化输出。真正超出移动端脚本范畴的，是蓝牙 BLE 扫描与 GATT 特征值读写、NFC 标签与协议交互、带持久化登录态的内置浏览器控制层，以及旁边这个能用 apk 装包、随时跑起 Python 和 Node 的 Linux 环境。

这里已经能看到一个面向人的工具和面向智能体的执行面的关键差异。给人用的终端或浏览器会把窗口顶在前台、让人盯屏幕、动手点按才能一步步走。面向智能体的执行面则不需要把浏览器界面打开摆在台面上；只要应用还在运行，智能体就可以用编程的方式直接驱动内置的 WKWebView。多个标签页可以并行，同一条标签页上的动作会排队，且受配额和全局上限约束。这不等于应用能在后台无限运行，iOS 还是会按系统策略把切出前台的应用挂起。只是在执行任务的过程中，人不必坐在浏览器窗口前亲自操作，智能体可以把本地脚本、网页和原生接口串成一条连续的执行链。

一个想象的使用场景是：我们用手机拍一张活动海报或者纸质账单，智能体调用原生的照片和机器视觉接口来做OCR，拿到混杂着排版换行和识别噪声的原始文本。然后在本地命令行里跑一个Python脚本来提取准确的起止时间、地点或金额，再调用原生的日历或提醒事项接口，把结构化事件写进系统日程表。

如果有一个正在发射数据的蓝牙BLE传感器，我们同样可以想象另一个工作流：智能体先用蓝牙工具扫描并连接设备，读取指定的GATT特征值，拿到一串十六进制字节。然后在同一沙箱中运行本地脚本，根据字节序解包转换成实际物理量，最后通过HealthKit接口写到系统的健康记录或本地CSV里。对网页而言，也可以想象智能体直接控制已登录的内置浏览器翻页提取后台数据，交给本地脚本汇总落盘后弹出系统通知提醒。

如果我们把中间的数据流转摊开，就能看见工具声明和端到端跑通的差距。我在 iPhone 上做了一轮单机观察，发现智能体确实能调用很多常见接口，以及蓝牙 BLE、NFC、机器视觉等工具，但也有一些工具因为服务端签名配置或通知权限没给到位而失败，还有一些工具还没做端到端实测。同样地，一个蓝牙外设能不能连上要看具体的 GATT 服务和系统的连接管理；NFC 能不能读卡看卡片协议、认证加密和权限，不能因为接口存在就默认任意外设或银行卡、交通卡都能直接交互。系统 API 本身不罕见，这里真正新增的变量，是一个由模型在运行时动态决定的、能横跨命令行、内置浏览器与 iOS 原生接口的执行链。

Shortcuts 能手搓 loop，但补不上 runtime

Shortcuts 的用户指南里包含了网络请求、循环、条件判断和各种 App Intents，理论上可以在 iOS 捷径里构建一个调用 LLM 的循环。但从实际体验来看，捷径仍然是一个需要人预先设计的静态流程图，一旦任务复杂化、工具增多、目标网页变化，或者中间某个步骤失败，就需要重新设计流程。Open Minis 是一个在运行中决定下一步的智能体运行时，它会自主选择工具、读取网页，在某一步骤失败时调整策略。

二者的区别首先体现在控制流的归属上。捷径的控制流由设计流程图的人决定，下一步使用什么系统动作则由预先设定的条件分支决定。只有两三种固定动作还能应付，二十多种工具自由组合时，就很难根据实时反馈改变路径。此外，捷径会沿着既定的轨道执行，中途遇到权限未开或调用报错就会停下弹窗；而智能体运行时则会记住之前的上下文和中间状态，将报错信息作为反馈告诉模型，让它在下一次尝试中改变参数重新尝试，或者改用其他工具绕过当前错误。

更明显的区别是能不能随时运行代码并连续操控浏览器。iOS上的捷径没有原生的通用shell、Python或Node环境，遇到需要解包传感器字节流或用脚本清洗文本的任务就会卡住；按照Shortcuts的网页脚本说明，它的网页脚本动作也只能在当前打开的Safari页面上做单次注入。反观Open Minis的浏览器控制实现源码，应用内维护了带持久化数据存储的WKWebView，暴露出导航、截图、点击、输入、滚动与多标签页管理等二十来个动作，智能体可以一边连续操作网页，一边切回本地Linux环境跑Python脚本处理数据。外层循环框谁都能拼，两边的核心差别在循环底下：那整层负责工具调度、状态保持、失败恢复与代码执行的运行时，到底要不要由你自己用积木重写一遍。

手机多出来的是现场，不是算力

把命令行、Python 和智能体都装进手机以后，如果希望它像口袋电脑那样做重度编译或批量计算，真机上很快就会撞墙。解释执行的性能折损加上移动端功耗散热限制，用手机沙箱来拼算力是没有优势的。手机比桌面电脑多出来的是物理现场，是人站在具体的环境里，他的意图刚刚冒出来的那一刻。

人走出书房，手机能接触到桌面电脑够不着的东西：当前地理位置、几米内的蓝牙 BLE 外设、贴一下就能读的 NFC、相机与系统分享、带登录态的内置浏览器，以及锁屏可见的系统通知。整层执行面收在应用沙箱与授权接口里，既不能控制整台手机或操作其他第三方应用的界面，内置浏览器里的点击与填表也是靠脚本派发事件完成的，并不等同于手指在屏幕上的真实物理触摸。

看清楚这个范围以后，可以想象两个在物理场景里的小例子。比如在餐桌上，饭菜刚端上桌，随手拍个照给手机智能体，视觉接口识别食物组成，本地脚本换算营养数据，直接写到健康记录里。要是到晚上回电脑前再补，多半早就忘了细节。再比如站在硬件工作台或者设备现场，手里有个蓝牙传感器外设，不用回屋搬笔记本电脑，直接掏出手机让智能体扫描周围的 BLE 设备，连上指定服务读几组特征值字节，当场跑几行 Python 脚本验证数据格式对不对。

一旦把这些即时的动作拉长成耗时任务或者做成后台常驻，就会碰到 iOS 的系统生命周期与内存管理的矛盾。应用切到后台，系统随时会挂起它，沙箱脚本或者浏览器一旦吃满内存，系统的内存管理机制jetsam就会直接杀掉进程，具体限额动态且未公开。再加上第一次调用接口需要用户亲手确认授权，指望它在后台无限期地盯你也不现实。手机的威力在当下：当意图出现的那一刻它就在那里，能把眼前的画面、身边的外设和你正处的登录态立刻变成行动。

现场 context 与长期 context：组合才是答案

把电脑上的 Markdown 笔记、个人规则和技能文档全部同步到手机里，真在手机上调起日常模块，会发现接不上。健康 skill 背后是桌面的 CLI 和本地数据库，智能家居 skill 指向家庭内网常驻服务，工程项目 skill 离不开那棵带有未提交改动和凭据的源码树；手机拿到了文档，也接不上半截进度。参考 公开版 Context Infrastructure 仓库 的结构就能看清，文件同步不等于 context 可用，context 可用也不等于任务接续。

这个断层之所以存在，是因为个人智能体所依赖的两种不同的上下文。长期 context 包括你是谁、在做哪些项目、做过的决策、人际关系和长期偏好；现场 context 则包括你此时在哪里、面前有什么、周围有哪些蓝牙或 NFC 设备、刚才说了什么话，以及手机上打开的已登录的浏览器会话。Open Minis 擅长的是现场 context，最近火热的常驻型个人智能体和我自己的 context infrastructure 长于长期 context。

例如 Meta 发布的 Muse 在云中运行，有一个独立的浏览器和记忆，即使关闭了手机上的 App 也可以继续工作，可以通过 Muse 应用或 WhatsApp 进行交互。另一个还在私有测试中的产品 Instinct 则在 iMessage 和 WhatsApp 上常驻，可以调用浏览器，并且连接到了 Shopify 的商品目录。它们有长期记忆和云端算力，可以通过应用或用户分享获得手机信息，但手机的原生传感器如相机、蓝牙 BLE、NFC、HealthKit 等并不是它们直接执行的层面，它们调用的也是云端的浏览器而不是手机上已经登录的浏览器会话。从这个角度，我们可以用现场依赖和连续性依赖两个维度来理解二者的区别：

想把右下角这个又现场又连续的象限补起来，可以按响应速度和上下文深度把系统拆成三层。最外面是反射层，用 Siri 和捷径实现零延迟的固定单步指令；中间是身体层，手机运行时用相机、蓝牙、NFC、定位和随身浏览器感知现场并执行本地动作；最里面是记忆与规划层，用 Muse、Instinct 或长期智能体系统来保管跨项目历史和做长链路规划，调度耗时任务。

身体层与记忆层之间通过主动推送和按需拉取两种机制连接。主动推送是手机在少量高信号现场事件中，如拍照、语音、标签扫描、明显位置变化或主动分享，将来源和隐私范围一并发送给长期智能体；按需拉取则由长期智能体在任务中要求手机完成具体观察或动作，比如拍摄设备标签、扫描NFC、读取蓝牙特征值或浏览网页；手机弹出权限确认框后执行并将结果以结构化方式返回。手机在这里是一双按需调用的眼睛和手，而不是一个不断喷涌原始数据的水龙头。

基于这两条通路，可以想象四种把物理现场和长期系统连成闭环的场景。从现场到长期记忆，比如你在路上拍活动海报或书封，手机当场做OCR与字段抽取，把结构化摘要推给长期智能体存档到项目笔记。从长期记忆到现场动作，比如长期智能体根据项目进度与作息记录计算最佳专注时段，然后调用手机设锁屏闹钟、写日历，或在你到家时触发HomeKit切换书房模式。

从现场触发长耗时任务，可以设想你在工作台前用手机读取一串异常的蓝牙传感器字节并拍下接线照片，手机把初步解包结果发往云端或桌面端的常驻智能体，由后者调起完整代码库与历史日志做深度排查。等到长任务跑出修复方案，收尾一步又回到现场验证：常驻智能体生成新的校验脚本，反向请求手机再次连接蓝牙外设读取特征值，或用随身登录态打开内部网页确认状态，在现场完成闭环验证。

把这四种闭环放到真实设备上看，把几份 Markdown 文件拷进手机只是表层小事；真正的棘手工程在跨端任务交接、每次现场调用的权限边界，以及如何维护一个唯一长期记忆源，不让手机和云端分化出冲突状态。这种组合的目标从来不在把手机做成缩小版电脑，它真正要解决的是让现场发生的一次具体动作能顺畅接回长期运行的系统。接下来手机端会暴露更多工具，但工具数量早已不是瓶颈；能跨越设备与执行面、把现场瞬间和长期脉络接在一起的连续性，才是真正稀缺的东西。