diff --git a/content/cn/open_source/modules/mem_chat.md b/content/cn/open_source/modules/mem_chat.md
index b9605fea..63524249 100644
--- a/content/cn/open_source/modules/mem_chat.md
+++ b/content/cn/open_source/modules/mem_chat.md
@@ -1,6 +1,6 @@
 ---
 title: MemChat
-desc: "MemChat 是你的 Agent 的‘外交官’，它协调用户输入、记忆检索与 LLM 生成，打造连贯且具备长期记忆的对话体验。"
+desc: "MemChat 是你的“记忆外交官”，它协调用户输入、记忆检索与 LLM 生成，打造连贯且具备长期记忆的对话体验。"
 ---
 
 ## 1. 简介
@@ -17,7 +17,7 @@ desc: "MemChat 是你的 Agent 的‘外交官’，它协调用户输入、记
 在回答用户问题前，MemChat 会自动从 MemCube 中检索相关的 Textual Memory（文本记忆），将其注入到 Prompt 中。这使得 Agent 能够基于过往的交互历史或知识库来回答问题，而不仅仅依赖于 LLM 的预训练知识。
 
 ### 自动记忆沉淀 (Auto-Memorization)
-对话不仅仅是消耗 tokens，MemChat 会利用 Extractor LLM 自动从对话流中提取有价值的信息（如用户偏好、事实知识），并将其存储到 MemCube 中。这个过程是自动化的，无需用户手动干预。
+对话后，MemChat 会利用 Extractor LLM 自动从对话流中提取有价值的信息（如用户偏好、事实知识），并存储到 MemCube 中。无需用户手动干预，整个过程完全自动化。
 
 ### 上下文管理
 自动管理对话历史窗口 (`max_turns_window`)。当对话过长时，它会智能裁剪旧的上下文，同时依赖检索到的长期记忆来保持对话的连贯性，有效解决了 LLM Context Window 的限制问题。
@@ -34,7 +34,6 @@ desc: "MemChat 是你的 Agent 的‘外交官’，它协调用户输入、记
 *   **`simple.py`**: **默认实现 (SimpleMemChat)**。这是一个开箱即用的 REPL（Read-Eval-Print Loop）实现，包含了完整的“检索 -> 生成 -> 存储”闭环逻辑。
 *   **`base.py`**: **接口定义 (BaseMemChat)**。定义了 MemChat 的基本行为，如 `run()` 和 `mem_cube` 属性。
 *   **`factory.py`**: **工厂类**。负责根据配置 (`MemChatConfig`) 实例化具体的 MemChat 对象。
-*   **`llm_chat.py`**: **LLM 交互层**。处理与底层 LLM 的具体通信细节。
 
 ---
 
diff --git a/content/cn/open_source/modules/mem_cube.md b/content/cn/open_source/modules/mem_cube.md
index 3475e2a8..b7fd92aa 100644
--- a/content/cn/open_source/modules/mem_cube.md
+++ b/content/cn/open_source/modules/mem_cube.md
@@ -1,16 +1,16 @@
 ---
-title: MemCube 概述
-desc: "`MemCube` 是 MemOS 中的核心组织单元，专为封装和管理用户或代理的所有类型记忆而设计。它为加载、保存和操作多个记忆模块提供统一接口，使构建、共享和部署记忆增强应用程序变得容易。"
+title: MemCube
+desc: "MemCube 是你的“记忆收纳箱”，统一管理三种类型的记忆：明文记忆、激活记忆和参数化记忆。它提供简洁的接口，方便加载、保存和操作多个记忆模块，让开发者轻松构建、保存和共享记忆增强应用。"
 ---
 ## 什么是 MemCube？
 
-**MemCube** 是一个容器，捆绑了三种主要类型的记忆：
+**MemCube** 是一个容器，包含了三种主要类型的记忆：
 
 - **明文记忆** (例如，`GeneralTextMemory`、`TreeTextMemory`): 用于存储和检索非结构化或结构化文本知识。
 - **激活记忆** (例如，`KVCacheMemory`): 用于存储键值缓存以加速 LLM 推理和上下文重用。
 - **参数化记忆** (例如，`LoRAMemory`): 用于存储模型适应参数（如 LoRA 权重）。
 
