Spring AI-2.0-01章-港品优选

1、Spring AI2.0 - 入门

1.1、为什么需要Spring AI

1.1.1、从传统的应用到智能体时代

1.2、大语言模型(LLM)的局限性

单一的大语言模型主要存在三大短板：

1.2.1、知识受限于训练数据

大模型的知识全部来自训练阶段的数据集，模型训练完成后，就无法自动获取训练时间点之后产生的新知识、实时信息，新知识无法穿透训练数据这道 “围墙”。

1.2.2、无法直接与外部系统交互

原生大语言模型如同被隔离保护起来，不能直接访问数据库、调用 API、访问互联网或者对接其他外部应用，无法主动查询实时数据。

1.2.3、不具备状态保持能力

模型很难长久保存对话上下文记忆，在多轮对话里，容易遗忘前面沟通的内容。举例：用户自我介绍名字后，继续聊别的话题，再回头询问模型是否记得自己名字时，模型无法记住该信息，难以维持连贯的长对话。

综上所述:

要构建真正实用的AI应用，必须将大语言模型与外部工具、数据源和记忆机制有机结合，从而催生了Spring AI、LangChain框架的设计理念。Spring AI是当前构建生产级Java AI智能体系统的首选。

1.3、Spring AI发展历史

1.3.1、Spring AI 各版本详细文字说明

1、0.x 预览系列（0.8.0、0.8.1、0.9.x，2024 全年，非生产）

基线：SpringBoot3，JDK17；定位：实验预览，API 频繁变动，不建议商用

1.1、0.8.0（2024-02，第一个对外发布预览版）

核心特性

奠定 SpringAI 最基础抽象：ChatModel、EmbeddingModel、VectorStore统一接口
支持基础 Function Calling（函数调用），支持 OpenAI/AzureOpenAI
内置文档 ETL 框架，文档加载、文本分片，实现基础 RAG 能力
8 种向量存储实现，向量库统一 SQL 风格元数据过滤语法
SpringBoot Starter 自动装配，yml 配置驱动局限

没有ChatClient流畅 API，代码写法繁琐
Advisor 体系尚未成型；工具调用逻辑内置在模型内部
API 不稳定，后续版本大量破坏性改动，仅适合学习，严禁生产

1.2、0.8.1（2024-03，小迭代）

新增 Mistral 大模型接入
OpenAI 增加音频转写能力，增加请求重试
Azure OpenAI 完善 Function Calling，修复自动装配配置属性命名

1.3、0.9.x（2024 下半年持续迭代）

扩充更多向量数据库支持（Redis、Chroma、PgVector）
完善 DocumentLoader，新增 Word、Markdown 解析器
优化流式 SSE 输出；初步探索 Advisor 拦截器设计

缺点：0.9 版本 API 依然会变，网上很多老博客教程基于 0.8/0.9，代码无法直接迁移到 1.0 GA

2、1.x 正式生产系列（SpringBoot3，JDK17，企业主流生产版本）

2.1、1.0.0 GA（2025-05，重大里程碑，第一个正式生产可用版本）

核心亮点与优化

ChatClient 正式推出：Fluent 流式 API，简化对话调用，成为推荐主入口
Advisor 拦截器体系成型，SpringAI 标志性架构落地：RAG、记忆、安全校验都用 Advisor
原生支持多模态图文问答；支持结构化输出，直接映射 Java POJO
Micrometer 指标、Actuator 端点完善，token 消耗、耗时、异常指标开箱即用
模型生态扩充：智谱、Ollama、Anthropic、Google Gemini 等模型接入
向量库 API 稳定化，废弃旧构造器，统一 Builder 模式

工具调用机制：ChatModel内置自动工具循环，调用工具后模型会自动循环直到返回最终答案

适用场景：SpringBoot3 项目，RAG 知识库、简单对话、基础工具调用，国内绝大多数企业项目选型。

2.2、1.0.x 补丁版本（1.0.1 ~1.0.9，稳定性维护）

向量库各类 bug 修复、元数据检索优化
结构化输出增强，Kotlin DataClass JSON Schema 支持
依赖包安全升级，修复并发、空指针问题
新增更多文档解析器，优化大文件分片策略

2.3、1.1.0 GA（2025-11，1.x 大版本增强）

核心亮点

首次引入 MCP（Model Context Protocol），可以对接 MCP 外部工具服务（早期 MCP 在社区包）
新增更多模型、向量库实现，增强检索重排组件
优化 ChatMemory 会话记忆，支持内存 / Redis 持久化会话
850 + 项改进、241bug 修复，提升整体稳定性

注意：1.1 仍然基于 SpringBoot3、JDK17，可以平滑从 1.0 升级，破坏性变更很少

3、2.x 新一代架构系列（SpringBoot4 + JDK21，全新重构，有破坏性变更）

重大前提：2.0 不再兼容 SpringBoot3 项目，必须升级 Boot4、JDK21；大量 API 破坏性改动，升级需要改造代码

3.1、2.0.0 GA（2026-06，新一代正式版）

核心架构改动 & 新特性

