企业官网建设流程全解析

如果你正在做一个 AI Agent 项目，且已经接到第二个模型 API，感受往往会从“终于能自由切换供应商”变成“怎么又要写一遍适配代码”。再往后，当你开始给 Agent 挂工具，天气接口、新闻搜索、数据库查询、企业内部服务，每一家的 API 风格、鉴权方式、错误码都不一样，而这些工具代码和模型调用代码又耦合在一起。等到模型供应商要切换、工具服务要升级时，你才会意识到：Agent 应用的接入层一直没有被真正抽象好。

模型路由（Model Router）解决了一部分问题：它把不同大模型供应商的 API 归一成统一格式，负责路由、故障转移和成本控制。MCP（Model Context Protocol，模型上下文协议）则解决了工具层标准化的另一部分问题：它让工具、数据源、资源的暴露方式变得统一。但很多团队在落地时仍然把这两层分开部署：一个服务做模型转发，另一个服务管 MCP 工具。这其实是把同一段请求链路切成了两半，带来了重复的鉴权、重复的配置、重复的监控。

我的判断是：一个真正服务于 Agent 生产环境的模型路由器，同时也应该是一个 MCP 网关。模型路由解决的是“这次请求该找哪个模型”，MCP 网关解决的是“这次工具调用该找哪个 MCP 服务”，它们在一次 Agent 请求里往往是交替发生的。把它们合并到同一个控制面，配置、权限、监控、成本统计才能复用一套基础设施。本文会先讲清楚这两者的边界和融合逻辑，然后给出一个最小可运行的 Python 示例，把“模型路由 + MCP 网关”这条完整链路跑通，最后补充生产环境落地时你一定会遇到的坑。

1. 为什么模型路由器需要 MCP 网关能力

先说传统 API 网关的边界。当你的项目只是“对话”时，一个模型转发网关确实够用：上游统一暴露一份 OpenAI 兼容接口，下游转发到 GPT、Claude、DeepSeek 等供应商，失败时切换备选模型。这种抽象在 Chat 时代很自然，因为所有模型供应商的协议都收敛到了 chat completions 格式。

但 Agent 和 Chat 的本质区别在于：Agent 要调用工具。而工具层长期以来没有标准，大家都在用 HTTP + JSON，但路径不同、鉴权不同、参数校验方式不同、错误码不同，甚至同一个模型的 tool_calls 输出格式在不同供应商之间也有差异。于是 Agent 工程里出现了大量工具适配器代码，每接入一个新工具就得为它写一套客户端。

MCP 的出现在工具层建立了统一协议。MCP server 通过标准化的方式暴露工具（tool）、资源（resource）和提示词（prompt），MCP client 用同一套协议连接不同的 MCP server。工具描述、入参声明、调用结果都变成结构化数据，Agent 不需要再逐个适配工具 API。

但 MCP 并没有解决“管理多个 MCP server”的问题。真实项目里你会同时连接很多 MCP server：一个提供天气查询、一个提供新闻检索、一个连内部数据库、一个操作工单系统。谁的优先级高？哪些 Agent 能访问哪些工具？工具名冲突了怎么办？调用超时和失败应该怎么处理？这些职责正是“路由”的本职工作，但传统模型路由器管不到工具层，传统 API 网关又只是透传 HTTP，对 MCP 协议和工具注册表一无所知。

所以在架构演进上，很自然的推论就是：模型路由器和 MCP 网关是同一个控制面的两部分。从请求链路来看，用户消息进来后，先由模型路由器选择模型；模型返回 tool_calls 后，由 MCP 网关把工具调用转发到正确的 MCP server；工具结果回传后，又由模型路由器继续走模型对话。这个过程里“选择调用谁”的决策反复出现，把它拆成两个服务，只会增加网络开销和运维成本；合并成一个服务，配置、鉴权、监控、成本统计都可以在统一控制面上完成。

