Southblock'Blog

✅深入理解MCP技术原理（中）MCP 数据层的标准化 什么是 JSON-RPC 协议？所有工具都必须用统一的格式描述自己——包括工具名、使用说明、参数结构、返回格式等。 这种描述不是随意写的，而是采用严格的 JSON 格式。智能体在连接 MCP Server 的第一步，就是向其索要所有工具的说明书。这一步在 MCP 中被称为“初始化”，对应一次标准的 JSON-RPC 请求。智能体无需关心工具是谁写的，也无需去理解其内部逻辑，只需要根据“说明书”就能让大模型进行决策判断，并最终发起调用。另外，工具的执行返回也遵循同样的标准格式，因此智能体无需适配不同工具的返回值，也不需要写任何特殊逻辑。 只要按标准写了工具说明书，任何工具就能被任何智能体直接使用，不需要额外的集成成本。 JSON-RPC 就是两个服务之间通过发送 JSON 数据来进行沟通的一种“通用语言”。 **RPC (Remote Procedure Call)**：就是指远程过程调用。它的核心思想是：我在 A 服务上调用一个函数（比如 getWeather()），但实际上这个函数是在 B 服务上运行的，B 把结果运行完再传回给 ...

✅深入理解MCP技术原理（上） 在上一节中，我们已经弄清楚了 MCP 的设计初衷：它要解决智能体中“工具混乱、硬编码、难以复用、扩展代价大”等问题。 而 Function Call 的问题在于：工具被硬编码绑定在智能体内部，每个智能体都得自己背着一整套自定义的工具箱去工作，任何工具换环境、换智能体都得重写接入逻辑，扩展复用几乎无从谈起。 因此就产生了两个关键问题： MCP 是怎么做到把工具从智能体里拆出来的？ 它又是通过什么机制，让工具变成了真正意义上的标准化？ 这一节，我们就要从原理出发，逐一回答这些“为什么”。 为什么 MCP 必须是协议，而不是框架？理解 MCP 的第一原则就是： 它不是一个 SDK，也不是一个框架，而是一种协议约定。 这背后的核心原因只有一个： 真正的复用，一定发生在框架之外。 只要工具被绑定在某个 SDK 或某个框架内部，它就无法脱离该框架供其他智能体使用。 你写一个 Java SDK，Python 智能体怎么用？ 工具要实现可移植、可复用、可组合，唯一办法就是： 把工具做成一个任何人、任何语言、任何框架都能访问的“独立能力端点”。 因此，MCP 的本 ...

✅什么是MCP？  MCP，全称是 Model Context Protocol（模型上下文协议）。它是由 Anthropic 开源，旨在解决大模型与外部世界“沟通不畅”的问题。 首先需要理解的是：它不是一个具体的框架或技术，而是一个通用开源标准协议，用于安全、高效地连接智能体应用与外部工具。其核心理念就是赋予智能体应用类似 USB 接口的功能：只需遵守统一的协议，就能标准化地调用各种外部工具，从而实现即插即用。你完全可以把 MCP 理解为是智能体连接外部工具的 USB 接口。  比如，以前如果你想让大模型读取你的数据库，你必须为这个特定的智能体写一段专门的 function call 代码。如果你换一个智能体，这代码可能就得重新写一遍。现在有了 MCP 后，你只需要把数据库的一些列操作包装成一个 MCP Server。任何支持 MCP 的客户端（如 Claude Desktop, Cursor，Cline等）都能直接连接上这个server使用工具，无需重复造轮子。 借助MCP，工具都遵循统一的调用协议，智能体则能够更加丝滑地与外部工具交互。社区中已经公开了大量可用的 MCP ...

✅实战：仿PDD自动帮买家申请退款目标：针对用户反馈的商品质量问题，自动帮买家发起退款。如果是其他问题，则作为客服安抚用户。  需要用到技术： 1、提示词工程+提示词模板 2、Function Call 3、Spring AI 4、对话记忆 5、流式输出 6、结构化输出  提示词工程+提示词模板 角色定义：你是一名专业的电商平台客户体验专家，你的核心职责是高效、准确地处理用户关于商品的反馈。你的首要任务是敏锐识别用户对商品质量的严重不满，并在确认后立即主动为用户申请退款，以最大化客户满意度和信任度。  FewShot：例如：“根本没法用”、“是坏的”、“有瑕疵”、“质量太差了”  COT：我们规定了LLM的第一步、第二步、第三步做什么。  123456789101112131415161718192021# Role你是一名专业的电商平台客户体验专家，你的核心职责是高效、准确地处理用户关于商品的反馈。你的首要任务是敏锐识别用户对商品质量的严重不满，并在确认后立即主动为用户申请退款，以最大化客户满意度和信任度。# Task请严格遵循以下步骤与用户进行对话：第一步：主动识别与确 ...

✅Spring AI中的Tool Calling怎么实现的前面几节都是用Function Call或者Function Calling来介绍的，因为工具使用最开始在OpenAI提出的时候就是叫Function Calling的，所以这么叫的更多。  这一篇为啥改成Tool Calling了呢，因为在SpringAI中，一开始是提供了一套Function Calling的API的，但是在正式版发布的时候，废弃了，都改成Tool Calling了。  那么，Tool Calling在Spring AI中是如何支持的呢？  实现原理 之前在讲Function Call的时候提过，大模型自己不会调用工具，他只是决策什么时候、调用哪个工具、参数是什么。  而工具的调用是交由用户进行的，而我们这里的”用户”——Spring AI帮我做了工具调用的事情。如下图是Spring AI官方给的一张图，也和我们的说法是一致的，是Spring做的工具调用，而不是模型。    当我们想要使工具对模型可用时，我们在聊天请求中包含其定义。每个工具定义包括名称、描述和输入参数的架构。 当模型决定 ...

