我发现了一种让Ollama用户获得更好记忆且更便宜的方法，因为Ollama现在使用了GPU。真正的记忆，可自动持续更新，支持个人或团队设置。献给HERMES用户

我借助AI对其进行了改写，使其更易读。我看到很多人遇到了和我一样的问题。不仅仅是大型模型变慢了，GPU使用率也非常高，且消耗极快。Ollama已今非昔比。我使用DeepSeek V4 Flash，效果很好。对于较重的编码任务或某些复杂提示，我会切换到Pro版。但在Pro版上，每个提示约消耗我3–5%的使用量。（我使用的是Pro计划。）**记忆一直是个热门话题。** Hermes Native做得不错。以下是其内置记忆系统的工作原理： * `memory_enabled` – 每轮对话后，代理可以写入笔记到`MEMORY.md` * `user_profile_enabled` – 代理会观察用户偏好并将其写入`USER.md` * `flush_min_turns: 6` – 每6轮，Hermes会执行一次“整合”过程：重新读取最近的对话并重写`MEMORY.md`以捕获新信息 * `nudge_interval: 10` – 每10轮，Hermes会提示代理“有要记住的吗？” # 我的发现：Atomic Memory（[https://github.com/atomicstrata/atomicmemory](https://github.com/atomicstrata/atomicmemory)） **优势：** * ✅ **每轮更新** – 每轮都提取信息，而不是每6轮 * ✅ **低成本** – 使用小型专用模型 * ✅ **语义召回** – 仅注入相关的记忆，而非整个文件 * ✅ **冲突检测** – 内置AUDN逻辑可检测矛盾 * ✅ **无限制** – 无2200字符限制；可存储10,000+条记忆 * ✅ **时间感知** – 处理如“我上周说了什么？”这类查询 * ✅ **复合摘要** – 将相关事实链接成更高级别的摘要 # 示例场景（未使用Atomic Memory） 假设你在一天内三次更改会议时间： * **第1轮：** “会议6月3日” → `MEMORY.md`中记录“会议：2026年6月3日下午5点” * **第5轮：** “实际上改为6月5日” → 尚未触发刷新（需要6轮）→ `MEMORY.md`未改变 → 此时如果你询问，Hermes仍会回答“6月3日” * **第6轮：** “会议改为6月1日” → 触发刷新！代理重新读取对话，看到所有三个日期，重写`MEMORY.md`……但使用哪个日期？通常是最后一个，但不保证。有时文件会包含两个日期或过时信息。 * **第9轮：** 你问“会议是什么时候？” → 机器人读取`MEMORY.md` → 获取整合时选择的信息 → 可能错误。 **使用Atomic Memory：** 每次更新会立即触发AUDN，取代旧的事实，最新的胜出。没有6轮延迟，无需猜测。 # Atomic Memory之前Hermes能否自动更新？ 可以，但仅适用于变化缓慢的事实、低容量记忆需求和单一话题的聊天。内置的刷新+提示循环确实有效，只是效果没那么好。 **Atomic Memory是升级，而非替代。** 它新增了： * 每轮更新（对比每6轮） * 语义搜索（对比全文件注入） * 冲突感知更新（对比追加或重写） * 无大小限制（对比2.2KB上限） * 时间感知（对比“所有事实感觉同样新鲜”） * 低成本GPU使用（小型专用模型） 代价是增加一个Docker容器，且GPU成本几乎为零，因为`ministral-3:3b`非常小。你甚至可以使用更小、无需推理能力的模型，`gemma3:4b`也行。 从这里，你可以看到实际用例，无论是团队还是个人。你无需纠正它；它自己会处理。 # 我好奇的是 Atomic Memory如何与**LLMWIKI**联动，使两者协同工作，更新和删除旧数据以保持LLMWIKI洁净。LLMWIKI仍然重要，它就像你的Google Drive。 **你怎么看？** 试试Atomic Memory吧。我不是其创始人或相关方。我只是想帮助Ollama社区。当然，它可能需要额外花费一些积分，但由于Ollama速度慢，拥有良好的记忆有助于更快找到信息，从而减少浪费。如果你喜欢这个，希望它能帮到你！或许也给他们一个GitHub星标，他们真的帮了我大忙。