给 AI 装个大脑：RecordKeeper 记忆系统实战

你是不是也有过这样的经历——

周一早上打开电脑，脑子里一片空白：上周那个需求评审到底定了什么？Badcase 处理到哪一步了？老板上周交代的计划，截止日期是哪天？

你翻了微信聊天记录、飞书消息、本地笔记、邮件……花了 20 分钟才拼凑出全貌。然后发现，还漏了一条。

这不是记忆力问题，是工作记忆管理的问题。

更关键的是——如果你在用 AI Agent 辅助工作，它比你更惨：你没告诉它的，它一概不知。

今天我分享一套实际在用的方案：RecordKeeper —— 一个语义化的工作记忆系统。它不是又一个笔记工具，而是让 AI Agent 拥有"记住-回忆-关联"能力的完整基础设施。

AI Agent 的"失忆症"

现在大家都在用 AI Agent 提效。但有一个根本性的问题被忽略了：

AI Agent 的记忆是会话级的。

对话一关，它就忘了。下次你问"上周那个 Badcase 怎么样了"，它一脸茫然。

这不是模型能力的问题，而是信息架构的问题——你没有一个系统化的方式把工作内容"喂"给 Agent。

传统的解决方案是什么？写文档、建 Wiki、用 Notion。但这些工具的设计对象是人，不是 AI。人能通过浏览目录、搜索关键词、翻看历史来找回信息。AI 需要的是结构化的、语义化的、可直接消费的数据。

RecordKeeper 就是为此而生的。

记录是为了被找到

RecordKeeper 的核心设计哲学只有一句话：

记录是为了被找到，不是为了存档。

这决定了它和传统笔记工具的根本区别：

它由三个核心机制组成：分类体系让 AI 知道"这条记录是什么"，状态流转让 AI 知道"这件事进展到哪了"，向量索引让 AI 能"联想"和"回忆"。

三者配合，再加上 Cron 自动化定时任务，形成了一套完整的工作记忆闭环。

13 类分类：给 AI 一个明确的判断空间

分类是 RecordKeeper 的骨架。

为什么不用自由标签？因为自由标签对 AI 来说等于没有标签。人看到"需求评审"能猜到是会议还是文档，AI 不行。它需要一个明确的、有限的、互斥的分类空间。

经过反复实践，我们收敛到 13 个类别：

这里有一个关键的设计决策：分类是严格封闭的，不允许随意新增。这不是偷懒，而是刻意的约束——分类越少，AI 的判断越准确。当分类空间开放时，AI 会在相似类别之间犹豫，导致归类错误。封闭空间迫使 AI 做出明确选择。

边界判定：当分类变得模糊

"需求评审会"是 meeting 还是 requirement？

规则很简单：记录的是讨论过程就归 meeting，记录的是产出的文档/结论就归对应类别。

这个判定规则看似简单，但在实践中解决了很多混淆。比如，季度评审会本身是 meeting，但会后整理的下季度规划是 plan；技术方案如果是零散笔记就归 memo，如果整理成标准作业程序就归 sop。

文件命名：让文件名成为第一层索引

RecordKeeper 的文件命名遵循固定格式：

[YYYYMMDD]-[category]-[topic]-[sub-topic]-[seq].md

示例：

• 20260707-meeting-搜索服务季度评审.md
• 20260707-task-第三方合作对接-001.md
• 20260703-weekly-report-W27.md
• 20260625-quarterly-report-2026-Q2.md

文件名本身就是第一层索引。AI 不需要打开文件，就能通过文件名判断类别、时间、主题。这是刻意为 AI 优化的设计——降低检索成本。当向量索引不可用时，文件名匹配可以作为有效的降级方案。

5 个状态：追踪任务的生命周期

分类解决"是什么"，状态解决"怎么样了"。

RecordKeeper 定义了 5 个严格封闭的状态值：

为什么只有 5 个？因为状态是给 AI 做判断用的。状态越多，AI 的决策树越复杂，出错概率越高。

这里有一个核心设计：唯一完成态。查询"未完成"只需要 status != 'done'，不用关心中间态。这一个设计决策，省掉了无数边界条件判断。

