Interview Bank

Context Engineering in 5 Days

D1 Context Is the Scarcest Resource: the Window, Attention Decay, and Cost — From Prompt Engineering to Context Engineering

• What actually goes into the context of a single agent request, and which part is most likely to blow up?一次 Agent 请求的上下文里都有什么？哪一块最容易失控，为什么？

  Common in ChinaCommon overseasBasic#context-window#token-budget

  How to reason about it · think before answering

  1. This question separates people who have measured from people who have read. Naming the four parts is easy; describing how each one grows is where the signal is.
  2. Classify the four by growth pattern: system prompt and tool definitions are resent verbatim every turn at roughly constant size; conversation history grows linearly by tens of tokens per turn; tool results grow in steps, often thousands of tokens per call.
  3. Conclusion: tool results are the most likely to blow up, because a single increment is one to two orders of magnitude larger than the others and its size is decided by an external system you do not control. Tool definitions come second since they scale with a tool count that only ever goes up.
  4. Add the subtlety: tool results live inside user-role messages but they are data, not dialogue. Bucketing by message role folds them into history and ruins the breakdown, so bucket by content block type instead.
  5. Expect the follow-up: what numbers did you actually see? A concrete figure lands best, for example tool results at 72.9 percent of a customer-support session while most people had guessed history.

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

  1. 这题在考你有没有真的量过。能背出「系统提示、工具定义、历史、工具结果」四块的人很多，能说出各自增长方式的人很少，区分度全在后半句。
  2. 怎么拆：按「每一轮会怎么变」给四块归类。系统提示和工具定义是每轮原样重发、长度基本不变；对话历史是线性增长，每轮加几十个 token；工具结果是阶梯增长，一次调用就能加两千。
  3. 结论：最容易失控的是工具结果，因为它的单次增量比其它三块大一到两个数量级，而且完全由外部系统决定，你写代码的时候看不到它会有多大。工具定义排第二，它随工具数量线性增长，而工具是最容易被顺手加上去的东西。
  4. 补一个容易被忽略的点：工具结果虽然写在 user 角色的消息里，但它是数据不是对话。按消息角色统计会把它算进历史，那张表就废了——要按内容块的类型拆。
  5. 可预期的追问：那你实际量出来是多少？给一个具体数字最有说服力，比如一次电商客服会话里工具结果占 72.9%，而大多数人事先都猜的是对话历史。

  Key points

  • Four parts: system prompt, tool definitions, conversation history, tool results.
  • Group them by growth: the first two are resent every turn at near-constant size, history grows linearly, tool results grow in steps.
  • Tool results blow up first because a single call can add thousands of tokens and its size is set externally; tool definitions are second, scaling with tool count.
  • Bucket by content block type, not by message role, or tool results get miscounted as history.

  答题要点

  • 四块：系统提示、工具定义、对话历史、工具结果。
  • 按增长方式分：前两块每轮重发且基本恒定，历史线性增长，工具结果阶梯增长。
  • 最容易失控的是工具结果，单次增量最大且由外部系统决定；其次是工具定义，随工具数量增长。
  • 统计时要按内容块类型拆，不能按消息角色拆，否则工具结果会被算进对话历史。

D2 System Prompts and the Instruction Hierarchy: the Right Altitude, Persistent Instruction Files, Progressive Disclosure, Less Is More

• How do system prompts keep growing, and how would you stop it?系统提示越写越长是怎么发生的？你会怎么止住这个过程？

  Common in ChinaCommon overseasBasic#prompt-bloat#maintenance

  How to reason about it · think before answering

  1. It sounds like a complaint prompt but it tests process thinking. Many can name the cause; few offer a mechanism that actually stops the growth.
  2. The cause is a one-way ratchet. Every production incident is fastest to patch by appending a sentence to the system prompt. The person who added it knew why but did not write it down. Six months later nobody dares delete it, because if the incident recurs the blame lands on whoever deleted it.
  3. Name the subtle layer too: many rules exist to work around a specific model generation's quirks. After a model upgrade they are useless yet still consume input budget every turn, and nothing signals that they expired.
  4. Give three mechanisms. Record the failing case beside each rule when adding it. Start minimal and add rules only for observed failures rather than writing everything imaginable before launch. Periodically re-audit rule by rule using the can-you-write-an-assertion test, and re-run that audit after every model upgrade.
  5. Expect the follow-up: how do you de-risk deletion? Turn each rule's originating failure into a regression case and run it before deleting. A rule with no supporting case never earned its place.

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

  1. 这题看着像吐槽题，其实在考流程意识。能答出成因的人不少，能给出一条可执行的止损机制的人很少。
  2. 怎么拆：先讲成因，它是一条单向棘轮。每次线上出问题，最快的止血手段就是往系统提示里加一句；加的人当时知道为什么加，但没写下来；半年后没人敢删，因为删了万一那个事故重来一次，责任在删的人身上。于是只进不出。
  3. 再指出成因里最隐蔽的一层：很多规则是为了绕过某一代模型的具体毛病写的。模型换代之后它们不但没用，还在继续消耗每一轮的输入预算，而且没有任何信号提示你它们已经过期。
  4. 结论给三条机制：一是加规则时强制记录它对应的失败案例，这是将来敢删的唯一依据；二是最小起步——先用最少的规则跑一批真实用例，按观察到的失败逐条加，而不是上线前把能想到的都写上；三是定期做一次逐条判定，用「能不能写出断言」当尺子，并在换模型之后重跑一次。
  5. 可预期的追问：删规则的风险怎么控？答：把每条规则对应的失败案例沉淀成回归用例，删之前先跑一遍。没有用例支撑的规则，本来就没有资格待在那里。

  Key points

  • The cause is a ratchet: incidents are patched by appending a line, the reason is never recorded, and nobody dares delete it later.
  • Subtle layer: many rules work around one model generation's quirks and silently expire after an upgrade.
  • Three fixes: record the originating failure with each rule, start minimal and add only for observed failures, and re-audit periodically with the assertion test.
  • Control deletion risk with regression cases derived from each rule's originating failure.

  答题要点

  • 成因是单向棘轮：出事就加一句，加的理由没记录，之后没人敢删。
  • 隐蔽的一层：很多规则是为绕过某代模型的毛病写的，换代后过期却没有任何信号。
  • 止损三招：加规则时记录对应失败案例、最小起步按失败驱动增加、定期用断言尺子逐条重判。
  • 删除风险靠回归用例控制：每条规则对应的失败案例应沉淀成用例，删前先跑。