在 Muse 为我搭建网站时，我看到一个标着 azure/muse-special 的模型，就顺着这条线索往下挖。这是继我关于 Muse 运行时导出的文章登上 Hacker News 首页后，第二次翻查 Muse 的文件系统。这次我盯住日志里那个 muse-special 模型，直接问：Muse 背后是不是真的在用 OpenAI 和 Claude 的模型。Muse 会记录每个代理会话用的是哪个模型，而我虚拟机里几乎每条会话日志都指向 Meta 内部的 Avocado。

Muse 在帮我建网站时，我发现了一个标着 azure/muse-special 的模型。于是我挖得更深了一些。

这是我上一篇讲 Muse 运行时的帖子登上 Hacker News 首页之后，翻查 Muse 文件系统的第二部分。

这次我聚焦在日志里发现的一个叫 muse-special 的模型，并直面一个问题：Muse 是否在幕后用了 OpenAI 和 Claude 的模型？

一次奇怪的会话

Muse 会记录每个 agent 会话用的是哪个模型。

我虚拟机里几乎每一条会话日志都路由到 Meta 的内部模型 Avocado。

但有一个 subagent 用了名为 azure/muse-special 的模型。

有意思……

顺着名字查下去

我很好奇，在 Cursor 里搜了整个 repo，找到这么一句：

“GPT Responses model client via MAGI native Azure OpenAI lane.”

好吧。

模型目录似乎先列出 azure/muse-special，然后是 azure/gpt-5.6-sol。

于是我又去搜会话记录……

有两个细节很突出：

1. 签名标为 gpt_responses_v1，包含以 gAAAAA 开头的加密 payload（OpenAI 用的格式）。
2. 工具调用 ID 用 call_ 加 24 个大小写混合字符。

这和其他所有行都不一样，Avocado 会话打印的是 call_ 加 32 个十六进制字符。

这些小细节说明，muse-special 有可能是 OpenAI 的模型，或者用的 OpenAI 的 Responses API。

那 muse-special 是不是通过 Azure 提供的某个 GPT 模型的别名？

文件没告诉我具体是哪个 GPT 模型，也没说这个 subagent 当初为什么选中它。

模型目录

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 客户端，带请求处理、提示转换和流式解析：

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

好，那现在我们就要想了……为什么？

Anthropic、OpenAI 等的 API key 文件都在，访问权限只给 inference-proxy 服务。

……但 env 里还有一个 proxy 的 kill switch 设置。

JARVIS_ANTHROPIC_BASE_URL_REVPROXY_OVERRIDE=0，注释说这是 live kill switch，不是过时配置。

为什么要带上这些？

我猜有几种原因。

1. OpenAI 或 Anthropic 的模型在某类任务上确实更强，Muse 现在做不到，于是有选择地路由过去。
2. 这些 VM 都带有对模型响应、工具调用等做 A/B 测试的能力，用于蒸馏和 RL。

蒸馏还是 RL？也许吧。我不知道。

这引向一个事实：Muse 背后的模型最终是服务端的选择。

运行时有多家 provider 的客户端，Meta 因此可以不问用户就改路由。

我这边只有一个没用 Avocado 的异常会话，但基础设施是具备的。

那 Meta 是不是在从其他前沿实验室蒸馏？

（技术细节，简而言之：不是。）

muse-special 的原始推理是加密的。daemon 把它存下来，下一轮发回 Azure。二进制里明确写着，加密推理不能使用 RL completion-server override。

所以 Meta 能看到的只有回复、工具调用，以及 OpenAI/Anthropic 偶尔返回的简短推理摘要。原始思维链加密，RL 服务器拒收这些 blob。没有迹象表明 Meta 复制了 OpenAI 或 Anthropic 的权重。

Avocado 模型则不同：thinking 文本直接写进 transcript，签名为空，可供 RL 使用。

所以按隐私说明和 repo，Avocado 模型确实表示对话可用于在 Meta 开发 AI，除非你选择退出。（合理。）

结语

这是我自己对 Meta 一次很酷发布的探索。

我最新的猜测是：muse-special 是通过 Azure 提供的 OpenAI 模型。

不管怎么看 Meta，他们在这个项目上拉来的人才值得肯定。在满是聊天机器人和搜索框的世界里，他们走了一条不同的路；我第一篇帖子引来一些关注后，高管团队的反应也相当不错，愿意主动联系一个无名小卒解释他们的思路。

不是每天都能看到一款可能触达数亿人的产品的文件系统内部。

看到运行时内部，让我们对个人 agent 这件事的走向有了早期一瞥，这一周读下来非常有意思。

事情似乎发展很快。还没有崩，暂时。

讨论围绕作者在 Muse 文件系统里翻出一个调用 azure/muse-special 的后台 agent、并推测它指向 Azure 上的某个 OpenAI 模型展开，主要分歧在于证据是否支撑「OpenAI 模型」这个结论，以及 Meta 为什么要绕道别家模型。

认为把结论说成「OpenAI 模型」证据不足

• 从转录和守护进程二进制只能推出它跑在 Azure 上，无法确定是哪家、哪个模型，标题的指向性过强。(较多人) > 我没看到任何能证明这是「OpenAI」模型的证据，这个标题实在误导。（@Tiberium）

认为调用外部模型这件事本身才反常

• 不太像算力不足，更像担心自家模型的回答质量做兜底，但这条推理也说不通，不排除另有原因。(较多人) > 如果只是算力不够还说得过去，可这看起来完全不像是算力问题，难道是不放心自家模型的输出？（@GenerWork）

关注 Meta 若真向 OpenAI 付费会不会暴露在公开文件里

• 若存在这样的交易，按理会出现在公开披露或正式文件中，这本身就是一条可追查的线索，反差感也正来自这里。(少数人) > 如果真有这么一笔交易，它难道不会在公开或官方文件里露出来吗？（@6thbit）

以扎克伯格的性格为由否认这桩交易

• 认为他太骄傲，不会去给竞争对手送钱。(少数人) > 扎克伯格不会干这种事，他太骄傲了。（@sourcecodeplz）

在辨认这到底是哪个模型

• 有人印象里是 1.3 spark；也有人反馈用 Muse 1.3 spark 时偶尔会冒出像内部指令的中文片段，既像模型身份混乱，也像本地化或提示词串了味的痕迹。(少数人) > Muse 1.3 spark 有时会给我吐出中文的内部指令，像「快点」「去求助」这种。（@manav）

有价值的补充

• 作者说明这是 Muse 文件系统系列的第二篇：运行时还自带一个 Anthropic 客户端，以及一份列出 Claude、GPT、Kimi 的模型目录，但他本人的会话中没有观察到 Claude 被调用。
• 也就是说，「后台 agent 跑在 Azure 上」和「用的是 OpenAI 的模型」之间还缺一环，这正是本轮质疑集中攻击的缺口。
• 评论里还提到一个未解的问题：如果真有 Meta 侧调用外部模型的安排，公开申报文件是否会留下记录，目前没人给出答案。