-每种记忆类型都是独立可配置的，可以根据需要进行交换或扩展。
+每种记忆都可以独立配置，根据应用需求灵活组合。
 
 ## 结构
 
@@ -18,6 +18,8 @@ MemCube 由配置定义（参见 `GeneralMemCubeConfig`），该配置为每种
 
 ```
 MemCube
+ ├── user_id
+ ├── cube_id
  ├── text_mem: TextualMemory
  ├── act_mem: ActivationMemory
  └── para_mem: ParametricMemory
@@ -35,7 +37,7 @@ MemCube
 
 ### SingleCubeView
 
-操作单个 MemCube。当你只有一个逻辑记忆空间时使用。
+用于管理单个 MemCube。当系统只需要一个记忆空间时使用。
 
 ```python
 from memos.multi_mem_cube.single_cube import SingleCubeView
@@ -59,7 +61,7 @@ view.search_memories(search_request)
 
 ### CompositeCubeView
 
-操作多个 MemCube。将操作 fan-out 到多个 SingleCubeView 并聚合结果。
+用于管理多个 MemCube。当需要跨多个记忆空间进行统一操作时使用。
 
 ```python
 from memos.multi_mem_cube.composite_cube import CompositeCubeView
@@ -78,13 +80,23 @@ results = composite.search_memories(search_request)
 
 ### API 请求字段
 
+#### 添加记忆（add模式）
+
 | 字段                  | 描述                                                             |
 | --------------------- | ---------------------------------------------------------------- |
 | `writable_cube_ids` | add 操作的目标 cube                                              |
+| `async_mode`        | `"async"`（启用 scheduler 后台处理）或 `"sync"`（禁用 scheduler 同步处理） |
+
+#### 搜索记忆（search模式）
+
+| 字段                  | 描述                                                             |
+| --------------------- | ---------------------------------------------------------------- |
 | `readable_cube_ids` | search 操作的目标 cube                                           |
-| `async_mode`        | `"async"`（scheduler 启用时）或 `"sync"`（scheduler 禁用时） |
+| `async_mode`        | `"async"`（启用 scheduler 后台处理）或 `"sync"`（禁用 scheduler 同步处理） |
+
+## 核心方法（GeneralMemCube）
 
-## API 总结 (`GeneralMemCube`)
+GeneralMemCube 是 MemCube 的标准实现，通过统一的接口管理系统的所有记忆。GeneralMemCube 提供以下核心方法来管理记忆数据的生命周期。
 
 ### 初始化
 
@@ -104,7 +116,7 @@ mem_cube = GeneralMemCube(config)
 
 ## 文件存储
 
-MemCube 目录包含：
+MemCube 保存后的目录包含以下文件，每个文件对应一种记忆类型：
 
 - `config.json` (MemCube 配置)
 - `textual_memory.json` (明文记忆)
@@ -273,6 +285,6 @@ for i, mem in enumerate(memories[:2], 1):  # 显示前2条
 
 ## 开发者说明
 
-* MemCube 强制执行模式一致性以确保安全的加载/转储
-* 每种记忆类型都是可插拔的且独立测试
+* MemCube 强制执行模式一致性，确保安全的加载/转储
+* 每种记忆类型都是可插拔的，支持独立测试
 * 参见 `/tests/mem_cube/` 了解集成测试和使用模式
diff --git a/content/cn/open_source/modules/mem_feedback.md b/content/cn/open_source/modules/mem_feedback.md
index 759c91e2..3bd312bf 100644
--- a/content/cn/open_source/modules/mem_feedback.md
+++ b/content/cn/open_source/modules/mem_feedback.md
@@ -1,6 +1,6 @@
 ---
 title: MemFeedback
-desc: "MemFeedback 让你的 Agent 能够听懂“你记错了”，并自动修正记忆库。它是实现记忆自进化的关键组件。"
+desc: "MemFeedback 是你的“记忆错题本”，让你的 Agent 能够听懂“你记错了”，并自动修正记忆库。它是实现记忆自进化的关键组件。"
 ---
 
 ## 1. 简介
diff --git a/content/cn/open_source/modules/mem_reader.md b/content/cn/open_source/modules/mem_reader.md
index 429a25b9..358d36e1 100644
--- a/content/cn/open_source/modules/mem_reader.md
+++ b/content/cn/open_source/modules/mem_reader.md
@@ -1,6 +1,6 @@
 ---
 title: "MemReader"
-desc: "MemReader 是 MemOS 的“记忆翻译官”。它负责把用户杂乱的输入（聊天、文档、图片）翻译成系统能理解的、结构化的记忆片段。"
+desc: “MemReader 是你的“记忆翻译官”。它负责把杂乱的输入（聊天、文档、图片）翻译成系统能理解的、结构化的记忆片段。"
 ---
 
 ## 1. 简介
@@ -23,7 +23,7 @@ MemReader 设计了两种工作模式，分别对应“快”和“准”两种
 *   **适用场景**：
     *   用户发消息飞快，系统需要毫秒级响应。
     *   只需保留对话的“快照”，不需要深度理解。
-*   **产物**：原始文本片段 + 向量索引。
+*   **产物**：原始文本片段 + 向量索引 + 来源追踪 (Sources)。
 
 ### 🧠 Fine 模式（精雕细琢）
 *   **特点**：**调用 LLM** 进行深度分析。
@@ -31,7 +31,7 @@ MemReader 设计了两种工作模式，分别对应“快”和“准”两种
     *   长时记忆写入（需要提取关键事实）。
     *   文档分析（需要总结核心观点）。
     *   多模态理解（需要看懂图片里的内容）。
-*   **产物**：结构化的事实 + 摘要 (Background) + 来源追踪 (Provenance)。
+*   **产物**：结构化的事实 + 关键信息提取 (Key) + 背景 (Background) + 向量索引 + 来源追踪 (Sources) + 多模态细节。
 
 ---
 
@@ -86,8 +86,10 @@ memories = reader.get_memory(
 
 **返回结果**：`list[list[TextualMemoryItem]]`
 
+::note{icon="ri:bnb-fill"}
 为什么是双层列表？  
 因为一个长对话可能会被切成多个窗口（Window），外层列表代表窗口，内层列表代表该窗口提取出的记忆项。
+::
 
 ---
 
@@ -174,9 +176,9 @@ refined_memories = reader.fine_transfer_simple_mem(
 
 在 `.env` 或配置文件中，你可以调整以下关键参数：
 
-*   **`chat_window_max_tokens`**: **滑窗大小**。默认 1024。决定了多少上下文会被打包在一起处理。设得太小容易丢失语境，设得太大容易爆 LLM 的 Token 限制。
-*   **`remove_prompt_example`**: **是否移除 Prompt 里的示例**。如果你想节省 Token，可以设为 True；如果你发现提取效果不好，建议设为 False（保留 Few-shot 示例）。
-*   **`direct_markdown_hostnames`** (仅多模态): **域名白名单**。如果文件 URL 的域名在这个名单里（比如 `raw.githubusercontent.com`），Reader 会直接把它当 Markdown 文本处理，而不是去尝试 OCR 或转换，效率更高。
+*   **`chat_window_max_tokens`**: **滑窗大小**。默认 1024。决定了多少上下文会被打包在一起处理。设得太小容易丢失语境，设得太大容易超出 LLM 的 Token 限制。
+*   **`remove_prompt_example`**: **是否移除 Prompt 里的示例**。True = 省 Token 但可能降低提取质量；False = 保留示例提高准确度但消耗更多 Token（保留 Few-shot 示例）。
+*   **`direct_markdown_hostnames`** (仅多模态): **域名白名单**。列表中的域名（如 `raw.githubusercontent.com`）会被直接当作 Markdown 文本处理，跳过 OCR/格式转换步骤，加速处理。
 
 
 
diff --git a/content/cn/open_source/modules/mem_scheduler.md b/content/cn/open_source/modules/mem_scheduler.md
index 2f06dc6d..ddb16c43 100644
--- a/content/cn/open_source/modules/mem_scheduler.md
+++ b/content/cn/open_source/modules/mem_scheduler.md
@@ -1,6 +1,6 @@
 ---
-title: "MemScheduler: 记忆组织调度器"
-desc: "`MemScheduler` 是一个与 MemOS 系统并行运行的并发记忆管理系统，它协调 AI 系统中工作记忆、长时记忆和激活记忆之间的记忆操作。它通过事件驱动调度处理记忆检索、更新和压缩。<br/> 该系统特别适合需要动态记忆管理的对话代理和推理系统。"
+title: "MemScheduler"
+desc: "MemScheduler 是你的“记忆组织调度器”，它在后台异步管理记忆的流转和更新，协调工作记忆、长时记忆和激活记忆之间的交互，让对话系统能够动态地组织和利用记忆。"
 ---
 
 ## 主要特性
@@ -12,19 +12,24 @@ desc: "`MemScheduler` 是一个与 MemOS 系统并行运行的并发记忆管理
 - 📊 **全面监控**：实时监控记忆使用率、任务队列状态和调度延迟。
 - 📝 **详细日志记录**：全链路追踪记忆操作，便于调试和系统分析。
 
-## 记忆调度器架构
+##  MemScheduler 架构
 
-`MemScheduler` 系统采用模块化架构，核心组件如下：
+`MemScheduler` 采用模块化架构，分为三层：
 
-1. **消息处理**：核心调度引擎，通过带有特定标签（Label）的消息来驱动业务逻辑。
-2. **任务队列**：支持 Redis Stream (生产环境推荐) 和 Local Queue (开发测试) 两种模式，用于缓冲和持久化任务。
-3. **记忆管理**：负责不同层级记忆（Working/Long-term/User）的读写、压缩和遗忘策略，以及同类型记忆的组织和不同类型记忆间的转换。
-4. **检索系统**：结合用户意图、历史记忆场景管理与关键词匹配的混合检索模块。
-5. **监控**：跟踪任务积压情况、处理耗时以及记忆库的健康状态。
-6. **调度器 (路由器)**：智能路由器，根据消息类型（如 `QUERY`, `ANSWER`, `MEM_UPDATE`）和预设的触发埋点将任务分发给对应的处理任务。
-7. **日志记录**：维护记忆操作日志用于调试和分析。
+### 调度层（核心）
+1. **调度器（路由器）**：智能消息路由器，根据消息类型（`QUERY`, `ANSWER`, `MEM_UPDATE` 等）将任务分发给对应的处理器。
+2. **消息处理**：通过带有特定标签（Label）的消息驱动业务逻辑，定义消息格式和处理规则。
 
-## 记忆调度组件 MemScheduler 的初始化方法
+### 执行层（保障）
+3. **任务队列**：支持 Redis Stream（生产环境）和 Local Queue（开发测试）两种模式，提供异步任务缓冲和持久化。
+4. **记忆管理**：执行三层记忆（Working/Long-term/User）的读写、压缩、遗忘和类型转换。
+5. **检索系统**：混合检索模块，结合用户意图、场景管理与关键词匹配，快速定位相关记忆。
+
+### 支撑层（辅助）
+6. **监控**：跟踪任务积压、处理耗时和记忆库健康状态。
+7. **日志记录**：维护全链路记忆操作日志，便于调试和分析。
+
+##  MemScheduler 初始化
 
 在 MemOS 的架构中，`MemScheduler` 是作为服务器组件的一部分在启动时被初始化的。
 
@@ -62,12 +67,14 @@ redis_client = components["redis_client"]
 ```
 
 
