我用一年时间在知识图谱上构建智能体记忆。以下是让我耗费数月的5个错误

过去一年，我使用知识图谱和本体论在MongoDB之上为我的AI智能体构建了一个统一的记忆层。我最初追逐了每一个趋势。我拿起了那些闪亮的框架，试图预先设计出完美的本体。我几乎犯遍了所有可能的错误。简单的记忆在规模扩大时会失效。当记忆变大时，文件搜索会使上下文窗口膨胀。Claude Code开箱即用地处理这个问题。即使是基于历史记录的语义搜索，也无法遍历人物、话题、对象、地点和偏好之间的关系。解决办法是停止将记忆视为检索问题，而是将其视为**数据建模问题**。以下是我犯的5个错误： 1. 我首先选择了框架。我尝试了LangGraph和CrewAI。当我需要自定义本体约束、不可变的观察日志、复合ID和多跳遍历时，我一直在与框架作斗争。教训：自己掌控记忆和工具，因为框架编码了你的系统很少匹配的假设。 2. 我过度思考了本体。知道这是数据建模问题后，我试图预先设计完美的本体。这使项目停滞了数月。教训：本体设计是一个数据探索循环。从POLE+O（人/对象/地点/事件/组织）开始，仅在冲突时扩展。例如，我曾经将"Claude Code"标记为Person，而它其实是一个Object。 3. 我混淆了解析与去重。命名不是身份。混淆它们会破坏图谱。解析是规范化名称，而去重是根据实体上下文决定身份。教训：使用特定阈值：≥0.95自动合并，>0.85触发人工审核，≤0.85创建新节点。这样可以防止公司"Apple"与水果"Apple"合并。 4. 我只构建了短期和长期记忆。智能体重复失败的策略，因为我跳过了推理记忆。这是每次运行的轨迹，包括策略、使用的工具以及成功或失败。教训：推理记忆类似于数据库层的强化学习，而不是权重。诚实的告诫：它可能适得其反，因为不良轨迹会强化不良策略，并且对于一次性任务来说过于复杂。 5. 我尝试在将图谱物化到数据库之前构建一个不可变的日志层，因为这听起来很酷，它为图谱添加了版本控制和时间性。缺点是对虚拟机的RAM造成巨大压力，成本极高。教训：只有在真正需要时才这样做。模式决定了系统性能的一切。将边作为MongoDB中的一等文档，使得原生的`$graphLookup`得以实现，最终让系统能够扩展。这种方法避免了关系重复，使写入更加简单。 你是否尝试过通过知识图谱和本体构建你自己的智能体记忆？如果是，你最大的错误或收获是什么？ **TL;DR:** 智能体记忆是数据建模问题，而非检索问题。掌控工具，不要预先过度设计本体，将解析与去重分开，并加入推理记忆。