先说结论这套组合我真的实测过别只看网上那些“概念先行”的文章。SpringBoot 3.X 配合 Spring AI 把 MCP 协议集成进来用 SSE 作为传输通道最终效果就是你写一个普通的 Java 方法大模型在对话中能根据用户意图自动去调用它然后基于返回值继续生成回答。整个过程不需要你手动拼接 Prompt不需要自己维护 Function Calling 的 Json Schema工具注册、参数校验、结果回传全是框架帮你扛。这篇文章就围绕“SpringBoot 3.X Spring AI JDK 17 集成 MCP 协议通过 SSE 协议供大模型调用”这条完整链路来展开。我会先讲清楚为什么是这套技术选型再给出可以直接抄作业的工程配置最后把我踩过的坑、排查过的诡异问题一并交代清楚。适合正在做 AI Agent、准备把现有 Java 业务能力开放给大模型的开发者也适合刚接触 MCP 但已经有点 Spring Boot 基础、想直接上手的同学。1. 这次集成到底在做什么1.1 从一次真实的接入需求说起我接手这个需求时的场景是这样的公司内部有一个订单查询服务核心逻辑已经写在 Spring Boot 的老项目里了。现在想做一个内部 AI 助手让员工直接对机器人说“查一下订单 A10086 现在到哪一步了”机器人需要自己去调订单服务再把查询结果自然语言化地回复给员工。传统做法是写 Function Calling手动给模型声明函数名、参数描述、JSON Schema然后自己处理模型返回的 function_call再自己拼第二轮对话。这套东西每加一个函数就要碰一遍而且还跟具体模型厂商的格式绑定。后来换了 MCP 协议整个思路就变了MCP Server 自己暴露“工具”和“资源”大模型通过 MCP Client 动态发现有哪些工具可用然后按协议发起调用。我这边只需要把订单查询方法用注解标一下剩下的注册、参数映射、结果回传全部交给 Spring AI。项目标题里提到的几个关键词SpringBoot 3.X、Spring AI、JDK 17、MCP 协议、SSE 协议恰好就是这条链路的全部要素。很多人会问为什么不直接用 Spring AI 自带的 Tool Calling因为那只是 Spring AI 内部的工具抽象如果想要把工具能力标准化地暴露给外部的大模型平台或者被多个不同的 AI 客户端复用那 MCP 才是统一语言。MCP 解决的是“工具能力怎么发布和被发现”的问题Spring AI 解决的是“大模型怎么方便地调用这些工具”的问题两者一结合就是一套标准的 Agent 工具基础设施。1.2 为什么必须用 JDK 17 而不是 8 / 11先说一个大多数人踩过的坑Spring Boot 3.X 从底层上就放弃了 Java 8 和 Java 11Spring Framework 6 要求 JDK 17 起步这是硬性门槛不是配置一下 source/target 就能糊弄过去的。如果你在 pom.xml 里把 spring-boot.starter.parent 升到 3.x但本地 JAVA_HOME 还指向 JDK 8编译时会直接报错甚至有些类在扫描阶段就加载失败。我当时的处理方式是腾出一台专门的构建机装的是 JDK 17并在 IDEA 和 Maven 里都统一指定 toolchain。对于 Windows 环境直接下载 JDK 17 的 zip 包解压然后配置JAVA_HOME和PATH就行。Linux 环境下我用的是 tar.gz 方式安装路径放在/opt/java/jdk-17然后在/etc/profile里写 export 配置。需要注意一点如果你的机器上还装了 JDK 8 的老项目不要让全局 PATH 指向 17最好在 IDEA 的 Project Structure 里按项目指定 SDK否则老项目动不动就给你来一个 UnsupportedClassVersionError。另外一个和模块相关的原因JDK 17 自带的强封装和模块化约束让 Spring 和它在底层字节码生成上配合得更顺。虽然 JDK 21 现在也很成熟但 Spring Boot 3.2 / 3.3 系列对 17 的支持是最稳妥的网上教程也多出了问题容易搜到解决方案。所以项目标题里写的是“jdk17以上版本”我的建议就是新项目直接 JDK 17不要太激进上 21除非你有充分的性能测试依据。2. 先捋清楚MCP、SSE 和 Spring AI 到底是什么关系2.1 MCP 不是又搞一个 RPC 标准MCP全称 Model Context Protocol它的定位是给 AI 应用提供标准化的“上下文接入协议”。你可以把它理解成 USB-C 接口——不同设备数据库、文件系统、业务系统、第三方 API通过同一个标准接口接入电脑大模型应用。以前的 AI 应用要接一个数据源就得写一套私有代码接十个数据源就得维护十套集成代码有了 MCP数据源方只需要实现一个 MCP ServerAI 应用通过 MCP Client 就能统一发现和调用。我在学习这个概念的时候习惯把它拆成两块看一块是“资源”也就是给模型提供上下文数据另一块是“工具”也就是让模型主动发起动作。Spring AI 集成 MCP 主要是把“工具”这部分打通因为工具调用才是真实业务场景里最常遇到的问题。MCP 协议底层是基于 JSON-RPC 2.0 的所以工具定义、参数校验、返回结果都有一套标准结构不像私有 Function Calling 那样各家有各家的格式。2.2 SSE 在 MCP 里扮演的角色SSE即 Server-Sent Events是 HTTP 协议上的一种服务端单向推送机制。它跟 WebSocket 的主要区别在于WebSocket 是双向全双工SSE 是服务端到客户端的单向流式传输。MCP 早期规范里定义了两种传输方式一种是 stdio适合本地进程之间通信比如 Claude Desktop 直接拉起一个本地 Node 进程另一种是 HTTP SSE适合远程部署也就是我们这次讲的场景。实践里面SSE 模式的实际交互更像“一长一短两条通道”客户端通过一个普通的 HTTP 端点向 MCP Server 发送 POST 请求请求体是 JSON-RPC 格式的消息比如initialize、tools/call服务器端开启一个 SSE 流把endpoint信息、响应消息、工具执行结果都通过这个流推给客户端。这个设计的好处是充分利用了 HTTP 的普及性不需要像 WebSocket 那样升级连接中途也能靠 HTTP 的缓存、代理等机制调试。缺点也很明显如果服务器和客户端在不同网络环境需要把两条 URL 都放通往往就在这里开始踩坑。2.3 Spring AI 把最后的胶水活也干完了Spring AI 是 Spring 官方生态里的 AI 应用开发框架。它做的事情简单说就是把“和模型对话”这件事抽成了ChatClient、ChatModel这些稳定接口底层可以切换 OpenAI、Ollama、通义千问等各种模型提供商。而它从 1.0.0-M 版本开始引入的 MCP 支持又进一步把“模型调用工具”的流程封闭起来。我在没有接触 Spring AI 之前自己写过一版对接逻辑先用 RestTemplate 去调模型接口解析出 function_call 参数然后反射调用本地方法再把结果拼进 messages 数组。这套流程理论上能跑但每换一个模型、每加一个工具都要改动一块代码。Spring AI 的做法是你只负责定义好带注解的工具方法然后在构建ChatClient时把 MCP Client 塞进去当用户提问被模型判定为需要工具时Spring AI 会自动回调 MCP Client由 MCP Client 通过 SSE 去远程调用 MCP Server 暴露的工具并把结果带回模型的下一轮上下文里。所以从业务开发者的视角看你几乎感觉不到跨协议的调用过程只看到最终 AI 给出了基于工具结果的回答。3. 环境准备和基础工程搭建3.1 JDK 17 的安装与多版本共存策略如果你已经装好了 JDK 17这步可以跳过但我还是想啰嗦两句因为这个环节比想象中更容易出问题。Windows 上我建议直接下载正式的 JDK 17 安装包或者 zip 免安装包解压后放到一个不含中文和空格的路径比如D:\dev\jdk-17。然后设置系统变量JAVA_HOMED:\dev\jdk-17在Path最前面加一行%JAVA_HOME%\bin。设置好之后打开新终端执行java -version看到openjdk version 17.0.x才算通过。Linux 上我这边用的是 tar.gz 包步骤大概是sudo mkdir -p /opt/java sudo tar -zxvf jdk-17_linux-x64_bin.tar.gz -C /opt/java sudo update-alternatives --install /usr/bin/java java /opt/java/jdk-17/bin/java 100 sudo update-alternatives --config java然后把/opt/java/jdk-17/bin加到 PATH。这里有个经验如果你的生产服务器是内网环境千万别现场下载提前把安装包传上去。我们有次在内网机器上装 JDK下载链接直接被安全策略拦掉了最后只能走审批流程申请离线包。还有一个非常容易被忽略的细节Maven 编译时用的 JDK 和运行时 JDK 必须一致否则可能编译产物是 class 版本 61对应 JDK 17但运行环境是 JDK 11启动直接报java.lang.UnsupportedClassVersionError。我习惯在 Maven 的~/.m2/settings.xml里用 profile 指定 JDK或者直接在 pom 里写死maven.compiler.source和maven.compiler.target为 17从源头杜绝版本错乱。3.2 创建 SpringBoot 3.X 工程时要注意的点这一步最大的坑是版本号对应关系。Spring AI 的 MCP 模块迭代非常快不同版本对 Spring Boot 版本、Java 版本的要求都有差异。我用的组合是 Spring Boot 3.3.5 Spring AI 1.0.0整体比较稳定。如果你用 Spring Boot 3.2.x 去配 Spring AI 1.0.0也会有一些兼容问题建议直接用下面这套parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.3.5/version relativePath/ /parent然后引入 Spring AI BOMdependencyManagement dependencies dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-bom/artifactId version1.0.0/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement有人认为只需加一个 spring-ai-starter-mcp-server 相关依赖就行但实际项目里最少还得分两种模块一种是被外部大模型调用的“MCP Server 端”另一种是作为大模型客户端的“MCP Client 端”。如果既想体验完整链路又想尽快跑通可以把 server 和 client 放在两个独立服务里或者用不同 profile 加载。3.3 依赖怎么加各个 starter 都是干什么的假设我们按照“两个服务”的方式来组织一个叫 mcp-server-order负责暴露订单查询工具一个叫 ai-chat-gateway负责对接大模型并作为 MCP Client 连接 mcp-server-order。MCP Server 端需要的核心依赖dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-mcp-server-webmvc/artifactId /dependencyMCP Client 端需要的核心依赖dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-mcp-client/artifactId /dependency如果你要对接的是 OpenAI 兼容接口的大模型还需要加模型依赖dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId /dependency这里用一个类比帮助理解spring-ai-starter-mcp-server-webmvc负责把 Spring MVC 应用变成一个 MCP Server并开启 SSE 端点spring-ai-starter-mcp-client负责在另一个应用里创建 MCP Client通过 SSE 去连接远程 Serverspring-ai-starter-model-openai负责接入具体的对话模型。三者各管一段缺一不可。4. 服务端实现把 Java 方法变成 MCP 工具4.1 服务端配置与 SSE 端点设计先看配置文件。spring-ai-starter-mcp-server-webmvc这个 starter 引入之后Spring Boot 的自动配置会帮忙创建 MCP Server 相关的 Bean。我用的最小配置是这样server: port: 8080 spring: ai: mcp: server: name: order-mcp-server version: 1.0.0 transport: webmvc sse: endpoint: /mcp/sse这里面有两个关键点。第一个是transport: webmvc它代表使用 Spring MVC 作为底层 Web 框架来承载 SSE 连接。如果你用的项目是 WebFlux那应该配置成webflux依赖也要改成spring-ai-starter-mcp-server-webflux。第二个是sse.endpoint这是 MCP Server 对外暴露 SSE 流的地址客户端连接的时候就是从这个地址去发起长连接的。启动服务后你可以直接访问http://localhost:8080/mcp/sse正常情况下浏览器的响应会一直处于 pending 状态并且陆续收到事件流。首次连接时服务端会推送一个 event里面带着一个 client 会用来发送 POST 请求的 endpoint 路径一般是类似/mcp/message?sessionIdxxx的形式。这种“先建立 SSE再动态获取消息发送地址”的模式是 MCP HTTPSSE 传输的核心机制。4.2 用 Tool 注解暴露真实业务方法这里我直接用订单查询这个场景来举例。先写一个普通 Spring Bean方法上用Tool注解做标记Service public class OrderQueryTools { Tool(description 根据订单号查询订单当前状态和物流进度) public String queryOrderStatus(ToolParam(description 订单号) String orderId) { // 这里调用实际的订单服务 OrderInfo orderInfo orderService.findByOrderId(orderId); if (orderInfo null) { return 未找到订单 orderId; } return String.format( 订单【%s】当前状态%s物流进度%s最近更新时间%s, orderId, orderInfo.getStatus(), orderInfo.getLogistics(), orderInfo.getUpdateTime() ); } }然后需要让 Spring AI 识别这个工具。一般情况下把工具类注册成 Bean 并提供一个ToolCallbackProvider给 MCP Server 用即可Configuration public class McpServerConfig { Bean public ToolCallbackProvider orderQueryTools(OrderQueryTools orderQueryTools) { return MethodToolCallbackProvider.builder() .toolObjects(orderQueryTools) .build(); } }这里特别说明一下Spring AI 的 MCP Server 自动配置会从容器里收集ToolCallbackProvider然后把它管理的工具注册到 MCP 协议里。注册完成后MCP Client 就能通过tools/list请求拿到这个工具的 name、description、parameters 等元数据。而Tool注解里的 description 内容会直接映射成大模型判断“要不要调用这个工具”的依据所以描述要写清楚最好包含触发条件和参数含义。一个常见的误解是必须用McpToolDefinition之类的专属注解。不同版本确实存在不同注解但最通用、最不容易出错的组合就是ToolMethodToolCallbackProvider它在 Spring AI 的文档里长期有效。你只要保证Tool方法的参数个数合理、类型简单就能顺利转换成 JSON Schema。如果你在工具里抛了异常Spring AI 默认会把异常信息传给大模型让模型知道这个工具调用失败了这点对排查问题很有用。4.3 启动、验证工具列表是否正常服务端启动后第一步先别急着连大模型而是用 curl 或 Postman 验证 MCP 协议本身通不通。由于 MCP 的 SSE 模式不是一个简单的 REST 接口手动验证稍微麻烦一点但至少可以确认 SSE 端点是否正常响应curl -N -H Accept: text/event-stream http://localhost:8080/mcp/sse如果看到类似event: endpoint和data: /mcp/message?sessionId...的输出说明 SSE 通道已经建立成功。接下来更省事的办法是直接用 MCP 官方调试工具用 mcp-remote 连接远程服务器或者直接拿 Spring AI 的 MCP Client 做集成测试。如果你只是想快速验证我建议在测试类里写一个简单的客户端SpringBootTest class McpClientSmokeTests { Test void testToolsList() throws Exception { McpClient client McpClient.sync( HttpSseClientTransport.builder(http://localhost:8080/mcp/sse).build() ).build(); client.initialize(); ListToolsResult tools client.listTools(); System.out.println(tools.tools()); client.close(); } }这个测试脚本能直接打印出工具列表如果这里能看到queryOrderStatus说明服务端注册成功如果这里就报错那根本不用往下排查大模型那边的问题。我个人习惯把这条链路当作“服务端自检”每次改完工具都要跑一遍因为它能快速暴露 JSON Schema 转换、Bean 注册等低级错误。5. 客户端实现让大模型真正开始“使唤”工具5.1 客户端与模型配置现在到最关键的部分让大模型通过 MCP Client 去调用刚才那个订单查询工具。我在实际项目里把“客户端”单独做成了一个服务因为这样职责清晰MCP Server 负责工具实现客户端服务负责对话和调度。如果是一个小 Demo也可以放到同一个服务里不过你得注意区分自动配置避免一个服务既当 Server 又当同名的 Client导致连接混乱。客户端的application.yml大致如下server: port: 8081 spring: ai: openai: base-url: http://localhost:11434/v1 api-key: ollama chat: options: model: qwen2.5:7b mcp: client: sse: connections: order-server: url: http://localhost:8080/mcp/sse我这边对接的是本地 Ollama 启动的 Qwen 模型因为它跟 OpenAI 接口兼容SaaS 大模型又很容易涉及密钥和外网访问问题本地模型更适合拿来调试。如果你的业务环境允许也可以把base-url改成 OpenAI 官方或者其他厂商的兼容地址。这里值得单独说一下spring.ai.mcp.client.sse.connections的结构connections 下面可以配置多个远程 MCP Server每个 server 用一个自定义名称作为 key然后指定它的 SSE URL。Spring AI 会自动创建对应的McpClientBean并把它注册成ToolCallbackProvider。所以只要你配置了这个路径框架就会在构建ChatClient时把这些远程工具一并带进去。5.2 通过 ChatClient 把用户问题变成工具调用在客户端代码里我先构建一个ChatClient然后就可以直接聊天了Service public class AiOrderAssistant { private final ChatClient chatClient; public AiOrderAssistant(ChatClient.Builder builder) { this.chatClient builder .defaultSystem(你是一个订单查询助手用户问订单状态时必须使用工具查询不能凭经验回答。) .build(); } public String ask(String userMessage) { return chatClient.prompt() .user(userMessage) .call() .content(); } }这段代码看起来普通但背后发生的事一点不普通用户消息进入之后Spring AI 会把当前可用的工具列表包括远程 MCP Server 上的queryOrderStatus一起发给大模型模型判断这个问题需要调用工具就会返回一个 tool call 请求Spring AI 收到后通过McpClient走 SSE 请求mcp-server-order的/mcp/message接口把真实订单数据拿回来然后 Spring AI 再把工具结果塞回消息上下文让模型生成最终回答。所有这几步在业务代码层面都被封装进了chatClient.prompt().call()里。有一个点必须强调工具调用的成败和模型的能力很有关系。有些小模型虽然支持 OpenAI 格式的 function calling但在面对多个工具时可能选错参数、编造结果。我给系统提示词里写了“必须使用工具查询不能凭经验回答”这样能显著降低模型瞎编订单号的概率。生产环境还可以加一层校验比如模型返回的结果里如果带了订单号先校验格式再决定要不要走工具。5.3 完整调用链路的日志验证当你在浏览器或者 Controller 里发起一个请求比如“帮我查一下订单号 ABC123 的状态”日志里应该能看到几条关键记录大模型返回的 assistant message 里带有tool_calls内容是queryOrderStatus参数是{orderId:ABC123}。Spring AI 调用了 MCP Client 的callTool方法请求发到了http://localhost:8080/mcp/message?sessionIdxxx。MCP Server 那边执行了OrderQueryTools.queryOrderStatus方法。工具结果返回之后模型有第二轮输出内容是“订单 ABC123 当前状态是已发货物流进度……”。如果你发现第 1 步就没有 tool_calls说明模型没有被正确告知工具存在大概率是客户端配置漏了远程 Server 地址或者工具描述写得太模糊。如果第 2 步报错先检查 SSE 连接是否还能正常维持再检查两个服务之间是否有防火墙挡着。我把这些问题的排查方法统一放到下一节。6. 常见问题与排查技巧实录6.1 工具列表拿到了但模型就是不调用这是最让人抓狂的问题。我排查过的案例里十有八九是工具描述不够具体。大模型决定是否调用工具主要看description和参数 schema。如果你的描述写成“查询订单”模型很可能判断用户问“我的快递到哪了”跟这工具无关如果你改成“根据订单号查询订单当前状态和物流进度适合在用户询问物流、配送、签收状态时使用”模型就会更愿意触发。还有一种情况是模型本身不大支持 function calling。我最初用某个 3B 小模型测试时它几乎每次都不输出 tool_calls后来换上 7B 模型就正常了。所以如果你的模型比较小建议先换一个大一点的模型验证链路确认全通了再考虑压缩模型。最后检查一下系统提示词。如果系统提示词里写了“你是一个通用助手不要使用任何工具”那模型当然不会调。把提示词改成鼓励使用工具、并且明确工具结果优先能解决一大堆“不调用”的问题。6.2 SSE 连接断连和 HTTP 超时SSE 长连接在真实网络环境下容易受到代理、网关的影响。常见表现是客户端日志里出现Connection closed、EOFException或者隔一段时间第一次调用没问题第二次就超时。我这边遇到最典型的一个案例是Nginx 默认的 proxy_read_timeout 是 60 秒而 SSE 流可能几分钟没有任何数据于是被 Nginx 主动掐断。解决方案是在 Nginx 配置里调大超时同时关闭缓冲location /mcp/sse { proxy_pass http://localhost:8080; proxy_set_header Connection ; proxy_http_version 1.1; proxy_read_timeout 3600s; proxy_buffering off; proxy_cache off; chunked_transfer_encoding off; }另外要注意SSE 模式下 MCP Client 实际上既有一条持续连接的 GET 流也会有主动发消息的 POST 通道。如果只放通了 SSE 端点没有放通/mcp/message客户端就会出现“能初始化但调不了工具”的诡异现象。我习惯先在客户端服务里把目标 Server 的地址配置成内网 IP 来排除代理问题全部调通之后再切到公网域名。6.3 Java 类型和 JSON Schema 转换的坑用Tool注解暴露方法时Spring AI 会通过反射读取方法签名然后生成 JSON Schema。如果你写了比较复杂的参数类型比如一个自定义对象包含嵌套 List、MapSpring AI 的自动转换不一定完全符合预期。我在项目里吃过一次亏工具方法参数是一个OrderQueryRequest对象里面有LocalDateTime字段生成的 JSON Schema 类型异常导致模型传参时出现了字符串时间无法解析的问题。规避办法工具方法的参数尽量使用基本类型和 String如果需要传结构就把结构拆成多个 String 参数让模型自己去填。这样生成的 Schema 简单模型调用成功率更高。如果你确实需要对象参数记得给每个字段加ToolParam的 description帮助模型理解格式。还有一个容易忽略的细节不要把工具方法命名为get、execute这种过于泛化的名字否则可能出现 Bean 方法解析冲突或者模型在多工具场景下选错。命名要体现业务语义比如queryOrderStatus、createRefundRequest这也是在帮助模型做判断。6.4 JDK 版本冲突与 Maven 编译错误这类问题集中在刚迁移到 Spring Boot 3.X 的老项目上。报错最常见的是java: invalid source release: 8或者UnsupportedClassVersionError failed to load class ...。原因基本都是 IDEA 的 Project SDK、Maven 的JAVA_HOME、pom 里的java.version三者不一致。我的排查顺序很固定先确认JAVA_HOME再确认 IDEA 里 File - Project Structure - Project SDK最后看 pom.xml 里的 properties。properties java.version17/java.version maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target /properties如果你用的是 Maven Wrapper还要确认~/.m2/wrapper/dists里下载的 Maven 版本不会影响 JDK 检测。这个坑比较隐蔽有一次我换了 Maven 3.9 之后编译突然开始用默认的 JDK 8后来在MAVEN_OPTS里显式指定了 JAVA_HOME 才解决。另外Spring Boot 3.X 的自动配置比较多如果项目里同时引入了旧版的javax包大概率会跟jakarta命名空间冲突。MCP Server starter 依赖的是 EE 9 之后的jakarta.*老代码里如果有javax.servlet.Filter之类的东西启动时会出现找不到类的错误。最干净的方案是把老代码的 API 包升级到 jakarta 版本或者单独拆一个干净的 MCP 模块避免历史包袱。7. 最后再分享几个实在建议这套集成方案跑通之后我最大的感觉是MCP 确实把“工具接入”从手工作坊推进到了标准化时代但它的实际价值取决于你工具设计的质量。工具描述写得清晰模型调用就准确工具边界划定得清楚Agent 的稳定性就高。别想着一个服务把所有业务都暴露成 MCP 工具先从一个高频、低风险的查询类场景开始再逐步扩展。实际操作中还有两件事值得做一是给 MCP Server 加简单的权限校验尤其是通过 SSE 暴露在内网之外时至少要做 API Key 或者 OAuth 的验证否则任何能访问端点的人都能调用你的业务工具二是做好方法级监控埋点在工具方法里记录耗时和成功失败状态方便后续优化模型参数或者工具实现。我在日志里给queryOrderStatus加了耗时统计之后才发现模型连续调用工具时真正耗时的不是接口本身而是两次 SSE 握手的时间后来通过复用连接就明显改善了不少。如果你现在正在把已有的 Java 服务接入大模型我的建议是从这套组合开始JDK 17 Spring Boot 3.3 Spring AI 1.0先跑通一个查询工具再逐步把创建、修改类操作加进来。这个方向现在资料已经比较齐全照着本文的思路踩几遍坑你就能搭出一套稳定、可扩展的 Agent 工具层。