MCP 正在成为 Java 后端的新接口层：从 REST 到工具调用的迁移路线

MCP 正在成为 Java 后端的新接口层：从 REST 到工具调用的迁移路线

一、开篇：一周之内四条线索指向同一件事

2026 年 10 月到 11 月初，Java 后端社区密集出现了几类内容并不相同、但技术取向高度一致的实践文章：其一，有开发者基于 Spring Boot 4.1 与 Spring AI 2.0 搭建了一个覆盖 RAG、知识图谱、工作流编排与 MCP 的 Agent 平台，并分别实现了 SSE 与 Streamable HTTP 两种 MCP 服务端传输，声称覆盖工具注册、调用与双向流式通信 [1][2]；其二，AgentScope 的 Java 版本被以 Spring Boot Starter 的方式接入既有微服务，Agent 注册为 Spring Bean，消息传递复用 Spring 事件机制或消息队列 [5]；其三，Redis 接入 MCP 协议的实战文章提出让 Claude Code 直接操作缓存与队列 [4]；其四，有团队主张用 MCP 协议加纯元数据沙箱，替代“层层包装 REST API + 维护 BPMN 引擎”的方式，让 Agent 接管跨部门审批流 [3]。

这四条线索分别覆盖了 MCP 的四个侧面：协议与传输、多智能体编排、基础设施直连、业务流程接管。它们共同构成一个值得认真对待的判断——在 Java 后端体系里，MCP 正在从“某个 AI 框架的附属功能”演变为一层独立的接口层：它与既有的 REST Controller 并列，面向的是另一类调用方，遵循的是另一套契约与治理规则。

需要先说清楚本文的事实边界。上述四篇文章均为社区实践分享，其中涉及的版本号（如 Spring Boot 4.1.0、Spring AI 2.0.1、LangGraph4j 1.8.27、Spring Cloud 2025.0.1、Java 21）是作者自述 [1][2]，本文写作时未能逐项与官方发布记录核对；Spring Framework 7.1 在官方 Wiki 中仍标注为预览页面、计划于 2026 年 11 月发布，其内容可能继续变动 [8]。因此，本文不把这些版本号当作结论，只把它们当作观察样本。文中代码均为不依赖特定框架 API 的结构示意，实际接入请以 Spring AI 官方文档与 MCP 规范原文为准；社区文章中的主张一律以“来源观点”呈现，不代表本文背书。

本文不讨论“REST 会不会死”这类无法证伪的命题，也不逐个复述四个项目的搭建步骤。要解决的是三个工程问题：什么时候该暴露 MCP、工具契约与流式传输怎么落地、Agent 直连基础设施之后风险如何收敛。

四个案例的能力对照

案例	来源	主要能力	Agent 最终触达的对象	来源所述的边界/治理手段
Spring Boot 4.1 + Spring AI 2.0 Agent 平台	[1][2]	RAG、LangGraph4j 工作流、A2A 协作、MCP 双传输（SSE 与 Streamable HTTP）	向量库、知识图谱、对象存储、消息系统等	提到 Skills 沙箱、流量治理
AgentScope Java Starter 多智能体编排	[5]	Agent 注册为 Spring Bean，消息走 Spring 事件或消息队列	既有业务微服务	文章以踩坑记录为主，治理细节有限
Redis 接入 MCP	[4]	让 Claude Code 直接操作缓存与队列	Redis（缓存、队列、分布式锁）	未给出系统化的权限模型描述
MCP 接管跨部门审批流	[3]	纯元数据 + MCP 生成“系统沙箱”，替代 REST 包装与 BPMN	审批流引擎与业务对象	主张元数据沙箱，具体机制为作者自述

从这张表可以看出一个重要共性：MCP 层出现之后，Agent 的触达对象从“另一段业务逻辑”迅速下沉到了数据库、缓存、队列、审批状态机这类原本只有后端服务才有权操作的资产。这既是它的价值所在，也是本文第四节要专门讨论风险的原因。

