MCP 爆火背后：是技术革命，还是精心包装的“新瓶旧酒”？

無限月讀 發表於 2025-12-10 22:04:00

MCP 爆火背后：是技术革命，还是精心包装的“新瓶旧酒”？

<blockquote>
2024 年末，MCP（Model Context Protocol）火了。各种技术文章蜂拥而至："MCP 革命性突破！"、"AI 工具调用的未来！"、"不懂 MCP 就out了！"
但当你真正去了解时，会发现很多文章要么是概念科普（讲了半天不知道怎么用），要么是愿景描绘（听起来很美好但落不了地）。
这篇文章就是来破局的。 我们不讲故事，只讲本质：MCP 到底是什么？它解决了什么问题？和 Function Call 有什么关系？该不该用？
</blockquote>
<hr>
<h2 id="一mcp-到底是什么">一、MCP 到底是什么？</h2>
<h3 id="11-一句话说清楚">1.1 一句话说清楚</h3>
MCP（Model Context Protocol，模型上下文协议） 是一套标准化的协议，用来规范 AI 应用如何调用外部工具和数据源。
听起来还是有点抽象？我们换个说法：
想象你在开发一个 AI 助手，需要接入：
<ul>
<li>📍 地图服务：查地址、规划路线</li>
<li>🌤️ 天气查询：实时天气、天气预报</li>
<li>📊 数据库：查用户数据、订单信息</li>
<li>📧 邮件服务：发送通知</li>
</ul>
没有 MCP 之前：每个服务都有自己的接口格式
<ul>
<li>A 服务用 JSON-RPC</li>
<li>B 服务用 REST API</li>
<li>C 服务用 gRPC</li>
<li>D 服务要自定义协议</li>
</ul>
你得分别研究每个 API 文档，写不同的适配代码，维护多套调用逻辑。团队协作时还要反复对齐接口格式。
有了 MCP 之后：大家约定统一的"接口标准"
<ul>
<li>工具提供方按 MCP 协议暴露能力（MCP Server）</li>
<li>AI 应用按 MCP 协议调用工具（MCP Client）</li>
<li>格式、认证、错误处理都有统一规范</li>
</ul>
类比理解：MCP 之于 AI 工具调用，就像 USB 之于数据传输。
<ul>
<li>没有 USB 前：每个设备都有自己的接口（各种圆口、方口、扁口），乱七八糟</li>
<li>有了 USB 后：一个标准走天下，插上就能用</li>
</ul>
<hr>
<h3 id="12-mcp-解决的核心问题">1.2 MCP 解决的核心问题</h3>
我们用一个实际场景说明：
场景：你在做一个智能客服系统，需要：
<ol>
<li>查询用户订单状态（调用内部订单系统 API）</li>
<li>查询物流信息（调用顺丰/京东物流 API）</li>
<li>查询商品库存（调用库存系统 API）</li>
<li>发送客服消息（调用企业微信 API）</li>
</ol>
<h4 id="问题-1接口格式不统一">问题 1：接口格式不统一</h4>
<pre><code class="language-javascript">// 订单系统的接口
{
"action": "query_order",
"params": {"order_id": "12345"}
}

// 物流系统的接口
{
"method": "trackShipment",
"arguments": {"tracking_no": "SF123456"}
}

