any-llm 用一层薄接口替掉多套 SDK：切换供应商只改一个字符串
Communicate with an LLM provider using a single interface
秒懂
- 它是什么？
- Mozilla AI 的 any-llm 把 OpenAI、Anthropic、Mistral、Ollama 等供应商的调用收敛到 completion 一个函数上，本文说明它解决什么问题、底层如何复用官方 SDK、上手要敲哪些命令，以及在什么场景下它并不合适。
- 适合谁用？
- 如果团队同时接了两家以上供应商、又不想在每个项目里重复写 SDK 适配层，any-llm 值得先在一个脚本里试：pip install 'any-llm-sdk[openai,anthropic]'，把 model 写成 provider:model 跑通一次 completion，再决定是否迁到 AnyLLM.create。反过来，只锁定单一供应商、且重度依赖该家独有参数或新特性的项目，这一层抽象只会增加调试成本，不必引入。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
多供应商适配层到底省掉了哪部分代码
问题不在调用本身，而在调用之外。OpenAI、Anthropic、Mistral、Ollama 各有自己的客户端类、认证参数名、消息结构和返回对象，同一段业务逻辑要接第二家供应商时，改的往往不是模型名，而是构造参数、异常类型和取值路径。any-llm 的做法是把这些差异收进一层，对外只暴露 completion、responses 这类函数，以及一个 AnyLLM 类。README 给出的目标读者很明确：需要在多个供应商之间切换、又不希望把切换成本写进业务代码的 Python 开发者。它同时给了一条迁移路径，文档称从 LiteLLM 过来的用户，API key 与环境变量可以原样保留，只需改 import 和模型字符串写法。这一点对已经积累了一批环境变量配置的团队来说，意味着迁移的边界比想象中窄。
completion 调用背后的两层结构与连接复用
any-llm 提供两种使用方式，README 把它们分别对应到不同场景。第一种是直接调用模块级函数 completion，参数拆成 provider 与 model 两个字段，也支持合并写法 model="mistral:mistral-small-latest"，即 provider_id:model_id。第二种是 AnyLLM.create("mistral", api_key=...) 拿到实例，再调实例上的 completion。两者的功能集被描述为一致，差别在连接处理：文档中的对照表写明，直接函数每次调用新建客户端，属于无状态；AnyLLM 类复用客户端，也就是带连接池。这条区分是选型时最实际的一条，脚本和 notebook 用前者更省事，长驻服务用后者能避免反复建连。另一点值得留意的是实现策略：README 明确说它复用各家官方 SDK，而不是自己重写 HTTP 客户端。这带来兼容性上的好处，也意味着上游 SDK 的版本变动会传导进来，抽象层无法完全隔离。
安装 extras 与 provider 字符串的对应关系
安装按供应商拆成 extras，命令形如 pip install 'any-llm-sdk[openai]'、pip install 'any-llm-sdk[mistral,ollama]'，或一次装全的 pip install 'any-llm-sdk[all]'。运行期要求 Python 3.11 或更新版本。认证走环境变量，例如 OPENAI_API_KEY、ANTHROPIC_API_KEY、MISTRAL_API_KEY，README 也说明可以直接在代码里传 api_key。调用侧的最小例子是 completion(model="mistral-small-latest", provider="mistral", messages=[{"role": "user", "content": "Hello!"}])，返回对象按 OpenAI 风格取值，即 response.choices[0].message.content。对实现了 OpenAI 风格 Responses API 的供应商，另有 responses 与 aresponses，输入用 input_data，输出读 result.output_text。这里有一个容易踩的点：extras 名称、provider_id 与模型字符串三者必须对得上，而 provider_id 的合法取值以官方 Supported Providers 页面为准，不在列表里的自建服务需要走 Custom OpenAI-compatible Endpoints 那条路径，而不是随便编一个 provider 名。
抽象层抹平差异时也抹掉了供应商的个性
统一接口的代价是表达能力向最小公约数收敛。当某家供应商推出一个独有的采样参数或新的消息类型，any-llm 在把它纳入统一签名之前，你在这一层里是用不上的，只能绕开抽象直接调官方 SDK，于是项目里同时存在两套调用方式。这不是实现缺陷，而是这一类库的结构性取舍，LiteLLM 同样面对。另一个需要自行确认的点是能力覆盖的粒度：README 声称两种调用方式都支持 streaming、tools、responses API 等特性，但不同供应商对这些能力的支持程度并不一致，文档把细节放在各供应商页面里。选型时应当按你实际要用的那家去查，而不是按整体描述判断。还有一处文档没有展开：错误处理。README 只提到错误信息清晰可操作，并未说明各供应商的异常是否被归一成统一类型，如果业务代码需要按错误类型做重试或降级，这一点必须自己验证。
和 LiteLLM 相比，差别在客户端生命周期
最直接的替代品是 LiteLLM，README 自己就把迁移路径写了出来。两者都提供 completion 这一层统一入口，也都能沿用同一套环境变量，所以差异不在能不能调通，而在调用形态。LiteLLM 的典型用法是模块级函数 completion(model="openai/gpt-4o", messages=[...])，模型字符串用斜杠分隔；any-llm 改成冒号分隔的 model="openai:gpt-4o"，并额外提供了一个 AnyLLM 类来显式持有客户端。如果你的服务是长驻进程、每秒有稳定请求量，能显式复用客户端是一个可感知的差别；如果只是脚本里发几次请求，两者在使用体验上几乎没有区别，迁移收益主要来自代码风格统一，而不是性能。另一个差异是依赖来源：any-llm 明确基于各家官方 SDK，LiteLLM 的适配策略需要你自行核对其文档，这里不做判断。
Apache-2.0 与版本节奏带来的维护成本
许可证是 Apache-2.0，属于宽松型许可，允许修改和再分发，通常需要保留版权与许可声明；具体条款的适用请以仓库中的 LICENSE 文件为准，这里不构成法律意见。版本节奏上，从近期发布记录看，1.27.1 与 1.27.0 相隔一天，1.26.0 到 1.27.0 约两周半，属于较快的迭代频率。快节奏对使用者是双向的：修 bug 和加供应商的响应快，但升级时 extras 名称、provider_id 或模型字符串写法存在调整的可能，锁版本并保留一个跨供应商的冒烟测试脚本是合理的做法。维护成本还有一部分来自上游：既然复用官方 SDK，各家 SDK 的大版本升级最终会体现为 any-llm 的依赖约束变化，依赖解析冲突可能出现在你的项目里，而不是这个库本身。
什么时候这层抽象是负担
只对接一家供应商、并且深度使用其独有能力的项目，引入 any-llm 只会多一层需要跟着升级的依赖，直接调用官方 SDK 更短。需要精确控制 HTTP 行为、超时、重试策略或自定义传输层的场景也一样，抽象层通常不暴露这些旋钮。还有一种情况容易被忽略：如果你的代码需要在不同供应商之间做细粒度的能力探测，比如先问某家是否支持某个参数再决定怎么发请求，统一签名反而让这类判断无处安放。判断标准可以很具体，看你项目里 provider 这个字段是否真的会出现两个以上的取值，如果答案是否定的，这层抽象目前没有回报。
编辑结论
如果团队同时接了两家以上供应商、又不想在每个项目里重复写 SDK 适配层，any-llm 值得先在一个脚本里试：pip install 'any-llm-sdk[openai,anthropic]'，把 model 写成 provider:model 跑通一次 completion，再决定是否迁到 AnyLLM.create。反过来，只锁定单一供应商、且重度依赖该家独有参数或新特性的项目，这一层抽象只会增加调试成本，不必引入。动手前先核对三件事：目标供应商是否在官方 Supported Providers 列表内，你依赖的能力（流式、tools、responses）在该供应商下是否被标注支持，以及版本升级时 extras 名称与 provider_id 是否发生变更。
社区笔记