MCP 协议详解：解决 AI 集成的 N×M 问题

MCP（Model Context Protocol）是一种通用语言，让 Claude 能够与你现有的工具和数据对话。本文将解释 MCP 是什么，以及它为何改变了我们与 AI 协作的方式。

假设你有 5 个 AI 模型和 8 个企业系统需要对接：订单库、客服系统、文档仓库、邮件系统、日历系统。最坏的情况下需要写多少个集成？5 乘以 8 等于 40 个独立代码模块——而且只要其中任何一个工具发生变化，所有相关的集成都需要维护。这就是经典的"N × M"问题，导致企业 AI Agent 的落地被大量集成工作拖累，无法真正交付价值。Model Context Protocol（MCP）解决了这个难题——就像 USB-C 接口统一了线缆标准一样：用一套通用协议，让任意模型与任意工具互通。本文将解释它的工作原理、展示代码，并诚实地说清楚 MCP 在哪些场景下是 overkill。

通过本文你将了解：

• "N × M"问题的本质，以及它为何让企业 AI 集成陷入停滞
• MCP 的架构：Host 与 Client、协议、暴露工具和数据的服务器
• 可用的代码示例：服务器配置（JSON）、Python 最小 MCP 服务器、工具定义
• 企业实际应用场景，以及 MCP 如何规范安全保障和访问控制
• MCP 与普通 API 调用的区别，以及何时不适合使用 MCP

"N × M"问题——为什么 AI 集成总是卡住

在通用标准出现之前，每个 AI 模型与企业工具的连接都需要从零开发。假设你希望 AI 助手能够：

• 在 ERP 系统中查询订单状态
• 从企业文档仓库获取文件
• 在客服系统（CRM）中保存笔记
• 查询日历中的空闲时段
• 对数据库执行查询

对于一个模型来说，这是 5 个集成。当你有多个模型（浏览器中的助手、代码编辑器中的助手、后台运行的 Agent）和多个工具时，问题就出现了。所需连接的数量是乘积关系：N 个模型乘以 M 个工具。每一个连接都有各自的数据格式、错误处理方式和认证机制。换一个模型——就要重写所有集成。更新一下客服系统的 API——就要同时修改好几处代码。这不是在创造价值的工作，而是碎片化带来的税务。

MCP 颠覆了这个逻辑。不是把每个模型与每个工具单独连接，而是定义一个通用协议。工具只需暴露一次——作为 MCP 服务器——任何客户端都可以使用。这样"N × M"的乘积就变成了"N + M"的和：你有多少个工具，就有多少个服务器；你有多少个模型，就有多少个客户端。仅此而已。

Gospodarz + klient AI asystent, edytor, agent

Protokół MCP (JSON-RPC) repozytorium dokumentów

一个通用协议取代了每对模型-工具的单独集成。AI 客户端可以连接任意 MCP 服务器，无需重写代码。

MCP 工作原理——Host、Client、Server

MCP 描述了三个组件之间的对话。区分它们很重要，因为名称经常被混淆。

Host 与 Client（AI 端）

Host（宿主机）是用户与模型交互的应用：浏览器中的助手、代码编辑器中的助手、在服务器上运行的 Agent。Host 内部嵌入了一个 Client（客户端）——一个负责与特定 MCP 服务器建立和维护连接的组件，并在模型与协议之间做翻译。一个 Host 可以有多个 Client，每个连接一个服务器。

Server（工具和数据端）

MCP 服务器是一个轻量级程序，暴露三类内容：

• 工具（Tools）：模型可以调用的操作，例如"查询订单状态"
• 资源（Resources）：只读数据，如文件、数据库记录
• 提示模板（Prompts）：预定义的指令模板

关键在于：服务器自己描述它能做什么——提供工具名称、人类可读的描述和输入数据 schema。因此模型不需要预先内置这些知识——而是在运行时动态发现。

协议（通信层）

Client 与 Server 通过基于 JSON-RPC（一种轻量级的 JSON 格式远程过程调用协议）的标准化消息格式进行通信。连接可以在本地运行（服务器作为同一台机器上的进程运行，通过标准输入/输出通信），也可以通过网络远程运行。一次操作的流程如下：

Użytkownik  ->  „Jaki jest status zamówienia 4815?"

Klient AI  ->  pyta serwer: jakie masz narzędzia?

Serwer MCP ->  zwraca: get_order_status(order_id)

Model      ->  decyduje wywołać get_order_status z argumentem "4815"

Serwer MCP ->  odpytuje ERP, zwraca: {"status":"wysłane","kurier":"DPD"}

Model      ->  „Zamówienie 4815 zostało wysłane kurierem DPD."

