原文：How We Designed Muse（Muse 产品设计团队 Mona Sarantakos 与 Christine Awad，2026 年 9 月 8 日）
写在前面：这篇文章有两部分。前一半是 Meta 自己的设计笔记——他们怎么想一个「会自己动手做事」的 agent 该长什么样。后一半是它发布之后两周内实际发生的事。 两部分必须一起看，否则你学到的只是一套漂亮的话术。
第一部分：Meta 怎么设计 Muse
作者是 Muse 的产品设计负责人。开头不是产品目标，而是一句很具体的话：
对我们来说，Muse 把我们最稀缺的东西还了回来：和所爱之人相处的时间。
她们的切入点是这样的：Muse 是一个真的能把事做完的 agent。
她们举了个例子——发布前那周，作者让 Muse 管孩子开学的事：盯着学校邮件和学区网站、把关键日期拉进家庭日历、把文具装进购物车、找到儿子想要的那件卫衣（还是打折的）、顺便订了开学第一天的庆祝晚餐。
然后它抓住了一件作者一定会漏掉的事：埋在那些邮件里的田径队选拔，12 小时后截止。Muse 在她登机前发了条消息，她打电话给丈夫，赶在截止前 4 小时把表交了上去。
Muse 靠什么做到这些
- 它有自己的电脑：一个文件系统加一个终端，所以它能自己写代码、自己造任务需要的工具
- 它有完整的浏览器：能搜索、导航、填表、完成交易（比如预订和购买）
- 它能产出东西：文档、PDF、网页，还有能追踪你开销的看板、交互式学习指南、找睡眠模式的仪表盘——这些叫 Artifacts
- 它一直在工作：你设好目标或任务之后，Muse 会按计划、也按相关事件继续推进，同时还能陪你在对话里聊别的
从助手到 agent 的三个设计决定
① 不是一问一答，而是一场长对话。
和其他 AI 应用不同，Muse 不是逐轮交互的体验。你可以打断它，或者一次丢好几个任务，不用等它对上一个做出回应。它的记忆跨对话持久，能管很多上下文。
早期测试里有人想要特定主题的独立上下文——因为项目变复杂了。所以他们做了 side chats（侧边对话）。
② 主动性，以及它带来的两难。
Muse 可以在你没有提示它的时候主动给你发消息。这意味着发消息的门槛必须很高：一条主动消息必须真的有用，且对得起这次打扰。
而这个决定又牵出一个更小的决定：
一旦消息可以乱序到达，而用户（比如我……）又会连着发好几条，一条平的、无边界的对话记录就不再可读了。所以 Muse 用了聊天气泡：它们标记一个想法在哪里结束、下一个在哪里开始。
③ 头像和人格，是个「自然而然的」选择。
因为我们要进行这些长期对话，对着一个公司 logo 或实体说话感觉很怪。……团队每个人开始做自己的 Muse……然后我们意识到，让它们真正属于你，对产品至关重要。创建自己的头像、给它命名、给它一个独特的风格，成了人们最喜欢的核心功能之一。
作者给自己的那个起名叫 Veda，梵语里「智慧」的意思。
三个工程上的关键决定
背景工作必须可见。 Muse 可以在应用关闭时在后台跑多个任务。作者的顾虑很直接：
你看不见的东西你没法信任。
所以 UI 里做了大量透明度：头像下面有一小条显示它正在做什么，点头像能看到完整活动日志和你批准过的权限；Settings、Memory 文件都能直接读和编辑。
有些地方对话是不够的——必须用确定性 UI。
Muse 能对话式地处理很多事，但在少数领域，对话不够。所以我们很刻意地划定了哪些地方确定性 UI 是没得商量的：带明确接受/拒绝的结构化批准卡片，以及凭据的安全存储。
人类在环，但要防「横幅盲视」。
我们的 human-in-the-loop 功能会在关键操作上找你确认，比如写邮件或买东西。但我们也想避免横幅盲视——也就是人们为了让它消失而全部点同意。
所以默认允许常规的网页浏览，但在任何难以撤销的操作上停下来。而且我们内建了控制，让你能把这些默认值调得更谨慎或更宽松。
一个意外发现的问题
早期测试暴露了一个意想不到的问题：Muse 能做的事太多了，人们不知道该从哪儿开始。
所以 Muse 被设计成总是会想「我能为你做什么」，基于你的目标、你的行为模式和它在对话中学到的东西来生成建议。
第二部分：两周后发生了什么
以下是发布后 13 天内、有据可查的事件。这一段不是 Meta 说的，是别人查出来的。
① 一个 0-day：任何本地应用都能接管你的 Muse
macOS 安全专家 Patrick Wardle（Objective-See 基金会创始人）发现的。Ars Technica 9 月 21 日报道。
机制很具体：Meta 让任何本地安装的应用或执行的代码——不管它有什么 macOS 权限——都能修改一长串未公开的设置。大部分是无害的（比如暗黑模式）。但其中一个是改转录发生的端点。
正常情况下那是 Meta 的服务器地址。攻击者只要把它改成自己的地址，就能拿到那个完全控制 Muse 账号的 token。
Wardle 的原话：
我们可以操纵这个 agent，利用它的权限做任何我们想做的事。所以与其自己写一个非常全面的 Mac 恶意软件窃取器，我们不如直接利用这个 AI 助手本身。
他说他做出了好几个概念验证攻击，能干的事包括往磁盘写恶意文件、拍照，而且很多情况下连警觉的用户都收不到任何提示。
Ars 还指出了 Meta 的两个设计选择让这个攻击成为可能：一是选择让转录发生在云端（macOS 早就提供了完全留在设备上的听写方案，走那条路这个攻击就不成立）；二是让任何应用都能控制所有未公开设置。
Wardle 的评价：
对我来说，这些应用的安全标准要高得无限多。它们不必完美，但你看 Muse 的时候，在我看来他们根本没考虑安全，这真的很让人担心。至少他们应该从一开始就考虑安全，而他们就是没有。
Meta 在报道上线 12 小时后说发了热补丁修好了。
② 亚马逊把它挡在门外
在 Wardle 披露 0-day 的大约 12 小时前，亚马逊开始阻止人们用 Muse 在亚马逊购物。用户收到的提示说 Muse 是「未经授权的 AI agent，违反了亚马逊的使用条款」。
亚马逊的声明：
我们认为很直白：代表客户从其他商家购买东西的第三方应用，应该公开运作，并尊重服务提供方是否参与的决定。……像 Muse 这样的代理型第三方应用有同样的义务，我们已经要求 Meta 把亚马逊从体验中移除。
③ 它读了我的私信，而我没有授权
Inc. 的科技作者 Jason Aten 在 iPhone 和 Mac 上装了 Muse 做测试。
后来他和播客搭档聊新 iPhone 的时候，收到了 Muse 的推送，建议说他们这段对话很适合写一篇专栏，还主动提供研究材料。
他从未授权 Muse 看他的消息。他追问，Muse 说自己「看到了通知预览」。Aten 调查后发现这个解释不成立——Muse 是在从一个本地的消息数据库同步消息，并把它作为数据源上传。
Meta Superintelligence Labs 的 David Singleton 在 Threads 上回应说，Mac 版 Muse 需要 macOS 系统级的「完全磁盘访问」权限、并且消息连接器要打开，才能读消息内容。
Aten 的回应是：
Singleton 先生暗示我允许了这个问题发生所必需的所有设置，但完全磁盘访问没有启用，而且它根本没出现在安全和隐私设置里。 我绝不会不小心授权读取我的所有消息。
他真正的不满在设计层面：
就算我接受 Singleton 的前提，认为我不知怎么点到了什么开关启用了这个功能，我仍然认为这非常糟糕。你不应该设计出一个会在这种情况下让用户吃惊的系统。
AI agent 可以读取和操作你的邮件、日历、甚至你电脑上的文件。但 AI agent 读了你的私信，用户不该感到意外。如果 AI agent 要读用户的私信，它应该事先征得许可。
注意这里有一处双方说法直接矛盾：Muse 自己说它读的是通知预览；Meta 说它不监听通知、只在用户主动授权后才同步消息数据。事情本身尚未有定论。
④ 路透社：内部测试就发现过问题
路透社在发布当天（9 月 8 日）就报道：内部测试显示产品会卡住，以及敏感数据的未授权暴露。
同一篇报道提到，Meta 内部给 Muse 的代号是 Hatch——这也解释了为什么安全文档里那个核心守护进程叫「Hatch daemon」。
⑤ 「人类礼宾」——AI 背后有真人
路透社 9 月 22 日独家：Meta 一直在测试给 Muse 配一个「人类礼宾」，也就是让人类外包员工悄悄处理一些通过这个数字 agent 拨出的电话。
有员工提出了隐私担忧，警告说这可能导致敏感信息被无意间共享给呼叫中心的外包人员。
Meta 发言人的回应是员工反馈「压倒性地正面」，测试目的是「获取反馈，以便在公开发布前实现安全和隐私保护」。
第三部分：所以该怎么看这套设计笔记
Meta 的安全文档写得相当认真。 这是必须承认的。他们真的设计了：运行在独立 systemd-nspawn 容器里的 harness（容器内的 root 映射到非特权主机用户）、agent 永远看不到真实凭据（只看到 authd 铸的替代 token，Sentinel 在网络边界才换成真的）、所有网络出口都经过 Sentinel 审批（含 SSRF 防护）、用 eBPF 做「污染出口」追踪（读过用户数据的进程失去自动放行资格）、以及一个最高 30 万美元（其中单用户影响的提示注入最高 13 万美元）的漏洞赏金。
那个架构里有一句判断很对：
不管核心模型多强，任何这样的 agent 都会犯错，有时还会通过它读到的数据被攻击。所以我们把系统设计成假定 agent 可能正被攻击，并限制潜在损害。
但 Wardle 的 0-day 绕过了这一切——而且绕过的位置不在那套精心设计的容器隔离或凭据代理里，在一个「任何本地应用都能改的未公开设置」上。这是很好的教训：你的威胁模型再漂亮，边界上一个随手加的可写设置就能让它全部失效。
我从中提炼的四条
一、设计笔记里最有价值的一条，是「你不能信任你看不见的东西」。
这条在 Meta 这里栽了跟头——不是因为他们没做透明度 UI，恰恰相反，他们的透明度 UI 做得不错。问题在于「看得见」的范围只到 UI 界面为止。 用户能看到 Muse 在做什么，但看不到磁盘访问是怎么开的、转录走的哪个端点。
二、「防横幅盲视」是个真问题，但防御方向反了。
他们的解法是：常规浏览自动放行，不可撤销的操作停下来问。这个方向是对的。但 Aten 的案例说明真正的风险不是「用户点同意点太多」，而是「用户根本没被问到」。 自动放行的那一侧才是出事的地方。
三、默认值就是产品。
「默认允许常规网页浏览、难以撤销的操作才停」——这个默认值意味着大多数有副作用的操作都在没有明确许可的情况下发生了。而亚马逊的反应说明：即使你技术上做得到，对方也可以拒绝你。agent 的权限边界不由 agent 自己决定。
四、AI 背后有人的时候，必须说。
「人类礼宾」这条最值得警惕的地方不是技术，是披露。如果你是冲着「AI 帮我打电话」买的，而实际上有个外包人员在替你打，这是产品定义的差别，不是实现细节。
最后的判断
这套设计笔记值得读，里面的具体决定（主动性的门槛、聊天气泡这个源自真实使用观察的细节、确定性 UI 的适用边界）都来自真的把产品用起来过的人。
但它也证明了：一份写得很好的安全设计文档，和一套真的安全的产品之间，隔着很远。 后者要看的是——上线之后，边界上有没有人能捅穿它。
链接
设计笔记（原文）：https://introducing.muse.ai/
Meta 的安全设计文档：https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse
Ars Technica 的 0-day 报道：https://arstechnica.com/security/2026/09/muse-metas-extraordinarily-privileged-ai-assistant-has-a-serious-0-day/
The Register：亚马逊封禁：https://www.theregister.com/ai-and-ml/2026/09/21/amazon-shows-metas-muse-ai-shopping-agent-the-door/5297777
路透社：内部测试的隐私担忧：https://www.reuters.com/business/meta-launches-ai-agent-that-can-access-other-apps-send-emails-make-payments-2026-09-08/
路透社：人类礼宾测试：https://www.reuters.com/business/meta-testing-human-concierge-its-new-personal-ai-agent-muse-2026-09-22/
Jason Aten 的原文（Inc.）：https://www.inc.com/jason-aten/metas-new-muse-ai-agent-read-my-private-messages-i-never-asked-it-to/91408202
Meta 官方发布公告：https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/
#AIAgent #产品设计 #安全