nanoMuse：开源个人助理论文解读

Brian Roemmele @BrianRoemmele原推发布于 2026.10.07

在 X 上打开原推

New paper: nanoMuse: An Open-Source Personal Agent for Every Device You Own The authors argue that a personal agent is a class of software rather than a model, and that no open counterpart had been published before this report. Meta announced Muse on 8 September 2026. In that announcement the company described an agent that performs tasks on a person’s behalf, runs on a dedicated secure virtual machine with its own browser, learns from conversation, and was beginning a United States rollout on iOS, Android, and http://muse.ai, with support for AI glasses listed as forthcoming. Liu, Liu, and Zhang reconstruct Muse from Meta’s public record, from shipped clients, and from a copy of a production prompt. Each statement in their account is marked by its source. They define a personal agent as a program that acts for one person on that person’s accounts, devices, and files, that continues to work for weeks, including while the person is away, and that can afterwards answer for what it did by means of a log, a ledger, and a list of the permissions it holds. In their framing, assistants of 2011 answered a query and then waited, and agents of 2023 completed a task and then stopped. Muse is the closed instance of an agent that persists. nanoMuse is offered as the open instance, intended to run on each device a person owns. The interface to applications that lack an API is the screen. The Android application is a 38 MB arm64 download that includes a sandboxed Alpine Linux environment, a shell, a browser, MCP servers, skills, and scheduled tasks. The desktop application is an Electron shell around a DeepSeek harness with a nanoMuse plugin and a Python runtime. The download is 256 MB on Linux and 498 MB on macOS, and idle memory use is reported at about 0.5 GB. An iOS build is distributed through TestFlight, and a web application is served from the person’s computer. Screenshots and available APIs are used first, and login steps remain with the person. Devices share one conversation through a relay that anyone can run. That relay, called nanoMuse Cloud in the report, is an optional Python process backed by SQLite. It stores a hashed account identifier, keys, device mappings, a ledger of model calls that records model name, token counts, and cost but not content, and synced conversation text. It does not store files or tool outputs. The authors estimate a self-hosted relay at ¥30 to ¥60 per month in mainland China, or 4 to 6 US dollars per month outside China, for the smallest server tier, exclusive of model charges. A catalogue of eighteen providers is included, and a local model server on the person’s own machine is supported. The choice of model is left to the person. Every tool call passes through a component the authors call the Sentinel. The decision order is fixed. Denied tools are rejected first. The person’s own rules are applied next, followed by always-allow and always-ask lists. A taint rule converts any call that would send private data outside an allow-list into a request for approval once private data has been read. The tool’s risk is then compared with a mode set by the person, and destructive actions, including shell commands, piped downloads, and commitments expressed in labels, raise a warning. Approvals are scoped grants: once, for the current conversation, or always for a specified target. Decisions are logged for later review. Memory is stored as plain files that the person can read, edit, and export. On the phone these files include SOUL.md for the agent’s identity, USER.md for the person, GLOBAL.md for persistent data, a dated diary, and HEARTBEAT.md for routines.