这个流程中最关键的是：模型自己决定使用哪个工具以及传入什么参数——基于服务器提供给它的描述。没有人事先编程指定"问订单状态就必须调用这个工具"。这就是硬接线与通用插座的本质区别：插座可以插入任意你想插入的设备。

配置：如何连接 MCP 服务器

最简单的方式不需要写代码。现成的服务器通过 JSON 格式的配置文件连接，在其中指定如何启动服务器及其设置。以下是同时连接两个服务器的示例——文件访问和 PostgreSQL 数据库：

{
  "mcpServers": {
    "pliki-firmowe": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/dane/dokumenty"]
    },
    "baza-zamowien": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "postgres://sklep:tajne_hasło@sklep.pl/sklep" }
    }
  }
}

env 字段向 MCP 服务器进程注入环境变量——这是传递凭证的标准方式，而无需将密码直接写在命令中。在示例中，DATABASE_URL 是 PostgreSQL 的连接字符串，格式为 postgres://user:password@host/database。请将你自己的实际数据填入其中。注意不要让配置文件连同密码一起进入代码仓库——对于生产环境，最好从密钥管理器读取密码并单独注入。

配置文件存放位置

文件位置取决于所使用的客户端。以下是最常见的情况：

如果文件不存在，手动创建——将上面的 JSON 结构作为内容粘贴进去。在 Claude Desktop 中，你也可以进入 Settings > Developer，找到一个按钮来在编辑器中打开这个文件。保存并重新启动应用后，助手就能"看到"这两个服务器。它可以读取 /dane/dokumenty 目录下的文档，也可以向订单数据库提问。注意数据库用户：在生产环境中应该使用只读权限的账户，而非管理员账户。这一点稍后会解释为什么很重要。

最小 MCP 服务器——Python 实现自定义工具

现成的服务器可以满足很多需求，但 MCP 真正强大的地方在于可以暴露你自己的企业内部系统。假设你有一个旧版 ERP 系统，带有简单的 API，你希望助手能够查询其中的订单状态。一个只暴露一个工具的 MCP 服务器就够了。官方 Python 包让这件事变得非常简洁：

# pip install "mcp[cli]"
from mcp.server.fastmcp import FastMCP
import httpx

server = FastMCP("firmowy-erp")

@server.tool()
def get_order_status(order_id: str) -> dict:
    """Sprawdza status zamówienia po numerze w firmowym systemie ERP."""
    r = httpx.get(f"https://erp.firma.pl/api/orders/{order_id}",
                  headers={"Authorization": "Bearer tajny_token_erp"}, timeout=10)
    r.raise_for_status()
    dane = r.json()
    # Udostępniamy tylko to, co bezpieczne - bez danych płatności
    return {
        "numer": dane["id"],
        "status": dane["status"],
        "kurier": dane.get("carrier"),
        "data_wysylki": dane.get("shipped_at"),
    }

if __name__ == "__main__":
    server.run()

Authorization: Bearer <token> 是标准的 HTTP 认证头——"Bearer"意为"持证人"，即持有 token 的人拥有访问权限。Token 从 ERP 系统的设置中生成或获取，替换掉tajny_token_erp。

这是一个完整可运行的服务器。@server.tool() 装饰器将函数注册为模型可用的工具。关键在于，工具的描述直接来自函数的文档字符串和签名——"Sprawdza status zamówienia po numerze"这段文字以及参数 order_id: str 会进入服务器展示给客户端的 schema。模型基于此自行决定何时调用该工具。无需编写任何额外的映射——schema 从代码自动生成。

当你需要暴露的不是操作而是数据时，使用资源（resource）。同一个库允许你将价格表作为资源暴露，模型可以将其加载到上下文中：

@server.resource("cennik://aktualny")
def cennik() -> str:
    """Aktualny cennik usług w formacie tekstowym."""
    with open("/dane/cennik.md", encoding="utf-8") as f:
        return f.read()

工具与资源的区别是刻意设计的：工具执行操作（模型可以自主调用），资源提供数据（通常由 Host 决定何时加载）。这一区分有助于控制模型可以做什么、只能读取什么。

企业实际应用场景

MCP 不是面向发烧友的抽象——它解决的是具体的、成本高昂的问题。以下是企业在实践中反复出现的几个场景：

这些应用场景的共同点是：一个 MCP 服务器为多个客户端服务。同一个暴露订单库的服务器，既服务于浏览器中的助手，也服务于后台生成报告的 Agent。一次编写，处处使用——这就是标准带来的节约。

Chcesz zbudować bezpiecznych agentów AI z dostępem do firmowych systemów? Szkolenie z Model Context Protocol w JSystems · od podłączenia gotowych serwerów po własny serwer dla wewnętrznego systemu · 2 dni warsztatów z praktykiem Zobacz szkolenie MCP

