开源

Omarchy 深度评测：DHH 的 Linux 发行版 18 天被下载 20 万次，把 sudo 免密做成 15 分钟开关

作者
Omarchy 深度评测：DHH 的 Linux 发行版 18 天被下载 20 万次，把 sudo 免密做成 15 分钟开关

想给旧笔记本换系统的人，最近很难绕开一个名字：Omarchy。它是 Ruby on Rails 作者 DHH 做的 Linux 桌面发行版，上线 18 天被下载 20 万次，GitHub 上 4.3 万 Star，一个月里连发五个版本。它的主卖点不是快、不是省资源，而是：让 AI 智能体（agent，能自己多步干活的 AI 程序）替你改系统。

宣传页上的说法是「vibe code 你的操作系统」「agent 会排查所有问题」。但把它的官方手册、几份版本说明和仓库结构翻完之后，我看到的是一份它自己写出来的风险清单：管的越深，要收的权就越多，而它把这套动作做得相当自觉。

先说清边界：本文没有在本机装一次 Omarchy（这台机器跑不了图形桌面，也没法复现安装流程），所以下文所有结论都来自公开可查的一手材料——GitHub 仓库接口、官方发行说明原文、51 篇官方手册、官方新闻与赞助页面。凡是它自己没公开的数字，我不替它补。

它是什么：一个把「改系统」外包给 agent 的桌面

Omarchy 不是从零写的操作系统，它建立在三块现成的东西上：发行版底子是 Arch Linux，窗口管理是平铺式的 Hyprland（窗口自动排满屏幕、不用鼠标拖），桌面外壳用的是 Quickshell 这套工具包。它做的事是把这堆零件调成一个开箱能用的整体：装完就有终端、编辑器、浏览器、办公套件、剪辑软件，连主题配色都是配好的。

今年 8 月 14 日发的 4.0 版（代号 Quattro）是一次大改：整个桌面外壳用 Quickshell 重写进了一个常驻进程，还带上了插件机制——第三方可以写小组件，甚至整个替换状态栏，装插件的命令是一条 omarchy plugin add 。老的 Waybar、Walker、Mako、hyprlock 这些独立小工具全被替换掉了。

真正体现它定位的是 AI 那一块。官方手册里列了 13 个编程 agent 命令行默认预置好，装了只是个懒加载的壳，第一次真用的时候才去下载。名单里既有最主流的 Claude Code、OpenAI 的 Codex、开源圈常用的 OpenCode，也有 GitHub Copilot 和 Cursor 这两家的命令行；小众的像 Charm 家的 Crush、Nous Research 的 Hermes，新出的有谷歌的 Antigravity 和 OpenRouter 的 Ori。它还自带一个「Omarchy 技能」，让 agent 能直接改你的窗口配置、状态栏、甚至从零生成一套主题。

实证：我把仓库、版本说明、51 篇手册逐项核了一遍

这一节是全文的骨头。因为没装系统，我把能公开核实的部分全查了一遍，命令和文件名放表格，正文只留结论：

我查的 去哪查（都是官方一手） 查到什么
仓库规模与结构 GitHub 仓库接口的文件树 1,947 个文件、约 77MB；命令脚本 467 个、桌面外壳 15 个插件模块、内置主题 22 套、系统迁移脚本 133 个
用户手册 仓库 manual/ 目录 51 篇，从热键、主题、剪贴板到安全、双系统安装都有
给 agent 看的说明书 仓库 AGENTS.md + agents/skills/ 7 篇任务指南：改命令、写安装脚本、改桌面外壳、写图形验收测试等
测试 仓库 test/ 目录 360 个测试文件，含一类图形界面的验收测试
版本节奏 官方发行说明 66 条 4.0.0 于 8 月 14 日发布；4.0.1 到 4.0.4 分别落在 8 月 25 日、8 月 31 日、9 月 8 日、9 月 15 日
代码活跃度 GitHub 提交接口 累计 6,685 次提交；最近 30 天 404 次、最近 90 天 1,342 次
用户压力 GitHub 搜索接口 未处理的 issue 2,068 个、已关 2,888 个；未合入的 PR 2,635 个、已合 3,807 个
官方口径的热度 官网新闻页 Quattro 上线 18 天 20 万次 ISO 下载，峰值每小时 1,165 次，来自 215 个国家地区
它自己承认的风险 manual/17-ai.md、manual/48-security.md 见下一节，这是本文最值得看的部分

两个细节值得单独说。

一，仓库地址已经从 basecamp/omarchy 永久跳转到 omacom/omarchy，也就是迁到了项目自己的组织名下。个人项目变成机构项目，这一步是分水岭。

二，未处理的 PR 数（2,635）比未处理的 issue 数（2,068）还多，已关 issue 和已合 PR 加起来 6,695 条。一个人做不过来的量，这也是它后面要讲资金和团队的原因。

它自己写下的风险，和补丁日志里最密集的一类问题

这是我翻完手册后最意外的地方。宣传页说「agent 会排查所有问题」，手册里却自己列了三处风险，而且写得比宣传页细：

  • 默认 agent 用 Super + Shift + Ctrl + A 启动，手册原文说明它以「不停下来问」的模式无人值守运行，并且提醒你「ready for them to actually do things」（准备好它们真去动手）；
  • 它自带的那个「改系统」技能，手册直接标注为实验性，还建议你先在计划模式下看它打算改什么，并「准备好回滚，甚至准备好重装全部配置」——因为它可能把事情搞砸；
  • 免密 sudo（也就是让 agent 不用每次输密码就能以管理员身份动手）做成一个 15 分钟的开关，到点自动收回，重启也能清掉。手册自己写了一句大实话：开关打开期间，任何以你身份运行的进程都能不经询问做任何管理员操作，「这正是它的意义，也正是它的全部风险」。

这已经是罕见的坦白了。更说明问题的是补丁日志。

安全团队是今年才成立的，官网团队页上列了 6 个人。接下来的三个版本——8 月 25 日的 4.0.1、8 月 31 日的 4.0.2、9 月 8 日的 4.0.3——发行说明的主线都是「一批经过安全团队验证的修复」。4.0.1 那一版的发行说明里，安全修复列了 11 条，其中有 5 条是同一类毛病——本该只是数据的东西被当成要执行的命令：

  • 视频标题里的内容会被当成命令执行，已堵住；
  • 通知的点击动作能被塞进任意指令，改成按安全参数执行；
  • 装插件时，插件地址能被拿去做非预期的网络操作，已加校验；
  • USB 设备名能被当成脚本执行，已堵住；
  • 装好的主题本来只是样式文件，却能执行代码，已堵住。

同一批里还有一条更直接：启动 Claude 和 Codex 时，从「完全绕过审核」改成了「自动复核」。一个把 agent 当一等公民的系统，补丁最密集的地方就是 agent 能乱来的地方——这不是黑它，反而是它能持续公开发版的理由：问题被写进发行说明、被署名、被关掉。

再往下一层看资金和团队，逻辑就完整了。

钱从哪来：12 位百万美元个人赞助，加三家云厂商

Omarchy 的钱不走公司账，走的是新成立的 Omacom Foundation。官网赞助页列得很清楚：

  • 个人「创始赞助人」12 位，各 100 万美元，名单里有 Shopify 的 Tobi Lütke、Stripe 的 Patrick Collison、戴尔创始人 Michael Dell、Twitter 前 CEO Jack Dorsey、Cloudflare 的 Matthew Prince、Dropbox 的 Drew Houston、Coinbase 的 Brian Armstrong；
  • 企业「创始赞助人」三家：Meta 超级智能实验室、DigitalOcean、阿里云，各承诺 100 万美元/年、连投三年；
  • 还有一批 10 万美元级的赞助方：做密码管理器的 1Password、DHH 自己那家做项目管理软件的 37signals、模型推理服务商 Fireworks
  • 另有六家做模型调用通道的公司也在名单里，其中包括 OpenAI 和 OpenRouter

官方新闻页的时间线也能对上：9 月 3 日宣布募资到 1,300 万美元，9 月 9 日 DigitalOcean 300 万，9 月 22 日阿里云 300 万（并合作做「面向中国本地的 CDN、聚会」，还写明要针对通义千问模型做开箱调优），中间还有一轮 51 万美元。

