MCP的起源：从Claude到Anthropic
首先我们要知道MCP是Anthropic公司提出的概念，也就是Claude模型的公司。
可是要讲清楚MCP的由来，我们得从OpenAI讲起，也就是ChatGPT的母公司，毕竟是它帮助LLM破圈，让我们普通人了解到了大语言模型。
大语言模型的早期局限与挑战
一开始大语言模型在推理，也就是输出的过程中主要是以文字为载体的，毕竟大语言模型属于NLP领域，也就是自然语言处理。
但是随着LLM的发展，事情慢慢开始不对了。因为LLM是通过预训练实现的，因为其参数量巨大，需要的训练数据也是海量，所以就算是最新的大模型，也有一定的信息滞后性，比如它不可能知道昨天刚发生的事情。
工具化尝试：给大模型配网络搜索
此时聪明的你肯定想到，我给大模型配上一个网络搜索的工具不就好了吗？每次调用LLM之前我先基于问题里的关键词Google一下，获取当前的最新消息，然后把消息内容告诉LLM，给它临时补个课。
这时候又有一个问题出现了，现在我的网络搜索工具都是通过代码固定在调用大模型进行问答之前的，也就是工作流的形式。这样就算我只问个你好，也会上网搜罗一通，这样太耗时了，反而出力不讨好。
从手动开关到智能判断
于是从交互设计上，我们加了一个开关，让用户自己判断需不需要使用搜索功能。可是在当下，我们在使用豆包或者ChatGPT时候，会发现已经不需要我们手动选择了，这是如何实现自动判断的呢？
聪明的你肯定想到，既然大模型这么聪明，让它自己判断要不要联网不就好了？恭喜你，这样做没问题。可是问题又来了，这个联网工具之前都是代码写的，如何让大模型使用呢？
此时OpenAI的工程师们发现，我们可以把网络搜索这种工具，以固定的JSON格式输入给大模型，让大模型判断是否需要调用，并且注册这个工具的function的回调，如果大模型选择调用工具，那么我们就接受入参，执行回调函数，并把执行结果返回给大模型，让其参考执行结果进行回答。
到这里，OpenAI的function calling应运而生，我们把这些大模型调用的工具称为tool。
从此以后，我们的大模型不仅拥有对话的能力，还拥有了调用工具的能力，成功变身Agent，没错，目前行业内的共识就是能循环执行并调用工具来完成任务的大模型就是Agent，也就是智能体。
Tool的协议化设计
上面我们知道了什么是tool，此时问题又来了，我们的tool真正的执行核心是回调函数，这块内容依然在自己的代码里实现。一个网络搜索的工具，如果我又想用Google，又想用Bing，还得每次修改代码，引入这些依赖包。这样太麻烦了，如果我们可以只需要引入tool的定义，不用管tool的实现就好了。
于是聪明的你想到可以定义一个协议，来执行其他库或者服务器上的tool，那么这个协议如何定义呢？
我们想到可以通过这些tool是运行在本地还是远程服务器来区分。如果是已经安装在本地的包，我们使用进程之间的通信就好了，简单直接；如果在远程服务器，我们就用HTTP协议，恭喜你，到这里你和Anthropic的工程师想的一样，你发明了MCP。
于是我们发现，所谓的Model Context Protocol，就是一套协议，用于给大模型调用外部工具集的一系列约定。当然MCP更深入还有其内部是如何基于stdio调用Python和JavaScript本地包的，为什么MCP官方要废弃SSE而拥抱streamable HTTP，这些如果大家有兴趣可以留言，单独写一篇。
至此，MCP已经实现了，模型调用和工具实现完全解耦，大模型借助tool解决问题灵活性更强了，但是新的问题又出现了，以至于Claude Code也不得不引入新的方案来解决问题。
下一篇，我们为什么需要SubAgent？ 敬请期待。
