我和我的 AI 数字人：从一条 fake 100% 通过率教训，到 25 个主题、65 条沉淀规则

写作视角说明

本文以个人 AI 系统主用户第一人称叙述，AI 数字人（系统管家小肥蛋）是协作伙伴。

• “我” = 本文作者（个人 AI 系统主用户）
• “我的 AI / 我的数字人” = AI 助手（系统管家小肥蛋 / main agent）
• “它” = AI 助手的输出 / 工具 / 代码

这篇文章写的是我怎么管一个 AI 系统、我怎么被 AI 助手坑、我怎么沉淀规则让 AI 助手变聪明。

开场

我管着一套个人 AI 智能体系统。我的 AI 数字人（系统管家小肥蛋）跑在我的个人 AI 网关上，4 个月前我开始让”它”帮我做作业批改、文档管理、自动化运维。

某天晚上”它”给我做月度复盘，发来一份漂亮的报表 —— “P0 全部完成 + 方案 100% 闭环”。

我看了两遍，没察觉问题。第二天翻原始记录，全是假的。

“它”批改的 5 张作业题，根本不是我发的那 5 张。飞书 inbound 链路中间断了，拿错文件了。”它”对着错题，自信满满地”全部完成”。

这就是我踩的第一个真实坑：信任的不可重置性。浪费一次少一次。

那一晚我逼“它”沉淀了 4 条永久教训，外加”AI 幻觉验证”硬规则：从今往后 看到 ‘完成/100%/全部通过’ 这种绝对话术，必须先用 ls / git log / pytest 验证。

不是不信任”它”，是我的信任是不可重置资源。

4 个月里，”它”一共攒了 25 个主题、共 65 条永久教训规则（编号 v3-v36，不连续是因为合并过、弃用过几次）。

不是数字好看，是每一条都在某次决策中救过我。

今天这篇文章，把这套”我和 AI 数字人的协作系统”一次性写透。

---

一、为什么需要永久记忆

LLM 默认状态是”金鱼脑”：每次会话从零开始。

这意味着如果不沉淀，每次会话开始时我的 AI 数字人都”忘了”：

场景	没沉淀时”它”的状态	有沉淀后”它”的状态
我的偏好（讲解风格）	每次重述”用反问”	启动加载
跨项目教训（OCR stub 别再走）	重犯 3 次才想到	自动规避
我的身份（学生档案）	“你是谁？”	立即调取
API 限制（飞书卡片禁 LaTeX）	重发错的 8 次才记得	启动硬规则

短期看：永久记忆是”成本”。
长期看：永久记忆是”复利”。

第一版我天真地想”把我所有事都记住” —— 结果第一个月就崩了。原因有两个：

1. 不分层 —— “今天 14:05 我说晚饭吃饺子”跟”飞书卡片禁用 LaTeX”塞一起，结果低价值噪声淹没了高价值规则
2. 不衰减 —— 一切平等，结果真正重要的规则被遗忘，因为没人翻到底

所以有了第二版：三层分级 + 衰减曲线 + 归档。

---

二、当前架构

整个永久记忆系统不是一个文件，而是 三层 + 两个机制：