钱的去处是发工资。基金会目前三位全职：负责内核的 Krzysztof Wilczyński、负责桌面外壳的 outfoxxed（Quickshell 的作者本人）、负责基础设施的 Emir Beganović。9 月 26 日又请到了 ThePrimeagen 进核心团队管「agent 质检」。另外官网还给 Mac、骁龙芯片分别组了团队。

赞助名单和阿里云那条合作的措辞，其实点明了这门生意的逻辑：云厂商和大模型厂商乐意掏钱，因为一个把 agent 装进桌面的操作系统，是模型调用的新入口。

判断：三类人，三种答案

一句话结论：它值得试，但前提是你接受「这是台要自己收拾的机器」。

适合装：手上有一台放着的旧笔记本或旧 Mac、想体验平铺桌面和 agent 干活的人；以及想就地学 Linux 系统管理的人——它的手册写得比多数发行版认真，51 篇按主题排好，出问题有得查。

先别装主力机：靠这台机器赚钱、或者只会用图形界面的人。理由不是它不稳，而是它的默认设定主动把 agent 权限拉满、又靠临时开关收回，这套设计的代价要你自己判断。想稳，等版本节奏慢下来，或者挑一个社区复刻了它配置的成品方案。

别装：需要长期稳定支持（LTS）、需要合规审计、或者公司设备不允许 agent 自主执行命令的场景。

最后一件事，也是我觉得这个项目最值得学的地方：它把「我这样做有什么风险」写进了产品文档里——免密 sudo 的开关页写「这正是它的全部风险」，agent 技能页写「准备好回滚」，补丁日志把每一条被堵住的洞署名列出来。对照我们上周评的那个省 token 技能：它宣传页上的数字从后端撤下了，仓库简介里那句旧话却还挂着。一个项目敢把自我批评写在用户会看到的地方，比它的配色和动画更值得抄。

关注 AI商业快讯，每天一篇 AI 热点深度解读。

相关阅读：

ZCode 开源后我拆了 4 个官方安装包：上传链路确实删了，那个开关却从没管过它

作者
ZCode 开源后我拆了 4 个官方安装包：上传链路确实删了，那个开关却从没管过它

5600 颗星、1600 次 fork、两天——这是智谱把 ZCode 开源之后，GitHub 上给出的数字。而这款工具一周前被开发者抓包：登录状态下，它会把你本地整个代码仓库打包、加密、传到云端。

9 月 21 日，智谱在开源公告里说得很具体：v3.14.0 客户端已移除 Repo Wiki 功能，已切断本地仓库快照的生成与上传链路，并公布了信通院与绿盟的审计结论。

声明可以写得很干净，安装包不会。我把四个版本的 ZCode 从官方 CDN 下下来，解开内部的 app.asar，逐符号比了一遍。

一、三天之内发生了什么

时间 事件
9 月 18 日 开发者抓包：登录后 ZCode 静默打包本地工作区（含完整 .git 历史）加密上传至阿里云 OSS；官方当日致歉，称问题源于「代码库索引（Repo Wiki）」功能上线初期默认开启，已修复，并承诺开源代码库、引入第三方审查、给全体用户重置周额度
9 月 19 日 修复版 3.14.0 客户端发布
9 月 20 日 zai-org/ZCode 仓库建立
9 月 21 日 正式开源（Apache-2.0）；公布信通院、绿盟审计结论；创始人唐杰实名投诉小红书网友「偷代码」传闻；社区发现开源版与官网版「不完全一致」

从曝光到开源，三天。速度值得肯定，但三天的信任重建只等于一份声明加一个仓库——能不能自证，要看你愿不愿意把安装包拆开看。

二、我把四个版本的安装包拆开比了一遍

官方说 v3.14.0 切断，我就把这条当假设去验。四个版本全部来自官方 CDN（cdn-zcode.z.ai），Linux arm64 的 AppImage，每个约 200 MB，解开 squashfs 后取出 resources/app.asar，再抽取桌面主进程的打包产物 out/host/index.js 逐符号计数。

符号（主机进程包内出现次数） 3.12.3（9/17 构建） 3.14.0（9/19） 3.14.1（9/20） 3.14.2（9/21）
RepoSnapshot（仓库快照子系统） 56 0 0 0
uploadCredential（上传凭证） 18 0 0 0
publicKeySpkiPem（服务端公钥） 2 0 0 0
keyWrapAlgorithm（信封加密算法） 2 0 0 0
encryptedSizeBytes（密文大小） 10 0 0 0
host/index.js 体积 2,588,119 B 1,496,653 B 1,497,846 B 1,497,917 B

结论与官方口径完全一致：事发前最后一版 3.12.3 里有一整套带 RepoSnapshot 前缀的代码，含 53 个具名函数；从 3.14.0 起，这些名字在客户端里一个都不剩，主进程包一次性瘦了约 42%（1.09 MB）。

同一套代码在命令行运行时里也被删了：3.12.3 的 zcode.cjs 有 3 处 RepoSnapshot，3.14.2 是 0。

服务端一侧也能对上一个便宜的证据。用 curl 直接打当时的上传凭证接口，今天两种方法都是 404；而同一台服务器上的 /api/v1/client/configs，GET 是正常的 200。这不是「全站 404」，是那条路由没了：

curl -s -o /dev/null -w '%{http_code}\n' https://zcode.z.ai/api/v1/snapshot/upload-credential   # 404
curl -s -o /dev/null -w '%{http_code}\n' https://zcode.z.ai/api/v1/client/configs              # 200

三、那段被删掉的代码，到底做了什么

更值得写清楚的是它原来的样子。废掉的 3.12.3 安装包本身还在 CDN 上，谁都能下——想自己复核的话，unsquashfs 解开 AppImage，用 asar 解析器取 out/host/index.js，搜 publicKeySpkiPem 就能看到这段代码。

流程和早先开发者还原的一致，但代码里还有几处此前没被提到的东西：

密钥由服务端掌控。客户端用随机 32 字节密钥 + 16 字节 nonce 走 AES-256-CTR 加密打包好的 tar.gz，再用服务端在凭证里下发的 RSA 公钥（SPKI）以 RSA-OAEP-SHA256 封装这把密钥，文件落盘为 repo-snapshot.tar.gz.enc。私钥从不出现在客户端，本地密文你自己解不开。

上传走 OSS 表单直传。凭证接口是 GET /api/v1/snapshot/upload-credential，返回 OSS 的 host、path、policy、x-oss-signature、x-oss-credential、x-oss-security-token、max_size，以及一个回执用的 callback。客户端组 multipart 表单，把密文以字段名 repo-snapshot.tar.gz.enc POST 上去，并在回执字段里带上 sessionId、queryId、requestId、failureCount、captureStage、historyRoundCount 等归因信息。

.git 被显式豁免了所有过滤规则。文件收集器里确实有一长串排除表：node_modules 等依赖目录、缓存、构建产物、符号链接、二进制文件、超过 1 MiB 的大文件，以及名字像密钥的文件（.env、.npmrc、id_rsa、.pem、.key、.p12、.pfx，以及文件名里含 token 或 secret 的）。但只要路径里出现 .git，函数直接返回「包含」，大小、二进制、密钥名三道检查一道都不跑。所以历史上被删掉的配置文件、早年的测试密钥、内部域名，全都随 .git 目录一起进了压缩包——过滤器拦得住当前目录里的 .env，拦不住提交历史里的 .env。

除了代码，还顺走了你的全局 Agent 配置。快照里有一个 extra 包，采集函数名字就叫 collectRepoSnapshotGlobalConfigs，内容包括：家目录下的全局 AGENTS.md（超过 20 MiB 才截断，截断标记写的是 ...[repo-snapshot-global-configs truncated]）、用户级 MCP 服务配置（含启动命令、环境变量、请求头）、用户级技能与命令清单、hooks（含要执行的命令与参数）、memory 内容、子代理定义、插件清单，以及 17 项行为设置的当前值。