二、先定边界：MCP 与 REST 各自解决什么问题

2.1 一句话模型：确定性调用方与非确定性调用方

REST 接口的设计前提是调用方行为可预期。前端、脚本、其他服务调用 /api/orders/{id} 时，调用时机、参数取值、重试策略都由开发者写死在代码里，接口契约的作用是让两个人类团队在解耦的前提下达成一致。

MCP 工具面对的是另一种调用方：由大模型驱动的 Agent。它在运行时决定调用哪个工具、传什么参数、失败后是否重试、是否把结果继续传给下一个工具。接口描述不再只是编译期或联调期的文档，而是运行时直接影响行为的“提示词”——工具名称和参数描述写得含糊，模型就会调错或猜参数。

因此，更准确的表述是：MCP 不是 REST 的传输变体，而是为非确定性调用方准备的工具契约层。REST 的消费方是程序，MCP 工具的消费方是模型加一段运行时策略。

2.2 协议形态对比

维度	REST	MCP 工具
典型调用方	前端、服务、脚本	LLM Agent（经 MCP Client）
契约载体	OpenAPI/Swagger，静态文档	工具 schema + 运行时动态发现（list tools）
资源模型	URL 标识资源，动词表达操作	工具表达语义化操作，辅以资源/提示词等原语
调用模式	请求—响应为主，流式为扩展	会话内双向通信，支持进度通知与取消
鉴权单位	接口/路径/角色	单个工具，且可细化到参数约束
错误语义	HTTP 状态码 + 业务码	结构化工具错误，需面向“模型可恢复”设计
版本化	URL 或 Header 版本	工具名/描述版本化，需配合废弃策略
契约规模	容易膨胀到数千行文档	以“模型一次能用好的工具数”为约束

关于 MCP 的原语构成与传输演进，规范定义了 tools、resources、prompts、sampling 等能力，传输上社区实践已普遍把 Streamable HTTP 作为新的首选，SSE 方式在规范演进中被逐步取代。本文写作材料中没有规范原文可核对，这一表述属通行认知而非引自给定来源，落地前请直接查阅 modelcontextprotocol.io 的规范页面确认当前版本与支持矩阵。

2.3 场景决策表

场景	建议形态	理由
后台管理页面的 CRUD	REST	调用方确定，UI 交互依赖稳定的请求—响应语义
微服务间高频同步调用	REST/gRPC	工具发现与模型推理开销毫无收益
Agent 需要查询/操作业务对象	MCP 工具（可与 REST 并存）	需要语义化工具粒度与工具级授权
长耗时任务（文档解析、批量重算）	MCP + 流式进度通知，REST 保留查询入口	模型需要中间反馈；人需要可轮询的状态接口
事件驱动、系统间解耦	消息系统	MCP 是会话式调用层，不是消息中间件替代品
对外公共 API、有 SLA 与计费	REST 为主	契约稳定性与可观测性要求高于灵活性
跨部门审批、不可逆操作	MCP + 人工确认门	模型只能提议，最终确认权留在人

一个值得强调的判断标准是：接口形态应由调用方的确定性程度决定，而不是由技术潮流决定。同一个用例完全可以同时暴露 REST 与 MCP，共享 service 层，分叉在接口适配层。

2.4 一个反直觉观点：把 Swagger 喂给模型不等于 MCP

审批流那篇文章提出一个尖锐的观察：为了让 Agent 接入，后端往往层层包装 REST API，再把几千行 Swagger 文档塞给大模型，结果模型面对 /api/approve_order 时处在“盲人摸象”的状态 [3]。这是来源作者的比喻与主张，本文不评价其商业方案，但这个比喻指出了真实问题：端点是为程序切分的，不是为任务切分的。

REST 端点通常按资源和 CRUD 切分，一个业务动作可能需要组合五六个端点；模型要自己拼装调用序列，每一步都是出错机会。MCP 工具的价值在于两点：一是把粒度对齐到“任务”而非“资源”，二是把权限判断内建到工具层，而不是指望模型只调“被允许的端点”。单纯换一层传输、不做契约重构，收益接近于零。

