一句话看懂：开发者在 Meta 的 Muse 构建环境中发现一条名为 azure/muse-special 的独立会话记录，其技术特征与 OpenAI 的 Responses API 高度吻合，说明 Muse 后台可能通过 Azure 调用了外部模型，而不仅依赖 Meta 自研的 Avocado。
事件核心：发生了什么
这是 mouse.dev 作者对 Meta Muse 文件系统的第二轮排查。他在日志里发现，自己所处虚拟机中几乎全部 agent 会话都路由到 Meta 内部模型 Avocado，唯独 9 月 21 日有一个子代理使用了 azure/muse-special。该会话的转录带有 gpt_responses_v1 签名，含有 OpenAI 常见的加密负载前缀 gAAAAA，工具调用 ID 也采用 OpenAI 风格的 call_ 加 24 位混合大小写字符，而 Avocado 会话使用 32 位十六进制。
仓库内模型目录除约 15 个 Avocado 版本外，还列出 Claude Opus 4.6/4.7/4.8、Sonnet 4.6、Haiku 4.5、GPT-5.5 与 GPT-5.6 变体，以及经 Fireworks 等路由的 Kimi K3。Claude 相关代码包含请求转换与流式解析，API 密钥文件也存放在推理代理服务中。作者据此判断，muse-special 很可能是通过 Azure 提供的某个 OpenAI 模型，但具体型号尚不清楚。
为什么重要
这件事的意义不在“Meta 偷用竞品”，而在于推理路由的架构选择。Muse 运行时内置多家模型客户端，意味着最终调用哪个模型是服务端决策，Meta 可以在用户不知情的情况下调整路由。这既是能力补位的常规工程手段，也为 A/B 测试、蒸馏与强化学习留出空间。目前公开信息显示，muse-special 的原始推理过程是加密的，只能回传给 Azure，且 RL 完成服务器拒绝接收这类数据，因此没有证据表明 Meta 在复制 OpenAI 或 Anthropic 的权重。相比之下，Avocado 的思考文本直接写入转录，可供训练使用。
对用户/开发者/创作者的影响
对使用 Muse 的开发者而言，实际体验到的模型能力可能来自不同供应商，任务质量与延迟会随服务端路由变化，但界面和 API 未必提示。若你依赖 Muse 做代码生成或 agent 工作流，建议在关键任务上自行做输出对比，而不是假设背后始终是自研模型。对企业采购方来说，“多模型可路由”正在成为 AI 产品的基础设施能力，评估供应商时应关注其数据是否会被用于训练、以及是否有明确的退出选项。对创作者，短期影响有限，但要知道同一工具的输出风格可能漂移。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
第一，Meta 是否会对 muse-special 的用途给出说明，或将其用于正式功能；第二，模型目录中 Claude 与 Kimi 等外部路线的实际调用比例是否会上升；第三，Avocado 与外部模型在转录、加密和训练授权上的差异，是否会影响 Muse 的数据政策与合规表述。
来源：mouse.dev
