Spring AI学习笔记(四)工具调用和MCP

发表于 2026-05-29 22:24 1487 字 8 min read

Spring AI学习笔记(四)工具调用和MCPSpring AI学习笔记(三)RAG从文档入库到回答Spring AI学习笔记(二)ChatClient从怎么调到怎么封装Spring AI学习笔记(一)它到底解决什么问题java新版本-java25学习笔记(四)用JFR和GC日志做一次体检java新版本-java25学习笔记(三)虚拟线程要和资源边界一起看java新版本-java25学习笔记(二)运行时基线先统一java新版本-java25学习笔记(一)LTS版本对比和学习路线主流AI Agent能力对比与工程选型我用Kiro做了个自己的工具站盘一盘虚拟线程我用Trae做了个AstrBot的AI角色扮演插件Python初学笔记(六)常用标准库先学这几个Python初学笔记(五)读写文件和处理异常Python初学笔记(四)函数让代码开始有结构Python初学笔记(三)条件、循环和推导式Python初学笔记(二)变量和基础类型比想象中重要Python初学笔记(一)先把环境和运行方式弄明白主流AI大模型能力对比Java 21和Spring Boot 3升级笔记(五)日志指标与可观测性Java 21和Spring Boot 3升级笔记(四)数据访问层适配Java 21和Spring Boot 3升级笔记(三)虚拟线程使用边界Java 21和Spring Boot 3升级笔记(二)Jakarta迁移要点Java 21和Spring Boot 3升级笔记(一)工程基线整理How Can We Tolerate Magic Values! Major Overhaul of JPA Specification!处理生僻字乱码:JPA框架对于Oracle的NVarchar2,NChar,NClob类型支持Redis Stream能不能当轻量消息队列用RocketMQ 5学习笔记:普通消息之外要看什么事件流不是换个消息队列这么简单Kubernetes学习笔记04:发布、排障和观测Kubernetes学习笔记03:配置、密钥和存储Kubernetes学习笔记02:Deployment、Service和IngressKubernetes学习笔记01:Pod和控制器mysql索引原理02--存储引擎索引的实现mysql索引原理01--索引的数据结构
This post is not yet available in English. Showing the original.
  模型只回答文本时,它像一个会说话的助手。模型能调用工具以后,它就开始接近一个能办事的助手。   工具调用和 MCP 已经是 AI 应用里很重要的方向。Spring AI 也在这块提供了支持,让 Java 后端可以用更熟悉的方式把业务能力、安全边界和模型连接起来。  ...

前言

  模型只回答文本时,它像一个会说话的助手。模型能调用工具以后,它就开始接近一个能办事的助手。

  工具调用和 MCP 已经是 AI 应用里很重要的方向。Spring AI 也在这块提供了支持,让 Java 后端可以用更熟悉的方式把业务能力、安全边界和模型连接起来。

  但这件事必须谨慎。让模型调用工具,本质上是把后端能力暴露给一个概率系统。边界设计不好,就可能查错数据、执行错动作,甚至绕过权限。

工具调用是什么

  工具调用可以理解为:后端声明一组函数,模型在需要时选择调用。

比如用户问“我的订单到哪了”,模型发现需要查询订单状态,于是调用getOrderStatus工具。工具返回结构化结果,模型再把结果整理成人能读懂的话。

这比单纯让模型猜答案可靠很多。因为订单状态来自业务系统,不是模型编出来的。

但工具调用也带来风险。模型可能传错参数,可能在不该调用时调用,也可能尝试调用高权限能力。

所以工具不是后门,而是一组受控接口。

先从只读工具开始

  第一版工具调用,我建议只做只读工具。

比如:

1.查询订单状态。 2.查询库存余量。 3.查询知识库条目。 4.查询工单进度。 5.计算价格规则。

只读工具就算调用错了,通常也不会改变业务状态。

工具输入输出要用明确 DTO:

public record OrderStatusRequest(String orderNo) {
}

public record OrderStatusResponse(
        String orderNo,
        String status,
        String latestTrace) {
}

不要直接把数据库实体暴露给模型。实体字段太多,里面可能包含不该返回的信息。

参数校验和权限不能省

  模型传给工具的参数,本质上是外部输入。

订单号格式、用户 ID、日期范围、分页大小,都要校验。

if (!orderNo.matches("A-Z0-9")) {
    throw new IllegalArgumentException("订单号格式不正确");
}

权限也必须按当前用户计算。用户只能查自己的订单,运营只能查自己权限范围内的数据,租户之间不能串。

AI 入口不能绕过原来的权限系统。工具执行时,应该和普通接口一样走鉴权、数据权限和审计。

有副作用的工具要二次确认

  修改业务状态的工具要更谨慎。

比如取消订单、创建退款、发送通知、修改资料。这类动作不能让模型直接执行。

更稳的方式是两段式:

1.模型生成操作计划。 2.用户确认后,系统执行真实业务接口。

比如用户说“帮我取消这个订单”,模型先整理出订单号、取消原因和影响范围。前端展示给用户确认。用户点确认后,后端再调用取消订单接口。

这样模型负责理解意图,业务系统负责最终执行。

MCP 解决什么

  MCP 可以理解为模型和外部工具之间的一种标准连接方式。

如果每个模型、每个工具都写一套私有协议,集成会很乱。MCP 的价值是让工具能力以统一方式暴露出来,让模型客户端可以发现、调用和管理这些能力。

对 Java 后端来说,MCP 的意义不是追概念,而是可以把已有系统能力包装成可被 AI 客户端使用的工具。

比如内部知识库、工单系统、订单系统、监控系统,都可以提供受控工具能力。

Spring AI 的 MCP 支持让这件事更贴近 Spring 工程习惯。

MCP 服务也要按后端标准做

  MCP 服务不是玩具服务。

如果它连接真实业务系统,就必须按后端服务标准治理:

1.认证。 2.授权。 3.参数校验。 4.限流。 5.审计。 6.日志。 7.监控。 8.版本管理。

不要因为它服务的是模型,就降低标准。恰恰相反,因为模型调用更不确定,边界更应该收紧。

工具描述要像接口文档

  模型能不能正确调用工具,很依赖工具描述。

工具名、用途、参数含义、返回含义、限制条件都要清楚。不要起一个query,参数叫id,然后期待模型完全理解。

好的工具描述应该告诉模型:

1.这个工具什么时候用。 2.它不会做什么。 3.参数格式是什么。 4.返回结果代表什么。 5.失败时如何处理。

这其实就是给模型看的接口文档。

观测和审计必须有

  工具调用一定要记录。

至少记录:

1.用户。 2.会话 ID。 3.工具名。 4.参数摘要。 5.调用结果。 6.耗时。 7.是否产生副作用。

如果工具会修改业务状态,还要记录业务单号、确认人和执行结果。

出了问题以后,必须能回答:谁触发了什么,模型为什么选择这个工具,工具实际做了什么。

小结

  Spring AI 在工具调用和 MCP 能力,让 Java 后端可以把模型和业务系统更自然地连接起来。

  但连接不是放开权限。工具要像接口一样设计,只读先行,参数校验、权限控制、返回范围、审计日志都不能省。有副作用的动作要二次确认。

  MCP 的价值在于标准化连接方式,而不是让模型获得无限能力。后端要做的,是把能力包装成清晰、可控、可观测的工具。

If you enjoyed this, leave a comment~

© 2019 - 2026 VincentHo @VincentHo
Powered by theme astro-koharu · Inspired by Shoka