探讨模型上下文协议MCP的应用与未来

今天来聊一聊MCP，也就是模型上下文协议。这是Cloud公司推出了一个协议，让大语言模型能够去用工具，知道工具有哪些能力，从而可以借助这些能力在试弹的时候去执行它。就像人类有了工具，它才能够去生火，才能够去打猎。好，那么说到这一点的话，我们先看看在没有这个MCP之前。

那些场景里面会用到工具，也就是让AI使用工具呢？从那开始其实在ChatGPT的GPT-S里面就有一个类似于Action的能力扩展，它其实是通过OpenAPI的规范来让大语言模型知道我所提供的API会有哪些能力。比方说最近这个Notion的AI，笔记软件它推出了MCP，就是让用户可以把笔记保存到Notion的某个数据库，或者是直接把数据库里面某篇文章进行总结之后再存进去。从使用场景上来说的话，所有的软件你都可以理解成它不需要一个专门的操作界面了。我们都可以在Chatbot，也就是跟大语言模型的那个对话框里面把所有事情干完了。这个的话留到我们后面去讲它的优缺点好了。但是目前我先讲MCP它到底承担了什么职责。那比方说这里的第一个职责就是，或者说它最大的亮点是它可以包含API，再去做很多本地化的事情。

你比方说最典型的一个例子，除了把这个笔记保存到Notion，你怎么样保存到Apple Notes呢？其实苹果标录已经是很多很多人在折腾各种笔记软件之后依然选择回归了Apple Notes，但是你想它是苹果的一个本地软件，它虽然有云服务，但是并没有对外暴露任何的API。那么在本地你该如何让AI去操作你的本地软件去做一些事情，那么答案其实就是你可以起一个MCP的服务，在你的本地去通过AppleScript，也就是苹果的那个脚本工具去操作任何的本地软件。

所以随之而来的现在是Keynote AMCP，我去搜了一下也是有的。本来我之前有一个想法是通过AI去操控你的PPT，就不是在网上去通过web技术去生成PPT，因为那样的话其实它有大量的兼容性问题需要处理，它的流畅性和美观度都是非常非常差的。但是如果我们直接就在Keynote里面通过类似于脚本的方式或者图形化操作的方式去让Keynote直接生成在Keynote里面的PPT的话，那么后续的编辑和使用都是符合已有的用户习惯的。

也就是说我们先从0到1产出一个初始版本嘛，然后后续的优化的话，你可以继续自己做，也可以让AI继续修改。但是我自己的一个使用体验，大多数情况下都是从0到1 AI很擅长，但是从1到2或者到100，其实里面有大量的细节需要调整。这个时候人为去介入反而是更快的，因为你拥有比他更多的上下文和对业务的理解。那么有了MCP的本地化操作能力之后，你可以发现大语言模型它就不局限于通过所谓的API进行数据交换了，它更多的甚至能够操作你本地的。

我看到一个非常有趣的MCP的server，它是，我就感觉有点行为艺术啊，它是通过Cloud的code端，然后通过MCP协议去操作ChatGPT，所以你就能够做到说，在Cloud里面去读取ChatGPT的历史记录，比方说让Cloud去总结一下，GPT帮我最近做了什么事啊？他有哪些地方做的不好呀？你会发现这非常像是一个公司场景，你有了很多很多的AI助理，然后AI助理之间竟然还有层级等级之间的关系，那哪个AI的能力越强，哪个模型更能擅长做执行，或者说他更擅长做架构，你就把它作为这个AI团队的上层领导，让这个领导去指挥其他的AI模型去做事情。

好，这个扯远了。我们谈到MCP，它其实就是会有client端和server端。server端的话现在像是百度高德等等，推出了地图服务等等。其实本身他们都是一层API的套壳。我觉得这种套壳其实价值意义并不大吧。它是一个模型的上下文协议，它是个协议本身。

