从三层记忆到GEM记忆架构：个人助手记忆系统进化史

摘要

本文完整记录了WorkBuddy个人工作助手从三层记忆架构演进至GEM架构（Gene-Executive-Memory）的实战历程。最初的三层架构虽然成功解决了AI跨会话记忆保持问题，但随着深度使用，逐渐暴露了策略信号稀释、失败经验分散、调度机制缺失、记忆类型边界模糊四大核心缺陷。最终，GEM架构通过引入Gene方法论，将常驻注入的信息量从约6400 token精简至1720 token（降幅达73%），同时建立了显式路由表、双节点蒸馏机制和三类记忆分类管理体系，真正实现了“策略信号密度提升”与“懒加载有效落地”。

一、起点：三层记忆架构的建立与成果

1.1 问题的起源

回溯至2026年初，当时笔者频繁使用各类原生大模型辅助日常工作，却被同一个核心难题反复困扰：上下文切换成本过高。

每更换一个平台，就必须重新交代一遍背景信息，循环往复之间，30%到50%的宝贵时间就这样白白耗费在重复沟通上。所谓的“上下文”，根本无法在不同工具间顺畅流转。同样的需求，在Notion中叙述一遍，在Cline里又得重复一次，难以形成连续的工作流。各种工具各自为政，无法协同完成稍微复杂一点的任务。

更令人头疼的是那个“金鱼记忆”问题。对话窗口容量有限，话题一旦拉长，先前说过的内容就会被无情压缩或丢弃。对于那些需要持续数周甚至数月的工作项目，这套机制简直就是一场灾难。

1.2 三层记忆架构的设计

为解决上述问题，我们借鉴人类认知模型，设计了一套三层记忆架构：

其核心思想十分朴素：不要把所有的鸡蛋放在同一个篮子里。会话上下文窗口仅作为L3会话层的工具使用，而L1和L2则通过文件系统进行持久化存储，完全不受上下文窗口的限制。

1.3 核心成果

这套架构搭建完成后，确实有效解决了跨会话记忆保持的问题，并顺手沉淀出三项核心成果：

成果一：铁律体系

在工作区的根目录导航文档中注入了三条铁律：

• 根目录只允许放置文件夹，禁止存放散乱文件
• 任何预计耗时超过30分钟的工作，必须建立任务目录
• 删除操作优先使用回收站机制（以可恢复性为首要原则）

成果二：信息归属判定

建立了一套简洁好用的判断口诀：

• 定义我是谁 → 范式层（身份设定文档）
• 定义我如何工作 → 范式层（工作原则文档）
• 定义我知道什么 → 档案层（长期记忆文档）

成果三：实践验证

有两个完整的案例足以佐证其有效性：

• 商机雷达面板：48小时内从想法到系统上线
• HereNow桌面应用：4小时内从想法到可执行文件

二、问题暴露：实际使用中的四大缺陷

然而，随着系统规模的持续扩大，这套精心设计的三层记忆架构在实际应用中逐渐显露出其短板，暴露了四个根本性问题。

2.1 缺陷一：策略信号稀释

现象： 范式层的文档变得越来越长、越来越臃肿，真实的策略信息被大量背景内容所稀释。

在工作区的范式层中，存放着多个身份设定和工作原则文档。随着时间推移，这些文档不断累积各类内容，从最初简洁有力的策略方针，慢慢演变成了详细的操作说明书。

问题本质： 同样的篇幅，如果组织成“策略”则能发挥效用，组织成“摘要”则毫无价值。长篇文档反而压制了强模型固有的能力。真正起作用的只有核心的策略层面，那些背景说明、详细示例和模板填充，其实都是在不断稀释控制信号。

2.2 缺陷二：失败经验分散

现象： 关于失败经验的警告信号散落在多个文档中，有的重复出现，有的则被遗漏。

在工作区的各类文档中，散布着各种各样的“不要这样做”警告。它们可能隐藏在范式层的身份设定文档里，也可能出现在工作原则文档中，甚至工具配置文档里也有其踪迹。

问题本质： 失败经验不应原封不动地堆砌成故事，而应提炼为精炼的警告信号。一旦分散，AI就无法在关键时刻触发正确的约束机制；如果重复，则会造成注入冗余；倘若遗漏，关键风险就无人管控。

2.3 缺陷三：调度机制缺失

