MCP全称Model Context Protocol，模型上下文协议，是由Anthropic公司（Claude母公司）在2024年月提出的一套开放协议，它为LLM提供了一套标准化协议，旨在为LLM方便调用各类数据源和工具。
有了MCP，已经有人做出了将Claude与Blender结合。直接一句话3D建模;也可以将figma原型稿与LLM结合，直接原型变前端代码。
Anthropic的愿景很大，希望把MCP协议打造成AI世界的“Type-C”接口，可以啥工具、数据源都接进来。希望能够通用到类似HTTP协议的那种程度。
就在3月27日，连OpenAI都宣布正式支持MCP了。
而Function Calling呢，则最初是由OpenAI在2023年6月作为其API的一部分提出的，就是一种函数调用机制，允许LLM通在生成内容的过程中调用外部函数或服务，从而获取更多能力。现在，很多其他大模型也借鉴了这种概念，纷纷推出了自己的function calling 。借助这个功能，可以调用外网检索引擎、天气查询、图片生成服务、音乐生成服务调用等。
所以，你会发现，OpenAI只是首先提出了function call概念，至于怎么实现的，还是要各家自己来做。而MCP直接开放了协议，希望把这种各自为政的function call统一到一起，成为一个标准。
我们来举个例子，function call好比家里的电器遥控器，每个遥控器都得单独编接口才能控制相应电器。比如想让AI查询天气，就得跟第三方天气应用对接API接口，完成了之后，这东东也不能用来查其他的，就是特定用途。这就好比你对接了一款遥控器之后，想要控制灯光，还得再搞个电灯遥控器一样。
而MCP的野心，就是想做一套全屋智能中枢，通过统一协议接入所有家电，只需要家电采用相同的协议接入即可，这样，用户要睡觉，那就要首先控制窗帘关闭，接着关灯，把空调调到睡眠模式，而这一切，只需要一个“MCP”万能遥控器搞定，再也不用一个个找遥控器了！
而AI Agent又是什么呢？中文翻译过来是“人工智能代理”，即通过LLM为大脑，响应需求，进行意图理解，规划拆解任务，调用工具，执行动作并生成内容。
AI Agent可以把Function call理解为其实现目标的“动作单元”，就是那个可以调用的工具。
比如，你想睡觉了，那就只要设计一个AI Agent，说一句话：“现在我要睡觉了”。 LLM就开始进行意图识别，自己拆解任务，用户要睡觉，意味着要干三件事，关窗帘、关灯、空调调到睡眠模式。然后调用这三个电器的Function call，执行任务。
AI Agent就像你的管家机器人一样，你布置任务，它代你执行，就像你的代理人一样。所以你现在理解了这里面的“Agent”含义了吧。
而MCP的出现呢，相当于进一步简化了调用工具这个逻辑，AI Agent在设计的时候，也可以把调用Function call改为用MCP协议进行统一互联，实现跨系统协作，比如连接智能家居（灯光/音响）、本地文件（菜谱）、物联网设备（扫地机器人）等，形成协同效应。
当然，MCP也可以将多个Function Calling任务（如调用不同API）封装为标准化请求，减少重复开发成本。
MCP并非Function Calling的替代品，而是通过标准化协议解决了碎片化集成的问题，同时为Function Calling提供了更广阔的协作空间。两者的关系类似于“高速公路与汽车”——MCP是连接万物的基础设施，Function Calling则是灵活高效的交通工具，二者结合才能实现AI应用的规模化落地。
对于MCP来说，更牛的是，根据 Anthropic 前段时间在 AI 工程师大会上的演讲，他们似乎正在开发一套 MCP 服务器注册表和发现协议。
若MCP 真的实现了这个功能，能自主发现工具，API 提供商需确保其工具易于被发现，并具备差异化特性，使智能体能为特定任务选择它们，可见未来如何让MCP优先发现成了API提供商们优先要去竞争的点。
那么，我们可以预见，MCP 有可能打造出一个新的AI 智能体生态系统，这是一盘很大的棋。
试着想象一下，只要根据自然语言描述，进行意图识别，AI 智能体自己可以决定使用哪些工具、以什么顺序使用，以及如何将它们串联起来以完成任务。那么现在类似Coze、Dify这样的AI Agent智能体编排工具真成了一个伪命题，因为就不存在什么编排了，一句话就能搞定的事情。
这场AI Agent的革命也在悄然拉开序幕，我们拭目以待看着好戏发生。