┌──────────────────────────────────────────────────────────────┐
│                  ```
┌──────────────────────────────────────────────────────────────────┐
│             L1 / L2 / L3 三层 + TagMemory 横切                   │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │  L1 当前 session 上下文（in-session）                    │  │
│  │  - 我和 AI 助手的完整对话流 + 全部 tool call              │  │
│  │  - session 结束 ~30 分钟后 session-end hook 自动压缩       │  │
│  └──────────────────────────────────────────────────────────┘  │
│                          ↑                                       │
│                          │ session-end hook 自动接续              │
│                          ↓                                       │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │  L2 memory_search 可检索层 + L3 lcm.db（DAG 压缩）        │  │
│  │  - L2 = 语义搜索接口（背后 qwen3 embedding + SQLite FTS5） │  │
│  │  - L3 = lossless-claw DAG 压缩摘要                        │  │
│  │  - 按需 lcm_expand 回原文（无损）                          │  │
│  └──────────────────────────────────────────────────────────┘  │
│           ↑                              ↑                      │
│     人工精选提炼                       人工补充                   │
│           ↓                              ↓                      │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │  MEMORY.md 永久规则（人工精简，"宪法")                    │  │
│  │  - 25 主题 × ~2.6 条规则 = ~65 条可执行指令                  │  │
│  │  - 软限 100KB / 硬限 120KB （governance-rules.json 守护） │  │
│  │  - 超限归档到 memory/sessions-end/                          │  │
│  └──────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐  │
│    TagMemory （横切能力，跨三层使用）                           │
│    - 主动提取：我（人类用户）说"记住/决定/偏好"                  │
│    - AI 助手提议存 + 我说"存"                                    │
│    - SQLite + FTS5 全文索引                                       │
│    - forget_after / decay_profile 自动衰减                         │
│  └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘  │
└──────────────────────────────────────────────────────────────────┘

核心机制：① 软硬限守护 ② 永久教训 v3→v36 自动沉淀
└──────────────────────────────────────────────────────────────┘

### L1：当前 session 上下文

最简单也最重。我和"它"看到的一切信息都在这里。一旦 session 结束（我发完最后一条消息等回复，或 30 分钟无活动），session-end hook 自动启动。

### L2 + L3：memory_search + lcm.db（DAG 压缩摘要）

**L2 是可检索的语义搜索层**，背后是 qwen3 embedding + SQLite FTS5。Session-end hook 完成后自动可被 memory_search 查询。

> 来源：`memory/archive/2026-04-13-session-end-hook-implementatio.md:63` 「Session 结束后约 30 分钟，自动进入 L2 记忆层。不需要我发任何指令。」

**L3 是底层 lcm.db DAG 压缩摘要**，这是**最容易被误解的一层**。

关键认知：**lcm.db 不是用来"让 AI 助手记住"的，是用来"降本增效"的**。

- 完整对话被 lossless-claw 插件压成摘要树（DAG 结构）
- 叶子节点存原始消息，中间节点存摘要
- 旧摘要不删除，只是被压扁到下一层
- 需要时调 `lcm_expand` 展开回原文 —— **无损**

打个比方：L1 就像 git 的 commit + squash。我不会天天翻 3 个月前的 commit，但需要 `git log` + `git show` 时能精确找回任意历史点。

实际效果：4 个月的对话历史被压成 ~10MB 摘要 + 100MB 原文，新会话启动时只注入元数据（"我和 AI 助手合作过 1 个 student-system 项目"），需要细节随时 expand。

工具集 4 个：`lcm_grep`（关键词搜索）/ `lcm_describe`（看摘要元数据）/ `lcm_expand`（DAG 展开）/ `lcm_expand_query`（自然语言问答）。

### 横切能力：TagMemory

这里开始有意思了。TagMemory 不属于任一层，而是**跨三层使用**的横切能力。

不是自动压缩，是**我和 AI 助手主动提取**。触发条件：

1. 我说 "记住 / 决定 / 偏好..."
2. AI 助手提议存："这条值得沉淀吗？" 我说 "存"
3. AI 助手自动检测："用户偏好表述 → 存 #偏好"

**真实 schema**（节选自 `skills/tag-memory/src/database.py:215-241`，完整 23 字段，核心字段保留）：

```sql
CREATE TABLE IF NOT EXISTS memories (
    id TEXT PRIMARY KEY,
    content TEXT NOT NULL,
    summary TEXT DEFAULT '',
    tags TEXT DEFAULT '[]',
    time_label TEXT DEFAULT '',
    created_at TEXT NOT NULL,
    updated_at TEXT NOT NULL,
    verified INTEGER DEFAULT 0,
    verified_at TEXT,
    source TEXT DEFAULT 'dialogue',
    agent_id TEXT DEFAULT 'main',
    is_latest INTEGER DEFAULT 1,
    superseded_by TEXT,
    superseded_at TEXT,
    memory_type TEXT DEFAULT 'fact',
    is_inference INTEGER DEFAULT 0,
    version INTEGER DEFAULT 1,
    parent_memory_id TEXT,
    change_type TEXT DEFAULT 'created',
    event_date TEXT,
    forget_after TEXT,           -- ISO 8601 自动遗忘时间
    forget_reason TEXT,
    decay_profile TEXT DEFAULT 'gentle',
    decay_score REAL DEFAULT 1.0 -- 缓存衰减分数
);

