一个更像真实项目的 OpenClaw 长期记忆搭建案例

前面几篇文章讲的是原则和设计。
这篇换一个角度，不讲“理想系统”，而讲一套更接近真实项目推进方式的案例。

假设我们要给一个基于 OpenClaw 的内部研发助手加长期记忆，目标不是聊天更像人，而是解决下面这些真实问题：

• 团队每次都要重复解释项目约束
• 做到一半的任务下次接不上
• 之前踩过的坑没有被稳定复用
• 人类知道哪些规则重要，但系统总在关键处忘掉

第一步：先把需求缩到一个高价值场景

长期记忆最怕“什么都想做”。

这个案例里，我们故意只选一个最小可上线场景：

跨会话恢复研发任务状态

也就是当用户第二天再来时，系统至少能回答：

• 上次做到哪了
• 当前项目有哪些约束
• 接下来建议先做什么

先不做：

• 全量聊天记忆
• 自由问答型知识库
• 多用户共享记忆网络
• 自动学习所有新结论

因为只要先把“任务连续性”做好，价值就已经非常明显。

第二步：把系统拆成 6 个最小模块

这个案例里，我会把系统拆成下面 6 层：

1. Session Event Capture 采集用户输入、工具结果、人工确认和任务状态变化。

2. Memory Candidate Filter 判断哪些事件值得进入长期记忆候选。

3. State Summarizer 把候选事件变成结构化状态，而不是原样存整段文本。

4. Memory Store 分层保存状态事实、知识摘要和归档日志。

5. Task Resume Retriever 下次进入任务时优先拉取当前项目状态和最近任务检查点。

6. Review And Rollback 处理高风险更新、冲突状态和错误写入回退。

注意这里没有“超级智能中心”。
真实系统更需要的是职责边界，而不是一大块模糊能力。

第三步：只允许 3 类内容先写入

为了避免系统一开始就污染，这个案例里我只允许下面三类内容进入长期记忆：

1. 已人工确认的项目约束
2. 已完成任务步骤的结构化检查点
3. 重复出现且被验证过的解决方案摘要

暂时不允许写入：

• 普通对话全文
• 未验证的模型猜测
• 一次性调试输出
• 没有明确主体的泛化结论

这一步看起来保守，但它决定了后面系统会不会越用越脏。

第四步：给每一类记忆定义主体

这个案例里，所有条目都必须绑定主体，不允许“漂浮记忆”。

常见主体只有三种：

• project
• task
• user

例如：

{
  "layer": "state",
  "subjectType": "project",
  "subjectId": "project-alpha",
  "summary": "当前阶段禁止直接改生产库结构",
  "source": "manual-review"
}

这样做的好处是，下次检索时系统知道该围绕谁召回，而不是在全库里找“像相关”的内容。

第五步：上线顺序故意分 4 次

如果这套系统真要上线，我不会一次推完。
更稳的节奏通常是 4 个阶段。

阶段 1：只记录任务检查点

目标：

• 能记住上次做到哪一步
• 能在下次打开时恢复任务连续性

这时候还不做复杂知识复用，只验证“任务能否接得上”。

阶段 2：加入项目约束状态

目标：

• 系统能带着当前约束进入后续任务
• 项目级规则不会每次都靠人重复输入

这里开始需要人工确认，因为约束一旦写错，后面影响最大。

阶段 3：加入经验摘要

目标：

• 把重复出现的问题沉淀成可复用模式
• 让系统在相似问题上给出更快起步建议

这时才值得加入更像知识层的内容。

阶段 4：补观测和自动清理

目标：

• 看见误召回和冲突更新
• 定期把低价值记忆降级或归档

很多团队会把这一层拖到最后很后面，结果问题已经积累太多了。

一段更贴近真实项目的流程伪代码

function onTaskEvent(event: TaskEvent) {
  const candidate = extractCandidate(event);
  if (!candidate) return;

  if (!isAllowedMemoryType(candidate.type)) {
    archiveEvent(event);
    return;
  }

  const record = summarizeToStructuredState(candidate);

  if (record.type === "project-constraint" || record.confidence < 0.9) {
    queueReview(record);
    return;
  }

  const conflict = detectStateConflict(record);
  if (conflict) {
    createRollbackPoint(conflict.current);
    queueConflictResolution(record, conflict.current);
    return;
  }

  storeVersionedRecord(record);
}

function resumeTask(taskId: string, projectId: string) {
  const recentCheckpoint = getLatestTaskCheckpoint(taskId);
  const projectConstraints = getCurrentProjectConstraints(projectId);
  const relevantPatterns = getVerifiedKnowledgePatterns(projectId);

  return composeResumeContext({
    checkpoint: recentCheckpoint,
    constraints: projectConstraints,
    patterns: relevantPatterns,
  });
}

这段流程里最重要的不是复杂度，而是两个原则：

• 高风险状态不直接自动写入
• 恢复任务时优先状态事实，其次才是经验摘要

这类项目最容易低估的三个工程位

1. 记忆版本管理

只要状态会变，你就需要：

• 当前版本
• 被覆盖版本
• 回退点

没有这个，排错会非常痛苦。

2. 冲突检测

当新约束和旧约束打架时，系统必须知道这不是“多一条信息”，而是“要停下来处理的冲突”。

3. 观测入口

至少要能回答：

• 刚才写了什么
• 为什么写进去
• 下次检索为什么把它拉出来
• 它是不是后来被覆盖了

如果这些都看不见，你会越来越难信任系统。

一个现实可行的验收标准

这套案例如果要判断是否值得继续投入，我会只看 4 个问题：

1. 第二次进入任务时，是否明显更快进入状态
2. 团队是否减少重复补背景
3. 错误写入是否能在一轮内被发现并回退
4. 记忆层是否没有明显制造更多噪声

只要这 4 条里有 2 到 3 条持续成立，系统就值得继续迭代。

延伸阅读

• 如何给 OpenClaw 打造一套能解决实际问题的长期记忆系统
• OpenClaw 长期记忆系统的设计思路：记忆写入、检索、更新与遗忘怎么分层
• 如何验证一套 AI 长期记忆系统真的在解决问题