-## 当前版本记忆调度默认设置的调度任务以及任务触发消息
+## 调度任务与数据模型
 
-调度器通过注册特定的任务标签（Label）与处理器（Handler）来分发和执行任务。以下是当前版本（基于 `GeneralScheduler` 和 `OptimizedScheduler`）默认支持的调度任务：
+调度器通过消息驱动的方式分发和执行任务。本节介绍支持的任务类型、消息结构和执行日志。
 
 ### 消息类型与处理器
 
+调度器通过注册特定的任务标签（Label）与处理器（Handler）来分发和执行任务。以下是当前版本（基于 `GeneralScheduler` 和 `OptimizedScheduler`）默认支持的调度任务：
+
 | 消息标签 (Label) | 对应常量 | 处理器方法 | 描述 |
 | :--- | :--- | :--- | :--- |
 | `query` | `QUERY_TASK_LABEL` | `_query_message_consumer` | 处理用户查询，触发意图识别、记忆检索，并将其转换为记忆更新任务。 |
@@ -80,7 +87,7 @@ redis_client = components["redis_client"]
 | `mem_feedback` | `MEM_FEEDBACK_TASK_LABEL` | `_mem_feedback_message_consumer` | 处理用户反馈，用于修正记忆或强化偏好。 |
 | `api_mix_search` | `API_MIX_SEARCH_TASK_LABEL` | `_api_mix_search_message_consumer` | (OptimizedScheduler 特有) 执行异步混合搜索任务，结合快速检索与精细检索。 |
 