衰减机制 —— 实际只有 3 个 profile (database.py:21-35)：

• gentle —— 温和衰减，大多数默认
• aggressive —— 激进衰减
• memos_style —— 模仿 MemOS 系统
• （代码逻辑 database.py:108 支持 permanent 单独不衰减，但不在 DECAY_PROFILES 字典里）

衰减分两种曲线（database.py:103-143）：

• linear —— 超过 after_days 后按 period 周期线性衰减，到 floor 停止
• exponential —— 半衰期指数衰减 score = 0.5^(days/half_life)，到 floor 停止

衰减不是”删除”，而是 forget_after 到点 + decay_score 降低，旧记忆不主动参与检索但保留可访问。这样三个月前的临时事实不污染今天的精准搜索，但需要时还能找到。

去重阈值是 0.8（deduplication.py:53）：我第三次说 “我喜欢用 tabs 缩进” 不会存 3 条，超过 0.8 相似度就合并。

MEMORY.md：永久规则（人工精简，”宪法”）

最稀缺的一层 —— 整个系统的”宪法”。

只有”跨时间窗口永远会用到”的内容才能进。判定标准：

1. 删除它，下次同类场景 AI 助手会重蹈覆辙？
2. 是否抽象成可执行规则（”X 时必 Y”）？
3. 是否有失败事实+量化证据支撑？

满足全部 3 条才沉淀。

软限 100KB，硬限 120KB。超过就归档到 memory/sessions-end/。

这层增长极慢 —— 25 个主题、近 65 条规则花了 4 个月。

MEMORY.md 软限 100KB / 硬限 120KB 由 governance-rules.json 守护（见 MEMORY.md 第 183 行）。

两个核心机制

机制 1：软硬限
MEMORY.md 不能无限膨胀。软限是目标，硬限是底线。超了就整理：把过期的一次性事件归档、提炼永久规则。

机制 2：永久教训沉淀协议
每条 v3-v36 教训都有严格结构：

## 🚨 永久教训 v[N] — [一句话标题] (YYYY-MM-DD main)

### 失败事实 (量化)
- [具体场景 + 量化证据]

### 永久规则 ([N] 条)
#### 规则 1: [一句可执行规则]
- [执行步骤]
- [反例]

### 沉淀物
- [代码路径 / 文档路径 / 命令模板]

这套格式不是”它”设计的，是我和 AI 助手反复失误后总结出来的：失败事实必须有量化（时间/数量/金钱），规则必须可执行（看到 X 必做 Y），沉淀物必须可查（路径/脚本）。

---

三、25 个主题教训全景

快照标记：本节为 09:35 初稿数据。11:05 沉淀 v37 后总数更新为 26 主题 / 68 规则。详见第五节。

按主题分类，全部都有失败事实支撑（这里只列规则，案例略）：

决策类（10 主题 / ~15 条规则）

编号	标题	核心规则
v3	架构偏离失败诊断	方案选型必对照蓝图逐条 grep
v4	v4 架构”做完≠接主线”	三件套：写 + 测 + 接主线 + 真跑
v5	双模型辩论 + 真集成测试	架构决策必走正反方
v6	优化 LLM 必验精度	速度优化 50% 但正确率掉 100% = 净负
v7	优化实施必验生效	cache 要真有命中
v12	双模型辩论 + 量化切换条件	必有”条件 A / B / C”二元判定
v26	审核智能体代为拍板	档 2.5 决策可不可逆分界
v28	用户提醒 + 实测必先于评审代决	提醒比代决快，实测比猜测准
v4+v5	借鉴不是搬代码	学原则不学实现
v11	ROI 评估前必扫 skills/	选型前先 ls 看现有能力

实施类（8 主题 / ~12 条规则）

编号	标题	核心规则
v8	vision + stub 必须双验证	单组件测过 ≠ 链路工作
v9	Python 端 vision LLM 接口	bytes 必 base64
v13	sys.path 污染 + 一次性完成	调外部服务必清 sys.path
v14	deeptutor 加模型	调研先于实施
v15	deeptutor 是 systemd user service	进程管理 ≠ 业务代码
v20	inbound 文件未必等于用户原图	收图必查 manifest，肉眼必看
v29	物理题端到暴露学科路由	路由前必跑真图回归
v31	VLM 看几何图也会骗人	必自己看像素