现象： 缺少一个统一的调度路由表，AI需要自行拼凑调度逻辑。

工作区里存放着大量详细的工作原则和技术经验文档，它们通过范式层的身份设定文档来引导加载，但始终缺少一个显式的“元路由表”。

问题本质： 懒加载最大的风险并非“存了找不到”，而是“不知道该找谁”。没有显式路由表，AI就无法知晓“开发任务→应该加载哪个文档”，懒加载机制因此根本无法真正生效。

2.4 缺陷四：记忆类型边界模糊

现象： 范式层中既包含硬约束（必须常驻的内容），又混杂着软经验（应降级为长期记忆的内容），两者相互混淆。

在工作区的工具配置文档里，既包含了技术环境的各种硬约束（例如Python路径、Node路径等必须常驻的信息），又掺杂了一些技术经验（比如PPT设计的踩坑记录、Python环境配置的经验等本应降级为长期记忆的内容），两者搅在一起，职责划分不清。

问题本质： 陈述性记忆（事实性知识）与程序性记忆（执行策略）混合在一起，导致职责模糊。硬约束应当常驻注入，软经验则应按需加载，但目前缺乏一个明确的分类机制。

三、理论突破：Gene方法论与认知科学框架

3.1 Gene方法论的核心发现

2026年4月22日，笔者在阅读清华大学的xEvoMap论文（arxiv 2604.15097）时，发现了一个关键结论：

这个结论为我们带来了几个核心洞察：

• Gene的优势不在于长度，而在于形态
• 只有策略层才是真正起作用的，背景说明、详细示例、模板填充都在稀释控制信号
• 失败经验的最佳提炼形态 = 警告信号（而非原样堆砌叙事）

3.2 认知科学框架的契合

进一步研究发现，心智系统四层模型与GEM架构之间竟然存在高度的契合性：

这里有几个关键概念值得注意：

• 晶体智力 = 优质的陈述性记忆，对应“晶体化蒸馏”过程
• 刻意练习 → 类别化 → 固定思维模式 → 共性迁移，对应“Gene蒸馏 → 匹配 → 执行”的流程

四、关键策略：GEM架构设计

4.1 架构命名与定义

GEM，全称为 Gene-Executive-Memory。

选择这个名称，一是因为三个字母简洁有力，G-E-M恰好对应了三个核心支柱。二是因为“gem”在英文中意为宝石，恰好暗合了“晶体智力”（crystallized intelligence）这一核心概念。

4.2 架构设计图

GEM架构图

4.3 与旧架构的关键区别

五、执行方案设计：Gene池与三类记忆

5.1 Gene池构建：10个策略模板

每一个Gene的结构都遵循严格规范，大约为50 token：

## Gene: [名称]
**SIGNALS**: [触发信号，逗号分隔]
**STRATEGY**: [核心策略，2-3句话]
**CONSTRAINTS**: [警告信号，如有]

本次共设计了10个核心Gene：

5.2 三类记忆分类管理

针对“记忆类型边界模糊”这一缺陷，我们建立了一套三类分类管理机制：

工具类记忆（Gene 8: ToolMemory）

• 触发时机：用户显式要求创建或安装新技能时
• 执行流程：创建/安装技能完成后，立即更新源文档，并同步至经验文档；若失败则记录在每日记录中待补
• CONSTRAINTS：A VOID: 工具类同步失败未记录

知识类记忆（Gene 9: KnowledgeMemory）

• 触发时机：完成知识密集型任务后（如研究报告、技术方案、行业分析等）
• 抽取标准：用户明确要求沉淀，或Agent判断具有长期复用价值
• 执行流程：抽取知识点 → 按命名规范生成Markdown文件 → 写入知识库 → 更新索引文件
• 命名规范：`YYYY-MM-DD_[主题]_[类型].md`（类型包括：概念/方法/经验/技术/流程）
• 目录分类：概念与方法论/ 项目经验/ 技术知识/ 工作流程/
• CONSTRAINTS：A VOID: 知识类误入Gene池。A VOID: 知识文件超过500字（需提炼精华）
• 关键设计：知识类记忆不进入Gene池，因为知识类属于陈述性记忆，而Gene池是程序性记忆（执行策略）

策略类记忆（Gene 10: StrategyMemory）