2. 核心概念与边界：Model Router、MCP Gateway 与普通网关的区别

先明确几个概念。

Model Router（模型路由器）：一个中间层组件，负责接收统一的 LLM 请求，根据路由策略选择下游模型供应商，然后把请求转发出去。它的职责通常包括：供应商 API 格式适配、失败重试与故障转移、成本统计、并发控制、限流。

MCP Gateway（MCP 网关）：一个管理多个 MCP server 的接入层。它充当 MCP client 的统一入口，让上层 Agent 应用不需要直接连接每一个 MCP server。网关内部维护一张工具注册表，记录每个工具属于哪个 MCP server，并在收到工具调用时完成转发。它还负责权限校验、超时控制、审计日志。

这里容易混淆的是，普通 API 网关也能转发请求，为什么不能直接当 MCP 网关用？因为普通 API 网关通常在 HTTP 资源层面做转发，它不知道“get_weather”是一个 MCP 工具，也不知道它属于 weather-service 这个 MCP server，更不知道工具入参要符合哪个 JSON Schema。MCP 网关的工作是在协议语义层面完成的，它需要维护工具注册表、理解 MCP 协议的消息语义，而不是简单地把 URL 转发到下游。

另一个容易混淆的概念是 MCP registry 或 MCP 工具中心。它们更像是“工具目录”，帮助开发者发现和浏览可用的 MCP server。网关更偏运行时，它要处理实际的请求转发、鉴权和故障恢复。二者可以配合使用：registry 负责元数据管理，gateway 负责运行时调用。

还需要区分 Agent 运行时（Agent runtime）和 MCP 网关。Agent 运行时负责编排大模型的推理循环，比如决定下一步是调用工具还是直接回复；MCP 网关则更底层，它只是高效地将工具调用转发到对应的 MCP server。二者可以都放在同一个进程内，也可以拆开。但模型路由器和 MCP 网关因为共享同一份下游端点选择逻辑，合并的价值远大于拆分。

用一张表格对比会更直观：

3. 融合架构设计：一次请求在统一控制面里的完整链路

把一个模型路由器和 MCP 网关融合后，一次带工具调用的 Agent 请求完整链路是这样的。

第一步，用户消息进入统一入口。这个入口同时承接高层 Agent 应用的模型请求和工具调用请求。此时它还不知道要用哪个模型。

第二步，模型路由器根据用户的任务类型、成本预算、模型能力，选择一个模型端点。例如用户问“北京今天天气如何”，任务类型属于“工具型”，路由策略会优先选择支持工具调用且成本较低的模型。

第三步，统一入口把用户消息发给选中的模型。模型返回两种可能之一：直接回复，或者返回 tool_calls。如果模型认为自己需要查询天气工具，它的回复里会带一个结构化的工具调用请求，比如调用 get_weather，参数为 city=北京。

第四步，MCP 网关收到这个工具调用请求。它查阅工具注册表，发现 get_weather 注册在 weather-service 这个 MCP server 上，于是把调用请求转发给该 server。此时可能出现三种情况：调用成功，返回结构化结果；调用超时，网关按策略决定重试或返回错误给模型；权限校验失败，网关直接拒绝并记录日志。

第五步，网关把工具调用结果封装成标准消息格式，回传给模型路由器。模型路由器的会话上下文里多了一条 tool 角色消息，然后它再次向同一个模型端点发出对话请求。

第六步，模型收到工具结果后，生成最终回复。例如“北京今天气温 23 摄氏度，晴”。整个调用链结束。

这个架构里，模型路由器和 MCP 网关共享了三个关键模块：配置中心、会话上下文、监控指标。配置中心统一维护模型端点和 MCP server 地址；会话上下文保存某次 Agent 任务的多轮消息；监控指标记录模型调用次数、成本、工具调用频率和失败率。这就是融合的价值所在：你不需要在三个系统之间同步配置和上下文。