-### 调度消息结构 (ScheduleMessageItem)
+### 消息数据结构 (ScheduleMessageItem)
 
 调度器使用统一的 `ScheduleMessageItem` 结构在队列中传递消息。
 
@@ -101,7 +108,7 @@ redis_client = components["redis_client"]
 | `info` | `dict` | 额外的自定义上下文信息 | `None` |
 | `stream_key` | `str` | (内部使用) Redis Stream 的键名 | `""` |
 
-### Web 日志结构 (ScheduleLogForWebItem)
+### 执行日志结构 (ScheduleLogForWebItem)
 
 调度器会生成用于前端展示或持久化存储的结构化日志消息。
 
diff --git a/content/cn/open_source/modules/mos/overview.md b/content/cn/open_source/modules/mos/overview.md
index e5ec5cef..fc239dcf 100644
--- a/content/cn/open_source/modules/mos/overview.md
+++ b/content/cn/open_source/modules/mos/overview.md
@@ -4,31 +4,29 @@ desc: MemOS v2.0 采用了更加模块化和解耦的架构。旧版的 MOS 类
 ---
 
 
-这种架构将“系统的构建”（Components）与“业务逻辑的执行”（Handlers）分离开来，使得系统更易于扩展、测试和维护。
+这种架构将“系统的元件”（Components）与“业务逻辑的执行”（Handlers）分离开来，使得系统更易于扩展、测试和维护。
 
 ## 1. 核心概念
 
 ### 1.1 Components (核心组件)
 
