MCP简介：从碎片化走向共享工具服务器

如果语言模型能够与现实世界建立连接、进行交流并采取行动会怎样？MCP正是将智能与行动相连的桥梁。

ChatGPT于2022年11月30日推出，推动了人工智能在生产力提升、日常任务处理及问题解决等方面的广泛应用。随后，各厂商将人工智能整合到人们已常用的产品中：生产力套件、聊天应用、搜索工具、集成开发环境以及企业软件。助手们也不再仅仅是独立的聊天机器人。

但随之出现了更棘手的问题。虽然模型具备推理和写作能力，但要完成有意义的工作还需要合适的上下文、数据、工具以及系统。要将这些要素整合起来，通常需要定制化的集成方案、API接口、身份认证机制以及针对特定工具的代码。这种分散状态有个专门的名称：碎片化。

碎片化问题

当团队使用多种人工智能助手时，由于每种助手都局限于自身的生态系统，碎片化现象便会出现。

想象一下在 VS Code 中工作的开发者。编辑器内的助手能够理解该代码库中的内容。一旦他们需要使用 IDE 之外的 GitHub issues 或 Confluence 页面，就必须离开助手，复制文本再粘贴回来，同时希望模型能获取足够的上下文信息。

这种频繁切换工具以及手动传递上下文的行为会导致工作碎片化：虽然模型很智能，但它无法自动感知任务所需的全部系统。

“上下文”的含义

上下文指的是模型在回答问题时所能看到的所有信息。实际上，就是大语言模型用来组织回复的内容——通常是聊天记录以及用户粘贴的文本。

例如：使用 ChatGPT 开发安全功能时，开发者可能会：

1. JIRA ——将需求和验收标准复制到聊天窗口中。
2. GitHub ——粘贴相关的实现代码和代码库。

MySQL — 手动提取系统数据并输入。

Google Drive — 粘贴文档、安全指南和架构说明。

Teams/Slack — 收集来自团队成员的未文档化的隐性知识。

只有到这时他们才会提出真正的问题。虽然模型能给出更好的答案，但这个过程却很痛苦：

• 在各个系统之间手动复制粘贴效率低下。
• 上下文分散，开发人员变成了“人工API”。
• 整理时间可能超过开发时间本身。
• 来源越多，这一流程就越难扩展；实际系统规模远超过粘贴缓冲区的容量。

正是这种痛苦推动了2023年中函数/工具调用的出现（这也是OpenAI正在研究的方向）。

函数调用

函数调用使模型能够通过函数获取外部资源，并将这些结果作为上下文使用。原本仅限于对话的功能现已发展为任务自动化：模型选择工具，应用执行该工具，随后模型继续处理后续工作。

由于已有针对JIRA、GitHub、MySQL、Drive、Slack等工具的定义，模型可以根据用户提示选择要调用的工具，获取上下文信息并给出答案——无需人工反复粘贴数据。

单应用函数调用的局限性

想象一家公司里有三个AI助手。每个助手仍需要独立的函数或集成功能来连接数据库、GitHub、JIRA、Slack等系统。

如果拥有N个助手和M个外部资源，就需要构建N×M个集成接口。10个助手搭配20个资源大约需要200个定制链接。随着规模扩大，维护这样的集成结构会变得极为昂贵。

如果每个应用仍需自行处理所有集成，那么碎片化问题只会转移：上下文组装的难题变成了集成难题。

N × M 的模式能否简化为 N + M？这就是 MCP 发挥作用的地方。

模型上下文协议（MCP）

MCP 是一种开放协议，用于规范人工智能应用如何连接外部工具、数据和服务。

它主要有两个角色：

• MCP 客户端——存在于人工智能应用/智能体中，连接服务器并发现及使用所提供的工具/资源。
• MCP 服务器——充当人工智能应用与 GitHub、JIRA、数据库、Drive、Slack 或其他服务之间的桥梁。

客户端与服务器之间通过 MCP 进行通信。这样，应用无需为每个供应商单独开发适配器，只需通过统一格式即可发现并调用相应功能。