三、落地拆解：工具注册、调用与双向流式通信

3.1 三段式生命周期

一个 Java MCP Server 在工程上由三段构成：

1. 注册：把工具名称、描述、参数 schema 与执行器绑定，随服务启动对外发布；
2. 发现：Agent 侧的 MCP Client 通过 list tools 获取当前可用工具集合，模型据此决策；
3. 调用与回传：Client 发起调用，Server 执行领域逻辑，返回结构化结果；长任务可发送进度通知，客户端可取消。

这三段之间存在一个常被忽略的耦合：描述与 schema 的质量直接决定第二段的调用准确率，而错误结构的设计决定第三段失败后模型能否恢复。把工具注册当成“加个注解导出接口”是不够的。

3.2 工具契约的工程要点

命名与粒度。 approve_order 这种动词化命名优于 order_api_v2_action；但也不宜细到 set_order_status_field_3。经验做法是：一个工具对应一个业务用例，一次调用完成一个模型可理解的动作。如果工具数量超过几十个，模型的选择准确率会下降，此时应考虑按域拆分工具集，或用多智能体分别持有不同工具集——AgentScope 的 Java Starter 路线正是把 Agent 注册为 Spring Bean、按职责分配能力的做法 [5]。

参数 schema 的自描述性。 参数名、类型之外，描述里要写清取值范围、单位、默认行为和约束。例如 dept_id 应说明“仅允许调用者所属部门及其下级部门的 ID”，而不是留给模型猜。

幂等性与可重试性。 必须显式标注某个工具是否幂等。Agent 在超时后重试是常态，cache_get 可以无脑重试，queue_push 必须带幂等键，approve_order 则根本不应允许自动重试。

错误结构面向模型设计。 错误返回要区分“参数错（可改后重试）”“权限不足（不可重试，应换路径）”“业务冲突（需人工介入）”“系统繁忙（可延迟重试）”，而不是把 Java 异常栈直接序列化出去。

3.3 代码示意：与框架无关的工具契约骨架

以下代码不引用任何具体框架 API，只展示契约要素，可作为接入 Spring AI MCP Server 时的映射参考；注解名、starter 坐标与注册方式请以 Spring AI 官方文档为准。

import java.util.List;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

// 1) 工具定义：名称、描述、参数 schema、幂等与风险等级
public record ToolDefinition(
        String name,            // 语义化名称，如 cache_get
        String description,     // 给模型看的操作说明与约束
        JsonSchema inputSchema, // 参数类型、范围、必填项
        boolean idempotent,     // 是否允许安全重试
        RiskLevel risk          // READ / WRITE / DESTRUCTIVE
) {}

// 2) 执行结果：结构化，便于模型判断下一步
public sealed interface ToolResult {
    record Ok(Object data, String summary) implements ToolResult {}
    record Recoverable(String code, String hint) implements ToolResult {}   // 参数错误、可修正
    record Fatal(String code, String message) implements ToolResult {}      // 权限不足、需人工
}

// 3) 注册表：启动时装配，运行时可被 list tools 查询
public final class ToolRegistry {
    private final Map<String, ToolHandler> handlers = new ConcurrentHashMap<>();

    public void register(ToolDefinition def, ToolHandler handler) {
        // 此处可挂载 schema 校验、审计埋点、限流器、dry-run 开关
        handlers.put(def.name(), wrap(def, handler));
    }

    public List<ToolDefinition> listTools() { /* 返回对外可见工具集 */ }

    public ToolResult invoke(String name, Map<String, Object> args, CallContext ctx) {
        // 统一处理：参数校验 -> 权限判定 -> 执行 -> 审计
    }
}

对应的工具 schema 片段示意（JSON Schema 风格，字段名以实际协议为准）：