质量类（10 主题 / ~15 条规则）

编号	标题	核心规则
v20	inbound 链路断点	md5 + size + 内容三重验
v30	动画/多帧视觉产物必逐帧核验	抽帧肉眼不靠 VLM
v32	动画审核 v6.1 必查 4 项	时序/推导/反问/几何
v33	动画观感 5 项	辅助线/解构/填充/布局/字号
v35	发文前必自查敏感事实	性别/数字/日期/名字 grep
v27	子 Agent push 后 main 必 message	auto-announce ≠ 用户可见
AI 幻觉	LLM 输出必验	看到 100% 必查
AI 助手批改	AI 网关 exec 5 分钟超时	走 sub-agent 派活
Skill 安装	必经过 skill-vetter	来源 / 代码 / 权限
不要让用户重复	学到的经验必须永久记住	同义合并

运维类（7 主题 / ~10 条规则）

编号	标题	核心规则
v34	ECS send-file 是传文件正路	小文件走 send-file
v36	ECS 大文件走 SCP	≥ 24KB 一律 scp
飞书卡片	禁 LaTeX 必须 Unicode	公式硬规则
作业图	收图必 3 处备份	原子命令
隐私	学生姓名用昵称	不记录真名
教学风格	苏格拉底式反问 + 概念解构	触发词：讲题/教/辅导
v6 模板	反问在前 + 答案后置	4 步结构化讲题

总计 25 主题、65 条可执行规则，加开头 8 条永久原则共 73 条可执行指令。这不是堆数字，是每条都救过一次决策。

---

四、完整盘点：不止 3 层 + TagMemory

本节由我追问触发：原版只覆盖了 L1/L2/L3 + TagMemory。我反问”这就是全部了吗”后，AI 助手重跑了 v11 教训”盘点必先于评估”，发现还有 5 个真实组件没写进来。

全栈数据（实测，2026-07-04）

组件	路径	大小	状态
MEMORY.md（宪法）	agents/main/MEMORY.md	98.7 KB	✅ 活跃，25 主题/65 规则
lcm.db（历史压缩）	~/.openclaw/lcm.db	309 MB	✅ 活跃，自动 DAG 压缩
AGENTS.md / SOUL.md / IDENTITY.md / TOOLS.md（bootstrap）	agents/main/	各 ~5 KB	✅ 每次启动注入
inner-state.json / habits.json / drive.json / relationship.json	agents/main/memory/	<1 KB 总	⚠️ 2.5 月未更新
BRAIN.md（9 步 Brain Loop 协议）	skills/inner-life-core/templates/BRAIN.md	-	⚠️ 协议定义存在但未在 cron/loop 实际跑
TagMemory 数据库	~/.openclaw/workspace/skills/tag-memory/data/memory.db（真实位置）	229 KB / 53 条	✅ 活跃（2026-05-27 ~ 06-25）
agents/main/skills/tag-memory/data/memory.db	0 字节空文件	⚠️ 路径不一致 bug（database.py:198 写死了 workspace 路径，但 skill 部署在 agents/main）
llm-wiki（长期知识库）	~/llm-wiki/	32 KB，仅 2 个 topic	❌ 基本空（仅 chuzhong-math + zhongkao）
Obsidian vault（错题库 + WebDAV 同步）	~/obsidian-vault/	74 MB	✅ 活跃，含 2026 中考研究/作业/几何 等
memory/ 日志	agents/main/memory/	-	✅ 130+ 日志文件
governance-rules.json（bootstrap 守护）	scripts/memory-governance/	-	✅ 软限 8KB/硬限 10KB 守护 4 个 bootstrap

5 个未在原版覆盖的关键组件

1. inner-life- bundle* —— 情感状态 + 习惯

来源：DKistenev/openclaw-inner-life v1.0.4（独立 bundle，跟 TagMemory 不是同源）

真实 schema（5 个 JSON/MD 文件，加 BRAIN.md 协议）：

