Muse 解读：Meta 的个人 AI 智能体、其安全虚拟机，以及无人拥有的邀请码

如果你搜索过 Muse 智能体，你很可能有两个问题。第一个是你能否进入：Meta 的 Muse 在 Meta 自己的所有文档中都没有邀请码、没有等候名单，也没有访问码，而本页会告诉你这个答案从何而来，而不是要求你凭信心接受。第二个是 Muse 究竟是什么，因为这个名字会与 Meta 推出的许多东西联系在一起。Muse Spark 是底层的模型；Muse 是它所驱动的产品。Muse 是 Meta 在一台为此专门打造的计算机上运行的个人 AI 智能体，而真正值得理解的工程之处，不在于它能做什么，而在于 Meta 已决定绝不允许它触及什么。

这里有两个日期很重要，但两者都不是撰写本页的理由。Meta 于 2026 年 9 月 8 日推出 Muse，并于当天在美国将其启用；在 2026 年 9 月 23 日的 Connect 大会上，Meta 表示正将 Muse 引入其 AI 眼镜。第二个日期是过去七天内唯一的 Muse 事件，此处用它来确定产品的时间，而非作为撰写文章的依据。这是该名称的参考页——是搜索“muse agent”的读者会到达的页面，而他们只找到了我们对发布的报道；那是唯一值得拥有的链接，没有什么值得转述的。以下所有内容均来源于 Meta 自己的公告和 Meta 自己的安全报告，这两者均于 2026 年 9 月 29 日重新审阅，且其中每个数字都来自 Meta，除非本页另有说明。

Muse 是什么，以及它不是什么

Meta 自己给出的总结尽可能直白地指出了这一区别：“Muse 是一款个人 AI 智能体。它不只是回答问题，而是会真正去做事。”在实践中，这意味着 Meta 描述 Muse 会处理诸如发送电子邮件或预订旅行之类的具体任务，也会承担开放式目标——把说出的抱负转化为个性化计划，然后自行推进。对于耗时超过一次会话的工作，Meta 表示，Muse 会在应用关闭后继续运行，并在有变化或需要审批时回来。交互模式是发消息，而不是聊天窗口：你可以在 Muse 应用中或直接在 WhatsApp 里与它交谈，它“由 Muse Spark 驱动，这是 Meta 迄今为止能力最强的模型，专为这类现实世界的智能体工作而打造。”

对于通过搜索来到这里的人来说，Muse 不是什么，同样重要。它不是你能从 API 调用的模型，也不是披着个性的聊天界面。它是 Meta 代表你运营的消费级产品，运行在 Meta 掌控的基础设施之上，而且它不是你能安装的东西。Meta 并未发布针对 Muse 本身的任何基准测试——没有分数，没有排名，没有正面对比——而这一缺失是关于文档本身的事实，而不是本页可以用某个替代指标填补的空白。评估 Muse 的诚实方式是阅读其架构与可用性，本页其余部分正着眼于此。

为什么智能体需要一台属于自己的计算机

起点是 Meta 的那句话：“Muse 运行在 Muse Secure VM 上，这是一台自带浏览器的专用安全计算机。”同一篇帖子在别处把它描述为“一台专用虚拟机（VM），其中同时容纳智能体和个人数据”，并将其隔离起来，使其他任何人的智能体都无法触及。每个人所连接的每项服务的凭据和数据都存放在那里。在阅读时，Meta 对设计目标的表述值得记住：一台机器上两个相互隔离的安全域，而不是一个拥有 root 权限的语言模型。

Meta 的安全文章《我们如何为 Muse 构建安全》比公告具体得多，并且对于任何关于该代理值得多少信任的说法，它都是应当引用的来源。代理执行框架、工作区文件以及 Muse 执行的每一个工具都运行在一个 systemd-nspawn运行时容器内。该隔离单元内的 root 映射到主机上的一个非特权用户，因此隔离单元 root 并非主机 root。该隔离单元拥有自己的根文件系统，与存放更敏感数据的主机文件系统分离，同时还拥有虚拟网络接口、经过过滤的系统调用——没有 io_uring，举例来说——以及受限的能力集：没有 CAP_SYS_PTRACE，也没有 CAP_NET_ADMIN。在隔离单元之外，单独的 systemd 单元运行着那些不能从隔离单元内部切换的保护措施，包括一层独立的模型和分类器，用于检查推理请求和响应，以发现提示注入和前沿风险。Meta 将这些保护放在外面的理由是，运行时隔离单元预计会处理不受信任的数据。

把这些选择放在一起读，就能回答读者真正关心的问题：Muse 能触达什么？它能访问网络，但只能通过另一个系统控制的路径。它能驱动浏览器，但不能触及浏览器的内部。它能持有凭据，却无法看到它们。

