夜雨聆风一、引言
在第一篇中，我们介绍了 Spring AI Alibaba 的五层架构，以及各个核心模块的整体定位。从本篇开始，我们将深入源码，逐模块解析核心实现。
本篇聚焦两个最核心的机制：Model API（统一模型抽象层）和Function Call（函数调用）。这两个机制，是 Spring AI Alibaba 所有上层能力的基础。
二、Model API：如何用一套接口管理多模型
2.1 设计目标
在 AI 应用开发中，模型的选择直接决定了应用能力的天花板。但不同模型的 API 差异巨大——OpenAI 用的是 REST，Anthropic 用的是自己的协议，阿里云的 DashScope 又是另一套接口。如果每个模型都单独对接，应用代码将难以维护。
Spring AI Alibaba 的 Model API，就是来解决这个问题的：用一套统一的 Java 接口，抽象所有模型的调用方式。
▲ Model API 统一抽象层：上层业务代码面向 ChatModel 接口编程，实际模型可在配置层切换，无需改动业务代码
2.2 核心接口设计
Model API 的核心是 ChatModel 接口，它定义了所有聊天模型必须实现的能力：
ChatModel 接口核心方法：ChatResponse call(ChatRequest request) — 发送对话请求，返回结构化响应
面向接口编程，上层业务不需要知道底层是通义千问还是 Claude。切换模型，只需要改一行配置：
切换模型的配置方式：spring.ai.dashscope.chat.model=Qwen-Max 只需修改配置文件中模型名称，上层代码零改动。
2.3 已支持的模型
🤖 Model API 已接入模型
- 通义千问（DashScope）
— 阿里云官方，深度集成 - 豆包（Doubao）
— 字节跳动大模型 - OpenAI GPT 系列
— via OpenAI API - Anthropic Claude 系列
— via Anthropic API - 本地模型（Ollama）
— 支持本地部署
2.4 模型路由与动态切换
Model API 还支持在运行时动态切换模型。比如根据任务复杂度自动路由：简单任务用小模型省成本，复杂任务自动切到 GPT-4 或 Claude。这背后是一套模型路由器（Model Router）机制，根据模型能力标签和任务描述匹配最适合的模型。
三、Function Call：让 AI 调用 Java 方法
3.1 什么是 Function Call？
Function Call（函数调用），是 AI Agent 实现"工具使用"能力的关键技术。当用户提出需要实时信息的请求时（如"今天北京的天气如何？"），AI 本身无法知道答案，需要调用外部工具获取——这就是 Function Call。
在 Spring AI Alibaba 中，Function Call 的实现分为三步：注册 → 推理 → 调用。
▲ Function Call 完整链路：Java 方法注册 → AI 推理决定调用 → 参数序列化 → 执行 → 结果返回 AI
3.2 注册：@Tool 注解的魔力
Spring AI Alibaba 使用 @Tool 注解来注册函数。开发者只需在一个方法上加注解：
@Tool 注解使用示例：
@Tool(name = "get_weather", description = "获取指定城市的天气信息") public String getWeather( @ToolParam("城市名称") String city ) { // 调用天气 API 并返回结果 return "北京今天晴，温度26℃"; }加上注解后，框架会自动：
提取方法签名，生成 function description 构建 FunctionCallback 元数据，注入 ChatModel 让 AI 在推理时看到可用函数列表
3.3 推理：AI 决定调用哪个函数
当用户请求到达时，AI 会在回复之前，先判断是否需要调用函数。如果需要，它会输出一个结构化的"函数调用请求"，包含：
- 函数名
（如 get_weather） - 参数
（如 {"city": "北京"}）
Spring AI Alibaba 的 FunctionCall 拦截器会捕获这个调用请求，路由到对应的 Java 方法，执行后，将结果返回给 AI，让 AI 继续生成最终回复。
3.4 调用：FunctionCallbackRegistry
所有注册的函数，都被统一管理在 FunctionCallbackRegistry 中。框架负责维护：
📋 FunctionCallbackRegistry 职责
函数元数据存储（名称、描述、参数 schema） 运行时函数调度（根据 AI 请求调用对应方法） 参数校验与反序列化（JSON → Java 对象） 执行结果序列化（Java 对象 → JSON）
四、ChatMemory：对对话历史的精细管理
▲ ChatMemory 架构：消息存储 → 历史检索 → 摘要压缩 → 上下文注入，完整的消息生命周期管理
4.1 多后端存储支持
Spring AI Alibaba 的 ChatMemory 支持多种存储后端，开发者可根据场景选择：
- InMemoryChatMemory
— 内存存储，简单场景，即开即用 - RedisChatMemory
— Redis 存储，支持分布式部署和会话持久化 - JdbcChatMemory
— 关系数据库存储，企业级持久化
4.2 消息摘要压缩
随着对话增长，历史消息会占用大量上下文 token。ChatMemory 内置了消息摘要压缩机制：当对话轮次超过阈值，自动触发摘要生成，将多轮对话压缩为单条精炼摘要，大幅减少 token 消耗。
五、RAG Pipeline：企业知识库的完整方案
▲ RAG Pipeline 全流程：文档加载 → 分块处理 → 向量化存储 → 语义检索 → Prompt 构建 → LLM 生成
5.1 完整 RAG 流程
Spring AI Alibaba 内置了完整的 RAG Pipeline，覆盖从文档到答案的全流程：
🔍 RAG Pipeline 六大步骤
- ① 文档加载
— 支持 PDF、Word、Markdown、TXT、HTML 等格式 - ② 分块处理
— 智能切分文档为合适大小的 chunks - ③ 向量化
— 调用 Embedding 模型，将文本转为向量 - ④ 存储
— 向量数据库存储（支持多种向量库） - ⑤ 语义检索
— 根据用户问题检索相关 chunks - ⑥ 生成
— 将检索结果注入 Prompt，LLM 生成最终答案
5.2 文档分块策略
分块（Chunking）是 RAG 效果的关键。Spring AI Alibaba 支持多种分块策略：
- 固定长度分块
— 按 token 数或字符数均分文档 - 句子级分块
— 按句子边界切分，保留语义完整性 - 递归字符分块
— 按层级分隔符递归切分 - 语义分块
— 基于 Embedding 相似度自动判断断点
六、设计哲学与工程价值
① 统一抽象，分层解耦Model API 让上层业务与底层模型解耦，新增模型只需实现接口，无需改动业务代码。
② 注解驱动，最小侵入@Tool、@ToolParam 等注解，让 Java 开发者用熟悉的 Spring 风格接入 AI 能力，无需学习新范式。
③ 工程化优先ChatMemory 的摘要压缩、RAG 的完整 Pipeline——每个机制都面向生产环境设计，不是玩具级别的演示。
七、第二篇小结
本篇深入解析了 Spring AI Alibaba 的两大核心机制：
- Model API
— 通过统一接口，让 Java 应用可以自由切换模型，配置驱动，零代码改动 - Function Call
— 通过注解注册，让 AI 自动发现并调用 Java 方法，是 Agent 能力的基础
这两大机制，共同构成了 Spring AI Alibaba 上层能力（Agent、RAG、多模型协作）的技术基石。
预告：下一篇我们将解析 Spring AI Alibaba 的 Agent 框架——单 Agent 的实现、多 Agent 协作机制，以及 MCP Gateway 的源码细节。
