面试题库

5 天上下文工程

D3 工具结果与检索的上下文管理：按需加载、摘要与裁剪、结构化返回

• 为什么说工具返回的内容是不可信输入？做了字段白名单裁剪之后还需要担心吗？Why are tool results untrusted input, and does field whitelisting make the concern go away?

  国内高频海外高频深入#prompt-injection#trust-boundary

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

  1. 这题有个陷阱：很多人会把它当成上下文工程题来答，说「裁剪之后就干净了」。它其实在考你分不分得清预算问题和安全问题。
  2. 怎么拆：先说清楚为什么不可信。工具返回的内容来自第三方接口、用户上传的文件、网页抓取的结果，不是你写的；而模型读到它的时候，和读你的系统提示是在同一个上下文里，没有天然的权限分层。里面可以藏一句「忽略之前的所有指令」，这就是提示注入。
  3. 关键结论：字段白名单一点都不解决这个问题，甚至更危险——你把字段裁到只剩四个，会产生一种「已经清理过了」的错觉，但那四个字段的值仍然是外部可控的自由文本，注入照样能进来。裁剪管的是体积，不是内容的可信度。
  4. 给出正确的分层：上下文工程负责决定装什么进去，安全机制负责决定装进来的东西能做什么。后者要靠最小权限、工具白名单、把外部内容和指令在结构上分开、以及对有副作用的操作加确认，而不是靠裁剪。
  5. 可预期的追问：那能不能在裁剪层顺手做过滤？可以做一些低成本的（比如剥掉控制字符、给外部内容加明确的包裹标记），但不要把它当成防线——基于关键词的过滤对提示注入几乎无效，真正的边界在权限层。

  How to reason about it · think before answering

  1. There is a trap here: many answer it as a context question and claim trimming cleans the data. It actually tests whether you separate budget problems from security problems.
  2. Explain the untrust first. Tool results come from third-party APIs, user-uploaded files, or scraped pages. You did not write them, yet the model reads them in the same context as your system prompt, with no inherent privilege boundary. A line saying to ignore prior instructions can ride along; that is prompt injection.
  3. The key point: field whitelisting does nothing about this and can make it worse by creating a feeling of sanitization. The four surviving fields still carry externally controlled free text. Trimming governs volume, not trustworthiness.
  4. Give the right layering: context engineering decides what goes in; security decides what the content is allowed to cause. That means least privilege, tool allowlists, structurally separating external content from instructions, and confirmation on side-effecting actions.
  5. Expect the follow-up: can the trimming layer filter too? Cheap hygiene like stripping control characters or wrapping external content in explicit delimiters is fine, but keyword filtering is close to useless against injection. The real boundary is the permission layer.

  答题要点

  • 工具结果来自外部系统，模型读它和读系统提示在同一个上下文里，没有天然的权限分层。
  • 字段白名单只减体积，不改变内容的可信度，反而容易造成已清理的错觉。
  • 正确分层：上下文工程决定装什么，安全机制决定装进来的东西能做什么。
  • 防线在最小权限、工具白名单、结构上隔离外部内容、有副作用的操作加确认，不在关键词过滤。

  Key points

  • Tool results originate outside your system yet share a context with your instructions, with no built-in privilege boundary.
  • Field whitelisting reduces volume only; it does not change trustworthiness and can create a false sense of sanitization.
  • Correct layering: context engineering decides what enters, security decides what it may cause.
  • Defenses live in least privilege, tool allowlists, structural separation of external content, and confirmation on side effects, not keyword filters.

D4 长时程会话：压缩、笔记与记忆文件、子代理隔离与交接摘要

