为什么你没有短期记忆+长期记忆+变量注入
1️⃣ 考察意图
面试官想看你是否真正理解 Agent 记忆体系不是“存聊天记录”，而是状态管理 + 变量生命周期控制。考察类型是系统设计 + 工程取舍。刁钻点在于：多数候选人只会说“用 Redis 存对话历史”，但答不出短期记忆（上下文窗口）与长期记忆（持久化存储）的边界在哪，更答不出变量注入（Variable Injection） 是让 Agent 从“复读机”变成“执行器”的关键。答好了能展示你对 Agent 状态机、工具调用参数自动填充、以及记忆压缩策略的实战理解。
2️⃣ 标准答
核心矛盾：Agent 每轮对话都是独立推理，模型本身无状态。没有记忆体系，多轮交互会退化成“每轮都从零开始”。
1. 短期记忆（Short-term Memory）—— 上下文窗口管理
- 实现：用滑动窗口 + Token 预算控制。例如 GPT-4 128K 窗口，但实际只保留最近 3-5 轮对话 + 当前工具调用结果。
- 为什么这么做：全量历史会导致注意力分散、推理变慢、成本飙升。工程取舍：保留关键事实，丢弃冗余对话。例如用户说“帮我查北京到上海的机票”，上一轮“我想去北京玩三天”中的“北京”必须保留，但“玩三天”这种意图描述可以压缩。
- 实际落地的坑：窗口截断时丢失了工具调用中间结果（如 API 返回的航班列表）。解法：对工具返回做摘要（summarize），只保留关键字段（航班号、价格、时间），丢弃原始 JSON。
2. 长期记忆（Long-term Memory）—— 持久化事实存储
- 实现：用向量数据库（如 Chroma / Pinecone）存储用户偏好、历史事实。每轮对话结束后，用 LLM 提取关键实体（出发地、目的地、日期）并写入。
- 为什么这么做：短期记忆窗口有限，用户可能隔 10 轮后说“还是上次那个酒店”。工程取舍：只存结构化事实，不存对话原文。例如存
{user_id: 123, departure: "北京", destination: "上海", date: "2024-03-15"}，而不是整段对话。 - 实际落地的坑：事实冲突（用户先说“去北京”，后说“改去上海”）。解法：用版本号或时间戳覆盖旧值，并在注入时让 LLM 确认“你之前说去上海，现在确认吗？”。
3. 变量注入（Variable Injection）—— 让 Agent 自动填参数
- 实现：在工具调用前，从长期记忆中读取当前会话的变量字典，注入到工具参数模板中。例如航班查询工具需要
{departure, destination, date}，Agent 从记忆里取{departure: "北京", destination: "上海", date: "2024-03-15"}，自动填充。 - 为什么这么做：避免模型每轮都问“出发城市是？”。工程取舍：变量注入优先于模型生成。如果记忆中有值，直接注入，模型只负责确认或修改；如果记忆为空，才让模型主动提问。
- 实际落地的坑：变量注入后模型仍会重复提问（因为 prompt 里没告诉它“变量已注入”）。解法：在 system prompt 中显式声明“当前会话变量：{departure: 北京}，如果用户未修改，直接使用，不要重复询问”。
总结：短期记忆管“最近说了什么”，长期记忆管“记住了什么事实”，变量注入管“怎么用这些事实去调工具”。三者缺一不可。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从短期记忆、长期记忆、变量注入三个层面回答。短期记忆用滑动窗口管理上下文，保留最近 3-5 轮关键事实；长期记忆用向量数据库持久化用户偏好和会话变量，只存结构化事实不存原文；变量注入在工具调用前自动填充参数，避免模型重复提问。总结一句：没有这三层，Agent 就是每轮失忆的复读机，无法完成多轮任务。”
4️⃣ 高频追问 & 应对
追问 1：如果用户说“帮我查机票”，但记忆里没有出发城市，你怎么处理？
触发变量缺失检测。在工具调用前，检查变量字典中所有必填字段。如果
departure为空，不调用工具，而是让 Agent 生成反问：“请问您从哪个城市出发？” 同时将反问结果写入短期记忆，等用户回答后更新变量字典。工程取舍：宁可多问一轮，也不让工具调用失败。实际落地中，可以设置“必填字段列表”和“可选字段列表”，必填缺失才反问，可选缺失直接忽略。
追问 2：长期记忆中的事实怎么更新？用户说“改去深圳”，之前存的是“上海”。
用覆盖策略。每次对话结束后，LLM 提取当前会话中的事实，与长期记忆中的旧值对比。如果冲突，以最新值为准，并记录变更日志。例如旧值
{destination: "上海"}，新值{destination: "深圳"}，直接覆盖。但为了防误改，可以在注入时让模型确认：“您之前说去上海，现在改为深圳，对吗？” 工程取舍：信任用户最新意图，但加一层确认，避免因上下文歧义导致错误覆盖。
追问 3：变量注入和工具调用参数自动填充，怎么避免模型“幻觉”填充？
加一层校验。变量注入后，在工具调用前，用规则引擎（如 JSON Schema）校验参数格式。例如日期字段必须是
YYYY-MM-DD格式，如果记忆中的值是“下周一”，注入前先用 LLM 解析成具体日期。如果解析失败，触发反问。工程取舍：规则校验优先于模型推理，因为模型可能生成非法参数（如负数价格）。实际落地中，可以设置“参数白名单”和“格式模板”，不符合的直接拒绝调用。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“用 Redis 存对话历史，每次把全部历史塞进 prompt” → ✅ 正确做法是只保留关键事实，用变量字典压缩，避免 token 爆炸和注意力分散。
- ❌ 说“长期记忆就是向量数据库存 embedding，然后做相似度检索” → ✅ 长期记忆的核心是结构化事实存储，不是全文检索。向量检索用于“模糊回忆”，变量注入需要精确值。
- ❌ 说“变量注入就是让模型自己从历史里提取参数” → ✅ 变量注入是系统层自动填充，不是模型层推理。模型只负责确认和修改，减少幻觉和重复提问。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“记忆检索 vs 文档检索”角度切入，对比 RAG 的向量检索和 Agent 的变量注入，强调 RAG 是“找文档”，Agent 记忆是“找事实”。
- 如果你只做过传统 NLP：用“槽位填充（Slot Filling）”类比，说变量注入就是多轮对话中的槽位管理，但 Agent 需要动态更新槽位值，而不是固定模板。
- 如果你是校招无项目：聚焦论文复现 demo，比如用 LangGraph 实现一个旅行规划 Agent，展示短期记忆（滑动窗口）、长期记忆（SQLite 存事实）、变量注入（自动填工具参数）的代码片段。
- 《MemGPT: Towards LLMs as Operating Systems》—— 长期记忆与短期记忆的分层管理
- 《LangGraph: Multi-Agent State Management》—— 变量注入与状态机实现
- 《Toolformer: Language Models Can Teach Themselves to Use Tools》—— 工具调用参数自动填充
- 《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》—— 对比 RAG 与 Agent 记忆
- 《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》—— 多轮推理中的上下文管理