本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 能够让AI拥有长期记忆一直是我的梦想，为此，我研究了市面上很多的记忆方案，无论是GitHub上星数破万还是社区里的佬友分享的方案，我都有在看和学习，因此我自己制作的记忆系统能够看到很多方案的影子，零零碎碎的很难致谢。 在此先放上项目的 GitHub 链接，为了公开删了不少私人内容。 github.com GitHub - Lucent-Snow/agent-knowledge-mcp: Portable Markdown memory for agents: six MCP... Portable Markdown memory for agents: six MCP tools, local and remote access, Chinese lexical search, and multi-device sync. 本项目的核心特点：简洁 本项目在公开的记忆系统里应该算是最简洁的（我研究过的范围内），核心运行代码大约六百行。（本地以 AGENTS.md 为核心的记忆系统除外） 我在设计之初就非常克制，因为我是坚定的纯文本派，会尽量少用数据库和 Embedding 模型，也不希望一个记忆系统占据太多资源，因此，记忆以 MCP 的形式提供给外界。 本记忆系统提供 6 个工具，支持本地 stdio MCP 的客户端，加一段配置即可使用： { "mcpServers": { "agent-knowledge": { "command": "npx", "args": ["-y", "agent-knowledge-mcp@0.1.0", "serve"] } } } 六个工具为： 工具 作用 knowledge_find 浏览摘要，或按标题、描述、tags、正文等词法检索 knowledge_read 正文、元数据、etag；关系作为独立字段返回 knowledge_write 创建或更新；支持精确 patch、append、replace knowledge_delete 使用最新 etag 永久删除；普通退役优先归档 knowledge_status 检查坏文档和同步冲突，不自动合并 knowledge_context 有长度上限的基础上下文，默认不含 Identity、Note 或项目正文 另外还提供多端同步和远程连接，放在后面讲。 我对记忆系统的理解 以下介绍一下我对记忆系统的理解，把思路展示给大家，大家也能理解我的设计逻辑。 许多记忆系统从跑分出发，并附上专业的名词显示自己的高大上，但我希望做减法。我认为理想的记忆系统本身一定是经得起解释的，这也是我为什么要写这么多内容，希望大家都能看懂并且提出自己的优化思路。 如何拆解记忆这个问题 记忆本质上是一类特殊的上下文。我们把会话中的上下文看作 AI 的短期记忆，而我们关心的记忆，则是跨会话、长期保存的上下文，它不会像会话内的上下文那样自动存在，需要一套机制把它放进会话。 所以想要解决记忆问题，无非就是解决四件事：记忆如何储存，如何检索，如何注入，以及附带的，如何整理。下面按这个顺序回答。 记忆的储存：Knowledge 文件格式 之所以叫 Knowledge 而不叫 Memory，是因为本项目的文件格式借鉴了谷歌提出的 Open Knowledge Format（OKF， 官方介绍 ）。OKF 的核心是一个由 Markdown 文件和 YAML 前置元数据组成的目录树（skill 也是类似的形态）。字段则是我按记忆场景自己定的，和 OKF 并不完全相同。 对传统的记忆来说，纯 markdown 分类困难，其他格式的文件人类又难以理解。我选用了这样一个对机器和 AI 都更容易阅读的格式。我之所以没有说对人类更容易阅读，是因为我知道人类是不会闲着没事看这些东西的，当然，不重要不代表不需要可阅读性。 从另一个角度说，只有你更加理解记忆的储存形式，你才能理解和预测什么时候 AI 会记住什么样的内容。 关于分层。L1-L5 这样的记忆分层很火，但说实话我没有真实理解其必要性，我只能提出我现有的分类：project、note、identity、context。之后会想办法扩展，但是肯定会从场景出发。 identity：个人相关的，默认不加载，需要时显式读取 context：通用的、反复需要的稳定约定 note：方法、经验和零碎的笔记 project：一个项目的目标、状态、决定和理由 检索：YAML 元数据 检索靠 YAML 元数据。我的想法是最大化利用每一个元数据，这些数据最好能够在机器中得到使用与自动记录。现有的包括 version、description、tags、links，以及 name 和创建、更新时间。其中 version 和时间由程序自动维护。 description 和 tags 是非常重要的两个内容，直接影响检索的过程和结果（检索也会看标题和正文）；links 则会在读取时作为关系一并返回。 举一个例子，一个叫“agent-knowledge”的项目是这样存的： --- type: project uri: memory://project/agent-knowledge name: agent-knowledge description: agent-knowledge项目的范围、状态和关键决定 tags: [memory] links: [] version: 1 --- 看不见我 之后我问"记忆或 knowledge"，检索会命中名字和描述，找到这份文档，AI 再去读正文。如果后来改了决定，更新的是同一份文档。 注入：knowledge_context 主要方式是find检索后排序，用read读取内容和元数据，还有另一个方式。 knowledge_context 工具来自一个真实场景：我有时候单纯希望 AI 能够帮我看看最近在做什么，但我的系统似乎确实缺少了一个 L1 的内容。本来这种东西写在 AGENTS.md 里面也一样，但偏偏有的 harness 连 .agents/AGENTS.md 都不会读取，并且不同平台的初始提示词注入非常迥异。 所以我想到的方法，还是由 AI 主动读取：context 下选定的内容，加上最近 30 天更新的项目description（最多 12 个，用的是yaml中的元数据）。正文仍然按需再读。 注入与整理的取舍 我的记忆系统没有内置每回合自动注入和后台整理。记忆由我和 AI 共建：AI 按 AGENTS.md 里的规则读写，我在关键节点提醒或纠正，比如在会话结束时说一句“整理一下会话中的记忆”。 之所以这么做，一方面是纯自动整理和注入的记忆令我感到厌烦，我举一个 Gemini 的例子，他会在我不希望的时候引用我的背景，这个时候的错误就会让我想我根本就不希望你保存这个记忆，我去找的时候我甚至看不到记忆的格式。无感的记忆也非常容易产生垃圾堆，你说再加个自动清理垃圾？（不学 Hermes） 另一方面是现有的 AI 确实非常厉害，我自己使用的时候，会发现大部分的 AI 都会自然地依照我设立的规则将记忆有序整理。当然这和模型有关，太蠢的模型就可能出现 memory://……v3 或者 memory://……xx年x月x日 这样的命名，如果你遇到了这种情况，请标记一下这个模型（基本上已经很少了）。 这也是为了更强的兼容性：我们无法控制 harness，但人本身是在我们的控制之内的。对于珍贵的项目记忆，我希望这一部分是人和 AI 共建的，我尽可能缩小人的摩擦，你只要做的只有在特定时候判断即可。 使用须知 在使用的时候，请关闭自己使用的 agent 的所有记忆系统，AGENTS.md 和其他的个性化指令要填一下这个记忆系统相关的内容，详见项目 README。已知有些 agent 的记忆系统写进了系统提示词，有可能出现串台，但一般问题不大。 多端同步 在 VPS 上部署好后，每台设备通过 Syncthing 同步 Markdown 副本：Mac 上聊完的项目，同步完成后就能在 Windows 上接着开发。 远程连接 在常在线的设备上运行 HTTP MCP，其他客户端连接同一个库。我自己在网页端的 ChatGPT 和 Claude 上读取记忆、聊完再更新记忆，用起来真的非常方便。 还没解决的问题 我自己使用的版本也有在尝试嵌入 embedding、jev 等更高级的工具，确实都有一定的效果：embedding 自不必说，性价比非常高；jev 则可以在某些关键记忆检索前通过排序快速筛选出置信度更高的记忆。但我目前的记忆规模下（大约 200 篇），没有出现较大的问题，欢迎大家克隆自己的分支加入一些有趣的功能。 我也实际上遇到了一些痛点，至少在我试过的记忆系统里，这些痛点都没有得到让我满意的解决。比如：我白天和某一个 AI 说了 x 任务需要完成并标明了期限，后来我已经自己完成了并且没有和 AI 对话，那么 AI 就很有可能以为这件事情还没完成并提醒你。我现有的思路是接入待办、日历等 app 来更便捷地更新记忆，但是效果一般，所以在公开版删去了。 本系统实际上更适配的是面向项目的记忆，对于纯 chat 和拟人的记忆我也在思考更优的解决方案，但现有的配置应该能满足大部分人的需求。 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/10/13 19:04:25