第 1 章 · Spring AI 技术概览

关注

原创最新推荐文章于 2026-09-28 00:15:00 发布 529 阅读 AI 写同款· GEO 优化 ›

用JAVA实现人工智能：采用框架Spring AI Java 过去，Java在AI应用框架方面存在不足，缺乏一个能够良好支持AI开发的统一框架。SpringAI应运而生，它是一个专为AI工程设计的应用框架，旨在将Spring生态系统的设计原则如可移植性和模块化引入AI领域。SpringAI的核心优势在于它提供了一套标准化接口，使得开发者可以轻松地切换不同的AI服务提供商，仅需修改配置即可。此外，SpringAI与现有的Spring生态兼容性极好，同时也完美地融入了Java面向对象编程的特点。这不仅简化了开发流程，还极大地减少了迁移和维护的成本。阅读详情

版本：Spring AI 2.0.1 · Spring Boot 4.x · JDK 17+（推荐 21）本章先建立全貌。环境搭建、API 细节与排障，放在后续专章。

把大模型接入 Java 业务，常见工作包括：对接各家 HTTP、组装多角色消息、解析响应与 token、执行工具调用、维护多轮记忆、检索私有知识、处理流式输出、得到结构化结果，并补齐观测。

这些都可以自研 SDK 封装，但每个服务重复做一遍成本很高。Spring AI 的定位，是用 Spring 体系里熟悉的抽象和 Boot 自动配置，把上述能力收成可替换模块。业务代码尽量面向接口编写；底层切换 OpenAI、Ollama 或兼容 endpoint 时，主路径改动应尽量小。

1.1 三层结构

理解 Spring AI，可以先抓住上图这三层；后续章节都是在此基础上展开。

应用层是业务开发最常接触的一层。多数场景从 ChatClient 起步：API 更顺手，记忆、RAG、日志、安全可通过 Advisors 接入，业务方法也能以 @Tool / ToolCallback 的形式交给模型调用。Controller 或领域服务通常停在这一层即可。

抽象层是真正的解耦边界。ChatModel、EmbeddingModel、VectorStore，以及消息与 Prompt，都定义在这里。更换供应商时，业务应尽量只依赖这些抽象类型，而不是某一家的私有客户端。在图节点中做薄调用，或在多模型之间路由时，也常会直接使用 ChatModel。

提供商层是各家模型与向量库的具体实现，通过 spring-ai-starter-* 自动配置进入容器。业务代码应尽量停留在抽象层之上。

此外还有两条贯穿能力：System / User / Assistant / Tool 组成的消息流；以及基于 Micrometer Observation 的调用次数、耗时与 token 观测。后面各章基本是在这张图上深入某一部分，而不是引入另一套概念体系。

1.2 一次对话请求的路径

聊天主链可以概括为：

业务代码
  → ChatClient（可选 Advisors / Tools / 模板）
  → Prompt（Message 列表 + ChatOptions）
  → ChatModel.call 或 stream
  → 具体 Provider
  → ChatResponse（文本 / 结构化结果 / toolCalls / Usage）

阅读这条链路时，有三点值得提前澄清：

ChatClient 不是另一套协议。 它减少的是组装成本；底层流通的仍是 Message、Prompt、ChatResponse。
工具循环既可以发生在 ChatClient / Advisor 侧，也可以由外层自行实现。 这与是否引入状态图是不同层面的问题。
Embedding、VectorStore、MCP 不一定经过聊天主链的每一步，但模块引入与自动配置的方式是一致的。

默认建议：普通对话优先使用 ChatClient；需要更薄的调用、手工控制工具循环，或做多模型切换时，再下沉到 ChatModel。具体用法在后续章节分别说明。

1.3 能力覆盖范围

不必先记忆模块清单，按要解决的问题来看会更清楚。上图是能力块总览，这里只补几句阅读提示：

对话、流式、消息与选项，是后面几乎所有能力的基础。
Advisors、窗口 / 长期记忆、Tool、结构化输出、RAG、知识图谱，是业务里最常叠加的能力块。
MCP 扩展的是工具目录，不替代流程编排。
观测、安全、多模态与评估，对应「能 Demo」之后的工程化。
依赖统一走 BOM + starter，避免手写零散版本号。

本章目标是建立「有哪些能力块、各自大致负责什么」的印象。配置方式与常见问题，留到对应专章。

1.4 依赖引入方式

能力划分可以很细，但应用侧日常入口并不复杂：

用 spring-ai-bom 固定版本
引入模型 starter，先打通聊天
记忆仓库、向量库、MCP、Advisor 等按需追加

实践上建议：版本只在 BOM 中固定一处，业务只引入当前场景需要的 starter。 具体坐标在后续依赖章节给出。

1.5 能力边界

Spring AI 适合解决的是：多家模型的统一接入，以及工具、记忆、RAG、知识图谱接入模式、结构化输出、流式、MCP、观测等周边能力，并与 Spring Boot 的使用方式对齐。

它不负责、或不适合单独承担的，主要是另一类问题：

复杂状态机、人工审批、中断后恢复 → 更适合 LangGraph4j
BPM、模型训练与微调平台
完整 GraphRAG 产品层 / 超大规模混合检索中台（通常需在 VectorStore 与图库之上自建）因此本系列的分工是：模型与周边能力使用 Spring AI；当流程本身成为业务资产时，再引入图编排。二者是底座与编排的关系，而不是互相替代。本分册先把 Spring AI 这一侧讲清楚。