大家好，我是你们的技术效能架构师。
在过去的篇章中，我们构建了 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 所需的请求体。输出适配：解析厂商返回的
