MCP 与大模型生态版图：开源闭源如何选型

MCP 与大模型生态版图：开源闭源如何选型

大模型能力再强，最终都要落地成"能调用工具、能读写数据、能和其他系统协作"的产品。这就带来两个绕不开的工程问题：第一，模型和外部世界（文件、数据库、API）之间怎么标准化对接；第二，业务方到底该选闭源 API 还是自己部署开源模型。本文分别讲清楚 MCP（Model Context Protocol）这套连接协议，以及当前开源与闭源模型的版图和选型思路。

这两个话题看似分属"技术"和"决策"两个层面，实际上是一枚硬币的两面：MCP 让你可以低成本地切换和混用不同来源的模型，而"开源 vs 闭源"的选型则决定了你到底要接入哪些模型。理解了 MCP，选型时就不必担心被某一家厂商锁死；想清楚了选型逻辑，才知道该用 MCP 把哪些模型和工具接进来。

🔌 MCP 是什么：先理解它要解决的问题

在 MCP 出现之前，如果你想让一个 AI 应用同时具备"读取本地文件""查询公司数据库""调用 Jira 创建工单""访问 Slack 消息"这几种能力，通常要为每一种数据源/工具单独写一套定制集成代码：Slack 有 Slack 的 SDK 和鉴权方式，Jira 有 Jira 的 API 格式，本地文件系统又是另一套读写逻辑。如果你同时维护多个 AI 应用（比如一个 IDE 插件、一个聊天机器人、一个自动化 Agent），这些集成代码还要在每个应用里重复写一遍。集成方数（M 个应用）乘以数据源数（N 个工具），复杂度是 M×N 的组合爆炸。

这正是 USB 接口出现之前电脑外设的处境：每一种打印机、鼠标、扫描仪都可能需要专属的接口和驱动程序。USB 统一之后，只要设备遵循 USB 协议、电脑有 USB 接口，任意设备插任意电脑都能用，M×N 的问题被拆解成了 M+N：设备厂商只需要适配一次 USB 标准，电脑厂商也只需要实现一次 USB 接口。

MCP（Model Context Protocol，模型上下文协议）就是 AI 应用世界里的这个"USB 接口"。它由 Anthropic 在 2024 年底提出并开源，核心思路是：定义一套标准化的协议，只要一个 AI 应用（Host）实现了 MCP 客户端能力，就可以对接任意实现了 MCP 服务端协议的数据源或工具，不需要为每一个数据源单独写定制代码。数据源/工具的开发者也只需要按照 MCP 协议规范包装自己的能力一次，就能被所有支持 MCP 的 AI 应用复用。

一个数字直观感受 M×N 到 M+N 的差别

假设你有 5 个 AI 应用、10 个要接入的工具：

| 方案 | 需要写的集成代码套数 | 新增 1 个工具的成本 |

| --- | --- | --- |

| 传统点对点集成 | 5 × 10 = 50 套 | 要为 5 个应用各写一遍 = 5 套 |

| MCP 标准化 | 5 + 10 = 15 套 | 只需写 1 个 MCP Server = 1 套 |

工具和应用越多，这个差距被放得越大。这就是标准化协议最朴素也最强大的价值：把乘法复杂度变成加法复杂度。

🏗️ MCP 的架构：Host、Client、Server 三者关系

MCP 采用经典的 client-server 架构，但引入了三个角色，理解它们的关系是理解 MCP 的关键：

Host（宿主应用）：用户直接使用的 AI 应用本体，例如 Claude Desktop、某个 IDE 插件、一个自研的 Agent 平台。Host 负责管理整体的对话流程、调用 LLM、决定何时需要外部能力。

MCP Client（客户端）：内嵌在 Host 内部的连接组件，每个 Client 与一个 MCP Server 建立一对一的连接，负责协议层面的通信（发送请求、接收响应、处理生命周期）。一个 Host 可以同时维护多个 Client，分别连接不同的 Server。

MCP Server（服务端）：对某一类数据源或工具能力的标准化封装，比如"文件系统 Server""GitHub Server""数据库 Server"。Server 独立于 Host 运行（可以是本地进程，也可以是远程服务），把底层能力翻译成 MCP 协议定义的接口暴露出去。

三者关系可以简单理解为：Host 是"电脑主机"，MCP Client 是"USB 接口"，MCP Server 是"USB 设备"。同一台电脑（Host）可以通过多个 USB 口（Client）同时接多个设备（Server），而同一个 USB 设备（Server）也能插到任何一台带 USB 口的电脑（不同 Host）上。

MCP Server 能提供三类能力

一个 MCP Server 通过协议向外暴露的能力分为三类：

Tools（工具）：可被模型主动调用、会产生副作用或返回计算结果的函数，例如"发送邮件""执行 SQL 查询""创建 GitHub Issue"。这是最接近 Function Calling 的部分，由模型根据对话上下文自主决定是否调用、传什么参数。

Resources（资源）：可被读取的只读数据，例如某个文件的内容、一条数据库记录、一份日志。Resources 更像是"喂给模型的上下文素材"，通常由 Host 应用或用户主动选择附加到对话中，而不是模型自主决定拉取。

Prompts（提示模板）：Server 预先定义好的、参数化的提示词模板，方便用户或 Host 快速复用某个 Server 领域内的最佳实践提示，例如一个 Git Server 可以内置"生成 commit message""总结 PR 变更"这样的模板。

用一句话区分这三者：Tools 是"模型能主动按的按钮"，Resources 是"人喂给模型看的资料"，Prompts 是"预置好的话术模板"。控制权的归属不同，是它们最本质的区别。

一个简单的 MCP Server 配置示例