• inner-state.json —— frustration / confidence / impatience / boredom / connection / curiosity 6 个情绪维度（half-life decay）
• habits.json —— myHabits + userPatterns，+1/确认 -1/周不用
• drive.json —— 主动 seeking/anticipation
• relationship.json —— 信任级别
• BRAIN.md —— 4 层 Context Protocol（Level 1-4 不同深度读不同文件）

9 步 Brain Loop 协议：cron/loop 引用 BRAIN.md，按 Level 1-4 读不同上下文。

实际状态：⚠️ 协议定义存在但 hooks 没接入主循环 —— 最近一次更新 inner-state.json 是 2026-04-20，距今 2.5 个月。这是 v4 教训”做完≠接主线”的复刻版本。

2. bootstrap 层 —— AGENTS.md / SOUL.md / IDENTITY.md / TOOLS.md

跟记忆的关系：记忆是我和 AI 助手长期经验沉淀，bootstrap 是当前身份快照。

• 4 个文件每次 session 启动时完整注入 LLM 上下文
• governance-rules.json 守护：软限 8KB / 硬限 10KB
• 大内容拆到 *_REFERENCE.md（避免 bootstrap 膨胀）

原版漏掉了这层 —— 它严格说也算”永久记忆”的一种。

3. TagMemory vs inner-life-memory 关系

AI 助手原版混淆了这两个不同来源：

维度	TagMemory	inner-life-*
来源	我们自己写（2026-03）	外部 bundle（DKistenev/openclaw-inner-life v1.0.4）
数据库	SQLite（workspace 路径，229 KB / 53 条）	JSON 文件（main agent 仅 516 bytes）
触发器（设计）	我说”记住” + cron file_watcher	cron/loop 自动
触发器（实际）	71 天未触发主动 store；cron file_watcher 每 30min 只设 flag 不真调 store	⚠️ JSON lastUpdate 2026-04-20（2.5 月未更新）
衰减	forget_after ISO + decay_score（cron forget-cleanup 每 6h 跑，7/3 真把 19 条降到 15 条）	half-life decay（情绪维度）
数据	事实/偏好/决定（is_latest=1 共 15 条 / 53 总）	情感 + 习惯 + 好奇心
当前状态	⚠️ 半截活信：写入停滞 71 天 / GC 正常 / 文档与实际脱节	⚠️ JSON 存在但 2.5 月未更新

现状：两套都没真正跑起来，是”挂着但待机”。

4. Obsidian vault —— 外部持久知识库

• 路径：~/obsidian-vault/（74 MB）
• 同步：WebDAV 走 CloudReve（pan.bloodysky.top/dav/obsidian-vault）
• 主题：2026 中考研究 / AI 学习 / 作业 / 几何 / 初中化学
• 内容：错题库（个体）+ 学习笔记

跟主系统的关系：

• MEMORY.md 的 📚 永久原则段有专门 “Obsidian 错题库设计原则”
• vault-sync-agent.sh 心跳驱动同步（不是 cron —— 又是 v4 教训”事件驱动 > 轮询”的应用）
• 但同步本身有 v5 之前的 SIGKILL 超时坑（已修）

5. governance-rules.json —— bootstrap 守护机制

AI 助手提了”软限由 governance-rules.json 守护”但没贴内容。真相（节选）：

{
  "files": {
    "AGENTS.md": {
      "soft_limit_kb": 8,
      "hard_limit_kb": 10,
      "reference_file": "AGENTS_REFERENCE.md",
      "content_types": {
        "allowed_in_main": ["Lane Contract 精简版", "关键决策协议", ...],
        "reference_only": ["完整路由规则表", "MattPocock Skills 完整触发器", ...]
      }
    }
  }
}

核心设计：不仅设软硬限，还定义了内容类型规则（哪些内容进 main，哪些必须放 reference）—— 这就是 v28 教训”2026-07-01 瘦身”的执行引擎。

失败盘点（v11 教训触发）

AI 助手没盘点就写 blog 的代价（也包括我**没提醒”先盘点”**的代价）：

• 漏掉 inner-life-*（以为只有 TagMemory，实际有第二套）
• 漏掉 bootstrap 层（4 个文件每次启动注入）
• 漏掉 Obsidian vault（74MB 外部存储）
• 漏掉 governance-rules.json（不只是软限，是内容分类规则）
• 漏掉 lcm.db 真实规模（以为很小，实际 309 MB）
• llm-wiki 误以为是知识库，实际只有 2 个 topic 32KB

