速评：nanoMuse 从第一次发布到挂上 arXiv，中间隔了 12 天。
这个速度，眼熟。
9 月 25 日首次发布，10 月 7 日 arXiv 冒出一份编号 2610.08699 的技术报告，作者三个人。同一时间，仓库停在 0.1.41，867 次 commit，217 个 star，26 个 fork，1 个 watcher。
先看最后一组数。867 次 commit 摊进十二天，一天七十多次——这不是一个刚起步、还在搭架子的仓库该有的节奏，这是一台全速运转的机器。而 217 个 star、1 个 watcher 说明外面几乎没人在看。做得比被看见快得多。这反差算好算坏，两说：可能是闷头干活，也可能是自己给自己赶工期，外人现在分不出来。
然后是"论文"这两个字。
我不打算把它当罪名。开源项目往 arXiv 上挂技术报告这两年早就常规化了，功能也很清楚——给自己那张对比表找一个可引用的出处。这一手不寒碜，反倒说明作者懂规矩。真正值得说的是顺序：产品线还停在 0.1.x，对比表先成型了。对比表上摆的是 Meta 的 Muse，和 OpenMinis。一个刚满十二天的项目，对标物直接点到大厂门口。
这里得插一句。仓库里有一份声明，写的是跟 Meta 没有任何隶属或背书关系，还专门点出 Muse 是 Meta 的商标。名字里带 Muse、默认形象一条小龙、对比表正对着 Meta Muse 排——然后郑重其事把这个关系撇干净。这是老手的动作，不是新手的动作。一个 0.1 版本的项目，最早写好的文件里躺着一份合规声明，这种优先级排序说明作者对自己会被怎么误读心里有数。
说回来，那张对比表里确实有一行不是话术。
Meta 那边智能体跑在每用户一台云虚拟机上；OpenMinis 跑在装了它的那台手机上；nanoMuse 的说法是，智能体跑在你自己的手机、你自己的电脑、或者你自建的服务器上，三端共用一个账号，登录后的设备之间靠 relay 互相发起请求。关键在后半句：走 relay 的只有会话文本，文件和截图不离开产生它们的那台设备。
这条是实的。云 VM 那条路，你的屏幕、你的文件、你的操作轨迹全在别人的机器上；改成每台设备各跑一份，relay 只当信使，这是个不一样的架构取舍，代价和收益都摆在明面上——代价是手机端得在 APK 里塞一整套运行时，靠 proot 拉了个 Alpine 在跑 shell、浏览器和 MCP；收益是数据的边界画在设备上，不画在公司的机房里。
这才是我觉得它值得多看一眼的地方。不是它铺了六个平台——铺平台堆人力就有，没什么智商含量。
说到六个平台，得拆一下。首页那六格是平等排列的：Android、iOS/iPadOS、Windows、macOS、Linux、浏览器。但能力不平等的部分写在文档里。Hands 那套屏幕操作，在 Android 和桌面上能用，iOS 上因为系统限制直接做不了。手机端最重要的一项能力，在苹果那边是缺的。再加上 iOS 走 TestFlight、macOS 未公证要右键打开、Windows 安装还得点"仍要运行"——六格并排的界面，实际交付状态是一地鸡毛。这不丢人，早期项目都这样。丢人的是把六格摆得跟六格都完工了一样。
还有一层我想说，但说不太准。这项目骨架是从好几样现成东西上攒起来的：手机应用建在 OpenMinis 上，桌面端套着 DeepSeek Harness 当插件跑，Hands 的操作器从字节的 UI-TARS-desktop 移植，连界面标记都沿用人家那套方案名，致谢名单还有一长串。这行业里功能互相抄接近常态，该讨论的从来不是抄没抄，是抄完有没有增量。这里的增量我认为在上面那条架构取舍上，不在"支持六个平台"这种数字上——数字能凑，架构取舍凑不出来。
这里立个 flag。
我猜它接下来一个月的动作是这样：先靠 arXiv 编号和那张对比表把技术正当性占住，然后重心回到补平台短板，尤其 iOS 那条腿。要是一个月后 star 数还挂在三位数，就说明"论文先行"这套打法在开源社区不转化——文档写得再齐、路线图再全，也换不来第二个 watcher。到那时候我回来收这个 flag。
至于现在，那 217 个 star 里有一个是我。