货拉拉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 的模型都可以灵活切换。

• 数据安全 - 你的敏感数据留在自己的电脑上，不必全部上传。（因为我们可以自行设计接口确定传输哪些数据）

大概了解了MCP是什么，也需要和目前业界主流的几个概念，从多个维度进行对比，有助于判断MCP可以用于哪些业务场景。

2.1 MCP vs Function Call vs Agent

2.2 选择依据

因此，如果需要和我们原来常用的服务和系统集成，又需要快速利用大模型本身的推理分析能力，把公司内部的服务封装为MCP server是一个很好AI赋能的思路

摘自官网https://modelcontextprotocol.io/introduction

MCP 的核心是客户端-服务器架构，其中主机应用程序可以连接到多个服务器：

• MCP 主机 ：希望通过 MCP 访问数据的程序，例如 Claude Desktop、IDE (curosr, windsurf) 或 AI 工具(cherry studio)

• MCP 客户端 ：与服务器保持 1:1 连接的协议客户端

• MCP 服务器 ：轻量级程序，每个程序都通过标准化模型上下文协议公开特定功能

• 本地数据源 ：MCP 服务器可以安全访问的您的计算机文件、数据库和服务

• 远程服务 ：MCP 服务器可通过互联网（例如通过 API）连接到的外部系统

4.1 招聘推荐

货拉拉内部有很多适合包装为MCP server的场景，今天以招聘推荐业务举例：

场景：企业招聘平台、简历数据库数据分散在不同平台，需要根据招聘岗位需求利用AI能力找到最合适的候选人

价值：通过MCP统一协议连接多个系统，AI模型可自主按需获取查询岗位、职位数据，将招聘找人效率提高40%

流程：

首先，内部服务提供接口能力

• 提供获取岗位JD的接口

• 提供内部封装的简历粗排能力

• 大模型根据MCP调用结果，给出对应的简历推荐理由

实现一个MCP Server也非常方便，例如使用Python，通过注解即可实现一个简单的本地Server

import requestsimport jsonfrom mcp.server.fastmcp import FastMCP# 创建MCP服务器mcp = FastMCP()@mcp.tool()def get_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()  # 检查请求是否成功        return response.json()    except Exception as e:        return {"错误": f"获取职位列表失败: {str(e)}"}

实现完成后配置到Client中，即可调用：

整理内网接口文档

MCP Server编写

Client调用

4.2 后续展望

我们也可以实现将不同的业务都封装为MCP Server，用户使用Client输入请求的时候会调用多个MCP Server完成任务，达到1+1>2的效果。同时也可以接入部分外部MCP Server，例如地图，搜索，社交媒体热度等，赋予Client在通用能力上的提升。

试想这么几个场景：

1. 对于数据分析同事，在分析舆情事件时，之前需要在观点平台查找对应的时间段与事件，然后通过组装SQL语句在BigQuery中查询对应数据，下载数据，然后进行可视化。如果使用MCP，可以直接在Client输入需要分析的时间段，就可以依次调用观点MCP Server、BigQuery MCP Server、本地可视化的MCP Server，来输出需要的结果，大大提升工作效率；

2. 对于平台同事，之前可能需要维护一个产品说明文档、接口文档，以及值班同事来及时解答各个接入平台的使用方。使用MCP Server之后，可以把自身平台的常用能力封装到Server中。使用方只要在Client端勾选该平台的MCP Server，即可通过自然语言对话的方式进行使用，无需再拼接接口，入参、解析出参。

3. 对于开发同事，开发效率也可以有效提升。之前需要与各个平台讨论接口方案，解析返回JSON，现在可以使用Client调用平台的MCP Server即可。

当MCP Server变得繁多了，可能也有以下挑战：

1. MCP Server选择困难：Client较难选择更合适的MCP Server去调用，需要花费较多时间去尝试不同的调用方案，不同的Server排列组合导致尝试成本指数级上升。此时可能需要开发Client端更好的记忆功能，对调用成功的路径进行记忆保存；以及Server端服务评级机制，择优调用。

2. 安全与鉴权：目前开源版本的MCP暂时没有考虑鉴权与访问权限，MCP Server可能会将有害信息植入Client，或者Client把本地个人隐私信息上传到网络中。

下图可以发现，无论是MCP server，MCP client，MCP marketplace，已经有很多公司开始布局，感兴趣的可以去对应官网了解一下～

从互联网技术演进的视角来看，MCP协议的出现标志着互联网进入以AI Agent为核心的新阶段，其本质是构建适应人工智能自主交互的基础设施层。这一进程可划分为三个阶段：