一念不落，万象可循：YOLO 的记忆系统实现

1.储存格式：markdown+列表式#

我最早考虑过的方案是 YAML Frontmatter + 三段式结构：属性区存键值对、用 checkbox 当事实库、末尾追加日志。这种方案对通用 chatbot，或者更复杂的商业化 Agent 项目来说还行，但对 YOLO 来讲有点过度设计了。三套东西各自需要不同的解析逻辑，维护起来很烦，而且对用户来说也不直观。

因此，最终我选的方案是纯列表式：一条记忆一行，- 开头，存在 YOLO/memory/global.md 文件里，和 YOLO/skills/ 同级。理由有三个：

1. 注入成本最低。 读记忆文件内容，塞进 <memory> 区块完事，不需要任何解析逻辑。
2. 工具封装最自然。 列表结构天然对应增删改三种操作，插件层可以轻松封装出专门的记忆工具，模型只管传参，格式维护、编号分配这些脏活全由底层处理。
3. 用户一目了然。 打开这个文件就能看到 AI 记住了什么，想删就直接删一行，零学习成本。

2.文件结构：分区 + 编号#

纯列表解决了格式问题，但如果 50 条记忆全摊在一起，用户看着会有点乱，AI 在管理时也缺乏抓手。所以在纯列表的基础上，我加了两层组织：分区和编号。

实际的记忆文档长这样：

1
# User Profile
2
> Long-term characteristics about the user. Update when user info changes.
3

4
- Profile_1: 用户叫xxx，今年 xx 岁，毕业于 xxx
5
- Profile_2: 用户正在开发 YOLO 插件，这是一个 Obsidian 的 AI 助手
6

7
# Preferences
8
> User's interaction preferences and behavioral patterns. Add when patterns emerge.
9

10
- Preference_1: 不喜欢对话结尾追问或反问
11
- Preference_2: 不要出现"不是……，而是"的句式
12
- Preference_3: 不要使用破折号
13

14
# Other Memory
15
> Contextual facts and temporary notes. Default category.
16

17
- Memory_1: 2025-03-15 开始设计 YOLO 的记忆系统
18
- Memory_2: 用户习惯深夜工作

三个分区各有定位：

• User Profile 放用户的长期特征，身份、背景、正在做的事。这类信息相对稳定，变更频率低。
• Preferences 放交互偏好和行为规则。用户纠正 AI 的行为（「不要用破折号」）、表达的格式偏好、沟通风格要求，都归这里。
• Other Memory 是默认分区，放不好归类的上下文性信息、临时性事实、带时间标记的事件。AI 添加记忆时如果不确定该放哪个分区，就往这里丢。

每条记忆有一个编号（Profile_1、Preference_3、Memory_2），编号在分区内独立递增，不重用。删掉 Profile_2 之后下一条新增的是 Profile_3，不会回填。这个设计的核心好处是：AI 在更新和删除记忆时只需要指定编号，不需要输出旧的全文内容做匹配。从 memory_update(id="Preference_2", new_content="...") 到定位具体是哪一行，这件事变得确定且廉价。

3.双重记忆：全局 + Per-Assistant#

上面展示的文档解决了一个助手记什么、怎么记的问题，但 YOLO 支持多助手配置，用户可能同时拥有一个日常陪伴型助手、一个整理文档的秘书型助手、一个写报告的分析助手。这些助手的角色定位完全不同，它们需要记住的东西也不一样：陪伴助手需要记住你们之间的互动默契，工程助手需要记住你的偏好和项目上下文，分析助手需要记住你的写作风格和报告规范。如果所有记忆都塞在同一个文件里，不同角色的信息会彼此污染，还浪费 token。

所以 YOLO 的记忆系统分两层：全局记忆（Global Memory）和助手记忆（Assistant Memory）。所有记忆文件统一放在 YOLO/memory/ 目录下，全局记忆是 global.md，每个助手的记忆以助手名命名，比如 helper.md、dev-helper.md。

文件结构如下：

1
YOLO/
2
├── memory/
3
│   ├── global.md         ← 全局记忆，所有助手共享
4
│   ├── helper.md            ← Helper 的专属记忆
5
│   ├── dev-helper.md      ← 工程助手的专属记忆
6
│   └── ...

全局 global.md 只放跨助手通用的信息：用户身份、年龄、职业、全局格式偏好（不要破折号、不要追问）这些不管哪个助手都需要知道的东西。分区结构和前面介绍的一样，三个区不变。

Per-Assistant 记忆文件 则放只跟当前助手角色相关的记忆，分区可以由助手自行组织。比如一个工程助手 dev-helper.md 可能长这样：

