
对大模型和agent的认识
从23年GPT的火爆到deepseek的出现,最开始接触AI的网页端问答式对话,到去年开始兴起的agent编程,笔者也使用AI辅助编程了这么久了,这篇文章主要是结合网上大佬的知识分享,为了回顾并记录自己对于大模型和agent的认识,从一个使用的开发者角度整理相关概念
大模型的本质
这里的大模型指的是语言大模型
每当身边非电子/IT技术行业的朋友问我大模型是什么,我都会一句话回答:大模型本质就是一个概览预测的文本模型。它的本质就是通过对输入的上下文进行一个最大概率的预测,预测下一个词句是什么,或者叫做token
token
token是大模型处理文本的最小单位,和我们常见的一个字母为一个单元或者一个汉字为一个单元不同,一个token对于大模型可能是一个单词,或者一组汉字。一个token的定义是什么在我看来本质就是对于大模型来说几个字拼接出来最大可以使用成一个词的概率。比如:”校,学,一“,如果从它们三个字里面组一个token,那么就会是“学校”
上下文
大模型在预测下一个token的时候,依据的就是当前上下文中的所有文本。
和我最开始使用网页端的大模型很反直觉,最初自己并不懂大模型的本质,认为其本身具备了一定的记忆能力,所以它可以记住和我几十轮次前的对话,但是事实并非如此,大模型本身没有记忆,可以把它看成一个单纯根据输入反馈输出的系统
所以只要在一轮对话中,只要没有超过大模型本身的上下文限制,那么此次发送的对话一定是附带之前的所有对话内容的
所以这也是目前许多模型厂商都在补段扩充模型的上下文容量
思维链
大模型有一个特性:对于你的问题如果直接让它说出答案,它可能会给出错误答案,但是如果先让他把给出的推理过程写出来,准确率就会高很多,这就是思维链,就和人在做数学题需要打草稿一样,把自己输出的每一步结果都作为下一次的输入
System Prompt
模型本身是会随意的输出结果的,和一个纯粹不加限制的模型聊天可能会发现他每次的输出风格都有差异,这时候就需要使用System Prompt(系统提示词),指定模型用什么风格来输出结果
System Prompt是一段对话开始前给模型的文本指令,拼接到上下文的最前面,我们在使用很多AI聊天工具都看不见这段指令,有些是厂商自己规定好的,也有些是我们可以在界面上进行人为设置
System Prompt还有一个很重要的用处是设置安全规则,我们可能在很多次使用时都会发现有一些话题是禁止聊的,他可能会回复你抱歉我无法回答这个问题,或者像以前deepseek刚出来那样服务器繁忙,装死😂
这些都是因为大模型厂商就设置了System Prompt作为安全设置,当然也可能会问不是用户也可以设置System Prompt吗,用户设置让它可以输出不仅可以吗?
如果使用过大模型API或者把AI对话记录导出的时候就会发现在我们每次对话都有agent,user等前缀,这是用于标记不同角色的,厂商一般设置的都是最高的System级别,所以大模型会优先执行厂商的设置
函数调用
我记得在去年agent出来之前, Function Calling(函数调用)是很火的,可以说这是agent的基石
如上面所述大模型的本质就是一个文本大模型,它是一个超级大脑,但是也仅仅是一个大脑,没有手脚,能够做的就是对到来的文本进行预测并输出
而函数调用解决了这个问题,它可以让模型在想要做自己不能做的时候通过调用用户提供的API得到一组输出整合到自己的上下文中
这个API的描述也是塞进了对话的上下文中,比如让大模型查看今天的天气,可以告诉它自己有一个查询天气的API,需要使用的时候可以调用API,大模型调用API本质也是输出一个符合API输入预期的文本,当程序接收到预期API输入文本的时候就执行然后将结果输出给大模型,大模型再整合API输出结果然后反馈给用户
MCP
在说明上述的函数调用的时候,我们知道大模型可以调用API感知外部信息,但是你提供的API函数我提供的API函数多多少少不会一样,指定大模型的输入输出结果也不一样,并且把工具描述塞给大模型也依赖模型厂商提供的接口,那么为了一个统一的标准,2024 年 11 月,Anthropic 推出了 MCP(Model Context Protocol,模型上下文协议)。
MCP我认为重点就在最后一个P(Protocol),他就是一个协议,规范了开发者给予大模型API的接口描述,把这一整套流程标准化
AI agent
那么结合上面这么多,接下来到来的是去年开始掀起颠覆性的AI agent。agent本质上就是给大模型套了一层壳,把上面讲到的函数调用集成到一块,结合网上众多大佬的说法,Agent 的核心思路很简单:把 LLM + Tool Use 放进一个循环里。
while 任务未完成:
模型根据当前上下文思考下一步该做什么
if 模型认为需要使用某个工具:
执行工具,把结果追加到上下文
elif 模型认为任务完成了:
输出最终结果,退出循环
就是这么简单,所有编程agent,都是这个循环,配上编程相关的工具
当用户给出一个问题:解决某某bug。agent调用大模型首先去定位bug位置,大模型调用读文件工具,然后得到读取结果给大模型,大模型根据内容确认bug发生原因,调用些文件工具,写文件结果反馈给大模型,大模型再去确认是否修改成功,调用执行文件工具,工具执行完成反馈结果给大模型,大模型根据结果判定是否完成,完成后给用户最终答复
当然这个循环有一个副作用就是每一轮的工具调用结果都会附加在上下文中,上下文不断增加,所以上下文窗口很重要。如果agent跑个一两次就把上下文占满了,那后面继续对话大模型就会丢失最上面内容的记忆,而且工具调用也很消耗token,agent也需要注意如何给大模型最短的精确信息。记得当初MCP刚出来的时候网上也是一堆人唱衰说太消耗token了
skill
skill这个词是从去年下半年开始火起来的,在那个时候感觉几乎高端的AI编程都需要会skill。那skill是什么?
在笔者看来skill就是一个经验总结,可复用的执行手册。它的主要作用就是把你自己经常使用的一套流程规范化,不必要每一次都重复在文本框里面输入给AI,重复造轮子让AI把上一次对话的坑再踩一遍。
skill就是一个带有 SKILL.md的文件夹,这个MD文档现在都是遵守YAML规范,在开头去告诉agent什么时候该使用这个skill
而后面跟随的MD正文就是这个skill的具体操作指南,对于skill的编写不是事无巨细的说明文档,而是一个清晰步骤的使用指南,可以在同级目录下存放更多的说明和脚本,但是SKILL.md本身应该是一个明确的操作步骤,因为大模型它没必要去知道你这个具体的运行,它只需要遵从步骤跑出结果
Anthropic 在 Skills 的加载上有一个巧妙的设计叫渐进式披露(Progressive Disclosure)。比如一个 PDF Skill 的完整内容可能有十几万个 token,如果把所有 Skills 的完整内容一股脑塞进上下文很浪费 token。
所以实际做法是:启动时只告诉模型每个 Skill 的名字和一句话简介,几十个 Skill 加起来也占用不了多少上下文。等模型发现当前任务和某个 Skill 相关了,再加载更多的内容。
这就是一个典型的工程优化:核心原理没变(都是往上下文里塞文本),但通过按需加载,大幅降低了 token 消耗。
At last
所以上面说了那么多,笔者认为,大模型就是一个没有记忆的文本预测工具,而agent是集合各种工具调用丰富了大模型对外部感知的能力