// 库存系统的接口
POST /api/inventory/check
Body: {"sku": "PROD-001", "warehouse": "BJ"}
</code></pre>
每个接口都不一样，你得写大量的适配代码。
<h4 id="问题-2ai-不知道该调用哪个工具">问题 2：AI 不知道该调用哪个工具</h4>
AI 收到用户问题"我的订单什么时候到？"，需要判断：
<ul>
<li>这个问题需要调用什么工具？</li>
<li>需要哪些参数？</li>
<li>参数从用户的话里怎么提取？</li>
</ul>
没有统一规范，每个开发者都自己定义，导致：
<ul>
<li>工具描述格式不一致</li>
<li>参数定义方式不一致</li>
<li>AI 难以准确判断</li>
</ul>
<h4 id="问题-3团队协作困难">问题 3：团队协作困难</h4>
<ul>
<li>前端开发者：后端接口怎么调？参数格式是什么？</li>
<li>后端开发者：AI 会传什么参数过来？怎么处理？</li>
<li>AI 工程师：工具列表怎么维护？提示词怎么写？</li>
</ul>
缺乏标准，沟通成本巨大。
<hr>
MCP 的解决方案：
<pre><code class="language-json">// 统一的 MCP 工具定义格式
{
"name": "query_order",
"description": "查询订单状态",
"inputSchema": {
"type": "object",
"properties": {
 "order_id": {
 "type": "string",
 "description": "订单ID"
 }
}
}
}
</code></pre>
所有工具都按这个格式定义，AI 能统一处理，开发者能快速集成。
<blockquote>
💡 Tip：MCP 不是银弹，它只是把"调用外部工具"这件事标准化了。原有的问题（AI 判断不准、参数提取错误）并没有消失。
</blockquote>
<hr>
<h3 id="13-破除三个常见误解">1.3 破除三个常见误解</h3>
<h4 id="误解-1mcp-是一种新的-ai-技术">误解 1："MCP 是一种新的 AI 技术"</h4>
很多文章会说"MCP 提升了 AI 的工具调用能力"，这是不准确的。
真相：MCP 底层用的还是传统的 Function Call（工具调用）。
看一段 MCP 客户端的核心代码：
<pre><code class="language-javascript">// MCP 客户端决定使用哪个工具
const response = await openai.chat.completions.create({
model: "gpt-4",
messages: messages,
tools: this.tools// ← 这就是传统的 Function Call 参数！
});
</code></pre>
MCP 只是在 Function Call 外面包了一层标准化协议，没有改变 AI 的判断能力。
Function Call 原有的问题依然存在：
<ul>
<li>❌ 工具选择不准确（工具太多时容易选错）</li>
<li>❌ 参数提取错误（复杂参数容易提取不准）</li>
<li>❌ 多意图识别困难（一个问题涉及多个工具）</li>
</ul>
结论：MCP 是协议标准化，不是技术突破。
<hr>
<h4 id="误解-2用了-mcp-就不用自己写工具调用代码了">误解 2："用了 MCP 就不用自己写工具调用代码了"</h4>
很多人以为 MCP 是什么"开箱即用"的解决方案，装上就能用。
真相：MCP 的工作流程和你自己实现 Function Call 几乎一模一样。
对比一下：
<table>
<thead>
<tr>
<th>实现步骤</th>
<th>自己写 Function Call</th>
<th>使用 MCP</th>
</tr>
</thead>
<tbody>
<tr>
<td>1️⃣ 定义工具</td>
<td>写工具描述 + 参数定义</td>
<td>MCP Server 定义工具（还是要写）</td>
</tr>
<tr>
<td>2️⃣ AI 决策</td>
<td>调用 AI 的 Function Call</td>
<td>MCP Client 调用 AI（还是 Function Call）</td>
</tr>
<tr>
<td>3️⃣ 执行工具</td>
<td>后端接收参数，调用真实 API</td>
<td>MCP Server 执行并返回（还是要实现）</td>
</tr>
<tr>
<td>4️⃣ 生成回复</td>
<td>把结果给 AI 生成回复</td>
<td>MCP Client 把结果给 AI（逻辑一样）</td>
</tr>
</tbody>
</table>
本质上是一样的。
那 MCP 的价值在哪？答案是：生态标准化。
当大家都按同一套规则来：
<ul>
<li>✅ 工具能跨项目复用</li>
<li>✅ 团队协作有统一规范</li>
<li>✅ 第三方工具能方便集成</li>
<li>✅ 降低学习和沟通成本</li>
</ul>
但如果你只是一个人开发，或者工具都是自己的内部 API，MCP 的价值就没那么大。
<blockquote>
💡 Tip：把 MCP 理解成"工具调用的接口标准"，就像 RESTful API 是 Web 服务的接口标准一样。
</blockquote>
<hr>
<h4 id="误解-3mcp-服务都是免费的">误解 3："MCP 服务都是免费的"</h4>
看到各种 MCP Server（高德地图、百度地图、天气服务），有人以为调用是免费的。
真相：API 调用成本最终还是要有人承担。
以高德地图 MCP 为例：
<ol>
<li>你通过 Cursor 调用高德地图 MCP</li>
<li>高德的 MCP Server 收到请求后，会调用高德自己的地图 API</li>
<li>这些 API 调用是计费的（按调用次数或配额）</li>
</ol>
有些大厂的 MCP 服务是免费的，但那是因为：
<ul>
<li>前期投入，吸引开发者</li>
<li>调用量有限制（超过就收费）</li>
<li>培养生态、获取数据、占领市场</li>
</ul>
天下没有免费的午餐，只是谁付费、怎么付费的问题。
如果你用 MCP 接入收费服务，要注意：
<ul>
<li>⚠️ 了解计费规则（按次数？按流量？按时长？）</li>
<li>⚠️ 设置调用限额（防止意外超支）</li>
<li>⚠️ 监控使用量（定期检查账单）</li>
<li>⚠️ 考虑缓存策略（减少重复调用）</li>
</ul>
<hr>
<h3 id="14-mcp-的真正价值生态话语权">1.4 MCP 的真正价值：生态话语权</h3>
既然 MCP 没有技术创新，为什么 Anthropic（Claude 的母公司）要大力推？
答案是：争夺 AI 工具生态的话语权。
<h4 id="类比usb-标准的故事">类比：USB 标准的故事</h4>
还记得 USB 标准是怎么来的吗？
1990 年代：
<ul>
<li>键盘用 PS/2 接口</li>
<li>鼠标用串口</li>
<li>打印机用并口</li>
<li>扫描仪用 SCSI 接口</li>
<li>每个设备都不一样，乱七八糟</li>
</ul>
1996 年：
<ul>
<li>Intel、微软、IBM 等巨头联合推出 USB 标准</li>
<li>一个接口统一所有设备</li>
<li>谁制定标准，谁就掌握话语权</li>
</ul>
今天：
<ul>
<li>USB 成为事实标准</li>
<li>USB-IF（USB 标准化组织）掌握生态控制权</li>
<li>新技术（Type-C、USB4）都要通过他们认证</li>
</ul>
<h4 id="mcp-想做的就是-ai-领域的-usb">MCP 想做的就是 AI 领域的 USB</h4>
Anthropic 推 MCP 的真实意图：
<ol>
<li>制定规则：让大家按自己定的协议开发</li>
<li>占领生态：所有工具提供商、AI 应用都接入 MCP</li>
<li>话语权：在未来的标准委员会中占据关键位置</li>
</ol>
如果 MCP 真的成为行业共识：
<ul>
<li>所有模型的工具调用格式可能被统一</li>
<li>Anthropic 在标准委员会的位置举足轻重</li>
<li>能影响整个 AI 工具生态的走向</li>
</ul>
对开发者来说，MCP 的价值在于：
<ol>
<li>✅ 快速接入现成服务：不用研究 API 文档，装个 MCP Server 就行</li>
<li>✅ 团队协作规范：统一配置格式，方便版本控制</li>
<li>✅ 参与生态建设：早期参与者能占先机</li>
<li>✅ 降低集成成本：一次开发，到处运行</li>
</ol>
但也要认清：
<ul>
<li>⚠️ MCP 还在早期，规范可能变化</li>
<li>⚠️ 生态不够成熟，可用工具有限</li>
<li>⚠️ 不是所有场景都适合用 MCP</li>
<li>⚠️ 核心业务逻辑建议自己掌控</li>
</ul>
<hr>
<h2 id="二mcp-的工作原理">二、MCP 的工作原理</h2>
理解了 MCP 是什么，我们来看它具体是怎么工作的。
<h3 id="21-核心工作流程">2.1 核心工作流程</h3>
MCP 的工作流程分为三步，我们用一个实际例子说明：
场景：用户在 Cursor 中问 AI："北京天安门的经纬度是多少？"
<pre><code>第 1 步：用户提问
┌─────────────────────┐
│ 用户 │
│"北京天安门的经纬 │
│ 度是多少？" │
└──────────┬──────────┘
 │
 ▼

