多轮对话的 Agent 老“失忆“?聊聊会话状态我是怎么存的

做单轮问答的 Agent 很简单,一进一出完事。真正难的是多轮——用户上一句说"帮我订北京的",这一句说"改成明天",你的 Agent 得知道"明天"是接着"订北京"的。我在做一个预约助手时,会话状态管理这块来回返工了三遍,把心得理成几条。

先分清两种"记忆"

我一开始把所有东西都往对话历史里塞,塞到上下文爆了还满屏乱。后来想明白,得拆成两类:

• 对话历史:用来给模型理解语境的原始问答,有窗口上限,旧的要么截断要么压缩;

• 会话状态(slot/上下文变量):结构化的、当前会话里确定下来的关键信息,比如 城市=北京、日期=待定、人数=2。

后者才是 Agent 真正"记住"业务的地方。别把状态藏在对话历史里靠模型每轮重读,那既慢又不稳。该结构化存的就单独存。

我的状态字段怎么设计

预约助手我设了几个槽位,每轮对话结束更新一次:

session_state = {
  intent: "预约",      // 当前意图
  city: "北京",
  date: null,          // 还没确定
  count: 2,
  stage: "收集信息"     // 流程阶段
}

stage 这个字段很关键,它决定 Agent 这一轮该干嘛——还在收集信息就接着问,信息齐了就进确认环节。用一个显式的阶段字段驱动流程,比让模型每轮自己判断"现在到哪了"靠谱得多。

三个把我坑过的点

1. 状态没及时清。 一次预约走完了,用户开新话题,我没重置 session_state,结果新对话还带着上一单的城市。后来在"完成"阶段加了清空逻辑。

2. 多端/多会话串了。 同一个用户在两个入口聊,状态如果只按用户 ID 存会互相覆盖,得按会话 ID 隔离。

3. 状态更新和模型回复不同步。 模型嘴上说"好的已记下明天",状态里 date 却没更新——因为我抽取逻辑漏了这种相对日期。抽取这块单独测了一批 case 才补齐。

落地用的工具

我现在搭这类多轮 Agent,用的是个能可视化配会话变量、带上下文管理的平台,槽位填充和状态保持它有现成机制,不用我自己在代码里手搓一套会话存储。老实讲缺点也有:它默认的会话保持时长对我的场景偏短,用户隔了俩小时回来状态就没了,我得自己往外接一层持久化兜底。免费档调试还行,真上量得留意会话并发。

模型走的讯飞 MaaS,API 现成调,多轮上下文拼接它那套接得很顺。

你们的多轮 Agent 怎么防失忆的?是塞历史还是存结构化状态?评论区聊。