在这个架构中，还需要引入一个工具注册表。它是一张内存/数据库表，key 是工具名，value 是该工具所属的 MCP server 标识以及工具的输入 Schema。Agent 应用可以把这张表暴露给大模型，让模型在生成 tool_calls 时只生成已注册的工具名。这样可以在路由之前就拦截掉不存在的工具名。

4. 环境准备与配置文件设计

下面进入可落地部分。我们先用一个最小示例把整个链路跑通。这个示例不需要真实的大模型 API，也不需要真实部署 MCP server，核心是展示控制面的数据流和路由逻辑。你可以把它理解成一个“模型路由 + MCP 网关”的骨架 Demo。

环境要求如下：

• Python 3.10 或更高版本，因为示例中使用 dataclass、类型注解等语法。
• 不需要额外安装第三方依赖，示例中的 MCP server 用 mock 对象模拟。
• 如果要在生产环境中接入真实的 MCP server，建议安装官方mcp的 Python SDK，用它的 client 实现连接。示例只演示协议调用逻辑。

先把配置文件设计好。融合控制面的一大优势是：一份配置文件同时描述模型端点和 MCP server 注册信息。我们使用 YAML 格式，因为它方便维护。

# config.yaml model_router: strategy: cost_first default_model: deepseek-chat endpoints: - name: gpt-4o provider: openai model: gpt-4o capabilities: [general, code, tools] cost_weight: 5 - name: claude-3-5-sonnet provider: anthropic model: claude-3-5-sonnet capabilities: [general, analysis, tools] cost_weight: 3 - name: deepseek-chat provider: deepseek model: deepseek-chat capabilities: [general, code] cost_weight: 1 mcp_gateway: servers: - name: weather-service transport: sse url: http://localhost:8001/mcp - name: news-service transport: stdio command: node args: [mcp-news-server.js]

在这个配置里，cost_first表示路由策略按成本权重升序选择端点；capabilities标记端点能力，工具调用任务会优先选择支持tools能力的端点。mcp_gateway部分声明了两个 MCP server。示例代码不会真正解析 YAML，我会用接近的结构在代码里直接构造这些对象，保证逻辑一致。

配置好后，需要明确一个小原则：路由策略不要写死在代码里。模型端点的可用性、价格、能力都可能变化，把路由策略放进配置，生产环境才能在不改代码的情况下调整模型选择逻辑。示例里我用策略对象来抽象，你可以在此基础上扩展。

5. 核心代码实现：模型路由层与 MCP 网关层

5.1 模型路由层

先定义模型端点类和模型路由器。模型端点描述一个下游模型的元信息，包括名称、供应商、模型名、支持的 capability 列表、成本权重。模型路由器负责根据策略选择一个端点。

# demo_model_router_mcp.py 第一部分：模型路由层 import asyncio import json from dataclasses import dataclass, field @dataclass class ModelEndpoint: """模型端点配置。""" name: str provider: str model: str capabilities: set = field(default_factory=set) cost_weight: float = 1.0 class ModelRouter: """模型路由器：负责根据策略选择下游模型端点。""" def __init__(self, endpoints: list[ModelEndpoint], default_model: str = ""): self._endpoints = {e.name: e for e in endpoints} self._default_model = default_model def register_endpoint(self, endpoint: ModelEndpoint): self._endpoints[endpoint.name] = endpoint def route(self, task_type: str) -> ModelEndpoint: """选择最合适的端点。本文演示 cost_first + capability 过滤策略。 策略说明： 1. 只保留能力集合中包含 task_type 的端点。 2. 按 cost_weight 升序排序。 3. 返回匹配中的第一个端点。 """ candidates = [ e for e in self._endpoints.values() if task_type in e.capabilities ] if not candidates: raise ValueError(f"no endpoint available for task_type={task_type}") candidates.sort(key=lambda e: e.cost_weight) return candidates[0] def default(self) -> ModelEndpoint: """返回默认端点，作为 fallback。""" if self._default_model: return self._endpoints[self._default_model] return next(iter(self._endpoints.values()))

