德刑君

《AI MCP Gateway》第1-1节：网关需求分析

大家好，我是技术UP主小傅哥。

今天是我们 《AIMCPGateway网关服务系统》 项目学习的第1节课程，小傅哥会带着大家，以互联网公司正规的承接产品需求到开发部署上线的流程，带着大家以第一主人公视角的方式进行学习。这样既可以保证你学习到项目内容，也能了解到公司里正规的开发模式，以后进入到公司也可以很好的融入团队，承接项目需求。加油💪🏻！让我们开启新项目之旅！

一、本章诉求
站在产品视角，分析 AI MCP Gateway 网关服务系统，这样一个产品功能需求的背景、诉求和目的。

需求是怎么来的呢？

作为互联网公司里的研发，我们通常都是从业务产品经理那承接需求，评审 PRD 文档，之后研发进行详细设计，给出设计文档在评审，评审通过后开始进入编码开发，以及推进后续的测试和上线。

那么，还有一类需求是不需要业务产品经理的，往往是纯技术产品经理或者研发和技术一起驱动的，这类的需求包括，系统的重构、组件的设计、框架的升级等。他们虽然也是需求，但不直接影响到产品经理的业务需求，所以往往由技术产品或者研发推动。

所以，像是 AI MCP Gateway 网关服务系统，是附属于 AI 应用开发部门的项目，一般是由 AI 技术产品经理推动，这类产品经理，往往比纯业务产品经理要多一些技术储备的。虽然他们编码不熟练，但对技术是有不错的储备，可以很好的规划和推进技术产品。

二、项目背景
MCP 协议的定义和发布，改变了我们使用 AI 的形态。

LLM 大模型第一次以 chatgpt 问世时，就足以震撼到我们。它具备各行各业的知识储备，可以识别人类语言，可以完成逻辑关系推理。在很长一段时间里，我们都是把问题抛给大模型，大模型回答后，我们在根据它的回复，复制粘贴到具体的场景进行处理。

但大模型不能无中生有，不能根据你的提问，直接帮你完成最终的处理。如；帮我查询最近一天内数据库账户表写入的数据量，这是做不到的，因为大模型并不能直接连接到我们的数据库或者其他任何服务。

在 2023 年前，如果想让大模型和程序代码互动，我们经常做的方式是写提示词，告诉大模型我的程序具备什么样的能力，有什么样的接口格式，你需要分析我的问题，并按照最终的执行给出结构化参数。json 格式为 {“function”:”query_user_account”,”arguments”:{“sc”:”渠道值”}} 之后再根据大模型的结果调用对应的程序方法。不过以上方式执行起来的误差较大，经常是需要慢慢微调提示词。

到了 2023年6月，OpenAI 发布 gpt-3.5-turbo-0613 模型，给 API 的调用提供了 Function Calling 的能力，只需要在请求 API 的时候传入 functions 参数，告知大模型本地有哪些函数方法可以被调用使用即可。到了 2023年11月，gpt-3.5-turbo-1106 发布，这回开始支持 tools 函数，我们可以在提问的时候，进行网络检索，天气对接。但是这些功能代码， 都被嵌入到大模型调用中，编写起来耦合在一块，维护起来很麻烦。

直至到2024年11月，Anthropic 发布了 MCP 协议，将 tools 的封装单独抽离到独立的服务，这种服务称之为 MCP 服务，然后通过远程协议的模式提供给大模型调用。而 MCP 协议的主要作用是将服务转换为可以被大模型识别的格式结构（后面章节会细分析 MCP 协议）。

MCP为何重要？

MCP 在构建或与 AI 应用程序或代理集成时减少了开发时间和复杂性。

MCP 提供对数据源、工具和应用程序生态系统的访问，这将增强功能并改善最终用户体验。

MCP 可产生功能更强大的 AI 应用程序或代理，它们可以在必要时访问您的数据并代表您采取行动。

