Memory
User Memory vs. Agent Memory：两种记忆，两种侧重
AI 的记忆系统可以针对两个对象设计：User Memory 和 Agent（智能体）Memory。它们的功能各不相同，但目标都是提升用户体验。
User Memory：理解用户，建立"个人档案"
用户记忆的重点是围绕每位用户建立详细档案，从而记住他们的偏好、个性化需求和关键事件。
组成部分：
- 用户画像： 包括基本信息（年龄、兴趣）、偏好、关系网络等。
- 应用场景数据： 比如心理咨询应用中用户的性格特质，或者教育应用中用户的学习风格（比如“视觉型”）。
- 关键事件： 比如某用户的健身计划开始日期，或某段感情关系的变化。
适用场景： 需要高度个性化体验的应用，尤其是2C的应用，比如教育，笔记，陪聊，虚拟伴侣，游戏等泛娱乐类的应用。
Agent Memory： 则侧重于AI Agent 自身的学习与能力发展。它相当于为AI构建自己的记忆库，包括比如：
- 工作流程记忆：回忆多步骤流程、API调用以及与环境的互动，使其能够更高效地完成任务。这与开发者随时间积累编程技能颇为相似。
- 技能积累：学习特定技能，如编程、数据分析或图像识别，以应对日益复杂的任务。
- 错误日志：记住过去的错误，避免重复，并持续提升性能。
Agent memory 更倾向于优化工作流程，适合生产力、服务与自动化类应用，例如客服机器人，生产力工具和智能助手。
现有记忆方案的常见问题
尽管市面上有很多记忆解决方案，但它们往往存在一些局限性。LangGraph 团队总结得很好：
“目前的大多数‘智能体记忆’产品都太通用化了。试图满足所有需求，结果却没有一个能真正解决用户的痛点。”
如果你计划为自己的应用增加记忆功能，以下几个问题值得认真思考：
1. 记忆系统会记住哪些内容？
你清楚系统会记录什么吗？很多现有方案并不允许开发者决定记什么、不记什么。但不同的 AI 应用对记忆的需求完全不同，比如：
- 一个老师的 AI 助手需要记住学生的学习习惯；
- 一个虚拟秘书需要记住会议日程；
- 一个陪伴型 AI 则更关注你的兴趣和情感状态。
然而，现在许多解决方案完全依赖 AI 来决定记录什么。这种做法要么会导致 过度记忆（无用信息太多，成本飙升），要么会 遗漏重点 （关键信息没被记住）。
2. 增加记忆功能会影响性能吗？
有些记忆系统要求在用户互动过程中实时更新记忆（比如通过函数调用或工具操作）。这种方式可能导致：
- 性能下降： AI 同时处理记忆更新和用户交互，效率低下；
- 提示复杂： 为了管理记忆，提示词会变得复杂难懂，难以优化和调试。
更高效的解决方法是将记忆功能解耦——也就是让记忆成为一个独立的存储层，专门负责记忆的读写操作，而不干扰 AI 产品的主要交互职责。
3. 记忆功能会不会增加太多成本？
记忆不是免费的，更新和管理记忆需要消耗额外的计算资源。常见的两种更新机制：
- 实时更新（Hot-Path Update）： 每次用户互动后立即更新记忆。这种方式可以保证记忆是实时的，但会：
- 增加延迟： 等待记忆更新会拖慢响应速度；
- 提高成本： 更新频繁，计算资源需求更大。
- 批量更新（Batch Update）： 会话结束后统一处理记忆更新。这种方式更经济：
- 减少延迟： 用户体验更流畅；
- 节约成本： 批量处理更高效。
其实，大多数场景下并不需要实时更新记忆，因为 AI 本身可以暂时记住当前对话的上下文。只要确保下次用户互动前，记忆能被正确更新就足够了。所以，对于用户记忆来说，批量更新 往往是更合适的选择。
总结
虽然目前有许多 AI 记忆解决方案，但大多数都存在定制化不足、效率低下或成本高昂的问题。那些一刀切的方法、复杂的函数调用以及实时更新的弊端表明，开发者需要更灵活、更实用的解决方案。我们 Memobase 团队坚信以用户为核心设计、优先采用批量更新以及存储层解耦的理念，相信这对大部分 AI 应用，尤其是2c应用，是更高效更实用的记忆方案。
Mastra Memory 机制
Memory 的定义和作用
Memory 是 Mastra 智能体系统中管理上下文信息的关键模块。
它的目标是模拟人类的记忆能力，使智能体能够在多轮对话中持续理解用户、记住关键信息，并在对话中灵活调用历史记录，从而：
- 提高响应准确性和连贯性；
- 降低用户重复输入成本；
- 提供个性化和上下文感知的对话体验。
Memory 的三大核心
会话历史（Conversation History）
- 保存最近 N 条对话消息；
- 提供即时上下文；
- 不持久化，仅针对当前会话有效；
- 每次调用中，自动注入到模型输入中。
类比：你还记得刚才聊了什么，但不会记住很久以前的对话。
语义召回（Semantic Recall）
- 基于向量搜索从历史中找出语义上相关的旧信息
- 弥补“上下文窗口”长度限制带来的记忆盲区；
- 使用嵌入模型将历史消息编码并存入向量数据库；
- 每次新对话前，从数据库中检索相似内容并作为提示注入。
类比：你想不起来一句话的原文，但能回忆起与之相关的讨论。
工作内存（Working Memory）
- 用于长期保存与用户持续相关的重要信息；
- 信息结构可自由定义（如名字、偏好、目标等）；
- 会随对话动态更新和扩充；
- 分为“线程级”（仅当前对话）和“资源级”（跨多个对话）两种作用域。
类比：你记得朋友的名字、喜欢的颜色和职业，哪怕上次见面是上个月。
Memory 的工作流程
我们把 Mastra 的 Memory 工作机制分为 请求前、请求中、请求后 三个阶段：
请求前：信息准备
目标：构造用于大模型调用的上下文内容
流程如下：
- 用户发出一条新消息；
- Memory 开始准备上下文信息，包括：
- 最近的对话（会话历史）；
- 从向量数据库中召回与当前问题语义相似的旧消息（语义召回）；
- 工作内存中保存的用户长期信息（如姓名、兴趣）；
- 将这些信息拼接成上下文窗口，发送给大模型。
请求中：生成回复
目标：模型基于上下文信息生成智能响应
流程如下：
- 模型（如 GPT-4）接收完整上下文；
- 基于历史、召回信息和工作内存生成自然、合理的回复；
- 回复返回给用户。
请求后：信息更新
目标：将新对话内容持续写入记忆系统中
流程如下：
- 系统将用户的新输入、模型的响应，以及调用的工具结果写入数据库；
- 同时将这些信息进行嵌入编码，保存进向量数据库，供下次语义召回使用；
- 检查工作内存中是否有需要补充/更新的字段，如新提到了名字、偏好等；
- 更新完成，等待下一轮对话。
Memory Processors：上下文管理助手
在 Memory 模块的基础上，Mastra 提供了“记忆处理器”（Memory Processors）机制，用于在信息进入模型前进行细粒度处理。
作用包括：
| 类型 | 功能说明 |
|---|---|
| TokenLimiter | 限制注入模型的 token 总量，防止上下文超长报错 |
| ToolCallFilter | 过滤掉历史中无用或冗长的工具调用（如图像生成、数据库检索等） |
| 自定义处理器 | 自定义过滤逻辑，如只保留用户+助手的对话，或移除包含敏感词的历史内容 |
所有 Processor 按顺序处理，最后一般使用 TokenLimiter，确保最终上下文合法且不超长。
作用域管理（Scope）
Memory 系统中的“作用域”决定了记忆是只在当前对话有效，还是能跨多个对话线程共享。
| 类型 | 说明 |
|---|---|
| Thread-scoped | 每个对话线程独立保存记忆，适用于任务分离的对话场景 |
| Resource-scoped | 所有与同一个用户 ID 相关的线程共享记忆，适用于用户助理或持续服务场景 |
在 resource-scoped 下，需要在调用时提供 resourceId，以便系统识别“这是同一个用户”。