Spring AI 多模型接入：模型路由与运行时切换

真实 AI 项目通常不会只使用一个模型。

可能同时接入：

DeepSeek
智谱
通义
OpenAI
Claude
硅基流动

如果每接一个模型就在业务代码里加 if-else，很快就会失控。

因此更合理的设计是：

让 Agent 不关心具体模型，把模型选择和厂商适配下沉到基础设施层。

1. Provider：统一模型供应商

先定义统一接口：

public interface ModelProvider {

    String apiStyle();

    Model model(ModelConfig.ModelInfo info);
}

不同厂商分别实现：

OpenAIProvider
AliProvider
AnthropicProvider
...

最终统一返回 Spring AI 的：

Model

于是上层只依赖统一接口。

整体变成：

具体厂商
   ↓
ModelProvider
   ↓
Spring AI Model

这本质上是 Adapter + Factory。

---

2. 插件化自动发现

每个 Provider 注册成 Spring Bean。

Provider 模块
    ↓
@AutoConfiguration
    ↓
Spring Boot 自动发现
    ↓
注册 ModelProvider

这样增加新厂商时，只需要新增实现模块，不需要修改核心业务代码。

这就是：

插件式模型接入。

---

3. ModelResolver：模型路由

系统可以使用统一模型标识：

zhipu#glm-4
deepseek#deepseek-chat
openai#gpt-x

其中：

deepseek#deepseek-chat
    │           │
 Provider    ModelName

启动时把所有 Provider 建成索引：

Map<String, ModelProvider> providerMap;

请求进来后：

用户
 ↓
模型偏好
 ↓
ModelResolver
 ↓
找到 Provider
 ↓
创建 / 获取 Model

这样就可以做到：

用户 A → 智谱
用户 B → DeepSeek
默认用户 → 全局默认模型

这就是 Model Routing。

---

4. Agent 不直接操作模型

Agent 最好不要写：

DeepSeekChatModel model = ...

而是调用统一的：

llmCaller.call(...);

然后内部完成：

Agent
 ↓
LlmCaller
 ↓
ModelResolver
 ↓
ModelProvider
 ↓
具体 LLM

这样职责非常清楚：

Agent
负责业务逻辑

LlmCaller
负责调用流程

ModelResolver
负责选模型

ModelProvider
负责适配厂商

模型换了，Agent 不需要改。

---

5. 调用器也可以分层

不同场景需要的能力不同。

可以设计：

SimpleLlmCaller
模型 + Prompt

适合分类、摘要等一次性任务。

再往上：

MemoryLlmCaller
模型 + ChatMemory + Tools

适合普通 Agent。

再往上：

IdentityLlmCaller
模型 + Memory + Tools + 用户画像

适合个性化 Agent。

核心思想是：

不同调用器的区别，不是模型不同，而是给模型附加的上下文能力不同。

---

6. 优先复用 OpenAI 兼容协议

很多模型厂商都提供 OpenAI Compatible API。

例如只需要修改：

base-url:
api-key:
model:

底层仍然可以复用同一套 OpenAI Provider。

于是：

OpenAI Provider
      │
      ├── DeepSeek
      ├── 智谱
      └── 硅基流动

不需要每个厂商都重新写 Java 代码。

这里有一个很重要的架构思想：

优先按照协议抽象，而不是按照厂商抽象。

10 个厂商，可能只有两三种协议。

真正协议完全不同的模型，例如 Anthropic，再单独实现 Provider。

---

7. Model Cache

创建模型实例通常还包含：

HTTP Client
API Key
Base URL
Timeout
Retry
ToolCallingManager

所以没必要每次请求都重新创建。

可以：

provider + modelName
        ↓
     Cache

第一次创建：

ModelResolver
↓
build Model
↓
Cache

后续直接复用。

---

8. 运行时切换模型

生产环境不能每改一次模型配置就重启服务。

因此可以设计：

后台修改配置
     ↓
保存
     ↓
发布配置变更事件
     ↓
清理 Model Cache
     ↓
下一次请求重新构建 Model

这样就实现了：

Runtime Model Switching

模型切换从“代码部署行为”变成了“配置行为”。

运营人员就可以动态调整：

默认模型
用户模型
API Key
Base URL
模型名称

而不需要重新发布系统。

---

9. 最终架构

可以把整套系统记成：

                User
                  ↓
                Agent
                  ↓
              LlmCaller
                  ↓
             ModelResolver
                  ↓
          provider#modelName
                  ↓
             ModelProvider
            /      |       \
       OpenAI     Ali    Anthropic
          ↓
       Model Cache
          ↓
          LLM

---

10. 最值得沉淀的几个关键词

ModelProvider
ModelResolver
Model Routing
Adapter
Plugin Architecture
OpenAI Compatible
Model Cache
Runtime Switching

最核心的一句话是：

Agent 只依赖模型能力，不依赖具体模型；模型选择、协议适配和动态切换全部交给基础设施层。

这样今天用 DeepSeek，明天换智谱，后天接 Claude，业务 Agent 基本都不用改。