什么是模型上下文协议(MCP)

MCP

在调研 Manus AI 时,很容易发现「工具不足」的问题。虽然 Manus AI 内置了 29个工具,但这在当前软件生态中远远不够。例如操作 PhotoShop、Holo 等专业工具时仍需重写适配方法,而 MCP 正是为解决这一根本性问题而设计。

MCP(Model Context Protocol)的核心价值在于定义了应用程序与 AI 模型间标准化的上下文信息交换机制。通过这套协议,开发者能够以统一的方式连接各类数据源、工具和功能到 AI 模型,无需为每个特定场景开发独立适配器。[1]

为什么要用 MCP

传统 AI 系统集成外部工具时面临显著挑战。每个 API 都需要独立处理代码实现、文档学习、认证机制、错误处理和持续维护,这种碎片化的开发模式极大增加了系统复杂度。[2] 在 MCP 出现前,AI 助手与外部工具的每次交互都需要预先编码和 API 调用,这种手工对接方式效率低下且难以规模化。

更严峻的是配置组合爆炸问题。假设存在 1000 个 AI 助手和 1000 个外部工具,传统方式需要开发 100 万(1000×1000)个独立连接,而 MCP 通过标准化协议将这个数字降低到 2000(1000+1000)。这种数量级的效率提升重构了智能体生态的连接范式。

打个比方:API 就像是不同的门,其中每扇门都有自己独特的钥匙和使用规则:

APls: Every tool needs its own key

而 MCP 的出现就像为 AI 助手和外部系统打造了一套通用的「标准语言」,堪称是智能体生态的一次「标准化革命」。[3]

一旦某个 AI 助手实现了 MCP 协议,它就能通过这个协议无缝连接上成千上万的外部工具,无需再为每种连接单独编写代码。

同样,外部工具(比如邮件、天气应用等)也只需搭建一次 MCP 服务器,之后所有支持 MCP 的 AI 助手都可以直接与之交互。

假如有 1 万个 AI 助手和 1 万个外部工具。在 MCP 模式下,每方只需实现一次协议,总共只需 2 万次配置。

而按照传统编码方式,每种 AI 助手与每种外部工具都要单独对接,那将是 1 万×1 万=1 亿次配置!

这直接使配置效率提高了不止一个维度。

我们可以用门锁比喻来理解这种变革:传统 API 如同需要独特钥匙的各式门锁(如图),而 MCP 则建立了通用的通行证系统。当 AI 助手实现 MCP 协议后,即可自动接入所有兼容工具;同理,工具开发者只需一次 MCP 服务器部署,就能服务所有支持该协议的 AI 助手。

MCP 的部署灵活性是其另一优势,既支持云端集中化部署,也可在本地设备运行。这种技术特性使其成为连接 AI 模型与外部系统的高速通道,彻底改变了传统手工桥接的低效模式。值得注意的是,传统 API 要求开发者为每个服务单独编写集成代码,而 MCP 通过协议抽象层实现了 “ 一次对接,全网通用 “ 的效果。

维度 Model Context Protocol (MCP) 传统 API
设计目标 标准化 LLM 与多源数据的动态交互,增强模型能力 为特定服务或功能提供固定接口
交互方式 双向协议,支持动态发现和调用工具、资源 单向请求 - 响应,需预先定义接口逻辑
灵活性 模块化设计,支持扩展多种工具和数据源(如 SQL、文件系统) 通常针对单一服务,扩展需重新开发接口
安全性 内置双向安全连接机制(如访问控制、数据加密) 依赖单独实现(如 OAuth、HTTPS)
生态开放性 完全开源,鼓励社区贡献工具和服务端实现 多为封闭式,由服务提供商维护
典型应用 医疗诊断时整合电子病历、实验室数据、医学文献 调用天气 API 获取温度数据