注意 done 是终态，不可逆。如果需要修改已完成的任务，应该创建新版本记录，而不是退回修改。这个设计保证了历史记录的可追溯性。

状态归一化：理解人类的模糊表达

用户说"搞定了"，AI 要知道这是 done。用户说"先放着"，AI 要知道这是 deferred。

RecordKeeper 维护了一张归一化映射表：

这层抽象让 AI 能准确理解人类的模糊表达，同时保持系统内部的状态一致性。没有这层映射，AI 需要每次都做语义理解，既慢又容易出错。

向量索引：让 AI 学会"联想"

分类和状态解决了结构化查询的问题。但真实场景中，用户的提问往往是非结构化的：

• "上次那个机场的 Badcase 怎么处理的？"
• "那个第三方对接的项目最近有什么进展？"
• "关于标准协议我们讨论过什么？"

关键词搜索能解决一部分，但语义模糊时就力不从心。这就是向量索引的价值。

技术选型

RecordKeeper 使用 BAAI/bge-m3 作为嵌入模型，生成 1024 维向量。存储层选择 SQLite，轻量且易于备份。API 平台使用硅基流动 (SiliconFlow)。

这里值得单独说一下硅基流动（SiliconFlow）——它提供了 BGE-M3 嵌入模型的免费调用额度，对于个人使用完全够用。你只需要注册一个账号，获取 API Key，就能直接调用。如果你也想搭建类似的系统，可以通过这个链接注册：

🔗 硅基流动邀请注册：https://cloud.siliconflow.cn/i/UWKqeb6g

注册后即可获得免费额度，足够支撑个人日常使用。对于大多数个人用户来说，这个免费额度可以覆盖数月甚至更长时间的使用。

三级检索降级

当用户提问时，RecordKeeper 按以下优先级检索：

向量搜索是首选，文件名匹配和 grep 只是降级方案。这确保了语义模糊的查询也能命中。

为什么要设计三级降级？因为向量索引依赖外部 API，可能因为网络问题或额度耗尽而不可用。在这种情况下，文件名匹配和全文 grep 可以作为兜底方案，保证系统始终可用。

增量更新：只处理变化的部分

向量索引支持基于文件哈希的增量更新——只处理新增或变更的文件，跳过未变更的。数百个文件的索引，增量模式下只需处理变更的 1-2 个，耗时从分钟级降到秒级。

这个设计很关键。如果每次更新都全量重建索引，随着文件数量增长，更新耗时线性增加，最终变得不可用。增量更新让系统可以长期稳定运行。

自动化闭环：从被动记录到主动推送

到这里，我们有了结构化的记录、可检索的索引。但还有一个问题：人不会主动来问。

真正高效的系统不是"你问它答"，而是"它主动告诉你"。

这就是 Cron 定时任务的价值。Agent 配置了 5 个自动化任务，覆盖了从高频提醒到年度报告的完整周期。

每 15 分钟任务提醒

调度规则：*/15 9-11,13-20 * * 1-5（工作日 9-11 点、13-20 点，每 15 分钟）

这是最高频的自动化。Agent 会：

• 查询今日会议（文件名匹配 + 向量搜索双保险）
• 查询未完成任务（SQLite 按 status 过滤）
• 查询今日完成任务（按 updated_at 过滤）
• 生成"今日聚焦"（最多 3 项最紧急的）
• 生成"动态"（对比昨日状态的变化量）
• 推送全量清单（逾期 → 今日截止 → 本周截止 → 后续 → 长尾备忘）

这里有一条铁律：禁止编造任务。输出中的每一条必须来自 SQLite 查询结果。AI 的幻觉在任务提醒场景是不可接受的——你不想被提醒一个根本不存在的任务。

周报自动生成

调度规则：30 20 * * 6（每周六 20:30）

Agent 会检索本周所有记录（日期范围 + 向量语义搜索 + memo 思考记录三路合并），读取每个文件全文，生成包含以下内容的完整周报：

