阶段一及阶段二折腾内容

week1（24.0318~0324）内容：

本地llm服务配置（with lm studio & Ollama）
理解并尝试langchain框架
chat with webpage

week2（24.0325~0331）内容：

chat with local file
本地embedding文件并持久化（with chromadb）
理解并尝试autogen框架
理解memGPT
使用langchain尝试构建agent with tools
接入更多大模型（dolphin_Q4_K_M, Qwen_Q4_K_M, llama2-13b）
agent框架复盘

阶段二踩坑记录

autogen框架使用

autogen框架的核心在于引入了human intervene。需要有个GUI来承接这样的过程（之前github上已有这样的框架），使得agent的对话可见，且用户能够很好地介入。
定义了一个计算器function作为agent的工具。对话时询问agent一个较复杂的数学计算问题，使用mistral7b、llama2-13b、mixtral-8x7b，均无法触发该function的调用。由此意识到：agent的实现，核心依赖于LLM对任务的理解，如果理解不到位，很难触发tool的使用和Knowledge的检索。memory的检索可能在某些场景下还好，但长久来说也依然是问题。得考虑是否存在外挂attention驱动的可能性——依据额外设置的attention机制使得大模型对某些信息更加敏锐，并且更容易触发相应工具和知识的调用。

知识管理

prompt工程比我原先想的要重要一些，因为它的构造影响着LLM，促进它调用工具、检索知识和记忆。而之所以调用知识库和记忆需要在prompt或者Workflow中声明，是因为它不在大模型的脑子里，无论是longterm还是shorterm。但prompt依然无法绕开LLM本身的理解能力问题，也无法为理解能力提供更多支持，就连prompt本身的生效都依赖于LLM的理解能力。
阶段二只尝试了将本地的file通过embedding生成向量。而这样做的过程带来了一些的值得思考的问题——为了获得更好的检索效果和效率：

应该构建怎样的索引和知识结构？
不同类型或主题的原始文件，应该以怎样的方式进行组织和编排？
项目中，需要如何对数据进行预处理？预处理时又应该设定怎样的pipeline和评价标准？
知识检索的过程或许存在需要工程化的部分？（例如当需要检索知识时，先通过API调用得到关于知识库中不同类型知识的tag信息，再定向查找对应的表或对应的collection）

记忆管理

记忆使得user之于agent是有厚度的，也使得agent之于user是唯一的。
agent的记忆是外部挂载的，它和知识库的接入方式没有本质区别（基于数据库和vectorstore），也因此是可移植的。

为了研究如何管理agent的记忆，我找来memGPT：它将记忆与LLM封装到一起，构建成一个OS。它的特点是构建了名为core memory和archival memory的记忆区：core memory理论上对应了下意识和长期记忆，它一直存在于对话情景中；archival memory则对应更广阔的记忆区，它并不是一直load的状态，需要特别地进行召回和检索。它的API不大优化，因此没有直接上手尝试。但它的构造给了我灵感：

将LLM和记忆管理封装在一起，确实是所有agent-based系统都需要的部分，也更接近一个OS
像是人的核心记忆和泛知识一样，区别存储是非常energy efficient的
如何才能触发由信息刺激到认知的转化呢？而memory又是如何在core和archival中间转化的呢？人的每次回忆都会对原始记忆进行重新加工改写，在构造agent的时候，如何能够在不断的回忆和更新时，既保留历史又保留主干？
如果像管理知识一样管理记忆，我们该如何做？如果要从记忆中提炼知识，我们又该如何做？

本地调用多个大模型

LM studio更新后，支持在本地起多个大模型的服务，更加适合多agent场景，尤其是一主多副的场景。
m3pro 36GB的mac可能最多也就是同时跑三个模型。这样的拓给agent编排带来更多选项。

未来阶段计划

本地化存储agent聊天记录并实现调用（带有时间戳等自定义的metadata），探索记忆的逻辑分区和相互转换
本地化存储知识库并实现调用，探索知识管理的pipeline
定义tool，并让agent成功调用（需要多尝试几个LLM，也需准备一些对应的测试问题）
接入多模态模型，以及对应的多模态工具
multi-agent对话的可视化界面
找特定落地场景，探索场景下的agent落地方案