一个开发者在用Muse给自己做网站时，翻了自己的会话日志，发现了一个标着azure/muse-special的模型。于是他深挖了下去。
这是他翻查Muse文件系统的第二篇，上一篇登上了Hacker News首页。这篇文章聚焦他在日志里发现的muse-special模型，并直面一个问题：Muse背后是不是真的在用OpenAI和Claude的模型？
一个不对劲的会话
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可能是OpenAI的模型，或者至少是OpenAI的Responses API。那么，muse-special是不是一个通过Azure提供的GPT模型的别名？文件和日志没有说明具体是哪个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
对Claude的支持不只是模型ID。仓库里有一套完整的Anthropic客户端，包括请求处理、提示词转换和流式解析器：anthropic/request_flow.rs、anthropic/convert_prompt.rs、anthropic/parse_sse_stream.rs。
Anthropic、OpenAI等服务的API密钥文件都在，访问权限被限制在推理代理服务内。环境变量里还有一个代理的kill-switch开关。
为什么要预置这些？
一种解释是，某些任务上OpenAI或Anthropic的模型确实做得更好，Muse目前做不到，所以按需选择性路由。另一种解释是，这些虚拟机出厂就带着A/B测试模型响应、工具调用的能力，用于蒸馏和强化学习。
但真正的答案是：Muse背后用哪个模型，最终是服务端的选择。运行时内置了多家供应商的客户端，Meta可以在不通知用户的情况下改变路由。在这位开发者的例子里，只有唯一一个会话没用Avocado，但基础设施已经在那儿了。
Meta在蒸馏吗？
用muse-special模型时，原始推理过程是加密的。守护进程把它存下来，下一轮再发回Azure。二进制文件里明确写着，加密的推理内容不能走RL completion-server的覆盖路径。
所以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
热门跟贴