关于LLM的几种工具扩展方法的区别和见解

LLM本身只能当做聊天对话机器,他只可以接收对话，然后返回回答,本身是不能干任何额外的事情.

我们使用ai的一些扩展功能，比如联网搜索和其他的工具本质上是让AI返回指定参数,交由外部工具去完成,然后在拿外部工具执行到的信息作为上下文,再返回给AI,llm只是决策者而并非执行者,工具真正的逻辑执行部分和判断部分需要人为的完成.

而市面上主流的LLM主要有以下几种方法扩展工具

1.Tool Calls(很少使用)

这个是一些大语言模型本身自带的功能,可以让用户自定义一段工具介绍，然后让LLM在适当的时候返回工具调用的结构体,然后由用户解析结构体执行程序之后，再返回获取到的结果来完善上下文

缺点: LLM和工具的衔接部分需要自己人为书写,比如需要判断LLM有没有返回工具调用信息,如果返回了，要根据返回的信息进行选择调用,写的工具越复杂，衔接部分需要花费的时间就越大,并且不同的模型的Tool Calls返回的信息可能还有所不同，不同模型的Tool Calls标准不一样，同一个工具需要对不同的模型单独做适配,所以并不流行(不过算是最早的给llm扩展工具的方法)

2.Mcp(流行)

这是一套严格的标准,不会像Tool Calls一样可能因为模型的问题，返回的结构体有所差异,有mcp客户端,还有mcp服务器,工具的连接方式有远程，也有本地调用,是一套很完善的规则.

缺点: 因为调用流程过于严谨和繁琐,所以很容易引起llm上下文直接爆炸,让llm抓不到重点,对话越到后面效果越差。部署和开发也相对麻烦,因为有服务端，客户端，还有一些七七八八.而Tool Calls,可以直接在一个片段代码里面完成开发.

3.Skills(流行)

这个是最近claude推出,我对他的理解是最高级别的prompt,这个严格来说并不是一个标准,而是共识,更偏向于一个技术理念,需要IDE自己去实现这个理念（Claude开源了他们官方skills的实现）,不像mcp和Tool Calls是有一定的标准的,要严格按照官方的标准来。

Skills某种程度上来说和Tool Calls有点类似,但是他不需要写LLM和工具之间的桥接代码,并且还可以完成一些prompt才可以做的事，比如说自定义一下语气和注意事项.

Tool Calls每写一个工具，我需要自己再写程序去判断LLM返回的工具调用信息，然后再去执行运算(并且还可能因为不同的模型返回的信息有差异而导致兼容性问题),而放到Skills,我只需要自定义一段话,不需要写具体的代码(工具本身是要写代码的，只是调用不需要写代码),比如在特定的时候执行某个文件目录下面的某个代码片段传入某些参数,相当于把桥接部分交由了程序本身(如Vscode和windsurf)去执行,所以说需要程序去适配Skills,它是共识和理念，而不是一套标准.(不过当流行起来的时候，共识理念最终也会成为大家默认的标准)

总结

总结:以上三种给LLM扩展工具的方式,我个人对未来最看好的是Skills,我认为把这套逻辑和共识再进行优化加强是完全可以比过Tool Calls和mcp。Tool Calls桥接部分比较麻烦,一切运转都要依靠代码,还有兼容性问题;mcp开发部署繁琐,且容易引起上下文爆炸,LLM运行缓慢.Skills恰好能解决这两者的缺点