{
  "name": "cache_get",
  "description": "按 key 读取缓存值。key 必须以 'biz:order:' 或 'biz:user:' 前缀开头；本工具只读，禁止用于探测其他前缀。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "key": { "type": "string", "pattern": "^biz:(order|user):[a-zA-Z0-9_-]{1,64}$" },
      "ttlHint": { "type": "boolean", "description": "是否同时返回剩余 TTL，默认 false" }
    },
    "required": ["key"]
  },
  "annotations": { "idempotent": true, "risk": "READ" }
}

描述里的前缀约束、幂等标注、风险等级，就是把治理信息写进契约本身。模型能看到它，网关和审计系统也能读取它。

3.4 传输选型：SSE 与 Streamable HTTP

社区实践中，同一个 MCP 服务端常被做成两种形态：基于 SSE 的实现与基于 Streamable HTTP 的实现，用于覆盖不同的部署环境 [1][2]。工程上的选择通常取决于三个问题：

• 网关与负载均衡兼容性。 SSE 是长连接单向推送，反向代理需要正确处理缓冲与超时；Streamable HTTP 以普通 HTTP 请求承载，更易穿过企业既有网关、鉴权链路和审计设备。
• 双向通知需求。 长任务需要服务端向客户端推送进度、并接受取消指令。传输层必须支持会话内多次消息往返，而不是一次请求一次响应。
• 连接生命周期与伸缩。 长连接意味着会话状态、断线重连、实例迁移都要额外处理；无状态的请求式传输在水平扩容上更简单。

对新系统，除非已有成熟 SSE 基础设施，否则优先评估 Streamable HTTP；对已有 SSE 通道的场景，不必急于迁移，但应确认所用框架版本对该传输的长期支持状态。由于本文材料未包含规范原文，SSE 在当前规范中的具体状态（是否标记弃用、兼容期如何）必须在选型前查证。

3.5 与既有 Spring 代码的共存方式

推荐的模块划分原则是“service 层共享、接口层分叉”：

• 领域逻辑保持在 service/domain 层，REST Controller 与 MCP 工具都调用它；
• MCP 适配层只做三件事：参数到领域命令的映射、错误到工具错误结构的映射、审计与权限拦截；
• 不要在工具 handler 里直接写 SQL 或拼 Redis 命令，否则同一业务规则会在两处漂移；
• 工具集与 Controller 清单分开维护，前者面向任务，后者面向资源。

关于具体装配方式，来源项目提到其 MCP 模块基于 Spring AI MCP Server 构建 [1][2]，AgentScope 文章则提到 Agent 可注册为 Spring Bean、复用 Spring 事件机制 [5]。这类描述足以说明生态方向，但不足以支撑精确到注解名的教程；接入前请核对所用版本的官方参考文档。

四、迁移路线：从 REST 到工具调用的三阶段

4.1 阶段一：并行暴露，不动存量

目标是让 Agent 尽快可用，同时不给存量系统引入风险。

1. 梳理 Agent 真实任务，而不是照抄接口清单。一个“查询订单异常并生成处理建议”的任务，可能需要订单、物流、库存三个域的数据，但只需要一个工具。
2. 在 service 层之上加 MCP 适配层，REST 完全不动。
3. 第一批工具全部设为只读、幂等、带 dry-run 支持。
4. 建立调用日志：记录每次工具调用的入参、结果、耗时、调用来源、触发它的用户与会话上下文。

退出条件：Agent 在真实任务上的工具调用成功率稳定，且日志足以还原“模型为什么这么调”。

4.2 阶段二：契约收敛

目标是把“能用”变成“好用且可控”。

• 根据调用日志合并高频组合：如果模型总是连续调 order_get、order_items_list、customer_get，就提供一个 order_case_view 聚合工具，显著减少调用轮次与出错面。
• 拆分低频大工具：一个 admin_execute 式的通配工具应被拆掉。
• 引入工具版本与废弃策略：工具名保持稳定，行为变更用描述标注；删除工具前保留一个发布周期并在描述中写明替代项。
• 收敛规模：目标不是工具越多越好，而是让模型在一次任务里只看到它需要的工具集。来源文章提到“把几千行 Swagger 压缩”式的痛点 [3]，本质上就是这一步要做的是契约压缩，不是格式转换。

