AI大模型的MCP协议，连接智能体的桥梁还是障碍？

核心内容：
1. MCP协议对AI大模型的作用及价值
2. MCP协议的局限：本地运行与传输方式的制约
3. MCP协议的挑战：用户鉴权、网络性能及安全性难题

近期，朋友圈中关于MCP协议的文章层出不穷，这里不再赘述细节。

简要概括，如何一句话阐明MCP协议对AI智能体与大模型的价值？打个比方：一个原本只能空谈的AI，瞬间拥有了上千个能切实执行任务的助手，而MCP协议正是招募这些助手的桥梁。

例如，让DeepSeek创作古诗轻而易举，但让它点一份外卖却不可行——美团并未提供AI直接调用的接口。而MCP协议则在AI大模型与美团之间搭建了通信桥梁，从而使得DeepSeek能够帮你完成外卖下单并送到家。

（官方以计算机USB接口作为MCP协议的比喻，十分贴切）

接触MCP协议一段时间后，起初觉得前景广阔。然而实际使用时，发现一个致命缺陷——它仅能在本地计算机上运行。

目前MCP仅支持stdio和SSE两种传输方式。这意味着用户要么将代码下载至本地，要么在本地运行服务并暴露一个SSE接口。常见的REST API方式完全不被支持，官方也未提供托管地址。尽管从开源社区的角度来看，这种设计蕴含长远考量，但对于广大普通用户而言，MCP协议与MCP服务几乎等同于一堆无法直接运行的代码。

例如，当你想使用MCP协议，打开Cursor准备添加MCP Server时，只会看到两种选项。

（Cursor添加MCP服务提供SSE与Command两种方式，你清楚它们的含义吗？）

这往往会让人困惑——是否需要填写网址？然而四处寻找却找不到填写位置。难道还要去运行MCP server代码？什么是Git？什么是命令行？什么是npm？什么是Node.js？（此处省略一系列疑问）

对于新手开发者而言，让普通人执行一条简单的bash命令已是难事，更别提在一小时内启动并运行一个Node.js服务了。尽管启动Node.js服务本身不算特别复杂，但若要求他们进行生产部署，配置托管的Kubernetes集群，并学习Docker容器部署——这成本高得惊人，难度也成倍增加。

须知，在当今云时代，真正难住大多数人的往往不是软件本身，而是软件的运维工具。这好比做菜——人人都知烹饪有趣，甚至堪称艺术，但大部分人却懒得洗菜切菜，嫌这些前置准备工作过于繁琐。

MCP协议的设计初衷其实相当不错。在软件时代，各类软件之间的连接与对接曾让无数程序员和产品经理头疼不已。数据若不打通，便会衍生出一系列繁琐的解决方案，对接过程更是令人困扰，这一问题不容小觑。

除了传输网络方案外，MCP协议还存在其他问题，例如用户鉴权、网络性能以及安全性等。但其生态系统与相关工具发展迅速，这才是关键所在——生态繁荣才能真正发挥价值。

后续值得持续关注MCP的替代方案。尽管挑战重重，但有问题就意味着有机遇。毕竟，大模型如同大脑，智能体好比脑干，要真正完成一项任务，还需要无数种类繁多的手脚与工具协同配合。