你为你的AI助手集成了一个Slack服务。这花了你一周时间完成了：OAuth流程、消息解析、错误处理、速率限制。它运行良好。你的团队非常喜欢它。

    然后首席技术官问：“我们也能把它集成到 ChatGPT 里吗？”不同的 SDK，不同的认证模型，不同的工具架构。又过了一周。然后有人想把它集成到 Cursor 里，接着是 Gemini。四个工具，四个自定义集成，四项维护工作。你竟然写了四遍同样的 Slack 连接器。

    这就是 N×M 问题。N 个工具乘以 M 个 AI 模型，这种架构的。每个构建生产系统的 AI 团队都遇到过这个问题。

    MCP 就是解决方案。花费一个下午把 Slack 连接器重写成 MCP 服务器。两个模型都立即识别到了它。下面就来解释它的工作原理，以及为什么所有主流 AI 公司都在一年内采用了它。

先概括下

1. MCP（模型上下文协议）是一种开放标准，它为AI模型提供了一种连接外部工具和数据的通用方式。一个MCP服务器，即可连接所有AI模型。可以把它想象成AI版的USB-C。
2. 它解决了集成爆炸的问题。无需为每个模型-工具组合构建自定义连接器，只需为每个工具构建一个 MCP 服务器，所有支持 MCP 的模型都可以使用它。
3. 该架构包含三个角色：主机（您的AI应用程序）、客户端（管理连接）和服务器（提供工具）。通信通过JSON-RPC进行。

    接下来详细看下。

在 MCP 出现之前，使用函数调用

    要了解 MCP 的重要性，你需要了解它所取代的东西。

    函数调用（也称为工具使用）是让语言学习模型 (LLM) 能够执行更多操作（而不仅仅是生成文本）的机制。您可以定义一个函数，用 JSON 模式描述其参数，然后模型会决定何时调用它。“东京天气如何？”会触发天气 API 调用。“帮我预订航班”会触发预订函数。AI Agent就是在“思考-行动-观察”循环的过程中，使用工具，获取结果。

    函数调用是可行的。正因如此，AI Agent才能真正执行操作，而不仅仅是只会输出文字建议。但它存在一个结构性问题。

    每个AI提供商实现函数调用的方式都不同。OpenAI有自己的`tool_choice`参数和并行函数调用。Anthropic有自己的工具使用格式。Google又有一套不同的架构。如果你为OpenAI API构建一个天气工具，它就无法在Claude上运行。如果你为Claude构建一个天气工具，它也无法在Gemini上运行。尽管函数功能相同，但连接方式却完全不同。

    这是USB-C时代之前的世界。你的手机充电器插不进笔记本电脑，笔记本电脑的充电器也插不进平板电脑。每台设备，每根线缆，都存在兼容性问题。

 

为什么函数调用存在很大问题

 

    我们用具体数字来说明。

    假设你的公司使用 5 个内部工具（Slack、GitHub、Jira、内部文档、生产数据库），并且你想让 3 个 AI 模型（Claude、GPT、Gemini）访问这些工具。这意味着需要 15 个自定义集成。每个集成都需要独立的身份验证处理、模式转换和错误管理。当工具或模型更新其 API 时，每个集成都会失效。

    当扩展到真正的企业级规模后。20 种工具。4 种模型。80 个集成。由一支更愿意专注于开发产品功能的团队维护。

    问题接踵而至：

1. 重复代码。 “搜索 Jira 工单”的逻辑无论哪个模型调用都相同。但你却写了三遍，因为每个模型都期望不同的包装器。
2. 脆弱性。Jira更新 API 时，你先修复了一个集成，然后是另外两个。接着你发现第三个集成两周前就悄无声息地失效了，但是却没人发现这个问题，因为这个模型只在周五使用。
3. 不能发现新功能。每个集成都是一个硬编码到应用程序中的定制 JSON 模式。模型无法浏览可用工具、阅读其文档，也无法了解其功能，除非您手动在系统提示符中列出所有函数。
4. 没有状态。函数调用是即用即弃的。模型调用函数，获取响应，但与工具之间没有持久关系。对于简单的查找操作来说，这没问题。但对于多步骤工作流（例如“在 Jira 中查找 bug，从 GitHub 拉取相关的 PR，检查修复是否已部署”），你需要自己将这些无状态调用拼接起来。

注意:

    MCP 并不会取代函数调用，而是对其进行标准化。您的 LLM 底层仍然使用工具调用。MCP 的意义在于，每个工具您只需定义一次，所有模型都可以用相同的方式调用它。您可以将函数调用比作电气标准（例如 110V 与 220V），将 MCP 比作插头形状（例如 USB-C）。MCP 使插头通用化。

    如果你的应用只使用一个模型和三个工具，函数调用就足够了。MCP 会增加架构复杂性，需要运行服务器、管理连接，以及进行安全审计。只有当 N 和 M 都大于 1 且持续增长时，N×M 问题才会真正显现出来。对于一个只与一个模型交互的内部工具来说，MCP 属于过度设计。直接使用函数调用即可。

MCP的工作原理

    MCP 的出现正是因为解决了这些问题。每个工具、每个模型都采用一套协议、一种集成方式。

    该架构具有三个角色，USB-C 的类比映射非常合适。

 

