MCP网关的实践

前言：

企业落地 MCP 的核心挑战与 Higress 网关的系统性解决方案
（基于张添翼老师直播内容的学习总结）
随着 Agent 技术快速发展，越来越多企业希望：

• 把内部业务能力开放给大模型

• 构建自己的 AI 运营助手 / AI 客服 / AI ERP / AI 业务协同系统

• 让大模型具备可控、可靠的执行能力

MCP（Model Context Protocol）作为统一的工具协议标准，让企业能以标准化方式向 LLM 暴露业务工具。

但从真实企业落地来看，会遇到大量复杂问题，尤其是在：

• 多团队协作
• 高并发场景
• 企业安全审计
• 工具数量爆炸
• 旧系统与新系统混用

因此 MCP 在企业中并不只是“能不能用”，而是“能不能规模化、低成本、稳态运行”。

文章中需要使用的网关地址如下：

网关地址：https://higress.ai/?spm=36971b57.3a251bd0.0.0.6fc129a5C0sB8z

一、企业落地 MCP 的三大痛点

企业在落地 MCP 时，通常会遇到以下三个核心挑战：

痛点1. 快速接入现有业务能力

如何将企业内部存量的业务能力（通常以 API 形式暴露）快速接入到基于 MCP 标准的 Agent 系统中。
企业内部接口极其多：
订单、商品、库存、营销、财务、BI…
几乎全是 API。
但 MCP 需要写 MCP Server —— 需要：

• 写工具定义
• 写参数映射
• 写返回结构
• 写鉴权和协议处理

这会导致：
1、每接一个系统，就要写一套 MCP Server
2、上线一堆 MCP Server，运维成本巨大
3、多团队风格不一致，难以治理
4、工期会快被拖死
本质难点：企业已有大量存量接口，但不能直接作为 MCP 工具使用。

痛点2. 统一治理与管理

当 MCP 服务多了，会出现如下问题：

（1）认证方式不统一

有的用 Token，有的用 JWT，有的走内部网关。

（2）权限不受控

一个 Agent 应该只能调用有限的工具，但 MCP 默认不包含权限体系。

这会导致：

危险：可能被提示词注入后调用高危接口（如删除订单、修改库存）
合规：审计难以追踪
项目：责任界限不清晰

（3）协议多样化

一些业务使用：

• Webhook
• REST
• WebSocket
• SSE（服务器推送）
• 内部 RPC（gRPC / Dubbo ）

MCP 需要统一协议，但业务端却五花八门。

（4）缺少统一观测能力

当 Agent 使用工具失败时，很难知道：

• 是超时？
• 是认证失败？
• 是网关问题？
• 是工具本身的问题？
• 是 Agent 乱调用？

实际排查时极度痛苦。

---

痛点 3：工具数量爆炸后的管理瓶颈

随着企业工具越来越多：

• 50 个工具 → 勉强能加载
• 100 个工具 → 上下文开始撑不住
• 300 个工具 → 延迟剧增
• 500 个工具 → 已无法正常使用
• 1000+ 个工具 → LLM 直接崩溃

问题本质：

• LLM 需要把所有工具描述装入上下文
• 工具描述越多，Token 消耗越高
• 工具越多，模型决策越困难
• 工具越多，延迟越大

导致：

• 成本暴涨
• 准确率下降
• 业务体验劣化

企业要上百上千个工具时，会遭遇“沉没成本”问题：

工具越多 → 越难使用 → 越想扩展 → 越扩展越无法使用
形成 MCP 大规模落地的“恶性循环”

二、以上三个问题使用网关如何应对

1、基础能力：连接与代理

Higress 作为 MCP 网关，通过两种核心模式实现 AI Agent 与企业内外服务的连接。
如下图：

1.1 REST to MCP：一键转换

核心价值：

将企业最大的资产===海量业务接口，Higress会将他们一键转换为 MCP 服务。

原理