主流 Host（如 Claude Desktop）通常用一份 JSON 配置来声明要启动哪些 MCP Server，典型写法如下：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxxxxxx"
      }
    }
  }
}

Host 启动时会读取这份配置，为每一个条目拉起对应的 MCP Server 进程（这里用的是 stdio 方式通信，也支持基于 HTTP/SSE 的远程 Server），并自动建立 Client 连接、拉取该 Server 暴露的 tools/resources/prompts 列表，供模型在对话中按需调用。

动手写一个最小的 MCP Server

理解协议最快的方式是自己写一个 Server。下面用官方 Python SDK 写一个只提供"两数相加"工具的极简 Server，帮助建立直观认识：

from mcp.server.fastmcp import FastMCP

# 创建一个名为 calculator 的 MCP Server
mcp = FastMCP("calculator")

@mcp.tool()
def add(a: float, b: float) -> float:
    """把两个数相加并返回结果"""
    return a + b

@mcp.tool()
def multiply(a: float, b: float) -> float:
    """把两个数相乘并返回结果"""
    return a * b

# 暴露一个只读资源：当前服务器版本
@mcp.resource("config://version")
def version() -> str:
    return "calculator-server v1.0.0"

if __name__ == "__main__":
    mcp.run()  # 默认通过 stdio 与 Host 通信

把这个 Server 注册进 Host 配置后，模型在对话中就能自主决定"这里需要精确计算"，进而调用 add 或 multiply——注意，模型本身不会算数，它只是发出调用意图，真正的计算由这个 Server 完成，结果再回传给模型。这也解释了 MCP 的价值：模型负责决策，Server 负责能力，二者通过标准协议对接。

本地 Server 与远程 Server 的区别

MCP Server 有两种典型部署形态，选型时要分清：

| 形态 | 通信方式 | 适用场景 | 安全边界 |

| --- | --- | --- | --- |

| 本地 Server | stdio（标准输入输出） | 访问本地文件、本机工具 | 运行在用户机器上，权限即用户权限 |

| 远程 Server | HTTP / SSE | 团队共享的企业内部服务、云端 API | 需要独立的鉴权与网络隔离 |

本地 Server 简单直接，但要小心它拿到的是用户本机的权限；远程 Server 便于团队共享和集中治理，但必须自己解决鉴权、限流、审计等问题。

MCP 和 Function Calling 是什么关系

很多人会疑惑：Function Calling（函数调用）不是已经能让模型调用外部工具了吗，为什么还需要 MCP？

答案是：MCP 是建立在 Function Calling 之上的一层标准化协议，而不是替代它。Function Calling 解决的是"模型和单次工具调用之间"的接口问题——模型输出结构化参数，宿主应用负责执行对应函数并把结果传回模型，这一步在 MCP 里依然存在，Tools 能力本质上就是通过 Function Calling 机制被模型调用的。

MCP 真正新增的价值在于"应用和工具之间"的连接标准化：在没有 MCP 之前，每个应用要自己定义一套"把外部能力包装成 Function Calling 所需 schema"的逻辑，工具提供方和应用开发方之间没有统一约定；有了 MCP，工具能力的发现（有哪些 tools/resources/prompts 可用）、能力的描述格式、调用的传输协议全部被统一，使得"一次开发 Server、多处复用"成为可能。可以理解为：Function Calling 是模型与单个函数交互的"语法"，MCP 是让不同应用和不同工具能够互相认识、即插即用的"通信协议与生态标准"。

        ┌───────────────── MCP 层（应用 ↔ 工具 的标准化连接）──────────────┐
        │  能力发现 / 描述格式 / 传输协议 / 生命周期  统一约定              │
        └──────────────────────────────────────────────────────────────┘
                                   ▲ 建立在其上
        ┌───────────── Function Calling 层（模型 ↔ 单次函数 的接口）──────┐
        │  模型输出结构化参数 → 宿主执行 → 结果回传                        │
        └────────────────────────────────────────────────────────────┘

MCP 的生态现状与常见误区

MCP 发布后迅速形成了一个官方 + 社区共建的 Server 生态：官方维护了文件系统、Git、GitHub、Google Drive、Postgres、Slack 等一批参考实现，社区和厂商也在持续贡献针对自家产品的 Server（例如项目管理工具、云存储、内部知识库）。主流 Host 侧的支持也在快速扩大，除了 Claude Desktop 原生支持外，多款 IDE 插件、Agent 开发框架也陆续把 MCP Client 能力内置进来，使得开发者只需要维护一份 Server 实现，就能被不同厂商的客户端复用。

使用 MCP 时有两个常见误区值得澄清：

误区一："MCP 就是一个 Agent 框架"。MCP 本身只定义连接协议和能力描述格式，不负责规划任务、拆解步骤或管理多轮调用逻辑——那是 Agent 框架（如何编排多个工具调用、如何做任务分解）要解决的问题。MCP 更像是 Agent 框架底层可以依赖的标准化"接线层"。

误区二："接入 MCP Server 就自动是安全的"。MCP 协议本身不天然保证 Server 的实现是安全可信的：一个恶意或写得不严谨的 Server 依然可能读取过多数据、执行危险操作。协议只解决"连接方式统一"的问题，权限范围、鉴权、审计仍然需要 Host 和 Server 各自实现好边界控制，接入第三方 Server 前也需要像审查一个新依赖一样做安全评估。

误区三："有了 MCP 就不用管上下文成本"。每接入一个 Server，它的 tools/resources 描述都会被注入模型上下文，占用 token。接入的 Server 越多，前缀就越长，成本和延迟随之上升。因此不是"能接就都接"，而应按需启用当前任务真正需要的 Server。