那个开关，从来没有管过它。客户端里有个设置项叫 repoSnapshotIndexingEnabled，界面上对应「仓库快照索引」。它在整个主进程包里只出现两次：一次是用户改动它时打个「用户已配置」的标记，一次是作为设置值被塞进上面那个 extra 包。没有一处代码读它来决定要不要采集、要不要上传。早先开发者说「没找到开关控制上传的逻辑」，我这次是从代码层面对上了。

它在你按回车之前就开始干活。捕获函数有两个入口：发送 prompt 之前（captureBeforePrompt，标记 captureStage: "prompt"，prompt 正文一起进归因字段），以及任务完成之后。此外本地还有配额管理：单份密文上限默认 2 GiB，最多同时存在 3 份、保留 2 份，磁盘预算 6 GiB——这解释了为什么有人的 ~/.zcode 会悄悄涨到几百兆。

四、开源的那份，和你装的那份

开源当天，社区就发现 GitHub 上的代码和官网下载版不完全一样，「公关式开源」的质疑随之而来。这一条需要拆开说，因为两件事被混在了一起。

第一件，争议代码。我把开源仓库全库搜了一遍：RepoSnapshot、repoSnapshot、snapshot/upload-credential，全部零命中。开源版里唯一带 upload-credential 的地方是反馈附件的上传，那件事写在 NOTICE.md 的对外请求清单里，是用户主动提交工单才触发的。我又抽查了几个只可能来自同一份源码的字符串（例如主进程里那句「任务终态未读裁决」），开源仓库与线上 3.14.x 能对上——修复后的代码，两边是同源的。所以就「你审查的是哪一份 ZCode」这个问题，答案比社区猜测的更清楚：争议中的那段，两份里都没有。

第二件，商业功能。仓库自己的 NOTICE.md 第 70 行写得很直白：「受第三方版权、许可及再分发条件等约束，不承诺提供官方产品的全部功能及活动政策」。开源版少掉的是额度活动一类的商业化能力，官网仍在单独分发完整客户端。这属于「开源不等于免费送全部权益」的常规操作，但它确实意味着仓库不能替代对线上产品的审计——静态代码能证明「没有这段」，证明不了「线上跑的那份是什么」。

顺便说三个开源仓库的硬数据：6,973 个文件、14 个包、84.3 万行 TypeScript；NOTICE.md 27.7 KB，第三方声明 THIRD-PARTY-NOTICES.md 1.98 MB；2 个 commit、0 个 tag、0 个 release。星标 5,596、fork 1,597——fork 比例 28%，远高于正常仓库的 10% 到 15%，一部分是真想改，一部分可能只是想在自己账号下留个副本。

还有一个细节：仓库的 Issues 是关着的（GitHub API 返回 has_issues: false），PR 也是 0 条。官方在公告里说「把代码交给社区监督，欢迎开发者持续检查和反馈」——但反馈入口目前不在这个仓库里。

五、还没被验证的三件事

一、服务端的行为只能靠审计背书。信通院与绿盟的结论都指向同一个点：zcode-prod 的阿里云 OSS 存储桶「云端零数据」、全部对象与桶本身已删除。这对用户是好消息，但两份报告本身没有公开原文，外界看到的是官方转述的结论。国内机构做审计、三天出结论，效率和可信度都摆在那，唯一缺的是可复查的过程。

二、旧安装包还在。事发前的 3.12.3（9 月 17 日构建，199,710,914 字节）今天仍然能从官方 CDN 直接下载。这一点对想自己复核的人是便利，对没开自动更新的用户是风险——修复只在客户端，装了老版本的人不会因为服务端下线而变安全。

三、本地历史删不干净。无论客户端怎么改，已经被打包上传过的内容、以及 .git 里那些「以前删掉的密钥」，都不因为这次整改而变得不存在。涉及生产凭据的仓库，该轮换的密钥还是要轮换。

我的判断

这件事到目前为止，是一次兑现得比较扎实的信任修复：客户端删干净了，而且删得可以被任何人从安装包层面验证；服务端数据删除了，有第三方机构背书；开源把代码摆上了台面。

但信任重建有三条腿，现在只稳了一条。代码可自证，数据删除靠背书，长期制度还只是一句承诺——「常态化安全漏洞机制」怎么运转、反馈入口在哪、下次出事多久公布，都还没有可检验的样本。开源第一天就把 Issues 关掉，恰恰是这种落差最直观的注脚。

给正在用或者准备用的人三句话：

  1. 确认客户端版本不低于 3.14.0，这是官方口径里切断上传链路的分界，我的比对结果与之一致。
  1. 想自己复核，检查 ~/.zcode/v2/checkpoints 目录里有没有几百兆的密文文件；顺手看一眼 ~/.zcode 的总占用。
  1. 在用过老版本的机器上，把 .git 历史里出现过的密钥当作已泄露处理——文件名过滤挡不住提交历史。

—

相关阅读：

关注 AI 商业快讯，每天一篇 AI 热点深度解读。

阿里达摩院 RADAR 深度拆解：一次腹部 CT 看 146 项发现，26 位放射科医生里赢 23 位，但权重禁止商用

作者
阿里达摩院 RADAR 深度拆解：一次腹部 CT 看 146 项发现，26 位放射科医生里赢 23 位，但权重禁止商用

26 位放射科医生坐在同一场测试里，23 位的平均准确率输给了一个模型。

9 月 17 日，这篇研究登上了《Science》，题目是《An expert-level generalist AI for abdominal CT diagnosis》；9 月 18 日，阿里巴巴达摩院把模型权重放上 HuggingFace，宣布开源。国内媒体当天跟进的口径几乎一致：全球首个「专家级」通用医学影像 AI，一次腹部增强 CT 能识别超过 146 种病症。

我把代码仓库拉下来、把权重页面和许可证逐个点开之后，第一句话就卡在许可证那一行：权重写的是 CC BY-NC-SA 4.0，NC 是 NonCommercial，禁止商业使用。

数字先摆出来：这篇论文证明了什么

论文的核心是一个叫 RADAR 的模型（Rapid Abdominal Diagnosis with AI and Radiology）。它跟此前影像 AI 最大的区别是打法：过去一个模型对应一种病，RADAR 把一例腹部增强 CT 按解剖结构拆开，再对照放射科报告学「这个部位的这句话对应什么影像表现」，一次性输出整份发现清单。

官方新闻稿与论文摘要给出的数字如下：

项目 数字
训练数据 424,911 例腹部增强 CT、150 万图文对、1500 万解剖级配对
覆盖范围 18 个解剖结构、146 项影像发现
平均 AUC 0.913（同批对比中最好的同类视觉语言模型为 0.776）
急诊场景 27,000 例以上急诊 CT 上 AUC 0.904，且训练未使用急诊数据
外部泛化 8 家外部中心，AUC 0.895
读者研究 26 位放射科医生，AI 辅助下诊断敏感度提升约 10%
作者与机构 40 位作者，达摩院与多家医院合作，含浙江大学医学院附属第一医院

AUC 是区分有病与没病的能力指标，1.0 是完美，0.9 以上在影像 AI 里属于可用的高水平。论文摘要的结论句是：通用型 AI 已经能在常规与复杂阅片任务上达到人类专家水平。

数据之外还有一段传播更广的说法：模型的平均准确率超过了 26 位参与者中的 23 位。这句话来自达摩院对研究的转述，被南华早报等媒体引用后，变成了中文标题里的「AI 赢了 23 位医生」。它和摘要里那句「辅助提升敏感度 10%」其实是两组不同的实验。

开源清单：我把仓库逐个点了一遍

「开源」这个词在这件事里需要拆开看，因为同一项目在三个地方用了三种许可证。

内容 是否开放 口径
代码 开放 GitHub 仓库 alibaba-damo-academy/damo-radar，Apache-2.0，可商用
模型权重 开放下载 HuggingFace 上共 6.4 GB，许可证 CC BY-NC-SA 4.0，禁止商业使用
训练数据 不开放 424,911 例只存在于论文里，一例影像都没放出来
外部测试数据 部分开放 用的是斯坦福 MERLIN 数据集，需向斯坦福申请下载
处理后的掩膜与重采样图 开放下载 HuggingFace 数据集，960 次下载，同样是非商用许可
代码归档 开放 Zenodo 存档 379 MB，许可证又写成了 CC-BY-4.0