1. 主机就是你的AI应用，比如Claude Desktop、Cursor、ChatGPT、VS Code（搭配Copilot）。用USB-C接口来类比，它就像你的笔记本电脑，需要连接各种设备。
2. 客户端位于主机内部，负责管理 MCP 连接。它处理身份验证、将请求路由到正确的服务器，并管理会话生命周期。这就是 USB-C 端口。一个端口，多种线缆。
3. 服务器通过以下三个基本方式公开特定的工具或数据源：

• 工具：模型可以执行的操作。“发送 Slack 消息。”“创建 Jira 工单。”“查询数据库。”
• 资源：模型可以读取的数据。“此文件的内容。”“#engineering 频道中的最新 50 条消息。”“此数据库的模式。”
• 提示：可重用的模板，整合了用于常见工作流程的工具和资源。“总结今天的 Slack 活动并创建站会报告。”

    该协议本身使用 JSON-RPC 2.0。如果您使用过语言服务器协议（为 VS Code 中所有编程语言提供自动补全功能的基础协议），那么 MCP 正是直接受其启发而设计的。理念相同：使用一个协议来规范一类应用程序与一类工具之间的连接方式。

    以下是用 Python 编写的最小 MCP 服务示例：

from mcp.server import Server 

import mcp.types as types 

 

server = Server( "weather" ) 

 

@server.list_tools() 

async def list_tools (): 

    return [types.Tool( 

        name= "get_weather" , 

        description= "获取城市当前天气" , 

        inputSchema={ 

            "type" : "object" , 

            "properties" : { 

                "city" : { "type" : "string" } 

            }, 

            "required" : [ "city" ] 

        } 

    )] 

 

@server.call_tool() 

async def call_tool ( name: str , arguments: dict ): 

    if name == "get_weather" : 

        # 在这里编写实际的天气 API 调用

        return f" {arguments[ 'city' ]}中的天气：72°F，晴朗"

 

    就是这样。这个服务器兼容 Claude、ChatGPT、Cursor、Gemini 以及任何未来支持 MCP 协议的型号。你只需要写一次。

    MCP 规范大量借鉴了语言服务器协议 (LSP)，后者解决了编辑器中编程语言支持的 N×M 难题。在 LSP 出现之前，每个编辑器都需要为每种语言定制插件。LSP 出现后，语言服务器可以通用。MCP 将同样的模式应用于 AI 工具集成。如果您正在构建服务器，那么官方规范值得一读。

 

谁能使用它（所有人）

    MCP不再是Anthropic公司的协议，而是整个行业的协议。发布仅12个月，OpenAI、谷歌和微软就都采用了它。2025年12月，Anthropic将MCP捐赠给了Linux基金会旗下的Agentic AI基金会，该基金会由Anthropic与OpenAI和Block共同创立。截至2026年初，MCP的SDK月下载量已达9700万次，拥有数万个社区构建的服务器，并且在ChatGPT、Claude、Cursor、Gemini、Copilot和VS Code等工具中均有原生支持。The New Stack杂志称其为科技史上普及速度最快的协议之一。

 

可能出现的问题（哪些方面被过度炒作）

    MCP 的普及速度令人瞩目，但其安全性方面也存在巨大风险。

    1. 工具投毒攻击。攻击者可以将隐藏指令嵌入 MCP 工具的元数据中，这些指令对用户不可见，但会被 AI 模型使用。在受控测试中，当AI Agent启用自动批准功能时，工具投毒攻击的成功率高达 84% 。这种攻击甚至不需要调用被投毒的工具。只需将其加载到上下文中，模型就能执行其中隐藏的指令。OWASP 发布了针对 MCP 的十大安全漏洞报告来应对这一问题。

    2. 该生态系统尚不成熟。43 % 的公共 MCP 服务器存在命令注入漏洞。热门软件包 mcp-remote 中的一个严重 OAuth 漏洞 (CVE-2025-6514) 在修复前影响了超过 55.8 万次安装。社区已构建了数万台服务器，但质量参差不齐。需要像对待浏览器扩展程序一样对待 MCP 服务器：仅安装所需组件，并确保其来自可信来源，同时定期进行审核。

    3. 上下文窗口的成本是隐藏的。你连接的每个 MCP 服务器都会将其工具定义添加到模型的上下文窗口中。连接 10 个服务器，每个服务器 5 个工具，那么在用户开口之前，你已经消耗了相当于 50 个工具描述的令牌。Cursor 正是出于这个原因将工具数量限制在 30 个。Cloudflare 的“代码模式”方法，即代理按需发现工具而不是预先加载所有定义，据称可以节省 98% 的令牌，但会增加延迟。

 

    MCP 的确是一项重要的基础设施。该协议解决了一个实际问题，其普及程度也证明了这一点。但是，“用于人工智能的 USB-C”这种说法虽然朗朗上口，却低估了其安全漏洞。USB-C 并不会让你的手机充电器读取你笔记本电脑的文件系统，而 MCP 服务器却可以而且确实拥有这种访问权限。这种便利性与风险之间的平衡仍在权衡之中。

    MCP 并不会让 AI 模型更智能，也不会提升推理能力或减少幻觉。它的作用在于让后续集成变得免费。第一个 MCP 服务器只需花费一个下午的时间，第二个只需一个小时，而第十个则完全免费，因为每个模型都已经支持该协议。这才是真正的变革：不是更强大的 AI，而是即插即用的 AI。