-Components 是 MemOS 的“大脑”和“基础设施”，它们在服务器启动时被初始化（通过 `init_server()`），并在整个生命周期中复用。
+Components 是 MemOS 的各个“器官”，它们在服务器启动时被初始化（通过 `init_server()`），并在整个生命周期中复用。
 
 核心组件包括：
 
 #### 核心记忆组件
 
-1. **MemCube**: 记忆容器, 用于隔离不同用户/不同 cube 的记忆, 并统一管理多种记忆模块.  
-2. **MemReader**: 记忆加工器, 把用户输入（聊天, 文档, 图片）解析为系统可写入的记忆片段.  
-3. **MemScheduler**: 调度器, 负责将耗时的记忆写入, 索引构建, 记忆组织等任务异步化并并发执行.mem_scheduler.  
-4. **MemChat**: 对话控制器, 负责“检索记忆 -> 生成回复 -> 写入新记忆”的对话闭环.  
-5. **MemFeedback**: 纠错与反馈, 用于把用户的自然语言反馈转换成对记忆库的安全修正.  
+1. **MemCube**: 记忆容器, 用于隔离不同用户/不同应用场景的记忆, 并统一管理多种记忆模块.  
+2. **MemReader**: 记忆加工器, 把用户输入的各类素材（聊天, 文档, 图片）解析为系统可写入的记忆片段.  
+3. **MemScheduler**: 后台调度器, 负责管理后台任务队列，将记忆的存储、索引、组织等耗时操作异步处理，支持多任务的并发执行.  
+4. **MemChat**: 对话控制器, 负责在对话过程中自动进行“记忆检索 -> 上下文管理 -> LLM 调度 -> 记忆更新”的对话闭环.  
+5. **MemFeedback**: 记忆纠错器，自动理解用户的自然语言反馈，精准定位冲突记忆并执行原子级修正（纠错/补充/替换）.
 
 ### 1.2 Handlers (业务处理器)
 
-Handlers 是 MemOS 的“手”，它们封装了具体的业务逻辑，通过调用 Components 来完成任务。
+Handlers 是 MemOS 的“大脑”，它们封装了具体的业务逻辑（如添加、搜索、对话），通过调用和协调 Components （器官）的各项能力来完成具体的用户任务。
 
-主要 Handler 包括：
-
-## 核心 Handler 概览
+#### 核心 Handler 概览
 
 | Handler | 作用 | 核心方法 |
 | :--- | :--- | :--- |
