Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D6 Messages, Context Engineering and Compression, Session Storage/Recovery/Forking (dg M06/M08/M09/M10)

• Where do you draw the line between short-term context and long-term memory, and how do you decide where a given fact belongs?短期上下文和长期记忆的边界怎么划？一条信息该往哪放，你的判断依据是什么？

  Common in ChinaCommon overseasBasic#memory#context-engineering

  How to reason about it · think before answering

  1. This looks conceptual but is really asking for an operational test. Reciting 'short-term lives in messages, long-term lives in a vector store' just describes the status quo and gives no signal.
  2. Lay out the engineering properties and the boundary draws itself: short-term context dies with the session, ships in full on every request, is billed per token and capped by the window; long-term memory spans sessions, is retrieved and injected rather than always sent, is stored per item and capped by retrieval quality.
  3. Give a reusable test — this is the core of the answer. Ask three questions: is it still needed after this session ends, does it expire with time, can retrieval find it again? Three yeses means long-term; a no on the first means it stays short-term. Illustrate: 'the user lives in Shanghai' is long-term, 'the user just asked me to shorten that paragraph to three sentences' is not.
  4. Name the common failure: stuffing all long-term memory into the prompt. Two hundred preferences accumulated over six months will both blow the window and drown the model in irrelevance. The value of long-term memory is retrieving the three or four relevant items, not the volume stored.
  5. Expect the follow-up on updates and expiry: memories need timestamps and provenance, and a changed preference must overwrite rather than coexist with a contradictory one. Add the deletion angle — long-term memory is the part you must be able to locate and erase when a user asks for their data to be deleted.

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

  1. 这题看着像概念题，其实考的是你有没有一条可执行的判据。背出「短期在 messages 里、长期在向量库里」只是描述现状，答不出「为什么这条该进长期」就没有区分度。
  2. 先把两者的工程属性摆出来，边界自然就清楚了：短期上下文随会话结束作废、全量进请求、按 token 计费、受窗口约束；长期记忆跨会话存在、不进请求而是检索后注入、按条存储、受检索质量约束。
  3. 给一条可复用的判据，这是本题的核心：问三句话——跨会话之后还需要吗、会随时间失效吗、能通过检索捞回来吗。三个都是「是」就进长期记忆，第一个是「否」就留在短期。举例说明：用户住上海进长期，用户刚才让我把段落改成三句话留短期。
  4. 点出最常见的误用：把长期记忆当上下文一次性全塞进去。用了半年攒两百条偏好，全塞进请求既撑爆窗口，又因为大量不相关记忆干扰模型判断——长期记忆的价值在于按需检索出最相关的三五条，不在于存了多少。
  5. 可以预期的追问：长期记忆怎么更新和失效？答要点是记忆要带时间戳和来源，用户改了主意要能覆盖旧记忆而不是并存两条矛盾的；再补一句删除权——用户要求删数据时，长期记忆是必须能定位并整体删掉的那一部分。

  Key points

  • Short-term context dies with the session, ships in full, and is billed per token under the window cap; long-term memory spans sessions, is retrieved on demand, and is capped by retrieval quality
  • The three-question test: is it needed after this session, does it expire, can retrieval find it — three yeses means long-term
  • The common failure is injecting the whole memory store, which blows the window and drowns the model in irrelevance; retrieve the three or four relevant items instead
  • Long-term memories need timestamps and provenance so a changed preference overwrites the old one instead of contradicting it
  • Long-term memory is the part that must be locatable and deletable per user for compliance, while short-term context simply dies with the session

  答题要点

  • 短期上下文随会话作废、全量进请求、按 token 计费受窗口约束；长期记忆跨会话、按需检索后注入、按条存储受检索质量约束
  • 判据三问：跨会话还需要吗、会随时间失效吗、能被检索捞回来吗——三个都是就进长期记忆
  • 常见误用是把长期记忆整包塞进上下文，既撑爆窗口又用不相关的记忆干扰模型，正确做法是检索最相关的三五条
  • 长期记忆要带时间戳和来源，用户改主意时覆盖旧记忆，避免两条矛盾记忆并存
  • 长期记忆是合规上必须能按用户定位并整体删除的那一部分，短期上下文随会话删除即可

D18 History Fidelity and Summarization, Multimodal Placeholders, Checkpointer Persistence

• 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?记忆应该怎么分层？短期上下文、摘要、长期记忆分别放什么、丢了会怎么样？

  Common in ChinaCommon overseasBasic#memory#context-management#multi-agent

  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.

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

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

  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

  答题要点

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