最近我为 openspec 准确来说是使用了 openspec 的业务服务加上了记忆系统memeory 机制让 openspec 在 AI Coding 的过程中能够更好的利用历史对话和 spec 内容从而提高 AI Coding 的准确性和效率。原因让我想到要为 openspec 加上记忆系统的原因有两个。首先随着 openspec 的模式进行 AI Coding 越来越久我发觉很多场景下实际上并没有发挥出 spec 的价值。当你和 agent 交互的时候agent 并不是都能很好地召回 spec 的内容。它总是倾向于不依赖外部知识而是自己推理甚至宁可从代码中进行推理也不愿意从 spec 中提取信息进行推理。其次我们一直希望能让 AI 自动理解需求做出设计方案为此我们建立了不少 spec做了服务画像等但是看起来效果都不是很好。于是我想到遵循生成式 AI 的第一性原理 “大力出奇迹”。要是想让 AI 做到准确理解需求那么就要和它一起理解 n 次需求它才能在 n1 次准确理解到新的需求。于是我们想到 是否能参考 openclaw 的 memory 系统建立一套属于自己业务的 memory 系统呢想到即做到。openclaw 的 memory 机制是什么样子的呢openclaw 的 memory 核心逻辑在本地磁盘搭建一套简单的数据库围绕数据库的输入输出构建了一套 memory 系统。memory的记录它的输入包括两层文件系统全部都是以 markdown 形式进行磁盘存储MEMORY.md长期、精炼记忆事实、偏好、长期决策。每次启动新的 context 都会注入memory/YYYY-MM-DD.md按天的流水账/观察/会话摘要。今天 昨天 会在会话开始自动加载全文会被索引供检索但不会像 MEMORY.md 那样每轮都当大块上下文塞进去。memory的索引建立memory 底层可有多种 memory backend文档列了内置 SQLite、QMD、Honcho、LanceDB 等默认内置方案开箱即用。会把上述 Markdown 切成很多 chunk规模约为 ~400 tokenschunk 之间有 ~80 token 重叠。每个 chunk 会作为一条索引记录进入 按 agent 划分的 SQLite 库。对每个 chunk内置引擎同时维护全文/关键词侧FTS5BM25并对 CJK 用 trigram 分词查询侧还会 tokenize 做 BM25。语义侧若配置了可用的 embedding 提供商则对每个 chunk 的文本调用该提供商的 embedding 机制。提供openclaw memory index --force进行索引建立机制。memory的检索召回memory_core 插件提供 memory_search语义 关键词的混合检索需配置 embedding 提供商时更完整和 memory_get读指定文件或行范围。我也为 openspec 加上了 memory 系统基本上就借鉴了 openclaw 的 memory 系统稍微进行了一些改造。memory的记录借助于 cursor 的 hook 机制我埋了一个 hook每次与 agent 对话后会自动将对话内容记录到 memory 中。这里的 memory 的目录结构也稍微调整了下按照团队用户名进行划分。这里主要是考虑到我们团队有多个用户每个用户都有自己的 memory而我们共用一个工作 workspace为了避免冲突个人维护个人子目录下的 memory 即可。memory.md 公共记忆这里存储公共的记忆统一维护memory/[用户名]/YYYY-MM-DD.md 用户记忆这里存储用户个人的记忆每个用户维护自己的子目录下的 memory用户记忆的记录方式与 openclaw 的 memory 系统一致都是以 markdown 形式进行磁盘存储。在 hook 脚本中我们会尽量完整记录每轮对话但是也会做一些精简比如“代码片段” 是需要过滤的。memory的索引建立我们也是围绕数据库 sqlite 搭建自己的 memory 索引。但是由于我们的 memory 记忆目录变化所以我们建立索引的范围也进行了变化我们会将下列的文件进行索引memory.mdmemory/[用户名]/YYYY-MM-DD.mdworkspace/openspec/specs/xxx.mdworkspace/[模块]/openspec/specs/xxx.md这里可以看到我们将 openspec 在 workspace 或者子模块中产生的 spec 文件都纳入了 memory 的索引范围。并且把所有人的memory 对话也纳入了 memory 的索引范围。本意是希望 spec 提供这个需求有用的业务模块信息对话提供有用的业务历史方案。提供python scripts/memory_index.py --force进行索引建立机制。这里我们没有办法像 openclaw 一样提供 embedding 机制。究其原因 embedding 的建立需要额外的模型不管是 llm 还是 openapi。而我们的 openspec 是已经运行在一个 agentcursor中模型的管理完全是依赖 cursor所以我们并不希望再cursor 之外引入额外的模型。所以我们只使用 BM25 进行检索。memory的检索召回memory 的索引机制建立以后索引召回就同 openclaw 一样了。memory_search语义 关键词的混合检索memory_get读指定文件或行范围但是结合 openspec我在 2 个地方是做了一些改造opsx:propose 命令中我强制要求使用memory_search 进行检索召回。这样你在描述一个需求的时候就能通过召回的信息让 context 有了上下文。opsx:propose 命令中强制带上了全局 memory.md。这样就能让 agent 有所谓的“大局观”。知道这是一个什么系统。总结有记忆的 agent 才有温度。整个 memeory 的逻辑基本都是参考 openclaw 进行改造的。当然这里的索引和召回的算法逻辑肯定是不如向量化 embedding 的。特别是召回算法如何更优召回这里肯定是有很多优化空间的。但是整体架子没有问题亲自体验后感觉还是不错的。当 agent 有了记忆好像和人就差不多了。