自从有了 MCP 协议以后，市面上开始出现各类的 AI Agent 智能体服务，如被大家熟知的 Dify、Corz、Trae.ai/Cursor 等。这些都是通用的智能体服务，可以解决市面上大部分通用场景问题。

到这以后，各个公司开启了自己的 AI Agent 智能体实现，对公司里自身业务场景进行提效。如账户服务、交易订单、计息计罚、还款计划等，做成智能客户和AI运营工具，都可以为企业提效。那么这里就有一个问题，这些接口想被大模型识别，就要开发为 MCP 协议服务，只有 MCP 协议才能被大模型识别的协议，公司里的各项服务要想被大模型调用，就要编写为一个个的 MCP Server 服务端，这个工作量是非常大的。

所以，为了解决需要把大量接口开发成 MCP 协议服务的工作，我们可以设计一个 MCP 网关服务系统。它的核心工作原理在于，设计实现一套 MCP 协议的统一服务入口，管理和使用动态化注册的 HTTP/RPC 服务接口。MCP 协议的接口会被接入 MCP 服务的大模型，进行调用，核心过程包括；建立sse连接创建会话ID、初始化服务、获取 tools 工具列表、响应工具调用。这些内容，小傅哥会在后续的协议分析中带着大家学习。

综上，当我们有了一套 MCP 网关以后，就可以把我们各项所需的接口，快速🔜转换为 MCP 协议，配置给 AI Agent 智能体系统进行使用啦。这也是我们本次课程的最终目的。

三、产品方案

1. 产品概述
   AI MCP Gateway 是一个基于 Model Context Protocol (MCP) 的智能网关服务系统，专为 AI 智能体应用提供高性能、可扩展的 MCP 实时通信基础设施。解决 AI 应用与各种数据源、工具和服务之间的连接复杂性，提供统一的接口和协议标准。

2. 技术架构
   

首先，核心目的为，为 AI 客户端的 MCP 服务协议使用诉求，提供便利性。后端服务接口可以在 MCP 网关进行注册，提供 MCP 协议类型接口。

之后，整个实现过程是以 MCP 协议 JSON-RPC2 通信结构，设计实现流式传输 Streamable HTTP 框架，完成 MCP 网关接口协议解析和消息处理。在消息处理过程中，则对注册进来的 http/rpc/… 接口进行调用。这部分会包括接口的描述性信息获取以及会话执行调用。更多细节会在后续的设计和编码中陆续体现

3. 功能流程
   

首先，是网关服务的注册，这部分提供管理端由用户进行接口配置注册操作，注册时把接口 http/rpc 进行详细拆解，录入到数据库中。在服务启动时，可以把接口进行服务加载，放到请求池中，等待调用。

之后，是 mcp 协议的2个调用过程，一个 {gatewayId}/mcp/sse 建立连接，创建出 sessionId 进行服务关联。首次建立连接后，会返回一个 /gd10090/mcp/message?sessionId=c2db-f64 之后在请求返回的地址，进行调用。

最后，在请求 {gatewayId}/mcp/message 进行消息处理，完成 initialze、tools/list、tools/call、resources/list，步骤调用。这些步骤需要从网关服务注册进来的接口中获取，而 tools/call 则是发起 http/rpc 接口调用。

《AI MCP Gateway》第1-2节：系统建模设计

一、本章诉求
按照 AI MCP Gateway 网关功能实现诉求，对系统服务进行建模设计。包括；用例图、四色建模拆解、工程模型分析。

二、架构选型
此项目会选择 DDD 领域驱动设计的方式，进行系统建模和功能设计。那为啥选择 DDD 架构呢？

因为 DDD 架构的四色建模方法可以更好的分析场景需求模型，同时它对应的六边形架构设计，非常合理的划分了微服务的各项单元功能。如；http、redis、mysql等都有自己的分层规划，同时又为领域服务与基础设施层的设计做了依赖倒置（这样的思想在Spring源码中很多），当我们在领域模块中实现服务时，就可以专心于各个模块的内聚服务了。

