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)

• When a long conversation outgrows the context window, how do you compress it — when do you trigger, what do you drop, and what do you keep?长对话里上下文放不下了，你会怎么压缩？什么时候触发、压掉什么、保留什么？

  Common in ChinaCommon overseasIntermediate#context-engineering#compression#cost

  How to reason about it · think before answering

  1. Saying 'summarize it' earns nothing — everyone says that. The signal is whether you name a trigger point and a keep-list; without those you sound like someone who never ran a long conversation in production.
  2. Split it into three questions before answering: when to compress, what to drop, what to keep. The split itself scores, because it frames compression as a policy rather than a function.
  3. Trigger on a threshold, not a timer, and never on an error. Give a number and justify it: compress at roughly 70% of the history budget, because summarizing is itself a model call that can be slow or fail. Waiting until 90% means one timed-out summary call and the next turn slams into the window limit.
  4. Drop the process: intermediate reasoning, raw tool payloads already consumed, requirements the user later reversed — their value has already settled into later conclusions. Keep the system prompt (it is not history), the most recent turns verbatim, and any constraint or fact the user stated explicitly. Getting that last one wrong makes the model visibly forget.
  5. Add the detail others miss: the cut must land on a turn boundary. Slicing between an assistant tool_calls message and its matching tool result leaves a dangling call, and most providers reject that request with a 400. This is the line that proves hands-on experience.
  6. Two follow-ups to expect. Which model summarizes? A cheap small one — summarization is extraction, not reasoning, which ties back to tiered routing. And what if the summary call fails? Degrade to a plain sliding window that drops the oldest turns, so a failed compression never fails the whole turn.

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

  1. 这题的区分度不在「用摘要」三个字上，几乎人人都答得出。区分度在你有没有说出触发时机和保留清单——只答「让模型总结一下前面的对话」的，面试官会判定你没在长对话上线过。
  2. 先把问题拆成三问再逐个答：什么时候压、压掉什么、保留什么。这个拆法本身就是加分项，因为它说明你把压缩当成一个策略而不是一个函数。
  3. 触发用阈值不用定时器，也不能等报错。给一个具体数字并解释它：历史占用到预算的七成就动手，因为摘要本身是一次模型调用，有延迟也可能失败，卡到九成再压，一旦摘要超时下一轮就直接撞窗口上限了——七成是留给自己的抢救时间。
  4. 压掉的是过程性内容：中间推理、已经被消费完的工具原始返回值、用户后来推翻的需求。它们的共同点是价值已经沉淀进后面的结论里。保留的是系统提示词（它不属于历史）、最近若干条原文、以及用户明确声明过的约束和事实——后者写错了模型会当场失忆。
  5. 再补一条别人不会说的：切口必须对齐到一轮的开头。切在 assistant 的 tool_calls 和对应的 tool 结果中间，下一次请求就有了悬空调用，多数厂商的 API 直接返回 400。这一条最能证明你真的调过。
  6. 可以预期的追问有两个。一是摘要该用哪个模型：用便宜的小模型就行，摘要是抽取任务不是推理任务，这也接上了 D4 的分层路由。二是摘要调用失败了怎么办：降级到不摘要的滑动窗口（直接丢最早的几轮），保证请求发得出去，别让压缩失败连带整轮对话失败。

  Key points

  • Threshold-triggered at about 70% of the history budget, because the summary call itself is a slow, fallible model call that needs headroom
  • Drop process, keep conclusions: discard intermediate reasoning and consumed raw tool payloads; keep the system prompt, the recent turns verbatim, and explicit user constraints and facts
  • Align the cut to a turn boundary — slicing between tool_calls and its tool result makes the next request fail with a 400
  • Compression is lossy and irreversible: keep an append-only original, send the compressed version, and read the original when you need to backtrack or fork
  • Summarize with a cheap small model, and degrade to a sliding window if the summary call fails so compression failure never fails the turn

  答题要点

  • 阈值触发：历史占用到预算七成就压，因为摘要本身是一次会失败、有延迟的模型调用，必须留抢救余量
  • 压过程、留结论：丢中间推理和已消费的工具原始返回，保留系统提示词、最近若干条原文、用户明确声明的约束与事实
  • 切口必须对齐到一轮开头，切在 tool_calls 与 tool 结果之间会让下一次请求返回 400
  • 压缩是有损且不可逆的：原始历史另存一份只追加，发给模型的是压缩版，需要回溯或分叉时读原始版
  • 摘要用便宜的小模型；摘要失败要能降级成滑动窗口，别让压缩失败连累整轮对话