• 触发时机：用户显式要求制定策略，或Agent在任务中发现可复用的策略模式
• 确认标准：纳入长期记忆需跨3个任务验证有效，或用户明确要求长期保留。进入Gene池需满足：跨会话通用 + 高频触发 + 符合Gene结构（SIGNALS + STRATEGY + CONSTRAINTS）
• 确认流程：先向用户确认是否纳入长期记忆 → 再确认是否进入Gene池 → 用户确认后创建记忆文件 → 若进入Gene池，则更新常驻注入文档和完整定义文档
• 同步更新机制：更新常驻注入文档（Gene池部分） + 更新完整定义文档（Gene详细定义部分） + 更新警告信号汇总表（如有新约束添加）
• CONSTRAINTS：A VOID: 策略类未确认就进入Gene池。A VOID: 进入Gene池后未同步更新完整定义文档。A VOID: 用户显式要求未判定就直接存储
• 关键设计：策略类记忆与Gene池紧密关联，一旦进入Gene池，必须同步更新完整定义文档

5.3 调度路由表：显式调度机制

针对“调度机制缺失”的问题，我们建立了一个显式路由表：

这里有一条路由铁律：路由表是懒加载生效的前提条件，没有路由，AI就不知道应该去找谁。详细原文则供深度查询时使用。

5.4 双节点蒸馏机制

针对“失败经验分散”和“进化机制缺失”的问题，我们建立了双节点蒸馏机制：

六、落地修改规划与关键细节

6.1 Phase 1：Gene池构建

任务清单：

• 创建完整定义文档，写入10个Gene的完整定义
• 更新常驻注入文档：精简至约1720 token
• 更新身份设定文档：精简至约100 token
• 更新用户画像文档：精简至约100 token

关键细节：

• Gene体量需控制在约50 token，避免信息稀释
• SIGNALS需明确触发条件，避免模糊不清
• CONSTRAINTS用于统一管理警告信号，避免分散

6.2 Phase 2：晶体记忆迁移

任务清单：

• 创建晶体记忆目录
• 从各类工作原则文档中提炼核心策略 -> 生成晶体文件
• 创建归档目录
• 原文件移动至归档目录，并添加【crystal源】标记

关键细节：

• 晶体化原则：保留策略形态、删除背景稀释内容、保持可检索性、进行版本标记
• 归档源文档的说明从“历史文档警告”改为“归档说明”，强调这是“源文档”而非“历史文档”

6.3 Phase 3：三类记忆分类管理

任务清单：

• 创建知识类记忆Obsidian规范文档
• 创建知识类记忆源文档
• 更新技术经验晶体化文档（工具类记忆的同步机制）
• 在知识库中创建目录结构和索引文件

关键细节：

• 知识类记忆写入知识库：需遵循命名规范和目录分类
• 索引文件：定期更新，确保可检索性

6.4 Phase 4：长期记忆精简

任务清单：

• 审查当前长期记忆文档的内容
• 删除已在Gene中表达过的策略
• 删除已在晶体记忆中表达过的背景知识
• 保留内容：项目档案索引、里程碑、用户偏好、API配置

关键细节：

• 删除铁律汇总（已在Gene中表达）
• 精简用户偏好（删除已注入的配置信息）
• 保留项目档案索引、里程碑、每日记忆索引（核心价值内容）

6.5 Phase 5：双导航文档关系明确

任务清单：

• 更新工作区的导航文档，完整重写为GEM架构术语
• 更新根目录的导航文档，添加双导航文档关系说明

关键细节：

• 根目录导航文档 = IDE的“项目身份证”，由WorkBuddy系统生成
• 工作区的导航文档 = 个人的“工作导航”，提供快速索引和启动检查清单
• 两者互为补充，根目录导航文档指向工作区的导航文档

6.6 Phase 6：同步更新机制

任务清单：

• 同步常驻注入文档到系统注入位置
• 更新警告信号汇总表（补充Gene 8/9/10的警告信号）
• 更新每日记录（记录本次工作内容）

关键细节：

• 策略类记忆进入Gene池后，必须同步更新：常驻注入文档 + 完整定义文档 + 警告信号汇总表
• Gene 10的CONSTRAINTS明确要求：A VOID: 进入Gene池后未同步更新完整定义文档

七、结果总结：定量与定性效果

7.1 定量效果

7.2 定性效果

效果一：策略信号强度提升

