多 LLM Provider 统一接入
Multi-Provider LLM Gateway
通过统一接口层接入多个 LLM 提供商，实现模型名到 Provider 的自动路由、API 密钥管理、请求格式适配，降低模型切换成本。
子问题
1.模型名→Provider 自动路由
2.API 密钥和 base_url 管理
3.请求/响应格式适配
4.自定义 OpenAI 兼容端点支持
5.OAuth 认证流程（如 Codex）
6.Gateway 聚合网关的模型前缀剥离与重前缀
7.Provider 特定参数覆盖（如 Kimi K2.5 temperature 下限）
8.Prompt Caching 的 Provider 感知注入
9.消息格式清洗（空内容、非标准 key 剥离）
各项目的解法1 solutions
Signals
横向对比
| 维度 | Nanobot |
|---|---|
| 适配层 | LiteLLM 统一适配 + CustomProvider/CodexProvider 旁路 |
| 路由机制 | ProviderSpec 声明式注册表，find_by_model 关键词匹配 + 显式前缀优先 |
| Gateway 支持 | 三级检测（config key → api_key 前缀 → api_base 关键词），strip_model_prefix 重前缀 |
| 认证方式 | API Key 环境变量自动映射 + OAuth 独立流程（Codex/Copilot） |
| Provider 数量 | 16 个内置 Provider（含 4 个 Gateway + 1 个本地 + 2 个 OAuth） |
| 扩展方式 | 添加 ProviderSpec 记录 + ProvidersConfig 字段，零逻辑代码修改 |
最佳实践
1.使用 LiteLLM 作为统一适配层，通过 registry 注册表实现 model→provider 映射
2.支持 gateway 模式统一转发，避免 if-elif 链式判断
3.frozen dataclass 注册表替代 if-elif 链，新增 Provider 只改数据不改逻辑
4.三级 Gateway 检测（config key → api_key 前缀 → api_base 关键词）避免误判
5.env_extras 模板化环境变量映射，解决 LiteLLM 对特定环境变量名的依赖
6.is_direct/is_oauth 标记实现旁路分发，特殊 Provider 不强制走统一适配层