三、建模方法
在MVC的系统开发中，是很少做建模的事情的。因为它都是面向过程开发，过程就是一个流程需要什么就编写什么，但随着系统的复杂，会逐步发现，A流程、B流程、C流程，越来越多的流程加入，但这些流程中又存在了交叉、复用。也就是大家看到的 MVC 里的代码，总是一个功能，被复制了好多次，好多地方编写。所以使用 DDD 思想的情况，会对这些内容提前思考，进行建模设计，划分出领域。让一个个单元变得容易管理。

MVC 有点像睡大车店子（大通铺的一个大炕），DDD 划分了每家每户，每个床🛏睡着该睡的人。

DDD 的建模过程，是以一个用户为起点，通过行为命令，发起行为动作，串联整个业务。而这个用户的起点最初来自于用例图的分析。用例图是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，我们可以分析出所有的行为动作。

在 DDD 中用于完成用户的行为命令和动作分析的过程，是一个四色建模的过程，也称作风暴模型。在使用 DDD 的标准对系统建模前，一堆人要先了解 DDD 的操作手段，这样才能让产品、研发、测试、运营等了解业务的伙伴，都能在同一个语言下完成系统建模。

此图是整个四色建模的指导图，通过寻找领域事件，发起事件命令，完成领域事件的过程，完成 DDD 工程建模。

蓝色 - 决策命令，是用户发起的行为动作，如；开始签到、开始抽奖、查看额度等。

黄色 - 领域事件，过去时态描述。如；签到完成、抽奖完成、奖品发放完成。它所阐述的都是这个领域要完成的终态。

粉色 - 外部系统，如你的系统需要调用外部的接口完成流程。

红色 - 业务流程，用于串联决策命令到领域事件，所实现的业务流程。一些简单的场景则直接有决策命令到领域事件就可以了。

绿色 - 只读模型，做一些读取数据的动作，没有写库的操作。

棕色 - 领域对象，每个决策命令的发起，都是含有一个对应的领域对象。

敲黑板 综上，左下角的示意图。是一个用户，通过一个策略命令，使用领域对象，通过业务流程，完成2个领域事件，调用1次外部接口个过程。我们在整个 DDD 建模过程中，就是在寻找这些节点。

四、系统设计

1. 用例图
   用例图（英语：use case diagram）是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。

客户端视角；与 AI MCP Gateway 的交互，配置 MCP 服务后，会进行会话的发起与会话通信的建立。以及在建立会话过程，查看资源、获取资源、调用资源服务。

运营端视角；维护客户端的运营人员，需要完成网关资源的维护，注册服务资源，网关配置，鉴权配置，审核服务等。

这样的用例图，它有点项目目标结果驱动，让你知道最终的产品形态要提供什么功能。所以有这样的一个指导是可以很好的完成后续的建模设计的。

2. 领域划分
   四色建模，指通过四种角色，循环领域事件的过程。四种角色分为；用户（命令）、对象、业务、事件。也就是一个人通过一个命令，携带一个对象，完成一个事件。完成事件的过程会需要使用到对应的聚合的业务。

这部分与用例图的衔接就是，用例图里找到的最终的事件的端点（xxx完成态），通过四色建模完成整个对象的产生过程。

蓝色，决策命令。这里我们找到协议注册、鉴权核验（ApiKey）、协议会话、发起会话、应答会话。

浅黄，领域事件。通过每一个命令完成最终的一个结果态。协议的存储、网关资源的确认、会话的简历、会话的应答。

四色建模完成的故事，是一种软件设计指引，也是思想。这样的思想落地的工程结构甚至可以是三层结构，不过我们在整个实践中发现，六边形架构或者整洁结构，才可以更好的承接 DDD 领域驱动设计完成的建模落地。

