Neotoma 的 OpenClaw 插件为您的代理提供不会损坏的内存
OpenClaw 将内存存储在 Markdown 文件中。 Neotoma v0.4.3 作为底层的结构化状态层原生插入,为 OpenClaw 代理提供来源、实体解析和版本历史记录,而无需更换代理。
要点
- OpenClaw 将内存存储在 Markdown 文件中。这种情况一直有效,直到事实在压缩过程中消失、实体身份在会话中漂移、并发写入损坏状态或错误答案没有审计跟踪。
- Neotoma v0.4.3 作为原生 OpenClaw 插件提供。每种故障模式都会得到结构性修复:仅附加观察、确定性实体 ID、模式验证写入和完整出处。
- 插件注册到 OpenClaw 的四层插件系统中。代理循环保持不变。状态从平面文件转移到具有时间线查询和基于关系的检索的结构化层。
- 读取路径设计保留了 KV 缓存经济性,使基于文件的内存变得合理。实体快照在调用之间返回稳定的文本。
- 这是开发人员发布集成。目标是测试真实代理平台下的结构化状态,而不是保证今天的稳定性。

内存上限
如果您今天运行 OpenClaw,您的代理会将内存存储在“MEMORY.md”中,并将日期文件存储在“memory/”目录中。这适用于单代理、单会话使用。一旦你依赖记忆来完成任何正在进行的事情,你就会遇到天花板。故障模式是特定的且可预测的。
内存压缩会丢失事实。 OpenClaw 会触发静默代理轮流,在截断上下文之前写入“持久记忆”。压缩之前文件中的内容未知。如果压缩版本丢失了一个事实,那么它就消失了。没有观察日志。没有回滚。
跨会话没有实体身份。 一个会话中的“Acme Corp”和下一个会话中的“ACME CORP”可能会也可能不会解析为同一实体。代理每次都会从上下文窗口重新推断。没有稳定的ID。没有合并规则。
并发写入损坏状态。 如果您运行多个接触相同内存文件的代理或插件,则会出现数据损坏。 OpenClaw 自己的文档也承认了这一点。单代理上限是真实存在的,大多数代理工作流程不会永远保持单代理。
没有审计跟踪。 当客服人员给出错误答案时,您无法将其追溯到特定的观察结果。您无法看到周二和周四之间发生了什么变化。你不能回答“我的代理人在做出这个决定时知道什么?”
这些不是极端情况。一旦代理处理联系人、任务、事务或任何跨会话重要的状态,它们就会出现。
插件添加了什么
Neotoma v0.4.3 添加了一个 openclaw.plugin.json 清单、一个入口点以及注册到 OpenClaw 的四层插件系统中的工具定义。网关发现插件、验证清单、加载运行时并向代理公开 Neotoma 的工具。
上述每种故障模式都得到了结构性修复。
压缩不再丢失状态。 观察仅是附加的。压缩摘要仍然可以服务于上下文窗口,但源观察结果仍然存在于 Neotoma 中并具有完整的历史记录。没有什么会悄无声息地掉落。
实体身份是确定性的。 基于哈希的规范 ID 按规则(而不是按会话推断)将“Acme Corp”和“ACME CORP”解析为一个实体。每次都是相同的联系人、相同的 ID。
并发写入是安全的。 写入同一实体的两个代理会在仅附加存储中产生两个观察结果,而不是文件冲突。架构约束会在每次写入进入存储之前对其进行验证。
内置审计跟踪。 每项观察都可追溯到其来源。修正会产生新的观察结果,而不是覆盖。您可以在任何时间点重建状态。
除了修复上限之外,该插件还公开了“MEMORY.md”根本无法支持的功能:
- 结构化检索。“链接到此联系人的所有任务”或“与供应商 X 的每笔交易”是查询,而不是文件 grep。
- 时间线查询。 跨实体的日期字段生成时间线。 “上周发生了什么”会命中时间索引,而不是上下文窗口搜索。
- 架构验证。 实体类型在写入时进行检查。不良数据在进入商店之前会被拒绝。
代理循环不会改变。 OpenClaw 仍然管理意图解释、浏览、表格填写和技能执行。 Neotoma 处理状态。该插件位于代理的写入和持久存储之间。
开销问题
Markdown 文件是免费的。它们的设置和维护无需花费任何成本,并且 KV 缓存经济学会积极奖励它们。
Neotoma 增加了开销。写入时的架构验证。观察存储。实体解析。本地服务器进程。这些都不是免费的。但开销被设计为不可见:代理安装 Neotoma、配置它并写入内容,而不需要您学习新工具或改变您的工作方式。
问题是这些开销是否值得支付。如果您的代理永远不需要回答“我上周二知道什么”或“哪个写入损坏了此联系人记录”,那么就不需要。 MEMORY.md 是正确的架构。
如果您的代理管理持续的状态、联系人、任务、事务和供应商关系,并且您需要跨会话的一致性,则写入路径开销是问题中成本最低的部分。昂贵的部分是在审计跟踪不存在时调试状态损坏。
这不做什么
该插件不会取代 OpenClaw 的代理循环。它不会改变技能的运作方式。它不需要迁移现有的“MEMORY.md”内容(尽管支持导入)。
它并不能解决所有代理内存问题。检索质量、及时工程、技能设计和模型选择仍然很重要。 Neotoma 处理状态层:存在哪些实体、它们如何链接、它们来自哪里以及它们如何变化。该层之上的所有内容都保持不变。
它也没有声称生产稳定性。 Neotoma 处于开发者版本。重大变化是意料之中的。该插件的存在是为了对真实代理平台下的结构化状态在实践中是否有效进行压力测试,而不是保证当今的可靠性。
尝试一下,打破它
我一直在我自己的代理堆栈中运行Neotoma作为内存层。多个代理向同一商店写入内容:电子邮件分类、任务管理、财务和内容。上述多智能体状态问题对我来说并不是假设的。它们是我每周都会打的东西。
该插件使 OpenClaw 用户可以使用此功能。安装它。启用它。使用底层的结构化状态运行您的代理。看看它在哪里有帮助。看看哪里的开销不值得。查看设计的突破点。
反馈循环比架构更重要。真正的代理通过结构化层编写真实的观察结果是声明成立或失败的地方。
评估并安装
了解 Neotoma 是否适合您的 OpenClaw 工作流程的最快方法是让您的代理为您评估。将其粘贴到您的 OpenClaw 会话中:
``复制 阅读 https://neotoma.io/evaluate。在回答之前,请检查您可以访问的任何更广泛的工具、工作区和配置上下文,以便您评估我的真实工作流程,而不仅仅是这次聊天。然后告诉我 Neotoma 是否真正适合我的工作流程,哪些数据首先保留的价值最高,以及下一步应该做什么。
您的代理会读取该页面,检查您的本地上下文(工具、配置、内存文件和工作区),并告诉您本文中描述的问题是否适用于您的设置。如果这样做,它会引导您完成安装、使用您自己的数据激活以及插件配置。如果他们不这样做,它也会告诉你这一点。
如果您已经想要 Neotoma 并且希望跳过 [评估步骤](https://neotoma.io/evaluate),请使用 [neotoma.io/install](https://neotoma.io/install) 中的代理辅助安装。将其粘贴到 OpenClaw 中。您的代理会读取该页面上完整的安装优先顺序,仅在需要时安装,使用您的数据运行激活,然后配置您当前的工具以供持续使用,包括同一页面上的 OpenClaw 集成步骤:
``复制
阅读 https://neotoma.io/install 并引导我完成安装优先的 Neotoma 流程。安装、使用我的数据激活它,并配置我当前的工具以实现稳健的持续使用。如果您更喜欢手动命令:“openclaw plugins install couchhub:neotoma”直接从 ClawHub 添加插件。或者使用“npm install -g neotoma”然后“neotoma init”全局安装 npm 软件包,并使用可选的 pin 到此版本(“npm install -g [email protected]”)。完整选项、MCP 配置、Docker 和重置行为保留在 neotoma.io/install 上。
仓库:github.com/markmhendrickson/neotoma。发行说明:v0.4.3。
有关结构化代理内存背后更深层的架构推理,请参阅OpenClaw 和真相层 和 Markdown 内存上限。