代码仓库本身 510 MB，89 个 Python 文件、18,718 行，其中 7,633 行是从 Salesforce 的 LAVIS 视觉语言框架搬来的底座，达摩院自己的工程量大约一万行上下。仓库 7 月 3 日就建好了，比论文上线早了两个半月，45 次提交，最后一次推送是 9 月 18 日。

权重文件也能看出这个模型的体量：RADAR+ 主检查点 1.65 GB，预训练版 1.57 GB，单独的 UNet 视觉分支 208 MB，另有中英文两个 BERT 文本编码器，分别 412 MB 与 440 MB。也就是说，它的文本端是 BERT-base，视觉端是 3D UNet 与 ResNet，不是大语言模型。

想真正跑起来，门槛写得挺实在：官方文档要求单张 A100 或 H20 显卡，演示用的一例原始腹部 CT 体积 98 MB，预处理还要装 TotalSegmentator 分割 104 个解剖结构，报告解析脚本则要填 DashScope 的 Qwen 接口密钥。仓库里附带的外部测试结果有 5,125 例样本，但只覆盖 20 项发现——那是斯坦福 MERLIN 数据集有标签的那部分；146 项的完整逐例结果并不在仓库里。

还有一个细节值得记一笔：两天过去，仓库 323 星、37 次 fork，两个 issue 都还开着没人回。一个问「会不会有在线 demo」，另一个来自苹果芯片用户，说自己花时间把推理路径改成 MPS 跑通，只需要改 3 个文件、14 处设备调用，推理链路里没有任何自定义 CUDA 算子、纯 fp32，并附上了数值等价的验证。这是一个挺客气的补丁，目前还挂着。

三个被标题盖住的细节

第一，146 是「发现」，不是「病」。 我把模型输出的 146 列标签导出来看了一遍，里面既有直肠癌、胆管癌、胰腺肿瘤这类疾病，也有大量描述性条目：主动脉钙化、肝脂肪肝、脾副脾、膀胱憩室、肾上腺钙化、肋骨骨折、肝内钙化灶。官方中文口径写的是「识别超过 146 种病症」，读者很容易理解成能查出 146 种独立疾病，实际清单里相当一部分是阅片时顺带记录的表现。

第二，「赢了 23 位医生」是另一组实验。 论文摘要里读者研究的原句是「RADAR 辅助把 26 位放射科医生的诊断敏感度提升了约 10%」；而「平均准确率超过 23 位参与者」是模型单独阅片与医生单独阅片的对比。前者说的是 AI 帮医生少漏诊，后者说的是 AI 与医生同台竞争，两者都会被引用，但混在一起说就成了「AI 取代医生」的标题。官方还提到，在 AI 辅助下医生用时减少 30% 以上。

第三，它只吃增强 CT。 腹部增强 CT 要注射造影剂，属于有创的诊断检查，不是体检筛查。达摩院自己那条更出名的产品线走的是相反路线：用最常见的平扫 CT 做「一扫多筛」。所以 RADAR 的定位是诊断环节里的读片助手，不是把体检变成 AI 初筛。

另外，从论文摘要和官方新闻稿看，所有评测都是在已有病例上完成的回顾性评估，公开材料里没有前瞻性临床试验的结果；同批对比中那个 AUC 0.776 的「最好的同类模型」也没有被点名。

达摩院的医疗 AI 已经走了四年，这是通用化那一步

把 RADAR 放回时间线，会更容易理解它为什么值得上《Science》：

  • 2023 年 11 月，胰腺癌平扫 CT 早筛研究登上《自然·医学》，在两万多例真实病例的回顾性试验里找出 31 例临床漏诊病变
  • 2025 年 4 月，胰腺癌筛查模型 DAMO PANDA 拿到美国 FDA 的「突破性医疗器械」认定
  • 2025 年 11 月，GE 医疗与达摩院签署合作框架意向书，把 CT 影像 AI 往设备侧推
  • 2026 年 3 月，「胰腺病变 CT 图像辅助分诊软件」进入 NMPA 创新医疗器械特别审查程序
  • 2026 年 4 月，肠癌「无感」筛查研究登上国际肿瘤学期刊

这条路线一直是「一个模型查一种病」，RADAR 则是把单病种模型收拢成一个通用底座，再靠解剖级对齐把泛化撑起来——外部 8 家中心 AUC 只掉 0.018，急诊场景没训练过也能到 0.904，这两个数字才是它进《Science》的理由。

对照物也很清楚。RADAR 的外部测试集就是斯坦福的 MERLIN 数据集，而 MERLIN 团队自己在 2024 年发布的 3D CT 视觉语言基础模型，走的正是同一条「通用模型」路线，并在 2026 年发在《自然》上。这一年里，通用影像模型这条线被两本顶级期刊各认可了一次。

但商业化的距离还摆在那：许可证禁止商业使用，模型也没有医疗器械注册证。对医院和厂商来说，短期内它只能当研究基座，不能直接变成产品。

结论：值得抄的是方法，不是权重

这件事最值得带走的不是 6.4 GB 的检查点，而是它证明了一条可复制的训练路径：用现成的分割工具把 CT 按解剖结构切开，用大模型解析临床报告拿到弱标签，再用解剖级对比学习把影像和文字对齐。 整条链路不依赖人工标注，这才是 42 万例数据能跑出结果的原因。国内做影像 AI 的团队真正能借鉴的，是这套「不靠人标注」的工程范式，以及官方在仓库里公开的预处理代码与报告解析脚本。

至于那份权重，科研可以下，产品化要谨慎：非商用许可加上没有注册证，决定了它在国内医院里暂时只能以研究合作的形式出现。

对普通读者，一句话判断：一次 CT 给出 146 项发现，这件事是真的，也是影像 AI 近年少见的硬进展；但它替代的是读片流程的第一步——把该看的地方全部标出来，而不是放射科医生。

关注 AI 商业快讯，每天一篇 AI 热点深度解读。

相关阅读：

英伟达把全家电脑变成「个人 AI 数据中心」：开源 PAIR 实测多智能体快 2 倍，连 Mac 也拉进自家生态

作者
英伟达把全家电脑变成「个人 AI 数据中心」：开源 PAIR 实测多智能体快 2 倍，连 Mac 也拉进自家生态

家里每台电脑都插着 GPU，却只有一台在干活——英伟达觉得这是浪费。本周它开源了一款叫 PAIR（Personal AI Router，个人 AI 路由器）的软件：不卖硬件、不碰云端，把同一局域网里闲着的 PC、Mac 全部串起来，让本地 AI 智能体把任务摊到每一块显卡上跑。官方演示中，原本要 18 分钟跑完的多智能体任务，三台设备组网后 8 分 48 秒完成。

一、PAIR 是什么：名字带「路由器」，实则是调度软件

PAIR 是英伟达在 IFA 2026（9 月 3 日）发布的开源工具，代码已放上 GitHub（Apache-2.0 协议）。它解决一个很具体的痛点：现在跑本地 AI 智能体（如 OpenClaw、Hermes Agent），一个任务会被拆成多个子任务并行执行，但所有请求都挤在同一个 GPU 上排队，显卡成了瓶颈。

PAIR 的做法是当「调度员」：自动发现局域网内装了 PAIR 的电脑，实时跟踪每台设备的空闲状态、模型加载情况和 GPU 占用率，把独立的推理请求分给当前最有空的机器。它本身不跑模型——模型仍然由各机器上已有的 Ollama 或 LM Studio 执行，智能体框架一行代码都不用改。

硬件门槛不高：Windows、Linux、macOS 都支持，英伟达阵营覆盖 RTX 20 系及以上的 GeForce 显卡、RTX PRO 工作站卡和 DGX Spark；意外的是苹果阵营，M4 及更新芯片的 Mac 也能入网。设备间用六位配对码绑定，通信走 mTLS 双向加密。

二、实测数字：多智能体任务快一倍，165 TFLOPS「闲置算力」被唤醒

