企业官网建设流程全解析

Spring AI 2.0 RC：Java Agent 工程化正在收敛

分享日期：2026-06-11
主题：Java / Spring AI / AI Agent / Tool Calling / MCP / RAG

1. 为什么今天值得关注

Spring AI 最近的发布节奏很密集。官方文档当前稳定版标注为 1.1.7，同时提供 2.0.0-RC2 预览文档；GitHub Releases 显示 2.0.0-RC2 在 2026-06-09 发布。对 Java 团队来说，这个信号很明确：AI 应用不再只是“调一个模型接口”，而是开始进入可治理、可观测、可组合的工程化阶段。

2.0 RC 的重点不是单个新模型，而是把企业 AI 应用里最常见的几块能力收拢到 Spring 的开发模型里：

• 用ChatClient统一构建提示词、模型调用、流式响应和结构化输出。
• 用 Tool Calling 让模型能请求调用业务系统能力，但由应用代码负责真正执行。
• 用 MCP 把外部工具、数据源、文件系统、内部服务变成标准化上下文能力。
• 用 RAG 和 Advisor 把企业知识库接入问答链路。
• 用 Spring Boot starters 和配置体系降低多模型、多传输、多环境切换成本。

一句话：Spring AI 正在把“AI Agent”从 Demo 代码拉回 Java 后端团队熟悉的工程边界里。

2. 从聊天机器人到 Agent，差别在哪里

传统聊天机器人通常只做一件事：接收用户输入，拼提示词，调用模型，返回文本。它的问题也很明显：模型不知道实时数据，不能访问内部系统，不能真正执行业务动作，也很难控制错误边界。

Agent 应用多了三层能力：

1. 检索上下文：从数据库、向量库、文档库、搜索系统拿到模型不知道的资料。
2. 调用工具：根据模型请求，执行受控的业务动作，例如查订单、建工单、发审批。
3. 管理过程：记录记忆、限制权限、观测调用链、处理失败、控制成本和延迟。

Spring AI 的价值就在这里：它不试图让模型绕过应用层直接访问世界，而是把模型放在 Spring 应用的编排链路里。模型提出“我需要调用哪个工具、用什么参数”，真正的执行、鉴权、审计、重试和降级仍由 Java 应用负责。

3. 核心链路图

User[用户请求] --> API[Spring Boot API] API --> ChatClient[Spring AI ChatClient] ChatClient --> Advisor[Advisors: Memory / RAG / Guardrails] Advisor --> Vector[(Vector Store)] Advisor --> ChatModel[Chat Model] ChatModel --> ToolCalling[ToolCallingAdvisor] ToolCalling --> LocalTool[本地业务工具] ToolCalling --> McpClient[MCP Client] McpClient --> McpServer[MCP Server] McpServer --> External[数据库 / API / 文件 / SaaS] ToolCalling --> ChatModel ChatModel --> API API --> User

这张图里最重要的不是模型，而是边界：

• ChatClient是应用侧入口，负责把提示词、参数、Advisor、工具组织成一次调用。
• Advisor是横切能力，适合放记忆、RAG、过滤、评估、观测等逻辑。
• ToolCallingAdvisor管理工具调用过程，避免工具执行散落在模型适配器里。
• MCP Client/Server把工具和资源抽象成跨应用、跨进程、跨语言的标准协议。

4. Tool Calling：模型不能直接碰业务系统

Spring AI 文档强调了一个关键安全点：工具调用看起来像是模型能力，但实际执行逻辑由客户端应用提供。模型只能请求调用某个工具并给出参数，应用负责识别工具、校验参数、执行调用，再把结果返回给模型。

这对企业应用非常关键。不要把 Tool Calling 理解成“给模型开权限”，应该理解成“让模型提交一次受控的函数调用申请”。

典型 Java 写法如下：

import java.time.LocalDateTime; import org.springframework.ai.tool.annotation.Tool; import org.springframework.context.i18n.LocaleContextHolder; class DateTimeTools { @Tool(description = "Get the current date and time in the user's timezone") String getCurrentDateTime() { return LocalDateTime.now() .atZone(LocaleContextHolder.getTimeZone().toZoneId()) .toString(); } }

调用时把工具挂到ChatClient：

String response = ChatClient.create(chatModel) .prompt("What day is tomorrow?") .tools(new DateTimeTools()) .call() .content();

生产里要补齐三类控制：

• 权限控制：用户能不能调用这个工具，能不能访问这条数据。
• 参数校验：模型给出的参数必须按业务规则二次校验，不能直接信任。
• 审计观测：记录工具名、调用参数摘要、执行结果、耗时、失败原因和 trace id。

5. MCP：把工具接入从“逐个硬编码”变成协议化

MCP 的全称是 Model Context Protocol。它的目标是为 LLM 应用和外部数据源、工具之间提供标准连接方式。官方规格把 MCP 角色分成 Host、Client、Server：Host 是 AI 应用，Client 是 Host 内部的连接器，Server 提供工具、资源和提示词能力。

Spring AI 对 MCP 的支持值得 Java 团队关注，原因有三点：