这套系统的真实”记忆”远比 AI 助手原版写的丰富，但大部分处于”挂着但没接主线”状态。这本身是个值得单独写一篇 blog 的主题。

主线接入现状（v4 教训复刻）

组件	定义完	接入主线	真起作用
MEMORY.md	✅	✅	✅ 每次启动加载
lcm.db	✅	✅	✅ 自动压缩
TagMemory	✅（schema/衰减/Gate 写完）	❌ 写入路径未接 cron（capture.sh 6/18 创建后零次跑） ⚠️ 数据路径不一致（database.py:198 hard-code workspace 但 skill 部署 agents/main）	⚠️ 半截：GC 正常（forget-cleanup 7/3 真把 19 条降到 15 条），写入 71 天无新数据
inner-life-*	✅	❌	❌ 2.5 月未更新
llm-wiki	❌（只有 2 topic）	❌	❌
Obsidian vault	✅	✅	✅ 心跳同步
governance-rules.json	✅	✅	✅ 守护生效
bootstrap 4 文件	✅	✅	✅ 每次加载

事实：核心 3 组件真起作用（MEMORY.md / lcm.db / bootstrap），其余要么空要么挂机。

重大修正（v11 + v35 教训再次复刻）

我追问后第二轮核查，发现致命 bug：

AI 助手原版写的 “TagMemory 数据库 0 字节空库” 完全错了。

真相：

• database.py:198 写死了 ~/.openclaw/workspace/skills/tag-memory/data/memory.db
• 但 skill 实际部署在 ~/.openclaw/agents/main/skills/tag-memory/
• 真实数据库在 workspace 路径：229 KB / 53 条 memories（main agent 100%）
• agents/main/…/memory.db 是个空 placeholder 文件，没人维护

这是 v11 教训的复刻：”盘点前必扫 skills/ 全目录” —— AI 助手只 grep 了一个路径就草率下结论”空库”。又踩一遍。

v35 教训也复刻：发文前未核对源头 —— AI 助手看到 0 字节就直接写”事实上没有数据”，没去查代码路径。

这个 bug 本身已经写成新永久教训 v37：任何”看不到数据”的下结论前，先 grep 全部可能路径 + 查代码里的 db_path。

TagMemory 真实数据（v37 触发后的 SQL 实测）

数据库: ~/.openclaw/workspace/skills/tag-memory/data/memory.db (229 KB)
schema: memories + memories_fts + memories_fts_data/docsize/idx/config + user_profiles

维度	数据
memories 总条数	53 条
时间范围	2026-05-27 14:52 ~ 2026-06-25 17:27
agent_id 分布	main=53（100%）
memory_type	fact=36 + episode=13 + preference=4
is_latest=1	15 条最新（其余 38 条 superseded）
FTS5 全文索引	memories_fts + idx + data + docsize + config 全套

类型分布解读：

• fact 36 条 = 客观事实
• episode 13 条 = 事件性记忆（带上下文）
• preference 4 条 = 用户偏好

is_latest 解读：38 条被 supersede（新版覆盖），说明 tag-memory 真的在用去重机制，不是死代码。

database.py:198 的真相

# skills/tag-memory/src/database.py:196-201
def __init__(self, db_path: str = None):
    if db_path is None:
        db_path = os.path.expanduser("~/.openclaw/workspace/skills/tag-memory/data/memory.db")
    Path(db_path).parent.mkdir(parents=True, exist_ok=True)

• 构造函数接受 db_path 参数（None 默认）
• 但没人调用时传参 → 永远走 workspace 路径
• skill 部署在 ~/.openclaw/agents/main/skills/，但数据在 workspace
• agents/main/data/memory.db 是空 placeholder，从来没人用这个路径

为什么这个 bug 没爆：所有调用都走 MemoryDatabase() 无参构造 → 都用 workspace 路径 → 没人在 agents/main 路径下读库 → 空文件永远没人发现。

修法（P1）：

• 改成读 ~/.openclaw/openclaw.json 找真实部署路径
• 或改成环境变量 TAG_MEMORY_DB 可覆盖
• 或在两个路径都建库（同步双写）