• 压缩最容易丢什么？你怎么验证一次压缩没有丢掉关键信息？What does compaction lose most easily, and how do you verify that a given compaction kept what mattered?

  国内高频海外高频深入#compaction#verification

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

  1. 这题的区分度全在后半句。谈「要保留重要信息」是空话，面试官想听的是一个可执行的验证机制，以及你有没有真的被它拦下来过。
  2. 怎么拆：先说清压缩为什么比裁剪危险。裁剪动结构，删掉一个字段你知道删了什么、也能取回来；压缩动语言，丢掉了什么是模型决定的，而且丢完不留任何标识。
  3. 点出最脆弱的两类内容：一是最近几轮正在进行的事，一折叠就失去指代对象，模型下一句就会问你说的是哪一单；二是形式上不像结论的硬性要求，比如用户提出的时间点、情绪化诉求、口头承诺——它们在语言上不重要，在业务上是全部。还有一类是标识符，摘要很容易把订单号写成「相关订单」。
  4. 结论给验证机制：预置一组「压缩后必须还能找到」的关键事实，每次压完逐条核对，不通过就拒绝这次压缩或调大保留轮数。三条配套措施是：保留最近若干轮原文、在摘要提示词里让硬性要求单独成段、明确要求逐字保留标识符。
  5. 可预期的追问：你被这个检查拦下来过吗？给一个具体例子最有力，比如把保留轮数从 6 调到 1 时压缩率从 68% 涨到 87%，但「用户要求周五 18:00 前答复」这条直接消失——因为它只活在最近几轮原文里，而且它不像一条结论。

  How to reason about it · think before answering

  1. The signal is entirely in the second half. Saying you keep the important parts is empty; interviewers want an executable verification step and evidence it has actually caught something.
  2. Explain why compaction is riskier than trimming. Trimming changes structure: you know which field you removed and you can fetch it back. Compaction changes language: what got dropped is the model's choice, and nothing marks the loss.
  3. Name the fragile categories. First, whatever is currently in flight in the last few turns, which loses its referent the moment it is folded. Second, hard requirements that do not look like conclusions, such as user-stated deadlines, emotional demands, or verbal commitments. Third, identifiers, which summaries happily rewrite from an order number into the relevant order.
  4. Conclusion: preset a list of facts that must remain findable after compaction and check them every time, rejecting the compaction or widening the verbatim window on failure. Support it with three measures: keep recent turns verbatim, give hard requirements their own section in the summary prompt, and demand verbatim preservation of identifiers.
  5. Expect the follow-up asking whether it ever caught you. A concrete case lands best: dropping the verbatim window from six turns to one raised the compression ratio from 68 to 87 percent but silently deleted a user's stated Friday deadline, because it lived only in recent turns and did not read like a conclusion.

  答题要点

  • 压缩比裁剪危险：裁剪动结构可回溯，压缩动语言且丢失无标识。
  • 最容易丢的三类：最近几轮正在进行的事、不像结论的硬性要求、标识符。
  • 验证机制：预置一组必须存活的关键事实，每次压完逐条核对，不通过就不采纳这次压缩。
  • 配套三招：保留最近若干轮原文、硬性要求在摘要里单独成段、要求逐字保留标识符。

  Key points

  • Compaction is riskier than trimming: structure is recoverable, language loss is silent.
  • Three fragile categories: what is in flight in recent turns, hard requirements that do not look like conclusions, and identifiers.
  • Verification: preset facts that must survive and check each one after every compaction, rejecting it on failure.
  • Support with a verbatim recent window, a dedicated section for hard requirements, and explicit verbatim preservation of identifiers.
• 子代理为什么只回传摘要而不回传全过程？主代理该怎么写交接要求？Why does a subagent return only a summary instead of its full transcript, and how should the lead agent specify the handoff?

  国内高频海外高频深入#subagents#handoff#cost

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

  1. 这题在考架构意图。答「为了省 token」只对了一半，而且是次要的那一半——子代理架构整体上是更贵的，不是更省的。
  2. 怎么拆：先说清目的。子代理隔离买的不是省钱，是主线上下文的干净。子代理可以在自己独立的窗口里烧掉几万 token 反复探索，主线只多了一两千 token 的浓缩结论，中间过程一个字都没进主线。这是关注点分离在上下文层面的落地。
  3. 把代价摆出来，这是最能体现做过工程的地方：Agent 类应用本来就比聊天多用约 4 倍 token，多 Agent 系统约 15 倍。所以适用面很窄——探索量大但产出能浓缩、子任务彼此独立可并行、主线确实不需要看中间过程，三条缺一就该退回压缩。
  4. 结论给交接契约：三段式（已定结论、待办事项、硬约束），且每条结论必须带来源标识（文件路径、订单号、URL）。原因是没有标识的结论不可复查，主线只能全盘相信或全盘重做；带标识之后主线可以只对存疑的那条做定点核实。硬约束那一段没有也要写「无」，不能省略，否则主线分不清是没有还是忘了写。
  5. 可预期的追问：主代理自己的计划怎么办？也该写到窗口外面。长任务后期一旦触发截断或压缩，最先丢的往往就是最初那份计划，而它恰恰最不该丢。

  How to reason about it · think before answering

  1. This tests architectural intent. Saying it saves tokens is only half right, and the lesser half: multi-agent setups are more expensive overall, not cheaper.
  2. State the purpose. Subagent isolation buys a clean main context, not a smaller bill. A subagent can burn tens of thousands of tokens exploring in its own window while the main thread gains only a condensed result of one or two thousand tokens. It is separation of concerns applied to context.
  3. Put the cost on the table, which is where engineering experience shows: agentic applications use roughly four times the tokens of chat, and multi-agent systems roughly fifteen times. So the fit is narrow: heavy exploration with a condensable result, independent parallelizable subtasks, and a main thread that genuinely does not need the intermediate steps. Missing any one, fall back to compaction.
  4. Conclusion: specify a handoff contract of three sections (settled conclusions, open items, hard constraints), with every conclusion carrying a source identifier such as a file path, order id, or URL. Without identifiers the main thread can only trust everything or redo everything; with them it can spot-check the one claim it doubts. Require the constraints section even when empty, or the main thread cannot tell absent from forgotten.
  5. Expect the follow-up about the lead agent's own plan: write it outside the window too, since truncation or compaction late in a long task tends to eat the original plan first.

  答题要点

  • 隔离买的是主线上下文的干净，不是省钱；多 Agent 整体更贵。
  • 代价数量级：Agent 约为聊天的 4 倍 token，多 Agent 约 15 倍。
  • 适用三条：探索量大且产出可浓缩、子任务独立可并行、主线不需要中间过程；缺一就退回压缩。
  • 交接契约三段式，每条结论必须带来源标识，硬约束段即使为空也要显式写「无」。
  • 主代理自己的计划也要写到窗口外，长任务里它最容易被截断或压缩吃掉。

  Key points

  • Isolation buys a clean main context, not savings; multi-agent is more expensive overall.
  • Magnitudes: agents use about four times chat tokens, multi-agent about fifteen times.
  • Fits when exploration is heavy but condensable, subtasks are independent and parallel, and the main thread does not need intermediate steps.
  • Handoff contract in three sections, every conclusion carrying a source identifier, and an explicit none when constraints are empty.
  • Persist the lead agent's plan outside the window, since it is the first casualty of truncation late in long tasks.

