最近在调研 AI 基础服务层的架构时发现一个经常被忽略的问题业务方接入了多家大模型模型路由、负载均衡、成本控制都已经是标配能力但一旦涉及让模型调用工具、读取知识库、操作业务系统整个链路就会迅速复杂起来。Model Context ProtocolMCP出现之后工具层的标准化有了统一方向。但新的问题也随之而来谁来统一代理用户的 MCP 请求谁来根据任务自动选择合适的模型同时在模型需要工具时把请求正确转发给对应的 MCP Server本文围绕“模型路由器是否应该同时具备 MCP 网关能力”这一话题展开先梳理两者各自的职责再给出一个可运行的组合架构示例覆盖核心概念、设计思路、完整工程代码以及上线时容易踩的坑。无论你是正在建设 LLM 基础设施的后端工程师还是想理解 MCP 落地方式的架构师都能在这篇文章里找到可用的一手经验。1. 背景与核心概念1.1 什么是模型路由器模型路由器Model Router是位于上层业务与大模型之间的分发层。过去一个应用只需要调用一个模型现在很多业务同时接入多个厂商的模型例如不同版本的 GPT、Claude、国产开源模型等彼此之间在数学能力、代码能力、中文质量、推理速度、价格成本上差异非常明显。模型路由器要解决的正是“如何把每次请求派发给最合适的模型”这个问题。常见判断依据包括策略说明适用场景按任务类型简单问答走轻量模型复杂推理走强模型通用聊天、客服按成本优先低价格模型失败或超时再升级高并发、成本敏感业务按能力代码生成、数学计算、结构化输出分别指定专项模型垂直应用按延迟对响应速度要求高的场景选择低延迟模型实时交互按稳定度某些模型出现故障或限流时自动切换生产容灾本质上model router 把“模型选择”从业务代码中抽离出来业务方只需要描述请求语义由路由器完成具体模型的选择、切换、降级和重试。1.2 MCP 与 MCP 网关是什么MCP 全称 Model Context Protocol是一套开放协议核心目标是统一大模型应用与外部数据源、工具之间的通信标准。在没有 MCP 之前每个工具接入都需要开发一套自定义接口模型厂商要适配 N 种工具协议工具方也要为不同模型框架分别写对接层重复劳动非常严重。MCP 把工具交互抽象成三个主要角色MCP Host需要调用工具的应用程序例如 AI Agent、IDE、客户端。MCP ClientHost 内部与 Server 建立会话的通信组件负责发请求、收响应。MCP Server暴露工具、资源、提示词的外部服务可以本机进程也可以远程服务。MCP GatewayMCP 网关则是在客户端与多个 Server 之间增加一层统一接入节点。客户端不再需要知道每个工具的真实地址和协议细节只需连上网关就能像使用“一个工具市场”一样完成发现、调用、权限校验。网关内部再做负载均衡、缓存、审计和密钥托管。1.3 两者为什么需要结合单独看model router 管“模型调用”MCP gateway 管“工具调用”两者似乎是不同层面的组件。但在真实 AI Agent 场景里一次用户请求往往同时涉及两个决策这个任务应该交给哪个模型模型在推理过程中需要调用哪些工具工具请求转发给谁例如用户提问“帮我查一下北京明天天气然后对比上海后天天气最后生成一段出行建议”。Agent 首先要把请求路由到一个“具备工具调用能力且中文生成质量较好”的模型模型决定调用天气工具的 moment工具请求又需要被统一转发到天气服务提供方。如果模型路由器和 MCP 网关是两个独立系统业务方就要维护两套地址、两套鉴权、两套链路日志模型上下文中的工具信息也需要在两层之间重复同步效率非常低。因此一个更合理的做法是让 model router 在完成模型选择的同时也承担 MCP 网关职责把“模型接入层”和“工具接入层”收敛成一个统一的智能接入网关。下面我们展开理解 MCP 协议的核心再动手实现这样一个组合组件。2. 理解 MCP 协议的核心构成实现 MCP 网关之前至少要把 MCP 协议的基础概念弄清楚。这里我用最直白的方式拆解。2.1 Client 与 Server 的通信模型MCP 使用 JSON-RPC 2.0 作为消息格式传输层支持两种主流方式stdioServer 以子进程方式启动通过标准输入输出传递消息适合本地工具。Streamable HTTPServer 暴露 HTTP 接口适合远程服务、跨网络调用。在网关形态下通常是网关作为 Client 去连接各 MCP Server同时网关又对外暴露一个统一的 HTTP/SSE 接口供上层业务接入。也就是说网关在自己的协议栈里同时维护了两套连接如下图所示简化示意上层 Agent / 业务应用 | | MCP 协议 / HTTP v ------------------- | MCP Gateway | | - Client 角色 | | - Server 角色 | ------------------- | | | | MCP over HTTP | ------------------- v v MCP Server A MCP Server B (天气服务) (内部知识库)这种“两面人”设计让上层业务体会到的是“一个统一入口”底层 Server 也只要实现标准协议即可不需要关心上层是谁。2.2 核心原语MCP 协议主要抽象了四种能力Tools工具可被模型调用的函数式能力例如查天气、发邮件、创建工单。工具请求由“模型决定调用”所以 Tool 通常需要与模型上下文深度配合。Resources资源可被读取的数据资源例如文件内容、数据库记录、文档片段。Prompts提示词可复用的提示词模板类似“预置的对话脚本”。Sampling采样允许 Server 反向请求 Client 调用 LLM 的功能。对于大部分业务Tools 是最核心、也最需要在网关层统一管理的对象。网关维护一张工具注册表上层模型在生成请求时可以把当前会话可用的工具列表作为上下文传给模型模型一旦决定调用某个工具网关负责把调用参数转发到对应的 MCP Server拿到结果后再回填给模型继续生成。2.3 一次完整工具调用的流程以“查天气”为例一次完整调用链大致是业务请求到达网关网关携带工具描述列表向 LLM 发起推理请求。LLM 在生成过程中意识到需要调用天气工具输出一条工具调用指令例如{tool: get_weather, arguments: {city: 北京}}。网关解析工具调用指令查询自己的工具注册表找到对应 MCP Server 地址。网关以 MCP Client 身份向目标 Server 发起 JSON-RPC 请求。MCP Server 执行真实业务逻辑返回结构化结果。网关把结果注入回 LLM 的上下文继续完成后续文本生成。网关把最终回复返回给上层业务。可以看到MCP Gateway 在整个链路里承担了“翻译官 转发器 上下文组装器”的角色。如果网关层还能顺便完成模型选择那第一步就可以根据任务类型自动决定用哪个模型链路会变得更内聚。3. 架构设计让模型路由器内置 MCP 网关能力3.1 设计目标我们希望实现一个组合组件具备以下能力对上层统一暴露模型调用接口同时提供 MCP 工具的发现与调用接口。根据任务类型、成本、能力要求自动选择模型。在模型决定调用工具时能根据工具名路由到真实 MCP Server。工具注册表可动态刷新新增工具不需要改上层业务代码。具备基础鉴权、超时、错误返回和日志能力。3.2 分层设计我把组件拆成四层API 接入层处理 HTTP 请求负责参数校验、鉴权、响应格式化。模型路由层维护模型列表实现路由策略调用具体大模型。MCP 网关层维护工具注册表以 Client 角色连接远端 MCP Server同时把工具列表暴露给模型路由层。基础服务层提供配置管理、日志、监控指标、缓存等公共能力。这种分层的收益是模型路由逻辑与工具调用逻辑在代码层面解耦但在链路层面共享同一份上下文和同一套入参。也就是说“选模型”和“调工具”在一个进程里完成省去了跨服务同步上下文的开销。3.3 请求流转策略在实际设计中我把路由策略分成两个阶段第一阶段是“模型选择”。上层业务会带上task_type或required_capability网关先判断这个请求是否可能涉及工具调用。如果用户问题需要检索数据、操作外部系统则优先选择支持 function calling / tool calling 的模型。第二阶段是“工具路由”。模型返回工具调用指令后网关根据工具名在注册表中查找目标 Server。工具路由不仅可以按固定映射还可以做分组灰度例如某些工具只对内部测试应用可见。更进一步的策略是把“某类工具能力”也纳入模型选择因子。例如当前请求涉及图像理解则必须选择具备视觉能力的模型涉及代码执行则优先选择代码专项模型。这就是“模型上下文即路由输入”的思路。4. 完整实战实现一个带 MCP 网关的模型路由器下面进入实操环节。我用 Python FastAPI 实现一个教学级但结构完整的示例重点演示两层能力如何在一个服务里协同。为了控制篇幅MCP Server 部分使用简化处理实际生产需要替换为官方 SDK 或标准协议实现。4.1 项目结构model-router-mcp-gateway/ ├── main.py # FastAPI 入口暴露 HTTP 接口 ├── model_router.py # 模型路由器路由策略与模型列表 ├── mcp_gateway.py # MCP 网关工具注册、发现、调用转发 ├── llm_client.py # 模拟的大模型调用客户端 ├── requirements.txt # 项目依赖 └── README.md # 项目说明可选4.2 环境准备示例使用 Python 3.10需要安装以下依赖fastapi0.110.0 uvicorn0.29.0 pydantic2.6.0 httpx0.27.0创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate # Windows 用户使用 venv\Scripts\activate pip install -r requirements.txt本文示例重点演示架构设计思路。需要说明的是MCP 协议规范仍在快速演进生产环境建议使用各官方 SDK 维护的长连接这里为了可读性统一采用 HTTP 风格的模拟接口。4.3 实现模型路由器先在model_router.py中定义模型信息和路由策略。# 文件路径model_router.py from dataclasses import dataclass, field from typing import Optional dataclass class ModelInfo: 模型基础信息。 name: str # 模型标识 provider: str # 厂商 cost_per_1k_tokens: float # 每 1k tokens 成本单位美元 avg_latency_ms: float # 平均延迟单位毫秒 supports_tool_calls: bool # 是否支持工具调用 capabilities: set[str] field(default_factoryset) class ModelRouter: 模型路由器根据策略选择合适的模型。 def __init__(self, models: list[ModelInfo]): self._models models def list_models(self) - list[dict]: return [ { name: m.name, provider: m.provider, supports_tool_calls: m.supports_tool_calls, capabilities: list(m.capabilities), } for m in self._models ] def route( self, task_type: str general, required_capability: Optional[str] None, max_cost: Optional[float] None, ) - ModelInfo: 根据任务类型与输入要求选择模型。 candidates [m for m in self._models] # 如果任务要求工具调用过滤出支持 tool call 的模型 if task_type agent or required_capability tool_call: candidates [m for m in candidates if m.supports_tool_calls] if not candidates: raise ValueError(没有支持工具调用的可用模型) # 如果指定了能力继续过滤 if required_capability: candidates [ m for m in candidates if required_capability in m.capabilities ] if not candidates: raise ValueError(f没有支持能力 {required_capability} 的模型) # 如果指定了成本上限 if max_cost is not None: candidates [m for m in candidates if m.cost_per_1k_tokens max_cost] if not candidates: raise ValueError(当前成本约束下没有可用模型) # 这里使用简单排序策略优先低成本、低延迟 # 生产环境可以替换为带权重的路由算法 candidates.sort(keylambda m: (m.cost_per_1k_tokens, m.avg_latency_ms)) return candidates[0]代码解读ModelInfo定义了模型的基本元数据包括成本、延迟、工具调用能力和能力标签。route()是核心方法接收任务类型、必需能力和成本上限逐层过滤出候选模型最后用“低成本 低延迟”的优先级排序返回最合适的模型。这段实现是教学级别的路由策略。生产环境通常还要考虑实时延迟、错误率、限流状态、多策略权重等因素后面我们在最佳实践里讨论。4.4 实现 MCP 网关接下来实现mcp_gateway.py。这一层维护工具注册表并负责工具的发现与实际调用。# 文件路径mcp_gateway.py from typing import Any, Callable, Optional ToolHandler Callable[[dict], dict] class ToolRegistration: 工具注册信息。 def __init__( self, name: str, description: str, input_schema: dict, handler: ToolHandler, target_server: str local, ): self.name name self.description description self.input_schema input_schema self.handler handler self.target_server target_server class MCPGateway: 简化版 MCP 网关负责工具注册、发现与调用转发。 def __init__(self): self._tools: dict[str, ToolRegistration] {} def register_tool( self, name: str, description: str, input_schema: dict, handler: ToolHandler, target_server: str local, ) - None: 注册一个新的工具。 self._tools[name] ToolRegistration( namename, descriptiondescription, input_schemainput_schema, handlerhandler, target_servertarget_server, ) def list_tools(self) - list[dict]: 返回当前网关下挂载的所有工具供上层模型生成上下文。 return [ { name: t.name, description: t.description, inputSchema: t.input_schema, targetServer: t.target_server, } for t in self._tools.values() ] def has_tool(self, name: str) - bool: return name in self._tools async def call_tool(self, name: str, arguments: dict) - dict: 根据工具名找到注册处理器执行真实逻辑。 tool self._tools.get(name) if not tool: return { ok: False, error: ftool not found: {name}, } try: # 这里预留了远程转发能力如果 target_server 不是 local # 则通过 httpx 向远程 MCP Server 发起 JSON-RPC 请求。 # 为保持示例可运行本文统一走本地 handler。 if tool.target_server ! local: return { ok: True, content: f转发到远程 MCP Server: {tool.target_server}, } result tool.handler(arguments) return { ok: True, content: result, } except Exception as exc: # 防御性捕获避免网关整体崩溃 return { ok: False, error: ftool execution failed: {str(exc)}, }这是一个极简实现。核心设计是register_tool()用于向网关注册工具每个工具都包含名称、描述、入参 schema 和处理函数。list_tools()返回工具列表将来可以作为 system prompt 的一部分传给模型。call_tool()是工具调用的统一入口它先查注册表再执行 handler。这里的target_server字段预留了远程 MCP 扩展能力。真实场景下工具处理器通常不是本地函数而是通过 MCP 协议连接到独立服务。你可以在call_tool()分支里用httpx或官方 SDK 把请求转发到远程 MCP Server原理一致。4.5 模拟大模型客户端由于真实大模型 API 需要密钥和相关账号为了让大家可以零成本运行我用llm_client.py模拟一个支持工具调用的 LLM。它接收用户消息和工具列表返回“文本 可能的工具调用指令”。# 文件路径llm_client.py import json class MockLLMClient: 模拟大模型客户端演示模型如何基于工具列表输出调用指令。 def __init__(self, model_name: str): self.model_name model_name def chat_completion( self, messages: list[dict], tools: list[dict], ) - dict: 模拟模型输出。如果用户消息中包含“天气”关键词 则返回工具调用指令否则返回普通文本。 user_text json.dumps(messages, ensure_asciiFalse) if 天气 in user_text: return { role: assistant, content: 我来帮你查询天气信息。, tool_calls: [ { id: call_001, name: get_weather, arguments: {city: 北京}, } ], } return { role: assistant, content: 这是一个模拟回复实际使用时请替换为真实模型 API。, tool_calls: [], }这个类的重点不是要模拟得多像而是要展示一个关键流程模型工具调用结果会由网关解析交给 MCPGateway 执行最终再返回给上层。生产环境的chat_completion应该被替换成真实的 OpenAI / Anthropic / 自研模型 SDK 调用。4.6 组装 FastAPI 入口接下来在main.py中把模型路由器和 MCP 网关组合起来并对外暴露 HTTP API。# 文件路径main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field from model_router import ModelRouter, ModelInfo from mcp_gateway import MCPGateway from llm_client import MockLLMClient def init_models() - list[ModelInfo]: 初始化模型列表。实际项目中从配置中心或数据库读取。 return [ ModelInfo( namefast-lite, providerexample, cost_per_1k_tokens0.001, avg_latency_ms300, supports_tool_callsFalse, capabilities{chat}, ), ModelInfo( nameagent-pro, providerexample, cost_per_1k_tokens0.01, avg_latency_ms800, supports_tool_callsTrue, capabilities{chat, tool_call, reasoning}, ), ModelInfo( namecode-expert, providerexample, cost_per_1k_tokens0.02, avg_latency_ms1000, supports_tool_callsTrue, capabilities{code, tool_call}, ), ] def init_gateway() - MCPGateway: 注册演示工具。 gateway MCPGateway() def get_weather(arguments: dict) - dict: city arguments.get(city, 未知城市) return {city: city, weather: 晴, temperature: 25} def calculator(arguments: dict) - dict: expr arguments.get(expr, 0) # 演示用途实际应使用安全表达式解析库 try: result eval(expr, {__builtins__: {}}, {}) return {expr: expr, result: result} except Exception: return {expr: expr, error: 表达式错误} gateway.register_tool( nameget_weather, description查询指定城市的天气情况, input_schema{ type: object, properties: { city: {type: string, description: 城市名称}, }, required: [city], }, handlerget_weather, target_serverlocal, ) gateway.register_tool( namecalculator, description执行简单的算术运算, input_schema{ type: object, properties: { expr: {type: string, description: 算术表达式}, }, required: [expr], }, handlercalculator, target_serverlocal, ) return gateway app FastAPI(titleModel Router with MCP Gateway) router ModelRouter(init_models()) gateway init_gateway() class ChatRequest(BaseModel): messages: list[dict] Field(..., description对话消息列表) task_type: str Field(general, description任务类型general、agent、code) required_capability: str | None Field(None, description必需能力标签) max_cost: float | None Field(None, description成本上限) app.get(/v1/models) def list_models(): 返回当前网关下可用的模型列表。 return {data: router.list_models()} app.get(/mcp/tools) def list_tools(): 返回 MCP 工具注册表中的全部工具。 return {tools: gateway.list_tools()} app.post(/v1/chat/completions) async def chat_completions(req: ChatRequest): 统一入口先选模型再决定是否需要走 MCP 工具链路。 # 1. 模型路由 try: model router.route( task_typereq.task_type, required_capabilityreq.required_capability, max_costreq.max_cost, ) except ValueError as exc: raise HTTPException(status_code400, detailstr(exc)) client MockLLMClient(model.name) # 2. 如果选出的模型支持工具调用把工具列表注入上下文 tools gateway.list_tools() if model.supports_tool_calls else [] # 3. 调用模型此处替换为真实大模型 SDK response client.chat_completion(req.messages, tools) # 4. 处理模型返回的工具调用指令 tool_results [] for call in response.get(tool_calls, []): tool_name call.get(name) tool_args call.get(arguments, {}) result await gateway.call_tool(tool_name, tool_args) tool_results.append({ tool_name: tool_name, arguments: tool_args, result: result, }) # 5. 返回完整响应 return { model: model.name, message: { role: assistant, content: response.get(content, ), }, tool_results: tool_results, } if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)整体流程已经完整呈现请求进来后先通过router.route()选出模型。如果模型支持工具调用就从gateway.list_tools()拉取工具列表。调用模型得到回复文本以及可能的工具调用指令。网关执行工具并把结果返回给上层。4.7 运行与验证在项目根目录执行uvicorn main:app --host 0.0.0.0 --port 8000启动成功后先看模型列表curl http://localhost:8000/v1/models返回结果大致是{ data: [ { name: fast-lite, provider: example, supports_tool_calls: false, capabilities: [chat] }, { name: agent-pro, provider: example, supports_tool_calls: true, capabilities: [chat, tool_call, reasoning] }, { name: code-expert, provider: example, supports_tool_calls: true, capabilities: [code, tool_call] } ] }再看工具列表curl http://localhost:8000/mcp/tools接下来测试一次带工具调用的请求。使用task_typeagent让模型路由到agent-pro并触发天气工具调用curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { messages: [{role: user, content: 北京明天天气怎么样}], task_type: agent }由于MockLLMClient检测到“天气”关键词返回响应如下{ model: agent-pro, message: { role: assistant, content: 我来帮你查询天气信息。 }, tool_results: [ { tool_name: get_weather, arguments: { city: 北京 }, result: { ok: true, content: { city: 北京, weather: 晴, temperature: 25 } } } ] }这里我故意把 Gateway 的工具注册表设计在模型路由之后。这样你就能直观看到同一个入口既能完成模型选择也能完成 MCP 工具调用链路。真实系统中返回给上层的内容通常会经过再次封装把工具结果重新喂回模型生成最终回答上面示例保留了这个扩展点。5. 常见问题与排查思路5.1 工具调用了但模型没有选择正确的工具问题现象常见原因解决思路模型不调用工具直接编造结果工具描述不清晰或上下文没携带工具列表检查list_tools()是否注入优化工具描述和参数 schema模型调用已下线的工具工具注册表与模型路由层缓存不一致网关层增加工具版本控制发布下线时同步刷新工具参数解析失败模型返回的参数与 inputSchema 不匹配参数校验层增加容错必要时用大模型二次修正参数5.2 MCP 请求超时或连接失败远程 MCP Server 是独立服务时网络抖动、服务重启、协议版本不兼容都会导致调用失败。建议方案网关侧为每个 MCP Server 设置独立的超时时间避免一个慢服务拖垮整体链路。重试要有次数上限并且区分“幂等工具”和“非幂等工具”非幂等操作不应盲目重试。把 MCP Server 的日志与网关日志关联起来最简单的方式是在请求入口生成request_id在日志中透传。5.3 网关成为新的单点瓶颈引入网关层后最担心的是它成为性能和可用性上的瓶颈。应对思路网关尽量无状态工具注册表放在 Redis 或配置中心实例可以水平扩展。远程 MCP 调用使用连接池避免每个请求都重新建连。网关自身的版本发布与 MCP Server 的解耦要彻底不能因为网关重启导致工具全部不可用。6. 最佳实践与工程建议6.1 路由决策要显式化、可观测不要把所有路由逻辑堆在一个大函数里。建议把“路由策略”抽象成独立模块支持配置化或插件化。每次路由决策都输出结构化日志记录输入特征、候选模型、选择原因、最终模型。只有决策可回溯线上出现效果问题时才能快速定位。6.2 工具注册表采用配置中心管理MCP 网关的工具列表不要硬编码在代码里。正确做法是把工具定义放到 Apollo、Nacos 或专门的数据库中网关启动时加载运行期监听变更。工具上线、下线、灰度发布都走配置中心流程。这样可以避免“代码发布才能增删工具”的低效模式。6.3 密钥与权限分离管理MCP Server 的访问密钥、模型厂商的 API Key 都属于敏感信息不能散落在网关配置或代码仓库里。建议模型密钥和 MCP Server 密钥分开存储按服务维度授权。网关对外只暴露最小权限接口内部 Server 的密钥不向下透传。所有工具调用都经过鉴权不同业务方只能看到自己有权限的工具。6.4 错误处理要区分“模型错误”和“工具错误”一次请求既有模型调用又有工具调用错误类型要区分开。模型限流、模型超时、工具不存在、工具执行异常应该分别返回不同错误码并触发不同的重试和降级策略。否则上层只能看到一个统一的 500排障成本会很高。6.5 上下文组装要控制 Token 消耗工具列表和工具结果都会占用模型上下文。工具特别多的时候不能一股脑把所有工具描述都塞给模型。建议按关键词或语义相似度先做工具召回只把最可能的工具描述传给模型。工具返回结果要截断避免超长 JSON 撑爆上下文。对固定工具结果做缓存减少重复调用。6.6 生产环境建议使用官方 MCP SDK本文示例为了演示把 MCP 协议简化成了本地 handler生产环境应当直接使用官方 SDK 或成熟的开源实现。MCP 协议包含初始化握手、能力协商、流式响应、错误码等细节自己实现很容易在边界情况下踩坑。6.7 为网关建立独立的监控大盘网关承载了模型路由和工具路由两个链路建议监控以下指标分类指标流量请求量、模型维度调用量、工具维度调用量性能路由决策耗时、模型响应耗时、MCP 调用耗时稳定性模型错误率、工具错误率、超时率成本各模型 Token 消耗、成本预估这些指标可以输出到 Prometheus配合 Grafana 展示也可以在阿里云 ARMS、日志服务等平台做链路追踪。7. 总结与学习路线模型路由器解决的是“用哪个模型”的问题MCP 网关解决的是“模型如何调用外界工具”的问题。两者拆开看各有边界但放在真实 AI Agent 场景里它们的决策发生在同一条请求链路上分享同一个模型上下文。把 MCP 网关能力内建到模型路由器中业务方只需要对接一个入口就能完成模型选择、工具发现、工具调用、结果回填的完整闭环。如果你打算从零搭建这样一套能力我的建议是按以下顺序深入学习先吃透 MCP 协议的核心规范理解 Client、Server、Tools、Resources 之间的关系。动手实现一个最简单的 MCP Server暴露一个自定义工具并手工用 JSON-RPC 消息调用它。在模型路由层加入路由策略先做“按任务类型选择模型”的简单规则。把两部分通过网关组装起来完成“模型选型 - 工具调用 - 结果返回”的闭环。再逐步补充配置中心、权限体系、可观测性和成本控制。当前 MCP 生态还在快速发展工具协议、SDK 版本、各家模型的 function calling 能力都在迭代不要指望一套代码写死跑三年。更值得投资的是架构边界的划分能力只要路由层和网关层的边界足够清晰底层协议怎么升级都不影响整体稳定性。本文的完整示例代码可以直接在本地跑通把它改造成真实连接 OpenAI / Anthropic / MCP Server 的版本只差一步替换llm_client.py和工具 handler你在自己项目中遇到的具体问题也会在这个实践过程里自然浮现出来。如果这篇文章对你有帮助收藏备用后续实践过程中有新的踩坑经验再来一起交流。 模型路由器内置MCP网关：统一AI工具调用与模型路由的架构实践
最近在调研 AI 基础服务层的架构时发现一个经常被忽略的问题业务方接入了多家大模型模型路由、负载均衡、成本控制都已经是标配能力但一旦涉及让模型调用工具、读取知识库、操作业务系统整个链路就会迅速复杂起来。Model Context ProtocolMCP出现之后工具层的标准化有了统一方向。但新的问题也随之而来谁来统一代理用户的 MCP 请求谁来根据任务自动选择合适的模型同时在模型需要工具时把请求正确转发给对应的 MCP Server本文围绕“模型路由器是否应该同时具备 MCP 网关能力”这一话题展开先梳理两者各自的职责再给出一个可运行的组合架构示例覆盖核心概念、设计思路、完整工程代码以及上线时容易踩的坑。无论你是正在建设 LLM 基础设施的后端工程师还是想理解 MCP 落地方式的架构师都能在这篇文章里找到可用的一手经验。1. 背景与核心概念1.1 什么是模型路由器模型路由器Model Router是位于上层业务与大模型之间的分发层。过去一个应用只需要调用一个模型现在很多业务同时接入多个厂商的模型例如不同版本的 GPT、Claude、国产开源模型等彼此之间在数学能力、代码能力、中文质量、推理速度、价格成本上差异非常明显。模型路由器要解决的正是“如何把每次请求派发给最合适的模型”这个问题。常见判断依据包括策略说明适用场景按任务类型简单问答走轻量模型复杂推理走强模型通用聊天、客服按成本优先低价格模型失败或超时再升级高并发、成本敏感业务按能力代码生成、数学计算、结构化输出分别指定专项模型垂直应用按延迟对响应速度要求高的场景选择低延迟模型实时交互按稳定度某些模型出现故障或限流时自动切换生产容灾本质上model router 把“模型选择”从业务代码中抽离出来业务方只需要描述请求语义由路由器完成具体模型的选择、切换、降级和重试。1.2 MCP 与 MCP 网关是什么MCP 全称 Model Context Protocol是一套开放协议核心目标是统一大模型应用与外部数据源、工具之间的通信标准。在没有 MCP 之前每个工具接入都需要开发一套自定义接口模型厂商要适配 N 种工具协议工具方也要为不同模型框架分别写对接层重复劳动非常严重。MCP 把工具交互抽象成三个主要角色MCP Host需要调用工具的应用程序例如 AI Agent、IDE、客户端。MCP ClientHost 内部与 Server 建立会话的通信组件负责发请求、收响应。MCP Server暴露工具、资源、提示词的外部服务可以本机进程也可以远程服务。MCP GatewayMCP 网关则是在客户端与多个 Server 之间增加一层统一接入节点。客户端不再需要知道每个工具的真实地址和协议细节只需连上网关就能像使用“一个工具市场”一样完成发现、调用、权限校验。网关内部再做负载均衡、缓存、审计和密钥托管。1.3 两者为什么需要结合单独看model router 管“模型调用”MCP gateway 管“工具调用”两者似乎是不同层面的组件。但在真实 AI Agent 场景里一次用户请求往往同时涉及两个决策这个任务应该交给哪个模型模型在推理过程中需要调用哪些工具工具请求转发给谁例如用户提问“帮我查一下北京明天天气然后对比上海后天天气最后生成一段出行建议”。Agent 首先要把请求路由到一个“具备工具调用能力且中文生成质量较好”的模型模型决定调用天气工具的 moment工具请求又需要被统一转发到天气服务提供方。如果模型路由器和 MCP 网关是两个独立系统业务方就要维护两套地址、两套鉴权、两套链路日志模型上下文中的工具信息也需要在两层之间重复同步效率非常低。因此一个更合理的做法是让 model router 在完成模型选择的同时也承担 MCP 网关职责把“模型接入层”和“工具接入层”收敛成一个统一的智能接入网关。下面我们展开理解 MCP 协议的核心再动手实现这样一个组合组件。2. 理解 MCP 协议的核心构成实现 MCP 网关之前至少要把 MCP 协议的基础概念弄清楚。这里我用最直白的方式拆解。2.1 Client 与 Server 的通信模型MCP 使用 JSON-RPC 2.0 作为消息格式传输层支持两种主流方式stdioServer 以子进程方式启动通过标准输入输出传递消息适合本地工具。Streamable HTTPServer 暴露 HTTP 接口适合远程服务、跨网络调用。在网关形态下通常是网关作为 Client 去连接各 MCP Server同时网关又对外暴露一个统一的 HTTP/SSE 接口供上层业务接入。也就是说网关在自己的协议栈里同时维护了两套连接如下图所示简化示意上层 Agent / 业务应用 | | MCP 协议 / HTTP v ------------------- | MCP Gateway | | - Client 角色 | | - Server 角色 | ------------------- | | | | MCP over HTTP | ------------------- v v MCP Server A MCP Server B (天气服务) (内部知识库)这种“两面人”设计让上层业务体会到的是“一个统一入口”底层 Server 也只要实现标准协议即可不需要关心上层是谁。2.2 核心原语MCP 协议主要抽象了四种能力Tools工具可被模型调用的函数式能力例如查天气、发邮件、创建工单。工具请求由“模型决定调用”所以 Tool 通常需要与模型上下文深度配合。Resources资源可被读取的数据资源例如文件内容、数据库记录、文档片段。Prompts提示词可复用的提示词模板类似“预置的对话脚本”。Sampling采样允许 Server 反向请求 Client 调用 LLM 的功能。对于大部分业务Tools 是最核心、也最需要在网关层统一管理的对象。网关维护一张工具注册表上层模型在生成请求时可以把当前会话可用的工具列表作为上下文传给模型模型一旦决定调用某个工具网关负责把调用参数转发到对应的 MCP Server拿到结果后再回填给模型继续生成。2.3 一次完整工具调用的流程以“查天气”为例一次完整调用链大致是业务请求到达网关网关携带工具描述列表向 LLM 发起推理请求。LLM 在生成过程中意识到需要调用天气工具输出一条工具调用指令例如{tool: get_weather, arguments: {city: 北京}}。网关解析工具调用指令查询自己的工具注册表找到对应 MCP Server 地址。网关以 MCP Client 身份向目标 Server 发起 JSON-RPC 请求。MCP Server 执行真实业务逻辑返回结构化结果。网关把结果注入回 LLM 的上下文继续完成后续文本生成。网关把最终回复返回给上层业务。可以看到MCP Gateway 在整个链路里承担了“翻译官 转发器 上下文组装器”的角色。如果网关层还能顺便完成模型选择那第一步就可以根据任务类型自动决定用哪个模型链路会变得更内聚。3. 架构设计让模型路由器内置 MCP 网关能力3.1 设计目标我们希望实现一个组合组件具备以下能力对上层统一暴露模型调用接口同时提供 MCP 工具的发现与调用接口。根据任务类型、成本、能力要求自动选择模型。在模型决定调用工具时能根据工具名路由到真实 MCP Server。工具注册表可动态刷新新增工具不需要改上层业务代码。具备基础鉴权、超时、错误返回和日志能力。3.2 分层设计我把组件拆成四层API 接入层处理 HTTP 请求负责参数校验、鉴权、响应格式化。模型路由层维护模型列表实现路由策略调用具体大模型。MCP 网关层维护工具注册表以 Client 角色连接远端 MCP Server同时把工具列表暴露给模型路由层。基础服务层提供配置管理、日志、监控指标、缓存等公共能力。这种分层的收益是模型路由逻辑与工具调用逻辑在代码层面解耦但在链路层面共享同一份上下文和同一套入参。也就是说“选模型”和“调工具”在一个进程里完成省去了跨服务同步上下文的开销。3.3 请求流转策略在实际设计中我把路由策略分成两个阶段第一阶段是“模型选择”。上层业务会带上task_type或required_capability网关先判断这个请求是否可能涉及工具调用。如果用户问题需要检索数据、操作外部系统则优先选择支持 function calling / tool calling 的模型。第二阶段是“工具路由”。模型返回工具调用指令后网关根据工具名在注册表中查找目标 Server。工具路由不仅可以按固定映射还可以做分组灰度例如某些工具只对内部测试应用可见。更进一步的策略是把“某类工具能力”也纳入模型选择因子。例如当前请求涉及图像理解则必须选择具备视觉能力的模型涉及代码执行则优先选择代码专项模型。这就是“模型上下文即路由输入”的思路。4. 完整实战实现一个带 MCP 网关的模型路由器下面进入实操环节。我用 Python FastAPI 实现一个教学级但结构完整的示例重点演示两层能力如何在一个服务里协同。为了控制篇幅MCP Server 部分使用简化处理实际生产需要替换为官方 SDK 或标准协议实现。4.1 项目结构model-router-mcp-gateway/ ├── main.py # FastAPI 入口暴露 HTTP 接口 ├── model_router.py # 模型路由器路由策略与模型列表 ├── mcp_gateway.py # MCP 网关工具注册、发现、调用转发 ├── llm_client.py # 模拟的大模型调用客户端 ├── requirements.txt # 项目依赖 └── README.md # 项目说明可选4.2 环境准备示例使用 Python 3.10需要安装以下依赖fastapi0.110.0 uvicorn0.29.0 pydantic2.6.0 httpx0.27.0创建虚拟环境并安装依赖python -m venv venv source venv/bin/activate # Windows 用户使用 venv\Scripts\activate pip install -r requirements.txt本文示例重点演示架构设计思路。需要说明的是MCP 协议规范仍在快速演进生产环境建议使用各官方 SDK 维护的长连接这里为了可读性统一采用 HTTP 风格的模拟接口。4.3 实现模型路由器先在model_router.py中定义模型信息和路由策略。# 文件路径model_router.py from dataclasses import dataclass, field from typing import Optional dataclass class ModelInfo: 模型基础信息。 name: str # 模型标识 provider: str # 厂商 cost_per_1k_tokens: float # 每 1k tokens 成本单位美元 avg_latency_ms: float # 平均延迟单位毫秒 supports_tool_calls: bool # 是否支持工具调用 capabilities: set[str] field(default_factoryset) class ModelRouter: 模型路由器根据策略选择合适的模型。 def __init__(self, models: list[ModelInfo]): self._models models def list_models(self) - list[dict]: return [ { name: m.name, provider: m.provider, supports_tool_calls: m.supports_tool_calls, capabilities: list(m.capabilities), } for m in self._models ] def route( self, task_type: str general, required_capability: Optional[str] None, max_cost: Optional[float] None, ) - ModelInfo: 根据任务类型与输入要求选择模型。 candidates [m for m in self._models] # 如果任务要求工具调用过滤出支持 tool call 的模型 if task_type agent or required_capability tool_call: candidates [m for m in candidates if m.supports_tool_calls] if not candidates: raise ValueError(没有支持工具调用的可用模型) # 如果指定了能力继续过滤 if required_capability: candidates [ m for m in candidates if required_capability in m.capabilities ] if not candidates: raise ValueError(f没有支持能力 {required_capability} 的模型) # 如果指定了成本上限 if max_cost is not None: candidates [m for m in candidates if m.cost_per_1k_tokens max_cost] if not candidates: raise ValueError(当前成本约束下没有可用模型) # 这里使用简单排序策略优先低成本、低延迟 # 生产环境可以替换为带权重的路由算法 candidates.sort(keylambda m: (m.cost_per_1k_tokens, m.avg_latency_ms)) return candidates[0]代码解读ModelInfo定义了模型的基本元数据包括成本、延迟、工具调用能力和能力标签。route()是核心方法接收任务类型、必需能力和成本上限逐层过滤出候选模型最后用“低成本 低延迟”的优先级排序返回最合适的模型。这段实现是教学级别的路由策略。生产环境通常还要考虑实时延迟、错误率、限流状态、多策略权重等因素后面我们在最佳实践里讨论。4.4 实现 MCP 网关接下来实现mcp_gateway.py。这一层维护工具注册表并负责工具的发现与实际调用。# 文件路径mcp_gateway.py from typing import Any, Callable, Optional ToolHandler Callable[[dict], dict] class ToolRegistration: 工具注册信息。 def __init__( self, name: str, description: str, input_schema: dict, handler: ToolHandler, target_server: str local, ): self.name name self.description description self.input_schema input_schema self.handler handler self.target_server target_server class MCPGateway: 简化版 MCP 网关负责工具注册、发现与调用转发。 def __init__(self): self._tools: dict[str, ToolRegistration] {} def register_tool( self, name: str, description: str, input_schema: dict, handler: ToolHandler, target_server: str local, ) - None: 注册一个新的工具。 self._tools[name] ToolRegistration( namename, descriptiondescription, input_schemainput_schema, handlerhandler, target_servertarget_server, ) def list_tools(self) - list[dict]: 返回当前网关下挂载的所有工具供上层模型生成上下文。 return [ { name: t.name, description: t.description, inputSchema: t.input_schema, targetServer: t.target_server, } for t in self._tools.values() ] def has_tool(self, name: str) - bool: return name in self._tools async def call_tool(self, name: str, arguments: dict) - dict: 根据工具名找到注册处理器执行真实逻辑。 tool self._tools.get(name) if not tool: return { ok: False, error: ftool not found: {name}, } try: # 这里预留了远程转发能力如果 target_server 不是 local # 则通过 httpx 向远程 MCP Server 发起 JSON-RPC 请求。 # 为保持示例可运行本文统一走本地 handler。 if tool.target_server ! local: return { ok: True, content: f转发到远程 MCP Server: {tool.target_server}, } result tool.handler(arguments) return { ok: True, content: result, } except Exception as exc: # 防御性捕获避免网关整体崩溃 return { ok: False, error: ftool execution failed: {str(exc)}, }这是一个极简实现。核心设计是register_tool()用于向网关注册工具每个工具都包含名称、描述、入参 schema 和处理函数。list_tools()返回工具列表将来可以作为 system prompt 的一部分传给模型。call_tool()是工具调用的统一入口它先查注册表再执行 handler。这里的target_server字段预留了远程 MCP 扩展能力。真实场景下工具处理器通常不是本地函数而是通过 MCP 协议连接到独立服务。你可以在call_tool()分支里用httpx或官方 SDK 把请求转发到远程 MCP Server原理一致。4.5 模拟大模型客户端由于真实大模型 API 需要密钥和相关账号为了让大家可以零成本运行我用llm_client.py模拟一个支持工具调用的 LLM。它接收用户消息和工具列表返回“文本 可能的工具调用指令”。# 文件路径llm_client.py import json class MockLLMClient: 模拟大模型客户端演示模型如何基于工具列表输出调用指令。 def __init__(self, model_name: str): self.model_name model_name def chat_completion( self, messages: list[dict], tools: list[dict], ) - dict: 模拟模型输出。如果用户消息中包含“天气”关键词 则返回工具调用指令否则返回普通文本。 user_text json.dumps(messages, ensure_asciiFalse) if 天气 in user_text: return { role: assistant, content: 我来帮你查询天气信息。, tool_calls: [ { id: call_001, name: get_weather, arguments: {city: 北京}, } ], } return { role: assistant, content: 这是一个模拟回复实际使用时请替换为真实模型 API。, tool_calls: [], }这个类的重点不是要模拟得多像而是要展示一个关键流程模型工具调用结果会由网关解析交给 MCPGateway 执行最终再返回给上层。生产环境的chat_completion应该被替换成真实的 OpenAI / Anthropic / 自研模型 SDK 调用。4.6 组装 FastAPI 入口接下来在main.py中把模型路由器和 MCP 网关组合起来并对外暴露 HTTP API。# 文件路径main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field from model_router import ModelRouter, ModelInfo from mcp_gateway import MCPGateway from llm_client import MockLLMClient def init_models() - list[ModelInfo]: 初始化模型列表。实际项目中从配置中心或数据库读取。 return [ ModelInfo( namefast-lite, providerexample, cost_per_1k_tokens0.001, avg_latency_ms300, supports_tool_callsFalse, capabilities{chat}, ), ModelInfo( nameagent-pro, providerexample, cost_per_1k_tokens0.01, avg_latency_ms800, supports_tool_callsTrue, capabilities{chat, tool_call, reasoning}, ), ModelInfo( namecode-expert, providerexample, cost_per_1k_tokens0.02, avg_latency_ms1000, supports_tool_callsTrue, capabilities{code, tool_call}, ), ] def init_gateway() - MCPGateway: 注册演示工具。 gateway MCPGateway() def get_weather(arguments: dict) - dict: city arguments.get(city, 未知城市) return {city: city, weather: 晴, temperature: 25} def calculator(arguments: dict) - dict: expr arguments.get(expr, 0) # 演示用途实际应使用安全表达式解析库 try: result eval(expr, {__builtins__: {}}, {}) return {expr: expr, result: result} except Exception: return {expr: expr, error: 表达式错误} gateway.register_tool( nameget_weather, description查询指定城市的天气情况, input_schema{ type: object, properties: { city: {type: string, description: 城市名称}, }, required: [city], }, handlerget_weather, target_serverlocal, ) gateway.register_tool( namecalculator, description执行简单的算术运算, input_schema{ type: object, properties: { expr: {type: string, description: 算术表达式}, }, required: [expr], }, handlercalculator, target_serverlocal, ) return gateway app FastAPI(titleModel Router with MCP Gateway) router ModelRouter(init_models()) gateway init_gateway() class ChatRequest(BaseModel): messages: list[dict] Field(..., description对话消息列表) task_type: str Field(general, description任务类型general、agent、code) required_capability: str | None Field(None, description必需能力标签) max_cost: float | None Field(None, description成本上限) app.get(/v1/models) def list_models(): 返回当前网关下可用的模型列表。 return {data: router.list_models()} app.get(/mcp/tools) def list_tools(): 返回 MCP 工具注册表中的全部工具。 return {tools: gateway.list_tools()} app.post(/v1/chat/completions) async def chat_completions(req: ChatRequest): 统一入口先选模型再决定是否需要走 MCP 工具链路。 # 1. 模型路由 try: model router.route( task_typereq.task_type, required_capabilityreq.required_capability, max_costreq.max_cost, ) except ValueError as exc: raise HTTPException(status_code400, detailstr(exc)) client MockLLMClient(model.name) # 2. 如果选出的模型支持工具调用把工具列表注入上下文 tools gateway.list_tools() if model.supports_tool_calls else [] # 3. 调用模型此处替换为真实大模型 SDK response client.chat_completion(req.messages, tools) # 4. 处理模型返回的工具调用指令 tool_results [] for call in response.get(tool_calls, []): tool_name call.get(name) tool_args call.get(arguments, {}) result await gateway.call_tool(tool_name, tool_args) tool_results.append({ tool_name: tool_name, arguments: tool_args, result: result, }) # 5. 返回完整响应 return { model: model.name, message: { role: assistant, content: response.get(content, ), }, tool_results: tool_results, } if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)整体流程已经完整呈现请求进来后先通过router.route()选出模型。如果模型支持工具调用就从gateway.list_tools()拉取工具列表。调用模型得到回复文本以及可能的工具调用指令。网关执行工具并把结果返回给上层。4.7 运行与验证在项目根目录执行uvicorn main:app --host 0.0.0.0 --port 8000启动成功后先看模型列表curl http://localhost:8000/v1/models返回结果大致是{ data: [ { name: fast-lite, provider: example, supports_tool_calls: false, capabilities: [chat] }, { name: agent-pro, provider: example, supports_tool_calls: true, capabilities: [chat, tool_call, reasoning] }, { name: code-expert, provider: example, supports_tool_calls: true, capabilities: [code, tool_call] } ] }再看工具列表curl http://localhost:8000/mcp/tools接下来测试一次带工具调用的请求。使用task_typeagent让模型路由到agent-pro并触发天气工具调用curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { messages: [{role: user, content: 北京明天天气怎么样}], task_type: agent }由于MockLLMClient检测到“天气”关键词返回响应如下{ model: agent-pro, message: { role: assistant, content: 我来帮你查询天气信息。 }, tool_results: [ { tool_name: get_weather, arguments: { city: 北京 }, result: { ok: true, content: { city: 北京, weather: 晴, temperature: 25 } } } ] }这里我故意把 Gateway 的工具注册表设计在模型路由之后。这样你就能直观看到同一个入口既能完成模型选择也能完成 MCP 工具调用链路。真实系统中返回给上层的内容通常会经过再次封装把工具结果重新喂回模型生成最终回答上面示例保留了这个扩展点。5. 常见问题与排查思路5.1 工具调用了但模型没有选择正确的工具问题现象常见原因解决思路模型不调用工具直接编造结果工具描述不清晰或上下文没携带工具列表检查list_tools()是否注入优化工具描述和参数 schema模型调用已下线的工具工具注册表与模型路由层缓存不一致网关层增加工具版本控制发布下线时同步刷新工具参数解析失败模型返回的参数与 inputSchema 不匹配参数校验层增加容错必要时用大模型二次修正参数5.2 MCP 请求超时或连接失败远程 MCP Server 是独立服务时网络抖动、服务重启、协议版本不兼容都会导致调用失败。建议方案网关侧为每个 MCP Server 设置独立的超时时间避免一个慢服务拖垮整体链路。重试要有次数上限并且区分“幂等工具”和“非幂等工具”非幂等操作不应盲目重试。把 MCP Server 的日志与网关日志关联起来最简单的方式是在请求入口生成request_id在日志中透传。5.3 网关成为新的单点瓶颈引入网关层后最担心的是它成为性能和可用性上的瓶颈。应对思路网关尽量无状态工具注册表放在 Redis 或配置中心实例可以水平扩展。远程 MCP 调用使用连接池避免每个请求都重新建连。网关自身的版本发布与 MCP Server 的解耦要彻底不能因为网关重启导致工具全部不可用。6. 最佳实践与工程建议6.1 路由决策要显式化、可观测不要把所有路由逻辑堆在一个大函数里。建议把“路由策略”抽象成独立模块支持配置化或插件化。每次路由决策都输出结构化日志记录输入特征、候选模型、选择原因、最终模型。只有决策可回溯线上出现效果问题时才能快速定位。6.2 工具注册表采用配置中心管理MCP 网关的工具列表不要硬编码在代码里。正确做法是把工具定义放到 Apollo、Nacos 或专门的数据库中网关启动时加载运行期监听变更。工具上线、下线、灰度发布都走配置中心流程。这样可以避免“代码发布才能增删工具”的低效模式。6.3 密钥与权限分离管理MCP Server 的访问密钥、模型厂商的 API Key 都属于敏感信息不能散落在网关配置或代码仓库里。建议模型密钥和 MCP Server 密钥分开存储按服务维度授权。网关对外只暴露最小权限接口内部 Server 的密钥不向下透传。所有工具调用都经过鉴权不同业务方只能看到自己有权限的工具。6.4 错误处理要区分“模型错误”和“工具错误”一次请求既有模型调用又有工具调用错误类型要区分开。模型限流、模型超时、工具不存在、工具执行异常应该分别返回不同错误码并触发不同的重试和降级策略。否则上层只能看到一个统一的 500排障成本会很高。6.5 上下文组装要控制 Token 消耗工具列表和工具结果都会占用模型上下文。工具特别多的时候不能一股脑把所有工具描述都塞给模型。建议按关键词或语义相似度先做工具召回只把最可能的工具描述传给模型。工具返回结果要截断避免超长 JSON 撑爆上下文。对固定工具结果做缓存减少重复调用。6.6 生产环境建议使用官方 MCP SDK本文示例为了演示把 MCP 协议简化成了本地 handler生产环境应当直接使用官方 SDK 或成熟的开源实现。MCP 协议包含初始化握手、能力协商、流式响应、错误码等细节自己实现很容易在边界情况下踩坑。6.7 为网关建立独立的监控大盘网关承载了模型路由和工具路由两个链路建议监控以下指标分类指标流量请求量、模型维度调用量、工具维度调用量性能路由决策耗时、模型响应耗时、MCP 调用耗时稳定性模型错误率、工具错误率、超时率成本各模型 Token 消耗、成本预估这些指标可以输出到 Prometheus配合 Grafana 展示也可以在阿里云 ARMS、日志服务等平台做链路追踪。7. 总结与学习路线模型路由器解决的是“用哪个模型”的问题MCP 网关解决的是“模型如何调用外界工具”的问题。两者拆开看各有边界但放在真实 AI Agent 场景里它们的决策发生在同一条请求链路上分享同一个模型上下文。把 MCP 网关能力内建到模型路由器中业务方只需要对接一个入口就能完成模型选择、工具发现、工具调用、结果回填的完整闭环。如果你打算从零搭建这样一套能力我的建议是按以下顺序深入学习先吃透 MCP 协议的核心规范理解 Client、Server、Tools、Resources 之间的关系。动手实现一个最简单的 MCP Server暴露一个自定义工具并手工用 JSON-RPC 消息调用它。在模型路由层加入路由策略先做“按任务类型选择模型”的简单规则。把两部分通过网关组装起来完成“模型选型 - 工具调用 - 结果返回”的闭环。再逐步补充配置中心、权限体系、可观测性和成本控制。当前 MCP 生态还在快速发展工具协议、SDK 版本、各家模型的 function calling 能力都在迭代不要指望一套代码写死跑三年。更值得投资的是架构边界的划分能力只要路由层和网关层的边界足够清晰底层协议怎么升级都不影响整体稳定性。本文的完整示例代码可以直接在本地跑通把它改造成真实连接 OpenAI / Anthropic / MCP Server 的版本只差一步替换llm_client.py和工具 handler你在自己项目中遇到的具体问题也会在这个实践过程里自然浮现出来。如果这篇文章对你有帮助收藏备用后续实践过程中有新的踩坑经验再来一起交流。