WangQuan's Blog

Appearance

Spring AI 总览 ​

如果你只是想看“怎么发起一次模型调用”，一两个 demo 就够了。
但如果你想把 Spring Boot + Spring AI 真正落成一个稳定项目，主线通常不会停在“调通接口”这一步。

更完整的工程问题通常是：

  1. 最小聊天接口怎么起步
  2. 流式输出怎么暴露给前端
  3. Function Call 和业务工具怎么接
  4. MCP 在 Spring 项目里该落在哪一层
  5. 知识库、文档切分、向量化、召回、重排和向量数据库怎么组织
  6. RAG、Agent、工作流、记忆、稳健性治理怎么逐步补齐

所以这一组笔记不再按“单篇示例”组织，而是按一条更贴近真实项目落地的演进主线组织。

1. 这条知识线到底在解决什么问题 ​

可以把它理解成：

如何把大模型能力，从一个能跑的聊天接口，逐步演进成一个具备流式输出、工具调用、检索增强和 Agent 能力的 Spring Boot 应用。

这里最值得先分清 3 层：

  1. 模型接入层：聊天、流式、结构化输出
  2. 外部能力层：工具调用、MCP、业务工具链
  3. 知识与执行层：知识库、RAG、Agent、工作流、治理

2. 🌟 完整项目落地通常怎么推进 ​

如果按一个真实项目从 0 到 1，再从 1 到更稳的顺序来看，更自然的推进通常是：

  1. 先跑通最小聊天接口
  2. 再补流式输出
  3. 再补 Function Call
  4. 再补工具链接入和 MCP
  5. 再补知识库、向量检索和 RAG
  6. 最后再补 Agent、工作流和治理能力

2.1 一张项目演进流程图 ​

mermaid
flowchart TD
    A[创建 Spring Boot 项目] --> B[接入 Spring AI 模型能力]
    B --> C[暴露最小聊天接口]
    C --> D[补流式输出]
    D --> E[补 Function Call]
    E --> F[接业务工具链 / MCP]
    F --> G[接 Knowledge Base / Embedding / VectorStore]
    G --> H[补 RAG 与检索增强]
    H --> I[演进到 Agent / Workflow]
    I --> J[补可观测性 / 限流 / 审计 / 降级]

这张图最想表达的是：

  1. 真正的落地主线不是一下子把所有能力堆满
  2. 更自然的节奏是把“基础交互”跑通
  3. 再逐步补外部能力、知识增强和治理能力

3. 推荐阅读顺序 ​

如果你希望按“完整项目落地”的顺序来读，推荐按下面几篇走：

  1. Spring Boot + Spring AI：最小接入、聊天接口与流式输出
  2. Spring Boot + Spring AI：Function Call、工具链调用与 MCP
  3. Spring Boot + Spring AI：知识库、分片、向量化、召回、重排与向量数据库实战
  4. Spring Boot + Spring AI：RAG、Agent 与稳健性治理
  5. Spring Boot + Spring AI：Agent 完整落地方案

这样排的原因是：

  1. 第一阶段把模型接入和前后端交互主线跑顺
  2. 第二阶段再把“模型如何调外部能力”讲清楚
  3. 第三阶段把知识库问答这条链路补扎实
  4. 第四阶段再把 Agent 执行和项目治理串起来
  5. 最后再用一篇完整方案把对话模型、知识库、Tool、MCP、Skill 和 Agent 编排真正串起来

4. 这三篇分别解决什么问题 ​

4.1 最小接入、聊天接口与流式输出 ​

先从这一篇开始：

  1. 依赖怎么加
  2. 配置项最小长什么样
  3. ChatClient / ChatModel 怎么接
  4. 怎么暴露同步和流式接口
  5. 为什么建议 Controller -> Service 分层

入口：

4.2 Function Call、工具链调用与 MCP ​

再往下就是这一篇：

  1. Function Call 在 Spring Boot 项目里怎么落
  2. @Tool 或工具 Bean 该怎么组织
  3. 工具调用链路怎么和业务服务衔接
  4. MCP 和 Function Call 的边界是什么
  5. 什么场景更适合把工具能力抽成 MCP Server

入口：

4.3 知识库、分片、向量化、召回、重排与向量数据库 ​

知识库这一块，重点在这一篇：

  1. 知识库问答完整链路在 Spring Boot 项目里该怎么拆
  2. 文档切分为什么会直接影响召回效果
  3. EmbeddingModel、VectorStore、过滤和 Rerank 应该放在哪
  4. 什么场景更适合做混合检索
  5. PGVector、Milvus、Elasticsearch / OpenSearch、Redis 这类向量方案该怎么判断

入口：

4.4 RAG、Agent 与稳健性治理 ​

当你开始把能力往线上场景放，重点会落到这一篇：

  1. RAG 和 Agent 在项目里通常怎么配合
  2. 多步执行能力在 Spring Boot 项目里怎么组织更稳
  3. 什么能力属于“能跑”，什么能力属于“能上线”
  4. 限流、超时、降级、审计、日志这些治理点该补在哪
  5. 为什么第三阶段的重点最终还是边界和治理

入口：

4.5 Agent 完整落地方案 ​

如果要把整套链路真正串起来，就看这一篇：

  1. 一个 Spring AI Agent 项目完整应该拆成哪几层
  2. 对话模型、知识库、Tool、MCP、Skill、Agent 分别放在哪
  3. 一套更可落地的代码骨架应该怎么组织
  4. 这些能力在一次真实请求里是怎么串起来的
  5. 从“能跑”走到“能扩展”的关键边界是什么

入口：

5. 🌟 最值得先记住的边界 ​

  1. Spring AI 不是另一个 Web 框架，它是把 AI 能力接进 Spring 编程模型
  2. Function Call 负责模型表达“想调用什么”，不等于模型直接执行业务
  3. MCP 负责标准化工具 / 资源对接方式，不等于所有工具都必须走 MCP
  4. RAG 负责把外部知识带进回答过程，不等于一接向量库答案就会天然正确
  5. Agent 负责多步任务执行，不等于系统天然就稳健可控

6. 这条线和现有 Spring 知识地图是什么关系 ​

放到整套 Spring 知识地图里，大概可以接在这里：

  1. 你已经理解 Spring Boot 基础启动和分层之后
  2. 但又还没进入“AI 工程完整落地”之前

和现有几篇放在一起看，大致是这个顺序：

  1. 看 Spring Boot
  2. 再看这一组 Spring AI 落地专题
  3. 再回到 Spring Security、Actuator 与可观测性 这些治理能力专题，把生产能力补齐

7. 一段更稳的总结 ​

如果把 Spring Boot + Spring AI 压缩成一句话，可以记成：

把模型接进 Spring Boot 应用，再把流式输出、工具调用、知识库、RAG 和 Agent 能力按工程分层逐步接进来，最后补齐治理能力，才能从“能跑 demo”走到“能稳定落地”。

基于 VitePress 构建的个人技术笔记。

Copyright © 2026 WangQuan's Blog