记忆架构与优先级

Q：讲一下 Agent 中的”长短期记忆”

来源：字节后端开发 Agent 一面 【蚂蚁AI应用开发二面同题：Agent 长期记忆设计思路】【淘天Agent开发同题：短期对话记忆和长期记忆分别怎么提取和存储】

新手答：“短期记忆是当前对话，长期记忆存数据库。”

高手答：

Agent 的记忆系统可以类比人类认知模型，分三层：

记忆类型	对应人类认知	Agent 中的实现	生命周期
感知记忆	瞬时记忆	当前输入 + 最近 1-2 轮对话	当前请求
短期记忆	工作记忆	上下文窗口内的全部对话历史	当前会话
长期记忆	长时记忆	外部存储（向量库、数据库、文件）	跨会话持久

短期记忆的工程挑战：

上下文窗口有限。对话轮次多了，早期信息被截断或被淹没。解决方案：

• 滚动窗口：只保留最近 N 轮原始对话
• 摘要压缩：定期让模型把已完成的对话压缩成结构化摘要
• 关键信息外置：实时提取用户提到的关键约束（预算、日期、偏好），存到独立的状态变量里，每轮强制注入

长期记忆的工程挑战：

存什么、怎么查、怎么融合：

• 存什么：不是把所有对话都存，而是提取有价值的信息——用户偏好、历史决策、学到的经验
• 怎么查：用 embedding 做语义检索，但要控制召回数量——塞太多长期记忆会干扰当前任务
• 怎么融合：长期记忆和短期上下文可能矛盾（用户偏好变了），需要有时效性权重——最近的记忆优先级更高

进阶：还有一类”工作记忆”——Agent 在执行多步任务时的中间状态（to-do list、已完成步骤、中间结果）。它不属于对话历史，也不属于长期记忆，是任务级别的临时状态。

记忆更新策略：

记忆写入后不是一成不变的，需要一套更新机制保证数据质量：

• 增量更新：新信息覆盖旧信息时不直接替换，而是版本化存储——“用户从北京搬到上海”→ 旧记忆降权但保留，新记忆设为当前有效版本
• 冲突检测：每次写入前和已有记忆做语义比对，发现矛盾时触发更新流程而非简单追加
• TTL 分级淘汰：事实性记忆（手机号、住址）设长 TTL，偏好性记忆（上次选了经济舱）设短 TTL，上下文性记忆（刚才聊了天气）会话结束即清理
• 主动验证：高频使用的记忆定期通过用户交互确认——“我记得您偏好素食，现在还是吗？”

差距在哪：新手只分了两层且没有展开。高手分了三层（感知/短期/长期），每层都说了工程挑战和解法，还补充了“工作记忆”这个进阶概念。面试官要的不是“存数据库”三个字，而是你能不能把记忆按层次拆清楚。

---

Q：一个 Agent 系统里，什么时候应该追问用户，什么时候应该自己继续推理？

来源：腾讯大模型应用开发二面

新手答：“不确定就问用户。”

高手答：

判断标准主要有两个：信息缺口是否影响正确执行，以及这个缺口能不能通过工具或外部知识补上。

情况	策略
缺的是执行必需参数（如订单号）	追问用户
缺的是可由外部系统补齐的信息（如城市从画像获取）	自己继续推理
能猜到但猜错代价极高（如支付、删除）	宁愿追问，不擅自补全

追问不是因为模型”不聪明”，而是因为系统要在体验和风险之间做平衡。无脑追问体验差，无脑猜测风险高——好的 Agent 需要根据操作的可逆性和代价来决定。

主动澄清 vs 历史画像推断的决策框架：

在电商、导购等场景中，Agent 还面临一个更精细的判断：用户说”帮我挑个好用的”——是追问”您需要什么功能？”还是直接结合历史购买记录推荐？

条件	策略	原因
有高置信度历史画像 + 低风险操作	强行推断，直接推荐	体验好，用户觉得”懂我”
有历史画像但置信度低（很久没买/品类陌生）	展示推断 + 请求确认	“根据您之前的偏好，推荐XX，是否合适？”
无历史画像 + 高风险操作（支付/删除）	必须追问	猜错代价大于追问成本
无历史画像 + 低风险操作	给出默认推荐 + 提供修改入口	先动起来，不阻塞流程

核心原则：追问的目的是减少不确定性，不是收集所有信息。如果历史画像能把不确定性降到可接受水平，就不要追问。

差距在哪：新手的”不确定就问”看起来安全，但会导致过度追问、体验打折。高手用两个判断标准（是否影响执行 + 能否自动补齐）加一个风险维度（猜错代价）构建了完整的决策框架。面试官考的是你能不能在”用户体验”和”执行安全”之间做工程化的平衡。

追问：用户表达极度模糊（如”帮我看看””随便推荐”），Agent 在工程上怎么处理？

上面的决策框架处理的是”有部分信息但不完整”的情况。但实际场景中还有信息量接近于零的极端情况——用户说”帮我看看”，连意图分类都做不了。

工程处理的三层兜底：