🌐 开源与闭源：当前大模型版图速览

如果说 MCP 解决的是"模型怎么连接外部世界"，那么"该用哪个模型"则是另一个必须面对的选型问题。当前大模型阵营大致分为闭源 API 与开源可部署两大类，代表玩家和特点如下：

| 阵营 | 代表模型 | 技术路线 | 可控性 / 隐私 | 成本结构 | 生态支持 |

|---|---|---|---|---|---|

| 闭源（GPT 系列） | GPT-4o、GPT-5 等 | 超大规模预训练 + 强化学习对齐，模型权重不公开 | 数据需经第三方 API，隐私可控性较弱，依赖厂商合规承诺 | 按 token 计费，用量越大边际成本越高，无需自建算力 | 生态最成熟，插件、Agent 框架、开发者社区规模最大 |

| 闭源（Claude 系列） | Claude Opus、Sonnet、Haiku | 强调对齐与安全性的规模化训练，模型权重不公开 | 同样依赖第三方 API，但对企业级数据处理协议支持较完善 | 按 token 计费，分级模型可按场景控制成本 | 在长上下文、工具调用（含 MCP 原生支持）、代码生成场景生态发展快 |

| 闭源（Gemini 系列） | Gemini 1.5/2.x Pro、Flash | 原生多模态架构，与 Google 云生态深度绑定 | 依赖 Google Cloud 的合规体系 | 按 token 计费，Flash 系列主打低成本高吞吐 | 与 Google 系产品（搜索、Workspace、Android）集成度高 |

| 开源（Llama 系列） | Llama 3.x / 4 | Meta 主导，权重开放，社区微调生态庞大 | 可完全私有化部署，数据不出内网 | 一次性算力/运维投入，边际推理成本随规模摊薄 | 生态工具链（llama.cpp、vLLM 等）非常成熟 |

| 开源（Qwen 系列） | Qwen2.5 / Qwen3 系列 | 阿里通义千问，多尺寸开放权重，中文能力突出 | 可私有化部署，适合对中文数据合规敏感的场景 | 同上，中小尺寸模型可在消费级硬件运行 | 国内生态适配好，官方微调与工具链完善 |

| 开源（DeepSeek 系列） | DeepSeek-V3 / R1 | 高性价比 MoE 架构，推理与代码能力突出，权重开放 | 可私有化部署，也提供官方低价 API | 官方 API 价格极具竞争力，自部署可进一步压缩成本 | 社区活跃，推理效率优化方案多 |

开源与闭源的核心权衡

技术路线：闭源厂商通常拥有更大规模的专有数据、算力和对齐工程投入，在综合能力上长期保持领先或与第一梯队持平；开源阵营通过更透明的架构（如 DeepSeek 的 MoE、Llama 的稠密模型）和快速的社区迭代，在特定任务（代码、数学、垂直语言）上逐步逼近甚至反超部分闭源模型。

"开源"的程度也不完全一样：选型时还要注意开源协议本身的差异。Qwen 和 DeepSeek 的多数版本采用 Apache 2.0 等宽松协议，允许商用、二次分发、修改后闭源发布，限制很少；Llama 系列使用 Meta 自定义的社区许可证，虽然大多数场景下可以免费商用，但对月活超过一定量级的超大公司有额外授权要求，并非严格意义上 OSI 认证的开源协议。评估"开源模型"时，除了看权重是否公开，还要仔细核对许可证条款，避免在商业化阶段才发现合规风险。

可控性与隐私：这是两者最本质的差异。闭源模型的推理必须经过厂商的服务器，数据、Prompt、业务逻辑都会以某种形式流经第三方，即便厂商承诺不用于训练，合规敏感行业（金融、医疗、政务）仍可能因为"数据不出域"的硬性要求而无法使用。开源模型可以完全部署在私有环境（本地机房、专有云、离线环境），从根本上避免数据出境问题，同时也能针对模型行为做更深度的定制（微调、剪枝、蒸馏）。

成本结构：闭源 API 是典型的按需付费模式，前期投入几乎为零，适合调用量不确定或调用量较小的场景；但当调用量达到一定规模后，token 计费的边际成本会持续累积，长期可能反超自建成本。开源自部署则是前期重投入（GPU 采购或云资源租赁、运维团队）、后期边际成本低的模式，适合调用量大且长期稳定的场景。

判断"什么时候该从 API 转向自部署"，可以粗略用一个损益平衡的思路来估算：把自部署的固定成本（硬件折旧/云资源包年费用 + 运维人力）除以"闭源 API 单价与自部署边际单价之间的差值"，得到一个"损益平衡调用量"。当实际调用量长期稳定超过这个平衡点，自部署更划算；如果调用量波动大、或者还处于验证阶段，继续用 API 通常是更稳妥的选择——毕竟自建团队和采购 GPU 本身也有相当的时间成本和沉没成本风险。很多团队的实际做法是：先用闭源 API 跑通产品逻辑、验证需求真实存在，等调用量和场景都稳定下来后，再评估是否把高频、低复杂度的部分迁移到自部署的开源模型上。

下面用一个简化的损益平衡估算把这个思路具体化：

def breakeven_calls_per_month(
    api_price_per_call,          # 闭源 API 每次调用均价（元）
    self_host_marginal_per_call, # 自部署每次调用的边际成本（电费/摊薄算力）
    fixed_cost_per_month         # 自部署固定月成本（硬件折旧 + 运维人力）
):
    price_gap = api_price_per_call - self_host_marginal_per_call
    if price_gap <= 0:
        return float("inf")      # 自部署边际成本还更高，永远不划算
    return fixed_cost_per_month / price_gap

