[!info] related notes

• 所属 MOC: docker-mcp-toolkit-moc, mcp-moc
• 核心概念: docker-mcp-gateway
• 相关配置: mcp-client-configuration
• 关联笔记: ai-ability-and-protocol

MCP Gateway 架构演进

主题范围

本文解释 MCP 工具调用架构从”网状直连”到”星型网关”的演进过程，以及为什么 Docker MCP Gateway 能解决多客户端配置重复的痛点。

为什么要把这些概念放在一起理解

当开发者同时使用多个 AI 客户端（Copilot、OpenCode、Codex）和多个 MCP Server（数据库、搜索、文件系统）时，会面临 M×N 的配置复杂度问题。理解架构演进有助于选择正确的工具链方案。

架构演进路径

第一阶段：网状直连（M×N 复杂度）

┌─────────┐     ┌─────────────┐
│ Copilot │────→│ MCP Server A│
└─────────┘     └─────────────┘
     │
     │          ┌─────────────┐
     └─────────→│ MCP Server B│
                └─────────────┘

┌─────────┐     ┌─────────────┐
│ OpenCode│────→│ MCP Server A│
└─────────┘     └─────────────┘
     │
     │          ┌─────────────┐
     └─────────→│ MCP Server B│
                └─────────────┘

问题：

• 每个客户端重复配置相同的 Server 路径、API Key
• 不同 Server 依赖不同运行环境（Node.js, Python, uvx）
• 密钥散落在各个配置文件中
• 更新 API Key 需要修改 N 个文件

第二阶段：星型网关（N+1 复杂度）

┌─────────┐
│ Copilot │──────┐
└─────────┘      │
                 ▼
┌─────────┐  ┌─────────┐     ┌─────────────┐
│ OpenCode│──→│ Gateway │────→│ MCP Server A│
└─────────┘  └─────────┘     └─────────────┘
                 │
┌─────────┐      │           ┌─────────────┐
│  Codex  │──────┴──────────→│ MCP Server B│
└─────────┘                  └─────────────┘

优势：

• 所有客户端只需配置 Gateway 一个入口
• Server 运行在隔离容器中，无环境冲突
• API Key 统一管理，单点修改全局生效
• 新增工具后所有客户端立即可用

对比表

维度	网状直连	星型网关
配置复杂度	M×N（客户端×服务器）	M+1（客户端+网关）
环境管理	各客户端需独立安装依赖	容器化隔离，无需本地依赖
密钥安全	散落各配置文件	Docker Secrets 统一管理
更新成本	修改 N 个文件	修改 1 处全局生效
资源占用	各客户端独立启动进程	共享容器，资源更优
依赖条件	无额外依赖	需要 Docker Desktop 运行

易混淆点

Gateway 不等于 Agent

• Gateway：负责路由和代理，是通信中间层
• Agent：负责任务编排和决策，是智能执行层

Gateway 让 Agent 更容易调用工具，但本身不参与决策。

Gateway 不等于 MCP Server

• Gateway：代理多个 Server，提供统一入口
• MCP Server：提供具体工具能力（如搜索、文件操作）

相关专题

• ai-ability-and-protocol：MCP、Skills 与 Agent 在前端研发中的作用
• what-is-mcp-interview-question：MCP 面试问题
• docker：Docker 容器基础

Related notes

• Docker MOC
• MCP MOC
• MCP
• MCP 客户端配置指南