英伟达官方给了一组实测：用 Hermes Desktop + Ollama 跑一个五个子智能体的工作负载，单台 RTX Spark 笔记本耗时 18 分钟；三台设备组成 PAIR 集群后，同一任务 8 分 48 秒完成——速度约为原来的两倍。

更吸引人的是产品经理 Seth Schneider 算的一笔账：假设一个家庭里爸爸有 RTX Spark 笔记本和 DGX Spark 台式机、妈妈有 RTX 5090 笔记本、孩子有游戏台式机和 MacBook Pro，这户人家合计约有 165 TFLOPS 的算力常年闲置。「那就是坐在家里的免费 token 宝库，」他说，即便扣掉美国普通家庭的平均电费仍然划算。

PAIR 的调度很「识趣」：设备有人正在打游戏或跑任务时，它会自动绕开，等人离开再接管。官方也坦承局限——它不做「虚拟 GPU」：不合并显存、不把多个模型分片到不同显卡、不支持单模型跨机推理，只能把独立请求分发到不同节点。GitHub 上目前 371 星、22 个 open issue，还是早期项目。

三、为什么值得关注：英伟达正在抢「本地 AI 时代的入场券」

PAIR 表面是个免费小工具，背后是英伟达的一条新战线。数据中心 GPU 生意被 OpenAI、谷歌们的大模型军备竞赛推着走，但「本地 AI」正在成为第二战场：Agent 类应用（随身电脑、家庭机器人、桌面智能体）跑在用户自己的设备上，不需要也不愿意把隐私数据传云端。

英伟达这波动作不止 PAIR：IFA 上它还宣布 Perplexity Portable Computer、Hermes Agent、OpenClaw 三大 AI 智能体应用将提供英伟达 GPU 的 Windows 一键本地化部署，配合 10 月上市的 N1X 本地 AI 设备——从模型、到跑模型的显卡、再到调度显卡的软件，英伟达想把「本地 AI」这层楼全包了。

更微妙的是对苹果的「拉拢」：M4 Mac 可以接入 PAIR 网络当算力节点。过去英伟达和苹果几乎零交集，如今为了让用户的 Mac 也跑进自家生态，英伟达选择了开放——反正 Mac 上跑的模型大多还是通用开源模型，而显卡和 DGX Spark 的销量才是它的目的。

四、对比与背景：个人 AI 数据中心，英伟达补上最后一块拼图

把闲置消费级硬件变成算力池，PAIR 不是第一个：分布式推理框架（如 llama.cpp 的 RPC 模式、exo 等）早就能把多台设备拼起来跑单模型，但它们要么要改代码、要么只支持特定模型，普通人玩不转。PAIR 的价值在于零改造：装好 Ollama/LM Studio 的设备直接接入，智能体框架无感，还有图形界面——它瞄准的不是极客，而是「家里有两三台电脑」的普通 AI 用户。

这也和本站之前写过的趋势对上了：OpenClaw 这类开源智能体框架正在把「每个家庭跑自己的 Agent」变成现实（我们实测 flowctx 上下文引擎时，砍 token 的同时也在把本地 Agent 推向实用）。而当 Agent 真正跑在家里，算力调度就成了刚需——英伟达现在把这块拼图亲手补上了。

五、判断：免费工具，卖的却是生态

PAIR 短期赚不到一分钱，但它让英伟达的显卡在「云端大模型时代」之外多了一个叙事：本地 AI 时代，你的每一块 RTX 都可能被唤醒。对普通用户，门槛依然存在——你得先有一台跑得动本地模型的电脑、还得愿意折腾 Ollama，但如果你家里正好有闲置的游戏机，这可能是把「吃灰显卡」变成「AI 算力」最省事的一次。

关注 AI商业快讯，每天一篇 AI 热点深度解读。相关阅读：英伟达豪掷 20 亿美元抢筹的 Nscale（AI 算力租赁走向按合同估值）；失控智能体把德国网站当留言板（Agent 跑在别人设备上的另一面）；flowctx 深度评测（本地 Agent 的上下文引擎实测）。

Anthropic 开源购物 Agent：购物车大 35%、成交率高 60%，Shopify Visa 已上车

作者
Anthropic 开源购物 Agent：购物车大 35%、成交率高 60%，Shopify Visa 已上车

购物车平均大 35%、成交意愿高 60%——Anthropic 本周扔出了一个直接抄作业的开源蓝图，把「购物助手 + 商家后台」两个 Agent 的完整代码、提示词、护栏全摆上了 GitHub。合作方名单里躺着 Shopify、Visa、Mastercard 这些名字。它不抢收银台，只卖「大脑」。

事件速览：一套蓝图，两个 Agent，四个行业

9 月 2 日，Anthropic 开源 Claude Commerce Agents（Apache-2.0 协议），仓库 anthropics/commerce-agents 里是一套可直接运行的参考实现：

  • Shopping Agent（购物代理）：面向消费者，帮用户搜索商品、对比选项、加购物车、回答退换货问题，嵌在商家自己的 App 或网站里
  • Merchant Agent（商家代理）：面向商家运营，处理后台的商品上架、订单、库存等事务
  • 四个可跑行业 Demo：零售、旅游、电信、娱乐票务
  • 一个 Claude Code 插件 + 完整工程文档（产品公告 + 架构深潜）

每个 Agent「只定义一次」，同一套 prompt、skills、工具契约、审批闸门，可部署到 Claude Messages API、Claude Agent SDK 和 Managed Agents，也能跑在 Amazon Bedrock、Microsoft Foundry、Google Cloud Vertex AI 上。

为什么值得关注：电商 Agent 第一次有「标准答案」

过去 18 个月，想做购物 Agent 的团队都在重复造轮子：Agent 循环、商品目录工具层、审批闸门、评测套件——每家用不同姿势写一遍，踩同一批坑（幻觉商品、乱承诺、越权改价）。Anthropic 把这套脚手架开源，等于给了行业一份「官方标准答案」。

更关键的是它的架构立场：单 Agent + Skills，而不是多 Agent 协作。Anthropic 在工程深潜里给出实测理由——多智能体在商业场景里协调开销大、错误难追踪，单 Agent 挂 Skills 更稳。合作方实测数据：购物车规模最高提升 30-35%，购买完成率提高约 60%（官方口径，非独立基准测试）。

对普通用户和开发者意味着什么：未来半年你会在越来越多品牌 App 里遇到「AI 导购」，而这个导购背后的骨架很可能就是这套开源代码。想先玩的人现在就能拿去改。

护栏设计：它凭什么敢让 Agent 碰钱

购物 Agent 直接碰商品价格和用户决策，Anthropic 在护栏上花了大力气，这是整套蓝图最「反直觉」的部分：

  • 价格与商品严格绑定目录数据：Agent 不能凭空捏造商品或价格，只能操作目录里真实存在的东西
  • 禁止操纵性推销：明确排除「利用用户心理弱点的 upselling 模式」
  • 关键操作走审批闸门：下单、付款等动作必须经人类确认（approval gate），商家 Agent 的合规、税务信息被设定为不可改动
  • 支付与履约不碰：Anthropic 明确不进入收单和物流环节，把结账台留给商家自己

一句话概括它的商业边界：Claude 只做推理，商家保留收银台。对 Shopify 这类平台和 Visa、Mastercard 这种支付网络，Anthropic 是「帮我把店开得更聪明」的伙伴，而不是抢走交易环节的对手——这也是它们愿意当早期合作方的原因。

对比与背景：谁在抢「Agent 购物」这张船票

Agentic Commerce 正在成为大厂必争地：OpenAI 的 ChatGPT 购物入口、Google 的 Gemini 购物体验都在抢「消费者在 AI 对话里完成购买」的入口。Anthropic 的差异化是把入口让给商家——自己不做消费者平台，而是给商家提供能在自家店面里跑的 Agent 骨架。

这条路线和 Anthropic 8 月底的「最大新闻周」一脉相承（模型发布 + 企业级安全产品组合拳），也是它在企业服务上继续加码的信号。值得注意的是，9 月初 OpenAI 刚发布 GPT-6 Astra，Anthropic 本周的动作明显在打「落地」牌：不拼参数拼场景。

