1960 字
10 分钟
MCP——打破AI数据孤岛的「Type-C」标准
为什么需要MCP?大语言模型最初出现时，用户需要手动将代码或信息复制粘贴到文本界面才能进行交互。这种方式很快就被证明不够用，所以需要进行自定义集成还更好地加载上下文。但是，这些集成方案分散并且都需要单独开发。于是 MCP(Model Context Protocol)应运而生，它通过提供一个通用协议，来高效地实现AI与本地或远程资源的交互。
什么是MCP？
Model Context Protocol (MCP) 是一种开放协议，它实现了 LLM 应用程序与外部数据源和工具的无缝集成。该协议由 Anthropic 于 2024 年 11 月 25 日发布。
MCP 通过定义标准化的接口和协议，使 LLM 能够动态访问和集成以下内容：
- 外部数据源：如数据库、API、文档库等，为 LLM 提供实时或历史数据
- 工具和服务：如计算工具、搜索引擎、第三方服务等，扩展 LLM 的功能
- 上下文管理：动态维护 LLM 的对话上下文，确保连贯性和一致性
NOTE如文章封面所示，MCP可以被视为AI系统的「USB 标准」。
在 USB 出现之前，每个设备都需要自己专有的连接器。同样，在 MCP 之前，开发人员必须为每种 AI 应用程序和数据源的组合创建自定义集成。MCP 建立了一个通用的「即插即用」协议，允许任何兼容 MCP 的客户端与任何兼容 MCP 的服务器协同工作，大大降低了集成复杂性和开发时间。
核心架构：客户端-服务器（Client-Server）三元模型
优势
- 架构级突破：破解“MxN”集成困境: 颠覆了传统一对一接口适配模式，通过“主机-客户端-服务器”三元架构，将多模型与多工具的适配复杂度从“MxN”转化为“M+N”。例如1万个AI应用与1万个数据源对接，传统模式需1亿次适配，MCP仅需2万次配置，效率提升5000倍，彻底解决企业30%开发资源浪费在接口适配的痛点
- 核心适用场景明确：MCP的价值并非服务于agent开发者，而是解决 向无法控制/开发的第三方agent(如Claude Desktop、Cursor)接入自定义工具的痛点，填补了“外部工具与非自有agent对接”的协议空白
- 面向非开发者，降低agent工具扩展门槛：能让某些领域专家等无技术背景者为agent添加所需工具，无需编辑agent底层逻辑，契合“agent构建平民化“的趋势
- 短期效果够用，长期随模型进化持续提升：虽然当前基于MCP的agent可靠性并非100%，但模型的工具调用能力会持续优化，成功率想必会逐步提升，且优质的
MCP Server的工具描述、内置提示词能弥补手动配置的不足，对个人/内部agent等非生产级场景已具备实用性- 生态初具规模，叠加模型能力提升，比过往同类方案（如 OpenAI Plugins）更有优势：MCP 当前生态已远超此前的 Plugins，且如今模型的工具调用能力远胜从前，能更好发挥 MCP 的价值
不足
- 当前模型工具调用能力不足，MCP 放大这一缺陷：内部基准测试显示，即便是为特定工具定制的 agent，模型仍有近 50% 的概率调用错误工具；将随机工具接入无适配的第三方 agent，失败率会更高，即便是个人 agent，这种低成功率也基本无实用价值
- 部署与体验缺陷: 现阶段需本地终端部署服务器，仅适配桌面端，无一键安装、服务注册发现，跨环境部署效率低
- 协议设计短板: 无原生服务注册、自动重连、故障转移；Schemaless JSON 易引发静默错误，版本管理与兼容性检查不足
- 生态与运维挑战: 跨厂商实现差异大，公共 MCP 服务器质量不稳定，约 80% 存在配置错误或无法使用，运维成本高
- 性能与规模化瓶颈: 工具列表随数量增长线性占用 Token，高频与长尾工具无区分，Token 利用率低，复杂任务成功率不足 20%
MCP的未来
结合当前大模型Agent生态的发展趋势以及MCP目前的技术与落地痛点，个人认为，MCP的未来改进可能需要围绕 体验轻量化、协议精简化、能力适配化、生态标准化、部署规模化等几个核心方向推进。同时，应该锚定『第三方Agent工具接入、非开发者优化』的核心定位。
Q & A
MCP和Function Call有什么区别？
对比维度 Function Call MCP（模型上下文协议） 核心定位 大模型调用外部函数的基础机制，侧重模型与工具的直接交互能力，是 “操作执行层” 技术 开放标准化协议，定义模型与外部资源（函数、文件、数据库等）交互的通用规范，是 “交互标准层” 协议 发起主体 模型在生成响应时，自主决策调用预定义函数，生成参数后由系统执行 由 MCP Client 发起请求，通过 MCP Server 对接工具 / 资源，模型无需感知底层工具实现，只需对接 MCP Client 交互架构 模型 - 工具直接交互，多为静态绑定，无中间层，扩展性受限 用 Client - Server - Host 三层分布式架构，支持多工具协同、负载均衡，模型与工具双向解耦 协议标准化 台特定，不同厂商（如 OpenAI、Google）的 Function Call 格式、认证机制不兼容，无统一标准 跨平台开放标准，定义统一请求 / 响应格式、认证、服务发现规则，任何遵循协议的模型和工具均可互通 工具发现 需提前静态注册函数清单，运行时无法动态发现新工具，扩展需修改配置或代码 支持运行时动态发现，模型 / Agent 可通过 MCP Server 自动发现可用工具，无需提前注册 资源支持范围 主要聚焦外部函数 / API 调用，以获取实时数据或执行特定操作 盖函数、文件（PDF/Excel）、向量数据库、长期记忆体等全品类上下文资源 通信方式 以同步调用为主，异步能力有限，并发处理效率较低 异步优先设计，全面支持异步通信，提升系统并发处理能力，适配分布式场景 安全与权限 基本身份验证，权限管理分散，缺乏统一的审计和管控机制 提供完善的权限管理、传输加密、敏感信息隔离及审计能力，支持数据血统和出处追踪 生态开放性 生态相对封闭，依赖特定模型厂商的接口和生态，跨框架迁移成本高 迁移成本高开放生态，主流 Agent 框架（LangChain、LlamaIndex 等）已开始支持，鼓励第三方开发可复用服务器，形成共享工具生态 典型应用场景 简单工具调用，如天气查询、数据计算等独立函数调用场景 复杂多工具协同任务，如企业级数据分析（连接多数据源）、智能助手（对接本地文件 + 远程 API + 记忆系统）等复杂上下文交互场景
附录
Model Context Protocol (MCP) Quickstart
Waiting for api.github.com...
MCP——打破AI数据孤岛的「Type-C」标准
https://blog.oceanh.top/posts/other/mcp协议/