【JchatMind智能体 | 第四天】Spring AI 集成与多模型支持

【JchatMind智能体 | 第四天】Spring AI 集成与多模型支持 前言本项目非原创我也是作为一名初学者跟着一起学习。项目来源于代码随想录-知识星球。代码随想录-知识星球https://wx.zsxq.com/group/88511825151142在知识星球里看到卡哥分享这个项目 感觉还不错于是想要学习一下这个项目怎么写。项目日记也会同步更新。本人不分享本项目源码支持项目付费本文由我学习该项目并结合AI整理总结而来分享出来学习过程中的心得体会由浅入深用于日后的回顾同时也希望能给你带来帮助。目录前言Spring AI 在 Agent 系统中的作用接入 Spring AI 的步骤一个模型对应一个 ChatClientChatClientRegistry模型调度的核心Agent 如何绑定模型模型成为系统基础设施【JchatMind智能体 | 第三天】数据模型设计https://blog.csdn.net/h52412224/article/details/159043756【JchatMind智能体 | 第二天】为何选 PostgreSQL pgvector 而非 MySQLhttps://blog.csdn.net/h52412224/article/details/159018355【JchatMind智能体 | 第一天】从最原始的大模型调用开始https://blog.csdn.net/h52412224/article/details/158881257前面几章我们用手写大模型 API 的方式把模型调用、上下文管理和工具调用的完整流程走了一遍。现在我们正式进入工程化开发阶段新的问题也随之而来当系统里有多个 Agent、多次模型调用甚至接入了多个不同厂商的模型时我们怎么把这些模型能力统一管理起来让它们变成可配置、可切换、可扩展的基础设施这一章就来解决这个问题。Spring AI 在 Agent 系统中的作用如果不借助任何框架每接入一个新模型我们都要自己处理一堆重复工作构造 HTTP 请求处理鉴权和请求重试适配不同模型的参数差异兼容各厂商的工具调用协议这些工作本身不难但它们和 Agent 的核心逻辑无关纯粹是和模型厂商打交道的细节。Spring AI 的好处就是把如何和模型打交道这件事抽象成了一套统一接口。这样我们就能把精力放在设计 Agent 的行为上不用再纠结各个模型厂商的细节差异。在 Agent 系统里我们只需要一个能和模型对话的对象这个对象就是 Spring AI 里的 ChatClient。接入 Spring AI 的步骤在 Spring Boot 项目里接入 Spring AI 非常简单主要分三步。首先用 BOM 来统一管理版本避免依赖冲突dependencyManagement dependencies dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-bom/artifactId version1.1.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement然后根据要接入的模型厂商引入对应的 starter 依赖。比如接入深度求索和智谱 AIdependencies dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-deepseek/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-zhipuai/artifactId /dependency /dependencies最后在 application.yaml 里配置模型的 API Key 和默认参数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 BeanConfiguration 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。我们只需要一个简单的注册表类就能实现模型的动态调度Component public class ChatClientRegistry { private final MapString, ChatClient registry; public ChatClientRegistry(MapString, ChatClient registry) { this.registry registry; } public ChatClient get(String modelName) { return registry.get(modelName); } }这段代码看似简单却解决了一个关键的工程问题新增模型时不需要修改任何调度代码模型注册是声明式的不用写复杂的控制流模型选择完全由配置数据驱动这种注册表模式是实现多模型支持的核心。Agent 如何绑定模型在之前设计的数据库表中Agent 表有一个 model 字段用来指定这个 Agent 默认使用的模型。当系统创建 Agent 实例时只需要一行代码就能拿到对应的模型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?fromfrom_copylink如果我的内容对你有帮助请点赞评论收藏。创作不易你们的支持就是我坚持下去的动力