《AI MCP Gateway 网关服务系统》第3-25节实战：LLM 对接测试 Streamable HTTP 接口，如何完成三件事的端到端验证

文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载导读本节是 AI MCP Gateway 网关服务系统对 Streamable HTTP 协议的收口验证章节。在前序章节已经完成 Streamable 协议基础能力开发的基础上本节通过三件事把能力跑起来验证GET / POST / DELETE三个 HTTP 入口是否可用、验证会话管理语义是否符合 Streamable 协议不再下发 SSE 的 endpoint 事件、验证 LLM 侧能否通过 Streamable HTTP 方式对接网关并完成工具调用。读完本节你将掌握一套可复用的 MCP 网关双协议SSE Streamable验证思路以及如何从协议语义层面区分两套传输机制。一、本章诉求Streamable 能力不是写出来而是真的能用起来前面章节中网关已经完成了 Streamable HTTP 协议的基础能力开发协议分析见 第2-5节streamable协议应用分析测试案例见 第3-22节streamable-http-api测试验证案例并通过 case 层与 domain 层的串联完成了协议编排见 第3-24节通过case和domain串联出Streamable协议。而本节要做的事情就是把这套能力真正验证起来主要完成三件事验证 Streamable HTTP 服务接口是否可用包括GET / POST / DELETE三个入口验证会话管理语义是否符合 Streamable 协议重点确认不会再像 SSE 一样发送 endpoint 事件验证 LLM 侧是否可以通过 Streamable HTTP 方式对接网关并完成工具调用。只要这三件事跑通就说明前面做的协议适配不是停留在代码层面而是真正可以在生产链路上被 LLM 使用。二、Streamable HTTP 与 SSE 是两套不同的协议语义不能直接混用本节验证工作的一个核心前提是Streamable HTTP 与 SSE 虽然都和 MCP 会话相关但它们是两套不同的协议语义。这一点在协议设计与验证时必须格外注意不能把 SSE 的处理逻辑直接套用到 Streamable 上。从 第2-4节streamable协议应用案例 的协议对比可以看到Streamable HTTP 的核心特征包括基于普通 HTTP 请求服务器可按需升级为 SSE 流式响应不强制长连接统一通过/message协议层通信支持 stateless无状态模式与现有基础设施兼容性好是对 HTTP SSE 的渐进式改进。而从 第3-24节 对两套协议差异的总结可以提炼出四个关键差异点这也是本节验证工作的观察重点差异维度SSE 协议Streamable HTTP 协议会话创建方式通过 GET 请求创建会话通过 POSTinitialize请求创建会话会话传递方式通过 SSE 事件流传递通过响应头Mcp-Session-Id返回会话 ID会话监听方式GET 请求即创建即监听GET 请求只负责监听已有会话不创建新会话端点事件会发送 endpoint 事件不发送 endpoint 事件避免破坏协议语义正因为存在这些差异网关在实现时把 sse、streamable 拆成了两套处理路径而不是在一套逻辑里堆if···else这一点在下一节展开。三、Streamable HTTP 的通信流程回顾同一个端点GET / POST 各司其职在进入验证细节之前先回顾 Streamable HTTP 的通信过程详见 第2-5节streamable协议应用分析。Streamable HTTP 采用单端点通信设计同一个接口方法如/mcp下通过 GET、POST 两种方法类型分别承担不同职责。步骤 1POST - 初始化通过 POST 请求传递 method 标识为initialize的初始化消息服务端创建sessionId并写入响应头Mcp-Session-Id。sessionId用于标记通信生命周期类似信贷审批、协议签约这类长流程业务中的会话标记。步骤 2GET - 建立监听拿到sessionId后以同一个接口的 GET 方式建立 SSE 连接用于数据传输。POST 是拿到批文GET 是建一条通信监听管道后续服务端需要主动推送的消息如通知、采样请求都通过这条 SSE 管道推送给客户端。步骤 3POST - 业务请求管道建立完毕后初始化完成确认、资源查询、工具列表查询tools/list、工具调用tools/call等操作都通过 POST 请求发送到服务端响应结果通过步骤 2 建立的 SSE 连接发送回客户端。因此本节验证GET / POST / DELETE三个入口本质上是验证这套单端点通信机制的完整闭环POST 负责创建会话与业务请求GET 负责监听已有会话DELETE 负责会话的结束与资源释放。四、功能设计把 Streamable 接入网关服务的验证链路本节的功能设计围绕Streamable HTTP 协议对接 LLM 服务的整体关系展开核心动作有三步把 Streamable HTTP 协议真正接入到网关服务验证链路中验证服务不再是只支持 SSE而是可以按协议方式选择走 Streamable调整会话管理逻辑让 Streamable HTTP 走它自己的协议语义——通过 POSTinitialize创建会话、通过响应头Mcp-Session-Id传递会话 ID、GET 只监听已有会话、不发送 endpoint 事件而不是继续沿用 SSE 的 endpoint 下发方式在 LLM 侧增加 Streamable 工具回调策略让模型也可以通过 Streamable 协议去加载 MCP 服务从而完成对网关能力的端到端验证。从 DDD 分层架构看这套设计延续了前序章节domain 核心领域不动case 层重新编排的思路。正如 第3-24节 所述对于一个新逻辑的引入不会废弃 domain 核心领域即积木而是在 case 层进行新的逻辑编排搭积木最后提供对应的接口服务。这样既保证了领域模型的稳定性也让新协议接入的成本可控。五、验证第二件事的关键会话管理语义与 case 层编排会话管理语义的验证是本节最容易出问题的地方因为它涉及两处代码层面的兼容设计详见 第3-24节 与 第3-23节调整case层结构设计处理不同方式的mcp实现1. case 层IMcpMessageService 泛型化与 InitializeNode 分支在 mcp 服务的 case 编排下原本有IMcpSessionService、IMcpMessageService两个接口类各自只有一套对应 sse 服务的实现。调整后做了两件事IMcpMessageService需要添加泛型因为 sse、streamable 返回的类型不一样泛型化之后才能在同一套接口框架下承载两种协议的差异化返回执行步骤与 sessionId 的使用位置不同sse、streamable 创建和使用 sessionId 的地方不一样。Streamable 的会话只是获取 sessionId消息处理中要单独拿出InitializeNode分支来完成会话的创建和初始化消息的处理——因为 Streamable 是通过 POSTinitialize创建会话的而不是像 SSE 那样在 GET 建立连接时创建。2. domain 层SessionManagementService 的类型区分领域层的会话管理服务SessionManagementService也需要做一小部分兼容动作。createSession方法在 sse 下会直接创建messageEndpoint调整后需要通过新增加的枚举SessionTransportTypeEnumVO来区分传输类型sse / streamable之后再按类型创建对应的会话结构。这样一来验证第二件事的通过标准就很明确调用 Streamable 入口时会话通过 POSTinitialize创建并以Mcp-Session-Id响应头返回GET 请求只负责监听已有会话整个交互过程中不会出现 SSE 那种 endpoint 事件下发会话创建逻辑正确走InitializeNode分支。六、验证第三件事的关键LLM 侧的 Streamable 工具回调策略第三件事的验证依赖 LLM 验证服务。网关在 domain 领域层实现了一个 LLM 服务能力详见 第3-20节验证服务LLM对接测试MCP接口其核心设计是动态构建含有 MCP 服务的对话模型MCP 的加载来自于接口层传入的gatewayId网关 ID按网关 ID 做动态加载而不是写死某个 MCP 服务支持是否重新加载因为网关配置是不断动态调整的所以流程上会有一个是否重新加载的操作重新加载的目的就是把 MCP 动态地刷新配置。在本节中LLM 侧在原有 SSE 回调的基础上增加了Streamable 工具回调策略让模型可以通过 Streamable HTTP 方式去加载 MCP 服务。验证时通过网关选择、认证key选择、是否重新加载等参数发起对话对应 第3-21节验证服务LLM对接测试MCP界面 的页面能力即可观察 LLM 是否走 Streamable 通道完成 tools/list 的工具发现和 tools/call 的工具调用。七、三件事的验证路径与通过标准把本章诉求的三个验证目标与验证动作对应起来可以整理成如下检查清单验证目标验证动作通过标准服务接口可用性分别调用 Streamable 入口的GET / POST / DELETE三个入口均返回预期响应无 4xx/5xx 错误会话管理语义观察会话创建与监听过程会话由 POSTinitialize创建通过Mcp-Session-Id响应头传递GET 仅监听已有会话全程不发送 endpoint 事件会话创建走InitializeNode分支、类型由SessionTransportTypeEnumVO区分LLM 工具调用通过 LLM 验证服务发起对话走 Streamable 回调策略LLM 成功加载 MCP 工具并完成 tools/list、tools/call 的完整调用闭环八、验证完成后的下一步衔接本节验证完成后Streamable HTTP 与 SSE 两套协议的开发和验证就全部完成了第3-26节分布式服务设计redis 对此有明确说明。接下来网关要解决的是单实例内存 Map 会话在分布式场景下的局限多实例部署下的会话数据共享、会话变更同步、服务重启恢复。这属于基础设施先行的后续演进与本节的协议验证解耦——先让协议能力真的能用起来再为它在分布式环境下的稳定性打地基。小结本节通过三件事完成了 Streamable HTTP 协议的端到端验证GET / POST / DELETE入口可用性、会话管理语义尤其是不再发送 endpoint 事件、以及 LLM 侧通过 Streamable 工具回调策略完成工具调用。验证过程中最需要把握的是 Streamable 与 SSE 的协议语义差异——它们都服务于 MCP 会话但会话创建、传递、监听方式完全不同不能混用。结合 case 层的IMcpMessageService泛型化、InitializeNode分支和 domain 层的SessionTransportTypeEnumVO类型区分网关在不废弃核心领域模型的前提下完成了双协议能力的编排与验证这也体现了 DDD 架构下领域积木复用、case 层灵活编排的设计价值。赞分享文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载相关推荐《AI MCP Gateway 网关服务系统》第3-14节实战解析 Swagger 标准 OpenAPI 协议把 HTTP 接口一键导入为 MCP 网关协议《AI MCP Gateway 网关服务系统》第3 14节实战解析 Swagger 标准 OpenAPI 协议把 HTTP 接口一键导入为 MCP 网关协议文档教程后端AI MCP Gateway 网关自测服务LLM 大模型对接 MCP 接口的动态加载设计与接口包装AI MCP Gateway 网关自测服务LLM 大模型对接 MCP 接口的动态加载设计与接口包装 本篇围绕 AI MCP Gateway 网关服务系统的验文档教程后端Zoom Phone Smart Embed CRM 集成实战基于 OAuth、Phone API 与 Webhook 构建 CRM 通信工作流Zoom Phone Smart Embed CRM 集成实战基于 OAuth、Phone API 与 Webhook 构建 CRM 通信工作流 导读 本文围文档教程后端上一篇IPED元数据伪造检测识别篡改文件的终极指南下一篇GyroFlow视频稳定工具从安装到专业使用的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考