示意：30 个 REST endpoint 经过任务级归并后，可能收敛为 8 个工具（此表为结构示意，非真实项目数据）。

迁移前（REST endpoint）	迁移后（MCP 工具）	归并逻辑
order/list、order/detail、order/items、order/logistics 等 12 个查询类	order_case_view、order_search	面向“查案”任务聚合
approve、reject、transfer、comment 等 9 个流转类	approval_propose、approval_explain	写操作收口，最终确认留给人
user/get、dept/tree、role/list 等 5 个	who_am_i、dept_scope_query	服务于权限自检
report/export、report/stat 等 4 个	report_run（长任务 + 进度通知）	长任务走流式

4.3 阶段三：权限内化

这是与“只做格式转换”的分水岭。接口层鉴权回答“这个调用方能不能访问这个服务”，工具级权限回答“这个 Agent 在当前上下文下能不能做这个动作、对哪些对象做”。

• 权限从路径级下沉到工具级，再下沉到参数级：approval_propose 不仅要求“可发起审批”，还要校验 order.dept_id 是否在调用者职权范围内。
• 引入风险分级：只读工具自动执行，写操作限流，破坏性操作必须触发人工确认。
• 引入环境隔离：生产环境的写工具默认关闭，启用需要单独审批和更细的审计。
• 把授权决策做成可测试的策略代码，而不是散落在 handler 里的 if 判断。

4.4 什么时候不要迁移

以下场景应继续以 REST/gRPC 为主，MCP 至多作为只读补充：

• 服务间高频、低延迟、强一致的同步调用：模型推理开销会成为纯负担；
• 对外公共 API：契约稳定性、SDK 生成、SLA 与计费都建立在 REST 语义上；
• 事件驱动与流式数据管道：该用消息系统；
• 需要精确事务边界的写入：工具调用的重试与模型决策的不确定性会让事务语义复杂化。

五、风险面：当 Agent 直连 Redis、队列与审批流

5.1 风险清单

工具过度授权。 提供一个 redis_exec 或 sql_execute 式的通用透传工具，等于把 DBA 权限交给模型。模型的幻觉不只表现为“答错”，还可能表现为“调错”——键名写错一位、环境选错一套。

参数注入与越权。 key 模式、队列 topic、脚本内容如果由模型自由填入，就存在拼接注入与横向越权的可能。Redis 接入 MCP 的社区文章描述了让 Claude Code 直接操作缓存与队列的形态 [4]，具体能力与权限机制应以 Redis 官方文档为准，但“直连”本身就意味着攻击面从应用层下沉到了数据层。

不可逆操作与幻觉叠加。 删 key、清队列、批量审批一旦误执行，回滚成本极高。模型的置信度无法作为执行许可。

多 Agent 权限放大。 A2A 式协作中，任务可以在 Agent 之间委派 [1][2]，每个 Agent 可能各自持有工具集，最终效果是权限的串联放大。必须回答：谁发起、谁授权、谁对最终副作用负责。

审计缺口。 如果日志只记“工具 X 被调用”，不记“由哪个用户会话触发、模型基于什么上下文决策、参数来自何处”，事后无法归因，也无法用于合规审查。

可用性风险。 Agent 的重试与并发可能放大后端压力。Redis 队列与锁在高并发场景中本身就是敏感资源，社区实践中已有用队列削峰、消费幂等来保障写入稳定性的做法 [10]，Agent 直连时必须复用同样的保护，而不是绕过它们。

5.2 Redis 场景的正确姿势

不要暴露通用命令通道，而是按场景切分窄工具：

// 反例：透传任意命令，等价于开放管理权限
ToolResult exec(String command, List<String> args);

