← 文章 / AI技术

Hacker News 2小时前 · 2026-09-26 08:28:56 · 3 阅读

Meta 的 Muse 疑似在用 OpenAI 模型：日志中出现 muse-special

我在 Muse 帮我建网站的时候，发现日志里出现了一个名为 azure/muse-special 的模型。于是我深挖了下去。

这是继我上周那篇文章登上 Hacker News 首页之后，继续翻查 Muse 文件系统的第二篇。

本文聚焦我在日志中发现的一个叫 muse-special 的模型，并直面一个问题：Muse 背后实际上是在用 OpenAI 和 Claude 的模型吗？

一个奇怪的会话

Muse 会记录每个 agent 会话所使用的模型。

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

但有一个子 agent 用的是 azure/muse-special。

有意思……

Session counts by model — 图 1. 我的虚拟机中按模型分组的会话。全部都是 Avocado，只有 9 月 21 日的一个 azure/muse-special 会话例外。点击图片可放大。

顺着名字查下去

这让我很好奇，于是我在 Cursor 里搜索了整个代码仓库，找到了这么一段：

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

好嘛。

模型目录里似乎把 azure/muse-special 排在 azure/gpt-5.6-sol 前面。

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

有两个细节引起了我的注意：

签名的标记是 gpt_responses_v1，还带有一个以 gAAAAA 开头的加密载荷（这是 OpenAI 惯用的格式）。
工具调用的 ID 是 call_ 后跟 24 个大小写混合的字符。

这和 Avocado 会话打印的所有其他行都不一样（那些是 call_ 后跟 32 个十六进制字符）。

Transcript lines from the muse-special session — 图 2. muse-special 会话记录中的内容：OpenAI 风格的 call_ ID，以及带 gAAAAA 加密载荷的 gpt_responses_v1 签名。点击图片可放大。

这些小细节告诉我，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

Model families shipped in the hatch daemon — 图 3. 我对 hatch daemon 中发布的模型 ID 的总结，按家族分组。发布 ID 仅表示运行时可以寻址，并不意味着它被实际使用。点击图片可放大。

Anthropic 的底层设施

Claude 的支持不仅限于模型 ID，还包括具有请求处理、提示词转换和流式解析器的 Anthropic 客户端：

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

好吧，现在你可能会好奇……为什么？

系统中存在 Anthropic、OpenAI 等 API 密钥文件，且访问权限限制在 inference-proxy 服务内。

……但环境变量中还有一个代理开关设置。

The Anthropic reverse proxy override in the env file — 图 4. 运行时环境变量中的 JARVIS_ANTHROPIC_BASE_URL_REVPROXY_OVERRIDE=0。注释称其为实时开关（live kill switch），而非陈旧配置。点击图片可放大。

为什么要发布这些？

我想，这里有几个原因。

第一，OpenAI 或 Anthropic 的模型可能在某些 Muse 目前无法完成的任务上表现得更出色，因此有选择地进行路由。
第二，所有这些 VM 都具备对模型响应、工具调用等进行 A/B 测试的能力，目的是用于知识蒸馏（distillation）和强化学习（RL）。

是蒸馏还是强化学习？也许吧。不清楚。

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

运行时支持多供应商客户端，这赋予了 Meta 在不打扰用户的情况下调整路由策略的能力。

在我的测试中，只有一场异常会话没有使用 Avocado（Meta 自家模型），但基础设施显然已具备这种切换能力。

Meta 在进行模型蒸馏吗？

等等，所以 Meta 真的在对其他前沿实验室的模型做蒸馏吗？

（深入技术细节。简而言之：没有。）

在 muse-special 模型中，原始推理过程是加密的。守护进程会将其存储，以便在下一轮对话时发回 Azure。二进制文件中明确指出，加密后的推理内容无法使用强化学习（RL）完成服务器的覆盖机制。

因此，Meta 在这里只能看到回复内容、工具调用，以及当 OpenAI/Anthropic 返回时提供的简短推理摘要。原始的思维链被加密，RL 服务器也拒绝处理这些数据块。没有任何迹象表明 Meta 在复制或提取 OpenAI 或 Anthropic 的模型权重。

然而，Avocado 模型的情况不同。其思考文本直接写入对话记录，带有空签名，并可供 RL 系统使用。

因此，根据隐私声明和代码仓库，Avocado 模型确实表明，除非你选择退出，否则对话数据可用于开发 Meta 的 AI。（这一点合乎逻辑。）

结语

这是我对 Meta 这次非常酷的产品发布所做的独立探索。

我目前的最佳猜测是，muse-special 是一个通过 Azure 提供的 OpenAI 模型。

无论你对 Meta 持何种看法，这个项目团队聚集的人才都值得称赞。在一个充斥着聊天机器人和搜索框的世界里，他们采取了不同的路径。此外，高管团队对我首篇获得一定关注的文章回应得相当出色，他们还主动联系我这个无名小卒，解释其设计思路，这种开放态度令人印象深刻。

并非每天都能有机会深入查看一个可能触及数亿用户产品的文件系统内部。

窥探运行时“单元”的内部，让我们得以提前看到这种个人智能代理产品的未来走向。这周阅读和分析这些代码的过程真的非常迷人。

如果你参与过 Muse 的开发，请随时联系我。我很乐意了解更多，并可能做出贡献。

一切都在快速发展。目前尚未出现明显的问题。

pete at mouse dot dev

-Pete

@heypeterjames

原始来源： Hacker News