AI网关 - 插件集成与MCP集成介绍

洗澡水加冰
47 阅读6分钟

AI网关-插件集成与MCP集成介绍

AI网关作为一个中心统一管理对内部LLM的调用，使用网关可以高效管理各种内部调用资源、收集调用链路、统计调用次序等，抽出的中间层还支持完成多种外部适配与连接。

插件系统集成

有的AI网关集成了插件系统，提供了搜索插件、缓存插件、意图识别插件等。虽然使用了插件系统这样高级的名词，但是本质上就是中间件或者wrapper，只是抽出了一个对象专门管理挂载功能。一般插件系统的核心链路：客户端请求AI网关-请求进入wrapper层-处理用户请求结构-识别用户请求中的标识-进入插件处理逻辑-完成后修改初始Prompt-进入核心LLM调用逻辑。

比如，在网络搜索插件中，识别到对应的searchOption之后，借助插件封装了搜索引擎功能，搜索得到结果，再将结果拼接到Prompt中，LLM就能够知道网络搜索的相关信息；而在流式转换的插件中，如果请求中携带了对应的标识，插件可以将流式响应转化为非流式响应。

插件系统核心抽象：（github.com/labring/aip…）


// adaptor hook
type Plugin interface {
	GetRequestURL(
		meta *meta.Meta,
		store adaptor.Store,
		do adaptor.GetRequestURL,
	) (adaptor.RequestURL, error)

	SetupRequestHeader(
		meta *meta.Meta,
		store adaptor.Store,
		c *gin.Context,
		req *http.Request,
		do adaptor.SetupRequestHeader,
	) error

	ConvertRequest(
		meta *meta.Meta,
		store adaptor.Store,
		req *http.Request,
		do adaptor.ConvertRequest,
	) (adaptor.ConvertResult, error)

	DoRequest(
		meta *meta.Meta,
		store adaptor.Store,
		c *gin.Context,
		req *http.Request,
		do adaptor.DoRequest,
	) (*http.Response, error)

	DoResponse(
		meta *meta.Meta,
		store adaptor.Store,
		c *gin.Context,
		resp *http.Response,
		do adaptor.DoResponse,
	) (model.Usage, adaptor.Error)
}

func WrapperAdaptor(adaptor adaptor.Adaptor, plugins ...Plugin) adaptor.Adaptor {
	if len(plugins) == 0 {
		return adaptor
	}

	result := adaptor
	for i := len(plugins) - 1; i >= 0; i-- {
		result = &wrappedAdaptor{
			Adaptor: result,
			plugin:  plugins[i],
		}
	}

	return result
}

插件系统核心诉求： 为LLM提供外部关联的能力，或者说，为AI调用提供一种热更新能力，以适配不同使用者千人千面的调用。基于此核心，不同的视角延伸了两种设计思路：

  • 以系统工程角度，在AI网关上集成插件系统，将外部关联挂载，提供外部能力。（AI IDE更多使用此思路）
  • 以服务模式角度，Openai面对LLM扩展能力这个需求的时候，也抽象了一种模式：通过传给LLM tool选项，LLM返回tool_call，让客户端自己识别tool_call并做相应扩展服务调用——因为openai并没有打算做一个大的网关服务，只是聚焦在单体。

以上不管哪种思路，最终都落到一个点：这种提供给LLM的拓展能力，调用者(客户、网关)都得自己一个个实现相应的功能。能不能有现成的、市场上提供的服务来供LLM调用呢？可以，但需要统一规范。MCP协议随着诞生。只要市面上的服务商都遵守一种规范（MCP协议），就可以提供这种外部扩展能力给LLM使用，调用者不再需要自己去实现拓展能力，而是利用现成的服务比如搜索引擎、地图服务。

MCP服务集成

MCP服务诞生后，AI网关的设计架构要求AI网关有管理mcp服务的能力。

企业级别的Agent部署总是配套有多个mcp的，在审计中不期望链路因为调用mcp而中断，所以需要在网关层面做到MCP集成，将MCP包装成为内部服务，或者做MCP协议代理转发。

AI网关会启动MCP Server接收来自客户端的请求、提供接口给外部查询tools列表，然后在插件系统中，可以自动做到意图识别与tools选择。客户调用的时候，通过接口获取tools List放在LLM请求中，然后结合LLM返回的tool_call，系统内部通过mcp_client发起mcp相关协议调用，请求网关上的MCP server，得到响应再返回。

过程：

  • 通过某一个接口获取网关内部提供的方法，客户端可以知道有哪些方法能调用或者是有哪些mcp

  • 拿到mcp的内部id之后，请求中可以带上，然后AI网关自动根据id，请求mcp的toolsList，得到工具列表后放入请求结构体的tools中；

    调用发现内部有什么工具
GET /api/mcp/public/group/{group}

调用了解内部工具的详情
GET /api/mcp/public/group/{group}/{id}

    AI网关也可以自动根据用户的请求内容，决定要调用什么mcp，由AI网关来补充tools的字段。

  • LLM判断需要调用mcp的时候，会返回tools_call信息 （如有必要要可以做成插件系统），AI网关识别到tools_call 之后，主动构造参数与调用当前进程中的mcp路由，以特定的通讯方式(sse\streamable http)调用MCP服务得到结果。
  • 结果作为tools_call的message_type上下文传递给LLM，LLM最终组合，得到最终的结果。

以上过程调用链路可控，MCP服务可以随时集成进入网关中，统一由网关管理。

MCP与多轮调用

一旦在chat中使用MCP服务，多轮对话与工具交互是随之而来需求，在AI IDE的场景中，经常是Agent识别到需要调用MCP服务，等待用户确认，点击确认后再让LLM自动执行。这种多轮对话交互与工具调用如何实现？

调用过程有两个核心点：

  • MCP规范提供的工具，对LLM而言都需要走tools 与 tool_call的模式调用
  • MCP服务的结果，都需要加入到上下文中才能被LLM感知

因为多轮调用的主体都是LLM，做到多轮调用只需要做好对话上下文管理与调用过程的交互。所以，功能的模块划分就是：

  • LLM Client负责LLM调用
  • MCP Client负责MCP调用，内部的MCP Client初始化的时候都已经连上了Server，这里一般会使用pool。
  • Agent Client负责处理与调用者的交互，作为对外的出口，询问是否执行操作等。
  • Message会话管理器管理多轮对话与内容格式decode、encode，不同的LLM服务商可能有不同的tools调用协议，所以需要针对适配。
  • 可选的缓存设计

实现过程：

  • Agent Client接收客户调用
  • 识别tools List 工具调用
  • Message记录会话信息，通过LLM Client传递用户请求与工具调用
  • 如果需要工具调用或者交互，识别LLM的response，通过Agent Client与用户交互——比如是否执行某一个mcp调用，记录message
  • MCP Client工具调用或者结束，message继续管理回话，工具调用完成后，将message中的上下文继续投喂给LLM，得到最终结果
  • 响应客户，等待新一轮对话。
avatar
文章
阅读
粉丝