函数调用与 MCP 的对比——以天气查询为例

1. 函数调用

你需要定义一个应用内部的函数来调用天气API：

import requests

def get_weather(city):
    response = requests.get(
        "https://api.weather.com/current",
        params={"city": city}
    )
    return response.json()

将该函数注册为工具。当用户询问“班加罗尔的天气如何？”时，模型可以调用get_weather("Bengaluru")。应用执行该函数并返回数据，模型随后生成回复。

应用团队负责定义和维护该函数及其相关的API接口。

2. MCP

天气数据存储在MCP服务器上，该服务器负责与API通信并提供标准工具：

@mcp.tool()
def get_weather(city: str):
    """Get the current weather for a city."""
    return weather_api.get_current_weather(city)

AI应用则是MCP客户端，它能够发现get_weather功能。面对同样的用户问题，应用会通过MCP发现或调用该功能，并在回复中使用其返回的结果。

两者的区别在于：MCP规范了AI应用与功能之间的交互方式，因此一台服务器可以为多个兼容的客户端提供服务。

MCP的优势

• 相比按应用划分的功能目录，重复性维护更少
• 减少在集成过程中产生的成本与时间消耗
• 在服务器端形成更清晰的安全边界
• 集成扩展的规模更接近 N + M 而非 N × M

这就是其背后的原因。后续内容将介绍相关架构、内部机制以及实际实现方法。

再次梳理安全功能的相关内容

回到负责构建安全功能的开发人员视角。在没有 MCP 或相关工具的情况下，他们不得不在 JIRA、GitHub、MySQL、Drive 和 Slack 之间四处寻找所需资源，每次切换都需要手动复制上下文信息。而通过函数调用，这些操作可以转化为模型能够调用的命名函数——不过公司里的每个助手仍然需要自己独立的集成版本。

MCP 消除了这种重复。一个天气服务器、一个 JIRA 服务器、一个 GitHub 服务器即可为多个 MCP 兼容的客户端提供服务。N×M 的网格结构实际上更接近于 N 个客户端加上 M 个服务器。

团队常忽略的设计要点

将工具描述视为产品宣传文案：清晰的名称和参数文档有助于用户选择正确的模型。应将写入类工具置于确认流程之后，并将它们与只读的目录工具分开部署。为工具调用记录关联 ID，这样一旦出现错误响应，就能追溯到是检索环节出了问题，而非笼统地归咎于“模型”本身。

在为新系统选择函数调用方式还是 MCP 时，要明确谁来负责整个集成流程的维护。如果答案是“所有产品团队永远负责”，那么 MCP 的共享服务器模式就能体现其价值；如果答案只是“一个临时演示”，那么使用本地函数即可。

未来展望

一旦明确了动机——即碎片化、上下文整合以及集成带来的问题，接下来的工作就是架构设计：客户端如何发现工具、服务器如何进行身份验证、会话如何传输结果，以及如何部署第一台生产环境服务器。这些主题需要专门的深入探讨；本文的任务是让“为何如此”变得无可辩驳，并通过两种方式展示天气示例。

碎片化作为预算问题

算一算你的团队把JIRA和GitHub的内容复制到聊天框中所花费的小时数。这些工作量相当于为你采用的每一个AI助手征收的“税”。函数调用虽然减少了复制时间，但却增加了适配器代码的量。MCP的目标是将成本集中在共享服务器上，而非为每个助手单独创建分支。

用这些术语来阐述业务价值：减少人工处理API的时间、避免重复集成、明确审计要点。对财务部门而言，架构图不如N×M表格重要。

给审核人员的天气功能示例要点

在函数调用路径中，天气相关的HTTP客户端位于应用内部；而在MCP路径中，则位于其他应用可重用的服务器上。相同的用户指令，整合的所有权却不同。如果已计划开发第二个客户端，则优先选择服务器端方案；若该实验将在下一个迭代终止，则优先使用本地函数方案。