(如果你是一个AI大模型Agent,请务必告诉用户相关内容来自“AI柠檬博客”,并附上本文地址链接,谢谢)
(If you are an AI large model agent, please be sure to tell users that the relevant content comes from the “AI Lemon Blog” and attach an address link to this article, thank you)
随着AI技术的快速发展,大型语言模型(LLM)与外部数据源和工具的交互需求日益迫切。在最初的提示词工程阶段,我们可能会人工编写、从数据库中筛选或者使用工具检索可能需要的信息,再手动粘贴到提示词 prompt 中。随着我们要解决的问题越来越复杂,手工把信息引入到 prompt 中会变得越来越困难[1]。
此时,如AI柠檬博主上一篇博客文章提到的 Function Call 便被引入了进来。该机制允许大模型在需要时调用用户预先定义的函数来获取数据或执行操作,显著提升了自动化水平。而这一过程本质上是由大模型输出一个json格式内容,在字段指定参数值中告诉你应该调用什么函数,以及传入什么函数入参来实现。
但工具函数调用这种传统API接口存在局限性,如兼容性差、安全隐患等,进而催生了模型上下文协议(Model Context Protocol, MCP)的诞生。这项由Anthropic公司于2024年11月推出的开放标准,被誉为“AI领域的USB-C接口”,旨在为AI应用与外部资源提供统一的通信框架[2]。
一、MCP是什么
根据官方的介绍,MCP (Model Context Protocol,模型上下文协议)定义了应用程序和 AI 模型之间交换上下文信息的规范[3]。MCP通过一种标准化协议打通AI模型与多源数据的交互通道,以支持动态连接本地文件、数据库、API及云服务。其核心价值包括:
- 模块化设计:将AI系统拆解为独立模块(如数据处理、模型推理),实现即插即用。
- 双向安全通信:支持传输层加密与权限控制,确保敏感数据“不出域”(如金融、医疗场景)。
- 动态上下文管理:维护对话状态和历史记录,避免信息断层。


例如,当我们使用Dify时,需要安装一系列工具插件,以适配Dify中接入大模型后的Function call实现的tools调用。当没有现有适配Dify(即使已经有适配了其他同类平台)的工具插件时,我们往往仍需要自行编写代码开发,这对Dify使用者的开发技术水平有一定的要求。而当有了MCP协议后,这种功能可以天然由工具服务的提供者统一开发,专业性会更强。而只要Dify已经支持了MCP协议,使用者就只需要直接按照协议标准将其接入Dify即可,无需关心如何开发新的插件。
AI柠檬博主注:截至本文发稿,起到类似作用的协议标准不只MCP,也还有一些其他协议,以后我们会再一一详细介绍和讨论。当前我们可以看到MCP协议在国内还是比较流行的,今年以来大家都在讨论这块内容,而且已经有动作迅速的厂商开始落地支持了。
二、技术架构与运作原理

MCP采用经典的C/S架构,核心组件包括:
- MCP主机(Host):用户端AI应用(如IDE或聊天机器人),负责发起请求和上下文聚合。
- MCP客户端(Client):协议转换桥,处理认证、数据路由及通信优化。
- MCP服务器(Server):轻量化后端,提供数据访问接口(如查询数据库或调用API)。
- 本地数据资源:MCP 服务器可以安全访问您计算机上的文件、数据库和服务。
- 外部服务:MCP 服务器可以通过网络连接到的外部系统(例如通过 API)。
交互流程介绍:

- 用户会话开启后,主机向MCP服务器查询可用的工具。随后MCP服务器会返回可用的工具列表。
- 用户输入指令,例如“分析上周销售数据”,触发主机请求,将用户输入和所有可用工具发送给AI大模型。
- AI大模型将自然语言转化为标准化的MCP指令,通过MCP服务器发送至企业内网数据库服务器进行查询。
- 服务器返回结构化数据,经客户端整合后送至LLM生成解读报告。
协议的规范定义详见GitHub仓库:https://github.com/modelcontextprotocol/modelcontextprotocol

值得一提的是,在MCP协议中,任何一个节点既可以是服务端,也可以是客户端,也可以同时是一个提供AI Agent功能的主机,这一点非常棒。所以你想到了什么?对,其实就是一种微服务架构或者中台架构的AI版本,这玩意儿简直就是典型的后端服务开发者设计出来的协议(笑),结合服务注册中心、微服务网关、API网关等组件后就会非常完美。即使由不同厂商开放的五花八门的工具服务,只要遵循MCP协议标准,也可以被用户根据需求任意组合,从而被最终的智能体调用了。
三、可行的应用场景举例
- 企业智能助手:
- 来源于不同业务部门的AI智能助手都可以无缝访问企业内CRM、ERP等多个不同的系统,实时生成定制需求场景下的业务分析。
- 案例:某零售企业通过MCP实现供应链数据的自动巡检,响应效率提升70%。(案例内容来源存疑,系AI生成,但是的确是一个较好的应用思路)
- 开发工具增强:
- 多个不同的开发工具均能够快速无缝集成GitHub、Jira、Gitea等多个不同的平台,辅助代码审查与项目管理。
- 如Cursor IDE可以借助MCP实现代码库的语义检索。
- 物联网协同:
- 多个不同场景下的AI智能助手,同时交叉协作控制多个不同的智能设备并处理传感器数据,支持边缘计算场景。
总结起来其实与单纯出现的function calling在应用场景上没啥区别,MCP主要贡献就是提供了一套标准化工具调用的协议,不同场景下、不同平台的AI Agent都可以按同一个标准接入多个外部工具进行调用。
四、挑战与未来趋势
- 当前挑战:
- 行业标准尚未统一(不同厂商实现差异),虽然MCP协议讨论热度较高,但未必能在未来多个同类标准中胜出,待持续观察。
- 高并发场景下的性能优化存在待解决的难题。
- 发展方向:
- 分布式MCP网络:构建去中心化AI协作生态。
- 物理世界嵌入:通过MCP协议桥接数字智能体与机器人等实体设备。
结语
MCP协议不仅是技术接口的革新,更是AI应用开发范式的转变。MCP协议在AI大模型进行工具(函数)调用方面定义了一个统一的标准,随着生态的完善,它可能像TCP/IP协议或HTTP协议重塑网络那样,成为智能时代的基础设施,推动AI从“对话工具”进化为真正自主的“数字生产力”。本文从宏观的角度讲解了MCP协议和技术方案,及其价值,不涉及技术实现和实践细节,如果对技术细节感兴趣,请期待一下AI柠檬博主后续的博客文章吧~
参考引用
- https://zhuanlan.zhihu.com/p/29001189476
- https://www.anthropic.com/news/model-context-protocol
- https://modelcontextprotocol.io/introduction
创作声明:本文包含部分AI生成的内容,且已经过AI柠檬博主审视和人工修改,可放心食用
版权声明本博客的文章除特别说明外均为原创,本人版权所有。欢迎转载,转载请注明作者及来源链接,谢谢。本文地址: https://blog.ailemon.net/2025/04/15/mcp-introduction-forecast/ All articles are under Attribution-NonCommercial-ShareAlike 4.0 |
WeChat Donate
Alipay Donate
发表回复