在 Claude Code 的生态中，记忆管理一直是开发者关注的核心议题。Letta 团队推出的 Claude Subconscious 插件采用向量数据库存储记忆块，通过 API 与后台代理交互，实现跨会话的上下文保持。然而，这种方案存在依赖重、透明度低、调试复杂等问题。与之对立的纯文本架构则提供了一条截然不同的路径：用本地 Markdown 文件构建认知记忆系统，脱离向量数据库的束缚，以文件系统为底层存储实现轻量化、可追溯的长期记忆方案。
纯文本架构的核心设计理念
纯文本认知架构的核心思想是将记忆视为结构化的文档集合，而非向量空间中的嵌入序列。这种设计源于一个简单但深刻的观察：对于代码助手的记忆需求而言，语义相似性检索并非唯一甚至不是最重要的能力。开发者更关心的是可读性、可版本控制、可搜索性以及完全透明的推理过程。Markdown 作为人类可读的结构化文本格式，天然具备这些特性。
在具体实现层面，纯文本架构通常采用 Hub-and-Spoke 模式。Hub 作为中央索引文件，包含全局性的站立指令、当前项目状态以及指向各个 Spoke 的索引指针。Spoke 则是独立的主题文件，分别承载架构决策、项目上下文、用户偏好、待办事项等特定领域的记忆内容。这种分层设计避免了单一文件的膨胀，同时保持了记忆内容的模块化和可维护性。一个典型的 Hub 文件应当控制在 200 行以内，确保每次会话启动时能够快速加载；每个 Spoke 文件则可以独立演进，按需读取。
从向量存储到文件系统：两种范式的本质差异
理解纯文本架构的优势，需要先厘清其与向量存储方案的根本区别。Letta Subconscious 依赖向量嵌入进行语义检索，每次记忆写入都需要将文本转换为高维向量，检索时则通过余弦相似度匹配最相关内容。这一过程虽然能够捕捉语义相似性，但引入了显著的系统开销：向量模型推理的算力消耗、存储空间的膨胀、以及检索结果的可解释性缺失。更重要的是，向量检索本质上是 “黑箱” 操作，开发者难以精确控制哪些记忆被激活、以何种优先级呈现。
纯文本架构则将所有记忆暴露在文件系统层面，完全透明且可调试。记忆的读取不再依赖嵌入匹配，而是基于显式的文件路径和内容匹配。这意味着开发者可以使用 grep、find 等标准工具定位特定记忆，可以通过版本控制系统追溯记忆的演变历史，还可以利用正则表达式实现精确的内容过滤。对于 Claude Code 而言，这意味着它能够 “看到” 完整的记忆来源，并在推理过程中做出更具确定性的判断。
Hub-and-Spoke 模式的工程实现参数
实现一个高效的纯文本记忆系统，需要遵循若干工程化的参数阈值。首先是 Hub 文件的规模控制：建议将 Hub 保持在 200 行以内或 50KB 以下，这确保了会话启动时的记忆加载时间控制在可接受范围内。Hub 的内容应高度抽象，仅包含全局性的站立指令、当前会话状态摘要、以及指向各 Spoke 的索引映射。每个 Spoke 文件则应当围绕单一主题构建，例如 arch-decisions.md 承载架构决策、user-preferences.md 记录用户偏好、project-context.md 维护项目上下文。
其次是记忆的更新策略。纯文本架构不追求 “记忆写入即生效” 的即时性，而是采用显式的同步机制。每次会话结束时，Claude Code 可以将本次会话的要点写入对应的 Spoke 文件，下一次会话启动时再显式读取相关内容。这种设计虽然牺牲了部分实时性，但换取了极高的可靠性 —— 记忆内容完全由开发者掌控，不存在向量检索带来的 “幻觉记忆” 问题。
第三个关键参数是 Spoke 的加载时机。推荐采用 “按需加载” 策略：Hub 在会话启动时必须加载，但各个 Spoke 仅在上下文明确指向相关领域时才被读取。例如，当用户讨论数据库设计时，系统自动加载 arch-decisions.md 和 database-schema.md；当用户提交代码审查时，系统加载 code-reviews.md 和 style-guide.md。这种懒加载机制有效控制了上下文窗口的膨胀。
与 Letta 方案的对比与选型建议
纯文本架构与 Letta Subconscious 代表了两条不同的技术路线，各有其适用场景。Letta 方案的优势在于开箱即用的向量检索能力、无需手动管理文件、以及跨设备的记忆同步（如果使用 Letta Cloud）。对于需要在多设备间保持一致的团队协作场景，向量存储方案提供了更便捷的同步机制。此外，当记忆体量达到数千条级别时，向量检索的效率优势会逐渐显现。
纯文本架构则更适合追求完全控制、透明可调试的场景。对于个人开发者或小型团队而言，本地 Markdown 文件的维护成本极低，无需支付 API 订阅费用，无需配置外部服务，所有的记忆内容都可以通过 Git 进行版本化管理。更重要的是，纯文本架构的推理过程完全可追溯 —— 开发者可以精确知道 Claude Code 读取了哪条记忆、基于哪条决策做出了判断，这对于调试和优化记忆系统至关重要。
在具体选型时，可以参考以下简化决策标准：如果记忆总量在数百条级别、需要精确控制记忆激活条件、追求推理过程的可解释性，应当选择纯文本架构；如果记忆体量预计超过数千条、需要跨设备同步、愿意牺牲部分透明度换取检索便利性，则可以考虑 Letta 方案。当然，两者并非互斥 —— 实践中完全可以将核心记忆以纯文本形式维护，同时用 Letta 处理增量记忆的语义检索。
监控与维护的实际操作清单
部署纯文本记忆系统后，需要建立一套维护机制确保记忆的有效性。首先是定期审计：每月检查 Hub 文件大小，确保未超过 200 行或 50KB 阈值；检查各 Spoke 文件是否存在内容漂移，即记忆内容与实际项目状态不再匹配。其次是版本控制：将记忆目录纳入 Git 版本控制，每次重要记忆更新都伴随有意义的提交信息，便于追溯记忆演变历史。
第三是监控指标。虽然纯文本架构不涉及向量检索，但仍然可以监控记忆的读取命中率 —— 即当前会话中实际使用的记忆条目占加载记忆条目的比例。如果该比例持续偏低，说明记忆内容过于宽泛或加载策略需要优化。最后是备份策略：尽管文件系统本身就是持久化存储，但建议定期将记忆目录备份至云端或另一台设备，防止本地磁盘故障导致记忆丢失。
纯文本认知架构为 Claude Code 的长期记忆提供了一条轻量、可控、透明的实现路径。它不依赖向量数据库的复杂基础设施，而是利用开发者熟悉的文件系统与 Markdown 格式，构建了一套结构化的记忆管理体系。这种设计理念与 PUG/U 统一认知架构中强调的 “规划、感知与行动的紧密耦合” 形成呼应 —— 记忆不再是孤立的存储单元，而是融入推理流程的可操作上下文。
资料来源：Letta Claude Subconscious (https://github.com/letta-ai/claude-subconscious)、Hub-and-Spoke Memory Pattern for Claude Code (https://unmarkdown.com/blog/hub-and-spoke-memory-for-claude-code)