考察点
聊天类应用绕不开这道题。面试官想看你知道「全量塞历史」为什么不可行（成本、lost in the middle、上下文窗口硬上限），以及压缩方案的取舍——摘要、窗口、事实抽取各自丢什么信息。能讲出分层记忆架构和 token 预算分配是加分项。追问常往「摘要丢失关键信息怎么办」「RAG 和对话记忆怎么配合」走。
参考答案
为什么不管不行
多轮对话默认做法是把全部历史拼进上下文，很快就会撞三堵墙：
- 窗口硬上限：聊着聊着超出上下文长度，请求直接报错。
- 成本：历史是每轮都要重复计费的输入 token，五十轮对话后每轮请求都带着几万 token 的包袱，费用和首 token 延迟同步膨胀。
- 效果衰减：上下文变长后模型对中间内容的利用变差（lost in the middle 现象），塞得越多，关键信息被淹没的概率越大，并不是历史给得越全效果越好。
主流方案及取舍
滑动窗口：只保留最近 N 轮。实现最简单，代价是早期信息全丢——用户第三轮说的「我对花生过敏」，第二十轮推荐菜谱时已经忘了。适合短会话、单轮任务为主的场景（客服问答），不适合需要长期记忆的场景。
摘要压缩：历史超过阈值后，用 LLM 把旧对话压成摘要，上下文里只带「摘要 + 最近几轮原文」。摘要可以递归滚动更新（旧摘要 + 新对话 → 新摘要）。优点是能保住长程信息，代价是摘要是有损压缩，细节丢失不可逆，且每轮更新摘要多一次 LLM 调用。关键细节（订单号、用户明确要求）摘要很容易丢。
事实/偏好抽取：对话过程中异步提取结构化事实存入用户画像（「花生过敏」「偏好简洁回答」），每轮把画像注入 system prompt，历史对话本身用滑动窗口。信息保真度比摘要高，因为抽取是定向的，但需要预定义「该记什么」，开放域的意外信息接不住。
向量检索记忆：历史消息向量化入库，每轮按当前输入检索相关历史片段注入。找回的是原文不是摘要，保真度高；但 embedding 召回对「指代和省略」敏感，口语化对话的检索质量经常不如预期。
实战：分层组合才是正解
生产系统很少单用一个方案，标准形态是分层记忆：
- 工作记忆：最近 5-10 轮原文原样保留，保证指代消解（「它多少钱」的「它」）正常工作。
- 情节记忆：更早的历史做滚动摘要，保住会话主线。
- 语义记忆：用户画像、偏好、关键事实，结构化存储，注入 system prompt。
- 档案记忆：完整历史全量落库，需要追溯时按需检索。
Token 预算要提前分配，比如总预算 32K：system + 画像 2K，摘要 2K，最近轮原文 8K，RAG 检索内容 8K，剩余留给输出。哪层超了压哪层，规则写死在代码里，不要等撞窗口再报错。
几个容易踩的坑
截断不能只按轮数砍，要按 token 数算（一轮里可能有一篇长文档）。裁剪时注意保持消息配对的完整性——tool call 和 tool result 必须成对出现，截断把 result 截没了留着一个悬空的 call，部分 API 会直接报错。摘要更新的时机放异步任务里做，别阻塞对话主链路。还有 KV cache 的利用：前缀稳定（system、摘要放前面）能命中缓存，频繁变动的内容放后面，成本和延迟都有实在收益。
可能的追问
- 摘要把关键信息丢了怎么补救？ 抽取式兜底：对订单号、金额、日期这类实体做规则或 NER 抽取，以结构化字段形式常驻上下文，不依赖摘要保真；同时保留全量历史，支持「回溯原文」的兜底查询。
- 怎么判断该用窗口还是摘要？ 看会话的信息密度分布：信息集中在新近轮次（工单问答）用窗口；早期信息长期有效（项目讨论、陪伴类对话）必须摘要或画像。也可以混合，窗口保近处、摘要保远处。
- 多 Agent 场景上下文怎么管？ 各 Agent 只传任务相关的最小上下文，不共享完整历史；由一个 orchestrator 维护全局状态，向下分发精炼后的任务描述。全量广播历史既贵又容易互相污染。