微信
飞书
选择您喜欢的方式加入群聊
扫码添加咨询专家
如果你用过任何对话式 AI 产品，大概率经历过这样一个场景：
你在第一次对话中告诉 AI："以后回答销售额这类指标，应该带上具体时间。"
AI 回答："好的，我记住了。"
第二天，你开启一个新的对话窗口问："上个月销售额怎么样？"
AI 回答："上个月销售额是 320 万。" —— 没有时间范围。
你只好再说一遍："我说过要带时间的。"
AI："抱歉，下次我会注意。"
这不是 AI 不够聪明。这是对话式 AI 的一个系统性缺陷。
每一次新对话，对 AI 来说都是一次"初次见面"。你之前说过的所有偏好、上下文、习惯，统统归零。
今天这篇文章，我想从用户体验的视角，聊聊我们如何在 AskTable 中构建永久记忆系统，以及它为什么是 AI 数据分析产品从"可用"走向"好用"的关键一步。
当前主流的对话式 AI 产品，记忆范围仅限于当前会话的上下文窗口。这意味着：
这种设计在早期的通用聊天场景中勉强可以接受——用户本来就是在"问问题"，问完就走。但在数据分析场景下，问题被成倍放大。
数据分析不是一个"问完就走"的场景。它是一个持续的、迭代的、有累积效应的工作流。
让我们来看一个真实的用户旅程：
第一天：运营经理小李第一次使用 AI 数据分析工具。他花了很多时间告诉 AI 公司的业务口径——GMV 怎么算、退货怎么处理、华东区包含哪些省份。AI 表示都理解了。
第二天：小李继续工作，但昨天定义的口径全部失效。他不得不再说一遍。
第一周：小李已经说了五遍同样的事情。他开始怀疑这个工具到底值不值得用。
第一个月：小李放弃了 AI 工具，回到了 Excel。因为"教它的时间比我自己查还长"。
这就是没有记忆系统的 AI 在数据分析场景下的真实命运。
| 场景 | 无记忆的体验 | 有记忆的体验 |
|---|---|---|
| 第一次定义"GMV"口径 | AI 理解 | AI 理解 |
| 第二次问 GMV | 需要重新解释口径 | AI 直接用你定义的口径 |
| 第三次做月度报告 | 再次说明格式偏好 | AI 按偏好生成 |
| 第 N 次查询 | 仍然需要从头说明 | AI 像老同事一样默契 |
问题的本质不是 AI 不够智能，而是每次对话都从零开始。
就像你每次和同一个同事沟通，他都要你重新自我介绍一遍。这不叫智能，这叫效率杀手。
用户在和 AI 交互时，天然带有一种"拟人化"的期待：
"我都告诉你一遍了，你怎么又忘了？"
这种抱怨背后，反映的是用户对 AI 的连续性人格预期——用户希望 AI 是一个"认识自己"的助手，而不是每次重启的陌生机器。
从心理学角度看，这是关系型交互的基本需求。人类在与任何智能体（无论是人还是机器）交互时，都会期望对方具备一定的"记忆连续性"。这是建立信任和使用习惯的基础。
从技术角度看，这种期待也非常合理。因为人类的助理确实是这样工作的：你告诉过一次的事情，不需要反复说。
市场上也有一些产品试图解决这个问题，但普遍存在以下局限：
这些方案要么不够自动化，要么不够灵活，要么不够精确。
永久记忆，指的是 AI 能够跨会话、跨对话、跨时间记住用户的偏好、习惯、定义和上下文，并在后续交互中自动应用这些记忆。
具体来说：
而且这些记忆不是被动存储，而是在你提问时主动召回并应用。
在 AskTable 的数据分析场景中，我们识别出了几类核心记忆：
1. 偏好记忆
用户在使用过程中的个人偏好设置，比如：
2. 定义记忆
用户对业务指标和术语的定义，比如：
3. 关注记忆
用户经常关注的维度、区域、时间窗口等，比如：
4. 纠错记忆
用户在历史对话中纠正过的错误，比如：
在 AskTable 中，记忆系统的运作可以概括为两个阶段、四个环节：
## 历史记忆
- 用户提问销售额、利润率等指标时，应带上具体时间段（2026-04-01）
- 用户主要关注华东区域的数据（2026-03-15）
- 偏好在图表中显示同比和环比增长率（2026-03-20）
这四个环节分别是：
1. 读取（Search）
在用户发起新请求时，系统从记忆库中检索与当前问题相关的历史记忆。这个过程发生在请求处理的早期阶段，确保后续分析已经带上了记忆上下文。
具体来说，当用户输入"上个月华东区的销售额怎么样"时，系统会：
2. 注入（Inject）
将检索到的记忆格式化为结构化的上下文提示，注入到 AI 的系统提示词中。AI 在生成回答时，会自然地将这些记忆考虑进去。
注入的上下文大致如下：
## 历史记忆
- 用户提问销售额、利润率等指标时，应带上具体时间段（2026-04-01）
- 用户主要关注华东区域的数据（2026-03-15）
- 偏好在图表中显示同比和环比增长率（2026-03-20）
这些记忆条目会被附加到系统提示的末尾，让 AI 在生成回答时自动应用。
3. 提取（Extract）
在 AI 完成回复后，系统分析本轮对话，提取其中可能构成新记忆的片段——比如用户的偏好声明、指标定义、纠正反馈等。
例如，用户在对话中说："以后不要用饼图，用柱状图更好对比。"系统会通过 LLM 分析这句话，提取出结构化的记忆条目："用户偏好使用柱状图而非饼图进行数据对比。"
4. 存储（Store）
将提取到的新记忆写入向量数据库，建立索引，供后续查询使用。每条记忆都会附带时间戳和来源信息，便于后续的管理和追溯。
在工程实现上，我们采用了读写分离的架构：
这种设计的关键考量是：
读取影响当下，写入影响未来。
读取直接决定了当前回答的质量——如果记忆没有及时加载，AI 就会像失忆一样回答错误。因此读取必须是同步的、低延迟的。
写入则是为了优化未来的体验——即使用户这次对话的记忆没有立即写入，也只是下次对话少一条记忆，不影响当前的使用体验。因此写入可以异步化、fire-and-forget。
用户不需要等待"记忆写入完成"才能看到回答。AI 先给你结果，然后默默在后台学习。
在记忆系统的技术栈选择上，我们最终选定了 mem0 作为记忆管理框架，配合 Qdrant 作为向量存储。
为什么是 mem0？
1. 专注记忆这一件事
mem0 的定位非常清晰——为 AI 应用提供持久化记忆能力。它不是大而全的 Agent 框架，而是专门解决"记忆存储、检索、更新"的中间件。这种专注性意味着：
2. 开箱即用的记忆操作
mem0 提供了三个核心 API：
add() —— 添加新记忆
search() —— 检索相关记忆
update() —— 更新已有记忆
delete() —— 删除指定记忆
这与我们的"读-写-更新-删除"需求高度吻合。我们不需要在底层自己实现记忆的增删改查逻辑。
3. LLM 驱动的智能提取
mem0 的 add 操作不是简单地把对话内容存入数据库，而是通过 LLM 对对话进行分析，提取结构化的记忆片段。这意味着：
这种智能提取能力，大大降低了应用层的记忆管理复杂度。我们不需要自己写规则来解析用户意图，mem0 内部已经通过 LLM 完成了这一步。
Qdrant 是一个开源的向量数据库，我们选择它主要基于以下考量：
1. 高性能的相似度搜索
记忆检索的核心是"找到与当前问题最相关的历史记忆"。Qdrant 的 HNSW 索引在向量相似度搜索场景下表现优异，能够在毫秒级返回 Top-K 相关记忆。
在我们的测试中，即使在数千条记忆的规模下，检索延迟仍然保持在 10ms 以内，完全满足实时对话的需求。
2. 元数据过滤
记忆不仅包含向量表示，还需要附带时间戳、来源、类型等元数据。Qdrant 支持向量搜索 + 元数据过滤的组合查询，这对于记忆的精确召回非常重要。
例如，我们可以查询"与销售额相关且最近 30 天内创建的偏好记忆"，这种组合查询能力是纯向量搜索无法提供的。
3. 部署灵活
Qdrant 支持 Docker 容器化部署，也支持云服务，与我们的整体技术栈兼容性良好。对于有本地化部署需求的企业客户，Qdrant 也可以完全在客户内网运行。
这是整个记忆系统设计中最关键的架构决策之一。
记忆系统有多种隔离粒度可选：
| 隔离粒度 | 说明 | 适用场景 |
|---|---|---|
| 用户级 | 每个用户独立的记忆空间 | 个人助手 |
| 会话级 | 每个会话独立的记忆 | 无（失去了跨会话的意义） |
| Agent 级 | 同一 Agent 下所有用户共享记忆 | 团队知识库 |
| 组织级 | 整个组织共享 | 大型企业知识库 |
AskTable 选择了 Agent 级 的隔离粒度。这意味着：
同一个 Data Agent 下，所有用户的记忆是共享的。A 用户定义的"GMV"口径，B 用户在提问时也能享受到这个记忆。
为什么这样设计？
1. 团队知识库模式
在数据分析场景中，指标定义、业务口径、偏好设置往往不是个人化的，而是团队层面的共识。A 用户告诉 AI "GMV 包含退款金额"，这个定义对 B 用户同样适用。
如果采用用户级隔离，就会出现"A 定义的 GMV 和 B 定义的 GMV 不一致"的混乱情况。
2. 降低重复沟通成本
如果采用用户级隔离，团队中每个人都要向 AI 重复一遍相同的定义和偏好。这与我们解决"重复说明"痛点的初衷背道而驰。
我们的目标就是让团队不需要反复说明同一件事。Agent 级共享是实现这一目标的前提。
3. 记忆即知识沉淀
随着团队使用时间的增长，Agent 的记忆库会自然沉淀为一份活的团队知识库。新加入的成员不需要重新教 AI 任何东西，AI 已经"认识"团队了。
这种知识沉淀的价值，远超过简单的对话效率提升。它实际上是在构建团队的数据资产。
4. 与 AskTable 的产品模型一致
AskTable 的核心产品单元是 Data Agent。每个 Data Agent 对应一个特定的数据分析场景（如销售分析、运营监控等），有独立的数据源、分析模型和权限配置。记忆系统作为 Agent 的能力之一，自然也应该以 Agent 为边界。
当然，Agent 级共享也带来了挑战——比如如何处理用户之间的记忆冲突。这在实际运行中通过时间戳优先级和手动管理功能来解决。
在架构设计上，我们做了一个重要的决策：记忆能力通过 Protocol 层抽象，mem0 只是当前的一个实现。
┌─────────────────────────────────┐
│ Agent 框架层 │
│ (只依赖 MemoryProtocol 接口) │
├─────────────────────────────────┤
│ MemoryProtocol 抽象层 │
│ - search(query) │
│ - add(conversation) │
│ - update(id, content) │
│ - delete(id) │
├─────────────────────────────────┤
│ 实现层（可替换） │
│ ┌─────────┐ ┌──────────────┐ │
│ │ mem0 │ │ 自研方案(未来) │ │
│ │ +Qdrant │ │ │ │
│ └─────────┘ └──────────────┘ │
└─────────────────────────────────┘
这意味着：
这种设计的好处是显而易见的：
在没有记忆系统之前，用户的使用体验是这样的：
对话 1（4 月 1 日）：
用户："什么是我们的 GMV 计算口径？"
AI："请告诉我你们的 GMV 定义。"
用户："GMV 包含已付款和待付款订单，不包含退款。"
AI："好的，我理解了。"
对话 2（4 月 2 日）：
用户："本月 GMV 是多少？"
AI："本月 GMV 是 1,200 万。"
（没有带时间范围，没有用正确的口径）
用户："我说过 GMV 要包含待付款的，而且要带上时间！"
AI："抱歉，本月（2026-04-01 至 2026-04-30）GMV 是 1,350 万，
包含已付款和待付款订单。"
对话 3（4 月 3 日）：
用户："华东区的情况呢？"
AI："请问你指的是哪个区域？"
（不记得用户主要关注华东）
用户："算了，我自己查吧。"
对话 4（4 月 5 日）：
用户："生成月度报告。"
AI："好的，请问你需要包含哪些内容？图表用什么形式？
关注哪些区域？时间范围是？"
用户："......"
（用户关闭了浏览器）
每一次对话，用户都在重复相同的事情。久而久之，用户对 AI 的耐心被消耗殆尽。
这不是用户的问题，而是产品的问题。
有了永久记忆系统之后：
对话 1（4 月 1 日）：
用户："什么是我们的 GMV 计算口径？"
AI："请告诉我你们的 GMV 定义。"
用户："GMV 包含已付款和待付款订单，不包含退款。"
AI："好的，我理解了。"
（后台：记忆写入完成）
对话 2（4 月 2 日）：
用户："本月 GMV 是多少？"
AI："本月（2026-04-01 至 2026-04-30）GMV 是 1,350 万，
包含已付款和待付款订单。"
（自动带上了时间范围和正确的口径）
用户："不错。"
对话 3（4 月 3 日）：
用户："华东区的情况呢？"
AI："华东区本月 GMV 为 480 万，占比 35.6%，环比增长 12.3%。"
（自动应用了用户关注华东区域的记忆）
对话 4（4 月 5 日）：
用户："生成月度报告。"
AI：直接按照用户偏好的格式、关注的区域、正确的口径生成报告。
包含：华东区各省份数据、同比环比柱状图、时间范围标注。
用户："很好，直接发给老板。"
AI 不再需要用户反复教导。它在默默学习，然后默默应用。
| 维度 | Before | After |
|---|---|---|
| 新对话启动 | 零上下文 | 自动加载相关记忆 |
| 指标定义 | 每次需要重新说明 | 一次定义，全局生效 |
| 偏好设置 | 重复声明 | 自动应用 |
| 错误纠正 | 纠正后下次仍然犯错 | 纠正后永久生效 |
| 团队协作 | 每个人单独教 AI | 一个人定义，全员受益 |
| 新人上手 | 需要教 AI 一遍 | AI 已经认识团队 |
| 用户感受 | "它不记得我" | "它越来越懂我" |
为了让用户对记忆系统有充分的控制和可见性，我们在 Data Agent 配置页面新增了 "Memories" Tab。
这个 Tab 提供了以下功能：
1. 记忆总览
展示当前 Agent 的所有记忆条目，按时间倒序排列，每条记忆包含：
2. 搜索记忆
支持关键词搜索，快速定位特定的记忆条目。比如搜索"GMV"可以立即找到所有与 GMV 相关的记忆。
3. 手动添加记忆
用户可以直接在界面上手动添加记忆条目，而不需要通过对话来触发。这对于一些不需要通过对话表达的规则和偏好非常有用。
4. 删除记忆
用户可以对不再需要的记忆进行删除操作。比如某个指标口径已经变更，旧的口径记忆就可以删除。
5. 开关控制
用户可以选择关闭记忆功能。在某些场景下（如临时分析、测试数据等），用户可能不希望记忆系统介入。
6. 记忆质量反馈
未来我们将增加记忆质量反馈功能，用户可以对记忆的准确性进行标记，帮助系统持续优化。
任何新系统的引入都会带来新的挑战。记忆系统也不例外。以下是我们在实践中遇到的主要挑战以及应对策略。
问题
mem0 的 add 操作每次需要 1-2 次 LLM 调用（用于从对话中提取结构化记忆）。对于高频使用的场景，这笔开销不容忽视。
假设一个团队每天有 50 次对话，每次对话产生 1 条记忆，那么每天额外需要 50-100 次 LLM 调用。一个月就是 1,500-3,000 次。
应对策略
异步化执行
记忆写入在回复完成后异步执行，不增加用户感知的响应延迟。用户看到回答的速度不受影响。
批量处理
对于短时间内的多轮对话，合并提取而非逐条处理。比如用户在 10 分钟内连续问了 5 个问题，我们可以将这 5 轮对话合并为一次提取操作，而不是 5 次。
按需开启
用户可以在 Agent 配置中控制是否开启记忆功能。对于一些临时性的分析任务，可以关闭记忆以避免不必要的 LLM 开销。
阈值控制
当记忆库达到一定规模后，可以降低写入频率。因为随着记忆库的完善，新记忆的边际价值会逐渐递减。
问题
mem0 的事实提取 prompt 主要面向英文场景优化。在中文对话中，提取的准确性和结构化程度可能受到影响。
比如，英文场景下：
中文场景下：
应对策略
结构化记忆降低语言依赖
AskTable 的记忆内容偏向结构化（指标定义、偏好声明等），这类内容在跨语言场景下受语言模型的影响较小。因为结构化的内容本身就包含了足够的语义信息。
逐步优化 Prompt
后续可以根据中文场景的特点，定制提取 prompt 和记忆 schema。我们已经在规划针对中文的优化方案。
影响评估与监控
在实际使用中持续监控记忆质量，用数据驱动优化。我们会定期抽查记忆条目的准确性，确保提取质量在可接受范围内。
问题
当记忆系统出现"记错了"或"召回了不相关的记忆"时，如何定位问题？记忆系统的黑盒特性使得调试成为一个挑战。
典型的调试场景包括：
应对策略
前端可见性
在 Data Agent 配置页面的 Memories Tab 中，用户可以：
这种可见性让用户不再是"盲人摸象"，而是可以清楚地看到 AI 记住了什么。
Protocol 抽象确保可替换
通过 Protocol 层的抽象，确保 mem0 只是实现之一。如果后续发现 mem0 在可观测性方面不够好，我们可以切换到自研方案，提供更详细的 Trace 和 Debug 信息。
内部 Trace 记录
系统会记录记忆的检索和写入过程，包括：
这些 Trace 信息为问题排查提供了数据支撑。
问题
在 Agent 级共享记忆的场景下，不同用户可能对同一指标有不同定义。比如：
这两条记忆是矛盾的。AI 应该听谁的？
应对策略
时间戳优先级
最新的记忆覆盖旧的记忆。这符合"业务口径以最新定义为准"的常规逻辑。
冲突提示
当系统检测到潜在的记忆冲突时，可以在 Memories Tab 中标记出来，提醒用户注意。
手动管理
用户可以在 Memories Tab 中查看和编辑记忆，手动解决冲突。对于重要的指标定义，建议由数据负责人统一管理。
精细化隔离（未来）
考虑在特定场景下支持用户级隔离的记忆空间，与 Agent 级共享记忆并存。比如某些偏好是个人化的（如图表颜色偏好），而某些定义是团队共享的（如 GMV 口径）。
永久记忆系统是 AskTable AI 能力升级的第一步，但不是最后一步。以下是我们正在规划和探索的方向。
当前的记忆系统是扁平化的——所有记忆存储在同一个空间中。未来我们计划引入记忆分类：
不同类型的记忆在检索和应用时会有不同的策略：
记忆不是永恒不变的。随着业务的变化，某些记忆会过期、失效或需要更新。未来我们将引入：
当前的记忆系统是被动式的——只有在对话中用户明确声明时才会提取记忆。未来我们探索：
随着 AskTable 支持更多类型的 Agent，不同 Agent 之间的记忆共享和协同将成为一个重要课题：
我们设想的未来架构是：
┌─────────────────────────────────────┐
│ 组织级知识图谱 │
│ (跨 Agent 共享的元知识和业务定义) │
├────────────┬────────────┬────────────┤
│ 销售 Agent │ 运营 Agent │ 分析 Agent │
│ 专属记忆 │ 专属记忆 │ 专属记忆 │
└────────────┴────────────┴────────────┘
在组织级层面，共享通用的业务定义和术语；在 Agent 层面，保持各自的专属记忆。这样既保证了知识的一致性，又保证了记忆的针对性。
这些问题我们将在后续的版本中逐步探索。
永久记忆系统的本质，是让 AI 从一个"每次都是陌生人"的工具，变成一个"越来越懂你"的同事。
这不是一个锦上添花的功能，而是对话式 AI 从可用走向好用的基础设施。
在 AskTable 的实践中，我们通过 mem0 + Qdrant 的技术架构，实现了：
同时，我们通过前端可见的记忆管理功能，让用户能够查看、编辑、控制自己的记忆数据，确保记忆系统的透明度和可控性。
我们对记忆系统的设计哲学可以概括为一句话：
好的记忆系统不应该让用户感知到它的存在。 它应该像人类助理的记忆一样——自然、可靠、不需要刻意维护。
如果你对 AI 数据分析的智能体架构感兴趣，欢迎阅读我们关于 AskTable AI Agent 工作原理 的深入解析，以及 AskTable 如何将数据分析师打包为 AI 的文章。
关于记忆系统如何让 AI 成为不断成长的"数据团队"，我们也有一篇专门的讨论：记忆系统：让 AI 成为不断成长的数据团队。
核心观点：好的 AI 助手不应该让你每次都重新介绍自己。它应该记住你说过的每一句话，并在下一次对话中默默应用。这就是永久记忆的意义——不是技术炫技，而是让交互回归自然。
从认知建立到落地陪跑，我们提供完整的企业AI服务
无论是刚开始评估AI，还是已经准备好落地，我们都能提供对应的支持