Spring AI

当运维同事想在 Claude 中查询一笔订单时，他能做的只是把订单 ID 粘贴到聊天框，等待模型回复无法访问数据库，再手动把日志贴回去。这类场景暴露出一个现实问题：企业内部有订单服务、库存服务和日志平台，但 AI 客户端并不能直接触达这些系统。Dev.to AI 的一篇技术文章给出的方案，是用 Spring AI 构建一个 MCP Server，把 Java 端点转换成 Claude 和 Cursor 可以直接调用的工具。按照文章说法，示例代码是一个完整项目，即使没有 LLM API key 也可以运行。对于需要让 AI 调用内部订单或运维 API 的团队，这提供了一个不必逐个修改客户端的接入路径。文章将问题拆开：MCP 不是为了解决“模型不够聪明”，而是解决“模型够不到你的系统”。如果产品经理使用 Claude Desktop 查询数据，后端工程师使用 Cursor 写代码并顺带查看生产订单，自研支持代理也需要查订单，那么三种客户端就意味着三种集成方式。其中，Claude Desktop 需要 MCP 配置，Cursor 需要 .cursor/mcp.json，自研代理需要 JSON Schema 完成 function calling。开发者要为每种客户端写三套描述、三套参数校验和三套错误处理。如果下个月出现第四种客户端，集成工作还要再来一次。MCP 的价值在于把 M×N 变成 M+N：所有 M 个客户端实现同一协议，所有 N 个系统也暴露同一协议，中间不再需要两两配对。文章用充电接口作类比：在 USB-C 出现之前，圆口、扁口、排线各自对应特定设备；接口统一后，充电器只需要供电，手机只需要接收。MCP 在 AI 工具调用中扮演的，就是这种统一接口角色。文章还纠正了两个常见误解。第一，MCP 不是模型能力，而是一种传输协议，和 HTTP 处于类似层级。模型并不知道 MCP 存在，它看到的只是“这里有一些工具，以及这些工具参数长什么样”。真正把 MCP 工具列表转换成模型可理解的 Function Calling 格式的，是 Host。第二，写好 MCP Server 并不意味着模型一定会正确使用它。工具名称、描述和参数文档是否清晰，会直接影响模型选择。例如，一个查询接口如果只写成“query order”，模型在想查用户时也可能调用；如果写成“按订单号查询订单详情；订单号以 SO 开头”，命中率会发生变化。因此，文章强调的重点不仅是“如何暴露 API”，还包括“如何让模型正确调用”。这篇实践文章把 MCP 从协议概念落到了 Java 工程语境。对于已有 Spring AI 和内部 API 体系的团队，真正的变化不在于让模型“更会回答”，而在于把订单、库存、日志等系统以统一方式暴露给多个 AI 客户端。这也把接口设计的要求前移了。过去，API 文档主要给人看；在 MCP 场景中，工具描述还要给模型看。命名是否准确、参数说明是否足够具体、错误返回是否可被理解，都会影响 AI 是否能正确执行任务。对于需要在 Claude、Cursor 和自研控制台之间复用内部能力的团队来说，MCP Server 更像是一层新的接口治理。

Spring AI 通过工具调用循环和代码控制流程图，为 Java 生态构建企业级 AI Agent 提供了一条可控路径。