层级	方法	何时触发
第一层：隐式信号补全	从用户当前页面、最近行为、会话上下文推断意图	有可用的行为信号时
第二层：选择式澄清	给出 2~3 个最可能的意图选项，让用户选	行为信号不足以做高置信推断时
第三层：默认行动 + 修正入口	执行最常见的默认意图，提供”不是我想要的”修正按钮	用户对追问不耐烦或场景要求快速响应时

第二层的实现细节——选择式澄清比开放式追问效果好得多：

❌ 开放式：”您想要什么？”（用户不知道从何说起，可能直接走了）
✅ 选择式：”您是想——A. 看看最近的热门推荐 B. 找上次浏览过的商品 C. 有具体想买的东西？”

选项生成的方法：

1. 频率统计：从历史数据中挖掘该类模糊 query 最常对应的 Top-3 意图
2. 用户画像：结合用户历史行为，个性化排序选项
3. 场景上下文：从当前页面/入口推断（从首页进来 vs 从售后页进来，默认选项完全不同）

核心原则：不要让用户做填空题，让用户做选择题。每次澄清最多问一个问题，且必须带选项。

---

Q：对于上下文工程有什么经验？有没有做过 to-do list？为什么让模型更聚焦？

来源：抖音基础架构 Agent 一面 / 字节 Agent 实习二面

新手答：“就是把相关信息塞到上下文里。”

高手答：

上下文工程的核心不是“塞更多信息”，是让模型在每一步都能看到恰好需要的信息，不多不少。

To-do list 机制是上下文工程的一个重要实践：

1. 任务开始时，让模型把复杂任务拆解成一个结构化的 to-do list，每个 item 有状态标记（pending / in_progress / completed）
2. 每一步执行后，更新对应 item 的状态，并把当前 to-do list 注入到下一步的上下文中
3. 模型在每一步都能看到“全局做到哪了、当前该做什么、还剩什么没做”

为什么这样能让模型更聚焦：

大模型的一个核心问题是上下文越长越容易迷失——长对话中，模型会忘记最初的任务目标，或者在中间步骤偏离方向。To-do list 起到**锚点（Anchor）**的作用：

• 它把隐式的任务进度变成了显式的结构化状态，模型不需要从历史消息中推断“我做到哪了”
• 每一步都有明确的当前任务，减少了模型的决策空间
• 已完成的 item 可以压缩或折叠，只保留结论，释放上下文空间给当前任务

实现方式：

• 在 System Prompt 中定义 to-do list 的格式规范
• 用工具调用（如 task_update）让模型显式更新任务状态
• 每轮对话前，把最新的 to-do list 作为上下文的固定部分注入，位置放在历史消息之前、当前任务之前

差距在哪：新手把上下文工程等同于“塞信息”。高手展示了 to-do list 这个具体的上下文管理手段，且解释了它为什么有效——把隐式进度变成显式状态。面试官考的是你有没有超越“Prompt Engineering”的认知——上下文工程是系统级的信息管理。

---

Q：Agent 需要同时读知识库、调外部 API、结合用户历史偏好，怎么处理这三类上下文的优先级？

来源：腾讯大模型应用开发二面

新手答：“都放进上下文里让模型自己判断。”

高手答：

三类信息不能混着塞，要先定义优先级：

优先级从高到低：
1. 系统规则（最高）
2. 当前轮用户明确输入
3. 外部工具返回 + 知识库证据
4. 用户历史偏好（最低）

因为偏好只影响表达方式或默认选择，不能覆盖当前事实。比如用户历史里一直偏好 Python，但这轮明确说“用 Java 给我写”，那当前轮约定一定优先。又比如知识库里有旧规则，外部 API 返回的是实时状态，那实时状态优先于静态知识。

真正做 Prompt 组装时，最好按槽位拼接，把“当前目标”“实时证据”“历史画像”分开，而不是混成一段自然语言。这样模型能清楚地看到每类信息的边界和权重。

差距在哪：新手把所有信息混在一起丢给模型——模型没有优先级意识，容易被低优先级信息干扰。高手定义了四级优先级，且在 Prompt 组装时按槽位分离。面试官考的是你有没有对多源上下文做过系统性的优先级设计。

---

Q：你怎么理解 Agent 里的“状态”而不是“上下文”？

来源：腾讯大模型应用开发二面

新手答：“状态就是上下文的一部分。”

高手答：

上下文更像模型看到的输入材料，状态则是系统对任务推进过程的结构化刻画。Agent 做得深一点以后，不能只靠大段对话历史维持执行，因为模型并不天然擅长长期状态一致性。

状态通常包括：

当前阶段、已完成任务、失败次数、已调用工具、关键中间结果、待确认信息

这样做的好处是，模型不用每次从自然语言自己猜任务进行到哪一步，系统可以明确告诉它现在在什么节点。很多所谓 Agent 不稳定，本质上不是上下文不够，而是没有显式状态。

差距在哪：新手把状态和上下文混为一谈。高手区分了两者——上下文是“模型看到的输入”，状态是“系统对任务进度的结构化刻画”。面试官考的是你理不理解 Agent 的核心工程挑战：把隐式的执行进度变成显式的结构化状态。