工具调用逻辑重构【最大变更点】移除 ChatModel 内部自带工具循环；ToolCallingAdvisor 接管工具循环执行。直接调用 ChatModel 只会返回工具请求，不会自动循环。好处：完全可控工具执行链路，支持自定义重试、终止策略。
MCP 移入核心包：MCP 注解、MCP 服务传输模块从社区包迁移进 SpringAI 核心，MCP 成为一等公民；支持 MCP Client 和 MCP Server 双向开发。
RAG 模块化升级：旧版QuestionAnswerAdvisor替换为RetrievalAugmentationAdvisor，支持多路检索、检索后重排、可自由组装 RAG 链路，不再是黑盒 RAG。
代码全量 JSpecify 注解，强空安全，大幅减少空指针异常；
Jackson 2 → Jackson3，JSON 序列化底层重构，新增 JsonHelper 自定义序列化
新增ToolSearchToolCallingAdvisor，支持海量工具检索，上千工具场景不用一次性全部传给大模型，解决工具数量上限瓶颈
ChatMemory 持久化能力增强，统一ChatMemoryRepository，JDBC/Redis/Mongo 多存储实现标准化

破坏性变更清单（升级重点）

ChatModel 内部自动工具循环移除，必须使用 ToolCallingAdvisor
部分模型模块移除（独立 AzureOpenAI 模块合并进 OpenAI 模块）
MCP 包路径、注解包名全部变更
Jackson 版本升级，JSON 序列化相关代码需要验证

适用场景：新项目 SpringBoot4、JDK21，需要 MCP、复杂 RAG、大量业务工具的企业 AI 应用。存量 SpringBoot3 项目不建议升级。

3.2、2.0.1（2026-08，2.0 维护版）

80 + 问题修复，基于生产反馈稳定优化
PDF 文档读取支持指定页码范围，TokenTextSplitter 增强
Google GenAI 新增 ToolChoice 控制、文生图 ImageModel 支持
DeepSeek API 对齐规范；Couchbase 向量库适配 Spring 托管客户端
OpenAI 工具调用 strict 模式默认关闭，匹配原生 OpenAI 行为

3.3、2.1.0-M1（2026-09，里程碑预览版，非 GA）

基线升级 SpringBoot4.2
新增 OpenAI Responses API 支持
结构化消息内容模型（Message Parts），为后续 Agent 能力铺垫
支持预计算 Embedding 直接写入向量库

1.3.2、版本选型一句话总结

老项目 SpringBoot3，JDK17→ 选Spring AI 1.1.x GA，稳定，生态成熟
全新项目 SpringBoot4、JDK21，想用 MCP、模块化 RAG→ 选Spring AI 2.0.1 GA
0.8/0.9 版本：仅用于学习参考，绝对不要上线生产
2.1.0-M1：预览版，仅适合尝新，不用于业务系统

1.3.3、版本演进主线逻辑

0.x：验证可行性，搭建基础 API 原型，实验性质 1.x：稳定落地，定型 Advisor 架构，ChatClient，支持企业 RAG、基础工具调用，引入早期 MCP 2.x：架构重塑，基于 SpringBoot4/JDK21，把 Agent 工具循环、MCP、模块化 RAG 作为核心能力，面向更复杂企业智能体场景

2、大模型选型

大模型的选型主要划分为三大类，分别是“自研大模型”、“云端大模型”、“开源大模型(可私有化本地部署)”，下面针对三类大模型进行介绍

2.1、自研大模型(从零预训练基座大模型)

定义：从零构建模型架构，采集海量原始语料，完整预训练基座大模型。不是对开源模型微调。

2.1.1、特点

完全自主知识产权，底层 100% 可控。模型架构、权重、训练数据全部自主掌握，可以针对行业底层特性深度优化；
可以解决通用模型无法覆盖的专属底层能力；
缺点：
- 成本极高：大规模 GPU 集群、电力、存储，资金动辄千万甚至上亿；
- 人才门槛极高，需要顶尖算法团队；
- 周期极长，从数据准备到训练收敛需要数月至数年；
- 后续持续迭代、安全对齐、漏洞修复，长期维护成本巨大；
- Java 在训练阶段几乎不参与；只有模型训练完成、对外提供推理接口后，Java 才做上层业务应用。

2.1.2、适用业务场景

仅限头部大厂、国家级科研机构，普通企业业务项目基本不考虑：

企业战略层面要求完全自主知识产权，不允许依赖开源或第三方厂商模型；
拥有独有的海量行业语料，通用大模型底层能力无法满足；
有充足资金、大规模算力、完整预训练算法团队。

注：绝大多数业务系统不需要自研基座模型，业务需求优先考虑开源微调或者云端 API。

2.1.3、对应岗位

大模型算法科学家 / 预训练算法工程师（核心）：模型架构设计、分布式预训练、超参调优、损失优化。
数据算法工程师：海量语料采集、清洗、去重、质量过滤、数据流水线。
MLOps / 分布式训练工程师：分布式训练集群、DeepSpeed/Megatron-LM、断点续训、算力调度。
对齐算法工程师：SFT、RLHF、模型安全对齐、模型评测。
Java 后端工程师：训练完成之后，开发上层 AI 业务应用，封装推理接口、业务集成。
存储 / 网络 / 运维工程师：支撑大规模 GPU 集群基础设施。