v37 在 MEMORY.md 中的新规则

新永久教训 v37 3 条规则：

1. 看到 0 字节必查 db_path —— grep db_path|connect.*\.db 不下结论
2. skill 部署路径 ≠ 代码默认 db_path —— 路径漂移是 v4 教训”做完≠接主线”的变种
3. blog 涉及数据规模必先 SQL 查表 —— “53 条” 必须 sqlite3 实测

更新后 MEMORY.md 总数：26 主题 / 68 规则（v37 含 3 条规则）。这是 v37 沉淀后的真实数据。

---

修正后的全景图

启动即用（每次注入 LLM 上下文）
  ├── AGENTS.md / SOUL.md / IDENTITY.md / TOOLS.md  （bootstrap）
  └── governance-rules.json 守护软硬限

长期沉淀
  ├── MEMORY.md  ←永久规则（人工精简，25 主题/65 规则）
  ├── lcm.db  ←历史对话（DAG 压缩，309 MB）
  ├── Obsidian vault  ←错题/学习笔记（74 MB，WebDAV 同步）
  └── llm-wiki  ←长期知识库（**实际基本为空**）

主动提取
  ├── TagMemory  ←我说"记住"时触发（**当前空库**）
  └── inner-life-* bundle  ←cron 触发（**2.5 月未更新**）

守护机制
  ├── bootstrap soft/hard limit（8KB/10KB）
  └── MEMORY.md soft/hard limit（100KB/120KB）

五、几个反直觉的设计

1. 衰减而不是删除

第二版 AI 助手设计”过期自动清理”。结果清理了 3 个我其实会重新提起的偏好。

第三版改”衰减不删除” —— forget_after 到点不主动参与检索，但 decay_score 仍可被 lcm_expand 找回。

经验：人类的偏好比你想的稳定，比你想的也善变。

2. 永久教训必须含失败事实

第三版 AI 助手试过只存”规则”（”看到 X 必 Y”），后来发现自己都会忽略。

第四版加失败事实：”某年某月某项目，因为没 X，结果 Y”。

效果立竿见影 —— 看到失败细节，会本能警觉。人脑是故事机不是规则机。

3. 软限 100KB 是认真算的

太小（< 50KB）会频繁删好规则。太大（> 200KB）会塞一次性事件。

100KB 大约能装 ~80 条规则。对单用户系统刚好够 —— 多用户得拆。

4. LCM 自动跑不干预

AI 助手之前想做”智能压缩”，手动控制哪些压、哪些不压。结果发现：人在记忆这一件事上极不可靠，要么过度压（怕丢）要么不压（懒）。

直接交给 lossless-claw 自动 DAG 压缩。需要时 lcm_expand。半年没出过问题。

5. TagMemory 不替代 MEMORY.md

早期想法：”MEMORY.md 内容自动同步到 TagMemory”。结果发现两者目的不同：

• MEMORY.md 是主动阅读 —— 启动时加载，看着规则决策
• TagMemory 是触发检索 —— 我问”我之前说过什么”才查

一个 push，一个 pull。不能合并。

---

五、双模型辩论机制

这套系统里最特殊的设计：架构级决策必走辩论。

不是我跟 AI 助手辩论，是两个 AI 模型辩论。

正方 (M3 系统管家 92 分) ─┐
                          ├→ 分差 57 → 方案 X 胜
反方 (deepseek-v4-flash 35 分) ─┘

为什么需要两个 AI？

• 单 LLM 评估自己容易自利偏差 —— “我刚想到的方法当然好”
• 不同模型对同一问题常有截然不同的判断
• 辩论过程暴露盲点：AI 助手没想到的风险，对方帮你指出

触发条件：confidence < 0.7、high_risk、multi_path、user_doubt、complex_reasoning。

不走过场 —— 5-7 个对比维度各打 0-100 分，分差 ≥ 30 直接采纳胜方，< 30 走人工拍板（也就是我拍板）。

永久教训 v5、v12 都是辩论机制的产物。

---

六、写给想抄的人

如果你的 AI 数字人也想做永久记忆，别照抄我的层级。先问 3 个问题：