// 正例：窄工具 + 参数约束 + 幂等 + 审计
ToolResult cacheGet(String key);                       // key 必须匹配白名单前缀，只读
ToolResult queuePush(String queue, String idemKey,     // 队列白名单 + 幂等键，写操作限流
                     JsonNode payload);
ToolResult lockAcquire(String resource, Duration ttl); // 明确超时，禁止无限持有

配套控制：key/队列前缀白名单、写操作速率限制、生产环境默认只读、危险动作需要 dry-run 与人工确认、所有调用写入不可篡改的审计流。缓存与队列的基础语义可参考 Redis 特性实践文章中对 Stream、Lua 脚本、事务等能力的梳理 [9]，但 Agent 接入层必须在其上再加一层约束。

5.3 审批流场景的治理启示

审批流案例主张用纯元数据加 MCP 构建“系统沙箱”，而不是让模型直接调用 approve_order [3]。抛开具体产品不谈，其治理思路值得吸收：

• 变更集预览：模型只能产出“我建议这样改”的结构化变更集，而非直接落库；
• 人工确认门：不可逆动作必须由人确认，模型不能自我授权；
• 元数据约束：字段可写性、状态机合法迁移、组织架构范围都由元数据层校验，不依赖模型自觉；
• 可解释性：每次建议附带依据（引用了哪些单据、哪条规则），便于审计与申诉。

5.4 多智能体编排的额外问题

当 Agent 以 Spring Bean 形式注册、通过事件机制或消息队列协作时 [5]，需要额外回答三个问题：事件消息中的身份信息如何传递而不被伪造；委派链上每个 Agent 的工具权限是并集还是交集；一个 Agent 失控时，编排层能否整体熔断。实践上应把“编排权限”与“执行权限”分开：能发起委派不代表能执行写操作，执行工具时仍需按最终调用主体重新鉴权。

5.5 工具权限矩阵示例

工具	读	写	删	生产环境	需人工确认	限流
cache_get	允许	否	否	允许	否	按 QPS
queue_push	否	允许（幂等键）	否	白名单队列	否	按队列
cache_invalidate	否	否	部分	默认关闭	是	极低
lock_acquire	否	允许	否	允许	否	按资源
approval_propose	否	允许（只产变更集）	否	允许	是	按用户
approval_execute	否	—	—	仅人工界面	是（人执行）	—

5.6 防护型 handler 示意

public ToolResult queuePush(String queue, String idemKey, JsonNode payload, CallContext ctx) {
    if (!queueWhitelist.contains(queue)) {
        return new ToolResult.Fatal("QUEUE_NOT_ALLOWED", "该队列不在允许范围");
    }
    if (!rateLimiter.tryAcquire(ctx.principal() + ":" + queue)) {
        return new ToolResult.Recoverable("RATE_LIMITED", "请稍后重试");
    }
    if (idempotencyStore.seen(idemKey)) {
        return new ToolResult.Ok(Map.of("duplicate", true), "幂等命中，未重复入队");
    }
    if (ctx.dryRun()) {
        return new ToolResult.Ok(Map.of("wouldEnqueue", true), "dry-run：未实际写入");
    }
    domainService.enqueue(queue, payload);      // 复用既有服务层，不直接操作客户端
    auditLog.record(ctx, "queue_push", queue, idemKey);  // 谁、何时、基于什么上下文
    return new ToolResult.Ok(Map.of("queued", true), "已入队");
}

六、上线检查清单与结论

6.1 上线前 checklist

#	检查项	通过标准
1	工具粒度	每个工具对应一个业务用例，不存在通用透传工具
2	描述质量	名称、描述、参数说明足以让模型无需猜测
3	schema 约束	类型、范围、正则、必填项齐全
4	幂等标注	每个工具明确可否重试，写操作带幂等键
5	权限最小化	工具级 + 参数级授权，按调用主体判定
6	人工确认	不可逆/破坏性操作必须人工确认
7	审计完整性	记录主体、会话上下文、入参、结果、依据
8	限流与熔断	按用户、按工具、按后端资源三层限制
9	环境隔离	生产写能力默认关闭，启用需单独审批
10	传输选型	依据网关兼容性与双向通知需求选择并验证
11	错误可恢复性	错误结构区分可重试/不可重试/需人工
12	回退开关	可一键停用 MCP 工具，调用方能退回 REST 路径
13	契约版本	工具有版本与废弃策略，变更有记录
14	后端保护	Agent 调用不绕过既有的锁、队列、事务边界