# 示例：API 每次 0.02 元，自部署边际 0.002 元，固定月成本 6 万元
be = breakeven_calls_per_month(0.02, 0.002, 60000)
print(f"损益平衡点约 {be:,.0f} 次/月")  # 约 333 万次/月，超过才考虑自建

这个估算的意义不在于算出精确数字，而在于提醒：自部署的固定成本是实打实的沉没投入，只有当调用量长期、稳定地远超平衡点，自建才真正划算；对量还没起来的团队，过早自建往往是花钱买麻烦。

生态支持：闭源模型尤其是 GPT 和 Claude 系列，配套的开发者工具、Agent 框架、MCP/Function Calling 支持、官方文档最为成熟，遇到问题更容易找到解决方案；开源模型的生态依赖社区和第三方推理框架（vLLM、SGLang、Ollama 等），近两年成熟度提升很快，但在最前沿功能（比如最新的多模态能力、超长上下文）上通常滞后于头部闭源厂商。

选型建议

优先选闭源 API 的场景：

优先考虑私有化部署开源模型的场景：

实践中很多团队并非二选一，而是采用混合策略：对外的核心创意型功能用闭源顶级模型保证体验上限，对内部批量处理、代码生成、数据脱敏等高频且成本敏感的场景用开源模型自部署或使用开源模型的低价官方 API，再通过 MCP 这样的标准协议把不同来源的模型和工具统一接入同一套 Agent 基础设施，兼顾体验、成本与合规。

一张决策速查表

把上面的判断压缩成一张速查表，实际选型时可以逐行对照：

| 你的处境 | 建议方向 | 理由 |

| --- | --- | --- |

| 还在验证需求、量不确定 | 闭源 API | 零前期投入，快速试错 |

| 数据严禁出域（金融/医疗/政务） | 开源私有化 | 从根本上规避数据出境 |

| 调用量已长期稳定超过平衡点 | 开源自部署 | 边际成本低，长期更省 |

| 需要深度微调/蒸馏专用模型 | 开源 | 可完全掌控权重 |

| 追求最强综合能力、预算充足 | 闭源顶级模型 | 前沿能力仍领先 |

| 既要体验又要控成本 | 混合策略 + MCP | 分场景用不同模型 |

📌 小结

MCP 和"开源 vs 闭源"这两个话题看似不相关，实际上共同构成了当前 AI 工程落地要解决的两类核心问题：前者是"连接问题"——如何让模型以标准化、可复用的方式接入外部工具和数据，避免为每个应用、每个数据源重复造轮子；后者是"选型问题"——如何在能力、成本、隐私合规之间找到适合自己业务阶段的平衡点。二者也并不互斥：无论最终选择闭源 API 还是自部署开源模型，都可以通过 MCP 这一层协议统一接入到同一套 Agent 基础设施中，让底层模型的替换、混用变得更加平滑。

最后用一张表把全文要点收束起来：

| 主题 | 核心问题 | 关键结论 |

| --- | --- | --- |

| MCP 是什么 | 模型如何标准化连接外部工具 | AI 世界的 USB，把 M×N 集成变成 M+N |

| MCP 架构 | Host/Client/Server 如何协作 | Host 主机、Client 接口、Server 设备 |

| MCP 三类能力 | Tools/Resources/Prompts 区别 | 按控制权归属区分：按钮/资料/模板 |

| MCP 与 FC 关系 | 是替代还是叠加 | MCP 建在 Function Calling 之上，做连接标准化 |

| 开源 vs 闭源 | 该用哪类模型 | 无绝对优劣，按阶段权衡能力/成本/合规 |

| 成本临界点 | 何时从 API 转自部署 | 调用量长期稳定超过损益平衡点才自建 |

| 落地策略 | 如何兼顾各方 | 混合部署 + 用 MCP 统一接入 |

理解 MCP 这层连接协议，以及开源闭源模型各自的技术特征和适用边界，是构建可持续、可控、成本合理的 AI 应用架构的两个基础前提。

🚚 MCP 传输层深挖：stdio vs SSE vs Streamable HTTP

前面提到本地 Server 用 stdio、远程 Server 用 HTTP/SSE，但传输层的选择直接影响部署形态、并发能力和运维复杂度，值得单独拆开讲。MCP 规范目前定义了三种主流传输方式，它们的底层机制和适用边界差异很大。

stdio（标准输入输出）：Host 以子进程方式拉起 Server，两者通过进程的 stdin/stdout 交换 JSON-RPC 消息，每条消息以换行符分隔。这是最简单、延迟最低（无网络栈开销，通常单次往返 1~5ms）的方式，但 Server 与 Host 强绑定在同一台机器、同一生命周期，无法被多个 Host 共享。

HTTP + SSE（Server-Sent Events）：这是早期远程方案，Client 通过一个 HTTP POST 端点发送请求，通过一个独立的 SSE 长连接端点接收服务端推送。它能跨机器共享，但有个硬伤：SSE 连接是单向的，且需要维持长连接，负载均衡器、反向代理对长连接的超时策略经常导致连接被意外掐断。

Streamable HTTP：2025 年 MCP 规范推出的新一代远程传输，用单一 HTTP 端点同时处理请求和流式响应，服务端可以选择返回普通 JSON（无状态、易水平扩展）或升级为 SSE 流（需要流式推送时）。它兼容标准 HTTP 基础设施，是目前远程部署的推荐方案。

| 传输方式 | 典型延迟 | 跨机器共享 | 水平扩展 | 断连风险 | 推荐场景 |

| --- | --- | --- | --- | --- | --- |

| stdio | 1~5ms | 否 | 不适用 | 极低 | 本地文件、本机 CLI 工具 |

