从前几天刚接触大模型相关知识的时候我就一直在想
为什么不能直接让大模型自己去调用外部的一些api，做一些自动化的操作，而是还需要我们自己先告诉大模型，用户需要知道今天或者明天的天气，然后告诉他，可能会需要的一些工具，这些工具是怎么使用的
然后让大模型自己去理解，得出了需要调用这些工具的结论，然后返回给我们的agent，然后再由agent根据大模型的返回，去调用相应的工具去使用
拿到数据之后，然后又把数据交给大模型，由大模型去自己理解这些结果数据，组织成自然语言返回给agent，然后再由agent展示给用户
今天继续深入了解之后
得出了一些结论
- 安全性：如果给大模型太多权限，可能会导致一些意想不到的结果（把用户的隐私数据当成段子发推特）
- 技术局限性：目前的大模型还做不到完全的去理解用户的需求，稍有理解偏差，就完全可能达不到用户需要的结果
总结：所以目前一些使用外部工具的功能还是需要自己编写好程序，去跟大模型进行交互，让自己编写的程序去做这些更强大的事情，这样的好处也在于，如果大模型理解错了，返回了错误的信息，也没关系，我们可以对大模型返回的结果进行校验，如果没达到预期，可以重试，不至于让大模型自由发挥，在错误的道路上越走越远。那么，如果说我们程序（agent）想要跟大模型进行比较省事的交互，就得定义一个标准，有了标准，与大模型交流起来就省事多了，那么，function calling就出来了，之前可能都是用自然语言去进行交互，这可能使得大模型返回的结果不太符合我们的预期，但是用function calling这套标准去交互，大模型返回的数据也就相对更加的准确。function calling约定了agent使用json格式的文本去跟大模型去交互，也要求大模型返回的格式使用json类型。如果大模型返回了错误的内容，也能够更好，更快的校验出来。而且function calling的重试相比于system prompt（系统提示词）不会消耗用户的token（因为大模型服务端就可以检测出来），更加的省钱，也降低了用户端的开发难度。
（function calling每个厂商的实现是不一样的）
当大模型告诉agent需要调用哪些工具的时候，agent就会根据大模型提供的内容去调用相应的工具，并且拿到相应的内容把内容交给大模型，由大模型去理解最后输出内容给agent，agnet再将内容展示给用户
那么agent与外部工具交互时，如果没有一套统一的标准，又比较的麻烦，而且很多的工具都是大家都需要的，每一个agent都拷贝一份也很麻烦，后面出现了mcp协议同一了规范，干脆把这些通用的工具都丢到mcp server （mcp服务器），agent根据mcp协议去跟mcp服务器去进行交互
从目前的理解来看，之前对mcp的理解似乎有点不对，想要壮大mcp协议的生态，不是第三方软件去支持，而是需要制定mcp协议的厂家去做，做好后上传到mcp服务器上共大模型厂商去使用
目前AI大模型正处于飞速发展阶段，谁也不知道这套架构是不是最终的结果，也很可能马上又被新起之秀给替代
最后贴一张b站上看到的图（各个名词之间的关联）：