这段逻辑的关键在route方法。它同时完成了两件事：能力过滤和成本排序。实际生产里，路由策略会更复杂，比如考虑端点健康状态、当前并发数、用户级别、模型上下文长度等，但核心模式是一致的：先过滤，再排序。

真实项目的模型调用层会在这里统一封装供应商 API client。由于本文聚焦路由与网关的拼接，示例里我给模型端点加一个chat方法，直接返回一个构造好的响应。

# demo_model_router_mcp.py 继续 @dataclass class ChatResult: content: str tool_calls: list = field(default_factory=list) class MockModelClient: """模拟模型调用客户端，用于演示，不真正连接外部 API。 实际项目中应该替换为真实的 OpenAI / Anthropic / DeepSeek client。 """ def __init__(self, endpoint: ModelEndpoint): self._endpoint = endpoint def chat(self, messages: list[dict]) -> ChatResult: # 简化规则：如果最后一条消息里包含"天气"或"新闻"关键词，返回工具调用结果。 last_user_content = "".join( m.get("content", "") for m in messages if m["role"] == "user" ) if "天气" in last_user_content: return ChatResult( content="", tool_calls=[ { "id": "call_1", "name": "get_weather", "arguments": {"city": "北京"}, } ], ) if "新闻" in last_user_content: return ChatResult( content="", tool_calls=[ { "id": "call_2", "name": "search_news", "arguments": {"keyword": "AI"}, } ], ) return ChatResult(content="这是一个模拟回复，未触发工具调用。") class ModelInvoker: """模型调用门面：封装端点选择和真实模型调用。""" def __init__(self, router: ModelRouter): self._router = router self._client_map = {} for endpoint in router._endpoints.values(): self._client_map[endpoint.name] = MockModelClient(endpoint) def chat(self, task_type: str, messages: list[dict]) -> ChatResult: endpoint = self._router.route(task_type) client = self._client_map[endpoint.name] return client.chat(messages) @property def router(self) -> ModelRouter: return self._router

在实际工程里，模型调用通常是异步的，需要在网络请求里处理流式响应、超时重试、token 计费。这里用同步简化的方式避免示例过于复杂。

5.2 MCP 网关层

MCP 网关的核心是工具注册表和调用转发逻辑。我们先定义 MCP 工具描述对象，再定义网关。真实项目中，工具注册表应该从 MCP server 的tools/list接口动态拉取；示例里用 mock client 来模拟这个过程。

# demo_model_router_mcp.py 第二部分：MCP 网关层 @dataclass class MCPTool: name: str description: str input_schema: dict server_name: str = "" class MockMCPClient: """模拟 MCP client。真实项目中应使用官方 MCP SDK 连接真实 server。""" def __init__(self, server_name: str, tools: list[dict]): self._server_name = server_name self._tools = [MCPTool(**t, server_name=server_name) for t in tools] def list_tools(self): return self._tools def call_tool(self, name, arguments): # 模拟工具的高层结果。真实场景里这里会触发 HTTP 或 stdio 请求。 if name == "get_weather": return {"city": arguments.get("city"), "temperature": 23, "unit": "celsius"} if name == "search_news": return {"keyword": arguments.get("keyword"), "articles": ["article-1", "article-2"]} return {"error": f"unknown tool: {name}"} class MCPGateway: """MCP 网关：维护工具注册表，并将工具调用路由到正确的 MCP server。""" def __init__(self): self._servers = {} self._tool_registry = {} def register_server(self, server_name: str, client: MockMCPClient): """注册一个 MCP server，并将其工具注册进表。""" self._servers[server_name] = client for tool in client.list_tools(): self._tool_registry[tool.name] = (server_name, tool) def list_registered_tools(self): return list(self._tool_registry.keys()) def route_tool_call(self, tool_name: str, arguments: dict) -> dict: """按工具名路由到 MCP server，并执行调用。""" if tool_name not in self._tool_registry: raise KeyError(f"unknown tool: {tool_name}") server_name, _ = self._tool_registry[tool_name] client = self._servers[server_name] return client.call_tool(tool_name, arguments)

