语音代理中的记忆问题比你想的更难
在调研语音代理的记忆模块实现时，我看到了一篇文章，讲的是为什么语音代理的记忆问题比想象中更难。作为记忆模块的开发者，我在开发语音代理的过程中也遇到了文章提到的许多问题，读来感同身受。语音代理和文本代理有很大不同，许多问题尤其棘手，其中响应速度和准确性是我面临的最大挑战。接下来，我会参考这篇文章，结合自己的实践，分享一些思考和体会。
第一次尝试为语音代理接入记忆层时，系统从第一轮开始就慢了数百毫秒，之后每一轮都是如此。仅仅一轮交互，对话就从自然流畅变成了让人忍不住问“还在吗？”的状态。原因是我原封不动地移植了文本代理的记忆架构：先对托管存储中的记忆做同步向量检索，再做一次简单的重排序，最后才交给 LLM。在文本聊天界面中，这点延迟几乎不会被注意到。但在语音场景中，每一轮都让人感觉代理开口前要先缓冲一下。
语音记忆并不是给文本记忆收紧一点延迟预算就能实现的。它对延迟的要求严苛到必须重新安排整个读写流程。大部分记忆操作都不能放在响应的关键路径上，而要提前加载、提前计算，或在响应之后写入。
我花了不少时间研究不同项目的记忆机制，包括 ChatGPT 和 Claude 的记忆如何运作，以及 Mem0、Hindsight、OpenClaw（小龙虾）等开源项目的记忆实现。但这些经验仍不足以让我充分应对语音场景给架构设计带来的挑战。这篇文章讨论的，就是这些约束、由此带来的权衡、生产环境中常见的四类架构，以及那些走过弯路才会明白的经验。
为何语音记忆与文本记忆截然不同
文本代理天然有一定的等待余地。用户输入文字，看到加载提示，通常可以接受等待 1–3 秒再收到回复。大多数记忆操作都可以安排在这段间隙里，包括向量查询、对过往对话的语义搜索，甚至一次快速的摘要处理。文本交互让用户习惯了等待，也给系统留下了处理记忆的时间。
语音交互没有这么多余地。预期的端到端响应时间为 500–800 毫秒，而这个预算涵盖了所有环节：语音识别（ASR）输出最终转录文本、记忆检索、LLM 生成首个 Token、语音合成（TTS）生成首个音频块，以及音频传输。记忆处理能分到的时间只有大约 50–100 毫秒，超过这个范围，就会打乱对话节奏。一次到托管向量数据库的往返，仅网络耗时通常就有 20–80 毫秒。再加上嵌入计算、近似最近邻（ANN）搜索和结果格式化，在 LLM 开始处理输入之前，记忆检索的延迟预算就已经耗尽了。
输入形式是第二个关键差异。文本代理接收的是经过组织的文字，而语音代理接收的是即兴口语的流式转录，其中夹杂着口头停顿、说到一半重新起句、指代错误和自我纠正。在我的实践中，语音识别错误尤其令人头疼。即使是在文本聊天中表现很好的信息提取流程，到了这里也会遇到困难。
话轮密度是第三个问题。语音对话的每一轮更短、交替更快，信息密度也更低，通常每轮只有 10–30 个词。一次 10 分钟的对话平均会产生 40–60 轮，以及 1500–2000 个 Token 的转录文本。这听起来似乎还可控，但在语音原生模型中，音频会进一步放大上下文占用。OpenAI 的 Realtime API 手册就明确提到：“在实践中，同一句话用音频表示时，Token 数通常约为文本的 10 倍”，而 gpt-realtime 的上下文窗口上限为 32k。一次普通的客服对话，就可能让你越过这条线。
第四个差异常被忽视，那就是冷启动问题。在文本聊天中，用户通常已经登录，系统知道会话属于谁。而在电话语音场景中，系统最初往往只有一个电话号码，必须在最初的几百毫秒内确认用户身份。将“第一轮就知道用户是谁”作为前提的记忆架构很脆弱。好的架构会从用户身份未知的情况出发来设计。
在陪伴型语音代理中，系统往往默认听到的话都来自用户。即使只面向一个用户，来自其他人的声音或背景音也可能被记到用户名下，让记忆变得一团糟。也许你从没说过自己喜欢吃麦当劳，只是电视里偶然出现了这样一句话，代理却牢牢记住了，还把它当成你的偏好。
真正重要的记忆层次
有三个层次值得关注，它们也与现有综述文献对代理记忆的整体划分相吻合。近期的 From Storage to Experience 综述将这一演进过程概括为：存储 → 反思 → 经验。Letta 的产品文档则将大致相同的划分明确为：核心记忆 → 回忆记忆 → 归档记忆。叫法不同，但底层的层次划分是一致的。
对话记忆包括当前对话的转录文本及各轮的先后顺序，保存在 LLM 的上下文窗口中。即使现代模型名义上支持 128k 以上的 Token，一次长对话仍可能在不知不觉间超出实际可用的 4–8k 上下文范围。将完整转录文本塞入上下文，会拖慢生成速度，也会让模型更难关注真正重要的信息。
会话事实属于工作记忆层，指当前对话中已经确认、需要在后续轮次中持续保留的信息。例如，“我叫小熊，今年 23 岁”，这些信息不应该过了五轮就又被代理问一遍。没有这一层，语音代理就会像只有“金鱼记忆”一样，转眼忘记刚说过的内容，很快就会破坏用户的信任。
用户档案属于长期记忆层，保存跨对话保留的事实，包括姓名、偏好、上次对话摘要、未解决问题以及人际关系背景。正是这一层，让再次发起对话的用户感到自己被记住了，不必每次都从头介绍。
核心的设计难题在于后两层：如何在对话过程中提取会话事实，并在需要时提供给代理？如何跨对话持久化和检索用户档案？这两件事都必须满足前面提到的延迟限制。
延迟究竟消耗在哪里
让我们把这一限制具体化。一个典型的语音代理响应周期如下：
1.用户停止说话 → 语音活动检测（VAD）判定这一轮结束（约 100 毫秒）
2.流式 ASR 输出最终转录文本（在 VAD 判定结束后约 50 毫秒）
3.执行记忆检索（耗时多久？）
4.LLM 接收补充了记忆的提示词 → 生成首个 Token（首 Token 延迟，即 TTFT，快速模型约 300 毫秒）
5.TTS 生成首个音频块（在首个 Token 之后约 100 毫秒）
6.总体目标：从用户停止说话到输出首个音频块，耗时控制在约 600 毫秒
第三步就是留给记忆检索的时间。要满足 600 毫秒的总体目标，这一步必须在大约 50–100 毫秒内完成。
这就直接排除了大多数容易想到的方案。在每轮对话处理时同步执行向量搜索，查询本身需要 30–100 毫秒，再加上生成嵌入向量、排序和格式化，还要额外花费 50–100 毫秒。Mem0 自己的语音代理记忆指南指出，语义搜索耗时为 “50–200 毫秒，具体取决于你的向量数据库和基础设施”。即使是专门为低延迟上下文检索而设计的 Zep，也宣称其独立运行时的 P95 延迟低于 200 毫秒，与 LiveKit 语音代理集成时低于 250 毫秒。
这些数字对于文字聊天来说很出色。但对于语音交互，它们已经处于可接受范围的边缘——而且也只有中位数延迟勉强达标，尾部延迟则完全不行。在每轮对话处理时再调用一次 LLM 生成摘要，更是不可行：主 LLM 还没开始工作，这一步就会耗费 300–800 毫秒，用光全部延迟预算。
真正可行的方案只有一个：从高速进程内缓存或本地 Redis 中按键读取数据。耗时仅 1–5 毫秒，延迟稳定，用户几乎感知不到。
每个语音记忆架构背后的四个关键问题
一旦你真正理解了“记忆处理不能放在关键路径上”，架构设计就可以收敛为四个关键决策。在我考察过的每一个生产级记忆系统中，包括 Letta、Zep、Mem0、A-MEM、MemoryBank 和 Generative Agents，都能发现这四个隐含的问题，只是各自给出的答案不同。把这四个问题确定下来，架构的大部分也就随之明确了。
（如果你想从供应商的角度了解这一话题，Mem0 的语音记忆指南值得一读。）
什么时候写入
是每轮写入，也就是每次交流后提取事实，还是等对话结束后再批量写入？后者成本更低，提取结果的噪声也更少，因为模型能看到完整的对话脉络。
每轮写入成本更高、噪声也更多，但数据更不容易丢失：如果进程在对话中途崩溃、WebRTC 会话异常中断，或对话结束时的提取任务失败，仅在结束时批量写入就可能丢失整次对话的记忆；每轮写入则能保留截至最后一次成功写入的所有事实。
我见过的几乎所有生产级语音系统，都愿意承担这部分额外成本，采用每轮写入。因为电话语音场景中的异常中断很常见，谁也不想等到线上丢失了对话记录，才开始排查原因。（第三种方案——休眠期写入——将在下文单独讨论。）
写什么
对于每一条待写入的事实，我都会问：它真的会改变代理在未来对话中的回应方式吗？如果不会，它就是噪声。带有噪声的记忆比没有记忆更糟糕，因为它会降低重要信息的检索准确性。这意味着应用场景越专门化，筛选就应该越严格。通用助手可以采用通用的 LLM 事实提取流程，而医疗接诊代理则应按照字段和类型明确的数据结构写入，拒绝不符合结构要求的内容。
如何检索
四种模式占主导地位：
| 模式 | 适用场景 | 代价与局限 |
|---|---|---|
| 全量注入记忆 | 用户的记忆条目少于 20–30 条时 | 超过阈值后，Token 用量膨胀；上下文过长时，容易忽略中间的信息 |
| 纯语义搜索 | 每轮检索结果的相关性成为瓶颈时 | 每轮增加 50–200 毫秒延迟，对语音交互而言通常太慢 |
| 预加载上下文 | 用户拥有稳定、可总结的历史记录时 | 长时间会话中，预加载内容可能过时；冷启动时没有可加载的内容 |
| 混合模式（预加载 + 按需加载） | 大多数生产级语音代理 | 需要话题切换检测机制，但这是推荐的默认方案 |
运行在哪
是在响应流程中同步执行，交给与语音流水线并行运行的记忆代理，还是放到后处理阶段？对于语音，通常的选择是并行写入、提前加载读取所需的记忆，只有确实需要在当前轮立即获取信息时，才在响应流程中同步检索。
这四个问题的答案，共同决定了系统采用哪一类架构。
架构全景
我将考察过的语音记忆架构大致归为四类。它们并不互斥，大多数实际系统都会结合其中至少两类。这种划分有助于理解不同方案各自解决什么问题。
第一类：原生框架状态
成熟的语音代理框架都会在会话期间，在流水线内部维护对话状态。主流端到端语音 API 也会在服务端维护这些状态，通常还内置了上下文截断功能。
这类方案只解决单次会话内的问题，对话结束后不会保留状态。它应当是记忆架构的基础，但本身还算不上一套完整的记忆架构：适合存放会话事实，却无法满足跨对话的记忆需求。
端到端语音模型将语音识别（STT）→ LLM → TTS 的多阶段流水线合并为一个有状态的会话，解决了各阶段串联带来的延迟问题，却没有解决记忆问题。OpenAI 的 Realtime API 将会话上下文限制在 32k Token 以内，Google 的 Gemini Live 会在每次对话结束时丢弃会话状态。两者都没有内置跨会话持久化机制，需要你在外围自行实现。
原本需要为级联流水线搭建的记忆架构，换成端到端模型后仍然需要。端到端方案的一个优势是，多模态模型可以直接处理音频，因此事实提取能基于原始音频进行，而不必依赖转录文本的间接表达。如果犹豫、语调、情绪等副语言信号会影响代理的回应，这一点就尤其重要。
第二类：外挂记忆服务
我交流过的大多数团队都是从这里起步的：将第三方记忆服务作为一个处理组件，插入用户消息聚合器与 LLM 之间，配置好用户或实体 ID，然后让它负责整个记忆读写流程。Mem0、Zep、Hindsight 和 Supermemory 都为主流语音框架提供了插件。
这些方案的共同点是：在处理流水线层面集成，按用户或实体划分记忆范围，异步写入，并通过预加载或按需检索来读取记忆。它们的差异主要在于底层存储方式（向量、图或 SQL）、事实提取的范围和力度，以及在每次对话中接入和使用的便捷程度。
第三类：知识图谱记忆
这类方案最让我感兴趣，因为它真正改变了“记忆”的含义，而不只是提高读取速度。知识图谱系统不再仅仅存储经过向量化的文本片段、按相似度检索，而是存储实体、关系及其时间有效性，并通过图遍历结合语义搜索来检索信息。模型得到的会是 “John 最喜欢的歌曲是 Coldplay 的《Viva La Vida》（有效期：2024 年 1 月 15 日至今）”，而不是三个零散的历史对话片段。
在生产环境中，我最常见到的选择是 Zep 的 Graphiti；学术界最有意思的方案则是 A-MEM（NeurIPS 2025）。它将每条记忆写成一则卡片盒笔记法（Zettelkasten）风格的笔记，后续的其他记忆可以不断更新已有笔记，因此整个图谱会被主动重新组织，而不只是不断追加内容。
代价是复杂性：与扁平的向量索引相比，图谱更难调试，清理和淘汰记忆也更麻烦，构建成本更高。但对于需要与同一用户持续对话数年的语音代理来说，这类方案才是长期解决之道。
第四类：认知架构
第四类方案将记忆视为一个认知过程。奠定这一思路的工作是 Park 等人的 Generative Agents（UIST 2023）：维护一条记忆流，通过周期性的反思提炼更高层次的认识，并在检索时根据新近程度、重要性和相关性为候选记忆评分。反思是大家最常借鉴的部分，因为它能让代理随着时间推移，给人一种越来越理解你的感觉，而不是只会复述你说过的话。
一些变体还加入了其他机制：MemoryBank 引入了类似艾宾浩斯遗忘曲线的机制，让长期未使用的旧记忆逐渐淡出；MemR3（2025） 则将检索改造成一种路由决策，在每轮对话中决定是检索、反思，还是直接回答。这些方案很少以开箱即用的产品形式交付，更值得借鉴的是其中的设计模式：反思的调度方式、按重要性加权的检索、随时间衰减的评分机制。你可以将它们叠加到“第一类 + 第二类”的基础架构之上。
反转记忆的读写路径
无论选择上述哪类架构，在生产环境中真正行得通的模式，都是把记忆操作分为两类：响应之前的检索，以及响应之后的写入。关键路径上只保留绝对必要的检索，即便是这部分，也要通过预加载尽可能提速。
在对话开始时预加载。对话刚建立、用户还没开口时，通常有几百毫秒的初始化时间，用于建立 WebRTC 连接、初始化音频、协商编解码器。利用这个窗口，将用户档案、上次对话摘要和未解决问题加载到会话本地缓存中。等到第一轮对话到来时，所谓的“记忆检索”就只是一次字典查找，不再需要网络请求。第一轮获取用户档案多花的每一毫秒，都会变成用户听到的沉默。
冷启动才是真正考验这一设计的场景。如果用户身份未知，就无法预加载任何用户专属信息。你可以在最初一两轮中确认身份，例如让用户提供账号，或在连接建立期间通过电话号码查询 CRM；也可以接受首次对话的上下文比较有限，并通过提示词让代理妥善应对这种情况。我最常见到的错误，是团队把已认证用户当作系统的默认情况，把匿名用户视为边缘情况。而在电话语音场景中，匿名用户恰恰是最常见的处理路径之一。
读写路径反转的另一半是异步写入。每次响应之后，启动一个无需等待结果的后台任务，从最新一轮对话中提取新事实并持久化。这样，对话结束时，用户档案基本已经更新完毕，而这些工作没有占用任何一轮响应的延迟预算。对于提取尚未完成、用户就已结束的短对话，可以让对话结束处理程序最多再等待一小段时间，通常 2–3 秒就够了，让正在执行的任务完成。此时用户已经离开，不必再为用户可感知的响应延迟争分夺秒。
随后，对完整转录文本进行一次总结，保存为这次对话的正式记录，包括讨论了什么、问题是否解决、关键事实以及后续待办。这份摘要会成为下一次对话预加载的 last_interaction，也是语音记忆系统中最被低估的一项产物。ChatGPT 和 Claude 的文本系统也依赖同样的思路：在检索时，经过整理的摘要总是比原始转录文本更有用。
真正上线后，有两个问题很容易让你吃亏。第一个是，预加载可能与上一次对话的回写发生竞态。假设用户在一次对话中要求代理称呼自己为 Alex，每轮提取捕获了“请叫我 Alex”并写入存储。如果下一次对话预加载时，读到的却是回写完成前几秒生成的快照，代理仍会用旧名字问候用户。这比完全没有记忆更容易损害信任。解决方法并不复杂：即使快照较旧，也要确保读取时能拿到最新回写的数据。但这种故障往往要等到真实用户开始使用后才会暴露。
第二个是成本。每轮提取意味着每一轮都要额外调用一次 LLM。按每次调用几美分、一次对话 40–60 轮计算，一段 10 分钟的对话，光是事实提取就可能花掉几美元。对于高价值的客服对话，这可以接受；对于大规模提供免费服务的消费级助手，这种成本则难以承受。务实的选择是使用更便宜的提取模型，通常一个经过蒸馏的 7–8B 模型就足够；也可以将多轮对话合并为更长的滚动窗口再提取，或者在利润空间较小的场景中，更多地采用对话结束后提取。
压缩单次对话中的历史记录
即使只看一次对话，你也会比预想中更快碰到实际可用的上下文上限。一段正常语速、持续 10 分钟的对话，仅转录文本就有 1500–2000 个 Token；在语音原生会话中，音频占用的 Token 数还会膨胀到约 10 倍。即便模型宣称支持很长的上下文，实际使用时也很难在这样的负载下保持效果。
应对方式是滚动窗口配合摘要：完整保留最近 N 轮，将更早的内容替换为压缩摘要。当转录文本达到某个阈值，例如 20 轮时，启动一次异步压缩，把前 10 轮浓缩成 3–4 句话。这项工作适合交给快速的小模型，例如部署在同一台机器 GPU 上的蒸馏版 1–3B 模型，或运行在 CPU 上、经过微调的摘要模型。每次压缩耗时 50–150 毫秒，放在异步流程中没有问题，放到响应的关键路径上就会很难受。
另一个办法是选择性保留。并不是每一轮都同样有价值，“好的”“明白了”“嗯嗯”几乎没有带来新信息。甚至不需要专门的小型分类器，仅靠文本长度和停用词等简单规则，就能在不丢失实质内容的情况下去掉信息量很低的轮次。应该把转录文本当作需要整理的内容，而不是必须原样保留的日志。
长期情景记忆的检索
对于姓名、偏好、已知问题等结构化档案数据，键值存储就是合适的选择：速度快、延迟可预测，也不需要生成嵌入向量。这部分记忆处理没有必要复杂化。
对于非结构化的情景记忆，也就是某次具体的过往对话、详细的历史互动，最终还是需要语义检索。关键在于什么时候检索，答案是：不要让它阻塞当前轮的响应。
行之有效的模式是在后台提前准备相关上下文。你需要维护一份当前对话主题的表示，实际中通常是将用户最近一两轮的发言编码为一个查询向量，有时再加上小型分类器生成的话题标签。每隔 3–5 轮，或当话题向量的变化超过阈值时，就对历史对话发起一次异步检索。如果找到了相关内容，先暂存结果，留到下一轮再注入上下文。
这会让情景上下文滞后一轮，但这种权衡几乎总是值得的。话题出现后，代理稍晚一轮才提起相关的过去对话，用户通常不会在意；可如果每一轮都要迟疑 200 毫秒，他们一定会察觉。
不过，快速切换话题是这一方案的短板。如果用户每一轮都换一个话题，暂存的检索结果就会不断过时，而这在比较随意的客服交流中，比你想象的更常见。实用的补救办法是用低成本方式检测话题变化，例如观察相邻查询向量之间的余弦相似度是否下降，并在发生切换时退回不使用情景上下文的处理方式，避免把上一个话题的内容注入当前问题。过时的上下文比没有上下文更糟糕。
休眠期的记忆整合
每轮写入加上对话结束后的摘要，能够满足基本需求。更进一步的做法，是利用会话之间、系统空闲的时候处理记忆。Letta 的 sleep-time compute（休眠期计算） 对这一思路给出了清晰的实现：启动一个独立代理，与面向用户的代理共享记忆块，在后台重新组织和整合已有记忆。
支撑这一思路的论文 报告称，在准确率相同的情况下，测试时计算量可降至约五分之一；在查询可预测时，准确率可提升 13%–18%。这些是论文在所选基准测试上报告的主要结果。对于语音场景，更有意义的理解是：即使只在两次对话之间做少量整合，也能改善下一次对话的检索质量。
放到语音场景中，这个思路很直观。每轮写入产生的是一条按时间排列的事实流。几周、几个月之后，其中就会积累矛盾信息，例如“用户偏好电子邮件”与“用户说请给他打电话”，也会留下过时的上下文。每晚进行一次休眠期整合，可以合并重复信息、优先采纳更新的信息来解决矛盾、按照遗忘曲线机制 清理不重要的记忆，并借鉴 Park 的 Generative Agents，提炼更高层次的认识，例如：“这个用户通常在遇到故障时才会发起对话，很少咨询一般性问题。”
这对语音尤其重要，因为你无法承担在响应关键路径上执行这些整合工作的代价。休眠期是整个架构中唯一不受即时响应延迟预算约束的阶段。没有在这里提前完成的工作，一旦被迫放到实时流程中，你就会为此付出代价。
干净的输入：转录文本与多说话人
前面所有设计，都假设输入记忆流水线的内容足够干净。现实往往并非如此，其中藏着两个不同的问题：用户自身语音的转录文本带有噪声，以及现场经常不止一个人在说话。
先说第一个问题。语音转录文本通常很杂乱：用户会说“嗯”“呃”，会说到一半重新组织句子，还会使用指代不明的表达，例如“跟我说说我们之前聊的那个东西”。直接从原始转录文本中提取事实，很容易引入噪声。缓解办法是增加一个轻量的转录清洗步骤，在文本进入记忆流水线前，快速去除语气词和重复起句，并结合上下文整理指代表达。这一步异步运行，不介入响应流程。负责回答的 LLM 仍然接收原始转录文本，因为等待清洗会增加无法承受的延迟；记忆提取则使用清洗后的版本。
第二个问题，几乎没有生产级语音代理能够处理得十分妥当。家庭客服对话中，配偶和孩子可能都在同一个房间；医疗咨询中，照护者可能在旁边；小企业联系技术支持时，可能有人隔着办公室大声补充情况。此时，要让记忆准确，就需要说话人分离（speaker diarization），弄清楚每句话是谁说的。
如果缺少这一步，事实提取器就可能把“用户的配偶不喜欢当前套餐”直接写进用户档案，混淆偏好的归属，进而在下一次对话中损害信任。pyannote-audio 是这一领域的主流开源方案；较新的、以 LLM 为基础的系统，如 TagSpeech 和 DM-ASR，则在多人重叠说话较多的音频上取得了明显改进。
但延迟代价也很实在：如果放在关键路径上，每轮会额外增加 200–400 毫秒。这也是为什么我见过的大多数生产级语音代理，都没有上线能实时区分说话人的记忆功能。可行的折中方案是，在对话结束后对录音异步执行说话人分离，先将事实归属到正确的说话人，再持久化保存，同时接受对话进行期间存在一定的归属误差。这类问题发生的频率可能低到可以接受，但一旦出错，后果又足够严重，因此至少应该有一套应对方案。
三层架构
把这些放在一起，一个生产级语音记忆系统可以分为三层，划分依据是延迟特征，而不是存储内容。
第一层——热缓存（1–5 毫秒）：对话开始时预加载用户档案、上次对话摘要和未解决问题，在整个对话期间保存在进程内存中。每一轮查询都能几乎立即返回。
第二层——后台检索（50–150 毫秒，异步）：在轮次之间检索情景记忆，暂存结果，等待下一轮注入上下文。始终不阻塞响应。
第三层——异步写入（不受响应延迟预算约束）：包括事实提取、档案更新、对话结束后的摘要，以及休眠期记忆整合。这些工作分别在每轮之后、对话结束后和系统空闲时执行，为下一次对话的第一层缓存提供数据。
注意这里的不对称性：阻塞路径上唯一保留的操作是缓存查询。 所有昂贵的工作，包括嵌入计算、检索、摘要、回写和整合，都被移到了轮次之间的空隙、对话结束后，或系统空闲时。
最后的思考
语音代理的记忆问题，在很大程度上仍未解决：要跨越多次对话，实现真正接近人类的回忆能力，依然很难。但基础设施层面已经有了清晰且可落地的做法，包括高速缓存、异步提取、结构化档案、对话结束后的摘要、知识图谱和休眠期整合。Pipecat、LiveKit Agents 等成熟框架，以及 Mem0、Zep、Letta、Hindsight、Supermemory、Cognee 等丰富的记忆服务，让你无需从头编写整个记忆读写流程。
真正考验功力的是语义层面的工作：决定记住什么、什么时候提起，以及怎样自然地表达，避免让代理听起来像是在照着档案念。这需要精心设计提示词，并严格筛选要持久化的内容，而不是一味扩大向量数据库。
如果只记住一句话，那就是：在语音代理中，记忆的速度取决于你提前准备好了什么，而不是你当下能检索到什么。
参考文章：Memory in Voice Agents Is a Harder Problem Than You Think