把 LLM 供应商统一成一个接口，然后呢？

大多数团队换模型供应商的流程大概是这样：改几行 BaseURL 和 API Key 的配置，跑一遍测试，没发现大问题，合到主分支。

一周后，线上出现奇怪的 bug。

aimux 想解决的是第一步。它是一个用 Rust 写的 LLM 访问层，项目作者 Dan Kornas 在推文里的定位很清楚：把模型调用收敛到一个 LanguageModel 接口，应用层只认接口，不认供应商。

换模型或者加新供应商，改的是路由层配置，调用方的代码不用动。

按项目描述，它做了这几件事：

• 统一模型接口，换供应商不用改调用代码
• 带供应商预设，本地引擎覆盖 Ollama 和 vLLM
• 八种语言绑定：Python、Node.js、Go、Swift、Kotlin、Java、Flutter、C，核心用 Rust
• 录制回放：请求/响应成对存成 JSONL，离线回放做回归测试
• 按调用选模型，失败时 fallback 到另一个模型

作者强调了边界：aimux 管服务接入，不碰 agent 循环，也不碰 RAG 编排。工具做小一点，说清楚自己不管什么，这是好事。

评论区有个叫 @read__the__diff 的用户指出了另一半问题：换供应商的时候，你的调用代码确实没变，但应用对模型输出的假设变了。

这句话比工具本身有意思。不同模型的输出格式、字段命名、JSON schema 的遵守程度、工具调用的格式，这些不是一层接口抽象能抹平的。代码可以统一，行为不能。

Dan Kornas 自己也这么回复：换之前还是会跑同一套 eval 集，先看工具调用和结构化输出。

另一个用户 @CDG 问得更具体：切换供应商是容易的那半，真正烦的是每个模型的工具调用方式都不一样，aimux 会归一化吗？

推文里没回答。从项目定位看，工具调用格式的差异属于模型行为层面，可能不在服务接入层的职责范围。但这恰恰是很多团队踩过的坑。

所以这东西的价值取决于你把它放在什么位置。

如果代码库里散落着五六个供应商的 SDK，调用方式各异，换一家要动十几处地方，aimux 这类抽象层能省维护成本。统一接口、录制回放做回归测试，这两件事对长期维护有实际意义。

但如果指望它让切换变“无感”，那是另一回事。接口可以统一，模型行为不会。

它支持的录制回放功能值得单独提一句。把现有模型的请求/响应录成 JSONL，换供应商之后回放对比，能比较快地看出行为差异。这就是在补“输出假设不一致”那个洞。

项目 MIT 开源，GitHub 仓库在回复里：https://github.com/arcships/aimux