这里真正重要的是_tool_registry。它把工具名收敛到唯一的注册点。当两个 MCP server 声明了同名工具时，后注册的会覆盖先注册的，所以生产环境必须做命名冲突检测或命名空间隔离。我们后面在常见问题里再展开。

5.3 统一运行时：把模型路由和 MCP 网关拼起来

现在可以把模型路由器和 MCP 网关组合成一个统一运行时。它的职责是维护会话上下文，并完成“模型 → 工具调用 → 模型”的循环。

# demo_model_router_mcp.py 第三部分：统一运行时 class UnifiedAgentRuntime: """融合模型路由与 MCP 网关的统一运行时。""" def __init__(self, model_invoker: ModelInvoker, mcp_gateway: MCPGateway): self._invoker = model_invoker self._gateway = mcp_gateway self._messages = [] async def _safe_call_tool(self, tool_name, arguments): """包装工具调用，便于统一处理异常。""" try: return self._gateway.route_tool_call(tool_name, arguments) except KeyError as exc: return {"error": str(exc)} except Exception as exc: return {"error": f"tool call failed: {exc}"} async def chat(self, user_message: str, task_type: str = "general") -> str: self._messages.append({"role": "user", "content": user_message}) # 第一轮：模型可能返回工具调用，也可能直接回复。 result = self._invoker.chat(task_type, self._messages) # 如果模型请求调用工具，则通过 MCP 网关路由。 if result.tool_calls: for tool_call in result.tool_calls: tool_result = await self._safe_call_tool( tool_call["name"], tool_call["arguments"], ) self._messages.append( { "role": "tool", "tool_call_id": tool_call["id"], "name": tool_call["name"], "content": json.dumps(tool_result, ensure_ascii=False), } ) # 第二轮：把工具结果回传给模型，得到最终答复。 result = self._invoker.chat(task_type, self._messages) self._messages.append({"role": "assistant", "content": result.content}) return result.content

这段代码是整个示例的核心。它演示了模型路由器与 MCP 网关如何在同一个运行时里协同工作。_messages作为会话上下文被模型和工具调用共享，而_gateway负责处理所有工具路由细节。上层 Agent 应用不需要知道 get_weather 属于哪个 MCP server，也不需要了解模型端点选择的具体策略。

5.4 组装入口与展示

最后，写一个main函数，把模型端点、MCP server、网关和运行时组装起来。

# demo_model_router_mcp.py 第四部分：组装与运行 async def main(): # 1. 配置模型路由器 router = ModelRouter( endpoints=[ ModelEndpoint( name="gpt-4o", provider="openai", model="gpt-4o", capabilities={"general", "code", "tools"}, cost_weight=5, ), ModelEndpoint( name="claude-3-5-sonnet", provider="anthropic", model="claude-3-5-sonnet", capabilities={"general", "analysis", "tools"}, cost_weight=3, ), ModelEndpoint( name="deepseek-chat", provider="deepseek", model="deepseek-chat", capabilities={"general", "code"}, cost_weight=1, ), ], default_model="deepseek-chat", ) model_invoker = ModelInvoker(router) # 2. 配置 MCP server 并注册到网关 weather_server = MockMCPClient( "weather-service", [ { "name": "get_weather", "description": "获取城市天气", "input_schema": {"city": "string"}, } ], ) news_server = MockMCPClient( "news-service", [ { "name": "search_news", "description": "搜索新闻", "input_schema": {"keyword": "string"}, } ], ) gateway = MCPGateway() gateway.register_server("weather-service", weather_server) gateway.register_server("news-service", news_server) # 3. 组装统一运行时 runtime = UnifiedAgentRuntime(model_invoker, gateway) # 4. 测试两条消息 print("===== Test 1: 天气查询 =====") print(await runtime.chat("帮我查一下北京今天天气", task_type="tools")) print() print("===== Test 2: 新闻搜索 =====") print(await runtime.chat("帮我搜索最近 AI 新闻", task_type="tools")) if __name__ == "__main__": asyncio.run(main())