@@ -45,64 +43,64 @@ Handlers 是 MemOS 的“手”，它们封装了具体的业务逻辑，通过
 ### 2.1 初始化 (Initialization)
 初始化是系统启动的基石。所有 Handler 的运行都依赖于统一的组件注册与依赖注入机制。
 
-- 组件加载 ( init_server ) : 系统首先会初始化所有核心组件，包括 LLM（大语言模型）、存储层（向量数据库、图数据库）、调度器（Scheduler）以及各类内存立方体（Memory Cube）。
-- 依赖注入 ( HandlerDependencies ) : 为了保证代码的解耦与可测试性，所有组件会被封装进 HandlerDependencies 对象中。Handler 在实例化时统一接收这个依赖容器，从而按需获取 naive_mem_cube 、 mem_reader 或 feedback_server 等资源，而无需在内部硬编码实例化过程。
+- 组件加载 ( init_server ) : 系统启动时会初始化所有核心组件，包括 LLM（大语言模型）、存储层（向量数据库、图数据库）、调度器（Scheduler）以及各类 Memory Cube。
+- 依赖注入 ( HandlerDependencies ) : 为了保证代码的解耦与可测试性，所有组件被统一封装到一个依赖容器（`HandlerDependencies`）中。当 Handler 启动时，只需接收这个容器，就能获取所需的 `naive_mem_cube`、`mem_reader`、`feedback_server` 等资源，而无需各自重复创建这些组件。
 
 ### 2.2 添加记忆 (AddHandler)
-AddHandler 是将外部信息转化为系统记忆的核心入口，支持处理对话、文件上传及纯文本输入。它不仅负责写入，还承担了部分反馈路由的职责。
+AddHandler 是大脑的"记忆接纳指令"，负责将外部信息转化并写入系统记忆。它不仅负责接纳和转化各类信息，还能自动识别反馈并路由到专门的反馈处理流程。
 
 - 核心功能 :
-  - 多模态支持 : 能够处理用户对话列表（Messages），将其转化为系统内部的记忆对象。
-  - 同步与异步模式 : 通过 async_mode 参数控制。生产环境推荐使用 "async" 模式，任务会被推入后台队列，通过 Scheduler 调度执行，接口立即返回 task_id ；调试时可使用 "sync" 阻塞等待结果。
-  - 自动反馈路由 : 如果在请求中标记了 is_feedback=True ，Handler 会自动提取对话中的最后一条用户消息作为反馈内容，并将其路由至反馈处理逻辑，而不是作为普通新记忆添加。
-  - 多目标写入 : 支持通过 writable_cube_ids 指定多个目标 Cube。如果指定了多个目标，Handler 会自动构建 CompositeCubeView 并行分发写入任务；如果仅单一目标，则使用轻量级的 SingleCubeView 。
+  - 多模态支持 : 能够处理用户对话、文档、图片等多种输入形式，统一转化为系统内部的记忆对象。
+  - 同步与异步模式 : 通过 `async_mode` 参数控制处理方式。**同步模式**（"sync"）：立即处理，调用者阻塞等待结果，适合调试；**异步模式**（"async"）：任务推入后台队列由 MemScheduler 并发处理，API 立即返回任务 ID，适合生产环境提升响应速度。
+  - 自动反馈路由 : 如果请求中标记了 `is_feedback=True`，Handler 会自动提取对话中的最后一条用户消息作为反馈内容，将其转发到 MemFeedback 处理，而不是作为普通新记忆添加。
+  - 多目标写入 : 支持向多个 MemCube 同时写入记忆。当指定多个目标 Cube 时，系统会并行处理所有写入任务；当仅有一个目标时，则使用轻量级的处理方式。
 
 ### 2.3 搜索记忆 (SearchHandler)
-SearchHandler 提供了基于语义的记忆检索服务，是实现 RAG（检索增强生成）的关键组件。
+SearchHandler 是大脑的"记忆检索指令"，提供基于语义的智能记忆查询能力，是实现 RAG（检索增强生成）的关键组件。
 
 - 核心功能 :
