TL;DR：研究者 Peter James 在 2026 年 9 月 25 日披露，他检查自己 Muse 虚拟机的会话日志时，发现 9 月 21 日有一个子智能体会话使用
azure/muse-special，而其他会话几乎都显示 Meta 的 Avocado。代码注释、gpt_responses_v1签名和工具调用 ID 让他推测它可能通过 Azure 调用了 OpenAI 模型；现有文件没有说明实际型号、路由原因，也不足以证明 Meta 长期使用或训练了竞争对手的模型。
上图是本期节目封面，属于模型路由的视觉示意，不是 Muse 内部系统截图。
你以为自己正在和某家公司做的智能体对话，后台实际由谁回答？在服务端可以随时选择模型的产品里，用户往往看不到这一步。Muse 的一份会话日志让这个问题有了具体样本，也让人看清“安装了客户端”“配置了模型”和“实际调用了一次”之间的差别。
🎬 视频版（B站） ｜ 🎧 音频版（8 分 19 秒）｜ 🟢 Spotify 订阅 ｜ 📖 偏好阅读？文字版就在下方 👇
一个会话为何引人注意
Muse 是 Meta 的个人智能体。James 此前让它把自己可见的文件归档并发送到他的 Google Drive。他报告压缩包约 2.7 GB，解压后约 6.8 GB，里面似乎包括分配给他那次会话的 Linux 环境文件、内部文档、技能和智能体日志。他没有公开归档、密钥或完整会话记录，也明确说没有证明逃出了容器边界。
随后，他检查这份环境中的模型路由记录。几乎所有会话都标为 Meta 内部的 Avocado，只有 2026 年 9 月 21 日的一个子智能体会话写着 azure/muse-special。一条异常路由足以继续调查，却不能代表每位用户、每类任务都走相同路线。
名称、注释和会话指纹分别说明什么
在相关代码里，James 找到一条描述 GPT Responses 客户端、通过 Azure OpenAI 路线工作的注释；模型目录把 azure/muse-special 列在 azure/gpt-5.6-sol 附近。这些信息说明运行时具备对应接口和配置，但目录相邻不是某次会话实际型号的证明。
更直接的线索来自他查看的那条会话转写：签名标为 gpt_responses_v1，包含以 gAAAAA 开头的加密负载；工具调用 ID 采用 call_ 加 24 位大小写混合字符，而他看到的 Avocado 会话使用 call_ 加 32 位十六进制字符。作者认为这些细节与 OpenAI 的响应格式相似。
由此可作出的谨慎判断是：这条 muse-special 会话可能经过 OpenAI 风格的 Responses 接口，也可能是经 Azure 提供的 OpenAI 模型。James 本人把“它是经 Azure 服务的 OpenAI 模型”称为自己的最佳猜测。日志没有给出准确模型名，也没有解释为什么该子智能体被路由过去。
模型目录不等于实际使用记录
James 还发现，Muse 的 hatch 运行时目录包含约 15 个 Avocado 版本，以及 Claude、GPT 和 Kimi 等模型的标识；Anthropic 客户端甚至有请求处理、提示词转换和流式解析代码。部分 API 密钥文件只允许推理代理服务访问，环境中还出现一个代理开关。
这些文件表明系统有多模型接入的能力，却不能证明所有列出的模型都曾在他的会话里运行。作者展示的实际异常会话只有一个。这也是读内部配置时最容易犯的错误：把“可用”写成“已用”，再把“一次”写成“常态”。
加密推理能排除什么疑问
另一个猜测是，Meta 是否借用别家的模型来训练自己的模型。James 查看代码后认为，这条 muse-special 会话的原始推理以加密负载保存，目的是在下一轮回传给 Azure；二进制信息还表明强化学习服务器的相关入口不接受这种加密推理负载。
按他看到的流程，Meta 可见的是回复文本、工具调用，以及提供方可能返回的简短推理摘要，而不是被加密的原始思维链。Avocado 则不同：其推理文本在作者看到的转写中以明文出现，签名为空。
这能约束一个具体说法：现有证据不支持“Meta 直接拿到了竞争对手的原始思维链或模型权重”。它无法单凭一份运行时归档，排除所有其他数据用途，也不能替代对 Meta 训练流程的独立审计。作者自己的表述也不是发现了蒸馏行为。
用户究竟买的是哪个服务
对用户来说，值得追问的是实际提供服务的模型和数据处理方是否会变化。模型路由可以提高可靠性，也可能影响隐私约定、输出特性、费用和责任归属。哪项任务可能转交给第三方？用户能否知道本次由谁处理？对话内容在不同提供方之间怎样流转？这些需要产品和合同回答。
本案还没有达到“Meta 正式承认采用某个 GPT 型号”或“所有 Muse 请求都依赖 OpenAI”的证据程度。公开文章给出的只是一台虚拟机、一条异常会话和一组有指向性的技术线索。把证据说准确，反而让问题更清楚：当底层模型是服务端随时可换的选择，用户应该得到什么程度的可见性？
收看本期节目
原始资料与延伸阅读
本文由《听懂 AI》第 039 期《Meta 的新模型里，为什么藏着一个 OpenAI 的名字？》整理而成，核对日期为 2026 年 9 月 28 日。节目采用脚本化双人对谈，并非采访 Peter James 或 Meta。核心证据来自作者对自己 Muse 环境的检查；我们未取得其未公开的归档和完整日志，不能独立复现实验。关于用户披露的建议是本文的编辑性归纳；HN 只提供社区观察。
- Peter James：Is Meta’s Muse secretly running an OpenAI model?——2026 年 9 月 25 日的主要原文，展示异常会话、代码注释和模型目录。
- Peter James：I asked Meta’s Muse for its filesystem and it sent me 6.8 GB——2026 年 9 月 22 日的前篇，说明归档取得方式及披露边界。
- Hacker News 社区讨论——围绕模型路由的讨论，不作为 Meta 实际部署范围的证据。