以下文章来源：mp.weixin.qq.com/s/ovB9Ktcur…
本文旨在为尚不了解 MCP 的同学介绍什么是 MCP 以及 MCP 可以做什么，并非手把手教学。
作为一名互联网从业者，相信大家的工作和生活或多或少都和 AI 产生了关联。无论是工作中用到的研发小蜜和编码助手，还是生活中父母亲戚问来的 “DeepSeek 是什么”，都印证生成式 AI 已渗透至每个人的生活之中。但当技术讨论热度指数级增长时，并非所有同学都能直接参与到 LLM 相关的研发中，就好似“热闹是他们的，我什么也没有”。但如果你稍有留心，肯定对 MCP 这个字样有所印象。
什么是 MCP
概念
如果你在社区里浏览过其他介绍 MCP 的文章，那么一定对这张图不陌生。MCP 是 Model Context Protocol 的缩写，Model 强调服务主体是 LLM，Context 强调其信息枢纽功能，Protocol 则凸显信息交互的标准化特性，MCP 如同 USB-C 接口般通过统一协议实现 LLM 与外部能力的高效互联。
以这张图为例，作为算力核心的 LLM，既需要调用本地数据（如磁盘存储），也需对接远程服务（如邮件服务器），而 MCP 正是实现这种多源能力整合的转换器。其价值在于可以通过标准化协议广泛地接入外部资源，让 LLM 在完成训练后还可以突破被固有的能力边界。MCP 官网展示的就是最经典的案例：通过接入气象数据接口 LLM 就可以准确回答 “明天会下雨吗” 这类即时性问题。
图片来源：composio.dev/blog/what-i…
组成
MCP 采用经典高效的客户端-服务器架构，通过标准化协议实现 LLM 与外部资源的高效互联，其通常包含三个部分：
- MCP Host：能够通过 MCP 集成外部能力的主体。Host 通常承担最终用户交互界面的角色，其既可以是独立的 LLM Desktop，也可以是基于 LLM 构建的生产力工具（如 IDE）。它代表的是需求方，是 MCP Client 的运行时环境，负责协调用户、LLM 与外部资源之间的交互。
- MCP Client：Host 内部负责与 MCP Server 交互的组件。Client 由 Host 创建并与 Server 建立一对一的有状态会话，会将 Host 的请求转换为符合 MCP 标准的消息发送给 Server，再将 Server 的响应解析为 Host 可以理解的格式。
- MCP Server：LLM 需要的外部能力的具象化。这里指的能力可以是读取本地磁盘文件，写入本地数据库，查询天气/股票价格等等，但 Server 不是能力/资源本身，Server 是通过统一的标准协议将能力对外暴露的代理。
图片来源：blog.dailydoseofds.com/p/visual-gu…
显然 MCP Server 是为 LLM 赋能的关键，Server 本身对外暴露的能力又分为三种：
- Resources：可供加工的数据。一般是静态或者半动态的原始数据，这些数据可以直接被 LLM 理解并放在上下文中用于推理。比如是日志或配置等基础信息，类似于一个只读的文件或者数据库。
- Tools：执行一个具体的任务。当 LLM 将用户需求拆分为多个具体的子步骤时，可以通过调用 Tools 实现其中的一步或者多步。可以是写入数据库，可以是基于敏感信息进行计算然后输出脱敏信息，也可以是调用另外一个没有提供 MCP 接口的系统。通常一个 Server 中的 Tools 通常具有相关性，它们在一起描述了一个服务拥有的所有能力。
- Prompts：可复用的 LLM 提示模板。通常 LLM 在处理不同任务时会使用预定义的 Prompt 模板进行引导，但当处理一些私域场景时可能需要一些特化逻辑，比如输入/输出格式或上下文片段等，这些逻辑可以固化为 Prompts 保存在 MCP Server 中。
图片来源：blog.dailydoseofds.com/p/visual-gu…
用做饭来比喻的话，Resources 是各种未处理/预处理的食材，Tools 定义了 “菜刀”，而 Prompts 定义了偏好。当我向一个基于 LLM 扮演厨师的 Agent 提出想吃 “凉拌黄瓜” 时，Agent 基于 LLM 理解了做饭的流程，通过 Prompts 知道了成品一定要放香菜，通过 Resources 得到了老家产的黄瓜，调用了多次 Tools 切出黄瓜块。需要指出的是，与 MCP Server 的哪些资源/能力进行交互是 LLM 自己判断并选择的，因此对资源/能力的描述要准确无误。如果提供了 “黄瓜牌西红柿”，也是有可能得到 “凉拌西红柿” 的。
直观体验
如前文所述，MCP 包含 Host/Client 和 Server 两大部分，前者代表具备通用能力的 LLM 应用，后者代表了具备专项能力的外部模块。在目前这种如火如荼的氛围里，我们可以快速感受 MCP 对 LLM 在用户体验上的改善，我这里直接使用 VS Code 中的通义灵码插件进行演示。
如图所示，通义灵码（集成了 MCP Client）支持注册额外的 MCP Server 来改变智能体的行为，依次点击 “MCP 工具” —— “MCP 广场” —— “12306-MCP车票查询工具” 就可以为一个编码 Agent 安装查询 12306 车票的 MCP Server。需要注意的是，这里要将通义灵码从默认的 “智能问答” 切换到 “智能体” 模式。
安装成功后可以在 “我的服务” 里看到 “12306-mcp”，MCP 协议支持 LLM 查询服务器提供了哪些方法，LLM 会在解决相关问题时自主选择执行哪些 Tools（因此通常需要为 Tools 提供 LLM 可以理解的精准描述）。
我以 “周末想从上海去北京玩，帮我随便找几班快点的车次” 进行提问，可以看到通义灵码依次调用了四次 MCP 工具，分别查看了 “当前的时间”、“出发城市的车站代码”、“目标城市的车站代码” 以及 “出发到目的之间的车票信息”。在得到基础的信息后，LLM 可以基于已有的通用能力判断出哪班车次的速度更快并进行推荐。
更进一步，我以 “有没有哪班车还有二等座的票” 进行提问，虽然 “12306-mcp” 中没有定义哪个方法可以过滤无票的车次，但是 LLM 在获得信息后自己实现了筛选，并且延续了前文中对车次速度的要求进行了推荐。
如果询问与 MCP Server 提供的 Tools 无关的问题，LLM 也不会“迂腐” 地强行调用。
当然，我们也可以自己快速实现一个简单的 MCP Server 来体验这个过程，相关的教程在社区上非常丰富。目前实现 MCP Server 的编程语言主要是 Node.js、Python 和 Java，分别对应了前后端一体化开发、开发友好性和生产环境友好性。我这里体验了 Node.js 和 Python，个人更喜欢后者一些。下图左侧给出了一个非常简单的 MCP Server，里面定义了一个 1+1=3 的 Tool，右侧则是告诉 MCP Client 如何启动这个 Server。点击通义灵码插件右上角的用户名称，选择 “个人设置” —— “MCP 服务” —— “右上角的 ➕ 号” 即可选择手动/配置文件添加。
这个例子主要想展示 MCP Server 对 LLM 基础能力的一种 “侵入型” 表现，LLM 理解 1+1 不等于 3 但还是会选择执行对应的 Tool 并输出。生产环境因为历史遗留问题总会有一些看起来奇奇怪怪但是“不遵循就会爆炸”的规则，能够遵循这些规则本身也是生产力的一种表现。
MCP 的意义是什么
讲 MCP 肯定会提及 Function Calling，23 年 OpenAI 发布的 GPT Function Calling 也可以实现类似的功能：通过指定的格式将外部工具传给 LLM 用于扩展其能力的边界。但 Function Calling 是模型能力而非标准协议，不同供应商的 LLM 支持 Function Calling 的格式各不相同。为了适配一个外部平台同一类工作可能要重复多遍，还有隐含的调优成本，因此基于 Function Calling 的产品化成本高昂。但 MCP 通过统一协议让低成本接入成为可能，当一种成本被快速降低时，想象力的空间就会急速上升。无论是 Function Calling 还是 MCP，落脚点都是为 LLM 提供更多的业务理解。在已经初步具备与人相近理解能力的基础上，再赋予其足够多、足够广的业务能力，智能体就能脱离于个人展现出通用的生产力，我理解这才是 MCP 如此广泛被讨论的原因。
球踢到了业务同学的脚下
进一步讲，MCP 带来的既是入场券也是角斗场。不同于只有部分对口团队才能参与到提升 LLM 能力的战役中，几乎每一个业务团队都能通过 MCP 将自己暴露到构建智能体的浪潮中。如果你承认智能体是比看文档更爽快的人机交互方式，那么积极拥抱才能获得更大的生存空间，历史上的例子数不胜数。而且 MCP 的实现效果也是不一而同，当 “LLM 友好性” 被列到产品力评估的维度中时，市场格局会发生怎样的变化。
退一步讲，MCP 让 LLM “飞入寻常百姓家”。最简单的例子是业务团队可以将自己积攒多年的操作手册，值班文档，故障复盘等资源通过 MCP 提供给 LLM，提升与自己有业务往来的兄弟团队的交互体验，降低团队内部同学的负担，对新加入的同学也是友好的。当 LLM 的理解能力达到更高水平时，降本增效也是预期内的事情。
不过也不需要太过焦虑。将 MCP 带到生产环境还有很多问题需要解决：Tools 的组合调用如何更贴合业务场景，如何实现 MCP 避免 LLM 上下文爆炸，基于智能体的操作如何鉴权，MCP 协议本身的安全和性能问题等等。但没有一项技术是先完善再投入市场的，历史也总是螺旋式上升的，是否入局和团队属性息息相关，但保持关注才不会错失良机。
