让语音助手"有记忆、能干活"：会话记忆与工具调用的工程实践

一个只会聊天的语音助手，用户三天就腻了。真正留下来的是：它记得我，而且真的能帮我做事。

纯对话模型的三个短板

• 记不住：上下文窗口一满，前面的对话就被挤出去，用户得反复交代背景。
• 算不准：库存、价格、今天的天气，这些实时数据模型不可能"记住"，只能去查。
• 干不了活：开灯、下单、查工单——这些动作要真的落到系统上，靠生成文字做不到。

对应的解法是三层结构：短期上下文、长期记忆、工具调用。少一层，体验就有一个明显的坑。

第一层：短期上下文

多轮对话的上下文不能无限堆。可行做法是"保留近几轮原文 + 更早内容做摘要压缩"，既省 token 又保住关键信息。压缩的时机很重要：等到超限才压，会丢掉正在讨论的细节。

第二层：长期记忆

跨会话记住"用户是谁、偏好什么、上次聊到哪"，通常用向量检索实现。但关键不在存储，而在写入判断：

• 哪些信息值得记（偏好、身份、长期目标），哪些是噪声（一次性的临时指令）
• 新信息与旧记忆冲突时，是替换、删除还是并存
• 检索时按相关度取回，而不是把所有历史都塞回上下文

反直觉的一点： 记忆不是越多越好。无关记忆混进上下文，会稀释注意力、拖慢响应，还容易让模型答偏。

第三层：工具调用

"能干活"依赖工具调用：模型判断该调哪个接口、传什么参数，拿到结果后再组织成自然语言回给用户。工程上有三点必须处理：

• 权限边界：哪些工具允许调用、参数范围多大，必须由服务端约束，不能只信模型。
• 超时与重试：外部接口会慢会挂，要有超时兜底和幂等设计，避免"说了一遍执行两次"。
• 结果回填：拿到结构化结果后要转成口语化表达，而不是把 JSON 念出来。

顺序很重要

先做短期上下文（改动最小），再加长期记忆，最后接工具——因为工具调用会引入外部不确定性，在没有稳定上下文的情况下排查问题会非常痛苦。

小智语音对话平台把这三层做成了内置能力，并支持接入企业自有系统作为技能。如果你的语音助手正卡在"能聊但不能用"的阶段，欢迎联系我们。