2.2、云端大模型（厂商 SaaS API）

云端大模型厂商SaaS API‌，是大模型厂商将部署在云端的超大规模模型能力，封装成标准化的可编程接口对外输出的SaaS化服务，开发者无需自行搭建大模型算力集群，几行代码就能把AI能力集成到自己的产品中。

2.2.1、特点

接入简单，开发成本低：Java 直接通过 HTTP/OpenAI 兼容协议调用 API，SpringBoot + OkHttp/RestTemplate 即可，不用管理 GPU、驱动、模型权重。
按量 Token 计费，前期投入小；算力、模型升级、安全对齐全部由厂商维护，模型版本自动迭代。
天然弹性扩容，应对流量波动，不用自己搭建集群。
缺点：
- 业务数据上传到厂商云端，敏感 / 涉密数据存在合规风险；
- 依赖外网，网络抖动会带来延迟，内网隔离场景无法使用；
- 存在 QPS 限制，高并发场景 Token 费用会快速上涨；
- 模型能力黑盒，底层不可修改，定制能力有限，微调一般走厂商云端微调服务。

2.2.2、适用业务场景

适合快速验证、非涉密、业务迭代快的场景：

企业营销文案生成、商品描述、邮件 / 报告摘要、内容润色
对外客服机器人、公开知识库问答（非涉密文档）
POC 原型、MVP 快速上线，市场活动类 AI 功能
低并发、短期项目，不想投入硬件和 AI 运维人力

2.2.3、对应岗位

Java 后端开发（核心）：封装 API 调用、会话管理、限流熔断、Prompt 组装、结果解析、对接向量库实现 RAG、权限日志，对接原有业务系统。
AI 应用工程师：Prompt 工程、参数调优（temperature、top_p）、RAG 编排、模型效果评估。
产品经理：需求拆解、AI 能力定义、成本评估、人机交互设计。
测试工程师：接口测试、压测、大模型输出效果校验、异常场景测试。

2.3、开源大模型（私有化本地部署）

开源模型≠自研。拿到开源基座权重后，企业可以本地部署推理、领域微调（SFT），可以部署在自有服务器 / 私有云。Java 服务一般作为业务网关，转发请求到推理服务（vLLM、TGI、Ollama 等，推理服务用 Python 生态）。

2.3.1、特点

数据不出内网，满足等保、数据安全、隐私合规，敏感数据不会对外传输；
自主可控：可自由选择模型版本（7B/13B/70B）、可以基于业务私有数据做领域微调；
硬件一次性投入，调用不再按 Token 计费，高频长期调用成本优于云端 API；
可离线运行，断网环境可用；
缺点：
- 需要 GPU 硬件，显存要求高，硬件采购成本高；
- 需要维护 CUDA、推理服务、模型版本、监控 GPU 资源，MLOps 运维成本高；
- 推理延迟受硬件限制，低配硬件会出现响应慢；
- 需要人力做模型微调、数据清洗、效果评测。

2.3.2、适用业务场景

数据敏感、内网隔离、合规要求高、长期稳定业务：

金融、政务、医疗内部文档智能分析、合同审核、工单智能处理
企业内部涉密知识库、私有 RAG 问答系统
工业内网系统，离线场景使用大模型能力
高频大量调用，云端 Token 费用过高的业务

注：很多客户口中的 “自研大模型”，实际就是开源大模型私有化 + 领域微调，并不是从零训练基座。

2.3.3、对应岗位

Java 后端开发：业务网关、会话管理、RAG 业务链路、向量库集成、权限、熔断监控，转发请求到内部推理服务。
MLOps 工程师：GPU 集群搭建、部署 vLLM/TGI 推理服务、模型版本管理、算力监控、扩缩容。
AI 应用 / 算法工程师：开源模型选型、领域微调、Prompt 优化、RAG 优化、模型效果评估。
数据工程师：文档解析、文本清洗、知识库切片、向量化、向量库数据维护。
测试工程师：性能压测、模型输出质量、稳定性、并发测试。

2.4、选型决策（Java 项目视角快速判断）

需求快速上线、数据不敏感、预算有限 →云端大模型 API，Java 直接对接。
业务数据涉密、内网使用、合规要求高、长期高频调用 →开源大模型私有化部署 + 领域微调，Java 做业务网关与 RAG 编排。
战略级诉求、海量资金 + 顶级算法团队，需要完全自主知识产权 →自研基座大模型（绝大多数业务场景不推荐）

2.5、Java 典型架构

云端 API 架构：SpringBoot (Java) → HTTP 请求云端大模型 + 向量库（RAG）
开源私有化架构：SpringBoot (Java) 业务服务 → HTTP/gRPC 转发到 vLLM 推理服务 + 向量库
自研模型架构：Python 完成训练 → 导出推理服务 → Java 对接推理服务做业务层

企业官网建设流程全解析