深度剖析Spring AI源碼（二）：Model抽象層 - “馴服”天下AI的“緊箍咒”

上一章我們鳥瞰了Spring AI的宏偉藍圖，今天，我們要深入這座大廈的基石——Model抽象層。如果說Spring AI是連接Java與AI世界的橋梁，那么Model接口就是這座橋最核心的承重結構。它定義了一套“普通話”，讓我們的Java代碼可以和來自五湖四海（OpenAI, Azure, Bedrock…）的AI模型們無障礙溝通。準備好了嗎？讓我們一起看看這套“普通-AI-話”是如何設計的。

設計目標：以不變應萬變

AI領域日新月異，新的模型層出不窮，API的變更也如家常便飯。如果我們的應用代碼與某個具體的模型（比如OpenAI的GPT-4）深度綁定，那么當你想切換到Anthropic的Claude，或者想“白嫖”一下本地部署的Ollama時，將面臨一場傷筋動骨的重構災難。

Spring AI的設計哲學，正是我們早已爛熟于心的面向接口編程。它在變幻莫測的AI模型和我們穩健的業務代碼之間，建立了一道堅固的抽象層。這道“防火墻”將AI模型善變的“脾氣”隔離開來，讓你的業務邏輯能夠穩如泰山，靜觀其變。

核心接口剖析：AI世界的“四梁八柱”

在spring-ai-model模塊中，定義了幾個關鍵的核心接口，它們共同構成了與AI模型進行標準化對話的“四梁八柱”。

1. Model<Q, R>: 抽象的“祖師爺”

這是所有模型接口的“根”，是整個抽象體系的“萬惡之源”（開個玩笑）。它用最純粹的形式定義了AI模型的核心交互模式。

// spring-ai-model/src/main/java/org/springframework/ai/model/Model.java
public interface Model<TReq extends ModelRequest<?>, TRes extends ModelResponse<?>> {TRes call(TReq request);
}

它運用Java最經典的泛型，優雅地解決了“輸入什么，輸出什么”這個宇宙終極問題之一。大道至簡，一個call方法便定義了請求-響應的完整交互。

• TReq: 代表請求類型，它必須是ModelRequest的子類。
• TRes: 代表響應類型，它必須是ModelResponse的子類。

2. ChatModel & StreamingChatModel: 對話的“雙子星”

ChatModel是你與AI進行聊天式對話的主力接口，它專為對話場景而設計。

// spring-ai-model/src/main/java/org/springframework/ai/model/chat/ChatModel.java
public interface ChatModel extends Model<Prompt, ChatResponse> {// ... 默認方法
}

它直接繼承自Model接口，并具體化了泛型：明確了在“聊天”這個場景下，輸入是Prompt（提示），輸出是ChatResponse（聊天回復）。

而它的“兄弟”StreamingChatModel則提供了更酷、用戶體驗更佳的玩法：

// spring-ai-model/src/main/java/org/springframework/ai/model/chat/StreamingChatModel.java
public interface StreamingChatModel extends StreamingModel<Prompt, ChatResponse> {// ... 默認方法
}// spring-ai-model/src/main/java/org/springframework/ai/model/StreamingModel.java
public interface StreamingModel<TReq extends ModelRequest<?>, TResChunk extends ModelResponse<?>> {Flux<TResChunk> stream(TReq request);
}

如果說ChatModel是你問一句，AI完整地回答一句，如同傳統的HTTP請求-響應模式；那么StreamingChatModel則像是實時視頻流，AI的回答會一個字一個字地“流”向你，極大地提升了交互的實時感。這背后，正是響應式編程的魔力在驅動。

3. EmbeddingModel: AI的“翻譯官”和“度量衡”

如果說ChatModel是AI用來與世界溝通的“嘴巴”，那么EmbeddingModel就是AI用來理解和度量世界的“尺子”。

// spring-ai-model/src/main/java/org/springframework/ai/model/embedding/EmbeddingModel.java
public interface EmbeddingModel extends Model<EmbeddingRequest, EmbeddingResponse> {// ... 默認方法
}

它的核心職責，是將人類的語言（文本）“翻譯”成機器能夠理解和比較的數字“指紋”——也就是高維向量（Vector）。這是實現RAG（檢索增強生成）和“以文搜文”等高級功能的關鍵所在，是構建AI“長期記憶”和“深度理解力”的基石。

請求與響應：溝通的“快遞包裹”

光有接口（溝通渠道）還不夠，數據交換還需要統一的“信封”和“信紙”。Spring AI通過一系列精心設計的DTO（Data Transfer Object）來規范這場跨物種對話的格式。

請求對象（發出的“快遞”）

• Prompt: 這絕不是一個簡單的字符串，而是一個結構化的“劇本”。它封裝了一個Message列表，共同構成了一次完整的對話上下文。
• Message: 這是一個消息接口，擁有多個實現，讓你能夠導演一出好戲：
  • SystemMessage: “系統指令”，用于給AI設定角色和行為準則，比如“你是一個只說騷話、樂于助人的資深程序員”。
  • UserMessage: 用戶的提問，也就是我們凡人輸入的指令或問題。
  • AssistantMessage: AI助手的歷史回復，用于構建多輪對話的上下文，讓AI知道“前情提要”。
• EmbeddingRequest: 這是發給“翻譯官”（EmbeddingModel）的請求，里面包含了一批需要被轉換成向量的文本。

響應對象（收到的“快遞”）

• ChatResponse: ChatModel的回復包裹，里面裝著一個Generation列表（因為一次提問，模型可能會生成多個候選答案）。
• Generation: 代表AI的一次“創作成果”。除了最核心的內容（content），它還附帶了一堆非常有用的“元數據”（metadata），比如模型為什么停止回答（finishReason）、這次調用消耗了多少Token（usage）等。這些信息對于成本控制和問題調試至關重要。
• EmbeddingResponse: “翻譯官”的工作成果，包含了一批新鮮出爐的、可用于計算相似度的向量。

ChatClient: 開發者的“神兵利器”

如果說ChatModel等底層接口是需要開發者自行組裝的“引擎零件”，那么ChatClient就是Spring AI官方為你精心打造好的一臺“超級跑車”，它提供了極其便利的流式API，讓你用最少的代碼完成最常見的任務。

// spring-ai-client-chat/src/main/java/org/springframework/ai/chat/client/ChatClient.java
public interface ChatClient {static ChatClient.Builder builder(ChatModel chatModel) {return new DefaultChatClient.Builder(chatModel);}// ... call() 和 stream() 方法
}

還記得上一章我們提到的建造者模式嗎？在這里它被發揮得淋漓盡致，創造出了絲滑的編碼體驗：

String response = ChatClient.create(chatModel).prompt().user("給我講個關于Java的冷笑話").call().content();

這種優雅的API設計，讓開發者可以完全專注于業務邏輯的實現，而無需與底層的API細節進行“肉搏”，極大地提升了開發效率和代碼可讀性。

小結

通過本章的探索，我們發現Spring AI通過一套設計精妙的Model接口、Prompt/`