Function Call、Tool、MCP大模型工具调用三件事一、大模型缺什么二、Function Call让大模型学会“下命令”三、Tool自带描述和干活逻辑的方法四、完整流程本地 Tool五、为什么执行完还要回传大模型六、Tool 多了的麻烦七、MCP让第三方自己提供 Tool7.1 核心思路7.2 两方各自做什么7.3 SDK 是什么在哪用7.4 我们怎么写代码两种方式八、MCP 配置实战8.1 配置文件8.2 框架启动时自动做了什么8.3 大模型该怎么调还怎么调8.4 调用流程九、有无 MCP 对比十、演变总结十一、速记卡一、大模型缺什么大模型能做的大模型不能做的回答学过的东西查实时天气理解你给的文章调你的 API翻译、润色操作你的文件它缺“手”和“眼”需要工具帮忙。二、Function Call让大模型学会“下命令”大模型不直接说人话而是输出一段 JSON告诉程序“我要调用哪个函数参数是什么”。普通对话Function Call“您可以打开天气 App 看北京天气”{function:get_weather,city:北京}格式谁定的大模型厂商内置好的你不用教它。填什么内容大模型根据你给的“工具菜单”和用户的话自己匹配工具、提取参数。三、Tool自带描述和干活逻辑的方法Tool 就是一个方法包含两部分Tool 里有什么作用给谁看描述部分名称、功能描述、参数定义告诉大模型“我能干嘛、需要什么参数”大模型执行逻辑方法体里的代码真正干活的代码调 API、跑脚本程序自己用 Java 写一个本地 ToolTool(nameget_weather,description查询指定城市的实时天气)publicStringgetWeather(ToolParam(description城市名称)Stringcity){return天气API.query(city);// 执行逻辑}组成部分代码里写的作用名称get_weather大模型在 JSON 里填这个名字描述“查询指定城市的实时天气”大模型据此判断能不能用参数city城市名称大模型知道要传什么执行逻辑调天气 API大模型不关心程序自己跑四、完整流程本地 Tool天气API大模型应用程序用户天气API大模型应用程序用户1. 发送工具列表Tool 描述2. “查北京天气”3. 转发用户的话4. 匹配 get_weather5. {“function”:“get_weather”,“city”:“北京”}6. 解析执行 get_weather7. 调 API8. {“temp”:25,“weather”:“晴”}9. 回传原始数据10. 润色11. “北京今天晴天25度”12. 展示一句话大模型点菜JSON程序炒菜执行方法大模型上菜润色。五、为什么执行完还要回传大模型程序拿到的是原始数据不会“说人话”。原始数据用户期待的回复{temp:25,weather:晴}“北京今天晴天25度体感舒适。”角色负责Tool 执行逻辑动手拿数据大模型动脑判断 动嘴润色六、Tool 多了的麻烦早期每接一个第三方服务都要手写一个 Tool。服务开发者要做什么天气手写 Tool 封装 APIGitHub手写 Tool地图手写 Tool本质问题我们在替服务方写 Tool。七、MCP让第三方自己提供 Tool7.1 核心思路第三方服务按统一标准封装接口我们直接连不用替它写 Tool。类比MCP 之前买电器送裸线自己接插头MCP 之后电器出厂自带标准插头直接插7.2 两方各自做什么角色做什么用什么第三方服务方把自己的 API 封装成 MCP 服务MCP 官方提供的 SDK我们配置连接地址直接调用配置文件里写 URL7.3 SDK 是什么在哪用SDK软件开发工具包是 MCP 官方提供的一套现成工具包给第三方服务方用的。第三方用这个 SDK可以把自己的服务比如 GitHub API快速变成一个标准的 MCP 服务端暴露一个 URL 出来。SDK 是第三方用的不是我们用的。我们的 Java 程序不需要引入 MCP SDK只需要配一个 URL。7.4 我们怎么写代码两种方式方式做法适用场景本地手动封装自己写Tool方法方法体里调第三方 API第三方没提供 MCP 接口MCP 配置连接在配置文件里写 URL框架自动拉取第三方提供了 MCP 服务端如果第三方提供了 MCP 服务我们选第二种零代码。八、MCP 配置实战8.1 配置文件假设有三个第三方服务都提供了 MCP 接口spring:ai:mcp:client:connections:github:type:STREAMABLE_HTTPurl:https://github-mcp.example.com/mcpweather:type:STREAMABLE_HTTPurl:https://weather-mcp.example.com/mcpemail:type:STREAMABLE_HTTPurl:https://email-mcp.example.com/mcp有多少个 MCP 工具就配多少个connections节点。不需要为每个工具写 Java 类。8.2 框架启动时自动做了什么1. 读取配置文件里的 MCP 连接列表 2. 逐个连接 MCP 服务端 3. 从每个服务端拉取它提供的工具描述 4. 把这些工具描述合并到本地 Tool 列表中 5. 把完整的工具列表发给大模型你不需要手动写任何代码去拉取、合并、发送。框架全自动完成。8.3 大模型该怎么调还怎么调大模型眼里所有工具都一样不区分是本地的还是 MCP 远程的。它照样输出 Function Call{function:github_search,arguments:{query:AI agent}}框架收到后自动判断这个工具来自 MCP走 MCP 协议远程调用拿到结果回传大模型润色。8.4 调用流程MCP服务端第三方大模型应用程序用户MCP服务端第三方大模型应用程序用户1. 启动时自动拉取 MCP 工具合并到工具列表发给大模型2. “搜索 GitHub AI 项目”3. 转发4. {“function”:“github_search”,“query”:“AI agent”}5. 框架自动走 MCP 协议请求远端6. 返回结果7. 回传润色8. 最终回复9. 展示九、有无 MCP 对比对比项没有 MCP有 MCP接一个工具要写多少代码一个完整的Tool类一行 YAML 配置接十个工具十个Tool类十段 YAML 配置工具更新维护改代码重新部署第三方自己更新我们不用动工具列表发给大模型手动收集框架自动合并本地 Tool MCP 工具调用逻辑框架自动框架自动跟本地 Tool 一样十、演变总结阶段核心起点大模型没手没脚Function Call大模型能下命令输出 JSONTool方法含描述和执行逻辑描述给大模型看逻辑自己跑MCP第三方自己封装我们配置 URL 直接用十一、速记卡Function Call 大模型下命令的语法 Tool 描述给大模型看 执行逻辑自己跑 MCP 第三方用官方 SDK 封装服务我们配 URL 直接连 本地 Tool 和 MCP 工具的关系 大模型眼里都一样 框架自动合并一起发给大模型 调用流程不变 SDK 给谁用 第三方服务方用用来封装 MCP 服务端 我们不用我们只配 URL