| HTTP+SSE | 20~80ms | 是 | 较难（有状态长连接） | 中高 | 已弃用，仅兼容老 Server |

| Streamable HTTP | 15~60ms | 是 | 易（可无状态） | 低 | 企业内部共享、云端 SaaS Server |

选型的经验法则：能用 stdio 就用 stdio（本地能力首选，最简单最快），需要团队共享或云端托管时用 Streamable HTTP，除非要对接遗留系统，否则不要新建纯 SSE 的 Server。

JSON-RPC 消息长什么样

MCP 底层用的是 JSON-RPC 2.0，所有交互都是结构化的消息。以模型调用一个工具为例，实际在传输层流动的数据大致是这样：

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": {
      "sql": "SELECT count(*) FROM orders WHERE status = 'paid'"
    }
  }
}

Server 处理完后回一条对应 id 的响应：

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "content": [
      { "type": "text", "text": "共有 12847 条已支付订单" }
    ],
    "isError": false
  }
}

理解这一点很重要：MCP 不是什么黑魔法，本质就是一套约定好方法名（tools/list、tools/call、resources/read、prompts/get 等）的 JSON-RPC 通信。任何语言只要能收发 JSON、能起进程或开 HTTP 端口，就能实现 MCP。

🛠️ 完整的 TypeScript MCP Server 实战

Python 的 FastMCP 前面演示过，实际工程里 TypeScript 生态用得同样广泛（尤其配合 Node 后端）。下面用官方 `@modelcontextprotocol/sdk` 写一个稍微完整的天气查询 Server，包含工具定义、参数校验、错误处理和资源暴露。

先装依赖：`npm install @modelcontextprotocol/sdk zod`。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "weather-server",
  version: "1.0.0",
});

// 定义一个带参数校验的工具
server.tool(
  "get_weather",
  "查询指定城市的实时天气",
  {
    city: z.string().describe("城市名称，如 '北京'"),
    unit: z.enum(["celsius", "fahrenheit"]).default("celsius"),
  },
  async ({ city, unit }) => {
    try {
      const resp = await fetch(
        "https://api.example.com/weather?city=" +
          encodeURIComponent(city) +
          "&unit=" + unit
      );
      if (!resp.ok) {
        return {
          content: [{ type: "text", text: "查询失败：" + resp.status }],
          isError: true,
        };
      }
      const data = await resp.json();
      return {
        content: [
          {
            type: "text",
            text: city + " 当前 " + data.temp + " 度，" + data.desc,
          },
        ],
      };
    } catch (err) {
      return {
        content: [{ type: "text", text: "网络异常：" + String(err) }],
        isError: true,
      };
    }
  }
);

// 暴露一个只读资源
server.resource(
  "supported-cities",
  "config://cities",
  async () => ({
    contents: [
      {
        uri: "config://cities",
        text: JSON.stringify(["北京", "上海", "广州", "深圳"]),
      },
    ],
  })
);

// 用 stdio 传输启动
const transport = new StdioServerTransport();
await server.connect(transport);

几个工程要点值得注意：

📥 MCP Client 是怎么连上 Server 的

光有 Server 不够，还要理解 Client 侧怎么发现能力、发起调用。下面用 TypeScript SDK 写一个最小 Client，连接上面的 Server 并调用工具：

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

const transport = new StdioClientTransport({
  command: "node",
  args: ["./weather-server.js"],
});

const client = new Client(
  { name: "my-host-app", version: "1.0.0" },
  { capabilities: {} }
);

await client.connect(transport);

// 1. 发现 Server 提供了哪些工具
const { tools } = await client.listTools();
console.log("可用工具：", tools.map((t) => t.name));

// 2. 调用其中一个工具
const result = await client.callTool({
  name: "get_weather",
  arguments: { city: "上海", unit: "celsius" },
});
console.log("结果：", result.content);

await client.close();

真实的 Host（比如一个 Agent）会把第 1 步拿到的 tools 列表，连同它们的 JSON Schema 一起注入到发给 LLM 的请求里，让模型决定调哪个、传什么参数；模型返回调用意图后，Host 再执行第 2 步。所以 Host 本质上是"LLM 决策"和"MCP 执行"之间的胶水层。

🔀 MCP 工具 schema 与 OpenAI Function Calling 的对照

不少团队已经有一堆 OpenAI Function Calling 的工具定义，纠结要不要迁到 MCP。其实两者的 schema 高度同源，都是围绕 JSON Schema 描述参数，理解这一点迁移成本就低了。

OpenAI Function Calling 里一个工具定义长这样：

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "查询指定城市的实时天气",
    "parameters": {
      "type": "object",
      "properties": {
        "city": { "type": "string", "description": "城市名称" },
        "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
      },
      "required": ["city"]
    }
  }
}

MCP 的 tools/list 返回的等价结构：

{
  "name": "get_weather",
  "description": "查询指定城市的实时天气",
  "inputSchema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "城市名称" },
      "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
    },
    "required": ["city"]
  }
}

对照可见：核心的 name/description/参数 JSON Schema 完全一致，只是外层包装字段名不同（`function.parameters` vs `inputSchema`）。

| 维度 | OpenAI Function Calling | MCP |

| --- | --- | --- |

| 参数描述 | JSON Schema | JSON Schema（几乎相同） |

| 工具发现 | 由开发者硬编码进请求 | 运行时 tools/list 动态发现 |

| 能力范围 | 仅工具（函数） | 工具 + 资源 + 提示模板 |

| 复用性 | 绑定单个应用/单个模型厂商 | 一次实现，跨 Host 跨模型复用 |

| 传输 | 随 chat completion 请求 | 独立的 JSON-RPC 连接 |