3. 工程模型
   对于整个领域，在工程里的划分，我们放到一个模型图里体现下；
   

trigger 是触发器层，我们把所有外部（http、rpc）调用我们，job调用，接收mq调用，都称之为触发动作。

case 是功能编排层，它的出现是为了减轻 trigger 层的压力。原本 trigger 要调用 domain 的领域层的各个方法完成逻辑串联，这部分拆分到 case 层来做处理，让 trigger 的 http 实现，只关心结果的封装和异常的打印。而这里的 case 层会有 mcp 的创建会话、消息处理的操作。后续还会随着功能开发增加其他 case 逻辑。

domain 是领域层，实现各个模块功能，包括；协议、鉴权、会话的处理。会话会有创建会话、查询会话和对会话的应答处理。

infrastructure 是基础设施层，所有资源和外部服务的链接，都会放到这里处理。这里还会实现 domain 领域层在 adapter 适配器内定义的接口，通过依赖倒置的方式实现。

基于以上分析，后续我们将开启系统工程的开发。

《AI MCP Gateway》第1-3节：网关协议表

一、本章诉求
设计 AI MCP Gateway 网关服务，所需的核心必备的数据库表。以用于存储，mcp 到 http 的协议转换处理，如，用户通过 sse 请求指定的网关 ID 对应的服务，则可以调用到对应的 http 服务接口。

二、功能设计
如图，库表驱动下的业务；

首先，以用户为入口，进行网关配置，他关心的是权限，以及配置的 http 怎么映射到 mcp 服务。

之后，mcp 服务对应的 http 接口能力和出入参字段，都需要给出对应的描述，这样 ai 调用 mcp 服务，才能拿到工具列表说明以及进行调用。

三、对照测试
为了让大家更好的理解，要做的 mcp 2 http 协议转换，我们做一个 mcp 服务，同时同出入参功能的设计一套 http 接口。之后来对比看，http 的出入参，在 mcp 协议是怎么映射的。

1. 工程结构

在 ai-mcp-gateway-demo-mcp-server-test 下，提供一个 http 接口，它的出入参和 TestService 这个 mcp 服务是一致的。

你可以进入到 api.curl.sh、api.mcp.json 对比查看数据，来感受下他们的差异。

2. 功能测试
   在咱们 ai mcp gateway 的学习中，我们通过 ai-mcp-gateway-demo-mcp-client-proxy 来分析协议。这里可以打开测试工程，以代理的方式，调用 ai-mcp-gateway-demo-mcp-server-test mcp 服务，拿到协议结构。

这里打开了2个工程，按照步骤启动服务，之后调试代码，来获取 mcp 通信协议结构。这个结构就是我放到 api.mcp.json 里面的数据。

有了这个结构的对比，可以思考到，要怎么设计mcp网关的库表，才能把一个 http 的接口，按照 mcp 的格式结构给组装出来。其实，设计库表的方式也很多，不非得局限到课程里设计。

3. 库表设计
   3.1 网关配置表

这个表负责一个网关的总注册表，在这里可以维护网关的关闭或者开启。

3.2 网关鉴权表

这个表的目的是给 mcp 网关通信协议增加 api_key 进行验证的处理，也可以限制访问频次。

3.3 协议注册表

mcp_2_http 表示从 mcp 到 http 协议的注册，这样的设计是为了以后如果还想扩展其他的，如 mcp_2_rpc、mcp_2_mq 也都非常方便的添加。http、rpc、mq，他们的差异比较大

表名称调整了下，mcp_protocol_registry

3.4 协议映射表

这一个表的作用，是为了映射每一个 http 出入参字段，到 mcp 协议的时候，这些字段的名称描述。

表名称调整了下，mcp_protocol_mapping

《AI MCP Gateway》第1-4节：升级网关库表