✅使用Spring AI做Function Call前面介绍过了Function Call的主要概念和用法之后，深入Spring AI，看看在Spring AI中如何做工具调用。 已有方法转成工具假如，现在我已经有个现成的服务了，我想把他变成一个Function（Tool），可以这样做： 123456@Configurationpublic class FunctionCallConfiguration { @Bean @Description("根据用户输入的时区获取该时区的当前时间") public Function<TimeService.Request, TimeService.Response> getTimeFunction(TimeService timeService) { return timeService::getTimeByZoneId; }} 也就是定义一个Bean，返回值是Function类型，构造函数中的参数是一个我们已经有的Spring中的服务 ...

✅如何定义一个好的Function（Tool）？想让模型会调用工具，就需要先定义好工具，他才知道调用哪个，但是模型怎么知道该调用哪个工具的呢？这就需要我们在定义工具的时候遵守一些原则，让模型可以更好地理解这些工具了。 给大家分享一些经验，按照这个标准来定义工具会让你少踩很多坑。  函数名称、描述、参数描述要清晰明了。在我们之前自己写代码的时候，定义一个接口的时候，不太关注注释的，对于方法的作用以及入参、出参很少描述的很清楚。主要是因为这些方法使我们自己写代码调用，虽然注释不清楚，但是自己能清楚就行了。 可是如果是让大模型决策模型调用的话，如果方法名称，参数描述不写清楚的话，大模型肯定是不知道他具体的作用的。所以一定要描述清楚这个方法是干什么的，每一个参数的作用和格式都要写清楚。  扁平化的参数结构尽量避免参数的多层嵌套，因为参数的嵌套都是通过json来描述的，如果层级比较多，很容易就搞错了。所以，尽可能扁平化的平铺参数。  不要有太多参数虽然我们建议扁平化参数，但是也要控制参数的数量，千万不要特别多参数，函数参数的数量最好不超过 3-4 个。尤其是一些默认的参数，这些就不要定义在 ...

✅什么是Function Call?因为大模型自身存在着局限性，无法获取一些最新的信息，无法获取私域知识等，那么，我们就可以通过function calling（也称为tool calling)的方式使大模型可以和外部交互，从而访问训练数据之外的数据。  比如我问大模型今天的天气如何，模型肯定是没有这部分数据训练过的，根据前面讲过的大模型的原理，他的输出结果一定是错的。而如果我们提供一个函数（工具）给他，那么就可以通过函数（工具）调用的方式获取今天的天气信息。  后面我们的介绍，为了方便，不管是Function，还是Tool，还是说函数，还是工具，都是一回事儿。  但是一定要注意，函数调用听上去好像是模型自己会调用工具，但其实并不是。在Function Calling中，大模型并不负责函数的调用和执行，大模型的作用是根据用户的问题，理解用户的需求，然后根据用户需求确定具体需要调用哪个函数以及函数所需要的参数是什么。  function call过程如下面这张图，其实是OpenAI给出的函数调用的过程，可以看到，最关键的函数的执行调用，其实是靠开发者来进行的，也是需要借助我们的应 ...

✅Spring AI & Spring AI Alibaba & Langchain4j Column 1 Column 2 Column 3 Column 4 能力 LangChain4j Spring AI Spring AI Alibaba 是否依赖 Spring ❌ 可独立使用 ✔️ 深度集成 ✔️ 深度集成 模型调用复杂度 ✔️ 支持高层次API，快速实现LLM调用 ❌只支持ChatModel和ChatClient ✔️ 除Spring AI功能外，有更多增强API 结构化输出 ✔️ 强（JSON Schema） ✔️ 基础支持 ✔️ 增强版 RAG 支持 ✔️ 全链路 ✔️ 基础 ✔️ 企业级增强 智能体（Agent） ❌ 需手动实现 ❌ 需手动实现 ✔️ 基于Graph实现了ReAct，支持 Multi-Agent等。 工作流编排 ⚠️ 简单 Chain ❌ 无 ✔️ Graph 引擎（核心优势） 阿里云集成 ✔️ Qwen/DashScope ❌ 无官方支持 ✔️ 深度集成（百炼、OSS、Nacos） ...

✅LangChain4J中实现持久化记忆我们之前也介绍过LangChain4j中的记忆，但是也是介绍的基于内存短期记忆，利用LangChain4j也能做持久化的记忆，但是官方没给现成的实现，只能靠我们自己实现。  在LangChain4j中，有一个内置的ChatMemoryStore接口，可以用它来扩展实现内存记忆。  这个接口中定义了删、改、查等接口： 1234567public interface ChatMemoryStore { List<ChatMessage> getMessages(Object memoryId); void updateMessages(Object memoryId, List<ChatMessage> messages); void deleteMessages(Object memoryId);} 有了它之后，就可以自己扩展，使用MySQL或者Redis等其他数据库来做保存了。如： 1234567891011121314151617181920212223242526272 ...