把内容喂好
重要的事实要说清楚
提取擅长捕捉明确的陈述和决策，也会恰当地跳过闲聊。当某件事必须被记住时，请把它直白地说出来：- ✅ “记住：Q1 的预算上限是 75K 美元，硬性限制。”
- ✅ “我们决定使用 PostgreSQL——JSON 支持更好，而且团队熟悉它。”
- ⚠️ “嗯，那就选第二个方案吧我觉得”——指代含糊的表述提取效果差。请指名道姓。
不只说是什么，还要说为什么
带理由的决策比一个孤立的结论要有用得多。“我们选择 PostgreSQL 而非 MySQL，是为了 JSON 支持和团队的经验积累”，能让未来的助手回答*“为什么用 Postgres？“——而不只是”用了哪个数据库？“*上传源文档，不要转述
如果知识存在于某个文件中，请上传该文件。文档内容的解析和索引保真度高于聊天中对它的摘要，而且从中提取的记忆会带有指向真实来源的溯源。更正要说出口
当情况发生变化时，请明确说明——“发布时间从 10 月 15 日改到了 11 月 1 日”——而不是只在闲谈中顺带提到新日期。明确的更正会更新旧记忆或将其标为冲突，而不是让两个版本同时生效。作用域划分：杠杆最高的决策
检索的作用域限定在项目内。项目划分得当意味着召回相关；一锅端的项目则意味着噪声。- 一个上下文一个项目——按客户、按项目、按生活领域划分。不要建一个巨大的”全部”项目。
- 多客户场景使用按 Agent 的配置——OpenClaw 插件的按目录
.memorylake/config.json会将每个工作目录固定到各自的项目，因此客户 A 的事实绝不会出现在客户 B 的会话中。参见编码 Agent。 - 检索变嘈杂时就拆分——如果回答开始引用不相关的上下文，说明您的项目很可能覆盖了两个上下文。拆开它。
让记忆保持诚实
及时审核冲突
冲突是记忆的免疫系统——但前提是有人去消解它们。当助手对某条事实显得不确定时，以及在任何一轮集中更正之后，都请查看项目的冲突标签页。在团队中，要确保有人持有消解权限并把这件事当成习惯。用溯源做审计
在相信一条意外的断言之前，先打开该记忆的来源溯源——您会清楚看到是哪段会话或哪份文档产生了它。这也是排查助手为什么相信某个错误结论的最快方式：找到记忆、溯源，然后编辑或遗忘它。有意识地清理
- 编辑细节已经偏移的记忆（标题、数字、名称）
- 遗忘已过时或本就不该被捕获的记忆——删除是永久的，且在所有地方生效
- 不要过度清理：去重和合并已经处理了重复问题；因为错误而删除，而不是为了整齐
面向团队
- 明确什么该进共享记忆——决策、政策、客户事实：该进。个人工作笔记：留在个人空间。工作空间边界就是个人记忆与组织记忆的分界线。
- 指派冲突负责人——没有冲突消解者的项目会悄悄积累过时事实。
- 依靠权限，而不是自觉——如果只有负责人可以删除记忆，那就从其他角色中移除
mem_delete，而不是依赖约定。参见权限参考。
面向开发者（API）
- 发送完整的会话轮次给 add-memory（
infer: true），让提取来决定什么值得长期保留——预先过滤通常会丢失有助于提升提取质量的上下文。 - 使用
user_id，让记忆归属到正确的终端用户。 - 只有在原样存储一条已经整理好的事实时，才设置
infer: false。 - 向您的用户开放溯源和遗忘能力——“你为什么知道这件事？“和”忘掉这个”既能建立信任，也能满足合规要求。
- 如果您的产品会断言事实，请通过程序检查冲突——参见冲突 API。
常见误区
后续步骤
记忆概览
深入了解提取、检索、溯源与冲突
场景
看这些实践如何端到端落地