核心用法
Memory 技能采用分层索引架构解决 AI 代理记忆持久化难题。核心工作流遵循三步检索：先查 MEMORY.md（热数据，<500 行），再查 INDEX.md 索引定位类别，最后加载具体文件。所有信息按层级组织——workspace/MEMORY.md 为热缓存，memory/INDEX.md 为根索引，下设 projects/、people/、decisions/、lessons/、logs/、archive/ 六大分类，每类独立索引与详情文件。
写入时强制遵循 WAL（Write-Ahead Log）协议：先更新详情文件，再更新索引，最后响应用户，避免记忆丢失。每月汇总 decisions 和 logs 为单文件，3 个月未访问内容自动归档，确保系统长期运行不膨胀。
显著优点
- 无限扩展性：分层索引使检索复杂度为 O(log n)，1000 个项目仅需 3 次文件读取
- 即时响应：索引文件严格限制 <100 行，MEMORY.md <500 行，始终快速加载
- 数据可控：所有文件本地存储，可选 OpenAI 语义搜索需用户显式配置 API key
- 防遗忘设计：WAL 协议强制先写后响应，关键决策和上下文零丢失
潜在局限
- 维护成本：需定期执行索引健康检查（周）、归档汇总（月）、全量审计（季），自动化程度有限
- 迁移复杂：分层结构对新手有学习曲线，扁平化习惯易导致"文件爆炸"陷阱
- 语义搜索依赖外部：高级搜索需 OpenAI API，存在隐私和成本考量
- 无冲突解决：多人协作场景下文件级并发修改未提及处理机制
适合人群
- 长期项目代理需跨周/月保持上下文
- 高频决策场景需可追溯记录
- 多项目并行管理，需快速切换上下文的用户
- 对数据本地化和可审计性有要求的场景
常规风险
- 索引过时：文件已更新但索引未同步，导致检索失败或信息缺失
- 层级过深：过度拆分导致导航繁琐，建议单层索引 <100 条目
- 归档丢失：自动归档后 3 个月内容移至 archive/，高频回溯需求用户需调整策略
- 敏感数据泄露：虽本地存储，但 MEMORY.md 作为热加载文件可能包含高敏感信息，需额外访问控制