它就必然会有客户端和服务端，而服务端之前的API只能作为一个子集，这个子集其实说白了现在所有的JSON API它都可以一键变成MCP的服务。这个MCP的服务呢，甚至不需要你写代码，我发现很多发现了好几个吧，就是这种MCP的server的wrapper，它就是把JSON API进行了一个自动化的包装，因为这里面有两个比较重要的概念或者说三个吧。第一个就是这个API要有字段的描述，就比方说你去记笔记，你需要记的是标题还是描述还是这个页面的信息，那你要告诉大语言模型让他知道。这个就跟人与人开发的时候需要知道API的那个类型。有了这些类型规范之后，那么我们才有了约束嘛，总不能说，你说这里有一个title的字段，但其实你的名称叫for title，这也是传统的JSON API的一个缺陷所在了，也是之前为什么会有GraphQL这种强类型的API规范或者传输手段。

那么第二个则是每一个function core，就是大语言模型它其实还是通过to use，也就是function core去执行MCP的能力。那么在你的JSON API里面，它其实每一个endpoint，每一个API的路径，它都必须去生成一个对应的function call的名称吧。这个名称的话就需要你去手动写，但其实本身API规范就已经包含了这个每一个端口的名称。如果你的端点的名称写的足够语意化，那其实AI就已经能够理解了。

在第三个的话则是API的授权，那么一个API端点，它可能是针对于不同的角色来进行更细刻力度的能力的限制嘛，所以MCP也包括了授权相关的一些概念，能够让你轻松的去管理它。

怎么说呢，这三点的话都是JSON API或者是OpenAPI规范都已经做到了的。那所以像类似于这种Swaga这种文档工具就能直接一键变成MCP的server的所谓规范。它终究只是一套协议而已。

那么除了本地化操作和这种JSON API的Wrapper之外，Talk以外，我还去看了很多所谓的MCP Server，那真的是忍不住吐槽，实在是太垃圾了，因为这宛如早期的NPM。所以程序员们，我觉得现在有一个很大的创造影响力的机会，就是直接去写一个Node，Go，Rust，Python各种语言的package的一个Wrapper。

把这些package加成一个我刚刚提到的，除了有词名字，然后每个能力的这些输入输出的字段或者授权信息，它就变成了一个MCP server。比方说你可以写一个mmfpeg的server，它就是可以帮你剪辑视频，提取音频啊等等。这个如果其他人不做的话，我自己都会做了，因为在BibiGPT里面会需要这样的视频操作能力。

好，那么这里诡异的或者说tricky的是，像这些官方非常好用的标准化的或者流行的NPM8或者各语言的库，在大语言模型的预训练数据里面其实早就有了。那为什么还需要李承轩重新写一遍呢？然后第二个问题是，写完这些MCP的Server其实还需要一个Runtime。这个Runtime要么就是在用户的本地端，要么就是一个云端的API服务嘛。MCP一旦变成云端了，它其实又变成就是一个API而已。

所以我觉得最开始Cloud应该本意只是在数据安全和自主可控性这个前提下，让大语言模型能够理解用户所在的环境上下文。那么这个运行时呢，如果让普通用户去安装像Node.js的运行环境或者Rust.go这样的环境，那其实还是非常有门槛的。好在你像macOS还自带Python环境，如果你想写一个好用的MCP server，那其实用Python会是最好的。如果是服务端册的话，我发现像Cloudflurry它又一次引马了呀，因为你看它现在已有的像walker的生态，它摇身一变都可以变成MCP server来服务用户了，而且它官方也有agents的sdk帮你能够快速开发，所以框架有了呀，运行室环境也有了，但本质上都是直接使用了Cloud官方所提供的一个MCP的SDK。所有的这些框架都是它这一层封装而已。所以技术上就可以先去虚昧了。

那最后呢，不管你是写MCP的Server还是写一个JSON API，它都是回归到你如何去设计一个好的接口。它这个Library输入和输出分别是什么。