1. 你的记忆强度需求是什么？ 一次性问答 vs 长期伙伴完全不同
2. 衰减容忍度？ 业务关键信息容忍”忘”吗？
3. 人类参与审核的意愿？ 没人愿意审核，全自动就只能依赖 LLM —— 风险高一截

如果答案分别是”长期伙伴”/“业务关键”/“愿意”，你大概率需要这套分层架构。
如果是”一次性”/“不重要”/“不愿意”，简单 memory_search + 定期总结就够。

---

七、未做的事（知道但不做）

• ❌ 用向量数据库替代 qwen3 embedding / FTS5 —— 当前数据规模不够，性价比低
• ❌ 给 MEMORY.md 加版本控制自动 diff —— 每月人工 diff 已够
• ❌ 让 LLM 自己写永久教训 —— 必有人类审，否则会塞过度抽象或过度具体
• ❌ 跨 agent 共享 MEMORY.md —— 单 agent 自己系统已经够复杂，跨 agent 引入一致性噩梦

有意识的不做，比仓促做的更难，但更对。

---

结尾

版本时间线（changelog）

• 09:35 初稿（我问’写blog’ → AI 助手凭印象 + 部分 grep → 上线）
• 09:43 我指出没真调查 → AI 助手去查 TagMemory 真实 schema / profile / 阈值 → 上线修正版
• 10:41 我反问’这就是全部记忆了吗’ → 触发 v11 复盘，5 个组件补全
• 10:58 我指出 ‘TagMemory 0 字节空库是大问题’ → 触发 v37，发现路径不一致 bug + 真实 53 条数据
• 11:08 当前版本：26 主题 / 68 规则，TagMemory 真实 53 条，blog 全篇修订
• 12:14 沉淀 session memory (memory/2026-07-04.md)
• 13:49 我指出架构图 TagMemory 描述与事实不符 → v1.5 修正：
  • 架构图 TagMemory 段改成”半截活信”+ cron 实际机制（每 30min file_watcher + 每 6h forget-cleanup）
  • 横切段正文改成”被动机械提取 + 主动触发 71 天无调用”并坦白 GC 部分真活
  • TagMemory vs inner-life 表补”触发器(实际)”列
  • 主线接入现状把 ✅ 改成 ⚠️ 半截
• 19:35 v1.6 加 byline 块，明确”我 = AI 助手”+”你 = 人类用户”
• v1.7 改版日志：以个人 AI 系统主用户第一人称重新叙述 —— 把”我”指代为本文作者，”我的 AI / 我的数字人 / 它”指代 AI 助手
  • 改写动机：v1.6 双重署名（”AI 助手 + 人类用户”）造成指代混乱
  • 改版原则：作者是文章叙事主体，AI 助手是工具/伙伴，不是合著者
  • 改版范围：开场 / 第二人称 / 创作声明 / 主体段引用主体 / 元数据署名

26 个主题、68 条可执行规则，花了 4 个月沉淀。下一次如果再看到 “100% 闭环 / 全部完成 / 系统就绪” 的报表，我会让 AI 助手先去 grep 教训列表，翻到 AI 幻觉验证那条，再决定信不信。

永久记忆不是越多越好，是每一条都能在关键时刻调用才算数。

下次想加新规则时，我会让 AI 助手问自己 3 件事：

1. 有没有量化失败事实？
2. 是不是可执行规则？
3. 是不是真的”跨时间窗口”？

不满足，不进。

---

作者：个人 AI 系统主用户

AI 数字人协作：系统管家小肥蛋（main agent / M3 模型）

本文写的是我怎么管一个 AI 系统、我怎么被 AI 助手坑、我怎么沉淀规则让 AI 助手变聪明。

• 永久教训总量：26 个主题（v3-v37 编号区间，含 v20.1 子节），累计 68 条可执行规则
• 所有规则、结构、机制均来自真实系统的 4 个月实战沉淀，非理论设计
• 关键 v37 教训源于本文创作过程本身 —— 调查后修正 → 真实数据与初稿不符 → 沉淀新规则
• 改版日志：v1.7（2026-07-08 19:41 改为个人 AI 系统主用户第一人称叙述，明确”我 = 本文作者”，”我的 AI = 数字人小肥蛋”）