Muse 的浙大版开源版来了，兄弟们。它就是 nanoMuse，一个让手机和电脑一起替你做事的项目。
你可以在手机上给在线的电脑交代任务，让电脑执行，再把结果和需要你批准的操作送回手机。手机端的后台执行则受系统限制，后面会具体说。
Muse 是 Meta 在 9 月发布的，走的就是个人智能体的路线。
按照 Meta 的说法，每位用户都有一台专属的云端虚拟机，Muse 在里面打开浏览器、填写表单、处理任务，也能记住用户的偏好。发邮件、购物等敏感操作，需要用户授权。
你也可以给 Muse 一个长期目标，让它拆出计划，持续推进，等有结果或需要确认时再通知你。
不过，工作放在云端，和工作发生在自己的手机、电脑上，是两种选择。文件在本地电脑里，操作要在手机 App 中完成时，智能体还得够得着这些设备。
nanoMuse 把手机端、桌面端和连接它们的中继放进了同一个开源项目。 手机上的 Agent 可以把任务交给电脑，电脑需要审批时，再把卡片送回手机。模型也能换成自己选择的服务商。
项目论文的三位作者来自浙江大学，仓库的动态里也注明了这一点。
nanoMuse 的实现也简单提一下，Android 应用基于 OpenMinis，桌面端运行在 DeepSeek Harness 之上。
这里的 nano，指的是个人可以安装、部署的整套系统，并不意味着它附带了一个能在手机上离线运行的大模型。
手机上交代一句，电脑接着做
nanoMuse 的多设备文档里，有一条很适合程序员理解的任务：在手机上让电脑编译项目，再把日志返回来。
假设电脑在设备列表里叫 Mac，可以在手机聊天框里输入这样的任务：
@Mac 编译一下项目，把日志发我
这是按官方语法写的示例，Mac 要换成设备列表里的实际名称。两台设备需要登录同一个中继上的账号，目标电脑也要保持在线，并具备项目所需的构建环境。
任务先从手机送到中继，再交给 Mac 上的 nanoMuse 执行。电脑端会为这次委托建立自己的会话，工具执行情况和最后的文字结果回到发起任务的手机。需要批准某个操作时，手机上能看到审批卡片，电脑端也会展示；用户还可以中途停止任务。
手机负责发起和跟进，编译仍然发生在那台有代码、有环境的电脑上。对需要临时查看执行结果的人来说，这比在手机上重新准备开发环境更有用。
平时的聊天也能在设备之间同步。登录后，对话同步默认开启，当前默认只同步主对话，旁聊需要另外打开同步开关；文件和图片不会随着聊天记录一起上传，另一台设备看到的是附件名称和大小。专门委托给另一台设备的任务会话，则保留在执行设备上。
需要跨设备处理文件时，还要通过对应的文件传输工具完成，不能只依赖聊天同步。
没有 API 的 App，才轮到它操作屏幕
编译项目可以调用 shell，读写文件也有现成工具。但一些任务只能在 App 里完成：按钮在屏幕上，服务没有开放给个人 Agent 的接口。
nanoMuse 为这类任务提供了 Hands，界面里叫“手”。开启相关权限后，Agent 可以查看截图，点击、输入、滑动，再看操作后的屏幕，继续下一步。Android 端操作手机 App，桌面端操作电脑窗口；iOS 端没有操作其他 App 屏幕的能力。
它会优先寻找 Skill、CLI 或 MCP 工具，再尝试网页和浏览器，最后才操作设备屏幕。每一次看图、判断、点击都要花时间，也会消耗模型调用，能用现成工具完成的动作没有必要绕到屏幕上。
这也影响模型怎么选。聊天模型和屏幕操作模型可以分别配置，后者必须能理解图片。填入一个能聊天的 API Key，并不代表屏幕操作、图片生成和视频生成就全部可用了，各项能力要看客户端和模型服务商的支持情况。
Agent 能碰文件、能点击按钮之后，审批就成了日常操作的一部分。下面是仓库提供的删除审批示例：卡片列出准备执行的命令，用户可以拒绝，也可以选择允许一次、在本次对话中允许，或记住对特定目录的授权。
这些授权可以在权限设置里撤销。密码、验证码等输入则交给用户接管。付款类操作有更严格的授权规则；文档也提供了针对特定 App 或站点、经设备解锁确认后记住授权的机制，所以不能把它理解成每次付款都必然重新弹窗。
具体 App 能否顺利操作，还要在自己的设备上验证，官方的界面示例无法说明任务成功率。
任务做完以后，还可以按时再检查
一次编译有明确的终点，跟踪一个目标却需要隔一段时间回来看看。
下面这张对话截图里，用户让 nanoMuse 帮忙规划一周，它开始查看当前目标、提醒事项、触发器和近期记忆。截图时任务仍在处理中，尚未返回完整计划。
nanoMuse 把 Goals 和 Routines 放在了同一个页面里。目标记录进展，例程负责按时间执行任务。官方截图里，上半部分是定期检查的目标，下半部分是每天运行的例程，可以看到检查间隔、下一次执行时间和开关。图中的车票与进度属于项目示例，并非本文实测结果。
它还有一个 Feed 页面，会根据记忆、日记和目标生成每日动态。用户可以查看、编辑用于描述 Agent 和记忆的 Markdown 文件，修正它对自己的理解，不必只靠一轮轮对话反复纠正。
但手机系统会影响后台执行。iPhone 在 App 打开时处理到期任务，进入后台后申请系统调度，只有 iOS 允许时才运行，也会通过本地通知提醒用户打开 App。需要长期、准点执行的任务，我会优先考虑放到持续在线的电脑或自托管运行时上。
免费额度能起步，数据流向要看配置
初次体验不一定要先买服务器。官方提供了浏览器演示，运行在模拟手机里；想操作自己的设备，则需要安装相应客户端。
截至发稿，发布页已经提供 1.0.1。Android 安装包要求 Android 8.0 及以上、arm64；桌面端支持 macOS 12 及以上、Windows 10 及以上和 Linux x64。iPhone、iPad 通过 TestFlight 提供测试版，实际可安装的构建受审核进度影响。macOS 安装包尚未公证，Windows 安装包尚未签名，初次安装会遇到系统提示。
用邮箱或中国大陆手机号登录，可以获得社区中继提供的模型额度，费用由开发者承担。具体额度以 App 显示为准，用完后可以配置自己的 API Key，模型调用费用按所选服务商计算。只想在单台设备上使用，也可以不登录，直接配置自己的 Key；账号主要用于社区模型、对话同步和设备互联。
本地运行 Agent，仍然可能向外发送数据。按照项目的隐私说明，消息、附带图片和工具结果会发送给配置的模型服务商；登录后，对话同步默认开启，主对话文字还会存到中继，供其他设备读取；可以在数据控制设置里关闭。
还有一个值得在登录后查看的开关：帮助改进 nanoMuse 的 AI 模型。官方说明，社区中继从 0.9 起创建的新账号默认开启这项设置，会保留部分聊天文本和工具调用信息，用于训练社区模型。它与对话同步是两个独立设置，可以关闭，也可以删除此前留存的数据，关闭不影响免费额度。
需要自己掌握账号和同步服务时，可以按自托管文档部署中继。中继负责登录、设备互联和对话同步；配置上游 Key 后，也能提供 OpenAI 兼容的模型接口，将设备的请求转发给模型服务商。运行 Agent 的设备和执行模型推理的服务仍是另外的部分，中继部署在自己家里，也不代表推理就在本地完成。
如果直接在 App 里配置自己的 Key，模型请求会从设备直达服务商，不经过中继的模型接口。不过，登录后的对话同步是另一条数据路径，仍需单独查看同步开关。
对 nanoMuse，我更想先验证的是跨设备委托这条链路。准备一个测试项目，从手机发起一次编译，看看电脑能否执行、审批能否返回、失败日志能否在手机上读到。这条链路跑顺之后，再逐步接入自己的日常任务。
项目地址： github.com/nano-muse/n… 。
⭐️推荐阅读：
- 后端开发学习 + 面试指南：覆盖 Java、计算机基础、数据库、框架、系统设计等后端开发核心知识与面试内容。
- AI 应用开发学习 + 面试指南：覆盖 LLM、RAG、Agent、MCP、Prompt、评测、系统设计等 AI 应用开发知识与面试内容。
- AI 编程实战指南：覆盖 Claude Code、Cursor、Codex、Trae 等工具的使用技巧与面试内容。