D5 度量与调优：token 账单、上下文利用率、失败模式排查与综合面试专题

• 怎么给一个 Agent 算一次任务的 token 账单？哪些部分是可以被缓存掉的？How do you compute the token bill for one agent task, and which parts can be cached away?

  国内高频海外高频深入#token-accounting#prompt-caching

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

  1. 这题的第一个坑在「一次任务」四个字。很多人报的是单次请求的输入量，那是称重不是账单——模型没有记忆，每一轮都要把前面全部重发，账单是整场会话每轮输入的累加值。
  2. 怎么拆：按四块各自的增长方式分别求和。稳定前缀（系统提示加工具定义）每轮原样重发，乘轮数；对话历史线性增长，是等差数列求和；工具结果阶梯增长，按调用次数与每次体积估。举个量级：一个 20 轮的客服任务，最后一轮单次输入 11256，整场累加是 133502，差了将近 12 倍。
  3. 再谈缓存。可缓存的是稳定前缀这一段，顺序是工具定义、系统提示、消息，改前面的会让后面全部失效。经济学是写入约 1.25 倍原价（一小时存活期约 2 倍）、命中约 0.1 倍，所以 20 轮的前缀从 20 次全价变成一次写入加十九次命中，能便宜八成以上。
  4. 结论要带上那条门槛：前缀必须达到模型的最小可缓存长度才生效，达不到既不报错也不告警。这直接导致一个反直觉现象——把系统提示精简掉一半，token 数降了，账单反而可能涨，因为前缀掉到门槛以下、缓存静默失效。
  5. 可预期的追问：那还该不该精简？该，但要同时报两个数——不含缓存的 token 降幅与含缓存的等效开销降幅，并检查前缀有没有跨过门槛。跨过了就把稳定的引用内容放回前缀抬回去，或者换一个门槛更低的模型。

  How to reason about it · think before answering

  1. The first trap is the phrase one task. Many people quote a single request's input size, which is a weight reading, not a bill. Stateless models resend everything each turn, so the bill is the sum of every turn's input.
  2. Sum the four buckets by their growth patterns. The stable prefix (system prompt plus tool definitions) is resent verbatim, so multiply by turn count. History grows linearly, so it is an arithmetic series. Tool results grow in steps, so estimate calls times size. For scale: a twenty-turn support task whose final request is 11256 tokens totals 133502 across the session, nearly twelve times larger.
  3. Then caching. The cacheable part is the stable prefix, ordered tools, system, messages, where editing anything earlier invalidates everything after. Writes cost about 1.25 times base (about 2 times for a one-hour lifetime) and hits about 0.1 times, so twenty full-price prefixes become one write plus nineteen hits, an eighty percent saving.
  4. State the threshold: the prefix must reach the model's minimum cacheable length or caching silently does nothing. That produces the counterintuitive result where halving your system prompt lowers token count but raises the bill, because the prefix fell below the threshold.
  5. Expect the follow-up on whether to trim anyway. Yes, but report two numbers: the raw token reduction and the cache-adjusted effective reduction, and check whether the prefix crossed the threshold. If it did, add stable reference content back into the prefix or move to a model with a lower threshold.

  答题要点

  • 账单是整场会话每轮输入的累加值，不是最后一次请求的输入量。
  • 按四块的增长方式分别求和：前缀乘轮数、历史等差求和、工具结果按调用次数估。
  • 可缓存的是稳定前缀，顺序是工具定义、系统提示、消息，改前面会让后面全失效。
  • 写入约 1.25 倍、命中约 0.1 倍；但前缀必须达到最小可缓存长度，否则静默失效。
  • 所以精简可能让 token 降而账单涨，必须同时报含缓存与不含缓存两个口径。

  Key points

  • The bill is the sum of every turn's input across the session, not the last request's size.
  • Sum by growth pattern: prefix times turns, history as an arithmetic series, tool results by call count.
  • The cacheable part is the stable prefix ordered tools, system, messages; editing earlier segments invalidates later ones.
  • Writes cost about 1.25 times base and hits about 0.1 times, but only above the model's minimum cacheable length, which fails silently.
  • So trimming can lower tokens while raising cost; always report both cached and uncached figures.