面试题库

30 天从前端工程师到 Agent 工程师

D18 历史保真与摘要、多模态占位、checkpointer 持久化

• 记忆应该怎么分层？短期上下文、摘要、长期记忆分别放什么、丢了会怎么样？How should agent memory be layered? What belongs in short-term context, in summaries, and in long-term memory — and what happens when each is lost?

  国内高频海外高频基础#memory#context-management#multi-agent

  分析过程 · 先想清楚再作答

  1. 这题的区分度不在能不能列出三层，而在能不能说出**每一层丢了会怎样**。只报名词的答案，面试官听不出你有没有真的运维过。
  2. 先给一条可复用的拆法：按「谁在读它、活多久、丢了能不能补」三个问题去分，任何一个记忆方案都能被这三问切开。
  3. 短期上下文是这一次请求要发给模型的那个消息数组，随请求结束作废，全量进 token 账单；它丢了只影响这一轮的连贯性，原文还在你自己的会话记录里，可以重放。
  4. 摘要是短期上下文的派生数据，用来在窗口顶到之前把早期内容压短；它丢了可以重新生成——**前提是原文另存了一份**。所以摘要绝不能覆盖原文，这是「压缩不可逆」那条纪律的实际落点。
  5. 长期记忆是跨会话的用户事实与偏好，不进消息数组，存在外部检索层里按需捞几条注入；它丢了的表现是「这个用户被系统忘光了」，不影响单次可用，但产品价值直接掉一层。
  6. 多 Agent 还要补第四层，也是最容易被忽略的一层：**图的执行状态**。它包含消息、共享工作区、评审轮次、降级标记，是唯一一份会被检查点持久化并在恢复时重放的数据。它丢了的后果最重——一次已经花掉九次模型调用的执行必须从头再来，而且用户界面还停在转圈。
  7. 可以预期的追问：摘要该放在消息数组里还是单独一个字段？答单独字段，理由是原文与派生数据要分开存，才可能换一种策略重新生成；混在一起之后你分不清哪条是真发生过的、哪条是事后编的。

  How to reason about it · think before answering

  1. The discriminator here is not listing three layers, it is saying what breaks when each one is lost. An answer that only names the layers tells the interviewer you have never operated one.
  2. Offer a reusable split first: sort any memory scheme by who reads it, how long it lives, and whether it can be rebuilt after loss. Those three questions cut through every design.
  3. Short-term context is the message array sent to the model this turn. It dies with the request and is billed in full every turn. Losing it only costs coherence for that turn, because the raw transcript still lives in your own store and can be replayed.
  4. A summary is derived from short-term context, produced to shrink early turns before the window fills. It can be regenerated after loss — but only if the raw transcript was stored separately. That is the practical reason a summary must never overwrite the original.
  5. Long-term memory holds cross-session user facts and preferences. It never enters the message array; it lives in a retrieval layer and a few hits get injected on demand. Losing it means the system forgot the user — single requests still work, but the product gets noticeably worse.
  6. Multi-agent adds a fourth layer people usually miss: graph execution state — messages, shared workspace, review rounds, degraded flags. It is the only copy that gets checkpointed and replayed on resume, and losing it is the most expensive failure: a run that already burned nine model calls starts over while the user watches a spinner.
  7. Expect the follow-up: should the summary live inside the message array or in its own field? Say its own field — keeping raw and derived data apart is what lets you regenerate with a different strategy later; merged together you can no longer tell what actually happened from what was written after the fact.

  答题要点

  • 按「谁在读、活多久、丢了能不能补」三问分层，比背名词有用
  • 短期上下文：本轮请求的消息数组，随请求作废，全量计费，丢了可从原始记录重放
  • 摘要：短期上下文的派生数据，可重新生成，前提是原文另存——所以摘要不能覆盖原文
  • 长期记忆：跨会话的用户事实，存在检索层按需注入，丢了是「系统忘了这个人」
  • 多 Agent 多一层图执行状态：消息 + 工作区 + 评审轮次 + 降级标记，会被检查点持久化并在恢复时重放，丢了最贵
  • 摘要放独立字段而不是塞回消息数组，原文与派生数据分开存才可能换策略重生成

  Key points

  • Layer by who reads it, how long it lives, and whether it can be rebuilt — that beats reciting names
  • Short-term context: this turn's message array, discarded after the request, billed in full, replayable from your own transcript
  • Summary: derived from short-term context and regenerable, but only if the raw transcript is stored separately — so it must never overwrite the original
  • Long-term memory: cross-session user facts in a retrieval layer, injected on demand; losing it means the system forgot the user
  • Multi-agent adds graph execution state — messages, workspace, review rounds, degraded flags — checkpointed and replayed on resume, and the most expensive to lose
  • Keep the summary in its own field rather than back in the message array, so raw and derived data stay separable