你听说过MCP（Model Context Protocol，模型上下文协议）吗？这是我的经历：
-
发现全网都在讨论MCP； -
搜索教程，被“服务器”、“客户端”等术语淹没； -
似懂非懂地关闭页面。
如果你不关心技术细节，而想了解AI产品发展的现状和方向，欢迎看这篇，了解为什么会有MCP这个东西。我希望做到：
-
尽量避开或充分解释专业名词； -
不打蹩脚的比方——拿厨房或Type-C来比喻对理解它没帮助； -
探讨新概念的本质和发展前景。
MCP的背景
语言模型的缺陷
你很喜欢和AI聊天。有一天，你问DeepSeek：
Strawberry这个单词里有几个字母“r”？
不要小看这个问题，在不久前，大部分语言模型还不能正确回答。如果技术一时无法突破，难道就放任问题存在下去吗？也不尽然。要知道，这种问题用一行代码就可以计算。如果AI可以自己写代码跑一下，不就数出来了？
可见，允许AI调用外部工具（比如运行代码），是现阶段增强模型能力的办法之一。
除了工具（Tools）外，另一种可以武装AI的“外挂”是资源（Resources）。
-
实时资源。你问AI中美关税到底改成多少了，它必须去阅读新闻和文件； -
个性化资源。你开会打瞌睡，但如果办公软件带AI，就可以帮你总结会议记录。
这需要RAG（Retrieval Augmented Generation，检索增强生成）。最常见的RAG当然是联网搜索。
回到本节开头：“你很喜欢和AI聊天。”——AI只能聊天吗？
如果你是一名程序员，通过让AI读取你目录下的代码，省得你复制粘贴到聊天框，那能不能进一步让AI帮你把代码写到编辑器里，甚至运行下试试？
这不仅需要模型能读取，还要它能“操作”。好了，其实我们不小心已经介绍了另一个重要概念：Agent，代理，顾名思义，即不仅可以聊天，还有权限代替你做事。所以它在中文语境下还有个酷炫的名字：智能体。
最常见的智能体是AI编程工具，比如GitHub Copilot和Cursor。你可以仅仅通过聊天，就让AI帮你撰写、运行代码。
可见，智能体不再仅仅纸上谈兵，还可以真正行动起来。当然，行动的范围是虚拟世界，它不能帮你拿锅砸男朋友的头。
总结下：现在基于语言模型的AI还是“笼中鸟”，本质是个一经推出就被封锁在自己世界里的对话程序。它不会再学习新知识，也不会做对话以外的事情。于是我们通过：
-
链接外部资源来拓宽它的视野（RAG）； -
赋予它操作权限来实现主动性（Agent）。
每个语言模型都是代码写手
说这么半天，语言模型毕竟只会聊天啊？就凭输出一段话的能力，它是如何操作你的电脑的？
这个问题也困扰过我，后来想了一个通俗的理解：这一切只靠给AI新增了一个角色——程序员，而且是只负责写，不负责运行的纯写手。
我们可以用一个实际的例子来解释这段话的意思。
有一个天气预报智能体，可以通过对话查天气。我问它：“明儿个北京什么天气？”它回答：“北京明天晴，15-30度。”这背后发生了什么？
-
我将问题输入智能体（注意，还没有输入语言模型本身）； -
智能体为我的问题附上一句话：“这有个写好的程序，运行它可以返回气象局的天气预报”； -
我的问题和这句额外的信息一起被输入语言模型； -
模型理解了我的意图，同时知道了有一个程序可以得到天气预报； -
模型返回一段请求代码，表示它需要调用该程序，并附上参数 {时间：20250530，地点：北京}； -
智能体按该参数配置运行该程序，得到结果 {天气: 晴, 最低温: 15, 最高温: 30}； -
这个结果连同之前的问题再次被发送给模型； -
模型拿着问题和答案进行润色，返回：“北京明天晴，15-30度。” -
智能体将这句话发给我。
该过程中，语言模型被运行了两次：
-
把用户用自然语言写的问题转换成了运行程序的请求； -
在程序运行完后，将其输出结果转换回自然语言。
这就是MCP的前身：Function Calling。多次运行语言模型，模型不仅和用户对话，还让智能体帮它调用程序。
第一次搞清楚这些，我的想法是：就这？那我们要把上文“赋予AI操作权限”的说法改一改：智能体其实是个软件。软件有权限，让内置程序按模型指示运行。此时，用户面对的是语言模型，还是包含自然语言处理功能的新形态软件，就不好定义了。关于这一点的讨论，我们放到下文，先来讲讲MCP。
MCP的价值
现在，我们假设这样一个场景：
-
你是一家天气预报服务商，预报准确率拳打ECMWF，脚踢微软天气（植入广告）； -
用户明明打开手机点几下就可以看到天气预报，但偏偏喜欢通过问AI获取信息。
你该如何让那些用AI问天气的人，获取的是你提供的预报？有两个基本的解决方案：
-
约谈各大AI厂商，展示你无与伦比的预报效果，让他们在自己的产品里内置你的预报服务； -
做个内置AI的天气预报软件。你自己没有AI模型，但可以购买AI厂商的服务。
前者不太现实，而后者的问题在于：
-
用户只能从你的软件才能获取你的天气预报，但用户习惯打开ChatGPT而不是你的软件； -
你需要为AI厂商的服务付费； -
AI调用请求的格式在不同厂商甚至不同版本间可能不同，你需要经常修改代码； -
你的产品是个孤岛，很难融入“泛天气”的服务。比如用户想根据天气安排行程，还需要日历、地图等function calling。
怎么解决这些问题？我们往回退一步，想想上一次“科技浪潮”——移动互联网发生了什么。
15年前，你已经是天气预报服务商，你希望用户在手机上看到的是你的天气预报：
-
如果用户手持功能机，你需要上门找诺基亚或者摩托罗拉，请他们在产品中集成你的服务； -
如果用户手持智能机，你只需要开发App，让喜欢你的用户安装即可。
第二点的关键是什么？平台。AI浪潮下，类似的美好愿景是：我们能否把AI做成像iOS或Android一样的平台，而把“function calling”当成这个平台上的App？如此，问题都得以解决：
-
用户和AI对话时，自己选择AI的信息来源，比如你的天气预报服务； -
你只需要优化天气预报，不需要为AI服务付费，或操心你的预报如何与AI对接； -
AI端负责融合天气、日历、地图等“App”，提供“泛天气”服务。
MCP的原理
要达成前文所述的愿景，核心之一是“车同轨，书同文”的标准化。比如：
-
App如何告诉软件自己有哪些功能，需要哪些参数？ -
如何确保软件发出的请求能成功调用App？
标准化，就是协议的目的。MCP，即Model Context Protocol，模型上下文协议，顾名思义，就是规范了如何将这些App作为context来增强模型能力。
这样做的好处显而易见——你确实不用写好几份代码了。
还不对……到此为止，MCP和function calling的唯一区别是，function calling是各家AI厂商自己实现的，MCP是想一统天下的。但前文所述的问题没有解决——你还是要把所有代码写到一起做成“孤岛”。如何从技术上真正解耦，分离AI平台要做的事和“App”所要做的事，让任意一个AI可以调用你的预报？
终于，我们可以来说说MCP的核心概念了——因为我们其实早就已经提到了它们：
-
MCP中的Server（服务器），负责提供资源和工具； -
MCP中的Client（客户端），负责给模型接发消息和执行模型的调用请求。
仔细想想，其实这两个要素在前文function calling的部分也有，为什么有了MCP，我们就可以将它们解耦了？因为协议！
-
你是天气预报Server，如果接到的请求都是统一格式，那何必管是谁发的？ -
你是AI模型，如果你的请求有Client负责解释，何必管最终落实到谁头上？
这么一来，当然可以各写各的代码，由用户来组装它们。由此可见，“服务器”和“客户端”这两个词还挺形象：服务器提供标准化的服务；客户端代表客户采购服务。这显然也符合计算机领域对这两个概念的理解。
实际运行时：
-
用户配置好服务器，将问题发送给客户端； -
客户端将问题和服务器内的工具和资源信息发送给AI； -
AI回答客户端它需要哪些工具和资源； -
客户端通过服务器调用这些工具和资源，将结果发送给AI； -
AI润色后经由客户端返回给用户。
此时，作为天气预报服务商的你，只需要写好MCP服务器代码，然后打广告让用户在AI客户端上装你的MCP服务器，正如现在打广告让用户在手机上装你的App一样。
总之，客户端这个“中间商”被独立出来，是从function calling到MCP的关键转变。它在AI和服务器间传话，一个“平台”就形成了。现在，我们可以理解这张图了：
这里又引入了一个概念叫“Host”（主机），可以理解为附带Client的软件，比如VS Code代码编辑器是个Host，它可以建立遵循MCP的Client。我们理解MCP并不需要严格区分Host和Client。
MCP的实现
MCP是由推出AI公司Anthropic在去年发布的。既然希望一统天下，当然首先得做些工作。Anthropic实现了一套帮助你开发MCP Client和Server的工具。我们可以简单过目下他们在官网给出的Server代码示例。
@mcp.tool()
async def get_alerts(state: str) -> str:
"""Get weather alerts for a US state.
Args:
state: Two-letter US state code (e.g. CA, NY)
"""
# 一段可以从气象局读取预警信息的代码
这个函数就是待调用的工具。输入美国州名，可以返回气象局在该州发布的天气预警。要关注的是@mcp.tool()这样一个“装饰器”。它至少可以实现以下两个作用：
-
告诉MCP框架，这个Server中包含一个叫 get_alerts的工具； -
自动解析函数名、参数列表和docstring（三引号中的“文档”）。
因此，通过一个简单的装饰器，Model Context就自动生成了，你唯一需要做的是实现核心功能。
关于MCP的实际效果，在近期微软召开的Microsoft Build 2025中有个示例，可以观看这个链接：https://www.bilibili.com/video/BV1KjJFz3EL4?t=3955.3。具体而言：
-
Windows支持MCP，可以启动MCP Client，形成上文中的“Host with MCP Client”。 -
注册了两个servers：WSL（在Windows中运行Linux的工具）和Figma（界面设计工具）。 -
在代码编辑器中，通过和AI聊天创建了一个网页： -
通过WSL server安装了一个Linux环境； -
让AI在Linux里写了一个简单的网页； -
通过Figma server读到了Figma中绘制的界面，再由AI转成代码。
可见MCP这个概念为Windows这样志在实现操作系统层面的“智能化”的系统提供了极大便利。
MCP的局限
MCP并不是技术突破
首先给出两个“暴论”（但却是显而易见的）：
-
MCP相比function calling并没有突破，纯技术角度，任何MCP能做到的事，之前都能做到； -
MCP甚至也没有脱离提示工程（prompt engineering）的范畴，其“让AI写代码”的本质没有改变。
对于第一点，MCP是一种规范而不是技术。用一个流行的说法，它只是将M×N优化为M+N，即，只需要分别实现M个AI和N个服务并自由组合，而不是为M×N个AI和服务的组合各写一套代码。
至于第二点，所谓提示工程，就是用高质量的文本输入让AI输出理想的信息。让我们看看Anthropic在GitHub上提供的一段Client示例中的“魔法”：
system_message = (
"You are a helpful assistant with access to these tools:nn"
f"{tools_description}n"
"Choose the appropriate tool based on the user's question. "
"If no tool is needed, reply directly.nn"
"IMPORTANT: When you need to use a tool, you must ONLY respond with "
"the exact JSON object format below, nothing else:n"
"{n"
' "tool": "tool-name",n'
' "arguments": {n'
' "argument-name": "value"n'
" }n"
"}nn"
"After receiving a tool's response:n"
"1. Transform the raw data into a natural, conversational responsen"
"2. Keep responses concise but informativen"
"3. Focus on the most relevant informationn"
"4. Use appropriate context from the user's questionn"
"5. Avoid simply repeating the raw datann"
"Please use only the tools that are explicitly defined above."
)
从这段发给AI的提示语中，我们清晰地看到本质：Client把工具说明合并成文本告诉AI，并要求AI输出规定的结构化文本（JSON），从而用写好的代码解析以正确调用程序。显然，这种实现方式假定了一个前提：AI始终一丝不苟地执行我们输入的指令。尽管目前写代码是生成式AI为数不多相对靠谱的能力之一，但传统软件尚且有铺天盖地的bug，在流程中引入AI，其不稳定性必然又上一个量级。
更何况，当我们只有有限的工具时，一切很美好，但如果有千百个工具，且要迭代很多次呢？别忘了，这些工具的说明都是“Model Context”，而AI一次性能高效阅读的内容也是有限的。这也催生了业界一些思考，比如将工具像文件夹一样分层级归类等。
说到这里，不禁想引出一个问题：MCP是用来规范AI和计算机、互联网工具沟通的，它们都是“硅基生命”，为什么要用人类的语言沟通？
MCP的底层逻辑是AI中心论
无论如何，MCP在AI”信徒“眼中是当前的最佳解决方案，拥有合理的故事线。但我们跳出这条线的“误导”，再想想呢？
你还是那个天气预报服务商，MCP可以将你的服务接入各家AI模型……等等，你为什么要这么做？用户都去ChatGPT、Claude里搜天气预报，那你软件里的广告给谁看？诸如The Weather Channel或国内墨迹、彩云，收入主要来自广告和订阅服务。这些收入的背后是流量，如果这些流量都被AI“吃”掉，后果可想而知。
显然，MCP是以AI为中心，一切地目的是为构筑更强大的AI。GitHub愿意做MCP服务，因为它本质上只是替你完成Git操作，所有代码还是出现在GitHub上；但Google或Bing却不一定有多大的动力：你希望用户打开你的网站，再不小心点进推广链接，还是用ChatGPT调用你的搜索引擎，过滤、总结一番？
其实国内搜索引擎在国内已经式微，封闭生态大行其道，不同用户选择去抖音、微信公众号、小红书搜索内容。同样的道理，未来的AI应用，到底是以AI为核心和入口，以一切资源为背景板，还是每项独立的产品试着在自己功能里融入AI？是谁来拥抱谁？我想，大部分讲究流量和入口的服务暂时恐怕还会选择后者。
所以，尽管MCP看似是为第三方开发者节省工作量，实际上是个把压力转移给第三方的“阳谋”，把要不要开放MCP服务为AI生态做贡献的大问题摆到了每个产品面前。AI领域如此火爆，当一个概念推出，所有人一拥而上，此时这个概念本身合不合理已经不重要了，重要的是不能落后。就像外卖、打车等刚上线时疯狂的补贴一样，现在拥抱AI的成本降低了，你要不要？
从MCP到Agent
有趣的是，我们上文将MCP Server比作AI生态下的App，而见微知著的程序员已经建立了不少和App Store类似的MCP Store了。如我们所料，里面多是些文档、数据库、云存储的服务率。这说明MCP起步是为每天写代码、分析数据、设计图纸的“牛马”作贡献，还谈不上新的商业模式或产品形态。
之所以如此，除了上一节所述外，另一个原因是，AI现在仍只在做简单重复性工作时才比较稳定。
说到这，我们其实已经不是在讨论MCP，而是AI和Agent。所谓Agent，可以从两个角度理解：
-
以AI为中心的视角下，Agent是拥有外挂的AI，通过调用外部工具和资源扩充知识，采取行动。 -
传统视角下，Agent是以自然语言为粘合剂的软件。如果我们把外部工具和资源本身看成主体，那么Agent只是利用语言模型为“界面”的新型服务。
选择哪个视角，取决于软件功能和语言模型的贡献孰轻孰重。比如：
-
如果是天气预报，那么模型只是充当传声筒，核心仍然是天气数据和预报方法； -
如果是代码生成，那么模型的编程能力是核心，直接在编辑器里自动操作的功能只是附加价值（所以我们看到人工智能厂商OpenAI收购了代码编辑器厂商Windsurf，而不是反之）。
由于AI能力有限，反倒是前者可能更容易普及（所以天气预报是所有科普MCP的人最喜欢的例子……）。
不过，如果有一天，AI的能力进一步提升，比如：
-
多模态能力增强，可以深入天气数据做天气学分析，那充当预报员角色的Agent指日可待； -
甚至，可以自主梳理数据、研发优化预报模式，那全员Agent的气象台就可以运转了。
即时到这一步，考虑到目前智能体还囿于虚拟世界，它还需要人类的辅助：
相关文章
