-
LLM 大语言模型
-
LLM本身只能针对文字进下词元预测，即原始能力只有续写，所有衍生能力都是对续写的封装
-
人为的为文字区分角色，即把一段字当做提问者，大语言当做解答者，让续写可以被封装成问答
-
提问者使用场景下，输入的文字往往分为两个部分
- context：上下文，也就是背景信息
- prompt：提示词，也就是指令
-
由于本质是续写，那么就只能做单次问答，无法实现追问，为了解决这个问题，可以把之前的对话内容也当做上下文，隐式的加入到下一次的提问中
- 自动整理的对话内容，作为新的上下文，称之为 memory
- context 的概念，上下文也得到扩展，除了你给出的背景信息还有自动整理的 memory
-
大语言模型本身的只能基于训练数据做预测续写，那么对于时效性和数据里没有提前准备好的部分，就无法保证内容质量
- 想要得到期望的内容，最有效的方法就是给大语言模型他缺少的信息，但是人为的收集，再给大语言就本末倒置了，为什么自己去找了，还要再问大语言呢
- 希望搜索，补充信息的过程自动化，这可以通过 coding 解决，调用 Google 的 API，然后补充信息，再生成回复
- 在用户眼里就只有右侧的一问一答，于是又是一个成功的封装
- 早期也就是简单的加一段 prompt ，根据大语言的回复做一些字符串判断是否调用 API
-
因为这个中间的 layer 似乎有了智能，可以自己查询自己需要的内容，还能调用自己需要的工具（如这里的 web searching），所以将这个中间层取名为 智能体Agent
- 既然Agent能联网搜索，那应该也能调用本地的外部文档数据，只不过不是用传统的数据库来做，而是使用向量 数据库，做语义化的检索
- 这种通过向量检索做语义匹配，并加入上下文的技术，叫做 RAG 检索增强生成
- RAG 和 web search都可以被称为 search，即获取模型参数外信息的能力
-
现在的架构如下
- 前文提到 agent 使用字符串匹配，来判断工具的调用，但是大语言不确定的回答格式，显然会为这个规则带来困难
- 为了解决这个困难，可以显式prompt 规定大模型回复 agent 的格式，比如 JSON
- 就类似于前后端的 API 规定
-
这种按照约定调用工具的方式，叫做 function calling
-
前文的架构工具写在 Agent 内部的，而如果工具作为外部的服务，如何进行通信呢，于是就又规定了一套协议，用于规定通讯格式，也就是 MCP
-
Agent 就像是一个传话筒，四处收集信息回答给我们
-
底层是肯定是文字，但是交互上可以有各种形式衍生
-
对于一些重复使用的可以编程固定的流程，每次让 Agent 发挥不仅不稳定，还效率低下，那为什么不把他们抽象出来呢，实现这个东西的方式，一种是 langchain，更低代码拖拽的形式就是 workflow
-
假设不是这种单一的场景，输入可能是各种格式，而输出又有可能是各种格式，那么写 if else 来判断显然不能是规模化的，不可能为所有的情况都写一套 workflow
-
而解决方案是，把这一系列工具放在一个文件夹里，再写一个类似说明书的文档，让大模型去读取，按需生成回复，调用需要的工具，就可以实现上述无法实现的复杂判断了
-
而这又带来了优化空间，可以规定其放在指定的位置里，这样不用每次都主动让 Agent 读取这个文件的一句废话，再把它隐式的加入prompt 中，而这就是 skill
-
-
-
而现在导致上下文膨胀，显然会影响质量和成本
-
于是又发明了subAgent，对上下文进行隔离子 Agent 的上下文不会再 Agent 里保存