一、本章诉求
增强网关库表设计，拆分出工具（tool）、工具协议类型（http），让网关配置可以支持一个网关下多个工具，工具可以绑定和切换到不同的协议上（1:n）。细节上会在 tool 上设计协议类型，以便于扩展支持不同的协议对接。

二、升级设计
如图，从旧版库表升级到新版库表的结构；

旧版的设计中，是有一个 mcp_protocol_registry 协议注册，里面包含了工具描述和 http 接口协议信息。功能理解和编码实现上会比较直观，适合我们最开始让大家上手学习。

新版的设计中，拆分了 tool 工具表，也就是一个网关（mcp_gateway）可以对应多个 tool 表，tool 表可以单独配置对应的协议信息，可以是 http，也可以是其他的。后续扩展的时候增加新的表即可。

三、新表设计

首先，新增设计 mcp_gateway_tool、mcp_protocol_http 表，去掉原有的 mcp_protocol_registry 表。使用 protocol_id 进行衔接，protocol_type 区分协议类型，如果是 http 的，则可以指定到 mcp_protocol_type 表查询，如果将来还有其他的类型，则可以查询其他表数据。

之后，mcp_protocol_mapping 去掉了 http_path、http_location，这部分不需要使用。

最后，整个结构来看，mcp_gateway 就可以 1:n 多个 tool 了，每个 tool 也可以动态的配置到 protocol 上（http 或者其他的）。

四、读者作业
简单作业：理解本节库表的设计的目标和拆分的方式，这个部分内容在以后工作中也会经常出现，在原有的库表上添加字段或者新增加表来解耦流程。

复杂作业：因为原有的功能和新的功能对比，只是库表做了变更，查询方式会有以一些调整。你可以尝试在工程里进行编码。鉴于这部分库表对应的代码实现的内容都是一致的，下一节将以代码评审的方式进行讲解，了解代码变更信息。这样你就可以对照变更信息，来修改你的代码了。

《AI MCP Gateway》第2-1节：MCP服务实现（用于后续协议分析）

进入到第二部分开始，小傅哥会带着大家通过各种手段对 MCP 协议进行细致的实践验证的方式进行分析。这部分包括了实现一个 MCP 服务，完成 MCP 服务的对接，通过代理的方式调试对接中 MCP 接口协议的数据，以及通过开发网页测试工具对接协议等。最后在进行 json-rpc2 定义的协议标准讲解。通过这样一套内容串联，你会对 MCP 有非常强的理解，也能为后面做 MCP 网关实现的学习打下良好的基础。

一、本章诉求
基于 Spring AI 框架，实现一个简单的 MCP 服务，为后续做协议的分析和验证进行使用。

因为协议分析，主要包括了通信的格式结构，如通信的入参，所以实现这样的一个 MCP 服务，会多增加一些入参类型，便于以后做网关设计时使用。

通常来讲，这部分的操作，也可以理解为是技术调研验证阶段。当我们要实现一个大的功能服务时，就要先想办法把复杂的逻辑拆分为独立的细小单元。也就是软件第一设计原则康威定律提到的，问题越小，越容易被理解和处理。所以，当你想在此项目拓展功能，或则自己在公司承接需求的时候，也可以使用这样的方式进行辅助完成系统的详细设计。

二、协议说明（MCP）
文档：https://docs.spring.io/spring-ai/reference/api/mcp/mcp-server-boot-starter-docs.html - 可以阅读官网文档，这里就包含了如何实现 MCP 服务，并提供了小案例。

org.springframework.ai spring-ai-starter-mcp-server

Spring AI MCP（模型上下文协议）服务启动器为在 Spring Boot 应用程序中设置 MCP 服务器提供了自动配置功能。它实现了 MCP 服务器功能与 Spring Boot 自动配置系统的无缝集成。

MCP 服务器启动器提供：

MCP 服务器组件的自动配置

支持同步和异步操作模式

多种传输层选项

灵活的工具、资源和提示规范