目前最大的变革就是你管它的使用对象从人变成了AI。那不管是AI来用这个接口还是人来用这个接口，那它好不好用，它的职责是否清晰，它的描述是否合理，对吧？那其实都是回归到如何去更好的做接口设计了。

那最终你是要服务为用户的需求的，解决用户的问题的。最后我想到一个punchline，就是既然MCP面向的对象是AI，那其实无论这个借口实现有多么垃圾，AI都能理解的。而既然AI都能理解，为什么不让AI自己去写一个更好的MCP server呢？

所以感性一点的认识就是AI学会了使用工具到现在人来提供工具，但更好的方式或者未来是AI自己亲自去写工具，而且他写出来的工具比我们人去写的还要更好用。好，那么今天分享就到这了。

也是自己昨天对于MCP的一些调研和吐槽吧。我觉得这个东西它确实是一种技术的hyper，因为它有点过度宣传，有点让大家觉得有了这个东西就牛逼的不行了。那么我们先去去妹，然后再想具体我真的能够使用到哪些场景。

这里面最大的变革其实就是未来你会直接在Chatbot里面去使用和调用所有的外部服务或者你的本地服务嘛。这个变革怎么说呢，我自认为是比较大，但是又没有那么大，因为对于普通用户来说，在Chatbot里面去聊天室的，比如说记账记笔记打车，它听起来非常美好，但是对于工作场景里面需要一些细致微调的部分，那可能还是专门的独特的用户界面会更好用一点。

比如说你说要剪辑视频，你在鼠标或者自动化的方式去剪辑，那么剪音的用户界面其实是还挺好用的。但是如果你要说我一句话一句话的去调整，比方说这个视频我想让左边这个音频轨道跟画面轨道再跟这个上面的特效轨道要对齐，要在某一分钟某一秒对齐。你看我话都说不完，说了两分钟可能才描述清这一个小的需求。那么在鼠标点点点的情况下可能一两秒就已经完成了，所以还是得取决于场景，不是所有的独特的用户界面都要被Chatbot来取代的。

第二个从技术上来说，MCP恰恰是把这个用户的能力进行了一个控制能力进行了一个导致吧。就是说这个里面叫控制反转，也就是说用户需要的是一个割草的能力。我不在意你提供给我的是一把镰刀还是一个割草机，我只需要告诉你我需要一个割草的能力就好了，然后AI自己去决定要调用哪一个服务。这一点在技术上还是一个伟大的创新的。

就是我们不是拿着锤子去钉钉子，而是我可以拿任何东西去钉钉子了。我只需要声明我有钉钉子挂画这个需求就好了。用户都是声明式的去表达自己的需求，而具体的执行都交由AI去选择优化。

所以这一点我觉得还挺有想象力空间的。好，今天又是录了将近20分钟，我觉得Voicenotes还是挺好，挺利于我的无压输出。这个输出呢，可以沉淀下来作为我后续的迭代资产。

怎么说就是我可能会把MCP这个系列做成一个视频，那么我的第一次语音输入其实相当于第一次迭代。纳瓦尔在最近的三个小时多的访谈里面，博客里面其实提到一类那本书提到了一万小时定律，但其实他认为更重要的是你要做一万次的迭代。

我们第一次在群里聊天可能就是第一次迭代，最初有这个想法，然后通过语音输出这样的方式进行了第二次迭代，然后如果后续要把它做成视频，那就变成第三次迭代，而在最后后面可能会把它变成文章，再去做演讲，再去做什么项目，那都是对于某一个概念的重复迭代。

而在这一次一次迭代之后，你不断的思考行动，再一次反思行动，这个效果才会越来越好嘛。单纯的重复它都是无效的，一定是要在每一次迭代优化的情况下，你才能够真正成为一个专家，一个符合一万小时定律的所谓天才。

好，那么我们今天说到这儿，刚好20分钟，我们下期再见，拜拜。