1
# Project Context
2
- Proj_1: YOLO 插件用 TypeScript 开发，基于 Obsidian API
3
- Proj_2: 记忆系统设计已完成，正在实现工具层
4

5
# Code Preferences
6
- Code_1: 偏好函数式风格
7
- Code_2: 不要过度抽象，能跑就行

对话开始时，插件把两层记忆合并注入 system prompt：

1
<memory>
2
<global>
3
{global.md 的内容}
4
</global>
5

6
<assistant>
7
{当前助手记忆文件的内容}
8
</assistant>
9
</memory>

用 <global> 和 <assistant> 标签分开，模型能清楚地区分哪些是所有助手都要知道的通用信息，哪些是只属于当前助手的上下文。

有一个边界处理：如果用户只用默认助手（没有自定义 assistant_instructions），就不需要创建 per-assistant 记忆文件，直接退化到单层全局记忆。插件层做个判断就行，对轻度用户零负担。

触发策略：谁来决定「该记了」？#

最偷懒的做法是完全靠模型自觉，在 system prompt 里写一句「当你发现重要信息时请保存记忆」，然后祈祷它的判断力在线。这在目前旗舰 chat 模型上其实也能用，但不够稳定，你可能会碰到两种很典型的翻车：一种是该记的没记，用户说了三遍自己的名字 AI 还是没调用 memory_add；另一种是不该记的疯狂记，每句话都触发一次存储，记忆文件很快变成垃圾场。

当然有的模型实在是比较粪，我作为开发者其实也真的没有办法适配每一个模型的 taste，遑论大家的渠道五花八门的，有的可能是纯净官方 api，有的可能是 Claude code 乃至 kiro 逆向的，还有的可能是直接从 ChatGPT 官网逆向下来的 api，实在是众口难调。

YOLO 的做法是在 system prompt 的角色设定（assistant_instructions）里显式写明记忆行为的规范。具体来说是两条：

1. 「你会主动使用记忆工具来新建/更新你的记忆。」 这是正向引导，告诉模型记忆操作是你的本职工作，不是可选项。
2. 「你会定期删除已经冗余的无用记忆。」 这是反向约束，防止只增不删导致膨胀。

注意，这里没有规定具体的触发条件（比如「每 10 轮检查一次」或「当用户提到个人信息时」），因为这种硬编码规则反而会让模型的行为变得僵硬。实际测试下来，只要在角色设定里把「该记」和「该清理」这两个意识植入了，模型在大多数场景下的判断力是够用的。它会在用户自我介绍时自动存 profile，会在被纠正行为时自动存 preference，也会在发现两条记忆说的是同一件事时主动合并。

去重与冲突：AI 自己判断，还是插件层兜底？#

一个很自然的问题：如果 AI 想新增一条记忆，但记忆文件里其实已经有一条语义相近的了，怎么办？

比如记忆里已经有 Profile_1: 用户叫无敌暴龙兽，今年 21 岁，然后用户在新的对话里又提了一嘴自己的年龄，AI 是应该 memory_add 一条新的，还是 memory_update 已有的那条？

YOLO 的答案是：完全交给 AI 判断。 因为前面说过，记忆是全量注入的，AI 在每轮对话里都能看到所有已有记忆。它有足够的信息来决定「这条信息已经存在了，我应该更新而不是新增」。在 system prompt 里补一句「当一条记忆已经过长时，请不要再往里加新的内容了，请新建一条记忆」，就能覆盖绝大多数边界情况。

插件层不做语义去重。原因很简单：要做就得引入 embedding 和相似度计算，工程复杂度直接翻倍，而收益几乎为零。50 条以内的记忆，模型看一眼就知道有没有重复，比任何 cosine similarity 阈值都靠谱。

把上面这些串起来，一次典型的记忆操作流程是这样的：

1. 对话开始，插件读取 memory.md 全文，注入 system prompt 的 <memory> 区块
2. 用户在对话中提到：「对了我最近换工作了，现在在做独立开发」
3. AI 看到 <memory> 里已有 Profile_2: 用户正在做 XX 项目，判断这条需要更新
4. AI 调用 memory_update(id="Profile_2", new_content="用户目前是独立开发者")
5. 插件定位到 Profile_2 所在行，替换内容，保存文件
6. 工具返回成功，AI 继续对话，不需要特别告知用户（除非用户主动问「你记住了吗」）

整个过程对用户来说是无感的。如果用户好奇 AI 记了什么，打开 YOLO/memory.md 就能看到，想手动改也随时可以改。