Sentinel 决定；Muse 只提议

Meta 的公告用一句话介绍了这一组件：“独立的 Sentinel 代理运行在同一台机器上，在系统层面与 Muse 相互隔离。”安全文稿中明确规定了权限归属，而且毫不含糊——“Sentinel 是连接器操作和网络出站的唯一权限方”——授权顺序也同样明确：Muse 提出操作，但只有 Sentinel 能授予执行这些操作的权限。对于任何提议的操作，Sentinel 都会根据用户设置的连接器策略，返回三种答复之一：允许、拒绝或询问。除非 Sentinel 批准，否则 Muse 的任何操作都无法访问互联网；而 Sentinel 会在需要时询问用户。

其背后的机制异常具体。对于网络出口，Sentinel 会在第 4 层和第 7 层进行检查——主机名、解析后的 IP 与最终 IP、端口、协议、方法、路径，以及解码后的请求本身——并施加 SSRF 限制，使公网主机名无法解析到私有基础设施。凭据会在网络边界处即时注入，仅在使用的瞬间将代理令牌替换为真实凭据，这也是 Meta 称通过提示注入诱使智能体交出真实密钥的尝试徒劳无功的原因。污点传播由 eBPF cgroup 程序和 LSM 钩子实现，它决定一项操作何时失去其自动允许状态。这是 Meta 产品内部的 Meta 架构：它不是我们的功能，我们也不对外暴露或转售其中的任何部分。

审批、凭证和浏览器

对于任何要决定让智能体做多少事的人来说，另外三项设计选择起着决定性的作用。

批准是能力，而不是对话。Meta 的表述非常精确：“通过人类在环系统授予的批准是严格的能力，而不是对话式建议。”每项授权都绑定到特定的连接器或目标以及特定用例，系统支持一次性、会话范围、任务范围、限时或永久权限。Sentinel 选择提供哪些授权类型，并验证后续调用与已授予的范围匹配。请求会发送到 Muse 客户端界面，而不是通过对话传递，回答会直接路由回 Sentinel。购买每次都需要人工批准。只读、先前已允许或可证明低风险的操作会跳过中断，这是 Meta 明确说明而非隐藏的权衡。

凭据存放在虚拟机内。hatch-authd是在运行时单元之外运行的安全敏感服务之一，负责凭据存储和凭据代理，因此主智能体永远不会看到敏感凭据。已连接服务的 OAuth 令牌存储在用户的虚拟机中，而不是集中式的 Meta 基础设施中。另外，一个名为 privsep 的服务以严格限定的权限执行内置连接器代码，使关联服务的凭据处于智能体无法触及的范围之外。Meta 自己对结果的总结是，Muse 无法看到密码或支付方式，包括用户自己在浏览器中输入的密码。

浏览器是受中介管理的。Meta 将该浏览器描述为由一个独立的中介管理，该中介拥有 Chrome DevTools Protocol 连接，而子代理通过页面的无障碍树快照而非原始 DOM 来驱动它。其后果被明确陈述：无法在页面上下文中运行 JavaScript，没有脚本动词，无法在浏览器进程中执行，并且 DevTools 被禁用。由于无障碍树是输入，子代理无法读取从凭据存储输入的凭据，并且它无法从 DOM 中退出来找到它们。当人接管浏览器时，或者当凭据存储正在填写表单时，代理会被暂停，完全无法行动。

漏洞赏金是应被当作信号来解读的那部分

Meta 表示，它通过内部试用、智能体红队测试和一项私密漏洞赏金计划强化了 Muse，随后将该计划向所有人开放：基于已证实影响的报告，有效者最高可获 30 万美元，其中成功影响单个用户的提示注入尝试最高可获 13 万美元。这些是 Meta 公布的计划最高金额，而非实测结果，Meta 之外的任何人都无法说明这些奖金实际支付的频率。

这份披露之所以有用，在于它的形态。其中被点名的最大单一类别，不是越狱，也不是 Meta 这一端的数据泄露——而是在某个人的会话内，某个网页或某封电子邮件说服智能体去做某件事。这就是 Meta 正在纳入定价的威胁模型，它告诉你在第一天就要小心哪里：在于一个人授予的连接器权限，以及智能体在依据这些权限行事时读取的内容。

可用性，完全按照 Meta 的表述

Meta 的原话，于 2026 年 9 月 29 日重读：“Muse 正在美国登陆 iOS、Android 和 muse.ai，并即将登陆 AI 眼镜。它对人们所需的大部分用途免费，并为想要做更多事情的人提供订阅方案。”这两半都应当按原文来读。这是一次在一个国家、跨三个平台端的滚动推出，AI 眼镜被列为未来的一个平台端。而那句定价表述是关于 Meta 自家消费者产品的陈述——它没有提及任何其他平台的分级，包括我们平台的，本页也不对其加以延伸。