• 读取 OpenAPI/Swagger 文档
• 自动解析路径、描述、参数、类型
• 自动生成 MCP 配置文件
• 自动注册为 MCP 工具集

实现方式：

• 读取 OpenAPI 规范文件（Swagger 文档）
• 自动提取 API 路径、参数、描述等信息
• 批量转换为 MCP Server 的 Tool 规范配置

使用示例：
比如：电商部门有一个order.json Swagger的文件，里面定义了GET
/api/v1/getOrderInfo?order_id={id} 这样一个查询订单的api 。
如果未使用网关之前，AI的Agent并不会找到这个api 。需要写一个专门的MCP Server来包装这个API
使用网关的情况，只需要运行

# 开源用户可使用命令行工具
openapi-to-mcp -input orders.json --output orders-mcp.yml

在商业化 AI 网关用户只需在控制台导入接口文档，即可自动生成对应的 MCP 服务。

1.2 MCP Proxy：统一代理入口

解决的问题：

• 不同 MCP 客户端（Claude、Cursor 等）支持的协议不同
• 后端服务使用不同的协议（SSE、WebSocket 等）
• 需要统一的安全认证和观测能力

核心优势：

1. 统一安全认证 - 在网关层实现统一的认证模式
2. 协议适配 - 屏蔽前后端协议差异
3. 统一观测 - 提供统一的日志，便于审计

如下图：

做MCP的代理，可能会遇到一个问题，会话的负载均衡，需要对状态会话做保持的。

问题场景：

有一个集成了A股行情的MCP服务，通过SSE长连接的形式推送实实地股价。如果在K8s等集群中部署了三个该服务的实例，用用户A的连接建立在实例A上时，如果下一次心跳或者请求负载均衡到实例B，链接将失效。

解决方案：

1.3 SSE 会话保持

场景说明： 对于 SSE 协议的有状态服务（如实时 A 股行情推送），需要保证同一会话的请求路由到同一后端实例。

解决方案： 在 Higress 配置中添加注解即可实现 SSE 会话保持：

annotations:
  higress.io/session-affinity: "cookie"

网关会根据 Session ID 精确路由到对应的有状态实例。

效果：

• 会话固定路由到同一后端实例
• 长连接不会被打断
• 非侵入式，无需修改工具端代码

二、进阶能力：体验、效率与安全

背景：当基础连接跑通之后，企业会立即面临“体验“ ，”效率”和安全的进阶挑战

可能存在的问题：

协议的复杂，比如刚才提到的SSE这种有状态的连接，使得大量的长连接跟后端服务进行维持，但是当你的后端服务要去做一些变更，可能会对已有的Agent的状态会产生一些干扰。比如可以想象一下当前的A股的Agent，它正在处理高频交易的实时信息，后端把服务更新了一下，把当前的连接断掉了，则连接就会中断掉了。还有一种情况涉及安全风险：企业在使用大量 Agent 工具时，可能会遭遇提示词注入攻击，使原本不应调用的服务被触发，从而造成企业自身损失。

2.1 让 LLM 理解 API 返回数据

问题背景： 国内很多的企业，对于一个系统的API文档是没有很好的维护起来的，会出现旧数据的问题。比如：旧的API返回

{"success": true,"data":{"p_name":"....","p_id":"...."}}

则LLM是无法理解p_name和p_id是什么意思。

解决方案一：基础调优 在 REST to MCP 配置中附加字段说明：

response_description: |
  p_name: 产品名称
  p_id: 产品ID
  price: 价格（单位：元）

在此基础上提供深度定制的能力。
解决方案二：深度定制（DSL） 提供 DSL 语言，提取后端中 JSON 字段，拼接为 Agent 友好的 Markdown 格式：

• 更易于 LLM 理解
• 节省 Token 成本，把用到的信息给提出来，无用的信息过滤（只返回必要信息）

2.2 协议卸载