更改通知功能

Spring AI MCP 框架是对 MCP 协议的实现，可以把我们实现的服务功能，以 MCP 格式进行转换处理。与我们要实现的 AI MCP Gateway 不同的是，Spring AI MCP 固定的框架，每一个 MCP 都要独立完成开发，而 AI MCP Gateway 是一个通用协议转换的服务，只需要配置就可以完成从接口（http/rpc）到 MCP 协议的转换。

但为了更好的理解 MCP 协议，我们可以先基于 Spring AI MCP 框架，来实现一个简单的 MCP 并陆续完成对接使用，再到协议分析和设计 AI MCP Gateway 网关服务。

三、服务开发（MCP）
jdk 17

Maven 3.8.x

SpringBoot 3.4.3

星球课程入口，编程环境，jdk、maven等软件下载有提供。

1. 工程结构

MCP 协议的实现，可以有2种方式，一种是提供 jar 包的（stdio 模式），本地引入使用。另外一种就是工程案例这种，sse 格式。其实 stdio 模式，只是不用自己启动 SpringBoot 服务，提供响应式接口了。把 jar 给提供出去，别人本地配置引入即可使用。但这样的方式不太适合做统一网关服务，所以我们把重点放到 sse 通信协议形式上。

Spring AI MCP 框架，提供的 MCP 开发方式非常简单，基本就是把自己平常开发的接口，配置上 @Tool 工具注解，之后再通过 Bean 对象，把服务注册进去。这样就可以把 Spring AI MCP 框架中的 webflux 进行管理和使用了。

2. 功能实现
   2.1 对象描述
   @Data
   @JsonInclude(JsonInclude.Include.NON_NULL)
   public class XxxRequest01 {

   @JsonProperty(required = true, value = “city”)
   @JsonPropertyDescription(“城市名称,如果是中文汉字请先转换为汉语拼音,例如北京:beijing”)
   private String city;

   @JsonProperty(required = true, value = “company”)
   @JsonPropertyDescription(“公司信息,如果是中文汉字请先转换为汉语拼音,例如北京:jd/alibaba”)
   private Company company;

   @Data
   @JsonInclude(JsonInclude.Include.NON_NULL)
   public static class Company {

    @JsonProperty(required = true, value = "name")
    @JsonPropertyDescription("公司名称")
    private String name;
   
    @JsonProperty(required = true, value = "type")
    @JsonPropertyDescription("公司类型")
    private String type;
   

   }

}

在 MCP 服务的实现中，你会看到方法的出入参对象，会加入大量的注解描述。因为 MCP 服务最终给 LLM 大模型调用时，会需要获取出调用 MCP 协议服务时候的所需的接口出入参描述。这样 LLM 才能更准确的把这些对象组装出来进行调用。

后面我们在 AI MCP Gateway 网关实现中，配置 MCP 协议接口时，也需要把准确的描述出接口出入参信息。

2.2 定义服务
@Slf4j
@Service
public class TestService {

@Tool(description = "获取公司雇员信息")
public XxxResponse getCompanyEmployee(XxxRequest01 xxxRequest01, XxxRequest02 xxxRequest02) {
    log.info("根据公司和雇员，查询工资和工作工时。{} {}",xxxRequest01.getCompany(), xxxRequest02.getEmployeeName());

    // 这部分可以实际调用你需要的接口，比如调用http接口获取个数据或者做一些操作等。

    XxxResponse xxxResponse = new XxxResponse();
    xxxResponse.setSalary(new Random().longs(10000).toString());
    xxxResponse.setDayManHour(String.valueOf(new Random().nextInt(24)));

    return xxxResponse;
}

}

MCP 服务的实现，其实本身也就是 Spring 中 Service 的实现方式，唯独有差异的地方，就是多增加了一个 @Tool 注解，这个注解可以写入 name - 名称、description - 描述，这些信息页是为了 LLM 大模型调用 MCP 时，先拿到对应 MCP 服务的能力，之后根据用户提问匹配到 MCP Tool 工具的能力。

