8.0
热点
AI SCORE
技术实践2026-08-16 20:04
MCP 协议详解：解决 AI 集成的 N×M 问题
dev.to · AI#MCP#AI集成#协议
Editor brief · 编辑速览
MCP 通过统一标准让任意模型连接任意工具，解决企业 AI 落地中重复编写 N×M 集成代码的问题；含服务器配置示例和 Python 最小实现。
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。
通过本文你将了解：
在通用标准出现之前，每个 AI 模型与企业工具的连接都需要从零开发。假设你希望 AI 助手能够：
对于一个模型来说，这是 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（宿主机）是用户与模型交互的应用：浏览器中的助手、代码编辑器中的助手、在服务器上运行的 Agent。Host 内部嵌入了一个 Client（客户端）——一个负责与特定 MCP 服务器建立和维护连接的组件，并在模型与协议之间做翻译。一个 Host 可以有多个 Client，每个连接一个服务器。
MCP 服务器是一个轻量级程序，暴露三类内容：
关键在于：服务器自己描述它能做什么——提供工具名称、人类可读的描述和输入数据 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."
这个流程中最关键的是：模型自己决定使用哪个工具以及传入什么参数——基于服务器提供给它的描述。没有人事先编程指定"问订单状态就必须调用这个工具"。这就是硬接线与通用插座的本质区别：插座可以插入任意你想插入的设备。
最简单的方式不需要写代码。现成的服务器通过 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 真正强大的地方在于可以暴露你自己的企业内部系统。假设你有一个旧版 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 周围已经形成了一个快速增长的现成服务器生态，只需配置即可连接：
实际的推论：典型的落地从几个现成服务器开始（文件、数据库、代码仓库），只有对于还没有人暴露的东西才写自己的服务器——通常是内部企业系统。这大大缩短了从想法到可用 Agent 的路径。
这是最常见的问题："我的代码已经能调用 API 了，为什么还要加一层？"区别很重要，本质在于谁来决策，以及方案的可移植性。
换句话说：普通 API 调用是两个点之间的硬接线——由人设计的，不能轻易转移到其他地方。MCP 是一个通用插座——服务器一次描述它能做什么，任何兼容的客户端都可以连接，让模型自主选择合适的工具。这就是为什么拿 USB-C 做类比：一个插座，取代抽屉里一堆不兼容的线缆。
一篇诚实的文章也必须说明什么时候不值得用。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。查看日程并报名