function calling的理解
在理解MCP之前，我们先知道什么是functioncalling，这是让模型能够调用本地代码的基础。
functioncalling本质：
- 大模型第一次阅读用户的问题，判断自己不能处理，返还一个特定格式（json）的数据给应用。
- 程序解析大模型返还的特定文本，并调用对应的工具（可能是一段代码、一个接口）。
- 返还一段数据（例如数据库查询结果）给模型输入，最后模型拿着新来的数据进行文本生成。
这就是朴实无华的模型与代码的沟通。相比于普通的大模型调用，function calling本质是将大模型的调用改为了两步调用：
第一步，将用户问题+工具定义，构成新的prompt，让大模型来判断工具使用。
第二步，应用执行工具后，将所需数据传输给大模型，大模型生成最终回答。
比直接调用大模型，多出来一步获取所需数据，或是调用工具操作。
MCP的理解
mcp，即model context protocol.
从function calling我们可以知道，模型现在有与外界交互的能力了。但是出现了一个极为麻烦的问题。
如果我用了多种公司的大模型，它们每一方的请求方式是不同的；我想用大模型与多种软件做交互，例如数据库，系统文件，excel，github，这么多的软件，每个的调用方式和鉴权也不同。
那么每有一种大模型要与一种工具结合，就会产生一种沟通方式。就出现了m × n种，这代码写到爆炸。
大家你说你的，我说我说，那不如找个统一的翻译，这就是MCP担任的功能，MCP作为在模型与工具中间的沟通桥梁，统一翻译它们说的话。只需要大家都认定这个标准，那么模型和工具都去适配它，那么沟通的成本都会由公司在产品出场的时候处理好。我们作为写代码的只需要利用一个MCP工具就一通百通啦。
MCP的实现
又来到了难点，看黑板。
这一套工作流程中有三个角色：
Host：AI应用本体，如clade，chatgpt。他们就是任务的发起者，自身带着模型对话的能力。
Client：协议中间件，内置在了Host中，负责将Host的模型指令->标准的MCP消息;以及把Server返还的内容 -> 模型可读的格式。它与Server进行1对1的有状态对话。
说白了，你在应用里说的自然语言，就是Client帮你翻译给Server听的。
Server：负责外部能力的对接，处理鉴权和执行实际操作，返还结构化的数据，例如，是server跟mysql沟通“小伙子， 你来给我查个数据吧”。这个server可以部署在本地，也可以部署在远程。
所以说白了，在这个协议中，我们的应用厂商与Clietn对接好，而工具厂商与Server对接好。在我们想用模型调用工具的时候，就不需要一个个自己去连接模型与工具啦。这就是MCP的贡献。
为了强化，用一个简单的例子讲述完整的流程。
- 人类对应用输入：帮我查询user 表里所有用户姓名
- MCP Client 解析 -> 生成结构化数据，将这段数据发送给MCP server
{
"tool_name": "mysql_select_query",
"params": {
"table": "user",
"column": "name",
"condition": ""
},
"request_id": "10086"
}
3. MCP Server收到结构化数据，做了几件事情：校验权限，解析tool_name，就知道要查询数据库了，解析其中的参数
-
MCP Server和mysql工具的悄悄话，把结构化数据，转化为原生sql
-
MCP Server执行查询，拿到数据库结果，将其策封装为结构化响应，返还给Client
{
"request_id": "10086",
"code": "success",
"data": [
"张三",
"李四",
"王五"
]
}
6. Client 收到结果，返还给用户,"查询完成，用户姓名列表：张三、李四、王五"