所以，在我们实现 MCP 或则通过 AI MCP GateWay 网关配置 MCP 的时候，也都要准确的描述服务的能力。这样才能更准确的进行匹配。

2.3 服务配置
@SpringBootApplication
public class Application {

public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
}

@Bean
public ToolCallbackProvider testTools(TestService testService) {
    return MethodToolCallbackProvider.builder().toolObjects(testService).build();
}

}

服务开发实现完成后，还需要把服务注入到 Tool 工具回调提供者中，这个提供的方式在 Spring AI 框架结构的源码中，就可以被自身的响应式接口调用到了。

其实我们实现一个 MCP 网关，和 Spring AI MCP 框架的设计形式也是类似的，不过我们做的是可以动态配置，而不是编码固定写死的方式。

2.4 文件配置（yml）
server:
port: 8701
servlet:
encoding:
charset: UTF-8
force: true
enabled: true

spring:
application:
name: ai-mcp-gateway-demo-mcp-server-test
main:
banner-mode: off

stdio 模式打开，sse 模式，注释掉。

web-application-type: none

ai:
mcp:
server:
name: ${spring.application.name}
version: 1.0.0
type: ASYNC
instructions: “This server provides weather information tools and resources”
sse-message-endpoint: /mcp/messages
capabilities:
tool: true
resource: true
prompt: true
completion: true

logging:

stdio 模式打开，sse 模式，注释掉。

pattern:

console:

file:
name: data/log/${spring.application.name}.log

整个 MCP 服务是按照 sse 的方式进行发布，也就是一个 MCP 的响应是接口。所以这里的配置，都是打开 sse 方式进行发布。

在实现后，可以直接以 SpringBoot 服务的方式进行启动，之后就可以被访问使用了。

四、启动测试

1. 启动服务

2. 访问接口

地址：http://localhost:8701/sse - 访问后可以看到响应信息在浏览器上就可以了

说明：MCP 服务启动后，可以访问 sse 验证响应，它所提供的 data 数据，就是用于另外的一个访问，http://localhost:8701/sse/mcp/messages?sessionId=18ecda95-23c6-407b-ae7b-df26b027b35a 你只需要知道有这么个东西就可以，后续会带着你来做访问的处理。

《AI MCP Gateway》第2-2节：MCP代理调用

一、本章诉求
实现一个 MCP 客户端，用于对接 MCP 服务端，并通过代理 AI 接口的方式完成调用。该方案旨在调试 AI 调用 MCP 过程中的通信的请求接口协议，便于查看和分析相关数据。

二、流程设计

如图，是整个 Ai Client 以 Tools 工具，对接 MCP 的流程结构图。也是 Ai Agent 智能体最基础配置。如果感兴趣 Ai Agent 项目，也可以在星球里学习。

之后，我们要在整个实现过程中，为 Ai 接口，通过 SpringBoot HTTP 方式做一层代理。这样在调用 MCP 的过程中，我们就可以清楚的知道这个过程的协议数据结构了。代理的方式可以用在很多场景，还有一种是浏览器代理的主动安全扫描技术，甚至你服务器的应用暴漏了数据库密码都可以被扫描出来。 扩展知识：安全漏洞扫描，他怎么拿到了我的数据库密码？

三、功能实现

1. 工程结构

proxy-api 定义代理接口，这个接口会被 app 层 config 进行配置实例化。

proxy-trigger 实现 proxy-api 代理接口，这一层要被 app 层的 pom 引入，这样才可以被 Spring 扫描到，实例化到容器。

proxy-app 程序启动入口，之后 ApiTest 层是测试调用 MCP 服务。

2. 代理接口
   2.1 接口定义
   public interface IOpenAiApiProxy {

   @POST(“v1/chat/completions”)
   Single