Meta 的 Muse 被曝暗中调用 OpenAI 模型，内部代号 muse-special
Meta 正在测试的 AI 智能体产品 Muse 可能并不像表面上那样“纯自研”。一位开发者在 Muse 构建网站时，从系统日志中发现了一个名为 azure/muse-special 的可疑模型，由此展开了一场对 Muse 文件系统的深度挖掘。
一个不该出现的模型名
据该开发者描述，Muse 会记录每个智能体会话所使用的模型。在虚拟机里，几乎所有会话日志都被路由到 Meta 的内部模型 Avocado，但有一个子智能体却调用了 azure/muse-special。
顺着这个名字，他在 Cursor 仓库中找到了这样一行说明：
“GPT Responses model client via MAGI native Azure OpenAI lane.”
模型目录里也同时列出了 azure/muse-special 和 azure/gpt-5.6-sol。
日志里的“指纹”
真正让开发者确信这不是误报的，是会话记录中的两个技术细节：
- 该模型的签名标记为 gpt_responses_v1，并包含以
gAAAAA开头的加密载荷——这是 OpenAI 常用的格式。 - 工具调用 ID 使用
call_加 24 位大小写混合字符，而 Avocado 会话全部是call_加 32 位十六进制字符。
这些特征指向一个结论：muse-special 很可能是通过 Azure 提供的 OpenAI 模型或 OpenAI Responses API 的别名。至于具体是哪个 GPT 版本，日志并未透露。
模型目录暴露的“全家桶”
更值得注意的是 Muse 智能体守护进程附带的模型目录，其中列出了约 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 的接入并非只挂了个模型 ID，还包含完整的客户端代码：anthropic/request_flow.rs、anthropic/convert_prompt.rs、anthropic/parse_sse_stream.rs，覆盖请求处理、提示词转换和流式解析。
为什么要“偷偷”用竞品？
文件中存在 Anthropic、OpenAI 等服务的 API 密钥，访问权限被限制在 inference-proxy 服务内，同时还设有一个代理“终止开关”。
作者推测，原因可能很简单：在某些特定任务上，OpenAI 或 Anthropic 的模型确实表现更好。对于 Meta 这样急于在 AI 智能体赛道追赶的公司来说，内部模型 Avocado 尚未在所有场景下达到可用标准，临时借用外部模型补齐能力短板，是一种务实的工程选择。
但这也引出一个尴尬的问题：当 Meta 对外宣传 Muse 时，它到底是在展示自研实力，还是在包装一个多模型编排层？目前没有官方回应，开发者也只能从日志和文件结构中拼凑真相。
这一发现再次提醒我们，在 AI 产品竞争白热化的当下，“自研”与“调用”之间的边界，往往比宣传材料所呈现的要模糊得多。
