第四篇：Spring AI LLM Client 深度剖析——企业级 AI 访问层的设计哲学

大家好，我是你们的技术效能架构师。

在过去的篇章中，我们构建了 Spring AI 的架构骨架（第二篇），并掌握了 Prompt Engineering 这一灵魂核心（第三篇）。现在，我们来到了整个 AI 应用的执行层，这是决定系统稳定、可控和灵活性的关键。

在企业级 AI 架构中，最大的痛点在于 LLM 服务的多变性、不确定性和厂商锁定风险。本篇，我将带领大家深入剖析 Spring AI LLM Client 体系背后的设计哲学和架构模式，揭示它是如何优雅地解决这些深层问题的，从而打造一个稳定可控的 LLM 访问层。

一、设计哲学核心：协议适配层与依赖倒置原则（DIP）

Spring AI 成功实现多厂商、多模型切换的秘密，并非在于其代码有多复杂，而在于其对经典软件工程原则的极致应用，核心目标是：将 LLM 的多样性复杂性，隔离在框架的边界之外。

1. 依赖倒置原则（DIP）：解耦的基石

• 原则体现：高层模块（业务逻辑）不应该依赖低层模块（具体的 LLM 实现），它们都应该依赖于抽象（接口）。

• 在 Spring AI 中的映射：

  • 抽象（接口）：ChatModel、EmbeddingModel。

  • 高层模块（业务代码）：你的 Service 层永远只依赖ChatModel。

  • 低层模块（供应商实现）：OpenAiChatModel、QwenChatModel等具体类。

资深洞察：这是实现避免厂商锁定的最强有力架构保障。当你决定从 OpenAI 切换到本地的 Ollama 服务时，你的业务代码（高层模块）不需要修改一行。你替换的仅仅是 Spring IoC 容器中注入的那个具体实现类。

2. 协议适配层（Adapter Pattern）：统一复杂的外部世界

国际和国内厂商的 LLM API 协议千差万别：参数命名、认证方式、Token 计算、错误码等都有巨大差异。

• 适配器模式的落地：每个spring-ai-{provider}-spring-boot-starter依赖包，本质上就是一个协议适配器（Protocol Adapter）。

  • 输入适配：将 Spring AI 定义的标准输入对象 (Prompt、ChatOptions) 转换为特定厂商 API 所需的请求体。

  • 输出适配：解析厂商返回的