1. MCP(Model Context Protocol)是什么模型上下文协议是一种开放标准，可让开发人员在其数据源和 AI 驱动的工具之间建立安全的双向连接。该架构非常简单：开发人员可以通过 MCP 服务器公开其数据，也可以构建连接到这些服务器的 AI 应用程序（MCP 客户端）。 https://www.anthropic.com/news/model-context-protocol
以上是anthropic官网对于MCP的解释，目标是成为 AI 领域的“HTTP 协议”，推动 LLM 应用的标准化和去中心化。而今天，我们盘一盘MCP如何在货拉拉场景下赋能。 新的 AI 应用也很多，但我们都能感受到的一点是，目前市场上的 AI 应用基本都是全新的服务，和我们原来常用的服务和系统并没有集成，换句话说，AI 模型和我们已有系统集成发展的很缓慢。 例如我们目前还不能同时通过某个 AI 应用来做到联网搜索、发送邮件、发布自己的博客等等，这些功能单个实现都不是很难，但是如果要全部集成到一个系统里面，就会变得遥不可及。
我们设定同一个场景，我电脑有一篇自己觉得写的不错的文章，想大模型帮我改写一下或者总结一下提纲。 prompt模式：打开文件-复制粘贴-贴到大模型prompt（尾部增加：请帮我仿写一篇，xxx风格/请帮我总结一下，xxx字以内）-大模型输出-来回修改 Function call模式：丢到本地知识库-构建服务接口-内网穿透-大模型调用注册接口（提供修饰词，不同LLM适配）-准确性质疑 MCP模式：我们直接看下面的图，MCP协议提供大模型和工具的适配接口，互相只用聚焦本身能力上限  
所以，数据与工具本身是客观存在的，只不过我们希望将数据连接到模型的这个环节可以更智能更统一。Anthropic 基于这样的痛点设计了 MCP，充当 AI 模型的"万能转接头"，让 LLM 能轻松得获取数据或者调用工具。更具体的说 MCP 的优势在于： 生态- MCP 提供很多现成的插件，你的 AI 可以直接使用。 统一性- 不限制于特定的 AI 模型，任何支持 MCP 的模型都可以灵活切换。 数据安全- 你的敏感数据留在自己的电脑上，不必全部上传。（因为我们可以自行设计接口确定传输哪些数据）
2. 区别大概了解了MCP是什么，也需要和目前业界主流的几个概念，从多个维度进行对比，有助于判断MCP可以用于哪些业务场景。 2.1 MCP vs Function Call vs Agent | MCP Server | Function Call | Agent |
|---|
定位对比 | 被动的工具箱 被动服务,仅响应调用请求 为大模型提供外部数据和能力支持 不参与决策或推理过程 像工具箱,等待别人挑选使用
| 瑞士军刀 直接扩展模型能力的机制 允许模型生成请求参数并整合结果 与模型绑定部署,紧密集成 像瑞士军刀,小巧多功能,随身携带
| 具备自主决策能力的AI实体 | 交互方式 | 单向响应 采用被动服务模式,仅在接收请求时响应 通过HTTP/SSE协议接收请求,返回数据 数据流向:模型→MCP Server→模型
| 模型内部触发 由模型运行时环境直接执行 开发者需预先定义函数并打包到模型服务中 数据流向:模型→函数执行环境→模型
| 双向交互 具备高自主性,可主动调用工具 能与用户进行双向交互,澄清需求 数据流向:用户-Agent-各种工具/服务
| 应用场景 | | | 适合端到端复杂任务 客户服务自动化 处理:自动监控用户反馈、分析问题、生成解决方案
|
2.2 选择依据任务复杂度 |
|---|
简单低延迟任务 | Function Call | 复杂数据整合任务 | MCP Server | 自主决策多步任务 | Agent |
协议标准化需求 |
|---|
无强制协议 | Function Call | 严格遵循标准 | MCP Server | 依赖底层工具 | Agent |
部署灵活性 |
|---|
需与模型绑定 | Function Call | 可独立扩展 | MCP Server | 需集成多种模块 | Agent |
因此，如果需要和我们原来常用的服务和系统集成，又需要快速利用大模型本身的推理分析能力，把公司内部的服务封装为MCP server是一个很好AI赋能的思路
3. 原理摘自官网https://modelcontextprotocol.io/introduction
MCP 的核心是客户端-服务器架构，其中主机应用程序可以连接到多个服务器： MCP 主机 ：希望通过 MCP 访问数据的程序，例如 Claude Desktop、IDE (curosr, windsurf) 或 AI 工具(cherry studio) MCP 客户端 ：与服务器保持 1:1 连接的协议客户端 MCP 服务器 ：轻量级程序，每个程序都通过标准化模型上下文协议公开特定功能 本地数据源 ：MCP 服务器可以安全访问的您的计算机文件、数据库和服务 远程服务 ：MCP 服务器可通过互联网（例如通过 API）连接到的外部系统
4. 货拉拉实践4.1 招聘推荐货拉拉内部有很多适合包装为MCP server的场景，今天以招聘推荐业务举例： 场景：企业招聘平台、简历数据库数据分散在不同平台，需要根据招聘岗位需求利用AI能力找到最合适的候选人 价值：通过MCP统一协议连接多个系统，AI模型可自主按需获取查询岗位、职位数据，将招聘找人效率提高40% 流程： 首先，内部服务提供接口能力 提供获取岗位JD的接口 提供内部封装的简历粗排能力 大模型根据MCP调用结果，给出对应的简历推荐理由
实现一个MCP Server也非常方便，例如使用Python，通过注解即可实现一个简单的本地Server importrequestsimportjsonfrommcp.server.fastmcpimportFastMCP# 创建MCP服务器mcp = FastMCP()@mcp.tool()defget_job_list(job_name="", page=1, page_size=20): """ 获取职位列表和对应的jobId
参数: 职位名称: 职位的名称关键词，如"安全"、"工程师"等 页码: 分页查询的页码，默认为1 每页数量: 每页返回的职位数量，默认为20 """
payload = { "jobTitle": job_name, "page": page, "limit": page_size }
try: response = requests.post(URL, headers=HEADERS, data=json.dumps(payload)) response.raise_for_status() # 检查请求是否成功 returnresponse.json() exceptExceptionase: return{"错误":f"获取职位列表失败:{str(e)}"}
实现完成后配置到Client中，即可调用：
4.2 后续展望我们也可以实现将不同的业务都封装为MCP Server，用户使用Client输入请求的时候会调用多个MCP Server完成任务，达到1+1>2的效果。同时也可以接入部分外部MCP Server，例如地图，搜索，社交媒体热度等，赋予Client在通用能力上的提升。 试想这么几个场景： 对于数据分析同事，在分析舆情事件时，之前需要在观点平台查找对应的时间段与事件，然后通过组装SQL语句在BigQuery中查询对应数据，下载数据，然后进行可视化。如果使用MCP，可以直接在Client输入需要分析的时间段，就可以依次调用观点MCP Server、BigQuery MCP Server、本地可视化的MCP Server，来输出需要的结果，大大提升工作效率； 对于平台同事，之前可能需要维护一个产品说明文档、接口文档，以及值班同事来及时解答各个接入平台的使用方。使用MCP Server之后，可以把自身平台的常用能力封装到Server中。使用方只要在Client端勾选该平台的MCP Server，即可通过自然语言对话的方式进行使用，无需再拼接接口，入参、解析出参。 对于开发同事，开发效率也可以有效提升。之前需要与各个平台讨论接口方案，解析返回JSON，现在可以使用Client调用平台的MCP Server即可。
当MCP Server变得繁多了，可能也有以下挑战： MCP Server选择困难：Client较难选择更合适的MCP Server去调用，需要花费较多时间去尝试不同的调用方案，不同的Server排列组合导致尝试成本指数级上升。此时可能需要开发Client端更好的记忆功能，对调用成功的路径进行记忆保存；以及Server端服务评级机制，择优调用。 安全与鉴权：目前开源版本的MCP暂时没有考虑鉴权与访问权限，MCP Server可能会将有害信息植入Client，或者Client把本地个人隐私信息上传到网络中。
5. 目前行业情况下图可以发现，无论是MCP server，MCP client，MCP marketplace，已经有很多公司开始布局，感兴趣的可以去对应官网了解一下～ 6. 展望从互联网技术演进的视角来看，MCP协议的出现标志着互联网进入以AI Agent为核心的新阶段，其本质是构建适应人工智能自主交互的基础设施层。这一进程可划分为三个阶段： 维度 | PC互联网1990s-2000s | 移动互联网2010s-2020s | AI Agent互联网2020s+ | 核心协议 | HTTP协议 | API接口 | MCP协议 | 工具形态 | 网页 | 移动应用 | MCP服务器 | 交互主体 | 人类 | 人类+APP | AI Agent | 连接方式 | 超文本链接 | API调用 | 动态服务发现 | 场景 | 信息检索： 用户需手动输入URL或关键词检索信息，门户网站和搜索引擎成为主要入口 | 移动支付： 用户通过点击操作调用特定功能，但每个应用仍需要独立开发接口，形成"应用孤岛" | 跨系统任务自动化： 协议层革命 通过标准化交互协议，实现AI与工具的动态连接。MCP客户端可自动发现并调用符合协议的工具服务器，突破传统API的静态绑定模式。 货运场景，AI能即时整合司机订单信息、地图、定价等跨系统工具。
交互范式升级 • 工具层（MCP服务器）：标准化服务供给这种架构使复杂任务
• 协议层（MCP）：动态工具发现与执行保障
• 智能体层（如Claude）：任务解析与决策中枢
从"人操作工具"转向"AI代理操作工具"，形成三层架构： 舆情评估监测，AI能自动分解为收集舆情信息、情绪分级、异常监控、自动拉群分配处理等子任务，由不同工具服务器协同完成。
生态体系重构 • 基础设施：需新型托管平台支持长任务管理、跨服务器负载均衡等特性
• 定价机制：动态竞价市场可能形成，AI根据实时性能指标择优选用工具
• 开发模式：从API定制开发转向工具市场建设，开发者通过构建MCP服务器参与生态
催生新型技术价值链： 21st.dev的商业化MCP服务市场，实现"一次开发，多端调用"的生态效应。
| 不足 | | 工具生态呈现碎片化 数据流通受限于平台壁垒
| 标准化建设（如OpenAI等巨头的协议竞争） 安全机制完善（动态权限控制） 生态治理（开源社区碎片化）
|
| 