• 本周概览（数据表格）
• 重点成果（已完成 + 进行中）
• 会议与决策
• 问题与风险
• 下周计划
• 本周反思/洞察（2-4 条深度洞察，基于 memo 中的思考提炼）

周报不是任务清单的罗列，而是有洞察、有判断、有上下文的复盘报告。这一点很重要——如果只是罗列任务，那和直接查数据库没有区别。周报的价值在于把散落的记录串联成有逻辑的叙事。

月报 + OKR 进度

调度规则：0 21 25 * *（每月25日 21:00）

在周报基础上，叠加季度 OKR 进度追踪。Agent 会读取 OKR 文件，逐项评估完成度，用 🟢🟡🔴 标记状态。

月报的意义在于中期校准。周报太细碎，季报太宏观，月报刚好可以回答"这个月的方向对不对"这个问题。

季报 + 下季规划

调度规则：30 21 25 3,6,9,12 *（每季度末 21:30）

从月报和周报中提炼季度数据，做环比分析，评估 OKR 完成情况，并给出下季度 OKR 草案建议。

季报是战略层面的复盘。它不关心具体任务，而关心方向是否正确、资源是否合理、风险是否可控。

年报

调度规则：0 22 25 12 *（每年12月25日 22:00）

全年大事纪、季度 OKR 汇总、业务数据年度趋势、下年度方向建议。

年报是历史档案。一年后回看，你可能不记得具体做了什么，但年报会告诉你这一年发生了什么、学到了什么、下一年应该做什么。

自动化全景

从记录到索引，从索引到自动化，从自动化到推送——这是一个完整的闭环。每一层都为下一层提供输入，每一层都依赖前一层的输出。

实战效果

这套系统运行了 3 个月，一些直观的变化：

检索效率：以前翻聊天记录 + 本地文件，平均 15-20 分钟找回一条信息。现在向量搜索，3 秒内命中，准确率 > 90%。

任务遗漏率：以前每周至少漏掉 1-2 个待办。现在 15 分钟一轮提醒，零遗漏。

周报/月报：以前周五下午花 1-2 小时回忆、整理。现在周六自动推送，只需审阅确认。

最意外的收获：memo 类记录的"洞察复利"。技术思考、Badcase 处理经验、架构决策，都被结构化地记录下来。周报的"反思/洞察"部分会自动提炼这些内容。三个月后回看，形成了一条清晰的技术思考脉络。

这种"复利效应"是被动记录无法实现的。如果你只是把东西写在本地文件里，三个月后它们就是一堆散落的文件。但如果有结构化分类 + 自动提炼，它们就变成了一条知识脉络。

给想复制这套系统的你

几个关键经验：

分类要少，不要多。 13 类看起来不少，但每一类都有明确的边界。如果你的分类超过 20 个，AI 的判断准确率会显著下降。

状态要封闭，不要开放。 5 个状态值，严格限制流转方向。不要让用户或 AI 随意创造新状态。

向量索引必须即时更新。 写入文件后必须立即更新索引。延迟更新 = 信息丢失。这是铁律。

自动化是闭环的关键。 没有自动推送的记录系统，最终会变成"写了但从不看"的坟墓。Cron 定时任务把被动记录变成了主动推送。

禁止 AI 编造。 在任务提醒场景，AI 必须严格基于数据库查询结果输出。宁可漏报，不可误报。

向量检索可以零成本起步。 硅基流动（SiliconFlow）提供 BGE-M3 嵌入模型的免费调用额度，个人使用完全够用。注册即可获取 API Key：https://cloud.siliconflow.cn/i/UWKqeb6g

写在最后

RecordKeeper 的本质，是给 AI Agent 装上了一个外置的工作记忆皮层。

它不性感，不花哨。它是一套由分类体系、状态流转、向量索引、自动化推送组成的基础设施。

但正是这套基础设施，让 AI 从"对话完就忘"变成了"持续跟进、主动提醒"。

好的工作流不是让你更努力，而是让你不遗忘。

如果你的 AI Agent 还在"失忆"，也许问题不在模型，而在你没有给它一个好好记忆的地方。