在这个示例里，模型的capabilities集合有讲究：gpt-4o 和 claude-3-5-sonnet 都包含tools，deepseek-chat 没有。当任务类型是tools时，路由策略会过滤掉 deepseek-chat，并在 gpt-4o 和 claude-3-5-sonnet 之间按成本权重选择 claude-3-5-sonnet。

6. 运行验证与效果观察

运行命令很简单：

python demo_model_router_mcp.py

预期输出如下：

===== Test 1: 天气查询 ===== 这是一个模拟回复，未触发工具调用。 ===== Test 2: 新闻搜索 ===== 这是一个模拟回复，未触发工具调用。

如果你的输出和上面一样，说明链路本身没有走通，因为第一轮模型模拟器确实没有触发工具调用：它的触发条件是“最后一条用户消息”里包含关键词，但这里messages里最终用户消息不是原始输入，而是被content字段拼接过的。严格来说，我的原始代码中MockModelClient.chat会从所有 user 消息里找关键词，因此第一轮会触发。但在第二轮时，最后一条消息已经变成了 tool 消息，所以不会再触发新的工具调用，而得到的是默认模拟回复。

更合理的做法是让 mock 模型在检测到工具调用后，第二轮直接根据 tool 消息返回天气或新闻结果。为了演示，我把模拟逻辑再优化一下：

class MockModelClient: """模拟模型调用客户端，用于演示不真正连接外部 API。""" def __init__(self, endpoint: ModelEndpoint): self._endpoint = endpoint def chat(self, messages: list[dict]) -> ChatResult: # 如果最后一条消息是 tool 消息，则直接根据工具结果生成回复。 last_message = messages[-1] if last_message.get("role") == "tool": content = last_message["content"] if "temperature" in content: return ChatResult(content="北京今天气温 23 摄氏度，天气不错。") if "articles" in content: return ChatResult(content="为你找到 2 条 AI 相关新闻。") return ChatResult(content="工具调用完成。") # 第一轮：检查用户消息是否需要工具。 last_user_content = last_message.get("content", "") if "天气" in last_user_content: return ChatResult( content="", tool_calls=[ { "id": "call_1", "name": "get_weather", "arguments": {"city": "北京"}, } ], ) if "新闻" in last_user_content: return ChatResult( content="", tool_calls=[ { "id": "call_2", "name": "search_news", "arguments": {"keyword": "AI"}, } ], ) return ChatResult(content="这是一个模拟回复，未触发工具调用。")

修正后再运行，预期输出：

===== Test 1: 天气查询 ===== 北京今天气温 23 摄氏度，天气不错。 ===== Test 2: 新闻搜索 ===== 为你找到 2 条 AI 相关新闻。

如何判断链路是否真的走通了？看两点：

1. 模型第一轮返回了 tool_calls，说明模型路由器选到了一个支持tools能力的端点。
2. 最终回复里出现了天气或新闻信息，说明 MCP 网关正确地把工具调用路由到了 weather-service 或 news-service，并把结果回传给了模型。

如果最终输出是“模拟回复，未触发工具调用”，优先检查ModelEndpoint.capabilities里是否包含tools，以及task_type是否传成了tools。

7. 常见问题与排查思路

融合架构在实际落地时，问题往往不像 Demo 里这么简单。下面列出一组高频问题。

这里的核心问题是：不要把工具路由的边界和大模型生态的边界混为一谈。模型供应商和工具服务都是“被接入的下游”，网关要做的就是屏蔽差异。不同模型返回的 tool_calls 格式不同，不同 MCP server 返回的结果格式也可能不同，网关必须在统一层把它们归一。