• 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 计费受窗口约束；长期记忆跨会话、按需检索后注入、按条存储受检索质量约束
  • 判据三问：跨会话还需要吗、会随时间失效吗、能被检索捞回来吗——三个都是就进长期记忆
  • 常见误用是把长期记忆整包塞进上下文，既撑爆窗口又用不相关的记忆干扰模型，正确做法是检索最相关的三五条
  • 长期记忆要带时间戳和来源，用户改主意时覆盖旧记忆，避免两条矛盾记忆并存
  • 长期记忆是合规上必须能按用户定位并整体删除的那一部分，短期上下文随会话删除即可
• How do context engineering and RAG relate, and what breaks if you do RAG without context management?上下文工程和 RAG 检索是什么关系？只做 RAG 不做上下文管理会出什么问题？

  Common in ChinaCommon overseasDeep dive#context-engineering#rag#retrieval

  How to reason about it · think before answering

  1. The hinge word is 'relate'. Treating them as two parallel techniques is the standard weak answer — the right frame is containment: context engineering decides what goes into this request, and RAG is one supply mechanism that fetches what should go in.
  2. Separate the responsibilities and it becomes obvious: RAG solves 'the information is neither in the weights nor in this conversation' by retrieving it; context engineering solves 'the retrieved chunks plus the history plus the tool definitions all have to fit, in some priority order'. One owns sourcing, the other owns budget.
  3. So RAG without context management breaks in three ways, best delivered in this order. Crowding: retrieved documents run to thousands of tokens and squeeze out the conversation, so the model knows the manual but forgot what the user said three turns ago. Interference: raising top-k feels safe but irrelevant chunks dilute attention and accuracy drops instead of rising. Cost: retrieved text is resent every turn, so a 2k-token passage costs ten times over ten turns.
  4. Give the correct combination: budget history and retrieval separately, keep retrieval to top-k without re-injecting the same chunks every turn, compress history when it crosses its line, and make sure both lines together still leave room for output. This 'separate budgets' framing lands much better than a vague 'you need to balance them'.
  5. Expect the follow-up on placement: putting retrieved context near the current question usually works better, and it should be labeled with its source so the model can tell reference material from what the user actually said. Note too that it is single-turn context and should not be written into the persisted history and resent forever.

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

  1. 题眼在「关系」。把两者说成并列的两种技术是最常见的失分答法——正确的框架是包含关系：上下文工程是「决定这次请求里放什么」，RAG 是它的一种供给手段，负责「从外部捞该放进去的东西」。
  2. 拆开看职责就清楚了：RAG 解决的是「信息不在模型参数里、也不在当前对话里」，靠检索把它取回来；上下文工程解决的是「取回来的东西、加上历史、加上工具定义，一共放不放得下、该按什么优先级放」。前者管来源，后者管预算。
  3. 所以只做 RAG 不做上下文管理会出三类问题，最好按这个顺序说。第一是挤占：检索回来的文档动辄几千 token，直接拼进去把对话历史挤没了，模型记得住资料却忘了用户三句话前说过什么。第二是干扰：召回条数调大看着安全，实际上不相关的片段会稀释模型注意力，准确率不升反降。第三是成本：检索结果每一轮都重发，一段两千 token 的资料聊十轮就付了十次。
  4. 给出正确的组合姿势：先给历史和检索结果各划一条预算线，检索结果只保留 top-k 且不跨轮重复注入，历史超线就压缩，两条线加起来必须留出输出空间。这套「分账」的说法比笼统的「要平衡」有说服力得多。
  5. 可以预期的追问：检索结果该放在系统提示词里还是当成一条 user 消息？答放在靠近当前问题的位置通常效果更好，而且要标注来源便于模型区分「资料」和「用户说的话」；顺带说清它是一次性上下文，不该被写进长期会话历史里反复重发。

  Key points

  • They are not parallel: context engineering decides what enters the request, and RAG is one supply mechanism for information that is neither in the weights nor in the conversation
  • RAG alone crowds out history — multi-thousand-token retrievals evict the conversation, so the model knows the docs but forgot the user's last request
  • A bigger top-k is not safer: irrelevant chunks dilute attention and accuracy drops, so cap retrieval
  • Retrieved text is single-turn context; persisting it into the history means paying for it on every subsequent turn
  • Budget history and retrieval on separate lines, compress history when it crosses its line, and leave room for the output on top of both

  答题要点

  • 不是并列关系而是包含关系：上下文工程决定这次请求放什么，RAG 是给它供货的一种手段，负责把不在模型和对话里的信息检索回来
  • 只做 RAG 会挤占历史：几千 token 的检索结果把对话挤没，模型记得住资料却忘了用户刚说的话
  • 召回条数越大越准是错觉：不相关片段会稀释注意力，准确率反而下降，应控制 top-k
  • 检索结果每轮重发会持续计费，属于一次性上下文，不该写进持久化历史反复重发
  • 正确姿势是给历史和检索各划一条预算线，历史超线就压缩，两条线之外还要留出输出空间