-  - 语义检索 : 利用向量嵌入（Embedding）技术，根据查询语句的语义相似度召回相关记忆，而非简单的关键词匹配。
-  - 灵活的搜索范围 : 通过 readable_cube_ids 参数，调用者可以精确控制搜索的上下文范围（例如仅搜索特定用户的记忆，或跨用户搜索公共记忆）。
-  - 多模式策略 : 底层支持多种搜索策略（如 fast 快速检索、 fine 精细检索或 mixture 混合检索），以在响应速度和召回准确率之间取得平衡。
-  - 深度搜索集成 : 能够集成 deepsearch_agent ，处理更复杂的、需要多步推理的检索请求。
+  - 语义检索 : 利用向量嵌入（Embedding）技术，根据查询语句的语义相似度召回相关记忆，相比简单的关键词匹配，能更准确地理解用户意图。
+  - 灵活的搜索范围 : 支持指定检索的目标数据范围。例如，可以仅在特定用户的记忆库中搜索，也可以跨多个用户搜索共享的公开记忆，满足不同的隐私和业务需求。
+  - 多种检索模式 : 根据应用场景在速度和准确率之间灵活选择。**快速模式**适合实时性要求高的场景，**精细模式**适合追求高记忆精准度的场景，**混合模式**兼顾两者。
+  - 多步推理检索 : 对于复杂问题，支持引入深度推理能力，通过多轮理解和检索逐步逼近最相关的记忆。
 
 ### 2.4 对话 (ChatHandler)
-ChatHandler 是上层业务逻辑的编排者（Orchestrator），它不直接存储数据，而是通过组合其他 Handler 来完成端到端的对话任务。
+ChatHandler 是大脑的"对话协调指令"，负责将用户的对话需求转化为完整的业务流程。它不直接存储数据，而是通过协调其他 Handler 来完成端到端的对话任务。
 
 - 核心功能 :
-  - 流程编排 : 自动串联 "检索 -> 生成 -> 存储" 的全过程。首先调用 SearchHandler 获取上下文，然后调用 LLM 生成回复，最后调用 AddHandler 将新产生的对话记录保存为记忆。
-  - 上下文管理 : 负责处理 history （历史对话）与 query （当前问题）的拼接，确保 AI 理解完整的对话语境。
-  - 流式与非流式 : 支持标准响应（ APIChatCompleteRequest ）和流式响应（Stream），适应不同的前端交互需求。
-  - 通知集成 : 可选集成 online_bot （如钉钉机器人），在生成回复后自动推送通知。
+  - 流程编排 : 自动执行"记忆检索 → LLM 生成 → 记忆保存"的完整对话闭环。用户每次提问都能基于历史记忆获得更智能的回复，同时每一次对话都被沉淀为新的记忆，实现对话即学习。
+  - 上下文管理 : 负责处理 history （历史对话）与 query （当前问题）的拼接，确保 LLM 理解完整的对话语境，避免信息丢失。
+  - 多种交互模式 : 支持标准请求-响应模式（ APIChatCompleteRequest ）和流式响应（Stream）模式，标准模式适合简单问题，流式模式适合长文本回复，满足不同的前端交互需求。
+  - 消息推送（可选） : 支持在生成回复后自动将结果推送到第三方平台（如钉钉），实现多渠道集成。
 
 ### 2.5 反馈与修正 (FeedbackHandler)
-FeedbackHandler 是系统的"自我修正"机制，允许用户对 AI 的表现进行干预，从而优化未来的记忆检索与生成。
+FeedbackHandler 是大脑的"反馈纠正指令"，负责理解用户对 AI 表现的自然语言反馈，自动精准定位并修正相关的记忆内容。
 
 - 核心功能 :
-  - 记忆修正 : 当用户指出 AI 的错误（如"会议地点不是北京是上海"）时，Handler 会根据用户的反馈内容更新或标记旧的记忆节点。
-  - 正负反馈 : 支持处理点赞（Upvote）或点踩（Downvote）信号，调整特定记忆的权重或可信度。
-  - 精准定位 : 除了基于对话历史的反馈，还支持通过 retrieved_memory_ids 参数，针对某几条具体的检索结果进行精确修正，提高反馈的有效性。
+  - 记忆修正 : 当用户指出 AI 的错误（如"会议地点不是北京是上海"）时，Handler 会自动更新或标记相关的旧记忆。系统采用版本管理而非直接删除，保持修改历史的可追溯性。
+  - 正负反馈 : 支持用户通过点赞或点踩的方式标记特定记忆的质量。系统据此调整该记忆的权重和可信度，使后续检索更加准确。
+  - 精准定位 : 支持两种反馈方式。一种是基于对话历史自动定位冲突信息，另一种是用户直接指定具体的记忆来修正，提高反馈的有效性和准确度。
 
 ### 2.6 记忆管理 (MemoryHandler)
