别再把你AI助手的记忆放在LLM上下文窗口里了
摘要
文章认为，AI助手的记忆和状态不应存放在LLM上下文窗口中，而应放在独立的事务性数据库中，采用确定性控制流，并将LLM视为处理非结构化输入的判断层。
大家好，最近我将一些智能体工作流投入生产，想吐槽/分享一个我看到很多人犯的重大架构错误。别再把你LLM的上下文窗口或大规模向量嵌入当作智能体的长期记忆。如果你的智能体需要保留状态、记住过去的误报、处理人机协同工作流或维护审计轨迹，那么将会话历史整成一个巨大的JSON blob来回传递到提示词中，简直就是无声失败和高昂token账单的配方。对我们而言，唯一能在生产环境中存活的架构依赖于严格的关注点分离。首先，持久化状态和记忆必须完全存在于智能体之外，放在像Postgres或Lakebase这样平淡且高度结构化的事务性数据库中。智能体只需在启动时读取，在工具执行时写入——它本身不应是数据库。其次，使用确定性控制流。如果你有明确的业务约束，比如“在写入数据前必须征求人类意见”，那就用Python或Langgraph这样的状态图框架来编码这个逻辑，不要依赖系统提示来强制执行安全边界。最后，把LLM当作判断层。严格将模型用于处理非结构化输入、生成工具参数或总结证据。将状态层迁移到专用数据库意味着我们实际上可以暂停、重放和单元测试智能体的执行，而不用担心上下文漂移或幻觉抹掉智能体的历史。很想知道其他人是如何处理多日工作流的持久状态的？你们是把所有逻辑都封装在自定义的SQL表中，还是依赖框架的记忆功能？
相似文章
Agent记忆层无需LLM来决定记住什么
作者认为，Agent记忆层应跳过基于LLM的提取来决定记住什么，转而使用简单的存储、嵌入和检索，其开源工具memU即是例证。
我认为AI代理没有记忆问题，而是存在状态完整性问题。
作者认为AI代理存在状态完整性问题而非记忆问题，并提出一个状态账本（State Ledger）来区分历史事实与当前状态，并跟踪来源。
尝试让智能体记忆跨会话持久化所学的经验
本文反思了AI智能体记忆的复杂性，远超简单的存储问题，强调了诸如判断真实性、优先级变化、区分决策与噪音以及何时恰当地呈现上下文等挑战。
受人类启发的LLM智能体记忆架构
微软研究人员提出了一种受生物学启发的LLM智能体记忆架构，该架构结合了睡眠阶段巩固和基于干扰的遗忘机制，以高效管理持久性记忆。
@akshay_pachaar: 没有记忆的智能体，根本算不上智能体。一个 LLM 看起来像是在"记得"，其实只是应用不断把之前的上下文重新发送给它…… **原文内容（推文）：** 没有记忆的智能体，根本算不上智能体。LLM 之所以能表现出"记忆"能力，是因为应用层一直在把历史对话重新发送给模型，而不是模型本身具备真正的记忆机制。
Akshay Pachare 阐述了 AI Agent 的记忆机制在短期范围（语义记忆、情景记忆、程序性记忆）与长期范围之间是如何协同工作的，并介绍了 Oracle AI Agent Memory——这是一个不依赖于特定模型或框架的 Python 包，构建于 Oracle AI Database 之上，提供受治理的会话线程、摘要、持久化记忆以及分域检索能力，其 token 消耗显著低于直接使用扁平历史记录的方式。