MCP 的优点

  • 统一性与标准化 :MCP 通过定义客户端 - 服务器架构下的通用接口规范(如 JSON-RPC 2.0 格式),让 AI 模型能无缝对接本地文件系统、数据库、API 等异构资源。例如,开发者无需为 Slack、GitHub 等平台单独开发适配器,只需通过 MCP 服务器统一调用功能,大幅降低集成复杂度,类似「万能插座」连接多样化工具。
  • 灵活的可扩展性 :MCP 的轻量级协议设计允许动态扩展新功能,企业可通过接入预制的 MCP 服务器(如 Google Drive、QGIS 集成)快速增强 AI 能力。开源生态中已存在超 1100 个服务器覆盖多场景,且支持本地/远程资源切换,实现「一次开发,多端复用」的敏捷迭代模式。
  • 增强的智能化协作 :双向通信机制使 AI 能执行多步骤任务链,例如从 Slack 消息解析需求、调用代码生成工具、自动提交 PR。上下文保持能力让模型在复杂流程中持续积累信息,而标准化接口则确保工具调用准确性,减少人工干预。
  • 开发效率与成本优化 :通过开源 SDK 和预构建服务器(如 Replit、Block Inc.的实践),企业可 bypass 重复开发,直接复用成熟方案。MCP 的抽象层设计简化了技术栈,让团队聚焦业务逻辑而非底层对接,降低维护成本。
  • 数据安全与合规保障 :MCP 通过服务器端权限控制实现「数据不离域」,例如本地数据库仅开放必要访问权限,避免模型直接接触敏感数据。协议强制要求用户授权机制,确保隐私合规,同时支持企业自定义安全策略。
  • 实时响应与生态兼容 :持久化连接支持实时上下文更新,适配动态业务场景。协议不限定特定模型,允许灵活切换供应商(如 Claude、IDE 工具),避免技术锁定,适应 AI 生态快速演进。

MCP 如何工作:架构原理

MCP 采用简单的客户端 - 服务器架构:

MCP architecture

  • MCP 主机(Host): 如 Claude 桌面应用或智能开发环境(IDE),需要访问外部数据或工具。
  • MCP 客户端(Client): 与 MCP 服务器建立一对一的稳定连接。
  • MCP 服务器(Server): 提供特定功能,连接本地或远程的数据源。
  • 本地数据源(Local Data Sources): 文件、数据库或服务。
  • 远程服务(Remote Services): 外部 API 或互联网服务。

MCP 像一座桥梁: 它本身不处理复杂逻辑,只负责协调 AI 模型与工具之间的信息流动。

Model Context Protocol (MCP) 架构

一图胜千言,理解不了的概念,让 Claude 给我画个图

One More Thing

未来设计趋势:从用户到 Agent 的转变

未来应该面向 Agent(智能代理)设计,而不是仅仅面向人类用户。目前的设计确实主要服务于人类,注重直观性和易用性,以满足我们的需求和偏好。然而,随着人工智能和自动化技术的飞速发展,越来越多的系统将由智能代理直接操作。这意味着设计的焦点需要从「给人看」转向「给机器看」,以适应这一技术趋势。

面向 Agent 的设计要求系统更加结构化、可解析且具备互操作性。智能代理依赖清晰的数据格式、明确的 API 接口和可预测的行为模式来高效完成任务。例如,一个为 Agent 设计的网站可能不会追求视觉上的美感,而是提供丰富的元数据和语义标记,让 Agent 能快速理解和处理信息。

通过将 Agent 作为中介,人类可以享受到更高效、智能的服务。例如,Agent 可以自动化处理繁琐的工作,提供个性化的建议,或在后台完成复杂的计算,让人类用户有更多时间和精力专注于创造性或策略性的任务。这种人机协作的模式可能会重新定义我们与技术之间的关系。

参考资料

The Why·Liam·Blog by WhyLiam is licensed under a Creative Commons BY-NC-ND 4.0 International License.

WhyLiam创作并维护的Why·Liam·Blog采用创作共用保留署名-非商业-禁止演绎4.0国际许可证

本文首发于Why·Liam·Blog (https://blog.naaln.com),版权所有,侵权必究。

本文永久链接:https://blog.naaln.com/2025/03/MCP/