用于数据工程智能体的可搜索长期记忆系统
多智能体数据工程系统如何停止重复调试相同故障：自动捕获、范围限定日志、精选层级及上下文级检索。
来源: Learning from Experience: Searchable Long-Term Memory for Data Engineering Agents
无状态智能体很擅长解决问题，但往往记不住自己已经解决了这些问题。
遗忘问题
想象这样一个智能体：它在新建的 Databricks 笔记本中花费了近一个小时来解决 NoClassDefFoundError 错误。它通过堆栈跟踪定位问题，发现作业集群中缺少某个库，随后应用修复措施并确认任务成功运行。这堪称出色的自主调试能力。
一周后，另一个流水线遇到了完全相同的错误，而该智能体却丝毫不知道自己曾经处理过这个问题。整个调试过程不得不重新进行，且这次很可能会采用不同的修复方法。
这并非模型故障，而是智能体的默认行为表现，它们会通过三种方式遗忘信息：
- 当会话结束时，其中所学到的所有信息都会消失。
- 过长的会话最终会被总结或压缩，这样虽然能保留整体故事脉络，但往往会导致那些重要的实现细节丢失。
- 在多智能体系统中，工作智能体通常从干净的上下文开始，不会继承之前智能体的任何信息，任务完成后也不会保留任何内容。
有一个团队在运行用于生成 Databricks lakehouse 流水线的多智能体系统，他们在以上三个方面都面临着这种“记忆丧失”问题。他们的解决方案是引入一个可搜索的长期记忆层。
“可搜索记忆”的含义
在智能体系统中，有两种不同的东西被称为记忆，因此需要明确这些术语的含义。
上下文窗口充当智能体的工作记忆。其中存储的内容模型可以立即获取，但仅限于会话期间有效。一旦信息被移除，对智能体而言就相当于已经消失。
长期记忆是一种能够超越会话、任务和智能体而持续存在的存储机制。然而，仅仅存储信息是不够的。只有当信息能够被自动捕获、有效检索，并在需要时被调入上下文窗口时，它才能成为有用的记忆。最后这一步才是关键。那些永远无法被调用的完美课程等同于不存在，而即便被调用了，如果无法传递给做出决策的智能体，也同样毫无价值。
认知科学提供了一种与智能体系统高度契合的分类体系：
- 情景记忆用于存储特定的过去经历：已归档的会话记录、之前的故障及其解决方案、以往版本中的决策记录等。
- 语义记忆存储结构化事实，例如“实体X属于数据产品Y”或“此源系统以这种方式进行身份验证”，理想情况下还会标注有效时间区间，因为这些事实会发生变化。
- 程序记忆则是各种操作技巧：指令文件、技能以及每次会话都会加载的规范。
两种层次的记忆
一个决定大大简化了问题：将记忆分为两个层次。
第一层：精心管理的记忆。这是一组规模较小、由人工维护的规则，会在每次会话中加载。包括架构标准、安全要求、命名规范以及管理约束等。提示空间十分宝贵，因此这一层仅用于存储那些必须始终可用的内容。
第二层：可搜索记忆。 这是一个自动收集的大量经验档案，仅在相关时才会被调取：经过验证的修复方案、故障排查成果、部署经验以及常见的故障特征。默认情况下它不会出现在提示信息中。
经验法则：
每次都必须遵守的事实应归入精心整理的层级；在类似情况再次出现时才有用的信息则应归入可搜索层级。
这样的划分既能保留知识，又不会让上下文窗口不堪重负。
需要它的多智能体系统
该系统负责处理整个数据工程生命周期，将业务需求转化为可直接投入使用的流程与仪表板。一个协调器负责管理各个专用工作节点，每个节点仅承担一项任务，并仅拥有其所需的工具：
- 功能规格制定：阅读需求工单，起草规格文档，并获得需求提出者的确认。
- 技术设计：将已批准的规格文档转化为数据契约及源数据到目标数据映射关系的蓝图。
- 数据摄取、转换与集成：生成实际的流程代码，包括从 Kafka、SAP、REST 接口或文件中获取数据的青铜级笔记本，用于数据重构的银级笔记本，以及采用奖章式布局的黄金级维度模型。
- 验证：是唯一被允许接近实时集群的组件，它会将每个生成的笔记本在临时测试表上运行并检查输出结果。
- 代码仓库：负责管理分支、代码提交及拉取请求。
- 监控：在代码变更合并后持续监控 CI/CD 流程。
该架构刻意采用了隔离设计。各个工作节点并行运行，拥有独立的文件所有权，彼此之间无法通信，且每项任务都在完全清空的上下文中开始。调度器会编写独立的任务指令，工作节点则执行限定范围内的任务，返回结果后便消失。
这种隔离机制使得系统更加安全且可并行处理。但同时也导致了“遗忘效应”比单节点系统更为严重，因为每次所有工作节点都如同“初生”一般。每个角色都会积累自己认为有价值的经验，而这些经验除非被保存在节点上下文之外，否则在任务结束后就会消失。
为多个智能体设计记忆机制
有四种机制可用于解决这一问题。
1. 自动捕获
代理运行时的钩子在两个时刻被触发：会话关闭时以及上下文被压缩之前。每次触发时，系统都会读取对话记录，并将可复用的经验提取到内存存储中。这样就无需有人记得编写文档或更新知识库了。
内存操作也是非阻塞的。如果内存基础设施出现故障，这些钩子会静默地不执行任何操作。内存层的作用是提供辅助，绝不能变成没有它就无法继续工作的核心组件。
2. 范围限定访问
协调器拥有完整的内存工具集，而工作节点仅具备三种功能：读取自己的日志、写入自己的日志以及搜索存储内容。是工具而非提示语来强制执行这些限制，这样既能明确职责，又能防止工作节点擅自修改内存中的内容。
3. 角色专属日志
每个工作节点都拥有独立的记忆命名空间。运行时故障及已验证的修复方案会记录在验证代理的日志中，而 CI/CD 监控器则会收集故障特征及有效的解决方案。其他代理也保存着类似范围有限的记录。
这些日志并非通信渠道。工作节点不会通过内存传递消息，协调工作仍由调度器负责，它确保每份日志的连贯性与相关性。
4. 上下文层面的召回
这被证明是最重要的决策。工作节点初始时拥有空上下文，因此只有将检索到的记忆注入该上下文后才能发挥作用。相关规则如下：
未被放入上下文的检索记忆对工作节点而言并不存在。
每当找到相关的经验教训时，协调器会在分配任务之前将其直接写入任务上下文中。仅检索数据是不够的，经验教训必须能够被看到才能被应用。
基于 MemPalace 构建
该层是基于 MemPalace 构建的，这是一种开源的、以本地优先为理念的记忆框架。存储、嵌入向量以及搜索索引都在本地运行，因此没有数据会离开该环境，这对于处理企业数据及生产系统的智能体而言非常重要。
MemPalace 将记忆以文本块的形式保存，并附加元数据，如创建智能体的信息、类别以及时间戳，这些内容被存放在不同的命名空间中。这样一来，针对不同角色的日志记录便得以实现：每个智能体都在自己的空间中书写，从而逐步积累专业技能。
捕获过程会经过上述的生命周期钩子。在会话结束或数据压缩之前，转录内容会被清理、转化为可重复使用的课程内容，嵌入本地ONNX模型，并建立索引以便日后检索。所有这些操作都在后台进行，因此智能体无需等待内存操作完成。
检索方式是混合型的，结合了向量相似度与关键词匹配。这在数据工程中很有用，因为有些信号是语义性的，而有些则是精确的字符串。诸如NoClassDefFoundError这样的错误名称或精确的Databricks运行时版本必须完全一致才能匹配，但用不同方式表述的同一问题也应能被识别出来。
智能体通过MCP访问内存。协调器能够看到整套工具集，而工作节点仅能看到diary_read、diary_write和search这些功能，其使用边界由工具本身而非提示语来限定。
选择MemPalace是因为它以本地化为核心、免费且易于集成，但其架构并不依赖它。Mem0、Zep或Letta也能承担相同的功能。重要的不是框架本身，而是反馈循环：记录经验、存储起来，当同类问题再次出现时便能加以利用。
实际应用中发生了哪些变化
最明显的收益是故障分类处理。验证代理的一个核心原则很简单：每次出现故障时，先搜索再调试。
mempalace_search(query="NoClassDefFoundError DBR 14.3")
当有匹配结果返回时，代理会获得从先前成功解决方案中提炼出的经验：
处理订单的青铜级笔记本在 DBR 14.3 版本中因与 Avro 反序列化器相关的
NoClassDefFoundError错误而崩溃。解决此问题的方法是：在作业集群配置中明确指定序列化器库。
这种差异非常显著。代理无需从零开始寻找解决方案，而是可以借助已有成功的案例作为依据。其价值不仅在于速度，更在于一致性。如果没有记忆功能，面对同一问题的两个代理可能会各自选择不同的、看似合理的解决方案；而有了记忆功能后，系统会选定已知有效的方案并持续使用它。
其他领域也出现了类似的改进。CI/CD监控工具现在会将历史上的故障特征记录纳入其诊断报告，会话启动钩子能够恢复相关的最新上下文，而专用代理则能随着时间积累专业知识，而无需不断重新学习。
无需重新训练。学习流程发生在模型之外：经验积累、经验总结、数据存储、数据检索、应用实施。
生产环境中的经验教训
处理历史数据时要谨慎。最初的尝试导入了大量旧记录。结果并不理想，因为旧数据往往掩盖了更新、更有价值的经验，还会导致检索结果混乱。团队放弃了批量导入的方式，从日志开始实时采集的那天起重新开始。时效性和质量比数据量更重要。
用通俗的语言记录记忆。该框架提供了简洁的输入格式，团队也沿用了这些格式。当存储的记录包含后续搜索会用到的确切词汇——如产品名称、实体名称、错误信息及异常类时，检索效果最佳。在记忆存储系统中，可检索性比存储容量更为重要。
谨慎选择要记录的内容。并非所有见过的内容都值得永久保存。值得保留的是已确认的解决方案、经过验证的发现以及可重复使用的经验。而常规日志、短暂观察、重复的状态更新以及敏感信息则不必记录。杂乱无章的记忆会迅速堆积，其危害可能超过完全没有记忆的情况。
要点总结
每当工作人员反复执行实际工作时，他们就会积累值得保存的经验。该框架的建议如下：
- 将内存分为人工精心整理的规则与可检索的经验内容。
- 自动记录经验教训，尤其是在上下文压缩之前。
- 为工作人员授予基于角色的有限权限。
- 当可能存在类似问题已被解决时，先检索已有答案再进行推理。
- 将检索到的记忆直接放入提示词中。
- 将记忆视为证据，而非不容置疑的真理。
- 更注重记忆的质量而非数量。
最核心的启示在于架构设计。虽然人们投入大量精力让智能体变得更聪明，但实际上系统的长期价值在于其记忆能力。
相关阅读
- 从模型到智能体：重新构建三道防御线 —— MLOps治理机制如何应用于智能体系统：三道防御线各自需要补充什么、存在哪些漏洞，以及欧盟、FDA和金融监管机构提出了哪些要求。
- 构建无需囤积数据即可延续对话的智能体记忆系统 —— 一种针对智能体的三层记忆设计：让会话状态自动失效，保持长期记录的规模较小且可编辑，并实时获取最新数据。此外还涉及多智能体之间的任务交接失败问题。