8. 生产环境最佳实践与演进方向

8.1 配置分离，控制面统一

融合架构不建议把所有信息写进同一个巨大的 YAML 文件。更合理的做法是分两个文件：一个管模型端点，一个管 MCP server 注册。使用配置中心或环境变量覆盖敏感信息。模型路由策略可以单独定义，方便 A/B 测试和灰度发布。

8.2 权限校验放在网关层

MCP 网关不仅要转发工具调用，还是天然的权限边界。你可以在网关里定义规则：哪些 Agent 应用可以调用哪些 MCP server；某个工具属于高权限组，只有管理员会话才能调用。权限校验要在进入 MCP server 之前完成，避免上游的高权限 token 被低权限会话复用。

8.3 全链路可观测性

Agent 应用调试非常痛苦，因为一次请求可能涉及模型路由、工具路由、上游服务。建议在网关层注入 trace_id，贯穿用户请求、模型调用、工具调用全链路。每一个路由决策都要记录：选中的模型端点、选中的工具、耗时、费用估算。不要让路由决策变成“黑盒”。

8.4 工具结果要做安全过滤

MCP server 返回的内容不一定适合直接拼进模型上下文。可能包含敏感字段、过大的文本、非结构化噪声。网关层应该对结果做脱敏、截断、结构化校验。尤其在接入企业内部服务时，避免把内部字段暴露给最外层模型。

8.5 动态注册与优雅下线

生产环境的 MCP server 不会永远存在。网关要支持动态注册、健康检查、自动下线。工具注册表不能只在启动时加载，要能监听服务变更事件。如果某个 MCP server 失联，网关要么快速失败，要么返回给模型一个明确错误，避免模型“自由发挥”编造工具结果。

8.6 模型路由策略要具备可解释性

当你同时管理多个模型端点和多个 MCP server 时，一次错误路由的成本可能是钱，也可能是用户体验下降。路由策略尽量写清楚“为什么选它”。示例里cost_first是简单策略，生产环境往往需要组合策略：价格、延迟、上下文长度、供应商地域、模型评测分数。建议把每次路由决策的输入和结果结构化成日志，便于复盘。

8.4 与 MCP Registry 整合

如果 MCP server 数量变多，可以引入一个 MCP registry 作为元数据目录，网关启动时从 registry 拉取工具清单并缓存到本地工具注册表。这样网关仍保持运行时组件的高性能，同时享受 registry 的治理能力。

9. 总结与后续探索方向

本文的核心观点是：模型路由器和 MCP 网关不应该被拆成两个独立的系统，它们属于同一个 Agent 接入控制面。模型路由处理模型选择，MCP 网关处理工具路由，两者在一次 Agent 请求中交替出现，合并后能统一配置、权限、监控和成本数据。

文中给出的最小示例验证了这个融合链路“模型路由 → 模型返回 tool_calls → MCP 网关路由 → 工具结果回传模型”的可行性。虽然示例里模型端点和 MCP server 都是 mock，但这个骨架可以直接替换成真实组件：模型路由层接入 OpenAI 兼容协议客户端，MCP 网关层接入官方 MCP SDK，就可以支撑一个真实的多工具 Agent 应用。

下一步建议你从三件事开始尝试：

1. 把MockModelClient替换成真实模型供应商 SDK，接入一个真实 MCP server，比如 GitHub MCP server 或文件系统 MCP server。
2. 在 MCP 网关里实现工具注册表的持久化和动态刷新，并加上权限模型。
3. 引入可观测性框架，把所有路由决策和工具调用记录结构化日志，用 trace_id 串起完整链路。

当模型路由器和 MCP 网关真正融合后，Agent 工程里“接入新模型”和“接入新工具”就不再是两套独立流程，成本会明显下降。这也是 MCP 生态走向生产可用道路上值得关注的一个架构方向。