过去七天里唯一一条有明确日期的新闻是眼镜产品线，Meta 在 2026 年 9 月 23 日的 Connect 大会上把它落到了实处：它正将个人 AI 智能体 Muse 引入其 AI 眼镜，主打免手动管理日常生活。该公告没有给出上市日期。值得关注的路线图项目是 Muse 机密虚拟机（Muse Confidential VM），Meta 表示它将在今年晚些时候推出；在其中，整个虚拟机——包括个人数据及其与 Muse 的对话——都用只有用户本人持有的密钥加密，因此连 Meta 也无法访问。

有一件事本页无法核查：Muse 的第一方产品页面位于 ai.meta.com/muse，其标题能够返回，但它的正文在我们 2026 年 9 月 29 日的读取中没有获取到。那是我们无法检查的一个页面，而不是一个澄清了任何问题的页面，因此这里没有任何内容取自它。

邀请码：Meta 未记录任何信息

人们在 Meta Muse 下搜索邀请码、邀请代码和进入途径。诚实的答案是，这些在 Meta 自己的材料中都不存在。9 月 8 日的公告完全没有邀请、推荐、等候名单或访问码相关表述；访问权限仅按地域和平台来描述，限制条件是美国加上 iOS、Android 和 muse.ai。9 月 23 日关于眼镜的帖子也没有补充任何关于获取访问权限的信息。所以没有代码可找，没有队列可加入，也没有任何有记录的机制能让别人给你一个。

有两点必须直说，因为把猜测包装成答案，比给出否定结论更糟。我们只能报告 Meta 发布的内容；如果某个需代码才能访问的项目存在于未公开列出之处，Meta 自己的页面并未记录它，我们的任何页面也不应被解读为承诺存在这样一个项目。而这一节之所以存在，正是因为该名称正以完全相同的形态被搜索：这个短语有稳定的搜索量，而我们目前能回答它的每一页都是那篇发布帖——这说明需要的是参考页，而不是又一篇公告。

你能调用 Muse 吗？不能——以下就是我们进行路由的方式

Meta 的 Muse 是一款消费级产品，并非我们所收录的模型；至于 OrcaRouter 是否提供任何与之对应的内容，答案是否定的：muse-agent在我们的目录中并不是一条路由，Meta 的该 agent 也不是我们托管、代理或转售的对象。承载其底层模型与承载该 agent 是两回事，本页面不会将两者混为一谈。截至 2026 年 9 月 29 日，Meta 的 Muse Spark 价目表也未以任何我们能读取的形式发布，因此此处没有任何内容会作为价格归于 Meta。

我们的实时模型列表确实收录的——截至今日核查——是模型本身：Muse Spark 1.2，即 Meta 所描述的、面向复杂智能体任务的推理模型，上下文窗口为 1,048,576 个 token，与 Muse Spark 1.1 并列。我们为它提供的模型卡是一条实时路由，本周已有真实流量跑在上面，按供应商费率计费，我们不额外加价——因为我们直接透传供应商的标价，而不是加收服务费，所以 Meta 一旦调价，当天就会落到我们这边。更新的 1.3 检查点不在我们的目录中，而我们不会列出自己无法提供服务的模型。如果你想以开发者而非产品用户的方式获得该智能体的能力，调用我们确实在提供路由的那个检查点才是你真正能够完成的购买，而且同一把密钥无需第二把，就能触达目录中的其余全部模型。

悬而未决的问题

Meta 没有为 Muse 发布任何基准测试，因此没有可供争论的记分牌，剩下的问题在于，一种异常严格的权限模型能否经受住真实工作的检验。有三件事值得关注：当智能体在连接多个连接器的情况下长时间无人值守运行时，Sentinel 的能力授权是否仍然可靠；Meta 最高标价 13 万美元的提示注入类漏洞是否会在真实环境中出现，因为赏金是公开的，这意味着“没有报告”是一种可被检验而非仅凭信任的说法；以及 Muse Confidential VM 是否会如 Meta 所说在今年晚些时候发布，这将把信任锚从 Meta 的基础设施转移到用户持有的密钥。

对于今天正在做决定的读者来说，这个决定很小。如果你在美国，使用 iOS、Android 或网页端，Muse 并没有被任何你必须自己寻找的东西挡在门外——你打开它，选择要连接哪些服务，查看它会请求哪些权限，并让审计记录始终可见。如果你在其他任何地方，或者在一个 Meta 尚未发布的平台上，就没有什么可兑换的，也没有代码要去找，诚实的建议就是别再找了。而如果你想要的是模型而不是智能体，那是一种单独的、简单得多的购买，是在经路由的检查点（routed checkpoint）上完成的，而不是订阅。