从3000 token的稀释内容，压缩至1720 token的纯策略信息。Gene论文已经证明：同样的篇幅，组织成“策略”才有价值，组织成“摘要”则无效。

效果二：调度可预测

路由表显式定义后，懒加载机制真正生效。之前的问题是“不知道该找谁”，现在路由表直接告诉AI“开发任务→加载开发规范文档”。

效果三：失败经验可用

警告信号实现了统一管理，不再分散叙事。之前警告信号分散在6个文件中，现在统一整合到各Gene的CONSTRAINTS部分，触手可及。

效果四：进化自动化

双节点蒸馏机制确保了持续提炼。任务完成节点和每日压缩节点，任一触发都能推动系统进化。

效果五：认知科学对齐

GEM架构完全符合中央执行系统 + 陈述性记忆 + 程序性记忆的认知模型。这并非巧合，而是刻意设计的结果。

效果六：记忆分类管理

三类记忆（工具类/知识类/策略类）各自拥有明确的触发时机、执行流程和判断标准，彻底避免了管理混乱。

效果七：知识沉淀自动化

知识类记忆能够自动输入知识库，无需手动整理，长期积累便能形成一个高质量的知识库。

效果八：Gene池同步机制

策略类记忆一旦进入Gene池，就会自动触发常驻注入文档和完整定义文档的同步更新，确保Gene池的定义与实际运行状态完全一致。

八、核心洞察总结

洞察一：Gene的优势不在长度，而在形态

冗长的Skill包反而压制了强模型的固有能力。只有策略层真正起作用，背景说明、详细示例、模板填充，都是在不断稀释控制信号。

洞察二：警告信号是失败经验的最佳提炼形态

失败经验不应原封不动地堆砌成叙事，而应提炼为精炼的警告信号。将警告信号统一管理，不再分散叙事，效果会好得多。

洞察三：路由表是懒加载生效的前提

懒加载的最大风险并非“存了找不到”，而是“不知道该找谁”。路由表显式定义了路径，AI才能知道“开发任务→加载开发规范文档”。

洞察四：蒸馏需要双节点触发

单节点蒸馏容易造成遗漏。双节点（任务完成 + 每日压缩）的设计，确保了持续提炼，不放过任何有价值的经验。

洞察五：记忆需要分类管理

三类记忆（工具类/知识类/策略类）各有不同的触发时机、执行流程和判断标准。工具类同步到经验文档，知识类输入知识库，策略类可能进入Gene池。混淆会导致管理混乱。

洞察六：知识类记忆不进入Gene池

知识类记忆属于陈述性记忆（事实性知识），而Gene池是程序性记忆（执行策略）。两者功能不同，不应混合。

洞察七：策略类进入Gene池需要同步

策略类记忆一旦进入Gene池，必须同步更新完整定义文档，否则会导致Gene池定义与实际运行状态不一致，产生“僵尸策略”。

洞察八：知识库是知识沉淀的最佳场所

知识库提供RAG检索能力，非常适合存储知识类记忆。通过命名规范和目录分类，可以高效地组织和检索知识。

结语

回顾整段进化旅程，三层记忆架构确实解决了AI跨会话记忆保持的问题，但也暴露了策略信号稀释、失败经验分散、调度机制缺失、记忆类型边界模糊这四大缺陷。GEM架构通过引入Gene方法论，最终实现了：

• 常驻注入精简：从约6400 token → 约1720 token（降幅达73%）
• 策略信号密度提升：从3000 token的稀释内容 → 1720 token的纯策略
• 调度可预测：路由表显式定义，懒加载真正生效
• 失败经验可用：警告信号统一管理，不再分散叙事
• 进化自动化：双节点蒸馏机制，确保持续提炼
• 记忆分类管理：三类记忆各有明确的运作机制
• 知识沉淀自动化：知识类记忆自动输入知识库
• Gene池同步机制：策略类进入Gene池后自动同步完整定义文档

当然，这远不是终点。产品在不断迭代，WorkBuddy也在持续进化，从工具变为伙伴，再从伙伴走向生态。作为使用者，如何善用不断更新的机制，将是一场持久的挑战。

文档附注

本文完整记录了笔者在VibeWorking过程中，从三层记忆架构向GEM架构演进的真实历程。现将其开放出来，希望能给同样在摸索中的开发者带来一些启发。如果工程文件和实践细节能让更多人参与讨论，那就更有价值了。