我移除了OpenClaw的默认Markdown内存，取而代之构建了一个严格的Node.js/Postgres API层。幻觉减少效果惊人。

和许多人一样，在使用OpenClaw默认的[`MEMORY.md`](http://MEMORY.md)文件几周后，我遇到了巨大的障碍。背景是，我目前正在构建一个认知生产力分析器（全栈应用，用于跟踪深度工作、生成专注热力图以及进行倦怠风险预测）。我一直在用OpenClaw帮助我规划系统架构和编写项目文档。但对于这样一个复杂的项目，依赖OpenClaw的原生内存简直就是一场灾难。因为内存只是一个纯文本文件，它变成了一个幻觉引擎。代理会自信地回忆三周前已废弃的API设计作为绝对真理，或者完全忘记我们刚刚就数据库结构达成的系统权衡。当LLM将文本写入`.md`文件时，没有任何结构保证。因此，我完全禁用了`memory-core`插件，并构建了一个确定性的强制层。我没有让代理写入文件，而是启动了一个轻量级的Node.js/Express中间件，底层由严格的PostgreSQL数据库支持。我通过自定义工具调用将这个中间件暴露给OpenClaw。**以下是该架构的实际工作方式：** * **严格的数据库模式：** 我设置了特定的Postgres表，用于存储`system_architecture_rules`、`api_design_decisions`和`feature_roadmaps`。 * **类型化的API契约：** 如果代理想要记住一个设计权衡或记录一个新的API路由，它*必须*执行一个`POST /memory/architecture`工具调用，并携带一个严格的JSON有效载荷，该载荷会根据我的TypeScript接口进行验证。 * **不可变真实：** 当我向OpenClaw询问项目相关问题时，工具层会从Postgres快速检索，并在代理开始推理之前将*精确的、类型化的*规则注入上下文窗口。 **权衡：** 是的，每次工具调用会增加约~150ms的延迟，而且我花了一个周末来编写处理API路由的后端逻辑。 **结果：** 上下文漂移降至绝对零。代理再也无法幻觉数据库模式，因为它物理上受限于Postgres中的关系数据。如果更新了架构规则，它会覆盖数据库中的旧行，意味着代理永远不会被庞大的markdown日志中的冲突笔记所困惑。 我认为我们正将代理内存视为一个“存储”问题，而实际上它是一个“API设计”问题。你不能仅仅给LLM一个空白文本文档，并期望它在数百次迭代中准确维护状态。你必须强制它通过严格的工具边界来分类其思维。 有人已经完全放弃原生内存插件而转向外部数据库了吗？如果其他人也遇到这个头痛的问题，我正在考虑开源这个Node仓库。