6.2 结论

MCP 在 Java 后端的定位，可以概括为：面向 Agent 的工具契约层。它与 REST 共存而不是替代——REST 仍是系统间确定性契约、公共 API 与高频调用的主力，MCP 则承担把业务能力以任务粒度、可授权、可审计的方式暴露给非确定性调用方的职责。二者的分界线不在协议，而在调用方的确定性、动作的风险等级，以及是否需要工具粒度的授权。

迁移路径不是推倒重来，而是三步：并行暴露以快速验证任务价值，契约收敛以控制模型认知负担，权限内化以承担 Agent 直连基础设施后的责任。真正决定成败的不是接没接 MCP，而是契约粒度、权限模型与审计链是否同时到位。

值得持续观察的信号包括：MCP 规范在传输与授权方面的演进、Spring AI 后续版本对工具权限能力的内建程度、A2A 与 MCP 在多智能体协作中的职责划分。这些方向在本文所依据的材料中尚无官方定论，落地决策前请以官方文档与规范原文为准。

如果要立刻动手，建议的顺序是：先读 MCP 规范的工具与传输章节；再用最小编排起一个只读工具的 MCP Server，验证 list tools 与调用链路；最后挑一个内部非关键工具做 REST/MCP 双暴露试点，用调用日志反推契约收敛方案。等到审计与权限模型成熟之后，再考虑让 Agent 触达缓存、队列和审批状态机这类高风险资产。

参考资料

[1] Spring Boot 4.1 + Spring AI 2.0：我如何用 Java 微服务把 RAG、知识图谱和 MCP 协议串成一个 Agent 平台，CSDN，https://blog.csdn.net/qq_37980551/article/details/169652600

[2] Spring Boot 4.1 + Spring AI 2.0：我如何用 Java 微服务把 RAG、知识图谱和 MCP 协议串成一个 Agent 平台，掘金，https://juejin.cn/post/7702792613526814771

[3] 干掉笨重的 BPMN！我用 MCP 协议让 AI Agent 安全接管了跨部门审批流，掘金，https://juejin.cn/post/7704429553675321398

[4] Redis 接入 MCP 协议实战：让 Claude Code 直接操作缓存与队列，CSDN，https://blog.csdn.net/weixin_31423955/article/details/166975162

[5] AgentScope 多智能体编排实战：Spring Boot 微服务集成与生产落地，CSDN，https://blog.csdn.net/weixin_32932149/article/details/169758785

[6] 一个 starter 通吃 9 家主流大模型：Spring Boot 3.x + Spring AI 1.x 极简落地，掘金，https://juejin.cn/post/7702736770073133091

[7] 快速搭建 AI 智能体后端：依托星桥 API 统一接入多家大模型，掘金，https://juejin.cn/post/7703007994456424482

[8] Spring Framework 7.1 Release Notes（预览页），spring-projects/spring-framework Wiki，GitHub，https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-7.1-Release-Notes

[9] Redis 核心特性与应用实践全解析，CSDN，https://blog.csdn.net/weixin_32642109/article/details/169494329

[10] Redis 分布式锁 + 队列削峰：SpringBoot 秒杀防超卖实战，CSDN，https://blog.csdn.net/weixin_31714129/article/details/169063244

注：以上均为社区文章与项目 Wiki 页面，其中涉及的版本号、产品能力与方案主张为作者自述或预览内容，本文未能逐项与官方发布记录、MCP 规范原文及产品官方文档核对，引用时已在正文相应位置标明来源性质与不确定性。