结论：如果你只用一个模型、工具也就几个，Function Calling 足够；一旦工具要跨多个应用复用、或想在不同模型厂商间自由切换，MCP 的动态发现和复用能力才体现价值。迁移时可以写个适配层，把现成的 Function 定义批量包装成 MCP tools。

🔐 MCP 的安全模型与鉴权

前面"误区二"点到了安全问题，这里展开。MCP Server 一旦接入，就等于给模型开了一扇通往真实系统的门，安全必须认真对待。核心威胁有三类：

远程 Server 的鉴权，MCP 规范推荐用 OAuth 2.1。一个受保护的 Streamable HTTP Server 的鉴权检查逻辑大致如下：

import express from "express";

const app = express();

app.post("/mcp", async (req, res) => {
  const auth = req.headers["authorization"];
  if (!auth || !auth.startsWith("Bearer ")) {
    return res.status(401).json({
      jsonrpc: "2.0",
      error: { code: -32001, message: "缺少或无效的访问令牌" },
      id: null,
    });
  }
  const token = auth.slice("Bearer ".length);
  const valid = await verifyAccessToken(token); // 校验 JWT 签名、过期、scope
  if (!valid) {
    return res.status(403).json({
      jsonrpc: "2.0",
      error: { code: -32003, message: "令牌无效或权限不足" },
      id: null,
    });
  }
  // 通过鉴权后再交给 MCP 处理器，并把 scope 限制传下去
  await handleMcpRequest(req, res, { scopes: valid.scopes });
});

实战安全清单：

| 风险 | 缓解措施 |

| --- | --- |

| 过度授权 | 最小权限原则，文件 Server 只挂必要目录，DB Server 用只读账号 |

| 提示注入 | 对工具返回内容做隔离标注，敏感操作要求人工二次确认 |

| 凭证泄露 | 凭证走环境变量/密钥管理服务，禁止写进日志和对话上下文 |

| 恶意第三方 Server | 像审计新依赖一样审查代码，优先用官方/知名来源 |

| 越权调用 | 远程 Server 用 OAuth 2.1 + 细粒度 scope，逐工具鉴权 |

🗄️ 常见 MCP Server 实战：数据库、文件、API

抽象讲完，看三个最高频的实战场景怎么落地。

1. 数据库 Server（只读查询）。给模型开放数据库时，务必用只读账号，并把危险操作挡在外面：

from mcp.server.fastmcp import FastMCP
import sqlite3

mcp = FastMCP("readonly-db")

@mcp.tool()
def run_query(sql: str) -> str:
    """执行只读 SQL 查询（仅允许 SELECT）"""
    normalized = sql.strip().lower()
    if not normalized.startswith("select"):
        return "错误：只允许 SELECT 查询"
    forbidden = ["insert", "update", "delete", "drop", "alter", "attach"]
    if any(k in normalized for k in forbidden):
        return "错误：检测到禁止的关键字"
    conn = sqlite3.connect("file:app.db?mode=ro", uri=True)
    try:
        rows = conn.execute(sql).fetchmany(100)  # 限制返回行数控 token
        return "\n".join(str(r) for r in rows)
    finally:
        conn.close()

注意 `fetchmany(100)`：数据库动辄返回上万行，全塞进上下文会瞬间打爆 token 预算（一行几十个 token，一万行就是几十万 token，远超模型上下文）。永远要限制返回规模。

2. 文件系统 Server（受限目录）。官方 `@modelcontextprotocol/server-filesystem` 直接可用，关键是启动时只把允许访问的目录作为参数传入，模型访问范围之外会被 Server 拒绝：

{
  "mcpServers": {
    "docs": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/data/knowledge-base"]
    }
  }
}

3. 第三方 API Server（带缓存降本）。包装外部 API 时，加一层缓存能显著降低成本和延迟——同样的查询没必要每次都打真实 API：

from mcp.server.fastmcp import FastMCP
from functools import lru_cache
import httpx

mcp = FastMCP("exchange-rate")

@lru_cache(maxsize=256)
def _fetch_rate(base: str, target: str) -> float:
    r = httpx.get("https://api.example.com/rate?from=" + base + "&to=" + target)
    return r.json()["rate"]

@mcp.tool()
def convert(amount: float, base: str, target: str) -> str:
    """货币换算"""
    rate = _fetch_rate(base.upper(), target.upper())
    return str(round(amount * rate, 2)) + " " + target.upper()

🧭 模型路由与 fallback 策略

有了 MCP 把工具接进来，另一半工程是"把请求路由到合适的模型"。生产系统很少只用一个模型，而是按任务复杂度、成本、可用性做动态路由。

核心思路：简单任务用便宜的小模型，复杂任务才升级到贵的大模型；主力模型不可用时自动降级到备用模型。下面是一个带 fallback 的路由骨架：

import time

# 按优先级排列的模型链，每个带成本档位
MODEL_CHAIN = [
    {"name": "gpt-4o-mini",     "tier": "cheap",   "in_price": 0.15, "out_price": 0.60},
    {"name": "claude-sonnet",   "tier": "balanced","in_price": 3.0,  "out_price": 15.0},
    {"name": "claude-opus",     "tier": "premium", "in_price": 15.0, "out_price": 75.0},
]  # 价格单位：美元 / 百万 token

def pick_model(task_complexity: str) -> dict:
    """按任务复杂度选起始模型"""
    if task_complexity == "simple":
        return MODEL_CHAIN[0]
    if task_complexity == "medium":
        return MODEL_CHAIN[1]
    return MODEL_CHAIN[2]

