记忆总览整理

要解决的问题

AI agent 的 memory store 会随会话不断膨胀，但真正有价值的信息——项目决策、踩坑记录、用户偏好——往往淹没在噪声里。项目完结或跨多轮会话需要复盘时，你会面临几个具体痛点：

• 重要信息散落在 memory store、sessions/*.jsonl、用户档案和外部笔记（Notion/Obsidian）之间，手动整理成本极高
• 长上下文压缩会丢 memory，Hermes 开启 compression 后聊久了关键决策被吞掉
• 多项目记忆互相污染，需要严格隔离但缺乏结构化手段
• 交付物停在"聊天完成"层面，没有一份可归档、可分享的正式复盘文档

核心能力与工作流

Memory Overhaul 用一套 8 步工作流 解决上述问题，核心理念是：memory 不进 memory，重要复盘用文档沉淀。

1. 扫描全部记忆来源 — 覆盖 memory store、sessions/ 历史记录、user profile、已有 skills 目录、外部笔记
2. 五维归类整理：

- A. 称呼/语气偏好 — 角色名、用户称谓、语气词、表情规则、正式阈值
- B. 工作偏好 — 草图风格、文档格式、迭代节奏、排版铁规
- C. 历史项目档案 — 每个项目一张卡片，记录 key_decisions / final_specs / pitfalls / cross_refs
- D. 用户原话语料库 — 触发词表与关键原话摘录
- E. 环境与限制 — 工作区路径、CDN 策略、API 节奏、压缩配置

1. 写入结构化 Markdown — 每个维度用表格或列表清晰标出
2. 生成 user_overhaul.yaml — 抽取 A/B/E 维度，供后续脚本注入页头
3. MD → DOCX 渲染 — 通过 memory_overhaul.py 转换，内置 Microsoft YaHei 中文防乱码、深蓝表头白字、分级标题排版（1 级 20pt 居中 / 2 级 16pt / 3 级 13pt / 4 级 12pt）
4. 可观察验证 — 渲染后不立刻交付，先检查文件大小与结构完整性

适用边界与注意点

• 依赖 python3 + python-docx，目标 agent 平台需支持 Python 脚本调用
• 无 skill 系统的 agent 可通过 CLI 或 API 方式调用
• YAML 多值必须用 list 写法（phrases: [A, B]），phrase: "A" / "B" 不是合法语法
• 工完 ≠ 投完：做完 docx 不算交付，必须走完"上 CDN → 发链接"两步才算真正交付
• 跨平台导入时需将整个 memory-overhaul/ 目录打包为 zip