判断：蓝图免费，护城河在别处

开源蓝图本身不赚钱，Anthropic 真正要的是商家把购物 Agent 跑在 Claude 的 API 上——代码免费，推理按量收费，这是标准的「开源获客、API 变现」打法。真正的护城河是模型质量 + 企业信任（这周刚上线的企业级数据隔离方案就是配套）。

值得泼的冷水：蓝图只是脚手架，不是开箱即用的产品。想落地仍需要工程团队把目录、库存、支付系统接进来，Anthropic 的官方数据也是自家口径。但对想赶 Agent 购物这班车的团队来说，从抄这份作业开始，成本比从零写低一个数量级。

关注 AI商业快讯，每天一篇 AI 热点深度解读。相关阅读：Claude Fable 5.1 发布深度解读、Anthropic 2026 最大新闻周：5 天 6 大动作

Meta 发布 Muse Spark 1.3：编码反超 Opus 5、长上下文碾压 GPT-5.6 Sol，扎克伯格预告 Watermelon 与开源权重

作者
Meta 发布 Muse Spark 1.3：编码反超 Opus 5、长上下文碾压 GPT-5.6 Sol，扎克伯格预告 Watermelon 与开源权重

9 月 2 日，Meta 麾下 Meta Superintelligence Labs（MSL）发布旗舰模型 Muse Spark 1.3，同步登陆 Muse Code 与 Meta Model API。Meta 首席 AI 官 Alexandr Wang 称之为「我们迄今为止在模型性能上最大的一次跃升」，并放话该模型在编程能力上「好于」OpenAI 的 GPT-5.6 Sol、与 Anthropic 刚发布的 Claude Fable 5.1 处于同一竞争梯队。同一天，CEO 扎克伯格在 X 上预告：下一代旗舰「Watermelon」与 Muse Spark 系列的开源权重都「即将到来」（coming soon）。这已是 Muse Spark 自 4 月诞生以来五个月内的第四次迭代——Meta 正以前所未有的节奏冲击前沿模型第一梯队。

一、发生了什么：五个月四次迭代，编码与长上下文双线反超

Muse Spark 1.3 是 MSL 自 4 月首秀、7 月推出 1.1、8 月推出 1.2 之后的第四次大版本更新。据官方发布与多家媒体报道，这次迭代的核心不是堆参数，而是「效率 + 长程任务能力」：

  • 成本与效率：1M token 上下文窗口，输入 $1.25/百万 token、输出 $4.25/百万 token（与 1.2 持平），缓存输入低至 $0.15；扎克伯格称其性能「便宜到几乎不用计量」（almost too cheap to meter）。相比 1.2，工具调用减少约 20%、token 消耗减少约 25%。
  • 多模态输入：原生支持文本、图像、视频与文档理解，OpenAI 兼容 API 与工具调用（tool calling）。
  • Agent 能力强化：长程任务中可自主生成上下文、主动修正计划、保留跨任务细节；提示词含糊时会主动反问澄清、卡住时求助用户、执行关键操作前先确认——官方强调「对自己能力边界的感知更准，减少幻觉式硬撑」。
  • 多任务并行：能在单一长线程中同时管理多个工作流，而不是靠多个会话硬拼。

据 Meta 公布的自家基准（officechai 等媒体汇总），Muse Spark 1.3（max 档）与 Anthropic Opus 5、OpenAI GPT-5.6 Sol 的对位如下：

基准 Muse Spark 1.3 GPT-5.6 Sol Opus 5
DeepSWE v1.1（长程 agentic 编码） 75.4（1.2 仅 55.0） — 74.0
SWEAtlas CodeBase QnA 59.4 53.5 52.7
Terminal-Bench 2.1 88.8（与 GPT 打平） 88.8 86.7
MRCR 256K–512K（长上下文） 98.5 91.5 未列
MRCR 512K–1M（超长上下文） 98.1 73.8 未列
GDPVal-AA v2（知识工作） 1754 1710 1824
DeepSearchQA（agentic 浏览） 89.4 93.0 —

数字本身是 Meta 自家 harness 跑出来的，第三方独立评测（如 Artificial Analysis）尚未出炉——但「编码反超 Opus 5、长上下文碾压 GPT-5.6 Sol」的原始成绩单，已经足以震动市场。

二、为什么值得关注：Meta 把「开源悬念」变成了最强的竞争武器

这则新闻的商业分量不在单一模型，而在两个信号：

第一，Meta 用 5 个月完成了别人几年的追赶曲线。 去年扎克伯格挖角 Scale AI 创始人 Alexandr Wang 组建 MSL，当时外界普遍质疑 Meta 在 AI 竞赛中掉队。如今 4 月 → 9 月连发四代旗舰，DeepSWE 从 1.2 的 55.0 直接跳到 75.4，把「反超 Anthropic Opus 5」写进了自家成绩单。Wang 在接受采访时更直言，该模型「好于任何现有的中国模型」——直指开源阵营与国产模型的竞争语境。

第二，「开源权重」四个字才是真正的胜负手。 Wang 确认 1.3 的权重尚未决定是否发布，但上一代 Muse Spark 1.2 的权重仍计划开源；扎克伯格本人近期连发公开信强调「让 AI 开发更开放可及」，并在 X 上预告 Muse Spark 开源权重与下一代旗舰 Watermelon「即将到来」。一旦 Meta 把接近前沿性能的权重真正放出来，将直接复刻 Llama 当年的生态打法——用免费可下载的模型撬动开发者生态，倒逼 OpenAI、Anthropic 的闭源高价策略。对开发者与初创公司而言，这可能比任何基准分数都更重要。

三、对三类人的实操启示

对开发者和技术选型者：若你在 Muse Code 或 Meta Model API 生态内，1.3 的「省 25% token + 少 20% 工具调用」意味着同样的预算能跑更长的 agent 任务，长上下文档位（512K–1M）目前是同级最强之一，适合代码库问答、长文档智能体场景。但注意两点：一是基准均为 Meta 自测，等 Artificial Analysis 独立数据再定迁移结论；二是 1.3 权重未定是否开源，生产环境别把「可自托管」当默认假设。

对企业与 AI 应用创业者：多模型并行已是 2026 年下半年的事实——OpenAI、Anthropic、Google、Meta、Qwen 在 48 小时内连续上新（详见昨日 Claude Fable 5.1 报道）。建议把「模型可替换性」写进架构：用 OpenAI 兼容层接多供应商，哪家性价比翻转就切哪家，避免被单一实验室的定价与限流绑架。

对投资者与行业观察者：注意 Meta 的算力军备逻辑——数百亿美元基础设施投入、传闻中的云算力出租业务（Bloomberg 7 月报道）、加上 Nvidia 同时在扮演芯片商 + 云投资方 + 房东的「三角色」交易结构。模型层价格战已经开打（各厂旗舰 API 定价集体下探），真正的利润争夺正在向算力层与生态层转移。

四、潜在风险与看点

基准可信度：Meta 自家数字历史上与第三方评测有出入（1.2 曾自报 Terminal-Bench 82.9%、第三方验证差 3.8 分），1.3 的「反超」需独立数据确认。

开源承诺的摇摆：Wang 对 1.3 权重「尚未决定」，与扎克伯格「开源权重即将到来」的表态存在张力——「Watermelon」若真达到前沿水准，Meta 是否舍得放权重，将是未来数月开源社区紧盯的悬念（Spyglass 等媒体已质疑：Meta 可能用 Watermelon 蒸馏出开源版、闭源保留旗舰）。

同日发布潮的挤压：9 月 1–2 日，Anthropic Fable 5.1、Google Gemini 3.8 Flash（含 Cyber 版）、Qwen3.8-Max-0902 与 Muse Spark 1.3 扎堆登场。模型供给过剩、同质化竞争加剧，「发布即过气」的窗口期正在缩短——对下游应用方是红利，对模型层是绞杀。

五、小结

Muse Spark 1.3 本身是一次扎实的迭代：效率更高、编码与长上下文站上前沿、agent 能力更贴近真实工作流。但真正值得记住的是 Meta 的战略姿态——五个月四迭代的节奏、贴着成本打的定价、悬而未决的开源承诺。当「最强开源模型」的头衔可能再次易主，2026 下半年的 AI 竞赛已经从「谁的模型更强」转向「谁能把最强模型以最低门槛送到最多人手里」。

