目录
[Spring AI 在 Agent 系统中的作用](#Spring AI 在 Agent 系统中的作用)
[接入 Spring AI 的步骤](#接入 Spring AI 的步骤)
[一个模型对应一个 ChatClient](#一个模型对应一个 ChatClient)
[Agent 如何绑定模型](#Agent 如何绑定模型)
【AI Agent基础 | 第二篇】从被动问答到主动推进任务的智能体
https://blog.csdn.net/h52412224/article/details/158689521?spm=1001.2014.3001.5502【AI Agent基础 | 第一篇】AI模型的能力边界与分类https://blog.csdn.net/h52412224/article/details/158500592?spm=1001.2014.3001.5502
前面几章，我们用手写大模型 API 的方式，把模型调用、上下文管理和工具调用的完整流程走了一遍。
现在我们正式进入工程化开发阶段，新的问题也随之而来：
当系统里有多个 Agent、多次模型调用，甚至接入了多个不同厂商的模型时，我们怎么把这些模型能力统一管理起来，让它们变成可配置、可切换、可扩展的基础设施？
这一章，就来解决这个问题。
Spring AI 在 Agent 系统中的作用
如果不借助任何框架，每接入一个新模型，我们都要自己处理一堆重复工作：
-
构造 HTTP 请求
-
处理鉴权和请求重试
-
适配不同模型的参数差异
-
兼容各厂商的工具调用协议
这些工作本身不难，但它们和 Agent 的核心逻辑无关，纯粹是和模型厂商打交道的细节。
Spring AI 的好处，就是把如何和模型打交道这件事，抽象成了一套统一接口。
这样我们就能把精力放在设计 Agent 的行为上，不用再纠结各个模型厂商的细节差异。
在 Agent 系统里，我们只需要一个能和模型对话的对象，这个对象就是 Spring AI 里的 ChatClient。
接入 Spring AI 的步骤
在 Spring Boot 项目里接入 Spring AI 非常简单，主要分三步。
首先，用 BOM 来统一管理版本，避免依赖冲突：
java
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-bom</artifactId>
<version>1.1.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>然后，根据要接入的模型厂商，引入对应的 starter 依赖。
比如接入深度求索和智谱 AI：
java
<dependencies>
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-starter-model-deepseek</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-starter-model-zhipuai</artifactId>
</dependency>
</dependencies>最后，在 application.yaml 里配置模型的 API Key 和默认参数：
java
spring:
ai:
deepseek:
api-key: ${DEEPSEEK_API_KEY}
chat:
options:
model: deepseek-chat
zhipuai:
api-key: ${ZHIPU_API_KEY}
chat:
options:
model: glm-4.6完成这三步后，Spring AI 就会自动把这些模型装配成 ChatModel Bean，接下来我们就可以在系统里直接使用了。
一个模型对应一个 ChatClient
在我们的 Agent 系统里，有一个约定：每一个可用的模型，都对应一个独立的 ChatClient 对象。
ChatClient 是对模型能力的封装，它把模型调用的细节都屏蔽了，只暴露一个统一的对话接口。
我们可以为每个模型创建一个独立的 ChatClient Bean：
java
@Configuration
public class MultiChatClientConfig {
@Bean("deepseek-chat")
public ChatClient deepSeekChatClient(DeepSeekChatModel model) {
return ChatClient.create(model);
}
@Bean("glm-4.6")
public ChatClient zhiPuChatClient(ZhiPuAiChatModel model) {
return ChatClient.create(model);
}
}ChatClientRegistry：模型调度的核心
当系统里有多个 ChatClient 后，新的问题就来了：运行时怎么根据 Agent 的配置，自动选择对应的模型？
答案很简单，不要用 if/switch 硬编码，交给 Spring 来处理。
Spring 会自动把所有 ChatClient 类型的 Bean 收集到一个 Map 里，Bean 的名称就是 Map 的 Key，实例本身就是 Value。
我们只需要一个简单的注册表类，就能实现模型的动态调度：
java
@Component
public class ChatClientRegistry {
private final Map<String, ChatClient> registry;
public ChatClientRegistry(Map<String, ChatClient> registry) {
this.registry = registry;
}
public ChatClient get(String modelName) {
return registry.get(modelName);
}
}这段代码看似简单，却解决了一个关键的工程问题：
-
新增模型时，不需要修改任何调度代码
-
模型注册是声明式的，不用写复杂的控制流
-
模型选择完全由配置数据驱动
这种注册表模式，是实现多模型支持的核心。
Agent 如何绑定模型
在之前设计的数据库表中，Agent 表有一个 model 字段，用来指定这个 Agent 默认使用的模型。
当系统创建 Agent 实例时，只需要一行代码就能拿到对应的模型：
java
ChatClient chatClient = chatClientRegistry.get(agent.getModel());
if (chatClient == null) {
throw new IllegalStateException(
"未找到对应的模型：" + agent.getModel()
);
}这样我们就实现了模型的动态切换：
-
Agent 只依赖 ChatClient 这个统一接口
-
Agent 完全不用关心模型来自哪个厂商
-
切换模型时，不需要修改 Agent 的代码
模型已经从写死的依赖，变成了可以在运行时动态注入的能力。
模型成为系统基础设施
到这一步，我们完成了一个重要的转变：
-
所有模型都被统一抽象成 ChatClient
-
多个模型可以在系统中并存
-
Agent 可以在运行时自由选择模型
-
模型接入和 Agent 行为彻底解耦
现在，模型不再是某个 API Key 对应的外部服务，而是系统里的一种基础能力组件。
上述内容也同步在我的飞书，欢迎访问
https://my.feishu.cn/wiki/QLauws6lWif1pnkhB8IcAvkhncc?from=from_copylink
如果我的内容对你有帮助，请点赞，评论，收藏。创作不易，你们的支持就是我坚持下去的动力！