原贴链接

我在研究基于代理的系统等处理内存的现有选项，我想也许其他人看到这个列表会受益。很多代理系统假定能访问GPT，完全没有设置使用本地模型，即便理论上本地模型会比GPT - 3表现更好。通常可以通过API调用本地服务器，但有点麻烦，而且不能保证提示词在不同模型上能生效。GitHub上特定于内存的项目：[Letta](https://github.com/letta - ai/letta)——“Letta是一个用于构建有状态的LLM应用的开源框架。”——似乎是作为服务器运行的。基于MemGPT论文中的思想，涉及使用LLM通过工具调用自我编辑内存。可以使用SDK从Python调用服务器。有连接vLLM和Ollama的文档，他们推荐使用Q6或Q8模型。Memoripy——新出现的项目，支持Ollama和OpenAI，其他支持即将到来。试图以一种让更重要的记忆比不重要的记忆更容易获取的方式对记忆建模。Mem0——“一个智能内存层”——默认使用gpt - 4o，但可以使用LiteLLM连接开放模型。cognee——“Cognee实现可扩展、模块化的ECL（提取、认知、加载）管道”——更侧重于能够摄取文档而不仅仅是记住聊天内容。其理念似乎是帮助为LLM构建数据。可以作为自定义提供者与任何OpenAI兼容的端点通信，有一种简单的指定主机端点URL的方法（很多东西都硬编码了URL!）。还有一个Ollama特定的设置。推荐的最小开放模型是Mixtral - 8x7B。Motorhead (已弃用)——不再维护——处理聊天应用内存的服务器。[Haystack基本代理内存工具](https://haystack.deepset.ai/integrations/basic - agent - memory)——Haystack代理的代理内存，有短期和长期记忆。memary——更侧重于代理，自动从代理交互中生成记忆。假定通过Ollama使用本地模型。[kernel - memory](https://github.com/microsoft/kernel - memory)——微软的一个实验性研究项目，将内存作为其他服务的插件。Zep——维护一个用户信息的时序知识图谱来跟踪事实随时间的变化。支持使用任何OpenAI兼容的API，明确提到LiteLLM作为可能的代理。有社区版和主机云版本；云版本支持导入非聊天数据。MemoryScope——聊天机器人的内存数据库。可以使用Qwen。包括内存整合和反思，而不仅仅是检索。自己编写：[LangGraph内存服务](https://github.com/langchain - ai/memory - template?tab = readme - ov - file)——一个示例模板，展示如何为LangGraph代理实现内存。txtai——虽然txtai没有实现聊天机器人内存的官方示例，但他们有很多像这样的RAG示例、这个和这个，这让我觉得它是一个可行的选项。Langroid有向量存储和来源引用。[LangChain内存](https://github.com/Ryota - Kawamura/LangChain - for - LLM - Application - Development/blob/main/L2 - Memory.ipynb)。其他：WilmerAI有带内存的助手。[EMENT：增强大型语言模型中的长期情景记忆](https://github.com/christine - sun/ement - llm - memory)——研究项目，结合了嵌入和实体提取。代理框架。我有没有遗漏什么？有人成功将这些用于开放模型吗？

讨论总结

原帖主要分享了处理基于代理系统记忆的项目资源，涵盖GitHub上的项目、自行编写的示例等，并询问是否有遗漏以及是否有人成功用于开放模型。评论者们从不同角度进行了回应，包括对原帖价值的认可与感谢、补充遗漏项目、分享自己在相关研究或测试中的经验、探讨记忆程序与其他程序的技术对比、对记忆相关技术提出疑问和见解，整体氛围较为积极且富有技术含量，但整体讨论热度较低。

主要观点

  1. 👍 原帖内容很有价值
    • 支持理由：评论者称其为“金子”，对自己研究有启发和帮助作用。
    • 反对声音：无。
  2. 🔥 原帖在列举记忆相关项目时有遗漏
    • 正方观点：评论者指出遗漏了MemoryLLM项目。
    • 反方观点：无。
  3. 💡 记忆程序与Kobold cpp在存储和使用数据集方面有相似之处
    • 解释：多数记忆程序都是存储和使用大数据集，但在获取信息添加到上下文中有所不同。
  4. 💡 很多agent memory相关库存在不足
    • 解释：如重量级、运行困难、功能单一、缺乏异步操作等。
  5. 💡 聊天机器人若有当前和过去交互记忆会更好
    • 解释：从聊天机器人发展潜力角度阐述记忆功能的重要性。

金句与有趣评论

  1. “😂这是金子，非常感谢你！”
    • 亮点：高度评价原帖内容，表达感激之情。
  2. “🤔forgot [https://github.com/wangyu - ustc/MemoryLLM](https://github.com/wangyu - ustc/MemoryLLM)”
    • 亮点：补充原帖可能遗漏的项目。
  3. “👀大多数（记忆程序）都是在做同样的事情，它们只是在你受限于上下文时存储和使用大型数据集的创造性方法。”
    • 亮点：概括记忆程序在存储和使用数据集方面的共性。
  4. “🤔智能记忆系统不会把英格兰国王放到他不属于的汉堡王场景中，对吧？”
    • 亮点：形象地说明智能记忆系统的特性。
  5. “👀试着将你的请求分解成一个更简单的任务。一次只要求一件事。不要把事情复杂化。”
    • 亮点：针对给LLM指令提出实用的优化建议。

情感分析

总体情感倾向为积极正面。主要分歧点较少，多数评论者都对原帖表示认可或感谢，或在原帖基础上进行补充和建设性讨论。可能的原因是原帖提供了较有价值的信息资源，且话题比较专业小众，大家更多是分享自己的经验和见解。

趋势与预测

  • 新兴话题：记忆存储前询问用户澄清问题的基于记忆的代理的探索方向。
  • 潜在影响：对优化基于代理系统的记忆处理功能，提升相关技术在不同场景（如创意项目、聊天机器人等）中的应用效果有潜在推动作用。

详细内容：

《探索代理系统的内存处理：Reddit 上的热门讨论》

在 Reddit 上，一篇关于处理代理系统内存选项的帖子引起了广泛关注。该帖子作者分享了自己的研究成果，列举了一系列与代理系统内存相关的项目和资源，并询问是否有遗漏。此贴获得了众多点赞和丰富的评论。

讨论的焦点主要集中在这些内存处理方式的差异、复杂性以及在实际应用中的效果。有人指出，大多数内存处理程序类似于在每个提示后注入自定义指令，但方式各有不同，关键在于如何抽取和添加信息到上下文中。比如，简单的方式如关键字激活，但存在局限性；而更复杂的系统如基于向量存储的 RAG 则能以更智能的方式处理。

有用户分享个人经历和案例，认为向 LLM 发出复杂且相互矛盾的指令会使其困惑，应简化请求或分层处理。还有用户提到目前在测试各种内存处理方式时遇到的问题，如运行困难、核心功能像黑箱、难以适应特定用例等。同时，对于理想的内存处理方式，有人提出了一系列期望的特性，包括多种检索方式的可扩展性、异步数据插入和处理、包含内存元数据、与非会话背景知识的结合、有效呈现和利用信息等。

在观点分析中，有人认为应尽量以积极的方式向 AI 提出请求，避免使用否定语句。也有人认为通过提供示例来展示期望的格式或风格比单纯描述更有效。

这一讨论揭示了代理系统内存处理领域的现状和挑战，为相关研究和应用提供了丰富的思考和借鉴。但究竟哪种方式才是最优解，仍有待进一步探索和实践。