• 工具发现更标准：不是每个应用都手写一套工具注册表，而是通过 MCP Server 暴露工具。
• 集成边界更清晰：本地工具、远程服务、文件系统、数据库可以通过统一协议接入。
• 生态复用更容易：Java 应用既可以消费别人的 MCP Server，也可以把自己的 Spring 服务暴露为 MCP Server。

Spring AI 文档里已经列出了 MCP Client 和 Server 的 Boot Starter。客户端侧支持STDIO、Streamable-HTTP、Stateless Streamable-HTTP和SSE等传输；服务端侧也有 WebMVC、WebFlux、STDIO 等不同形态。这意味着 MCP 不只是 IDE 插件场景，也可以进入后端服务和内部平台。

一个务实的判断是：内部系统能力还比较少时，可以先用本地@Tool；当工具数量变多、需要跨应用复用、需要动态发现和统一治理时，再把能力沉淀为 MCP Server。

6. RAG：Advisor 更适合放企业知识链路

大模型不知道企业内部最新文档，也不能自然保证回答事实正确。RAG 的作用就是在模型回答前，先从知识库里检索相关材料，再把这些材料作为上下文交给模型。

Spring AI 的 RAG 支持走模块化路线：你可以自己组装检索流程，也可以使用开箱的 Advisor。官方示例里，QuestionAnswerAdvisor会从VectorStore里按用户问题做相似度搜索，把检索结果追加到用户输入里，为模型生成答案提供上下文。

示例形态：

ChatResponse response = ChatClient.builder(chatModel) .build() .prompt() .advisors(QuestionAnswerAdvisor.builder(vectorStore).build()) .user(userText) .call() .chatResponse();

工程落地时，RAG 最容易踩的坑不是“向量库怎么连”，而是下面这些细节：

• 文档切片太粗会漏信息，太细会丢语义。
• 只做相似度检索，容易把过期文档和无关文档塞进上下文。
• 没有引用来源，用户无法判断答案依据。
• 没有评估集，调 chunk、topK、rerank、prompt 时全靠感觉。
• 没有数据权限过滤，会把用户不该看的内容检索出来。

所以 RAG 的生产清单应该包括：数据分级、元数据过滤、引用返回、离线评测、命中率监控、答案拒答策略和过期文档治理。

7. 2.0 RC 暴露出的工程方向

从 2.0.0-RC1 到 2.0.0-RC2 的 release notes 看，Spring AI 团队在收敛几个方向：

• 工具调用从模型内部执行走向统一的 Advisor/Manager 管理。
• 显式ToolCallback和运行时工具注入成为更重要的使用方式。
• OpenAI、Anthropic 等模型 HTTP Client 可配置性增强，利于企业代理、超时、连接池、观测和网络治理。
• ChatModel options 的替换/合并语义在修复，说明多模型配置正在走向更严格的行为一致性。
• MCP SDK 和 Streamable HTTP 相关能力持续演进，说明“工具协议化”正在成为主线之一。

这也给使用方一个提醒：2.0.0-RC2 仍然是预览版，不建议直接压到核心生产系统。更合理的路径是：

1. 生产项目继续使用稳定版 1.1.7。
2. 新 Agent 原型、内部平台 PoC、MCP Server 试点可以用 2.0.0-RC2 验证。
3. 已经大量使用早期 Spring AI API 的项目，尽快对照 2.0 升级说明盘点破坏性变化。
4. 把 Tool Calling、RAG、MCP 这三块从业务代码里拆成独立模块，降低后续升级成本。

8. 给 Java 团队的落地建议

第一阶段：先做“可控问答”

适合场景：内部知识库、运维手册、客服 SOP、研发规范问答。

建议技术组合：

• ChatClient
• QuestionAnswerAdvisor
• 向量库
• 文档元数据过滤
• 引用来源返回

目标不是做炫酷 Agent，而是把回答正确率、数据权限、引用可追溯性跑通。

第二阶段：再做“只读工具”

适合场景：查订单、查库存、查账单、查工单、查部署状态。

建议先只开放只读工具，避免一开始就让模型触发写操作。每个工具都要有清晰描述、参数 schema、权限校验和失败返回规范。

只读工具跑稳后，再考虑写操作。

第三阶段：最后做“可执行工作流”

适合场景：创建工单、发起审批、生成报告、执行低风险运维动作。

这类场景必须有人审、可回滚、可追踪。模型可以生成计划和参数，但关键动作建议走确认机制，尤其是支付、权限、删除、发布、外部通知这类高影响操作。

9. 分享金句

Spring AI 2.0 RC 的意义不是让 Java 应用“更会聊天”，而是把模型调用、工具执行、RAG、MCP 和观测治理放回 Spring 工程体系里。真正能进生产的 Agent，不是模型更自由，而是边界更清楚。

参考资料

• Spring AI Releases
• Spring AI Tool Calling Reference
• Spring AI MCP Reference
• Spring AI RAG Reference
• Spring AI ChatClient Reference
• Model Context Protocol Specification 2025-06-18