Meta 的 Muse 似乎使用了一个标注为 muse-special 的 OpenAI 模型

我在 Muse 帮我搭建网站时，发现了一个标注为 azure/muse-special 的模型。于是我深入挖掘了一下。

这是我挖掘 Muse 文件系统的第二篇文章，此前我的上一篇文章登上了本周 Hacker News 首页。

本文聚焦于我在日志中发现的一个名为 muse-special 的模型，并试图回答一个问题：Muse 的后台是否真的在使用 OpenAI 和 Claude 的模型？

一个奇怪的会话

Muse 会记录每个智能体（agent）会话使用的模型。

我的虚拟机里几乎所有会话日志都被路由到了 Meta 的内部模型——名为 Avocado。

但有一个子智能体（subagent）使用了一个叫 azure/muse-special 的模型。

有意思……

顺着名字查下去

这引起了我的好奇心，于是我在 Cursor 里搜索了仓库中的代码，找到了这样一段：

"GPT Responses model client via MAGI native Azure OpenAI lane."

（“通过 MAGI 原生 Azure OpenAI 通道的 GPT Responses 模型客户端。”）

好的。

模型清单（model catalogue）中似乎先是列出了 azure/muse-special，然后是 azure/gpt-5.6-sol。

于是我去搜索自己的会话记录……

我发现了两处特别值得注意的细节：

1. 签名被标记为 gpt_responses_v1，其中包含一段以 gAAAAA 开头的加密负载（这是 OpenAI 所采用的格式）。
2. 工具调用（tool call）ID 以 call_ 开头，后面跟着 24 个大小写混合的字符。

这与 Avocado 会话中打印出的所有其他行都不同（那些是 call_ 后面跟着 32 个十六进制字符）。

这些细节告诉我，muse-special 模型很可能是 OpenAI 的一个模型，或者是 OpenAI 的 Responses API。

那么，muse-special 是通过 Azure 服务的某个 GPT 模型的别名吗？

文件和日志并没有告诉我具体是哪一个 GPT 模型，也没有告诉我为什么子智能体一开始会选择它——但让我们先退一步，进一步探索……

模型清单

Muse 智能体守护进程（agent daemon）随附的更完整模型清单中，列出了大约 15 个版本的 Avocado，此外还包括：

• Claude Opus 4.6 / 4.7 / 4.8
• Sonnet 4.6 和 Haiku 4.5
• 通过 OpenAI、Azure 和 Codex 提供的 GPT-5.5 与 GPT-5.6 变体
• 通过 Fireworks 以及 Meta 自托管路由提供的 Kimi K3

Anthropic 的接入实现

对 Claude 的支持不仅限于模型 ID，还包含一个 Anthropic 客户端及其请求处理、Prompt 转换与流式解析模块：

• anthropic/request_flow.rs
• anthropic/convert_prompt.rs
• anthropic/parse_sse_stream.rs

好，到这里我们多少会开始想……这是为什么？

系统里确实存在 Anthropic、OpenAI 等服务的 API key 文件，且访问权限被限制为只能由 inference-proxy 服务调用。

……不过环境变量里也存在一个用于关闭代理的开关（kill-switch）。

为什么要在产品里内置这些？

至于原因，我能想到的大概有以下几种。

1. 第一种可能是：在某些任务上，OpenAI 或 Anthropic 的模型确实表现更优，而 Muse 目前还做不到，于是他们有针对性地做了路由。
2. 第二种可能是：所有这些虚拟机在出厂时就具备了 A/B 测试模型回复、工具调用等的能力，目的是为蒸馏（distillation）和强化学习（RL）收集数据。

蒸馏或 RL？也许吧。我也不清楚。

这把我们引向一个事实：Muse 后端使用的模型，归根结底是一个由服务端决定的选择。

运行时内置了面向多个提供商的客户端，这使得 Meta 可以在不告知用户的情况下随时更改路由策略。

在我这里，只出现了一个没有使用 Avocado（Meta）模型的异常会话，但相关基础设施已经具备了这种能力。

Meta 是否在进行蒸馏？

等等，那么 Meta 是在从其他前沿实验室进行蒸馏吗？

（技术向说明。TL;DR：不是。）

在使用 muse-special 模型时，原始的推理内容（reasoning）是加密的。守护进程会把它存下来，以便在下一轮发送回 Azure。在二进制文件里明确写着：这段加密后的推理内容不能使用 RL 完成服务器覆写项（RL completion-server override）。

因此，Meta 在这里能看到的只有回复内容、工具调用，以及当 OpenAI / Anthropic 返回时附带的一段简短的推理摘要。原始的思维链（chain of thought）是加密的，而且 RL 服务器会拒绝接收这些数据块。没有任何迹象表明 Meta 在复制 OpenAI 或 Anthropic 的模型权重。

不过，Avocado 模型的处理方式就不同了。其思考文本会直接写入会话记录，签名为空，可供强化学习使用。

所以，按照隐私说明和仓库中的代码来看，Avocado 模型确实意味着：除非用户主动选择退出，否则其对话内容可能被用于 Meta 的 AI 开发工作。（这很合理。）

结语

这是我基于自己对 Meta 这次非常酷的发布所做的探索。

我最好的猜测是：muse-special 是一个通过 Azure 服务的 OpenAI 模型。

不管你对 Meta 怎么看，这个项目所聚集的人才都值得肯定。在一个充斥着聊天机器人和搜索框的世界里，他们走了一条不一样的路；而在看到我上一篇有些关注度的文章后，执行团队也做出了相当出色的回应，并展现出愿意主动联系我这个无名小卒、向我解释他们想法的姿态。

能够一窥一款有可能触达数亿用户的产品内部文件系统，并不是每天都有的机会。

看清一个运行时容器的内部，让我们得以提前一窥“个人智能体（personal agent）”这条赛道可能走向何方；这一周里通读所有这些内容，真的非常有趣。

如果你曾参与过 Muse 的任何工作，欢迎与我联系。我很想了解更多，甚至有可能会出一份力。

一切似乎都在快速推进。至少目前，还没有真正翻车。

pete at mouse dot dev

—Pete

@heypeterjames