-MemoryHandler 提供了对记忆数据的底层 CRUD（增删改查）能力，主要用于系统管理后台或数据清理工具。
+MemoryHandler 是大脑的"记忆管理指令"，提供了对记忆数据的底层 CRUD（增删改查）能力，主要用于系统管理后台或数据清理等运维场景。
 
 - 核心功能 :
-  - 精细化管理 : 不同于 AddHandler 的业务级写入，此 Handler 允许通过 memory_id 直接获取单条记忆详情或执行物理删除。
-  - 依赖直通 : 部分操作需要直接与底层的 naive_mem_cube 组件交互，绕过复杂的业务包装，以提供最高效的数据操作能力。
+  - 精细化管理 : 不同于 AddHandler 的业务级写入，此 Handler 允许通过记忆 ID 直接获取单条记忆的详细信息或执行物理删除。这种直接操作方式绕过了业务逻辑的包装，主要用于调试、审计或系统清理。
+  - 底层直通 : 某些管理操作需要直接与底层的记忆器官（naive_mem_cube）交互，以提供最高效和最低延迟的数据操作能力，满足系统运维的需求。
 
 ### 2.7 任务调度状态 (SchedulerHandler)
-SchedulerHandler 负责监控系统中所有异步任务的生命周期，是系统可观测性的重要组成部分。
+SchedulerHandler 是大脑的"任务监控指令"，负责追踪系统中所有异步任务的实时执行状态，让用户能够了解后台任务的进度和结果。
 
 - 核心功能 :
   - 状态追踪 : 配合 Redis 后端，追踪任务的实时状态（Queued 排队中, Running 执行中, Completed 已完成, Failed 已失败）。
-  - 结果获取 : 对于异步执行的任务，客户端可以通过此接口轮询任务进度，并在任务完成后获取最终的执行结果或错误信息。
-  - 调试支持 : 提供 handle_scheduler_wait 等工具函数，允许在测试脚本中将异步流程强制转为同步等待，便于集成测试。
+  - 结果获取 : 提供任务结果查询接口。当异步任务完成后，用户可以通过此接口获取最终的执行结果或错误信息，从而了解操作是否成功以及失败的原因。
+  - 同步等待（调试工具） : 在测试和集成测试时，提供将异步任务强制转为同步等待的工具，使开发者能够像调试同步代码一样调试异步流程，提高开发效率。
 
 ### 2.8 猜你想问 (SuggestionHandler)
-SuggestionHandler 旨在通过预测用户的潜在意图来提升交互体验，生成"推荐问题"（Next Query Suggestion）。
+SuggestionHandler 是大脑的"建议生成指令"，通过预测用户的潜在需求，主动推荐相关问题，帮助用户探索系统能力和发现感兴趣的话题。
 
 - 核心功能 :
   - 双模式生成 :
-    - 基于对话 : 如果提供了 message （最近的对话记录），系统会分析对话上下文，生成 3 个与当前话题紧密相关的后续问题。
-    - 基于记忆 : 如果没有对话上下文，系统会调用 naive_mem_cube 快速检索用户的"最近记忆"，并据此生成与用户近期生活/工作状态相关的问题。
-  - 多语言支持 : 内置中英文提示词模板，根据 language 参数自动切换生成的语言风格。
+    - 基于对话的建议 : 当用户提供了最近的对话记录时，系统分析对话上下文，推断用户可能感兴趣的后续话题，生成 3 个相关的推荐问题。
+    - 基于用户画像的建议 : 当没有对话上下文时，系统从用户的近期记忆中推断其兴趣和状态，生成与用户最近生活或工作相关的推荐问题。这适合在对话开始或话题转换时使用。
+  - 多语言支持 : 推荐问题自动适配用户语言设置，支持中英文等多种语言，提升不同用户的体验。