面试题 · Agent
搜索「检索」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在构建多轮对话系统或Agent时，如何有效管理上下文状态？请说明会话状态存储、更新机制的设计方案，并探讨在高并发场景下如何确保数据一致性与低延迟访问。
短期状态（工作记忆）
Hash存元信息，List/ZSet存消息序列长期状态（外部记忆）
写路径
用户输入 → 路由层（按session_id哈希）→ 单线程处理保证顺序
→ 更新Redis + 异步落盘 + 发布变更事件并发控制
学习内容与项目面试，在同一条路上。
WATCH + MULTI/EXEC，版本号校验HSETNX 配合 last_seq 校验，冲突时重试/合并上下文截断
| 策略 | 实现 |
|---|---|
| 读写分离 | 读本地Caffeine缓存，写穿透Redis |
| 会话亲和性 | 同一session路由到固定Pod，减少竞争 |
| 批量合并 | 高频心跳/状态变更合并写入 |
| 异步持久化 | Redis确认即返回，DB落盘走MQ削峰 |
一致性权衡：最终一致性为主，关键操作（支付类工具调用）强制同步落盘。
建议系统学习该知识点
场景切入
假设你在做一个智能客服，用户连续问了好几个问题，比如查订单、改地址、问退款进度。你觉得这个会话的上下文应该怎么存、怎么更新，才能让后面的回答不跑偏？
层层追问
多轮对话的上下文你一般怎么管理？……那如果对话特别长，历史消息越来越多，你怎么处理？……高并发下比如双十一，成千上万的会话同时涌进来，你怎么保证每个会话的上下文不冲突，而且读写得快？
直球架构
设计一个多轮对话的会话状态管理模块，要能存短期和长期上下文，支持高并发。说说你用什么存储、怎么更新状态、怎么保证数据一致性和低延迟访问。
这道题问的是多轮对话里的上下文管理，其实本质上就是在问：多个用户同时跟你聊天的时候，你怎么保证每个人的对话状态不乱，而且响应还要快。说白了，这是一个一致性和延迟之间的权衡问题。
我的设计思路是分两层。短期状态，就是最近几轮对话和[[Agent]]执行的中间变量，我放Redis集群里，TTL设个30分钟，没活动就自动清掉。结构上，用Hash存session的元信息，用List或者ZSet存消息序列。长期状态呢，比如用户画像、历史摘要、关键事实，这些得持久化，我用MongoDB或者ES，再配合一个[[向量库]]做检索。两个层各管各的，短期追求快，长期追求全。
具体到更新机制，写路径是这样的：用户请求进来，路由层按session_id哈希，保证同一个session的请求都打到同一个处理线程上，这样单线程处理就天然有序了。然后更新Redis，同时异步写DB，再发一个变更事件出去。并发控制我主要用乐观锁，Redis的WATCH加MULTI/EXEC，带上版本号校验，冲突了就重试。另外上下文不能无限长，我会用[[滑动窗口]]保留最近K轮，超长就触发摘要，调用LLM生成一个历史摘要替换掉原始对话。
高并发场景下，我做了几件事。先说读写分离，读走本地Caffeine缓存，写穿透Redis。接着说会话亲和性，同一个session固定路由到同一个Pod，减少锁竞争。再补充批量合并，高频的心跳或者状态变更先攒一波再写，避免频繁IO。最后补充异步持久化，Redis确认就算成功，DB落盘走MQ削峰。
这里有个坑需要注意。一致性我选择最终一致性，因为大部分场景下用户能容忍短暂的不一致，比如客服聊天，中间几秒的延迟用户感觉不到。但如果是关键操作，比如支付类的工具调用，那就必须强制同步落盘，确保不丢。所以我会把操作分两类，普通操作走异步，关键操作走同步。
另外我还想提一个点，就是上下文截断时生成的摘要，如果摘要质量不好，反而会丢失关键信息。所以我会在摘要生成后做一个质量校验，比如跟原始对话对比一下关键实体有没有丢，如果召回率低于阈值就保留原始对话。这个校验怎么做，其实也值得深入讨论。
所以整体上，我更倾向于把上下文管理看作一个分层缓存加异步持久化的系统，核心是分场景选择一致性级别。不搞一刀切，才能在高并发下既快又稳。