From aefafae658da01cb514bfda4357123dd4a8c221c Mon Sep 17 00:00:00 2001
From: dolnna <99724206+dolnna@users.noreply.github.com>
Date: Wed, 11 Feb 2026 15:35:58 +0800
Subject: [PATCH] Update mem_production.md
---
.../introduction/mem_production.md | 89 ++++++++++++++-----
1 file changed, 68 insertions(+), 21 deletions(-)
diff --git a/content/cn/memos_cloud/introduction/mem_production.md b/content/cn/memos_cloud/introduction/mem_production.md
index 25cf4a44..f72e6496 100644
--- a/content/cn/memos_cloud/introduction/mem_production.md
+++ b/content/cn/memos_cloud/introduction/mem_production.md
@@ -1,6 +1,6 @@
---
title: 记忆生产
-desc: 记忆生产模块将原始消息或事件转化为可存储、可检索的记忆单元，作为MemOS全流程的起点。
+desc: 记忆生产模块将原始消息、事件或知识转化为可存储、可检索的记忆单元，作为MemOS全流程的起点。
---
::warning
@@ -13,40 +13,32 @@ desc: 记忆生产模块将原始消息或事件转化为可存储、可检索
## 1. 能力介绍：为什么要将原始消息加工为记忆
-在 MemOS 里，你提交的是 **原始信息**（用户与 AI 的对话、用户在APP上的操作日志 / 行动轨迹等），系统会自动完成“记忆化”的过程。
+在 MemOS 里，你提交的是 **原始信息**（用户与 AI 的对话、用户在APP上的操作日志 / 行动轨迹、知识库文档等），系统会自动完成“记忆化”的过程。
::note{icon="ri:triangular-flag-fill"}
**为什么要进行记忆加工？**
::
-如果只是简单地把原始对话全部保存，再次使用时直接丢给大模型，会出现几个问题：
+如果只是简单地把原始信息全部保存，再次使用时直接丢给大模型，会出现几个问题：
-- **上下文过长**：原始消息往往冗长、重复，把整段上下文都传给模型既低效，又浪费 Token；
-- **检索不精准**：没有加工的原始文本难以快速定位关键信息，检索往往会召回大量噪音；
-- **调用成本高**：直接拼接原始消息会显著增加模型输入长度，带来 Token 成本和延迟。
+- **上下文过长**：原始信息通常冗长且包含大量重复与无关内容，整段传入模型会显著拉长上下文窗口，处理效率低且浪费 Token；
+- **检索不精准**：未经结构化与抽取的原始文本难以突出对话中的关键信息，检索时容易召回大量噪音内容，影响回答质量；
+- **体验不连续**：原始对话是一次性的静态文本，无法感知用户偏好与情感、业务背景与规则的变化，造成连续对话的体验偏差。
::note
-**加工后有什么不同？**
+**MemOS 加工后的记忆是什么？**
::
MemOS 会把原始消息转化为结构化记忆单元，自动提炼：
-- **关键事实**：如“用户在旅行时通常是全家出游（带孩子和父母）”；
-- **任务线索**：提炼出用户的目标意图，比如“规划一次家庭旅游”，而不仅仅是“暑假出去玩”。
+- **关键事实**：
+ - 提炼用户对话中的事实信息，如“用户计划在2025年暑假期间前往广州旅游。”；
- **用户偏好**：
- - 不仅是显式表述（“我喜欢全家出游”），还包括隐含的推理范式。
- - 例如，如果用户在 让AI给10 篇文章评分过程中，展现出“偏向逻辑清晰的写法”，那么在未来的 20 篇文章评分任务中，MemOS 会保留这种偏好模式，引导模型保持一致性；
-
-
-
-这样一来：
-
-- **检索更快更准**：直接定位到事实 / 偏好 / 任务，而不是一整段原始消息。
-- **调用更高效**：拼接给大模型时只需传递精炼记忆，减少 Token 消耗。
-- **体验更稳定**：模型能持续保持对用户习惯的理解，不会因上下文丢失而偏离。
-
+ - 提炼用户对话中显式的偏好表述，例如“用户提到喜欢全家出游”；
+ - 提炼用户对话中隐含的推理范式，例如“用户可能偏好性价比高的酒店选择”；
+ - MemOS 会保留用户的偏好模式，引导模型在后续回答中保持一致性。例如，当用户在使用 AI 辅助写作时，展现出“偏向逻辑清晰的写法”，那么 MemOS 会继续引导模型在其他任务中，保持“逻辑性的写作手法”。
@@ -68,6 +60,61 @@ Reasoning: 七天酒店通常以经济实惠著称，而用户选择七天酒店
> 对你来说，这意味着：只要存原始对话，不必自己写“关键词提取”或“意图识别”的逻辑，就能得到可被长期调用的用户偏好。
+
+
+除了文本对话消息，针对 Agent 任务执行的过程，MemOS 适配了工具记忆、技能：
+- **[工具记忆（tool memory）](/memos_cloud/features/advanced/tool_calling)**：
+ - 提炼 Agent 任务执行过程中的工具调用信息为记忆，记录工具类型、使用场景与调用结果特征，用于后续相似任务的工具优先选择。
+- **[技能（Skills）](/memos_cloud/features/advanced/skill)**：
+ - 提炼用户对话，生成可复用的执行能力。
+ - 例如，从多轮关于“生成旅行规划”的对话中，提炼出包含目的地分析、行程拆分、预算约束的可执行“旅行规划技能”，而不仅仅再是“用户喜欢特种兵旅行”这样供模型推理参考的记忆。
+
+此外，MemOS 还支持基于[知识库](/memos_cloud/features/advanced/knowledge_base)、[多模态消息](/memos_cloud/features/basic/multimodal)的记忆加工哦！
+
+
+
+::note
+**记忆是如何被加工的？**
+::
+
+MemOS 始终认为记忆不是静态的记录，而是随时间演化的对象，它需要快速、准确、连续地记住用户。
+
+为了更好地处理记忆的三角问题：实时性、准确性、一致性，MemOS 把记忆加工的全流程拆分为以下三个阶段：
+| 阶段 | 目标 | 特点 |
+| ---- | --------- | -------------------------------------------------------------------- |
+| Fast | 不丢记忆 | 原文简单处理并快速入库，耗时毫秒级，下一轮对话即可检索到。 |
+| Fine | 近程组织 | 回溯当前上下文及历史记忆，如发现冲突，会在原 Memory ID 上生成新版本。 |
+| Offline | 全局组织 | 定期长程回溯，修正早期未识别的冲突，保持整体一致性。 |
+
+形成的结果不是两条冲突记忆，而是：**同一个 Memory ID 的 V1 / V2 / V3… 时间演化链**
+
+
+
+**例子**：
+
+```json
+# 假设是2025年
+User: 我是小忆，现在在上海居住，不太能吃辣。
+
+# 假设是2026年
+User: 最近我搬去成都了，突然爱上四川火锅，喜欢辣锅！
+```
+
+```json
+V1版本记忆：用户叫小忆，在上海居住，不能吃辣
+V2版本记忆：用户叫小忆，在成都居住，喜欢吃辣，喜欢四川火锅。
+```
+
+>这样，同一条记忆能够随时间演化，既能给出“可依赖的当前认知”，同时保留完整的历史轨迹。
+
+
+
+这样一来，我们解决了最初提到的问题：
+- **调用更高效**：拼接给大模型时只需传递精炼记忆，减少 Token 消耗。
+- **检索更快更准**：直接定位到事实 / 偏好 / 工具 / 技能记忆，而不是一整段原始消息。
+- **体验更稳定**：模型能持续保持对用户习惯的理解，不会因上下文丢失而偏离。
+
+
## 2. 进阶：如果你想做深度定制
@@ -78,7 +125,7 @@ Reasoning: 七天酒店通常以经济实惠著称，而用户选择七天酒店
| 抽取与结构化 | 默认会生成 MemoryItem（包含内容、时间戳、来源等） | 可以替换抽取模型或模板，或在 schema 中增加领域字段 |
| 切分与嵌入 | 系统会对长文本切分并送入嵌入模型 | 可以调整切分粒度，或替换为更适合的 embedding 模型（如 bge、e5） |
| 存储后端 | 默认使用向量数据库（如 Qdrant） | 可切换为图数据库，或混合使用两者 |
-| 合并与治理 | 系统会自动处理重复与冲突 | 可以编写自定义规则（如时间优先、来源优先），或增加治理逻辑（去重、过滤等） |
+| 合并与治理 | 系统会自动处理重复与冲突 | 可以编写自定义规则（如时间优先、来源优先）等 |
## 3. 下一步行动