def call_with_fallback(prompt: str, complexity: str, max_retries: int = 3):
    start = MODEL_CHAIN.index(pick_model(complexity))
    for model in MODEL_CHAIN[start:]:
        for attempt in range(max_retries):
            try:
                return call_llm(model["name"], prompt)  # 你的实际调用封装
            except RateLimitError:
                time.sleep(2 ** attempt)  # 指数退避后重试同一模型
            except (ServiceUnavailable, TimeoutError):
                break  # 直接降级到链上的下一个模型
    raise RuntimeError("所有模型均不可用")

路由策略的几个实战维度：

| 路由维度 | 策略 | 收益 |

| --- | --- | --- |

| 按复杂度分级 | 分类/抽取用小模型，推理/创作用大模型 | 综合成本可降 60~80% |

| 按可用性 fallback | 主模型限流/宕机时切备用厂商 | 提升可用性到 99.9%+ |

| 按延迟要求 | 实时交互用 Flash/mini 类，离线批处理用大模型 | 交互延迟可控在 1s 内 |

| 语义缓存 | 相似请求命中缓存直接返回 | 高重复场景省 30%+ 调用 |

一个常见做法是先用一个极便宜的小模型做"分诊"（判断这个请求属于简单/复杂），再据此路由——分诊本身的成本远低于用大模型直接硬扛所有请求带来的浪费。

💰 主流模型价格与能力对比

选型绕不开真金白银的价格和硬指标。下表汇总当前主流模型的关键参数（价格为官方 API 报价，单位美元/百万 token，随厂商调整会变动，仅作数量级参考）：

| 模型 | 阵营 | 上下文长度 | 输入价格 | 输出价格 | 突出能力 |

| --- | --- | --- | --- | --- | --- |

| GPT-4o | 闭源 | 128K | 2.5 | 10 | 多模态、通用综合能力强 |

| GPT-4o mini | 闭源 | 128K | 0.15 | 0.60 | 高性价比、批量任务首选 |

| Claude Opus | 闭源 | 200K | 15 | 75 | 复杂推理、长文档、代码 |

| Claude Sonnet | 闭源 | 200K | 3 | 15 | 能力/成本平衡，工具调用强 |

| Claude Haiku | 闭源 | 200K | 0.80 | 4 | 快速、低成本、轻量任务 |

| Gemini 2.x Pro | 闭源 | 1M~2M | 1.25 | 5 | 超长上下文、原生多模态 |

| Gemini Flash | 闭源 | 1M | 0.075 | 0.30 | 极低成本、高吞吐 |

| DeepSeek-V3 | 开源 | 128K | 0.27 | 1.10 | 高性价比 MoE、代码数学强 |

| DeepSeek-R1 | 开源 | 128K | 0.55 | 2.19 | 强推理、思维链透明 |

| Qwen3 (72B级) | 开源 | 128K | 自部署为主 | 自部署为主 | 中文强、多尺寸可选 |

| Llama 3.x (70B) | 开源 | 128K | 自部署为主 | 自部署为主 | 生态成熟、可完全私有化 |

几个从价格表能读出的关键信号：

一次调用到底花多少钱

价格表是抽象的，算一笔具体账更有体感。假设一个 RAG 应用，每次请求注入 8000 token 上下文，生成 500 token 回答：

def cost_per_call(in_tokens, out_tokens, in_price, out_price):
    # 价格单位：美元 / 百万 token
    return (in_tokens * in_price + out_tokens * out_price) / 1_000_000

# 8000 输入 + 500 输出，分别用不同模型
print(cost_per_call(8000, 500, 15, 75))    # Claude Opus: ≈ 0.1575 美元/次
print(cost_per_call(8000, 500, 3, 15))     # Claude Sonnet: ≈ 0.0315 美元/次
print(cost_per_call(8000, 500, 0.15, 0.6)) # GPT-4o mini: ≈ 0.0015 美元/次
print(cost_per_call(8000, 500, 0.27, 1.1)) # DeepSeek-V3: ≈ 0.00276 美元/次

同一个请求，Opus 每次约 0.16 美元，mini 每次约 0.0015 美元——相差 100 倍。如果日调用量 100 万次，Opus 一天 16 万美元，mini 一天 1500 美元。这就是为什么模型路由不是锦上添花，而是规模化后的生存问题。

🖥️ 私有化部署技术栈：vLLM / Ollama / SGLang

决定自部署开源模型后，用什么推理引擎是核心技术选型。三个主流方案各有定位：

Ollama：面向个人和小规模场景，一行命令拉起模型，内置量化、自动管理显存，开发调试和本地原型极其友好，但吞吐和并发能力有限，不适合高并发生产。

# Ollama：本地跑起来最快的方式
ollama run qwen3:8b
# 或作为 API 服务
ollama serve  # 默认监听 11434 端口，兼容 OpenAI API 格式

vLLM：生产级高吞吐推理引擎，核心是 PagedAttention（把 KV Cache 像操作系统管理内存页一样分页管理，大幅减少显存碎片）和 continuous batching（动态拼批），在高并发下吞吐远超朴素实现，是自建推理服务的主流选择。

# vLLM：起一个兼容 OpenAI 接口的高吞吐服务
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen3-8B \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

SGLang：新兴的高性能引擎，强项是 RadixAttention（自动复用相同前缀的 KV Cache），在多轮对话、共享系统提示、复杂结构化输出场景下，前缀复用带来的加速非常明显。

| 引擎 | 定位 | 并发/吞吐 | 上手难度 | 最佳场景 |

| --- | --- | --- | --- | --- |

| Ollama | 本地/原型 | 低 | 极低 | 开发调试、个人使用、边缘设备 |