问题： SSE 长连接在客户端到网关、网关到后端的全链路中，任意一环断开都会影响工具输出。会受到一定的影响。

解决方案： SSE有状态的连接对客户端来说变成无状态的：

• 客户端与网关间为无状态连接
• 后端连接断开不影响客户端使用
• 适合原本无需维护状态的业务场景
  

2.3 安全认证与权限控制

身份认证

支持多种认证方式：

• Bearer Token
• OAuth 2.0
• 第三方 SaaS（如 钉钉）的认证体系

权限控制

遵循最小权限原则：

• 将不同 Agent（如 AI 客服、财务 Agent）作为独立消费者管理
• 为每个消费者分配特定工具的访问权限
• 从源头杜绝高危操作风险

示例：

consumers:
  - name: ai-customer-service
    allowed_tools:
      - query_order
      - send_email
  - name: finance-agent
    allowed_tools:
      - query_balance
      - generate_report

consumers（消费者） 指向不同的 Agent，例如：

• ai-customer-service（AI 客服 Agent）
• finance-agent（财务 Agent）

每个 Agent 都会使用一些工具（tool），比如查询订单、发送邮件、生成财务报表等等。

为了避免安全风险，要遵循 最小权限原则（Least Privilege Principle）：

每个 Agent 只能使用它工作需要的工具。

三、深水区：大规模工具管理

当企业 MCP 工具数量达到数千个时，面临的挑战：

• 上下文窗口立刻会被撑爆
• 一个是成本激增
• 延迟增高
• 准确率下降
• 

3.1 方案一：MCP 工具组装

如下图：

适用场景： 中等规模（几十到上百个工具），任务相对明确

实现方式： 创建虚拟的MCP Server，从多个 MCP Server 中精选所需工具：

问题：一个email-server可能包含20个工具（发送，读取，删除，等）但是你的Agent明确只需要send_email。
解决方案：Higress 网关是允许在控制台上创建一个虚拟的MCP服务，从email-server中勾选send_email 。
效果:网关会生成一个全新的，轻量的meeting-agent-tools服务，AiAgent只加载这个虚拟服务。他的上下文中永远只有你勾选的服务，从源头上节省了token，以及消除干扰，极大的提高了准确率。

virtual_mcp_server:
  name: meeting-scheduler
  tools:
    - source: email-server
      tool: send_email

优势：

• 精确控制工具数量
• 从源头节省 Token
• 消除干扰，提高准确率

3.2 方案二：语义化检索

适用场景： 超大规模（数千个工具），此时Agent任务不固定，需要泛化的场景

场景流程：

1. 索引：将所有 MCP 工具描述向量化，存入向量数据库
2. 搜索：Agent 调用 higress_tool_search 工具查询相关工具
3. 召回：执行 Embedding 粗召回 + Rerank 精排
4. 调用：返回 TOP 5 相关工具供 Agent 使用

3.3 方案三：智能工具精选（零改动方案）

适用场景： 现有业务已使用大量工具去用MCP了，希望在不改变Agent和LLM的前提下，智能优化海量工具。

实现原理： 在请求到达 LLM 前，Higress 拦截并处理：

1. 理解用户意图，改写查询
2. 对传入的工具（如 500 个）进行实时相关性排序
3. 过滤出符合意图的 TOP 5 工具
4. 转发精选后的请求给 LLM
   

性能提升：

• 处理 500 个工具时，调用速度提升 7 倍
• 准确率提升 6%
• 业务完全透明，无需任何改动

四、总结

Higress AI 网关为企业提供了从基础连接到大规模管理的完整 MCP 解决方案：

阶段	核心能力	价值
基础	REST to MCP、统一代理	快速接入，统一治理
进阶	API 理解优化、协议卸载、安全管控	提升体验，保障安全
深水区	工具组装、语义检索、智能精选	高效管理，降本增效

通过这些最佳实践，企业能够高效、安全地构建和运营大规模 AI Agent 系统。