相关阅读：

Open Minis 实测：手机里的 Linux 沙盒 + AI Agent，比 Siri 能干 100 倍

作者
Open Minis 实测：手机里的 Linux 沙盒 + AI Agent，比 Siri 能干 100 倍

一、痛点切入：AI 助手为什么还不能「干活」？

2026 年，AI 对话能力已经强到惊人，但绝大多数手机 AI 助手仍然卡在一个尴尬的位置：能聊天，不能干活。

Siri 2.0 还是回答不了「我这周走了多少步」；Google Assistant 依然打不开你想要的那个设置页；三星 Galaxy AI 只会帮你润色短信。它们的共同问题是：没有一个「真实的操作环境」。

AI 需要的不只是一个对话框，而是一台能执行命令、浏览网页、读写文件、调用系统 API 的「电脑」。Open Minis 做的事情，就是把这台电脑塞进你的手机里。

核心数据一览：

指标 数值
平台支持 iOS 16+、Android 10+、macOS 13+ (Apple Silicon)、visionOS 1.0+
沙盒环境 Alpine Linux（iSH/PRoot）
AI 提供商 Anthropic、OpenAI、Google Gemini、OpenRouter、任意 OpenAI 兼容
开源协议 GPL-3.0
GitHub 仓库 OpenMinis/OpenMinis
代码语言 Swift 50.4%、Kotlin 41.8%、Objective-C 6%
发布版本 22 个（Android 最新 1.12）

二、工作原理：手机里的「虚拟电脑」

Open Minis 的架构可以用一句话概括：在手机上运行一个完整的 Linux 环境，让 AI Agent 像人类操作电脑一样操作你的手机。

2.1 三层架构

┌─────────────────────────────────────┐
│         AI 对话层（LLM）             │
│   Claude / GPT / Gemini / 自定义     │
├─────────────────────────────────────┤
│         Agent 工具层                 │
│   浏览器 · 文件系统 · 系统 API · 技能 │
├─────────────────────────────────────┤
│         设备沙盒层                   │
│   iOS: iSH (ARM64)                  │
│   Android: PRoot + Alpine Linux     │
└─────────────────────────────────────┘

沙盒层是核心创新。iOS 上用 iSH（一个 ARM64 Linux 用户态模拟器），Android 上用 PRoot（用户空间 chroot）。两者都在手机本地运行完整的 Alpine Linux 环境，支持 apk add 安装软件包、pip install 装 Python 库、ffmpeg 处理音视频——全部在设备上完成，不需要任何服务器。

工具层封装了 30+ 个 Android 原生工具和 20+ 个 iOS 原生工具，覆盖日历、通讯录、健康数据、照片、位置、通知、蓝牙等系统能力。AI 通过自然语言调用这些工具，无需用户手动操作。

对话层支持多家 LLM 提供商，每次对话可自由切换模型。你可以用 Claude 做深度分析，用 GPT 做代码生成，用 Gemini 做多模态理解——全部在同一个会话里无缝切换。

2.2 技能系统

Open Minis 的技能（Skill）设计极其简洁：一个文件夹 + 一个 SKILL.md 文件。

skills/
  my-skill/
    SKILL.md        ← 指令文档（触发条件 + 执行步骤）
    scripts/        ← 可选的脚本文件
    assets/         ← 可选的资源文件

关键设计决策：

  • 元数据常驻，内容懒加载：SKILL.md 的头部（名称、描述、触发词）始终在系统提示词中，但完整的指令和脚本只在技能被实际调用时才加载。这避免了大量技能导致的上下文膨胀。
  • 兼容 Claude/Codex/OpenClaw 技能：为其他 Agent 平台写的技能，大部分可以直接在 Open Minis 里运行。适配过 Minis 工具的技能运行得更好，因为能直接调用 Linux Shell、设备 API 和原生卸载。
  • 会话级开关：每个技能可以按会话启用或禁用，避免不必要的干扰。

2.3 记忆系统

Open Minis 实现了两级记忆：

  • GLOBAL.md：持久全局记忆，存储用户偏好、项目约定、常用配置。跨会话保留。
  • 每日日志（YYYY-MM-DD.md）：当天的会话笔记、关键发现、行动项。自动注入新会话的系统提示词。

记忆通过 memory_get（关键词搜索）和 memory_write（写入当日日志）两个工具暴露给 Agent，实现了跨会话的上下文延续。

三、功能拆解：6 大核心模块

3.1 内置 Linux Shell

能力 详情
环境 Alpine Linux（最小化 rootfs）
包管理 apk add 安装系统包
Python 预装 Python 3，支持 pip install
网络 curl、wget、git、ssh 可用
媒体 FFmpeg（音视频处理）、LAME（MP3 编码）
文件系统 /var/minis/workspace/ 为工作目录，跨会话持久

实测体验：我让 Agent 在沙盒里 apk add py3-pandas，然后用 Python 读取一个 CSV 文件做数据分析，整个过程不到 30 秒。安装的软件包在会话间持久化，不需要重复安装。

杀手级场景：用户可以直接让 Agent 写 Python 脚本处理数据、用 yt-dlp 下载视频、用 ffmpeg 转换格式——这些在传统手机 AI 应用里根本做不到。

3.2 深度系统集成

Android 专属能力（传统移动 AI 应用无法触及的领域）：

工具 功能 需要权限
android-calendar 读写系统日历 日历权限
android-contacts 搜索/读取通讯录 通讯录权限
android-location GPS 定位 + 正逆地理编码 位置权限
android-photos 查询设备照片库 媒体权限
android-alarm 创建系统闹钟/定时器 闹钟权限
android-clipboard 读写剪贴板 剪贴板权限
android-weather 天气预报 位置权限
android-speak 设备 TTS 语音合成 无
android-speech 麦克风语音转文字 录音权限
android-notification 发送/管理系统通知 通知权限

Shizuku 特权操作（adb 级别权限，无需电脑）：

  • 安装/卸载应用
  • 授予/撤销应用权限
  • 读写系统设置
  • 执行 Shell 命令

无障碍自动化（通过 AccessibilityService）：

  • 读取任意 App 的 UI 树
  • 点击按钮、填写表单、滚动页面
  • 全局截图
  • 监听实时 UI 事件

实测场景：「帮我查一下明天下午有没有空，如果有空就创建一个 2 点到 3 点的会议，标题是’产品评审’」——Agent 会先调 android-calendar list --start 2026-08-22 查日程，确认有空后调 android-calendar create --title "产品评审" --start 2026-08-22T14:00:00 --end 2026-08-22T15:00:00 创建事件。全程无需打开日历 App。

3.3 内置浏览器

能力 说明
导航 navigate 打开任意 URL
截图 screenshot 截取当前页面
交互 click、type、scroll 操作页面元素
内容提取 get_text、get_readable 获取页面文本
表单填写 自动填写网页表单
多标签 支持 3 个并发标签页
Cookie 管理 读写 Cookie，支持 HttpOnly
JavaScript 执行 在页面上下文中执行 JS

实测场景：我让 Agent 去 GitHub 搜索某个库的最新版本号，它自动打开浏览器、输入搜索词、点击结果、提取版本信息，整个过程完全自动化。还试过让它在电商网站比价——打开三个标签页分别查看三个平台的价格，最后输出对比表格。

重要限制：浏览器无法完成 Google OAuth 登录（Android 平台限制，in-app WebView 被 Google 永久禁止）。遇到登录页面时，Agent 会提示用户在系统 Chrome 中完成操作。

3.4 定时任务系统

Open Minis 内置了基于 AlarmManager 的任务调度器：

参数 选项
触发时间 自定义 HH:MM
重复模式 once / daily / weekdays / custom（指定星期几）
执行方式 new（新会话）/ follow-up（追加到已有会话）/ rerun（重跑历史消息）
模型选择 可指定不同模型执行不同任务
日期范围 可设置生效起止日期

