我构建的每个新闻阅读智能体都会永久重复获取相同文章。这是我最终采用的内存层方案。

我构建的每个涉及新闻的智能体都存在同样的缺陷：它调用新闻源，获取一组文章，使用它们，然后遗忘。下一次运行时，它重新获取，得到一组略有不同的文章，并不知道其中三分之二已经看过了。从来就没有“我已经读过关于这家公司的什么内容”这种记忆功能，而那才是我真正想要的。因此，我构建了这个内存层，而不是第五次编写那种胶水代码。设计决策比我预想的更不明显，所以在这里分享出来，以防其他人也卡在同样的问题上。去重就是全部的问题。谷歌新闻对同一篇文章会返回四五个不同的URL变体。基于URL的匹配方法在所有这些变体上都会失败。有效的做法是将规范化标题和规范化发布者名称一起进行哈希处理。注意，路透社和彭博社报道同一事件，会刻意保留为两个独立条目。两家媒体报道同一故事本身就是一种信息，合并它们会丢失信息。标题规范化还必须处理Unicode撇号变体，否则会出现人类看起来完全相同、但哈希值不同的“重复项”。在每一行存储嵌入模型信息。这是我通过麻烦的方式学到的教训。六个月后更换嵌入模型，旧向量会静默地处于不同的空间，检索会悄无声息地变差，且不会出现任何错误。现在每一行都包含模型名称和维度，这样不匹配就会明确报错。时效性应体现在排序中，而非过滤中。第一版按最近N天过滤，这意味着智能体查询某家公司时，无法看到五周前那篇解释了当前所有情况的文章。现在相似度与基于时间的指数衰减相结合，半衰期为三天。旧但非常相关的内容仍会浮出水面。所有操作保持一致。摄入、搜索、时间线、简报、情感分析、统计，全部通过Python API、CLI和MCP服务器以相同方式暴露。MCP部分比任何提示工程都更多地改变了我的使用体验。给Claude提供一个可以跨会话查询的新闻记忆，与每次将文章粘贴到上下文中是完全不同的体验。我尚未解决的问题：文章修订。发布者在第一小时内会修改标题和正文，而我的存储会保留首先捕获的版本，没有任何更改记录。上周有人向我指出了这一点，我还没有找到针对智能体记忆的干净解决方案。如果你处理过，我很想听听你的方法。存储采用SQLite加向量存储，全部本地运行。LLM步骤是可选的，指向你选择的任何提供商（包括Ollama），因此内存本身无需任何密钥即可运行。项目是开源的。根据规则3，链接放在评论区。