探索MCP的起源、应用和未来，一篇文章让你从小白变专家。
核心内容：
- MCP的诞生背景及其核心理念
- MCP在聚会规划等场景下的实际应用
- MCP面临的挑战与未来发展方向
之前假期我们用MCP做了聚会规划，体验相当不错。后来跟大魔、相柳聊起MCP，聊得热火朝天之后，大魔突然问了句：到底什么是MCP，有什么用？说点小白能听懂的。后来又有几个小伙伴问了类似的问题，还有人上手后挺困惑：这个MCP到底有啥用，这些功能看起来不用MCP也能搞定啊？
所以就写了这篇文章，跟大伙儿聊聊MCP是怎么来的、目前有哪些好用的场景、以及未来会变成什么样。
MCP的起源：从“看不见世界”到“动得了手脚”
要理解MCP的来龙去脉，得回到2022年ChatGPT刚诞生那会儿。
最早期的ChatGPT就是一个单纯聊天的AI，没有如今的联网、画图、画布等花哨功能。但模型训练有语料限制，你会发现它只能回答训练数据里的内容，碰到新信息要么答非所问，要么开始胡编乱造。
于是大家开始想办法：有人开发了各种浏览器插件，把用户的问题先拿去搜索一遍，然后把一堆搜索结果喂给ChatGPT，让它再回答问题——就是“大力扔数据”的模式，只不过靠插件实现。训练加语料约束幻觉、搜索加信息、RAG填充信息，本质上做的都是一件事：让模型看得见世界，了解更多的知识。
但问题又来了：模型有了更多知识，可要让它把一份内容生成Excel表，它依然做不到——因为它不具备调用工具的能力，只能输出纯文本。
于是大家又开始开发各种插件，让模型具备工具调用能力：查天气、查网页、分析数据、画图……总之，要让模型不仅看得见，还能动得了手脚。
到了2023年6月，ChatGPT发布了一个模型调用工具的协议——Function Call，第一个基准出现了。简单说就是“让模型以结构化方式使用你的API”的协议层。举个例子，搜索的Function Call长这样：
{
"name": "search_web",
"arguments": {
"query": "MCP 是什么"
}
}虽然各家大模型都陆续支持Function Call，但在落地过程中暴露出几个明显的问题：厂商之间机制不统一，接入成本高；工具也缺乏统一的调用基准，每家接口五花八门，基本是定制开发，没什么复用性。
连模型调用的Token统计各家都不一致，有的全给数据，有的需要二次开发，有的干脆没有得自己算，还得兼容虚拟缓存……算个Token消耗简直累死人。
MCP的出现：一个标准化的“商场”
2024年，随着Claude 3.5 Sonnet的出现，AI编程迈上新台阶，Cursor这类工具走进大众视野。当普通人能借助AI写程序时，行业对模型与外部交互的诉求也到了临界点——无非是谁先推出这个基准。
于是2024年11月，Claude团队带来了第二个基准：MCP（Model Context Protocol）。
打个比方：世界是一个大商场。在只有Function Call的商场里，每家店都自己装修、货架标签自己命名、自由摆放。模型进去发现每家店都不一样，想找瓶可乐都得先研究一下这家店的布局，效率极低。
而MCP是一个标准化商场，所有商铺的布局结构统一，货架、标签都是统一规范。模型只要理解一套基准，就能从商场里拿走它想要的所有东西。MCP没有取代Function Call，它只是把商家布局标准化了，让模型做Function Call更方便。
入驻的商家越多，模型能触达的世界就越大。自11月推出以来，各公司和开发者纷纷跟进，到4月份已经能看到百花齐放的MCP市场——阿里云的百炼和idoubi的mcp.so都是不错的平台。
目前调用MCP还不能在模型内部直接完成，一般通过AI编程软件Windsurf或Cursor来实现。Windsurf对小白更友好，只需要填入JSON就能高效使用，不用调试太多东西。
（阿里云的百炼智能体也支持MCP服务，但在调试中看不到具体模块，可以用来尝试，体验稍逊于Windsurf。）
MCP的实际应用：几个生动的案例
那现在MCP到底能做什么？来看看实际效果。
1. 查看北京未来天气并做成网站
本来想让AI画一个7天的网页，但高德地图MCP服务返回了4天数据，所以天气预报就这么呈现了。用户只需说一句话：把北京未来几天天气预报做成网页。Claude自动激活高德MCP服务，获取数据后直接生成HTML网页。
整个环节只靠一句话，剩下的全部由模型自己搞定。
2. 规划从北京西站到环球影城的出游路线
接着天气预报，用户告诉Claude：明天到北京西站，要去环球影城，规划条路线出来。同样是一句话，模型自动规划，调用MCP，最终生成一个网站。
这个过程中，模型主要调用了两个MCP服务：一个查询地理位置坐标（先把北京西站转成坐标），另一个制定具体路线规划。
3. 把网页发布上线
计划做好了，再把它发布到线上看看效果。通过腾讯云Pages MCP服务，直接得到一个可访问的链接：https://beijing-universal-route.windsurf.build/。电脑和手机都能正常访问。
目前Pages MCP主要支持将HTML快速转化为访问链接，复杂项目暂时还不支持。
4. AI控制电脑去搜索
通过browserMCP，可以让AI控制浏览器。试试让它把即刻近期的AI热门内容搜索总结并做成网站：
它会自己去逛网站、理解内容。但需要注意的是，要让AI通过browserMCP给出高质量结果，通常需要多次逻辑调优——毕竟browserMCP的核心是提供浏览页面能力，但如何让结果更好，取决于用户与AI的多次沟通。
MCP的价值：简化流程，拒绝造轮子
这些案例如果没有MCP能不能做？能做。每个功能单独写一套接口逻辑，跑脚本调用，用一次估计先开发1-2小时。而且想给别人用还得装环境、同步脚本，想想就痛苦。有了MCP，所有人都能一键快捷接入，不用重复造轮子了。
MCP并没有实现之前实现不了的功能，它只是大大简化了达到效果所需的步骤和时间。
小白如何快速上手MCP
最省事的办法就是让AI自己来搞定。打开你要安装的MCP服务的网站，把网址复制到Windsurf对话框，告诉它“我要接入MCP”，让它自己处理。如果需要你获取Key，按它给的路径找一下就行。这样超级省事。
当MCP新添加的图标变成绿色圆点，就代表添加成功，可以开始使用了。
MCP的未来：一种必然的进化
说到未来，先讲一个关于Cursor AI编程的故事。
从去年8月开始用Cursor编程，当时有两个模式：ChatAI（跟AI聊天要代码，人操作为主）和Composer（AI直接去文件里写代码，全自动）。深度用过一段时间后，Composer写了一大堆bug，让人崩溃，只好回到ChatAI模式，以人为主导。
但Cursor一直在进化：模型不能用终端，他们加了终端环境；上下文能力不够，升级了codebase；模型只会蛮干，追加了Agent模式，让模型具备更强的规划和执行能力。最终Agent模式扫平了ChatAI和Composer。当时坚持了许久ChatAI，后来不得不感慨Agent模式真香——只需要描述清楚需求，AI就能专注写代码，还能随时纠错。
这一切只花了6个月时间。现在很难想象6个月后的AI编程会是什么样子，但肯定比现在强上很多倍。
MCP的未来是什么？不知道。但可以肯定的是：今天MCP好不好用都不重要，它是模型进化中不可或缺的一环，它一定会变得更好用。先用起来，一点点解决它的问题，才是对待MCP最好的态度。
实践永远是最好的老师。
最后用一句话总结MCP：看得见世界，动得了手脚——让模型能够更好地了解现实，变得更智能。