安全性和访问控制

这里是 MCP 相对于"给模型 API 密钥然后指望它守规矩"方案最大的优势所在。以前 Agent 往往持有全权限凭证，可以做 API 允许的任何操作。MCP 引入了一层由你决定模型能做什么、不能做什么的控制。

细粒度权限（Granular permissions）。服务器只暴露选定的操作。如果暴露数据库，使用只读账户——模型物理上无法删除任何内容，即使它"想"。

审计跟踪（Audit trail）。每次工具调用都经过服务器，因此每次都可以被记录：谁、何时、什么参数、什么结果。完整的行为日志。

用户确认（User approval）。Host 可以要求在敏感操作（写入、发送消息、删除）之前，人类点击"确认"。模型提议，人决策。

隔离（Isolation）。模型从不直接接触系统——只通过标准化接口与服务器对话。服务器是唯一的网关，也是规则执行的唯一地方。

注意：MCP 本身并不会自动保证安全——它只是一层通信层。安全性取决于你如何构建服务器。使用全权限数据库账户、不验证参数、不对远程服务器做认证——这些会将优势变成风险。最小权限原则在这里和其他地方一样适用。

对于正在整理 AI 落地成果、注重可审计性和控制力的企业来说，这种架构提供了务实的答案：Agent 的行为被记录、限制在定义范围内、随时可审查。

现成服务器生态系统

并非所有东西都需要自己写。MCP 周围已经形成了一个快速增长的现成服务器生态，只需配置即可连接：

• 文件系统——安全的、受限指定目录的文档访问
• 数据库——PostgreSQL、SQLite 等，可限制为只读
• 代码仓库——仓库、issue、PR、代码搜索
• 通讯和邮件——频道、消息、用户
• 工作管理系统——issue、项目、冲刺
• 网页抓取——将网址内容加载到上下文中

实际的推论：典型的落地从几个现成服务器开始（文件、数据库、代码仓库），只有对于还没有人暴露的东西才写自己的服务器——通常是内部企业系统。这大大缩短了从想法到可用 Agent 的路径。

MCP 与普通 API 调用的区别

这是最常见的问题："我的代码已经能调用 API 了，为什么还要加一层？"区别很重要，本质在于谁来决策，以及方案的可移植性。

换句话说：普通 API 调用是两个点之间的硬接线——由人设计的，不能轻易转移到其他地方。MCP 是一个通用插座——服务器一次描述它能做什么，任何兼容的客户端都可以连接，让模型自主选择合适的工具。这就是为什么拿 USB-C 做类比：一个插座，取代抽屉里一堆不兼容的线缆。

何时 MCP 是 overkill

一篇诚实的文章也必须说明什么时候不值得用。MCP 是为规模和可控性设计的标准——在简单场景下只会增加一层什么忙也帮不上的复杂度。

一个模型、一个工具、一次性的。如果你写的是一个每天只调用一次某个 API 的脚本，普通函数调用更简单、更清晰。MCP 服务器在这里是不必要的仪式。

没有控制和审计需求。当你不需要记录行为或限制权限时，MCP 的主要好处就不存在了。

固定不变的集成。如果模型没什么可"选择"的，因为逻辑是硬编码的，那么动态发现工具除了增加开销外什么都带不来。

非常早期的原型。在验证想法的阶段，直接调用 API 更快看到效果。等原型成熟了、出现更多工具或客户端时再引入 MCP。

原则很简单：工具越多、AI 客户端越多、控制需求越强，MCP 的收益就越大。只有一个连接、没有安全要求的情况下，就是形式大于内容。好的落地从问题开始："我真正会有多少对模型-工具的连接？是否需要控制 Agent 能做什么？"

结语

MCP 解决了一个具体的、成本高昂的问题：把"N 个模型 × M 个工具"的乘积变成"N + M"的和，同时带来了在 Agent 拿着全权限 API 密钥时缺失的那层控制。服务器一次暴露工具和数据，用模型能理解的方式描述它们，任意兼容的客户端都可以使用。同一个插座、同一个插头、任意设备。

对于正在落地 AI Agent 的企业来说，这是从"粘合集成"到"在共同基础上构建"的转变——这正是 MCP 真正改变了 AI 与企业系统连接方式的的原因。在它变得像今天的 REST API 一样显而易见之前，值得现在就了解它。

Model Context Protocol - 企业中的 AI Agent 实践培训 JSystems：从连接现成 MCP 服务器到为企业内部系统编写自定义服务器，重点关注安全性和访问控制。2 天 workshop。查看日程并报名