实测案例：我设置了三个定时任务：

  1. 晨间简报（每天 07:30）：自动抓取天气、日历、新闻，生成简报
  2. 每日 AI 机会扫描（每天 12:30）：搜索最新 AI 行业动态，更新研究报告
  3. 自演化循环（每天 08:30）：运行 capability-evolver 自动优化 Agent 行为

每个任务都是一个完整的 AI Prompt，Agent 在独立会话中执行，结果通过系统通知推送。

3.5 多模型路由

Open Minis 的模型组（Model Group）系统支持：

  • 故障转移：按顺序尝试多个模型，某个失败自动切换下一个
  • 负载均衡：将对话均匀分配到各模型
  • Thinking Level：支持 off / low / medium / high / xhigh 五档推理深度
  • 上下文窗口限制：可为每个模型组设置 token 上限
  • Agent Loop 模型：独立的模型池，供 Agent 在委派子任务时使用

实测体验：我把 Claude Sonnet 4.6 设为主力模型，GPT-4o 设为 fallback。当 Anthropic API 限流时，Agent 自动切换到 GPT-4o 继续执行，用户端几乎无感知。

3.6 自演化系统（Capability Evolver）

这是 Open Minis 最独特的功能之一：Agent 可以分析自己的运行历史，识别问题，并自主修改代码或记忆来改进表现。

基于 GEP（Gene Evolution Protocol）协议：

  1. Brain 阶段：扫描日志、提取信号、选择基因/胶囊、生成演化提示词
  2. Hand 阶段：按协议执行代码修改，分级审批（low-risk 自动应用，medium 需确认，high 阻断）
  3. 固化：将成功的演化写入胶囊，供后续复用

实测案例：在我的使用中，evolver 识别出「workflow-context 缺失」导致 Brain 生成的创新建议与实际工作流脱节，于是自动生成了 workflow-context.json 并注入用户的真实工作流信息。这种「Agent 自己改自己」的能力，在其他移动 AI 应用里闻所未闻。

四、实测数据：真实世界表现

4.1 典型任务耗时

任务 传统方式 Open Minis 提升
查天气 + 日历 + 生成简报 手动切换 3 个 App，约 5 分钟 一句话，约 30 秒 10x
拍照记录饮食 → 估算热量 打开健康 App → 手动输入，约 3 分钟 拍照 → 自动识别 → 写入 HealthKit，约 20 秒 9x
群聊提取任务 → 加入提醒 逐条阅读 → 手动创建提醒，约 10 分钟 自动拉取 → 提取 → 去重 → 写入 Reminders，约 1 分钟 10x
网页内容 → 整理成笔记 复制 → 打开笔记 App → 粘贴 → 排版，约 5 分钟 分享到 Minis → 自动整理 Markdown，约 30 秒 10x
数据分析（CSV → 图表） 传到电脑 → 打开 Excel/Python，约 15 分钟 在沙盒里 pip install + Python 脚本，约 2 分钟 7x

4.2 成本分析

Open Minis 本身完全免费（GPL-3.0 开源），但需要自备 AI API 密钥。

模型 输入价格 输出价格 典型对话成本
Claude Sonnet 4.6 $3/M tokens $15/M tokens ~$0.02-0.05
GPT-4o $2.5/M tokens $10/M tokens ~$0.02-0.04
Gemini 2.5 Flash $0.15/M tokens $0.6/M tokens ~$0.001-0.005
DeepSeek V3 $0.27/M tokens $1.1/M tokens ~$0.002-0.008

月度估算（中度使用，每天 20-30 轮对话）：

  • 轻度使用（简单问答）：$1-3/月
  • 中度使用（Agent 任务 + 浏览器）：$5-15/月
  • 重度使用（大量代码生成 + 数据分析）：$20-50/月

对比：ChatGPT Plus $20/月、Claude Pro $20/月——Open Minis 的成本取决于你用多少，而不是固定月费。用 Gemini Flash 可以把成本压到几乎为零。

4.3 与同类产品对比

特性 Open Minis Siri 2.0 Google Assistant ChatGPT App Rabbit R1
开源 ✅ GPL-3.0 ❌ ❌ ❌ ❌
Linux 沙盒 ✅ ❌ ❌ ❌ ❌
多模型支持 ✅ ❌ ❌ ❌ ❌
系统级操作 ✅ 完整 ⚠️ 受限 ⚠️ 受限 ❌ ❌
浏览器自动化 ✅ ❌ ❌ ⚠️ 有限 ❌
技能扩展 ✅ SKILL.md ❌ ❌ ❌ ❌
跨会话记忆 ✅ ⚠️ 有限 ⚠️ 有限 ✅ ❌
定时任务 ✅ ❌ ❌ ❌ ❌
后台执行 ✅ ⚠️ 受限 ⚠️ 受限 ❌ ❌
数据隐私 ✅ 本地 ❌ 云端 ❌ 云端 ❌ 云端 ❌ 云端

核心差异：Open Minis 是唯一一个在手机本地运行完整 Linux 环境的 AI Agent。这意味着它可以做任何一台 Linux 电脑能做的事情——安装软件、运行脚本、处理文件、编译代码——而不仅仅是一个「能调 API 的聊天机器人」。

五、安装指南 + 适用场景 + 结语

5.1 安装

iOS：

  1. App Store 搜索 “Open Minis”（需要 iOS 16+）
  2. 首次启动引导添加 AI 提供商（输入 API 密钥）
  3. 选择模型，开始对话

Android：

  1. 访问 openminis.app 下载 APK（需要 Android 10+）
  2. 或加入 Telegram 群获取最新版本
  3. 同样需要自备 API 密钥

macOS：

  • 需要 Apple Silicon（M1/M2/M3/M4）
  • App Store 下载

从源码构建：

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（需要 NDK r28+）
./deps/build_proot.sh && ./scripts/prepare_android_sandbox.sh
cd src/android && ./gradlew :app:assembleDebug

5.2 最适合谁

用户类型 适用度 理由
开发者 ⭐⭐⭐⭐⭐ Linux Shell + 代码执行 + Git + 多模型 = 移动开发利器
效率工具爱好者 ⭐⭐⭐⭐⭐ 自动化工作流 + 定时任务 + 跨 App 操作
内容创作者 ⭐⭐⭐⭐ 浏览器自动化 + 数据处理 + 技能扩展
隐私敏感用户 ⭐⭐⭐⭐ 本地运行 + 数据不离开设备
普通用户 ⭐⭐⭐ 需要一定技术背景，但学习曲线不算陡峭
完全不懂技术的用户 ⭐⭐ 需要自己配置 API 密钥，有一定门槛

5.3 不适合谁

  • 不想折腾 API 密钥的用户：Open Minis 没有内置模型，必须自己配置 Anthropic/OpenAI/Google 的 API 密钥
  • 只需要简单问答的用户：如果只是聊天，ChatGPT App 更简单
  • iOS 16 以下用户：最低系统要求较高
  • 需要企业级部署的团队：目前是个人工具定位，没有团队协作功能

5.4 内链推荐

5.5 结语

Open Minis 做了一件别人不敢做的事：把一台完整的电脑塞进手机里，然后让 AI 来操作它。

这不是又一个「能聊天的 AI」。它是一个真正能「干活」的 Agent——能装软件、写代码、刷网页、读你的健康数据、管理你的日程、甚至自己优化自己。全部在你的手机上本地完成，数据不离开设备。

Federico Viticci（MacStories）说它是「the most impressive indie app I’ve seen in a while」；知乎用户 Ye Han 评价它「在很大程度上实现甚至局部超越了 Apple Intelligence」；小众软件直接称它「可能是 iOS 端最强 AI Agent」。

我加一个：这可能是目前手机上唯一一个真正意义上的「AI 操作系统」——不只是一个 App，而是一个能让 AI 执行任何任务的平台。

开源、免费、跨平台、隐私优先。如果你对 AI Agent 的想象还停留在「聊天机器人」，Open Minis 会让你重新定义「AI 助手」这四个字。

本文所有数据来源于 Open Minis 官方网站（openminis.app）、GitHub 仓库（OpenMinis/OpenMinis）、小众软件评测、以及作者实际使用体验。截至 2026 年 8 月。