第 2 步：MCP 客户端询问 AI
┌─────────────────────┐
│MCP 客户端 │
│(Cursor) │
│ │
│把问题和可用工具 │
│列表发给 AI： │
│- 地理编码工具 │
│- 路径规划工具 │
│- 天气查询工具 │
└──────────┬──────────┘
 │
 ▼

第 3 步：AI 决策
┌─────────────────────┐
│AI 模型 │
│(GPT-4/Claude) │
│ │
│分析后决定： │
│✓ 使用「地理编码」│
│ 工具 │
│✓ 参数： │
│ address= │
│ "北京天安门" │
└──────────┬──────────┘
 │
 ▼

第 4 步：MCP 服务端执行
┌─────────────────────┐
│MCP 服务端 │
│(高德地图 API) │
│ │
│收到请求后： │
│1. 调用高德地图API│
│2. 获取坐标数据 │
│3. 返回结果： │
│ 116.397428, │
│ 39.90923 │
└──────────┬──────────┘
 │
 ▼

第 5 步：AI 生成友好回复
┌─────────────────────┐
│用户看到的回复： │
│ │
│"北京天安门的经纬 │
│ 度是： │
│ 经度：116.397428│
│ 纬度：39.90923" │
└─────────────────────┘
</code></pre>
关键点：
<ul>
<li>MCP 客户端负责和 AI 模型通信（这部分用的是 Function Call）</li>
<li>MCP 服务端负责真正执行工具逻辑（调用真实的 API）</li>
<li>中间的数据传输按照 MCP 协议标准进行</li>
</ul>
<blockquote>
💡 Tip：MCP 没有改变 AI 的决策过程，只是规范了"工具列表 → AI 决策 → 工具执行"这个流程的数据格式。
</blockquote>
<hr>
<h3 id="22-mcp-的三个核心概念">2.2 MCP 的三个核心概念</h3>
MCP 定义了三种能力类型，理解它们只需记住：给什么、做什么、怎么做。
<h4 id="-resources资源-给-ai-看的东西">📦 Resources（资源）—— 给 AI "看"的东西</h4>
简单说：只读的数据源，AI 可以读取但不能修改。
常见例子：
<ul>
<li>文件内容（代码、文档、配置）</li>
<li>数据库记录（用户数据、订单信息）</li>
<li>API 响应（第三方服务返回的数据）</li>
</ul>
使用场景："分析一下这个文件有什么问题" → AI 读取文件内容（Resource）→ 分析并给出建议
<hr>
<h4 id="️-tools工具-ai-能做的事情">🛠️ Tools（工具）—— AI 能"做"的事情</h4>
简单说：可执行的函数，AI 调用后会产生实际效果。
常见例子：
<ul>
<li>查询地理坐标、规划路线</li>
<li>发送邮件、创建日历事件</li>
<li>读写数据库、执行系统命令</li>
</ul>
使用场景："帮我查北京的天气" → AI 调用天气查询工具（Tool）→ 返回实时天气数据
<hr>
<h4 id="-prompts提示词模板-标准化的工作流">💬 Prompts（提示词模板）—— 标准化的工作流</h4>
简单说：预定义的对话模板，用户一键触发常见任务。
常见例子：
<ul>
<li>"代码审查"：自动分析性能、安全、可读性</li>
<li>"生成文档"：根据代码自动生成 README</li>
<li>"Bug 诊断"：系统化排查问题</li>
</ul>
使用场景：用户选择"代码审查"模板 → 自动填充代码 → AI 按模板执行审查流程
<hr>
一句话区分：
<table>
<thead>
<tr>
<th>概念</th>
<th>一句话说明</th>
<th>最常见用途</th>
</tr>
</thead>
<tbody>
<tr>
<td>Resources</td>
<td>AI 读取的数据</td>
<td>读取文件、查询数据库</td>
</tr>
<tr>
<td>Tools</td>
<td>AI 执行的操作</td>
<td>调用外部 API（最常用）</td>
</tr>
<tr>
<td>Prompts</td>
<td>用户触发的模板</td>
<td>标准化工作流</td>
</tr>
</tbody>
</table>
<blockquote>
💡 Tip：实际使用中 Tools 占 90%，Resources 适合需要大量上下文的场景，Prompts 用于固定流程。
</blockquote>
<hr>
<h3 id="23-mcp-的传输方式">2.3 MCP 的传输方式</h3>
MCP 支持两种主流传输方式（还有第三种 Streamable HTTP，但较少用），理解它们只需记住：本地还是远程。
<h4 id="方式-1stdio--本地进程通信">方式 1：STDIO —— 本地进程通信</h4>
简单说：Cursor 启动一个本地程序（如 Node.js 脚本），通过标准输入输出通信。
适用场景：
<ul>
<li>本地文件系统操作（读写文件、搜索代码）</li>
<li>本地数据库查询（SQLite、本地 MySQL）</li>
<li>开发和调试自己的 MCP Server</li>
</ul>
优点：快、安全、不需要网络 
缺点：只能本地用，需要安装依赖
典型配置：
<pre><code class="language-json">{
"command": "node",
"args": ["/path/to/mcp-server.js"]
}
</code></pre>
<hr>
<h4 id="方式-2sse--远程-http-服务">方式 2：SSE —— 远程 HTTP 服务</h4>
简单说：Cursor 通过网络访问远程服务器（如高德地图的云端 API）。
适用场景：
<ul>
<li>第三方服务（地图、天气、翻译）</li>
<li>企业内部 API（统一部署的工具）</li>
<li>生产环境（多人共享同一个服务）</li>
</ul>
优点：免安装、可共享、易更新 
缺点：需要网络，有延迟
典型配置：
<pre><code class="language-json">{
"url": "https://mcp.example.com/sse?key=your_key"
}
</code></pre>
<hr>
如何选择？
<table>
<thead>
<tr>
<th>你的需求</th>
<th>推荐方式</th>
<th>典型例子</th>
</tr>
</thead>
<tbody>
<tr>
<td>读写本地文件</td>
<td>STDIO</td>
<td>文件搜索、代码分析</td>
</tr>
<tr>
<td>查询本地数据库</td>
<td>STDIO</td>
<td>SQLite、本地 PostgreSQL</td>
</tr>
<tr>
<td>调用第三方 API</td>
<td>SSE</td>
<td>高德地图、天气服务</td>
</tr>
<tr>
<td>团队共享工具</td>
<td>SSE</td>
<td>企业内部 API、统一认证</td>
</tr>
</tbody>
</table>
<blockquote>
💡 Tip：记住一句话：本地用 STDIO，远程用 SSE。
</blockquote>
<hr>
<h2 id="写在最后看懂本质少踩坑">写在最后：看懂本质，少踩坑</h2>
读到这里，你应该已经明白：
MCP 不是什么黑科技，它就是把 Function Call 包了一层标准化协议。 
MCP 不会让 AI 变聪明，该选错工具还是会选错，该提取错参数还是会提取错。 
MCP 也不是免费午餐，API 调用成本该谁付还是谁付。
那为什么还要了解 MCP？
因为它代表了一个趋势：AI 工具生态的标准化。就像当年的 USB 标准，虽然技术上没什么创新，但统一了接口，让整个生态繁荣起来。
<hr>
<h3 id="给你三个建议">给你三个建议</h3>
1. 不要盲目追新
看到 MCP 火了就觉得必须用，这是最大的误区。如果你的项目：
<ul>
<li>工具就几个，都是自己的 API</li>
<li>一个人开发，不需要团队协作</li>
<li>对工具调用有深度定制需求</li>
</ul>
那自己实现 Function Call 可能更合适，掌控力更强，调试也更方便。
<hr>
2. 也不要一棍子打死
如果你需要快速接入：
<ul>
<li>高德地图、百度地图这类现成服务</li>
<li>团队共享的标准化工具</li>
<li>开源社区提供的 MCP Server</li>
</ul>
那 MCP 能帮你省不少事，不用研究每个 API 的文档，装上就能用。
<hr>
3. 混合策略最务实
核心业务逻辑自己掌控，通用能力用 MCP 快速接入。
比如你做一个智能客服：
<ul>
<li>查订单、查库存 → 自己实现（核心业务）</li>
<li>地图导航、天气查询 → 用 MCP（通用能力）</li>
<li>发邮件、发短信 → 用 MCP（标准化操作）</li>
</ul>
这样既能保证核心竞争力，又能享受生态红利。
<hr>
<h3 id="最后一句话">最后一句话</h3>
MCP 是个好协议，但不要神化它。
技术永远是为业务服务的。理解它的本质，看清它的边界，在合适的场景用好它——这才是工程师该有的态度。
就像你不会因为 USB 出现了，就把所有设备都换成 USB 接口。有些场景该用雷电口还得用雷电口，有些场景干脆直接焊线更可靠。
工具是死的，人是活的。别让工具框住了思维。
<hr>
<h2 id="参考资料">参考资料</h2>
📖 官方文档
<ul>
<li>Anthropic MCP 协议规范</li>
<li>Cursor MCP 文档</li>
</ul> 
来源：https://www.cnblogs.com/xzqcsj/p/19333379

頁: [1]

琼殿技术论坛's Archiver

MCP 爆火背后：是技术革命，还是精心包装的“新瓶旧酒”？