核心功能与用法
持久记忆引擎是一套面向AI Agent的本地分层持久记忆系统，完全运行于用户主目录的~/memory/路径下，与Agent内置记忆并行运作且永不冲突。其核心设计围绕无限分层结构化存储展开——用户可自定义projects/、people/、decisions/、knowledge/等分类，每个条目以独立Markdown文件存储，支持完整的frontmatter元数据（状态、版本、重要度、标签、关联条目、过期时间）。
系统采用三层索引体系实现高效检索：根索引INDEX.md→分类索引{分类}/INDEX.md→条目文件，确保即使500+文件规模也能O(1)定位。检索策略智能分层：小规模（<50文件）直接用grep全文搜索，中等规模（50-500）走索引导航，超大规模（500+）建议接入可选的向量数据库（Chroma/LanceDB/Qdrant）实现语义检索增强。
记忆生命周期管理是另一核心机制：条目经历"写入→激活→归档→遗忘"四阶段，90天未更新提示归档，180天无引用提示遗忘，过期条目移入.trash/保留30天可恢复。写入时自动执行冲突检测与版本化，发现同主题矛盾时保留旧版本并递增version，主动提示用户确认而非静默覆盖。
显著优点
架构隔离性：完全独立于Agent内置记忆，单向读取、永不修改MEMORY.md或workspace memory/，避免系统级冲突。内置记忆负责当前会话快速上下文，本系统承载长期深度知识，两者协同互补。
零依赖轻量化：核心功能仅需操作系统自带的grep/find/cat/mkdir/echo，无需API Key，无需网络请求，纯本地运行。语义检索增强为可选依赖，按需接入即可。
工程化可维护性：三层索引+分类自动分裂（单类>100条目自动拆分）应对规模膨胀；版本化冲突管理保留完整决策历史；周期性维护机制（周/月回顾）确保系统长期健康。
多场景适配：覆盖长周期项目记忆、人脉网络管理、决策推理归档、领域知识库构建、收藏清单管理等典型场景，特别适合需要跨会话、跨项目保持上下文连续性的知识工作者。
潜在缺点与局限性
无原生云同步：所有数据本地存储，多设备同步需用户自行配置Git或云盘，且本技能不处理同步冲突。这在移动办公场景下可能成为门槛。
维护依赖人工：归档、分裂、冲突合并等生命周期管理需要用户在周/月回顾中主动确认，完全自动化决策可能误判（如错误归档仍在引用的条目）。
语义检索门槛：超大规模场景下关键词检索召回率有限，但向量数据库配置需要额外技术投入，对非技术用户不够友好。
单向数据流动：仅支持从内置记忆单向同步至本系统，反向永不修改。这意味着内置记忆中的临时上下文不会自动沉淀，需要用户主动触发同步。
适合的目标群体
- 独立开发者/技术博主：管理多个并行项目的技术决策、依赖版本、踩坑记录
- 产品经理/项目经理：追踪长周期需求变更、决策依据、干系人信息
- 研究者/终身学习者：构建个人知识库、文献笔记、概念图谱
- 销售/BD人员：维护客户关系档案、互动历史、偏好记录
- 任何需要跨会话保持上下文连续性的AI重度用户
使用风险与注意事项
性能风险：虽然三层索引保障O(1)定位，但未接入向量检索时超大规模（500+文件）的全文grep可能产生延迟。建议单分类超过100条目时主动分裂子分类。
数据安全风险：系统明确禁止存储API Key、密码等敏感凭证，但用户仍需自行确保~/memory/目录的本地访问权限。多设备同步时注意.gitignore配置，避免.trash/等敏感目录误提交。
数据一致性风险：索引与条目文件可能因写入中断不同步，需定期执行维护流程检查INDEX.md完整性。建议配合Git版本控制实现备份与恢复能力。
认知负荷风险：过度分类或过度版本化可能导致信息碎片化，建议遵循"写入前预检→定期归档→月度清理"的节奏，避免记忆系统本身成为管理负担。