| vLLM | 生产高吞吐 | 高 | 中 | 高并发在线服务、批量推理 |

| SGLang | 生产/前缀复用 | 高 | 中 | 多轮对话、共享长前缀、结构化输出 |

经验法则：本地玩用 Ollama，上生产用 vLLM，前缀复用重的场景考虑 SGLang。

📐 量化与显存估算

自部署最先撞上的墙就是显存。模型能不能在你的卡上跑起来，靠估算就能提前判断，不用等 OOM。

基础公式：模型权重占用显存 ≈ 参数量 × 每参数字节数。不同精度下每参数字节数不同：

| 精度 | 每参数字节 | 7B 模型权重 | 70B 模型权重 |

| --- | --- | --- | --- |

| FP16 / BF16 | 2 | 约 14 GB | 约 140 GB |

| INT8 量化 | 1 | 约 7 GB | 约 70 GB |

| INT4 量化 | 0.5 | 约 3.5 GB | 约 35 GB |

但权重只是一部分，实际还要加上 KV Cache（随上下文长度和并发数线性增长）和推理框架开销。一个更实用的估算：

def estimate_vram_gb(params_billion, bytes_per_param, ctx_len, batch,
                     n_layers, hidden_dim):
    # 权重显存
    weight_gb = params_billion * bytes_per_param
    # KV Cache 显存：2(K和V) × 层数 × 上下文 × 隐藏维 × 2字节(FP16) × 并发
    kv_bytes = 2 * n_layers * ctx_len * hidden_dim * 2 * batch
    kv_gb = kv_bytes / (1024 ** 3)
    overhead = 1.2  # 框架/激活值约 20% 冗余
    return (weight_gb + kv_gb) * overhead

# 7B 模型，INT4，8K 上下文，并发 16，约 32 层，hidden 4096
print(round(estimate_vram_gb(7, 0.5, 8192, 16, 32, 4096), 1), "GB")

实战结论：

🏢 混合部署架构实战

理论落到架构上，成熟团队的典型形态是"闭源 + 开源混合 + MCP 统一接入"。一个电商客服系统的实际分工可能是这样：

                    ┌─────────────────────────┐
    用户请求 ──────▶ │   路由层 (分诊小模型)     │
                    └───────────┬─────────────┘
              ┌─────────────────┼──────────────────┐
              ▼                 ▼                  ▼
      ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
      │ 意图分类/FAQ  │  │  复杂投诉处理  │  │  敏感数据查询  │
      │ 自部署 Qwen3  │  │ 闭源 Claude   │  │ 私有 DeepSeek │
      │ (vLLM,高频)   │  │ (低频,高价值)  │  │ (数据不出域)  │
      └──────┬───────┘  └──────┬───────┘  └──────┬───────┘
             └─────────────────┼──────────────────┘
                               ▼
                    ┌─────────────────────────┐
                    │   MCP 统一工具层          │
                    │ 订单DB / 物流API / 知识库 │
                    └─────────────────────────┘

这套架构的设计逻辑：

这种架构的收益量化：假设纯用 Claude Opus 每月成本 100 万元，改为混合后，80% 流量转自部署（成本降到约 5%），15% 用 Sonnet（成本约 20%），5% 保留 Opus，综合月成本可压到 20 万元以内，同时敏感数据合规、体验关键路径不降级。

混合部署的常见坑

| 坑 | 表现 | 规避 |

| --- | --- | --- |

| 模型输出格式不一致 | 不同模型对同一 prompt 的 JSON 格式微妙不同 | 统一用 structured output/工具调用约束输出 |

| 路由分诊本身出错 | 复杂请求被误判为简单，小模型答砸 | 分诊给出置信度，低置信度默认升级 |

| 自部署可用性拖后腿 | 自建服务宕机没有兜底 | 自部署也要配闭源 API 作为 fallback |

| 成本监控缺失 | 月底才发现某条链路烧了大钱 | 按模型/链路打点，实时成本看板告警 |

| 上下文重复注入 | 每个模型都塞全量工具描述，token 翻倍 | 按当前任务动态裁剪注入的工具集 |

📊 总结：从协议到落地的全景

把 MCP 深水区和模型选型的要点做最后收束：

| 主题 | 核心要点 | 一句话结论 |

| --- | --- | --- |

| 传输层选型 | stdio/SSE/Streamable HTTP | 本地用 stdio，远程用 Streamable HTTP |

| Server 开发 | zod 校验 + 结构化错误 + 清晰描述 | 工具描述就是给模型的说明书 |

| MCP vs FC schema | 参数 JSON Schema 同源 | 迁移成本低，MCP 胜在动态发现与复用 |

| 安全鉴权 | 最小权限 + OAuth2.1 + 防注入 | 接 Server 等于开门，权限必须收紧 |

| 模型路由 | 按复杂度分级 + fallback | 分诊 + 路由，成本可降 60~80% |

| 价格差异 | 同请求不同模型差 100 倍 | 用错档位就是烧钱 |

| 推理引擎 | Ollama/vLLM/SGLang | 原型 Ollama，生产 vLLM |

| 显存估算 | 权重 + KV Cache + 余量 | INT4 省 3/4 显存，别忘算 KV Cache |

| 混合架构 | 开源+闭源+MCP 统一 | 分场景用模型，工具层用 MCP 解耦 |

真正成熟的 AI 工程能力，不在于会调某个模型的 API，而在于能把"标准化连接（MCP）+ 分层模型路由 + 私有化部署 + 成本合规治理"组织成一套可演进的架构——底层模型可以随生态迭代不断替换，而上层的工具、数据和业务逻辑保持稳定。这，才是 MCP 与开源闭源版图这两个话题在工程上真正的交汇点。