在对 Meta 新推出的个人代理产品 Muse 进行文件系统深度分析时，发现了一个标记为 azure/muse-special 的特殊模型。这一发现引发了关于 Muse 后台是否实际调用 OpenAI 和 Anthropic Claude 模型的质疑。
异常会话与模型路由
Muse 会记录每个代理会话所使用的模型。在绝大多数会话中，请求均被路由至 Meta 内部模型 Avocado。然而，日志显示有一个子代理使用了 azure/muse-special 模型。
通过对代码库的检索，发现相关注释指出该模型“通过 MAGI 原生 Azure OpenAI 通道获取 GPT 响应”。进一步分析会话转录文件，发现了两个关键细节：
- 签名标记为
gpt_responses_v1，且包含以gAAAAA开头的加密负载，这是 OpenAI 特有的格式。 - 工具调用 ID 由
call_后接 24 个大小写混合字符组成，这与 Avocado 模型使用的 32 位十六进制字符格式显著不同。
这些技术特征强烈暗示，muse-special 实质上是托管在 Azure 上的 OpenAI GPT 模型或其 Responses API 的别名。
隐藏的模型目录与基础设施
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 客户端支持，涵盖请求处理、提示词转换和流式解析等功能模块。此外，系统中存在仅限推理代理服务访问的 API 密钥文件，以及一个代理紧急停止开关环境变量。
多模型集成的目的
集成第三方模型可能出于以下目的：一是针对特定任务选择性路由至表现更优的外部模型；二是利用多模型响应进行 A/B 测试，服务于知识蒸馏和强化学习（RL）。
然而，分析表明 Meta 并未直接窃取竞争对手的模型权重。在使用 muse-special 时，原始推理过程处于加密状态，守护进程仅存储加密负载以便在下一轮对话中回传至 Azure。二进制文件明确禁止强化学习服务器覆盖或处理这些加密的思维链数据。Meta 仅能获取回复内容、工具调用及简短的推理摘要。
相比之下，Meta 自研的 Avocado 模型会将思考文本直接写入转录文件，并允许用于强化学习。根据隐私政策，除非用户选择退出，否则 Avocado 的对话数据将用于 Meta 的 AI 开发。
结语
此次分析揭示，Muse 的运行时环境具备多提供商客户端，使 Meta 能够在不通知用户的情况下动态更改路由策略。尽管 muse-special 的具体身份未在日志中明文标识，但现有证据指向其为通过 Azure 提供的 OpenAI 模型。
这一架构展示了个人代理领域的一种潜在发展方向：即在本地运行基础模型的同时，按需调用云端最强模型以优化性能。目前，Muse 尚未引发颠覆性变革，但其技术实现路径值得密切关注。