面试题库

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

D2 工具调用原理：JSON Schema、tool_use 循环；不用框架手写 Agent Loop

• 怎么防止 Agent 循环停不下来？只加一个最大步数够吗？How do you keep an agent loop from running forever — is a max-step counter enough?

  国内高频海外高频深入#agent-loop#reliability#cost

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

  1. 后半句是明摆着的陷阱。只答「加一个计数器」是及格线，面试官真正想听的是你知道计数器拦不住什么。
  2. 先解释它为什么会停不下来：停止原因一直是 tool_calls，通常是因为工具返回的东西没帮模型前进——结果为空、字段答非所问、错误文案没说清该怎么改，于是它换个参数一试再试。所以第一层其实不是护栏，是把工具的返回值和错误文案写得有信息量。
  3. 再给硬护栏，三条互补：步数上限最直接；token 与成本预算拦的是「步数不多但每步都很贵」；单轮的墙上时钟超时拦的是「一步就卡了两分钟」。只有步数上限的系统，照样会被一次超长上下文的调用打爆预算。
  4. 语义层面再加一条：检测重复调用。同一个工具、同一份参数连续出现两次以上，几乎可以断定它在原地打转，直接截断并把「你已经用完全相同的参数调过这个工具了，换个思路或者告诉用户你做不到」回传给模型，往往比等步数耗尽更快收敛。
  5. 触顶之后必须有交代：不能静默返回空字符串，要给用户一句能理解的话；同时把触顶记成一个指标，触顶率上升通常意味着某个工具的描述或返回值该改了，而不是把上限调大。
  6. 可以预期的追问：上限设多少？没有普适值。聊天类任务 5 到 10 步通常够，需要多轮检索的任务可以更高。正确做法是看线上的步数分布，取 p99 再留一点余量，而不是拍脑袋——上限设得越死，你的系统就越靠近固定流程那一端，越不像一个 Agent。

  How to reason about it · think before answering

  1. The second half is an open trap. 'Add a counter' is the passing grade; what they want is whether you know what a counter cannot catch.
  2. Explain why it runs away first: the finish reason stays tool_calls because the tool results are not moving the model forward — empty results, fields that do not answer the question, error text that never says what correct looks like. So the first line of defense is not a guard rail at all; it is writing tool results and error messages that carry information.
  3. Then three complementary hard limits: a step cap is the obvious one; a token and cost budget catches 'few steps, all of them expensive'; a per-step wall-clock timeout catches 'one call hung for two minutes'. A system with only a step cap can still blow its budget on a single enormous context.
  4. Add a semantic guard: detect repeats. The same tool with identical arguments twice in a row is almost always spinning. Cut it short and tell the model so — 'you already called this tool with exactly these arguments' — which usually converges faster than waiting for the counter to run out.
  5. Hitting the cap needs an honest ending: never return an empty string, give the user a sentence they can act on, and record cap hits as a metric. A rising cap-hit rate usually means a tool's description or return value needs fixing, not that the cap should be raised.
  6. Expect: what number do you pick? There is no universal one. Chat-style tasks usually fit in five to ten steps; retrieval-heavy tasks need more. Read the production distribution, take p99 plus headroom, and remember that the tighter the cap, the closer your system sits to a fixed workflow rather than an agent.

  答题要点

  • 根因通常是工具返回值或错误文案没信息量，模型无法前进只能反复重试，先把这层写好
  • 三条硬护栏互补：最大步数、token 与成本预算、单步墙上时钟超时，只有步数上限并不够
  • 语义护栏：同一工具加同一份参数连续重复调用即判定原地打转，截断并把这个事实回传给模型
  • 触顶要给用户一句交代，不能静默返回空；同时把触顶率当指标，上升说明工具该改而不是把上限调大
  • 上限值按线上步数分布取 p99 加余量；上限越死越接近固定流程，越不像 Agent

  Key points

  • The root cause is usually uninformative tool results or error text, so fix that layer before adding guards
  • Three complementary hard limits: max steps, a token and cost budget, and a per-step wall-clock timeout
  • Add a semantic guard: identical tool plus identical arguments twice in a row means it is spinning — cut it and tell the model
  • Give the user an honest message when the cap is hit, and track the cap-hit rate as a signal that a tool needs fixing
  • Size the cap from the production step distribution, not intuition; a tighter cap makes the system a workflow rather than an agent

D4 模型接入与系统提示词：多 provider 抽象与 fallback、覆盖默认人设（dg P03/P04/M04）

• 设计模型 fallback 策略时要权衡哪些因素？What trade-offs shape a model fallback strategy?

  国内高频海外高频进阶#model-routing#reliability#cost

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

  1. 题眼在「权衡」两个字——面试官不要你背一个 for 循环，他要看你知不知道 fallback 是有代价的。
  2. 先拆出第一个关键判断：不是所有错误都该 fallback，而分类的依据不是状态码的首位数字，是「换一家有没有可能变好」。400 请求体不合法、403 被安全策略拦截，换谁都一样，重试只是把同一个 bug 再犯一遍、白花两倍的钱和时间；408 超时、429 限流、5xx 服务端故障是对方的问题，换一家大概率能成。最容易答错的是 402 余额不足和 404 模型被下线或改名——它们同属 4xx、长得像「你的问题」，其实换一家完全可能成功；401 则要看凭证怎么管，三家共用一把网关 key 时换了也没用，各有各的 key 时 A 被吊销切到 B 完全能救。分类是 fallback 的第一步，不是重试。
  3. 再说成本：切换意味着同一段 prompt 你付了两次钱，三家链路最坏是三倍成本。这条一定要主动说出来，它区分了「写过」和「上过线」。
  4. 然后是延迟：串行 fallback 的总耗时是各家超时值的累加。如果每家给 15 秒、三家串下来用户要等 45 秒，那还不如早点失败。所以超时值必须按 provider 分别设，且要设总预算上限。
  5. 最后是雪崩，这是最容易被追问的点：主 provider 限流时你把全部流量瞬间压到备用上，很可能把备用也压垮。所以要加熔断——连续失败 N 次就暂时摘掉该 provider，过一段时间放少量流量试探。
  6. 可以预期的追问：怎么知道该摘多久？答案是指数退避 + 半开状态试探，和数据库连接池的熔断是同一套思路。

  How to reason about it · think before answering

  1. The word 'trade-offs' is the hinge: they are not asking for a for-loop, they want to know you understand fallback has costs.
  2. First key judgment: not every error deserves a fallback, and the test is not the leading digit of the status code but whether another provider could plausibly succeed. A 400 (malformed body) or 403 (blocked by safety policy) fails everywhere, so retrying repeats your own bug at double the cost and latency; a 408, 429 or 5xx is theirs and usually succeeds elsewhere. The two that people get wrong are 402 (out of credit) and 404 (model retired or renamed): both are 4xx, both look like your fault, and both are fixed by switching. A 401 depends on how credentials are managed — one shared gateway key fails everywhere, but per-provider keys mean a revoked key on A is survivable on B. Classification comes before retry.
  3. Cost: switching means paying for the same prompt twice, up to 3x across a three-provider chain. Volunteering this separates people who shipped from people who only read about it.
  4. Latency: serial fallback accumulates timeouts. Three providers at 15s each means a 45s wait — worse than failing fast. Timeouts must be per-provider with an overall budget.
  5. Thundering herd is the most common follow-up: when the primary rate-limits, shifting all traffic at once can take down the backup too. Hence circuit breaking — drop a provider after N consecutive failures, then probe with a trickle.
  6. Expect: how long do you drop it for? Exponential backoff with a half-open probe — the same pattern as database connection pool breakers.

  答题要点

  • 先分类再重试，判据是「换一家有没有可能变好」而不是状态码首位：400/403 不该切，408/429/5xx 该切，402 余额不足和 404 模型下线同样该切，401 取决于三家是否共用同一把凭证
  • 成本：每次 fallback 都要重付一遍 prompt 的钱，链路越长最坏成本越高
  • 延迟：串行 fallback 的耗时是各超时值累加，必须按 provider 分设超时并设总预算
  • 雪崩防护：主 provider 故障时全量流量压向备用会把备用也压垮，需要熔断 + 指数退避 + 半开试探

  Key points

  • Classify before retrying, judging by whether another provider could plausibly succeed rather than the leading digit: 400/403 must not fail over; 408/429/5xx should; so should 402 (out of credit) and 404 (model retired); 401 depends on whether the providers share one key
  • Cost: every fallback re-pays for the same prompt, so worst-case cost scales with chain length
  • Latency: serial fallback sums the timeouts, so set per-provider timeouts plus an overall budget
  • Thundering herd: shifting full traffic to the backup can topple it too — use circuit breaking with exponential backoff and half-open probes
• 如何在成本和延迟之间给不同任务选择合适的模型？How do you pick the right model per task, balancing cost against latency?

  国内高频海外高频进阶#model-routing#cost#latency

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

  1. 这题考的是「你有没有真的在花自己的钱」。答「用最好的模型」是最差的答案，答「按需选择」太空，要给出可执行的分档维度。
  2. 先建立核心事实：不同模型的价格能差 50 倍以上，而你的任务里很大一部分根本不需要最强的模型。用旗舰模型做意图识别，等于开跑车去楼下取快递。
  3. 然后给出三个可操作的路由维度：任务类型（分类抽取走便宜模型，长文推理走强模型）、延迟要求（前台用户在等就走低延迟，后台批处理可以慢而便宜）、输入长度（超长上下文只有部分模型支持且价格陡增）。
  4. 结论要落到数字上才有说服力：1 万轮对话每轮 2000 token，全走旗舰约 300 元一天；把六成粗活改走小模型后降到 125 元左右，一年省六万多，用户感知不到差别。
  5. 还要主动说出实现上的取舍：先按任务类型静态分档，不要一上来就做「让模型判断该用哪个模型」的动态路由——那个方案本身又要多一次模型调用，延迟和成本可能得不偿失，等有真实数据再优化。
  6. 可以预期的追问：怎么验证降档没有损失质量？答案是准备 golden set，对同一批输入跑两档模型，用人工或 LLM-as-judge 比对准确率，把降档决策建立在数据上而不是感觉上。

  How to reason about it · think before answering

  1. This question tests whether you have ever spent your own money. 'Use the best model' is the worst answer; 'it depends' is too vague — give actionable routing dimensions.
  2. Establish the core fact: model pricing spans 50x or more, and much of your workload does not need the strongest model. Using a flagship for intent detection is driving a sports car to fetch a parcel downstairs.
  3. Give three routing dimensions: task type (classification and extraction go cheap, long-form reasoning goes strong), latency requirement (foreground users need low latency, background batches can be slow and cheap), and input length (only some models handle very long context, and pricing rises steeply).
  4. Quantify it: 10k conversations a day at 2000 tokens each costs roughly 300 CNY/day on a flagship; routing the 60% of grunt work to a small model drops it to about 125 CNY/day, saving 60k+ CNY a year with no perceptible quality change.
  5. Volunteer the implementation trade-off: start with static tiers by task type. Dynamic routing that asks a model which model to use adds another model call, and the latency and cost may not pay for themselves — optimize once you have real data.
  6. Expect: how do you verify the cheaper tier did not hurt quality? A golden set — run both tiers over the same inputs and compare with human or LLM-as-judge scoring, so the decision rests on data rather than vibes.

  答题要点

  • 不同模型价格能差 50 倍以上，用旗舰模型做意图识别是明显的浪费
  • 三个路由维度：任务类型（分类抽取 vs 推理生成）、延迟要求（前台 vs 后台）、输入长度（是否需要超长上下文）
  • 实现上给调用层加 tier 参数，按任务静态分档挑起始 provider，fallback 逻辑完全复用
  • 先静态分档再考虑动态路由，让模型判断该用哪个模型本身要多一次调用，可能得不偿失
  • 用 golden set 对比两档模型的准确率，把降档决策建立在数据上

  Key points

  • Model pricing spans 50x or more, so a flagship doing intent detection is obvious waste
  • Three routing dimensions: task type, latency requirement, and input length
  • Add a tier parameter to the call layer, pick the starting provider statically, and reuse the fallback chain
  • Prefer static tiers first — dynamic model-picks-model routing adds a call and may not pay off
  • Validate downgrades against a golden set rather than intuition

D6 消息、上下文工程与压缩、会话存储/恢复/分叉（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?

  国内高频海外高频进阶#context-engineering#compression#cost

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

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

  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.

  答题要点

  • 阈值触发：历史占用到预算七成就压，因为摘要本身是一次会失败、有延迟的模型调用，必须留抢救余量
  • 压过程、留结论：丢中间推理和已消费的工具原始返回，保留系统提示词、最近若干条原文、用户明确声明的约束与事实
  • 切口必须对齐到一轮开头，切在 tool_calls 与 tool 结果之间会让下一次请求返回 400
  • 压缩是有损且不可逆的：原始历史另存一份只追加，发给模型的是压缩版，需要回溯或分叉时读原始版
  • 摘要用便宜的小模型；摘要失败要能降级成滑动窗口，别让压缩失败连累整轮对话

  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

D11 run 状态机、输出流回传、按 runId 保序、SSE 等待者、30s 打断合并

• 用户在 Agent 还没回复完的时候又发来一条消息，应该怎么处理？A user sends another message while the agent is still answering the previous one. How should the system handle it?

  国内高频海外高频进阶#interrupt-merge#state-machine#cost

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

  1. 这题看起来是产品题，其实考的是你有没有想过「并发两次执行」的后果。答「排队处理」或「直接取消上一条」都不算错，但都不完整——面试官想听的是判据和代价。
  2. 先说清不处理会怎样：两次执行同时往同一个会话里写输出，前端看到两段交错的文字；而且第一次执行是基于不完整的信息跑的，它的答案注定要被推翻。这两条后果一说，方案的方向就定了——要合并，不要并发。
  3. 然后给可执行的判据，三个条件全中才合并：同一个会话、上一次执行正处于 running 或 streaming、距它创建不到 30 秒。命中就把新消息追加进同一次执行的输入并标记为需要重跑，不新建；超窗或上一次已完成就正常新建。把 pending 排除掉是有意的——那段窗口只有几毫秒，排除后判据不必考虑「执行侧正好在这一刻读输入」的竞态。
  4. 两个实现细节最能体现动手过：一是「需要重跑」这个标记不要写进业务表，它只在本次执行期间有意义，写进表里进程崩在半路就留下脏标记、重启后无限重跑，放一个带过期时间的键上更合适；二是重跑时序号必须接着往上加、不能重置，否则重连的客户端按上次收到的号续，会续到一段已经作废的历史上。
  5. 主动算一笔账，把「为了省钱」这个错误理由挡回去：按输入 2000、输出 500 个 token 估，单次约 0.0006 美元；不合并是两次跑完约 0.0012 美元，合并是第一遍被掐在三分之一处约 0.0004 美元加第二遍 0.0006 美元约 0.0010 美元，只省 17%，一天一万次改口也就两美元。所以合并的理由是体验，不是成本。
  6. 可以预期的追问：30 秒怎么定的？答它是产品判断不是推导结果——用户改口通常在 5 到 15 秒之间，窗口太短合并不到、太长会把新问题误并成补充；关键是这个数只在一处定义、被判据与前端提示共同引用，不要在代码里散落三份。

  How to reason about it · think before answering

  1. It reads like a product question but tests whether you have thought through two concurrent runs. 'Queue it' or 'cancel the previous one' are not wrong, just incomplete — they want the criteria and the costs.
  2. Start with what happens if you ignore it: two runs write into the same conversation, so the UI shows two interleaved answers, and the first run was computed from incomplete input, so its answer is already wrong. Those two consequences point straight at merging rather than concurrency.
  3. Then give the actual test — all three must hold: same session, the previous run is running or streaming, and it was created less than 30 seconds ago. On a hit, append the new message to that run's input and flag it for a rerun instead of creating a new run; outside the window, or if the previous run finished, create a new one. Excluding pending is deliberate: that window lasts milliseconds, and excluding it keeps the rule free of races with the worker reading the input.
  4. Two implementation details show hands-on experience. First, the rerun flag does not belong in the business table — it is meaningful only during this execution, and persisting it means a crash mid-flight leaves a dirty flag that makes the run loop forever after restart; an expiring key is the right home. Second, on rerun the sequence must keep counting up rather than resetting, or a reconnecting client resuming from its last id lands in a history that has been invalidated.
  5. Volunteer the arithmetic to kill the 'saves money' answer: at roughly 2000 input and 500 output tokens, one answer costs about $0.0006. Not merging means two full runs, about $0.0012; merging means a first pass cut off a third of the way in (about $0.0004) plus a full second pass ($0.0006), about $0.0010 — a 17% saving, which is two dollars a day even at ten thousand corrections. Merging is a user-experience decision, not a cost optimization.
  6. Expect: where does 30 seconds come from? It is a product judgment, not a derivation — corrections usually arrive 5 to 15 seconds in, too short misses them and too long merges genuinely new questions into old ones. What matters is defining it once and referencing it from both the rule and the UI hint rather than scattering the constant.

  答题要点

  • 不合并的两个后果：两段输出交错写进同一个会话，且第一次执行基于不完整信息注定被推翻
  • 判据三条全中才合并：同一会话、上一次执行处于 running 或 streaming、距创建不到 30 秒；否则正常新建
  • 命中就把新消息追加进同一次执行的输入并标记需要重跑，标记放带过期时间的键上而不是业务表
  • 重跑时序号继续往上加、绝不重置，否则断线重连会续到作废的历史上
  • 合并省的钱有限（约 17%），真正的理由是不让两个回答同时对着用户说话

  Key points

  • Without merging you get two interleaved answers in one conversation, and the first was computed from incomplete input
  • Merge only when all three hold: same session, previous run running or streaming, created under 30 seconds ago; otherwise create a new run
  • On a merge, append to the same run's input and flag a rerun, keeping that flag in an expiring key rather than the business table
  • Sequence numbers keep counting on rerun and are never reset, or reconnects resume into an invalidated history
  • The cost saving is small (about 17%); the real reason is to avoid two answers talking over each other

D12 长期记忆：pgvector、embedding、chunking、memory_search 工具

• 为什么 Agent 需要额外的长期记忆，而不是把历史全部塞进上下文？Why does an agent need a separate long-term memory instead of stuffing all history into the context window?

  国内高频海外高频基础#long-term-memory#rag#cost

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

  1. 这题最容易答成「因为窗口装不下」。那只答对了一半，而且是不值钱的那一半——窗口一年比一年大，光靠这条理由，面试官会追问「等窗口到一百万 token 呢」，你就没词了。
  2. 先把两个问题拆开：上下文压缩解决的是「同一次会话里这一轮塞不下」，长期记忆解决的是「上个月说过的事想不起来」。前者在组装请求时做减法，后者做加法，触发时机、数据去向、失败后果都不同。能主动区分这两件事，是这题最大的区分度。
  3. 然后给成本账：200 条记忆、每条约 400 token 就是 8 万 token，按输入价 0.15 美元每百万 token 算，每一轮多付 0.012 美元；一天 20 轮就是 0.24 美元一个用户。只检索最相关的 5 条是 2000 token、每轮 0.0003 美元，差 40 倍。而且这笔钱是每轮重复付的，不是一次性的。
  4. 再给比钱更硬的理由：无关信息会降低命中率。200 条里跟这一轮相关的可能只有 1 条，剩下 199 条是噪声，模型会被带偏去回答一个用户没问的问题。**所以哪怕窗口无限大、token 免费，也该检索而不是全塞。** 这一句是这题的最优解。
  5. 落到做法上：把跨会话的用户事实与偏好抽成陈述句存进向量库，每轮按语义检索最相关的三五条注入请求——这就是 RAG 最小的一环。
  6. 可以预期的追问：什么信息该进长期记忆？答三问——跨会话之后还需要吗、会不会随时间失效、能不能靠检索捞回来。「用户住上海」三条都满足，「把刚才那段改成三句话」一条都不满足。

  How to reason about it · think before answering

  1. The tempting answer is 'the window is too small'. That is half right and it is the cheap half — windows keep growing, and the interviewer will ask what you would do at a million tokens.
  2. Separate the two problems first: context compression solves 'this turn does not fit in one session', long-term memory solves 'I cannot recall what was said last month'. One subtracts at request-assembly time, the other adds. Naming that distinction unprompted is where the signal is.
  3. Then quantify: 200 memories at roughly 400 tokens each is 80k tokens; at 0.15 USD per million input tokens that is 0.012 USD every single turn, about 0.24 USD per user per day at 20 turns. Retrieving the top 5 is 2k tokens, 0.0003 USD per turn — a 40x gap, and it repeats every turn.
  4. Give the reason that beats cost: irrelevant context lowers accuracy. If one of 200 memories is relevant, the other 199 are noise that pull the model toward answering something nobody asked. So even with an infinite free window, you would still retrieve rather than dump.
  5. Land on practice: distil cross-session user facts and preferences into standalone statements, store them as vectors, and inject the three to five most relevant per turn — the minimal form of RAG.
  6. Expect the follow-up: what belongs in long-term memory? Three tests — is it still needed across sessions, does it expire, can retrieval find it again. 'Lives in Shanghai' passes all three; 'shorten that paragraph' passes none.

  答题要点

  • 压缩管「这一轮塞不下」，长期记忆管「上个月说过的事想不起来」，是两个问题、两套机制
  • 全塞的成本是每轮重复付的：200 条约 8 万 token，每轮多 0.012 美元；检索 5 条只要 0.0003 美元
  • 更硬的理由是准确率：无关记忆是噪声，会把模型带偏，所以窗口再大也该检索而不是全塞
  • 做法是把跨会话的事实抽成陈述句、向量化存储，每轮按语义检索最相关的三五条注入
  • 判断一条信息该不该进长期记忆：跨会话还需要吗、会不会失效、能不能被检索到

  Key points

  • Compression handles 'this turn does not fit'; long-term memory handles 'what did they say last month' — different problems, different machinery
  • Dumping everything costs on every turn: 200 memories is about 80k tokens and 0.012 USD per turn versus 0.0003 USD for five retrieved ones
  • The stronger reason is accuracy — irrelevant memories are noise, so you would retrieve even with an infinite window
  • Practice: distil cross-session facts into statements, embed them, inject the top three to five per turn
  • Admission test for a memory: still needed across sessions, does not expire, and is findable by retrieval

D13 cron 调度（中心调度→stream 投递）+ 成本计量（token→USD 台账、usage report）

• 服务部署了多个实例，定时任务为什么不能让每个实例各自起一个 cron？你会怎么做？When a service runs multiple replicas, why not let each replica start its own cron? What would you do instead?

  国内高频海外高频基础#scheduling#distributed-systems#cost

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

  1. 题眼在「多个实例」四个字。只答「会重复执行」拿不到分，因为那是现象；面试官想看你能不能把现象换算成业务后果和钱。
  2. 先把重复的代价说具体：3 个副本各起 cron，同一个任务被执行 3 次，用户收到 3 份一样的推送，你付 3 份模型调用的钱。而且这个倍数会跟着副本数走——扩容到 10 个副本，账单和骚扰量一起变成十倍，却不会触发任何告警，因为从每个进程自己的视角看它只是老实地执行了一次。
  3. 然后给出正确的形状：把「谁该在什么时候被执行」收进一个中心调度器，它命中 cron 之后只做一件事——往消息总线投递一条任务消息；执行侧照旧靠消费组分摊，一条消息只会被一个消费者拿到。关键认知是「定时任务不是一种新的执行方式，只是把按按钮的人从用户换成了钟表」，所以执行侧一行代码都不用改。
  4. 接着主动补上「那调度器自己不就成单点了吗」——这是必被追问的一句。答案分两层：调度器无状态、崩了拉起来就行，短暂不可用的代价只是几分钟内的任务延迟；真要高可用就起两个实例，靠投递时的幂等键去重，而不是靠给调度器加分布式锁。
  5. 最后点一句选型：任务量不大时中心调度器加消息总线足够；量大或者任务本身有依赖关系时，业界会换成专门的调度框架（带任务依赖、重试策略、补数），但底层的「中心决定 + 队列分发」结构是一样的。
  6. 可以预期的追问：调度器崩溃 90 秒，中间跨过的那一分钟怎么办？答启动时回看最近 N 分钟逐分钟重放，因为有幂等键兜底，重复投递无害——这正是 at-least-once 加幂等这组搭配能成立的地方。

  How to reason about it · think before answering

  1. The hinge is the phrase multiple replicas. Saying it would run twice is only the symptom; the interviewer wants the business and dollar consequence.
  2. Make the cost concrete: three replicas each running cron means the job fires three times, users get three identical pushes, and you pay for three model calls. The multiplier tracks replica count, so scaling to ten makes both the bill and the spam tenfold, with no alert firing, because from each process's own point of view it ran exactly once.
  3. Give the right shape: move the decision of who runs when into one central scheduler whose only job, on a cron match, is to publish a task message onto the bus; the execution side keeps using a consumer group so one message reaches exactly one consumer. The key insight is that a scheduled task is not a new execution path, it just swaps the user for a clock as the thing pressing the button, so the worker code stays untouched.
  4. Volunteer the obvious follow-up: doesn't the scheduler become a single point of failure? Two layers. It is stateless, so a crash costs you a few minutes of task delay; if you truly need HA, run two instances and dedupe on the idempotency key at publish time rather than bolting a distributed lock onto the scheduler.
  5. Close with sizing: a central scheduler plus a bus is enough at modest volume. At high volume, or when tasks have dependencies, teams move to a dedicated workflow scheduler with dependency graphs, retry policy and backfill, but the underlying central-decision-plus-queue shape is identical.
  6. Expect: the scheduler was down for 90 seconds and skipped a minute — now what? Replay the last N minutes on startup, one minute at a time. The idempotency key makes redundant publishes harmless, which is exactly what makes at-least-once plus idempotency the easy combination.

  答题要点

  • 每个实例各自起 cron 等于同一个任务被执行 N 次：用户收到 N 份重复推送，模型调用花 N 倍的钱，倍数随副本数线性增长且不会触发告警
  • 正确形状是中心调度器命中 cron 后只往消息总线投递一条消息，执行侧靠消费组保证一条消息只被一个 Worker 拿到
  • 定时任务不是新的执行路径，只是把触发者从用户换成了钟表，所以 Worker 侧不需要任何改动
  • 调度器是无状态的，崩了拉起来即可；需要高可用就起两个实例靠投递时的幂等键去重，不要给它加分布式锁
  • 崩溃期间跨过的时间点靠启动时回看最近 N 分钟重放补上，幂等键保证重复投递无害

  Key points

  • Per-replica cron means the job runs N times: N duplicate pushes, N times the model spend, scaling linearly with replica count and silently
  • The right shape is a central scheduler that publishes one message to the bus on a cron match, with a consumer group ensuring exactly one worker picks it up
  • A scheduled task is not a new execution path — only the trigger changed from a user to a clock, so worker code is unchanged
  • The scheduler is stateless: restart on crash, and if you need HA run two and dedupe on the idempotency key rather than adding a distributed lock
  • Missed minutes are recovered by replaying the last N minutes at startup, which is safe because the idempotency key absorbs duplicates
• 让你从零设计一套 token 成本计量和台账系统，你会怎么做？How would you design a token cost metering and ledger system from scratch?

  国内高频海外高频进阶#cost#observability#data-modeling

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

  1. 这题在考「你有没有真的对过账」。区分度在两个地方：金额用什么类型存，以及金额是冗余存还是查询时现算。答不到这两点的方案，上线三个月就会被财务打回来。
  2. 先立判据：台账不是日志。日志是给排查问题用的，删了就删了；台账要拿去对账、要回答「这个月为什么涨了 40%」，所以每一笔钱都必须能追回到「谁、因为哪一次执行、用哪个模型、花了多少 token」。字段设计全部由这条判据推出来。
  3. 然后给字段和理由，一一对应：user_id 回答该算谁头上、run_id 回答属于哪次执行（允许为空，因为有系统级批量开销）、model 存调用当时那一个（fallback 会让同一段业务落到不同模型上）、kind 区分 chat 和 embedding（两者量级和增长曲线完全不同）、prompt_tokens 与 completion_tokens 分开存（输入输出单价差三到四倍，只存 total 就算不回金额，也看不出是提示词太长还是模型太啰嗦）。
  4. 接着是两个最能体现经验的判断。第一，金额用定点类型：数据库用 numeric，代码里用 Decimal 或 BigDecimal，绝不用双精度浮点累加，否则十万条之后总额和逐条相加对不上。第二，cost_usd 要在写入那一刻算好并冗余存，不要查询时用当前价格表现算——价格会变，历史账单不能跟着一起变，这是台账和报表最本质的区别。
  5. 还要主动说记账的时机和事务边界：记账放在「拿到 usage 字段」那一刻，而不是「业务成功」那一刻，因为失败的调用同样产生费用，尤其 fallback 会一次业务跨两三次收费调用。台账写入不必和业务同事务（丢一条只是几厘钱，锁住台账表却会卡住用户对话），可以异步加重试，用 run_id 加调用序号做唯一约束防重；但如果产品有额度限制，配额扣减必须同事务，否则用户能靠并发把额度刷穿。
  6. 可以预期的追问：厂商调价了历史数据怎么办？答案是价格表本身要有生效时间和版本号，台账里既存算好的金额也可以存价格版本，这样重算和审计都有依据。

  How to reason about it · think before answering

  1. This question tests whether you have ever reconciled a bill. The discriminators are the numeric type you store money in, and whether cost is stored or computed at query time. A design missing either gets rejected by finance within a quarter.
  2. Set the criterion first: a ledger is not a log. Logs exist for debugging and can be dropped; a ledger has to reconcile against the vendor invoice and answer why the bill grew 40% this month, so every charge must trace back to who, which run, which model, and how many tokens. Every field falls out of that.
  3. Then walk the fields with reasons: user_id says whose budget it hits; run_id says which execution it belongs to and is nullable because some spend is system-level batch work; model records the one actually used, since fallback routes the same workload to different providers; kind separates chat from embedding because their volumes and growth curves differ completely; prompt_tokens and completion_tokens are stored separately because input and output differ three- to four-fold in price, and a single total can neither reproduce the amount nor tell you whether the prompt is bloated or the model is verbose.
  4. Now the two judgments that show experience. First, money uses fixed-point: numeric in the database, Decimal or BigDecimal in code, never accumulated in binary floats, or the total will diverge from the sum of rows after a hundred thousand entries. Second, cost is computed at write time and stored redundantly, not recomputed from the current price table — prices change, and history must not change with them. That is the essential difference between a ledger and a report.
  5. Volunteer the timing and transaction boundary: record at the moment you receive the usage field, not at business success, because failed calls still cost money and a fallback spans two or three billable calls per business operation. Ledger writes need not share the business transaction — losing a row costs fractions of a cent, while locking the ledger table stalls user conversations — so write asynchronously with retries and a uniqueness constraint on run id plus call index. The exception is quota enforcement: if the product caps spend, the decrement must be transactional or concurrent requests will blow through the cap.
  6. Expect: what happens to history when the vendor changes prices? The price table itself needs effective dates and a version, and the ledger stores both the computed amount and the price version, so recomputation and audit both have a basis.

  答题要点

  • 台账不是日志：每一笔钱要能追回到谁、哪一次 run、哪个模型、多少 token，字段设计全由这条判据推出
  • prompt_tokens 与 completion_tokens 必须分开存，因为输入输出单价差三到四倍，只存 total 既算不回金额也看不出问题出在哪一侧
  • 金额用定点类型（数据库 numeric、代码 Decimal/BigDecimal），不要用浮点累加，否则总额和逐条相加对不上
  • cost_usd 在写入那一刻算好并冗余存，不要查询时按当前价格现算——价格会变，历史账单不能跟着变
  • 记账时机是拿到 usage 字段那一刻而不是业务成功那一刻，失败调用和 fallback 同样产生费用；台账可异步写入加重试，但配额扣减必须和业务同事务

  Key points

  • A ledger is not a log: every charge must trace to a user, a run, a model and a token count, and the schema follows from that
  • Store prompt and completion tokens separately, since input and output prices differ three- to four-fold and a single total can neither reproduce the amount nor localize the problem
  • Use fixed-point money (numeric in the database, Decimal or BigDecimal in code); float accumulation makes totals disagree with the sum of rows
  • Compute cost at write time and store it, rather than recomputing from today's price table, so history stays stable when prices change
  • Record at the moment usage is returned, not at business success — failed calls and fallbacks still cost money; ledger writes can be async with retries, but quota decrements must be transactional
• 一份 LLM 应用的 usage report 通常要覆盖哪些维度？这些维度分别用来做什么决策？Which dimensions should a usage report for an LLM product cover, and what decision does each one drive?

  国内高频海外高频进阶#observability#cost#reporting

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

  1. 这题最容易答成罗列维度：按用户、按天、按模型、按功能……列得越全越显得没想过。区分度在后半句——每个维度对应的是哪一类行动。列不出行动，说明你只做过报表没用过报表。
  2. 先给三个主维度和它们各自的行动类型：按用户切是商业动作（谁该涨价、谁在滥用、定价分层能不能覆盖成本）；按天切是排障动作（对齐发布时间线，找出是哪次上线让成本跳了台阶）；按模型和调用类型切是优化动作（验证分层路由有没有真省到钱、embedding 的量是不是失控了）。三个维度对应三个不同的看板受众。
  3. 然后升一层，指出绝对金额没有信息量，真正有用的是带分母的单位经济学指标：每次执行成本（当月总成本除以 run 数）、每用户月成本（除以活跃用户数）、每美元产出（完成的业务动作数除以总成本）。前两个用来判断定价能不能覆盖成本，第三个用来判断这套系统值不值得继续投入。
  4. 举一个能落地的用法证明你真用过：每次执行成本这个比值是把尺子。如果用户数没涨而单次成本涨了，几乎一定是某次上线让提示词变长了，或者某个工具的返回体膨胀了——这个信号通常比超时告警早好几天出现，所以成熟团队会把成本曲线和错误率、延迟并排挂在值班大盘上。
  5. 最后补一个大多数人会漏的维度：失败与降级。失败的调用照样收费，fallback 会让一次业务操作跨两三次收费调用。报表里不单独切出这一块，你和厂商账单的差额就会恰好集中在故障期，也就是最需要看清成本的时候。
  6. 可以预期的追问：报表要做到什么实时度？答案是分层——按天的汇总离线跑就够，但配额和预算护栏需要近实时的当月累计，通常用一张按用户按月的汇总表增量更新，而不是每次请求都扫一遍明细。

  How to reason about it · think before answering

  1. The trap is listing dimensions: by user, by day, by model, by feature. Length signals you have not thought about it. The discriminator is the second half — which action each dimension drives. No action means you built reports but never used one.
  2. Give three primary dimensions with their action type: by user is a commercial action (who to reprice, who is abusing, whether tiering covers cost); by day is a debugging action (align with the release timeline to find which deploy stepped the cost up); by model and call kind is an optimization action (did tiered routing actually save money, is embedding volume running away). Three dimensions, three different dashboard audiences.
  3. Then go up a level: absolute dollars carry no information. What matters are unit-economics ratios with a denominator — cost per run (monthly cost over run count), cost per active user per month, and business actions completed per dollar. The first two say whether pricing covers cost; the third says whether the system deserves further investment.
  4. Prove you have used it with a concrete pattern: cost per run is a ruler. If user count is flat but cost per run climbs, it is almost always a deploy that lengthened the prompt or a tool whose response body grew. That signal usually appears days before latency alerts, which is why mature teams put the cost curve next to error rate and latency on the on-call dashboard.
  5. Add the dimension most people miss: failures and fallbacks. Failed calls are still billed, and a fallback spans two or three billable calls per business operation. Without slicing that out, your gap against the vendor invoice concentrates exactly during incidents, when you most need cost clarity.
  6. Expect: how fresh does the report need to be? Tier it — daily rollups can run offline, but quota and budget guardrails need near-real-time month-to-date totals, usually from an incrementally updated per-user monthly summary table rather than scanning the detail rows on every request.

  答题要点

  • 按用户切是商业动作（定价分层、异常账号），按天切是排障动作（对齐发布找成本跳变），按模型和调用类型切是优化动作（验证分层路由、盯 embedding 用量）
  • 绝对金额没有信息量，要看带分母的指标：每次执行成本、每用户月成本、每美元产出
  • 每次执行成本是把尺子：用户数没涨而单次成本涨了，通常是提示词变长或工具返回体膨胀，比超时告警早好几天出现
  • 必须单独切出失败与降级的开销，否则和厂商账单的差额会集中在故障期
  • 实时度要分层：按天汇总可离线跑，预算护栏需要近实时的当月累计，用增量汇总表而不是每次扫明细

  Key points

  • By user drives commercial decisions, by day drives debugging, and by model or call kind drives optimization — three dimensions, three audiences
  • Absolute dollars say nothing; use ratios with a denominator: cost per run, cost per active user per month, and business actions per dollar
  • Cost per run is a ruler: flat users with rising per-run cost usually means a longer prompt or a bloated tool response, and it shows days before latency alerts
  • Slice out failed and fallback calls, or your gap against the vendor invoice concentrates during incidents
  • Tier the freshness: daily rollups offline, near-real-time month-to-date totals from an incremental summary table for budget guardrails

D14 部署运维：compose 多 worker、心跳、健康检查、优雅停机、dev/prod 隔离；W2 复盘

• 系统设计：请设计一个 IM Agent 平台——用户在即时通讯软件里和一个 AI 助手对话，助手能调用工具、记住长期偏好、还能定时主动推送。要求支撑十万日活。System design: design an IM agent platform where users chat with an AI assistant inside a messaging app. The assistant calls tools, remembers long-term preferences, and proactively pushes scheduled messages. Target 100k daily active users.

  国内高频海外高频深入#system-design#distributed-systems#cost#operations

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

  1. 先别画图。系统设计题最常见的死法是听完就开始画框，二十分钟后面试官发现你解的是另一道题。花三到五分钟问清四件事：一是流量形状（十万日活对应多少并发会话、峰谷比多少），二是延迟要求（首字节要多快，是否必须流式），三是工具的性质（只读查询还是有写操作和副作用），四是主动推送的合规边界（能不能在深夜推、每天上限几条）。这四个答案会实质改变架构，问它们本身就是分数。
  2. 然后给主干，一句话先定形状：**接入层无状态、消息总线解耦、Worker 有状态且按用户分片、状态全在数据库**。接着按数据流走一遍：IM 平台的 webhook 打到接入层，接入层只做鉴权、限流、落库、投递四件事，立刻返回 202；执行侧从总线取活、跑 Agent 循环、把输出片段回传；主动推送由一个中心调度器按时间投递进同一条总线。**关键论点是接入层耗时确定、执行层耗时不确定，把它们放在一个进程里意味着一次慢的模型调用会占住一个本该毫秒级返回的连接**——这是整道题的立论基础，要主动说出来。
  3. 再逐个模块给出选择和理由。存储：sessions / runs / messages 三张表，runs 单独存在是因为只有它能回答「这次到底跑完没有」，幂等靠 runs 上的唯一约束而不是先查后插。总线：Redis Streams 的消费组做分摊，语义是至少一次，恰好一次靠消费端幂等做出来；反复失败的消息投递三次后进死信流。顺序：消费组的分配单位是一条消息而业务要求的串行单位是一个用户，所以按 userId 哈希到固定数量分片，每个分片同一时刻只有一个 Worker 持有租约。记忆：pgvector 存 embedding，检索包成一个工具交给模型自己决定要不要查，且不给它身份参数——身份只能来自会话。
  4. 主动推送这一块要单独讲透，因为它是这道题区别于普通聊天服务的地方。中心调度器命中时间点后只投一条消息，执行侧照旧；幂等键锚在「计划触发的那一分钟」，所以调度器崩溃重启后回看重放不会重复推送。合规上要有时区、静默时段、每日上限三道闸，而且这三道闸必须在投递前判断而不是在推送时判断——否则你已经花了模型调用的钱才发现不该推。
  5. 然后主动给出容量和成本的数字感，这是高级候选人的分水岭。十万日活、人均十轮对话是一百万次模型调用；按输入输出各一千 token、每百万 token 输入 0.15 美元输出 0.60 美元估算，一天大约七百五十美元。这个数字立刻推出三件事必须做：token 用量要按调用记账并换算成美元（否则你无法定位是哪个用户或哪个功能在烧钱）、要有分层降级（超预算的用户切便宜模型而不是直接拒绝）、以及上下文长度是主要成本杠杆（所以要压缩历史、控制检索条数）。
  6. 最后收在可运维性上，也就是这一周的落点：多副本部署、心跳发现假死、就绪探针只查自己必需的依赖、优雅停机让发版不掐断对话、dev 与 prod 用键名前缀隔离。**每个机制都要配一句「它失效时会怎样」**——租约会脑裂所以要有自杀规则和护栏令牌、心跳会误判所以面板转红只告警不自动摘流量、停机会超时所以等待要有上限。说不出失效模式的机制，面试官会认为你只是读过。
  7. 可以预期的追问，按出现频率排：单点在哪（调度器无状态可重启，Redis 和 Postgres 靠托管服务的主备）；怎么灰度（新旧 Worker 同时在线，靠消息里的版本字段决定走哪套提示词）；用户在助手回复中途又发一句怎么办（三十秒内的改口合并进同一次执行，而不是并发开两个）；成本再降一半怎么做（缓存高频问答、压缩历史、把简单意图路由到小模型）。

  How to reason about it · think before answering

  1. Do not start drawing. The most common way to fail a design question is to hear the prompt and immediately sketch boxes, only for the interviewer to realise twenty minutes later that you solved a different problem. Spend three to five minutes on four questions: traffic shape (how many concurrent sessions does 100k DAU imply, and what is the peak-to-trough ratio), latency (how fast must first byte be, is streaming required), the nature of the tools (read-only lookups, or writes with side effects), and the compliance boundary on proactive pushes (may you push at night, what is the daily cap). All four change the architecture materially, so asking them is itself worth points.
  2. Then state the trunk in one sentence: stateless ingress, a message bus for decoupling, stateful workers sharded by user, all state in the database. Walk the data flow: the messaging platform's webhook hits ingress, which does only auth, rate limiting, persistence and publish, and returns 202 immediately; the execution side pulls work, runs the agent loop, and streams output fragments back; proactive pushes come from a central scheduler publishing onto the same bus. The load-bearing argument is that ingress latency is bounded while execution latency is not, so putting them in one process means one slow model call occupies a connection that should have returned in milliseconds — say this out loud, it is the premise of the whole answer.
  3. Then justify each module. Storage: sessions, runs and messages, with runs existing separately because only it can answer whether this attempt actually finished; idempotency comes from a unique constraint on runs, not from check-then-insert. Bus: Redis Streams consumer groups for fan-out, at-least-once semantics, with exactly-once manufactured by consumer-side idempotency, and messages that fail three times moved to a dead-letter stream. Ordering: the consumer group's unit of assignment is one message while the business requires serialisation per user, so hash userId into a fixed set of shards and let exactly one worker hold each shard's lease. Memory: embeddings in pgvector, retrieval wrapped as a tool the model chooses to call, with no identity parameter — identity only ever comes from the session.
  4. Treat proactive push as its own section, because it is what separates this from an ordinary chat service. The central scheduler publishes one message on a time match and the execution side is unchanged; the idempotency key is anchored to the scheduled minute, so replaying after a scheduler restart cannot double-send. For compliance you need timezone, quiet hours and a daily cap — and all three must be evaluated before publishing rather than at send time, or you have already paid for the model call before discovering you should not have pushed.
  5. Then volunteer capacity and cost numbers, which is what separates senior candidates. 100k DAU at ten turns each is a million model calls; at roughly a thousand tokens in and out, with input at $0.15 and output at $0.60 per million tokens, that is about $750 a day. That number immediately implies three requirements: meter token usage per call and convert to dollars (otherwise you cannot tell which user or feature is burning money), build tiered degradation (push over-budget users to a cheaper model rather than refusing them), and recognise that context length is the dominant cost lever (so compress history and cap retrieved items).
  6. Land on operability, which is this week's payoff: multiple replicas, heartbeats to surface zombies, readiness probes that only check their own hard dependencies, graceful shutdown so deploys do not cut conversations, and dev/prod isolation via key prefixes. Pair every mechanism with what happens when it fails — leases can split-brain so you need a self-fencing rule and fencing tokens, heartbeats produce false positives so a red dashboard alerts a human rather than auto-draining, shutdown can time out so the wait needs a ceiling. A mechanism without a stated failure mode reads as something you only read about.
  7. Expect, in rough order of frequency: where are the single points (the scheduler is stateless and restartable; Redis and Postgres rely on managed primary/replica); how do you roll out safely (old and new workers coexist and a version field in the message selects the prompt set); what if the user sends another message mid-reply (merge a change of mind within thirty seconds into the same execution rather than running two concurrently); and how would you halve the cost (cache frequent answers, compress history, route simple intents to a smaller model).

  答题要点

  • 先用三到五分钟问清四件事：流量形状、延迟要求、工具是否有副作用、主动推送的合规边界——它们会实质改变架构
  • 主干一句话：接入层无状态、消息总线解耦、Worker 有状态且按用户分片、状态全在数据库；立论是接入层耗时确定而执行层不确定
  • 存储 sessions / runs / messages 三张表，幂等靠 runs 上的唯一约束；总线用 Redis Streams 消费组，至少一次加消费端幂等，三次失败进死信
  • 顺序靠 userId 哈希分片加租约：消费组的分配单位是一条消息，而业务要求的串行单位是一个用户
  • 记忆用 pgvector 并包成工具交给模型自己决定是否检索，不给身份参数——身份只能来自会话
  • 主动推送由中心调度器投递，幂等键锚在计划触发的那一分钟；时区、静默时段、每日上限三道闸必须在投递前判断
  • 给出成本数字感：十万日活人均十轮约一百万次调用、一天约七百五十美元，由此推出计量记账、分层降级、压上下文三件事
  • 收在可运维性：多副本、心跳查假死、就绪探针只查自己的依赖、优雅停机、dev/prod 前缀隔离
  • 每个机制都配一句失效模式：租约会脑裂、心跳会误判、停机会超时——说不出失效模式等于只是读过

  Key points

  • Spend three to five minutes clarifying four things: traffic shape, latency targets, whether tools have side effects, and the compliance boundary on proactive pushes
  • State the trunk in one sentence: stateless ingress, bus for decoupling, stateful workers sharded by user, all state in the database — premised on bounded ingress latency versus unbounded execution latency
  • Storage is sessions/runs/messages with idempotency from a unique constraint on runs; the bus is Redis Streams consumer groups, at-least-once plus consumer idempotency, dead-lettering after three failures
  • Ordering comes from hashing userId into shards plus leases: the consumer group assigns per message while the business serialises per user
  • Memory is pgvector exposed as a tool the model may call, with no identity parameter — identity comes only from the session
  • Proactive push flows through a central scheduler with the idempotency key anchored to the scheduled minute; timezone, quiet hours and daily caps are enforced before publishing
  • Bring numbers: 100k DAU at ten turns is ~1M calls and ~$750/day, which implies metering, tiered degradation, and context length as the main cost lever
  • Land on operability: replicas, heartbeats for zombies, readiness probes scoped to own dependencies, graceful shutdown, dev/prod prefix isolation
  • Pair each mechanism with its failure mode — leases split-brain, heartbeats false-positive, shutdown times out; a mechanism without one reads as book knowledge

D15 多 Agent 模式全景（Router/Supervisor、Planner-Executor、Critic、Swarm、Blackboard）与何时不该用；LangGraph 入门

• 从单 Agent 升级到多 Agent，通常是被什么信号触发的？升级之后系统会多付出什么？What signals typically trigger the move from a single agent to a multi-agent system, and what does the upgrade cost you?

  国内高频海外高频进阶#multi-agent#cost#architecture

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

  1. 这题考的是「你是被业务逼着拆的，还是照着博客拆的」。答「业务变复杂了」等于没答，面试官要的是**可观测的信号**：什么现象出现时你才动手。
  2. 给五个按出现顺序排的信号：一是提示词开始互相打架（加一条规则，另一个指标就掉）；二是工具列表长到自己都要查文档；三是某一步的失败需要单独处理，不该整轮重来；四是想给某一步单独换模型；五是评估颗粒度不够，只能整体打分好或不好。
  3. 第四个信号要展开讲，它是唯一一个反常识的：多 Agent 通常更贵，但按步换模型是它唯一能省钱的场景——分诊这种短判断走便宜的小模型，拟方案走大模型。单 Agent 做不到按步换模型。这一条在面试里是明显的亮点。
  4. 然后主动给代价，不给代价的回答会被当成布道：延迟按步数乘倍数（原来两秒变六秒，而用户耐心大约三秒）；成本按调用次数线性涨，因为每一步都要把当前状态重新塞进上下文，典型是三倍；调试难度按状态维度涨，出错要同时回答路由对不对、每个子 Agent 拿到的状态对不对、合并有没有互相覆盖。
  5. 再补一句反向判断，证明你不是无脑拆：工具太多的第一反应应该是合并工具、收敛描述，拆 Agent 是第二反应；质量差的第一反应应该是把单 Agent 版本调到最好，那个版本还会成为多 Agent 的对照基线。
  6. 可以预期的追问：拆完怎么证明比原来好？答：留住单 Agent 版本当基线，用同一批标准样本集跑 A/B，比准确率也比每次对话的成本与延迟。说不出对照基线的人，通常也说不清自己为什么拆。

  How to reason about it · think before answering

  1. This question tests whether business pain forced the split or a blog post did. Answering the business got complex is a non-answer; the interviewer wants observable signals — what symptom made you act.
  2. Give five, in the order they usually appear: prompts start fighting each other (add one rule, another metric drops); the tool list grows until you need the docs yourself; one step's failure needs isolated handling instead of redoing the whole turn; you want a different model for one specific step; and evaluation granularity is too coarse to say more than good or bad.
  3. Expand on the fourth, the counter-intuitive one: multi-agent is usually more expensive, but per-step model selection is the one case where it saves money — a short triage decision on a cheap small model, a drafting step on a larger one. A single agent cannot swap models per step. This lands well in interviews.
  4. Then volunteer the costs, or the answer reads as evangelism: latency multiplies by step count (two seconds becomes six, while user patience is about three); cost grows linearly with calls because every step re-sends the current state as context, typically three times; and debugging cost grows with state dimensions, since a failure now requires checking routing, each sub-agent's input state, and whether merges overwrote each other.
  5. Add the reverse check to show you are not splitting reflexively: too many tools should first prompt consolidation and tighter descriptions, with splitting as the second response; poor quality should first prompt tuning the single-agent version to its best, which then becomes the baseline the multi-agent version is measured against.
  6. Expect: how do you prove the split helped? Keep the single-agent version as a baseline and A/B both against the same golden set, comparing accuracy alongside per-conversation cost and latency. People who cannot name a baseline usually cannot explain why they split either.

  答题要点

  • 五个可观测信号：提示词互相打架、工具多到要查文档、某一步需要独立重试、想按步换模型、评估颗粒度不够
  • 按步换模型是多 Agent 唯一能省钱的场景：短判断走小模型、拟方案走大模型，单 Agent 做不到
  • 代价一：延迟按步数乘倍数，两秒变六秒，而用户对客服机器人的耐心大约三秒
  • 代价二：成本线性涨，每一步都要把状态重新塞进上下文，典型是原来的三倍
  • 代价三：调试难度按状态维度涨，所以多 Agent 和链路追踪必须一起上
  • 反向判断：工具多先合并再拆分，质量差先把单 Agent 调到最好——那个版本还是多 Agent 的对照基线

  Key points

  • Five observable signals: prompts fighting each other, a tool list you must look up, one step needing isolated retries, wanting a different model per step, and evaluation too coarse to act on
  • Per-step model selection is the only case where multi-agent saves money: small model for triage, larger model for drafting — impossible in a single agent
  • Cost one: latency multiplies with step count, two seconds becomes six, while patience for a support bot is about three
  • Cost two: spend grows linearly with calls since every step re-sends state as context, typically three times the original
  • Cost three: debugging cost grows with state dimensions, so multi-agent and tracing have to ship together
  • Reverse check: consolidate tools before splitting, and tune the single agent to its best first — that version becomes your baseline

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

• checkpointer 在多 Agent 系统里解决了什么问题？它的代价是什么？What problem does a checkpointer solve in a multi-agent system, and what does it cost?

  国内高频海外高频进阶#checkpointing#cost#operations

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

  1. 这题的下半句才是考点。只答「能恢复、能容错」是功能介绍，任何文档都写着；面试官想听的是你有没有算过这笔账，以及知不知道它会在哪里疼。
  2. 先把价值说具体，用钱和时间说：一次带评审回路的多 Agent 执行要调九次模型，跑到第七次进程被换版本重启，没有检查点就是九次全废、用户界面还停在转圈。有检查点则从上一个签字点接着跑，已经跑完的节点一次都不重跑——它买的是「失败的粒度从一整次执行降到一个节点」。
  3. 顺带说清它解锁的另外三件事，这三样单靠重试做不到：**人工审批闸口**（在某个节点前停下等人点确认，状态就停在那儿）、**时间旅行调试**（回到出问题那一步之前看状态长什么样）、**分叉对比**（从同一个检查点跑两种走法，比较结果，这也是评估的基础设施）。
  4. 然后是代价，三笔要说全。第一笔，**状态越大写得越慢**，而且是每一步都写一份——一次请求写六个检查点，状态里多一个字节就要多写六遍。所以附件存引用不存内容，检索结果存文档 id 不存全文。
  5. 第二笔，**存储本身有上限**。用 jsonb 存的话，硬上限很远，但单行超过大约两 KB 就会被挪到外存、每次读写多一次 IO，所以真正的工程线是「别让单个检查点变成几百 KB」，而不是那个理论上限。
  6. 第三笔也是最容易被忽略的：**版本兼容**。检查点是长期存活的数据，你每改一次状态形状就欠下一笔迁移债，而缺字段读出来通常不报错，只是静默给出 undefined 或 NaN。这一条决定了状态字段要尽早占好位子——图状态的形状一旦被持久化，改字段就不是改代码，是数据迁移。
  7. 可以预期的追问：那检查点要不要清理？答要，按会话线设保留期与归档策略，否则这张表会随日活线性膨胀；另外要留意它是敏感数据——图状态里有完整对话，删除用户数据时这张表必须一起处理。

  How to reason about it · think before answering

  1. The second half is the real question. Answering it enables recovery and fault tolerance is a feature blurb any doc carries. The interviewer wants to know whether you have done the arithmetic and where it hurts.
  2. Make the value concrete in money and time: one multi-agent run with a review loop costs nine model calls. If the process is restarted for a deploy at call seven, without checkpoints all nine are wasted and the user is still watching a spinner. With them the run continues from the last signed-off point and no completed node re-runs. What you bought is a smaller unit of failure — a node instead of a whole run.
  3. Mention the three things it unlocks that retries alone cannot: human approval gates (pause before a node and the state simply waits), time-travel debugging (go back to just before the bad step and inspect state), and forking for comparison (run two variants from one checkpoint) — which is also the infrastructure evaluation is built on.
  4. Then the costs, all three. First, bigger state means slower writes, and it is written at every step: one request produces six checkpoints, so a byte added to state is six bytes written. Hence attachments hold references, not content, and retrieval results hold document ids, not full text.
  5. Second, the store has limits. With jsonb the hard cap is far away, but a row past roughly two kilobytes gets pushed to out-of-line storage and costs an extra IO on every read and write. The real engineering line is do not let a single checkpoint reach hundreds of kilobytes, not the theoretical cap.
  6. Third, the one people forget: version compatibility. Checkpoints are long-lived data, so every change to the state shape incurs migration debt, and missing fields usually do not throw — they silently yield undefined or NaN. This is why state fields should be reserved early: once a shape is persisted, changing a field is a data migration, not a code edit.
  7. Expect the follow-up: do checkpoints need cleanup? Yes — retention and archival per thread, or the table grows linearly with active users. Also treat it as sensitive data: graph state contains full conversations, so it must be included whenever you delete a user's data.

  答题要点

  • 核心价值：把失败的粒度从「一整次执行」降到「一个节点」，九次模型调用的执行不会因为一次重启全废
  • 还解锁三件重试做不到的事：人工审批闸口、时间旅行调试、从同一个检查点分叉对比（也是评估的基础设施）
  • 代价一，状态越大写得越慢，而且每一步都写一份——所以附件存引用、检索结果存文档 id
  • 代价二，存储有上限：jsonb 单行超过约两 KB 就外存、多一次 IO，工程线是别让单个检查点到几百 KB
  • 代价三，版本兼容：状态形状改一次就欠一笔迁移债，缺字段静默给出 undefined 或 NaN；所以字段要尽早占位
  • 运维上还要有保留期与归档，并把它当敏感数据处理——图状态里有完整对话，删用户数据时必须一起删

  Key points

  • Core value: it shrinks the unit of failure from a whole run to a single node, so a nine-call run is not wasted by one restart
  • It also unlocks three things retries cannot: human approval gates, time-travel debugging, and forking from one checkpoint to compare variants — the substrate evaluation is built on
  • Cost one: bigger state writes slower, and it is written at every step — hence references for attachments and document ids for retrieval results
  • Cost two: storage limits — a jsonb row past roughly two kilobytes goes out-of-line and costs an extra IO, so the practical line is keeping a checkpoint well under hundreds of kilobytes
  • Cost three: version compatibility — every change to the state shape is migration debt, and missing fields silently yield undefined or NaN, which is why fields should be reserved early
  • Operationally you need retention and archival, and you must treat it as sensitive data: graph state holds full conversations and must be purged with the user's data

D21 评估与可观测：golden set、LLM-as-judge、tracing、失败率/成本面板；Pi vs LangGraph 总结；W3 复盘

• 系统设计：一个多 Agent 客服平台已经上线，团队每周改几次提示词，但没人说得清质量是变好还是变差，成本也只有一个月底的总数。请为它设计一套评估与可观测体系。System design: a multi-agent support platform is live, the team edits prompts several times a week, nobody can say whether quality is improving, and cost is only known as a month-end total. Design its evaluation and observability system.

  国内高频海外高频深入#system-design#evaluation#observability#cost

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

  1. 先别画架构图。这道题的陷阱是它听起来像「搭一套监控」，于是很多人上来就报 Prometheus 加 Grafana——那答的是基础设施，不是这道题。花三到五分钟问清四件事：一是**改提示词的频率和发布方式**（每周几次、有没有灰度、能不能回滚）；二是**现在出问题是怎么发现的**（用户投诉？还是有人偶然看到？）；三是**有没有历史数据**（线上对话存了多久、能不能回放）；四是**谁来看这套东西**（工程师排障，还是老板看成本）。这四个答案会实质改变设计，问它们本身就是分数。
  2. 然后给主干，一句话定形状：**一份数据、两种读法。** 埋点只做一套（span），横着读是一次请求的调用树（排障用），竖着堆是面板（趋势和成本用）。**这条是地基**——两套数据来源迟早对不上，然后没有人相信任何一个。很多候选人在这里就分叉成「监控系统」和「评估系统」两套，那是后面所有麻烦的源头。
  3. 接着按三层展开。**第一层，离线回归**：建一个小而稳的 golden set（15 到 50 条），三层覆盖——每条路由都有人走、每种失败模式各一条（置信度不足落兜底、工具预算耗尽降级、下游挂掉）、以及历史上真出过事故的那几条。每条写清期望路由和必备信息清单。维护规矩是**只增不改**：改一条期望，历史分数全部作废。用 LLM-as-judge 对照清单打分，**judge 换一个模型、rubric 版本化并随每条记录存下来**。这一层挂在 CI 上，每次改提示词跑一遍，产出一个能和上次比的数字。
  4. **第二层，在线观测**：每次请求落一棵 span 树，必须记路由理由（模型做的决策，当时不记就永远丢了）、每个节点的 token 与耗时、以及降级和兜底事件。面板回答四个问题：错了多少、慢在哪、花了多少、**钱花在哪个角色身上**。最后一个是多 Agent 特有的，也最有用。
  5. **第三层，在线采样评估**：离线的 15 条覆盖不了真实流量分布，所以按比例采样线上请求（比如 1%）跑同一套 judge，得到一条真实质量曲线。**这一层是前两层的桥**：离线告诉你有没有改坏已知的东西，在线告诉你真实用户遇到了什么。
  6. 成本这块要给数字感，这是区分层级的地方。**多 Agent 一次用户请求可能产生 5 到 10 次模型调用**，所以「每次调用多少钱」比真实单价小一个数量级，**必须按请求算钱**。给个算式：日活一万、人均三次会话、每次 5 次调用就是 15 万次调用；按输入 2000 输出 500 token、$0.15/$0.60 每百万算，一天约 90 美元。这个数立刻推出两件事：按节点分摊能定位省钱的地方，以及**评估本身的成本要单独记**——judge 调用和被评估系统一个量级，它决定你每次提交都跑还是每天跑一次。
  7. 最后收在「怎么让它真的被用起来」，这是很多人漏的一层：把评估结果接进发布流程（通过率跌破阈值就挡住发布）、把 rubric 和 golden set 放进代码仓库走 code review、以及**给每个机制配一句失效模式**——judge 会偏向同源模型、golden set 会被针对性优化（有人为了让它绿而调提示词，那一刻它就失去了意义）、采样会漏掉长尾。说不出失效模式的方案，面试官会认为你只是读过。
  8. 可以预期的追问，按频率排：judge 用什么模型（比被评估的强一档，且必须异源）；golden set 从哪来（先从线上捞一批人工标注，再逐次把事故补进去）；这套东西自己出问题怎么办（面板发现 rubric 混版直接拒绝聚合，而不是给一个没含义的平均分）；多久能上线（第二层一周、第一层两周、第三层一个月，因为它依赖前两层）。

  How to reason about it · think before answering

  1. Do not draw an architecture diagram yet. The trap is that this sounds like build monitoring, so many candidates open with Prometheus and Grafana — that answers infrastructure, not this question. Spend three to five minutes on four things: how often prompts change and how they ship (weekly cadence, canary, rollback); how problems surface today (user complaints, or someone happening to notice); what history exists (how long conversations are retained, whether they can be replayed); and who consumes this (engineers debugging, or an executive watching spend). All four materially change the design, so asking them scores.
  2. Then the trunk, in one sentence: one dataset, two readings. Instrument once, as spans; read across for a single request's call tree (debugging) and stack them for a dashboard (trends and cost). This is the foundation — two data sources will eventually disagree and then nobody trusts either. Many candidates fork here into a monitoring system and an evaluation system, which is the source of every later problem.
  3. Then three layers. Layer one, offline regression: a small stable golden set (15 to 50), covering three things — every route exercised, one item per failure mode (low-confidence fallback, tool budget exhaustion, downstream outage), and the cases behind real past incidents. Each item declares its expected route and a checklist of required facts. The maintenance rule is add, never edit: changing an expectation voids all historical scores. Score with an LLM-as-judge using a different model, and version the rubric, storing that version on every record. This layer runs in CI on every prompt change and emits a number comparable to last time.
  4. Layer two, online observability: every request writes a span tree recording the routing rationale (a model decision, lost forever if not captured), per-node tokens and latency, and degradation and fallback events. The dashboard answers four questions: how much is wrong, where it is slow, what it cost, and which role spent it — that last one is multi-agent specific and the most actionable.
  5. Layer three, online sampled evaluation: fifteen offline cases cannot cover the real traffic distribution, so sample a fraction of live requests (say 1%) through the same judge to get a true quality curve. This layer bridges the other two: offline tells you whether you broke something known, online tells you what real users encountered.
  6. Bring numbers on cost, which is what separates levels. A multi-agent request can produce five to ten model calls, so per-call price is an order of magnitude below the real unit cost and you must price per request. Give the arithmetic: 10k DAU at three sessions each and five calls per session is 150k calls a day; at 2000 input and 500 output tokens, $0.15 and $0.60 per million, that is roughly $90 a day. That number implies two things: per-node attribution shows where to optimise, and evaluation's own cost must be tracked separately, since judge calls are the same order as the system itself and decide whether you evaluate per commit or nightly.
  7. Close on adoption, which many candidates omit: wire evaluation into the release process (block a deploy when pass rate drops below threshold), keep the rubric and golden set in the repository under code review, and pair every mechanism with a failure mode — judges favour same-family models, golden sets get gamed (someone tunes prompts to make it green, and at that moment it is worthless), sampling misses the long tail. A proposal with no stated failure modes reads as book knowledge.
  8. Expect, by frequency: which model judges (one tier above the system under test, and necessarily a different family); where the golden set comes from (start with human-labelled production samples, then append every incident); what happens when this system itself misbehaves (the dashboard refuses to aggregate mixed rubric versions rather than emitting a meaningless average); and how long to build (layer two in a week, layer one in two, layer three in a month since it depends on both).

  答题要点

  • 先用三到五分钟问清四件事：改提示词的频率与发布方式、现在问题怎么被发现、有无历史数据可回放、这套东西给谁看
  • 主干是「一份数据、两种读法」：埋点只做一套 span，横着读是调用树、竖着堆是面板；两套数据源迟早对不上
  • 第一层离线回归：小而稳的 golden set，三层覆盖（每条路由、每种失败模式、历史事故），只增不改，挂 CI
  • 第二层在线观测：span 树记路由理由、每节点 token 与耗时、降级兜底事件；面板回答错了多少/慢在哪/花了多少/钱花在哪个角色
  • 第三层在线采样评估：按比例采样线上请求跑同一套 judge，补上离线覆盖不到的真实分布
  • 成本必须按请求算而非按调用：一次请求 5 到 10 次调用，给出日活一万约 90 美元一天的算式；评估自身成本单独记
  • 收在落地：通过率跌破阈值挡发布、rubric 与 golden set 进仓库走 review
  • 每个机制配失效模式：judge 偏向同源、golden set 会被针对性优化、采样漏长尾——说不出失效模式等于只是读过

  Key points

  • Spend three to five minutes clarifying four things: prompt change cadence and release process, how problems surface today, what replayable history exists, and who the audience is
  • The trunk is one dataset, two readings: instrument once as spans, read across for a call tree and stack for a dashboard; two sources will disagree
  • Layer one, offline regression: a small stable golden set covering every route, every failure mode and past incidents, add-never-edit, wired into CI
  • Layer two, online observability: span trees recording routing rationale, per-node tokens and latency, degradation events; the dashboard answers wrong/slow/cost/which-role
  • Layer three, sampled online evaluation through the same judge, covering the real distribution the offline set cannot
  • Price per request, not per call: five to ten calls per request, with arithmetic showing ~$90/day at 10k DAU; track evaluation's own cost separately
  • Close on adoption: block releases when pass rate drops, keep rubric and golden set in the repo under review
  • Pair every mechanism with a failure mode: judge self-preference, golden set gaming, sampling missing the tail — omitting these reads as book knowledge

D25 前端侧 Agent 体验：流式渲染、工具调用可视化、打断/重试、SSE hooks

• 用户点了「停止生成」，前端调用 AbortController.abort() 之后，后端在做什么？The user hits Stop and the frontend calls AbortController.abort(). What is the backend doing at that moment?

  国内高频海外高频深入#streaming#cancellation#cost

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

  1. 这题是本章题眼，也是一道**陷阱题**：题干里已经把「前端 abort 了」当成既成事实，等你顺着说「那就停了」。答「停了」的直接出局。
  2. 正确答案一句话：**后端什么都不知道，它还在跑。** 还在调模型、还在往库里写消息、还在按 token 计费。`abort` 只是让你这一端不再读了，它顶多让 TCP 连接断开，而后端是否感知得到连接断开、感知到之后做不做事，是另一回事。
  3. 怎么拆：把「谁知道这件事」画出来。用户知道 → 前端知道 → **中间断了** → 后端不知道。断掉的这一环必须用一个显式的请求补上：`POST /runs/:id/cancel`。所以打断是两步，不是一步。
  4. 给一个量化的对照最有说服力：同一段 70 个字的回复，在第 5 个字打断——两步打断的后端停在 5/70，只 abort 的后端照跑到 70/70。差 14 倍的 token，而且那 65 个字还会落进会话历史，下一轮当上下文重新发一遍，付第二遍钱。
  5. 生产视角的补充：cancel 收到之后**不要硬杀**，把 run 迁到 cancelled 状态、让当前这一步跑完再退出——硬杀会留下半写的消息和对不上的序号。而且 cancel 本身必须幂等，因为网络抖动时你会重试它。
  6. 可预期的追问：那能不能靠后端检测连接断开来自动停？可以做，而且应该做（作为兜底），但不能只靠它——反向代理和负载均衡常常会把连接维持一段时间，后端感知到断开可能已经是十几秒之后；而且用户点停止之后如果自动重连，连接根本没断。**兜底归兜底，显式 cancel 才是主路径。**

  How to reason about it · think before answering

  1. This is the core question of the chapter and a deliberate trap: the prompt states the abort as a given and waits for you to say 'so it stopped'. Saying that ends the conversation.
  2. The correct answer in one line: the backend knows nothing and is still running — still calling the model, still writing messages, still billing tokens. abort only stops your end from reading; at most it drops the TCP connection, and whether the backend notices, or acts on noticing, is a separate matter.
  3. Decompose by drawing who knows what: the user knows, the frontend knows, the chain breaks, the backend does not know. That broken link must be closed with an explicit request: POST /runs/:id/cancel. So stopping is two steps, not one.
  4. A quantified contrast lands best: on the same 70-character reply interrupted at character 5, the two-step version stops the backend at 5/70 while abort-only runs to 70/70. That is 14x the tokens, and those 65 characters also land in conversation history and get resent as context next turn, billing you twice.
  5. Production addendum: on cancel, do not hard-kill. Move the run to a cancelled state and let the current step finish, or you leave half-written messages and gaps in the sequence numbers. Also make cancel idempotent, because you will retry it when the network flakes.
  6. Expected follow-up: can the backend just detect the dropped connection and stop by itself? It can and should, as a safety net, but not as the only mechanism. Proxies and load balancers often hold connections open, so detection can lag by tens of seconds, and if the client auto-reconnects the connection never drops at all. The net is a net; the explicit cancel is the main path.

  答题要点

  • 后端完全不知情：还在调模型、还在写库、还在计费。abort 只让前端这一端停止读取。
  • 打断必须两步：abort（界面立刻响应）+ POST /runs/:id/cancel（后端真的停）。
  • 量化差别：同一段 70 字的回复在第 5 个字打断，两步是 5/70，只 abort 是 70/70。
  • 后端收到 cancel 不要硬杀，迁到 cancelled 状态让当前步跑完；cancel 必须幂等。
  • 靠后端检测连接断开只能当兜底：代理会维持连接、自动重连时连接根本没断。

  Key points

  • The backend has no idea: still calling the model, still writing, still billing. abort only stops your side reading.
  • Stopping is two steps: abort for instant UI response, plus POST /runs/:id/cancel to actually halt the run.
  • Quantified: interrupting the same 70-character reply at character 5 gives 5/70 with both steps versus 70/70 with abort alone.
  • On cancel, transition the run to cancelled and let the current step finish rather than hard-killing; make cancel idempotent.
  • Backend disconnect detection is only a safety net — proxies hold connections open and auto-reconnect means no disconnect at all.

D26 系统设计专题：Agent 平台 / 客服 Agent / 多租户 / 成本控制

• 一个 Agent 系统的模型成本失控了，你会从哪几个层面着手控制？每一层大概能省多少？An agent system's model spend is out of control. Which levers do you pull, in what order, and roughly how much does each save?

  国内高频海外高频进阶#system-design#cost#capacity-planning

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

  1. 这题最容易脱口而出的答案是「换个便宜模型」，也是最容易被追死的答案——面试官紧跟着就问「你怎么知道换了质量不掉」，答不出离线评估集和对比实验就露馅了。正确的第一句是「先看台账」：按用户、按天、按模型各切一刀，找出是哪一维在涨。先定位再动手，这是工程习惯。
  2. 第二步是把基准摆到桌上，没有基准的成本讨论全是废话。单轮 2000 输入加 500 输出，输入 2000 除以一百万乘 0.15 等于 0.0003 美元，输出 500 除以一百万乘 0.60 也等于 0.0003 美元，一轮约 0.0006 美元；日活 1 万、人均 5 轮就是 5 万轮，一天约 30 美元、一个月约 900 美元。
  3. 然后给五层，排序的依据是**你要付出的代价从小到大**，不是省钱多少：缓存与 prompt cache、模型分级路由、上下文压缩、步数与工具预算上限、限流与降级。这个顺序本身就是答案的一部分，因为它同时说明了你的落地顺序。
  4. 每层配一个从基准推出来的数字。缓存按一成半命中估，900 降到 765 左右。分级路由要诚实说清前提：它是唯一能改数量级的一层，但前提是你的基准用的是旗舰模型；基准已经是最便宜那档时这一层榨不出东西——主动说破这一条，比硬编一个省钱比例可信得多。上下文压缩把输入从 2000 压到 1200，单轮变成 0.00048 美元，一个月 720 美元，降两成。
  5. 第四层最容易被讲成「省钱」，其实它买的是**可预测**：给每个子任务设 5 次工具调用上限之后，单轮成本才有上界——调满 5 次、每次结果回灌 800 token，输入涨到 6000，单轮 0.0012 美元，正好是基准的两倍；没有上限时这个数字没有上界。这一层的正确说法是「我不是靠它省钱，我是靠它让账单可以被预测」。
  6. 第五层是限流与降级，代价最大所以放最后：900 美元摊到 1 万日活是每人每月 0.09 美元，给单用户设 1 美元硬顶，正常用户碰不到，挡的是脚本刷接口那种极端户。要点是超预算先降档再拒绝，而不是直接拒绝——它是五层里唯一用户能感觉到的一层。
  7. 可以预期的追问：这五层里哪一层最先做？答「第一层和第三层」，因为它们只改自己的代码、不动产品承诺、也不需要重新验证质量；而分级路由要配离线评估集，限流要配产品沟通，都不是当天能上的。

  How to reason about it · think before answering

  1. The reflex answer is 'switch to a cheaper model', and it is also the easiest one to get killed on: the follow-up is 'how do you know quality did not drop', and without an offline eval set and a comparison run you are exposed. The right opening is 'look at the ledger first' — slice by user, by day and by model to find which dimension is growing. Locate before you act.
  2. Second, put the baseline on the table, because cost talk without a baseline is noise. At 2000 input and 500 output tokens per turn, input is 2000 over a million times $0.15 which is $0.0003, output is 500 over a million times $0.60 which is also $0.0003, so about $0.0006 per turn. 10k daily actives at five turns is 50k turns, roughly $30 a day and $900 a month.
  3. Then give five layers ordered by the cost you pay, not by the savings: caching and prompt caching, tiered model routing, context compression, step and tool budget caps, rate limiting and degradation. The ordering is part of the answer, because it also communicates your rollout sequence.
  4. Attach a number derived from the baseline to each layer. Caching at a 15% hit rate takes $900 to roughly $765. For tiered routing, state the precondition honestly: it is the only layer that can change the order of magnitude, but only if your baseline runs a flagship model — if you already run the cheapest tier there is nothing left to squeeze. Saying that out loud is far more credible than inventing a savings percentage. Compression takes input from 2000 to 1200 tokens, so $0.00048 per turn, about $720 a month, a 20% cut.
  5. Layer four is usually mis-sold as savings; what it actually buys is predictability. With a cap of five tool calls per subtask, per-turn cost finally has a ceiling: five calls each feeding back 800 tokens pushes input to 6000, so $0.0012 per turn, exactly double the baseline — and with no cap there is no ceiling at all. The right phrasing is 'this does not save money, it makes the bill predictable'.
  6. Layer five is rate limiting and degradation, last because it costs the most: $900 across 10k daily actives is about $0.09 per user per month, so a $1 monthly hard cap is invisible to real users and only stops scripted abuse. The nuance is degrade before refusing — this is the only layer users can feel.
  7. Expect the follow-up: which layer first? Say layers one and three, because they only touch your own code, change no product promise, and need no quality re-validation, whereas tiered routing needs an eval set and rate limiting needs product buy-in.

  答题要点

  • 第一句不是「换便宜模型」，是「先看台账」：按用户、按天、按模型各切一刀定位是哪一维在涨
  • 先立基准：单轮约 0.0006 美元，日活 1 万人均 5 轮约每天 30 美元、每月 900 美元
  • 五层按代价从小到大：缓存与 prompt cache、模型分级路由、上下文压缩、步数与工具预算上限、限流与降级
  • 分级路由是唯一能改数量级的一层，但前提是基准用的是旗舰模型；基准已经最便宜时要诚实说没得省
  • 上下文压缩把输入从 2000 压到 1200，单轮 0.00048 美元、每月 720 美元，降两成
  • 工具预算上限买的是可预测：有上限时单轮上界是 0.0012 美元，没上限时没有上界
  • 限流降级放最后，因为它是唯一用户能感觉到的一层；超预算先降档再拒绝

  Key points

  • Open with 'look at the ledger', not 'use a cheaper model': slice by user, by day and by model to locate the growth
  • Set a baseline: about $0.0006 per turn, roughly $30/day and $900/month at 10k DAU and five turns
  • Five layers ordered by cost to you: caching and prompt cache, tiered routing, context compression, step and tool budget caps, rate limiting and degradation
  • Tiered routing is the only order-of-magnitude lever, but only if the baseline is a flagship model — say so when it is not
  • Compression from 2000 to 1200 input tokens gives $0.00048 per turn, about $720/month, a 20% cut
  • Tool budget caps buy predictability: with a cap the per-turn ceiling is $0.0012, without one there is no ceiling
  • Rate limiting comes last because users feel it; degrade before refusing

Claude 高效使用：从对话到 Claude Code

D2 长文档、多模态与 API 初见：大上下文怎么用、prompt caching 省钱、PDF 与图片输入、带引用回答；Messages API 最小调用

• 为什么说上下文窗口是 LLM 应用里最稀缺的资源？窗口已经有一百万 token 了，这个说法还成立吗？Why is the context window called the scarcest resource in LLM applications? With million-token windows, does that still hold?

  国内高频海外高频基础#context-window#cost

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

  1. 题眼在第二句。只答「窗口有上限」已经过时了，面试官想听的是「窗口变大之后为什么还稀缺」。
  2. 从三条因果链推：一、模型无状态，每次请求都把全部输入重读一遍，输入 token 按次计费——窗口大只解决了放得下，没解决每次都要重搬；二、上下文越长，延迟越高、注意力越稀释，模型对早期指令的遵守度会下降，也就是「性能随填充度下降」；三、Agent 场景里每读一个文件、每跑一条命令的输出都进同一个窗口，填得比聊天快得多。
  3. 结论：窗口大了，稀缺性从「放不下」变成了「每一 token 都在花钱和稀释注意力」，所以管理手段变成了主动管：只放必要的、把不变的缓存起来、把查资料的活派给独立上下文的子代理、该清就清。
  4. 生产视角：算一笔账——60 页 PDF 约 10 万 token，围着它问 10 个问题就是 100 万输入 token；不用缓存和不用缓存的差价是一个量级。
  5. 可预期的追问：那什么时候应该让上下文积累？在一个复杂问题里深挖时历史是有价值的；判据是「这段历史下一步还会不会用到」。

  How to reason about it · think before answering

  1. The second sentence is the point. 'The window has a limit' is a dated answer; explain why scarcity survives large windows.
  2. Three causal chains: models are stateless so every request re-reads the whole input and bills it, a big window only solves fitting, not re-sending; longer context means more latency and diluted attention, so adherence to early instructions degrades as the window fills; and in agent workflows every file read and command output lands in the same window, filling it far faster than chat does.
  3. Conclusion: scarcity shifted from 'won't fit' to 'every token costs money and attention', so the discipline becomes active management — include only what is needed, cache the stable prefix, delegate research to subagents with their own context, and clear between tasks.
  4. Production math: a 60-page PDF is roughly 100k tokens; ten questions about it are a million input tokens; caching versus not caching is an order of magnitude apart.
  5. Follow-up: when should context accumulate? While deep in one complex problem where the history is still load-bearing; the test is whether the next step will use it.

  答题要点

  • 模型无状态，每次请求重读全部输入并计费；窗口大只解决放得下，不解决每次重搬
  • 上下文越长延迟越高、注意力越稀释，早期指令遵守度下降
  • Agent 场景每次读文件、跑命令的输出都进窗口，填得比聊天快得多
  • 对策：只放必要的、缓存不变前缀、用子代理隔离查资料、任务之间清空

  Key points

  • Models are stateless: every request re-reads and bills the full input; a large window solves fitting, not re-sending
  • Longer context raises latency and dilutes attention; adherence to early instructions drops
  • Agent workflows dump every file read and command output into the same window
  • Tactics: include only what's needed, cache the stable prefix, isolate research in subagents, clear between tasks
• prompt caching 省在哪？什么情况下反而不省？线上发现缓存命中率是零，你怎么排查？Where does prompt caching save money, when does it cost more, and how do you debug a zero cache-hit rate in production?

  国内高频海外高频进阶#prompt-caching#cost

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

  1. 三问对应三层：原理、边界、排查。只答第一层是背文档，第三层才体现有没有真的上过线。
  2. 原理一句话：缓存匹配的是请求开头到 cache_control 标记为止的精确前缀（顺序是工具、system、messages），命中时这段只收正常输入价的 0.1 倍；代价是写入那一次收 1.25 倍（1 小时档 2 倍）。
  3. 不省的情况由此推出：同一前缀只用一次（多付 25%）；前缀里有每次都变的内容（时间戳、随机 id、未排序 JSON、用户名），导致每次都在写永远用不上的缓存；前缀短于最小门槛（主力模型 1024 token，Haiku 4.5 是 4096）根本不会缓存；两次请求间隔超过 TTL。
  4. 排查清单按发生概率排：一看 system 或工具定义开头有没有动态内容；二看两次请求的模型 id 是否一致；三看前缀长度是否过门槛；四看间隔是否超 5 分钟；五看工具列表顺序是否稳定。判据只有一个字段：usage.cache_read_input_tokens 是否大于 0。
  5. 可预期的追问：断点应该打在哪？不变的末尾——工具定义末尾、system 末尾、长文档末尾、多轮对话倒数第二条消息，最多四个；打在每轮都变的内容上等于白写。

  How to reason about it · think before answering

  1. Three questions, three layers: mechanism, boundaries, debugging. The third layer is what shows production experience.
  2. Mechanism: the cache matches the exact byte prefix from the start of the request to the cache_control marker (tools, then system, then messages). A hit bills that prefix at 0.1x input price; the write costs 1.25x (2x for the one-hour TTL).
  3. When it costs more: a prefix used only once (+25%); volatile content inside the prefix — timestamps, random ids, unsorted JSON, user names — so every call writes a cache nothing will read; a prefix below the minimum (1024 tokens on current flagship models, 4096 on Haiku 4.5) that silently never caches; requests spaced beyond the TTL.
  4. Debug order by likelihood: dynamic content at the head of system or tool definitions; model id mismatch between calls; prefix under the minimum; gap over five minutes; unstable tool ordering. The single signal is usage.cache_read_input_tokens greater than zero.
  5. Follow-up: where do breakpoints go? At the end of stable sections — tools, system, the long document, the second-to-last message in a multi-turn chat — at most four; a breakpoint on per-turn content is a wasted write.

  答题要点

  • 匹配精确前缀（工具 → system → messages 到标记为止）；命中 0.1 倍，写入 1.25 倍
  • 不省：前缀只用一次、前缀含动态内容、前缀短于最小门槛、间隔超过 TTL
  • 排查：动态内容、模型不一致、长度不够、间隔太久、工具顺序变了；看 cache_read_input_tokens
  • 断点打在不变部分的末尾，最多四个

  Key points

  • Matches the exact prefix (tools → system → messages up to the marker); hits bill 0.1x, writes 1.25x
  • Costs more when the prefix is used once, contains volatile content, is under the minimum length, or requests exceed the TTL
  • Debug: dynamic content, model mismatch, length, gap, tool ordering; verify via cache_read_input_tokens
  • Place breakpoints at the end of stable sections, at most four

5 天上下文工程

D1 上下文是最稀缺的资源：窗口、注意力衰减与成本，从提示词工程走到上下文工程

• 窗口越来越大了，为什么不能把所有可能有用的资料都塞进去？Context windows keep growing. Why not just put everything potentially relevant into the prompt?

  国内高频海外高频进阶#context-rot#attention-budget#cost

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

  1. 这题的题眼是「你知不知道窗口是容量、注意力是预算」。只回答「太贵了」的人会被判成没做过工程，因为成本是三笔账里最容易想到、也最不致命的一笔。
  2. 怎么拆：分成能力和代价两条线。能力这条线要点出上下文腐烂——随着上下文变长，模型准确回忆其中信息的能力会下降，根源在于 Transformer 里 n 个 token 有 n 平方级别的两两关系，注意力被摊薄；而且训练语料里长序列本来就少，处理长距离依赖的参数不够多。
  3. 关键是要强调它是一条缓坡不是一道悬崖：没有哪个长度会突然崩掉，每多塞一千个不相干的 token，正确率就低一点点。这个措辞能立刻区分读过一手材料的人。
  4. 代价这条线给三笔账：钱（模型无状态，每轮全量重发，总输入是累加值不是最后那次的值）、延迟（首字返回变慢）、正确率（无关内容稀释注意力）。第三笔最贵，因为它不会报错，只会给出看起来合理但违反了约束的回答。
  5. 可预期的追问：那你怎么判断某段内容该不该加？给一条可执行的判据——说不出它会改变模型哪一个具体决定，就不该加。

  How to reason about it · think before answering

  1. The hinge is whether you treat the window as capacity or attention as a budget. Answering only with cost reads as inexperience, since cost is the easiest and least dangerous of the three bills.
  2. Split into capability and cost. On capability, name context rot: recall accuracy degrades as context grows, rooted in the n-squared pairwise relationships a transformer maintains over n tokens, plus the fact that long-range parameters are underrepresented in training.
  3. Stress that this is a gradient, not a cliff. No specific length breaks; every thousand irrelevant tokens shaves a little accuracy. That phrasing distinguishes people who read primary sources.
  4. On cost, give three bills: money (the model is stateless, so every turn resends everything and the total is cumulative, not the last call), latency (slower time to first token), and accuracy (irrelevant content dilutes attention). The third is worst because it never raises an error, it just returns a plausible answer that violates a stated constraint.
  5. Expect the follow-up: how do you decide whether a given chunk earns its place? Give an operational test: if you cannot name the specific decision it changes, it does not go in.

  答题要点

  • 窗口是容量，注意力是预算；容量够不代表模型用得好。
  • 上下文腐烂：上下文越长，准确回忆的能力越差，是渐进的性能梯度而不是一道悬崖。
  • 三笔账：钱（每轮全量重发，成本是累加值）、延迟、正确率。
  • 正确率那一笔最危险，因为它不报错，只会给出看似合理却违反约束的回答。
  • 判据：说不出这段内容会改变哪一个具体决定，就不该放进去。

  Key points

  • The window is capacity; attention is the budget. Fitting is not the same as being used well.
  • Context rot: recall degrades as context grows, as a gradient rather than a hard cliff.
  • Three bills: money (stateless models resend everything each turn, so cost is cumulative), latency, and accuracy.
  • Accuracy is the dangerous one because it fails silently with plausible answers that break stated constraints.
  • Test: if you cannot name the specific decision a chunk changes, leave it out.

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

• 子代理为什么只回传摘要而不回传全过程？主代理该怎么写交接要求？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.

14 天 RAG：从检索到可信回答

D1 为什么要检索：幻觉、知识截止与长上下文的代价，以及一个纯关键词的最小 RAG

• 上下文窗口已经做到上百万 token 了，检索这一步会被淘汰吗？Context windows are now in the millions of tokens. Does that make the retrieval step obsolete?

  国内高频海外高频深入#long-context#cost#system-design

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

  1. 这是一道立场题，容易答成非黑即白。判断你有没有做过的地方在于：会不会区分「技术上能不能塞进去」和「工程上该不该每次都塞」，只谈前者的答案一听就是纸上谈兵。
  2. 先承认对方有道理的部分：窗口变大确实吃掉了检索的一部分场景。几十篇文档、更新不频繁、调用量不大的内部工具，直接全塞是最省事的选择，为它建一套检索系统是过度设计。
  3. 再给三条它吃不掉的理由。第一是成本：材料是按次计费的，同一份材料被问一万次就要付一万次，而检索只付取回的那几段；预填充缓存能缓解但不能消除，缓存也有有效期和命中率。
  4. 第二是规模：企业知识库动辄几十万篇，再大的窗口也塞不下，检索是唯一的入口。第三是归因与权限：答案要指回具体某一段，以及不同的人只能看到自己有权访问的材料——这两件事必须在把材料喂给模型之前完成，窗口再大也不解决。
  5. 还要补一条经验事实：材料变多之后，模型在长上下文里定位关键信息的稳定性会下降，出现「读了但没读到」。所以「全塞」并不总是等于「效果更好」，很多时候少而准反而更好。
  6. 可预期的追问：那检索的形态会不会变？会——窗口变大之后，取回的块可以更大、条数可以更多，重排与压缩的压力变小，检索从「精挑几句」变成「粗筛一批」。趋势是检索的粒度变粗，不是检索消失。

  How to reason about it · think before answering

  1. This is a position question and it is easy to answer as a binary. The signal is whether you separate what fits technically from what is worth paying for on every request.
  2. Concede the valid half first: bigger windows genuinely absorb part of the use case. For an internal tool over a few dozen stable documents with low traffic, stuffing everything in is the right call and building a retrieval stack would be over-engineering.
  3. Then give three reasons it does not absorb the rest. Cost is the first: context is billed per request, so the same corpus is paid for on every one of ten thousand queries, whereas retrieval only pays for the passages it returns. Prompt caching softens this but does not remove it.
  4. Scale is the second: enterprise corpora run to hundreds of thousands of documents and no window holds them. Attribution and access control are the third: pointing an answer at a specific passage, and showing each user only what they are permitted to see, both have to happen before the material reaches the model.
  5. Add the empirical point: as the supplied material grows, models become less reliable at locating the one relevant fact inside it. More context is not automatically better; fewer and more precise passages often win.
  6. Expected follow-up: does retrieval change shape? Yes. Larger windows allow bigger chunks and more of them, which relieves pressure on reranking and compression. Retrieval gets coarser, it does not disappear.

  答题要点

  • 先区分「能不能塞进去」和「该不该每次都塞」，前者是技术问题，后者是成本问题。
  • 小规模、低频、少变的语料确实可以直接全塞，为它建检索系统是过度设计。
  • 检索不会被淘汰的三个理由：按次计费的成本、几十万篇塞不下的规模、必须在喂给模型之前完成的归因与权限过滤。
  • 材料越多，模型定位关键信息的稳定性越差，全塞不等于效果更好。
  • 趋势是检索粒度变粗——块更大、条数更多、重排压力变小，而不是检索消失。

  Key points

  • Separate whether it fits from whether it is worth paying for on every request.
  • Small, stable, low-traffic corpora can legitimately be stuffed whole; building retrieval for them is over-engineering.
  • Three reasons retrieval survives: per-request cost, corpora too large for any window, and attribution plus access control that must happen before the model sees the material.
  • More supplied context reduces the reliability of locating a single fact, so stuffing everything is not automatically better.
  • The trend is coarser retrieval — bigger chunks, more of them, less reranking pressure — not the removal of retrieval.

D2 embedding 与向量检索：相似度、维度与模型选型，把文本存进 pgvector

• 把 embedding 维度从 1536 降到 512，你会损失什么？什么场景下这个损失可以接受？What do you lose when you cut embedding dimensions from 1536 to 512, and when is that loss acceptable?

  国内高频海外高频进阶#embeddings#dimensions#cost

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

  1. 这题考的是你会不会算账。只说「维度越低越省、精度越低」的答案没有区分度，面试官在等一个具体的成本模型和一个决策顺序。
  2. 先把三笔账列出来：存储与内存（向量数量乘维度乘每维字节数，近似最近邻索引要把它放进内存，所以基本等于机器预算）、检索延迟（每次比较就是一轮乘加，维度大致线性影响耗时）、检索质量（收益递减，低维段每加一档提升明显，高维段加倍只换来很小的改善）。
  3. 再说清降维为什么可行：主流模型用套娃式表示训练，重要信息压在靠前的维度上，所以直接截短再归一化仍然可用，这不是另训了一个小模型。截短必然有损失，损失多少只能在自己的数据上跑评估才知道。
  4. 给出决策顺序：先按存储与内存预算倒推一个维度上限，再从上限往下试两三档，看指标掉多少，掉得能接受就用低的。反过来「先选最高维再想办法省钱」基本都会返工。
  5. 点出可接受的典型场景：库很大而单条价值不高（比如日志、工单）、召回之后还有重排兜底（重排能把粗排的损失补回来一部分）、或者对延迟极敏感的在线场景。反过来法务、医疗这类一条都不能漏的场景就要谨慎。
  6. 可预期的追问：能不能不同文档用不同维度？不能——同一个索引里所有向量必须同维，改维度等于全库重建，这跟换模型是同一类迁移成本。

  How to reason about it · think before answering

  1. This is a cost-modelling question. 'Lower dimensions are cheaper but less accurate' earns nothing; the interviewer wants a cost model and a decision order.
  2. Lay out three costs: storage and memory (vector count times dimensions times bytes per dimension, which an ANN index must hold in RAM), query latency (roughly linear in dimensions), and retrieval quality, whose returns diminish sharply at the high end.
  3. Explain why truncation works at all: models trained with Matryoshka representations pack the most important information into the leading dimensions, so truncating and re-normalising keeps the vector usable. It is still lossy, and how lossy is an empirical question on your own data.
  4. Give the decision order: derive a dimension ceiling from your memory budget, then step down two or three notches and measure the metric drop. Choosing the largest model first and optimising cost later usually means redoing the work.
  5. Name the acceptable cases: large corpora of low individual value, pipelines where a reranker recovers some of the loss, and latency-critical online paths. Be conservative where a single miss is expensive, such as legal or clinical retrieval.
  6. Expected follow-up: can different documents use different dimensions? No. Every vector in an index must share one dimension, so changing it means rebuilding the whole index, the same migration cost as changing models.

  答题要点

  • 三笔账：存储与索引内存、检索延迟、检索质量，前两笔随维度近似线性，第三笔收益递减。
  • 套娃式表示让截短再归一化仍然可用，但一定有损失，损失多少要在自己的数据上评估。
  • 决策顺序是先按内存预算定上限，再往下试档位看指标掉多少。
  • 库大、单条价值低、后面还有重排兜底、对延迟敏感的场景，降维划算。
  • 同一索引里维度必须一致，改维度等于全库重建。

  Key points

  • Three costs: storage and index memory, query latency, and retrieval quality; the first two scale with dimensions, the third has diminishing returns.
  • Matryoshka representations make truncation viable, but it is lossy and the loss must be measured on your own data.
  • Decide by deriving a ceiling from the memory budget, then stepping down and measuring.
  • Truncation pays off for large corpora, low-value items, latency-sensitive paths, and pipelines with a reranker.
  • All vectors in one index share a dimension, so changing it forces a full rebuild.

D4 切块策略：固定、递归、按结构、父子与语义五种切法，以及用评估而不是直觉来选

• 语义切分比递归切分贵不少，你怎么向团队证明这笔钱值得花？Semantic chunking costs considerably more than recursive splitting. How would you prove to your team that the money is well spent?

  国内高频海外高频深入#chunking#evaluation#cost

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

  1. 这题表面问技术，实际考的是你会不会做一次带对照组的技术论证。上来就讲语义切分原理的人，答的是另一道题。
  2. 第一步是先承认它可能不值。语义切分的收益来自「文档没有可用的结构」；如果知识库是结构良好的文档，作者的标题层级已经免费替你做完了语义切分，这时候花的钱大概率打水漂。**先说清适用前提，再谈证明，这一步就把大多数候选人区分开了。**
  3. 第二步是把「值不值」翻译成可测的三笔账：指标涨了多少（同一批标准问题、同一个 token 预算下的命中率）、延迟涨了多少（切块是离线的，但更新链路的端到端时间会变）、钱涨了多少（首次全量 embedding 的费用，加上按更新频率折算的重算费用）。只报第一笔的论证不成立。
  4. 第三步是设计对照。递归切分是基线，语义切分是实验组，两组必须用同一份语料、同一批问题、同一个上下文预算、同一个检索器，只改切法这一个变量。改两个变量的实验，结论一文不值。
  5. 第四步是给决策一个门槛，而不是给一个感想。比如：命中率相对基线提升低于三个百分点就不上；提升超过五个百分点且重算成本在月度预算内就上；中间地带先在一类文档上灰度。**门槛要在跑数字之前定好**，否则你会不自觉地去迁就已经跑出来的结果。
  6. 可预期的追问是「有没有更便宜的办法拿到同样的收益」。答有：先试按结构切，它零成本且效果常常接近；结构确实不可用时，再考虑只对高价值的那一部分文档做语义切分，而不是全量上。

  How to reason about it · think before answering

  1. This looks like a technical question but it tests whether you can run a controlled technical argument. Launching into how semantic chunking works answers a different question.
  2. Step one is to concede that it may well not be worth it. The gain comes from documents that have no usable structure; if your knowledge base is well-formed documents, the authors' heading hierarchy already did the semantic split for free and the money is likely wasted.
  3. Step two is translating 'worth it' into three measurable numbers: how much the metric moved (hit rate on the same golden set under the same token budget), how much latency moved (chunking is offline, but the end-to-end update path changes), and how much it costs (the initial full embedding pass plus recomputation amortised over update frequency).
  4. Step three is the control. Recursive splitting is the baseline, semantic chunking the treatment, and they must share the corpus, the questions, the context budget and the retriever. Change one variable only; a two-variable experiment proves nothing.
  5. Step four is a decision threshold rather than an impression. For example: below three points of hit-rate gain, no; above five points with recomputation inside the monthly budget, yes; in between, roll it out on one document class first. Fix the threshold before you run the numbers, or you will quietly bend it to fit them.
  6. Expect the follow-up: is there a cheaper way to the same gain. Yes — try structural splitting first, since it is free and often nearly as good, and if the structure really is unusable, apply semantic chunking only to the high-value subset rather than the whole corpus.

  答题要点

  • 先讲适用前提：语义切分的收益来自文档没有可用结构，结构良好的文档上它大概率不值。
  • 把「值不值」翻译成三笔账：命中率涨多少、延迟涨多少、钱涨多少，只报第一笔不算论证。
  • 做对照实验：同语料、同问题集、同上下文预算、同检索器，只改切法一个变量。
  • 决策门槛必须在跑数字之前定好，避免事后迁就结果。
  • 先试零成本的按结构切；确需语义切分时也优先只覆盖高价值文档，而不是全量上。

  Key points

  • Start with the precondition: the gain comes from documents without usable structure, so on well-formed documents it usually is not worth it.
  • Translate 'worth it' into three numbers — hit rate, latency, and cost. Reporting only the first is not an argument.
  • Run a controlled comparison: same corpus, same golden set, same context budget, same retriever, with the splitting strategy as the only variable.
  • Fix the decision threshold before running the numbers so you cannot bend it to fit the result afterwards.
  • Try free structural splitting first, and if semantic chunking is genuinely needed, apply it to the high-value subset rather than the entire corpus.

D11 高级索引：父子文档、摘要索引、上下文检索，以及树状聚合与图检索的取舍

• 上下文检索要给每个块调一次模型，这笔一次性成本怎么估？有哪些办法能压下来？Contextual retrieval needs one model call per chunk. How do you estimate that one-off cost, and what levers bring it down?

  国内高频海外高频深入#contextual-retrieval#prompt-caching#cost

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

  1. 这题考的是你有没有真的算过账。只会说『用提示词缓存就便宜了』属于听过没做过——面试官会追问缓存到底省在哪一项上。
  2. 先把成本拆开：一次性 = 每块的输入 + 输出 + 全量 embedding；每次查询 = 块头在重排和上下文里各被读一遍。**这两笔要分开记**，因为它们随业务量的增长方式完全不同。
  3. 一次性那笔的主项是『同一篇文档被重复读了多少遍』。一篇切成 n 块就要读 n 遍，这是成本的大头。提示词缓存省的正是这一项：把整篇放在提示词最前面并标记为可缓存，第一块付一次缓存写入，后面 n-1 块只付缓存读取，而读取价通常比输入价低一个数量级。
  4. 顺序不能反：缓存按前缀匹配，整篇必须在前、块内容在后。把变化的块放前面，前缀次次都变，缓存一次都不会命中——这是最常见的翻车点。
  5. 我们的实测：30 篇、134 块，不开缓存输入 103017 token，开缓存后拆成写入 17340 加读取 60137，一次性成本降约 29%。**块切得越碎这个比例越高**，因为重复读的次数更多。
  6. 结论反直觉但很实用：一次性那笔是小钱，摊到 217 次查询就降到每次查询成本的一成以下；真正的长期账是每次查询多出来的那几十个 token（我们量到 +12.3%）。所以压成本的第一优先级不是压建索引，而是让块头别进上下文、别过长、别对全库无差别地生成。
  7. 最后一条是加分项：花这笔钱之前先确认你的评估环境**测得出**收益。我们的离线环境里向量路对召回的独立贡献实测为 0，所以它根本没法回答『块头对向量侧有没有用』——在这种环境里做的 A/B 会给你一个看起来有数字支撑的错误结论。

  How to reason about it · think before answering

  1. This checks whether you have actually done the arithmetic. Saying 'prompt caching makes it cheap' without knowing which line item it touches is a tell.
  2. Split the bill first: one-off = per-chunk input + output + full re-embedding; per-query = the header read twice, once by the reranker and once in the context. Keep them separate, because they scale with completely different things.
  3. The dominant term on the one-off side is how many times the same document is re-read. A doc split into n chunks is read n times. Prompt caching attacks exactly that: put the whole document first and mark it cacheable, pay a cache write once, then cache reads for the remaining n-1, typically an order of magnitude cheaper than input.
  4. Order matters. Caching is prefix-matched, so the document must come first and the chunk after. Put the varying part first and the prefix changes every call — zero cache hits. This is the most common way people get it wrong.
  5. Our measurement: 30 docs, 134 chunks. Without caching, 103017 input tokens; with caching, 17340 written plus 60137 read, cutting the one-off cost by roughly 29%. The finer the chunks, the bigger the saving, because re-reads multiply.
  6. The counter-intuitive part is the useful part: the one-off cost amortizes below 10% of per-query cost after about 217 queries. The lasting bill is the extra tokens every query carries (we measured +12.3%). So the first lever is not cheaper index building — it is keeping the header out of the context, keeping it short, and not generating it for the whole corpus indiscriminately.
  7. A bonus point: before spending any of it, confirm your evaluation setup can actually detect the benefit. In our offline harness the vector route contributed exactly zero unique answer documents, so it cannot answer whether headers help embeddings at all — an A/B run there hands you a wrong conclusion that looks numerically supported.

  答题要点

  • 把账拆成一次性（每块的输入输出 + 全量 embedding）和每次查询（块头在重排与上下文里各读一遍）两笔。
  • 一次性的大头是同一篇被重复读 n 遍；提示词缓存把它压成一次写入加 n-1 次读取。
  • 缓存按前缀匹配，整篇必须放在提示词最前面，块内容在后，顺序反了一次都不会命中。
  • 实测 30 篇 134 块，一次性成本降约 29%，块越碎省得越多。
  • 长期账在每次查询：块头别进上下文、控制长度、只对真正需要的文档生成。

  Key points

  • Split into one-off (per-chunk input/output plus re-embedding) and per-query (header read by both reranker and generator).
  • The one-off is dominated by re-reading each document n times; caching turns that into one write plus n-1 reads.
  • Caching is prefix-matched: the full document must come first, the chunk after, or you get zero hits.
  • Measured on 30 docs / 134 chunks, caching cut the one-off cost by about 29%, and finer chunks save more.
  • The lasting cost is per query: keep headers out of the context window, keep them short, and generate them selectively.
• 什么样的问题必须上图检索？给一个该上的具体例子和一个不该上的例子。What kind of question actually requires graph retrieval? Give one concrete case where it is justified and one where it is not.

  国内高频海外高频深入#graph-rag#multi-hop#cost

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

  1. 这题在考你会不会为了用而用。只要答案里出现『多跳问题就要上图检索』，面试官基本就知道你没落地过——多跳只是必要条件，远不是充分条件。
  2. 判据要落在一个可观察的现象上：**答案的第二篇文档和查询之间，有没有字面或语义上的重合**。有重合，普通的混合检索就能捞到它，多跳是假的；完全没有重合，只能靠一条关系边走过去，这才是图检索的领地。
  3. 该上的例子：问『生产库主备切换必须谁书面审批、这个人叫什么』。一篇写着须平台组组长审批，另一篇写着平台组组长是某人。第二篇跟查询一个词都不重合，我们在五种索引结构下测了一遍，它在 20 条候选池里一次都没出现过——换切法、加块头、父子回填全都无效。
  4. 不该上的例子：问『扩容要走哪个流程、最晚提前几个工作日提单』。同样跨两篇文档，但两篇都跟查询有明显字面重合，混合检索把它们分别排在第 2 名，一次检索就凑齐了。为它建图是拿几倍成本买一个已经解决的问题。
  5. 然后说代价，这一段决定了你像不像做过：建图不止一次抽取调用，实体要消歧、关系要去重、文档更新时受影响的子图要重算，还要多维护一套图存储和一套更新链路。
  6. 可预期的追问是『不上图检索还有什么办法』。答案是把多跳交给 Agentic 检索：让模型先查出中间实体，再拿这个实体发起第二次检索。它的一次性成本几乎为零，代价换成了每次查询的延迟与调用次数——先试这条，试不通再考虑建图。

  How to reason about it · think before answering

  1. This one tests whether you reach for tools you don't need. If the answer is 'multi-hop questions need a graph', the interviewer knows you haven't shipped one — multi-hop is necessary, nowhere near sufficient.
  2. Anchor the criterion on something observable: does the second required document share any lexical or semantic overlap with the query? If it does, ordinary hybrid retrieval will surface it and the hop is illusory. If it shares nothing, only a relation edge gets you there — that is graph territory.
  3. Justified case: 'who must sign off on a production failover, and what is that person's name?' One doc says the platform lead must approve; another says who the platform lead is. The second shares not one term with the query. Across all five index structures we tested, it never once appeared in a 20-item candidate pool — rechunking, headers and parent backfill all failed.
  4. Unjustified case: 'which process covers a capacity change, and how many working days ahead must the ticket be filed?' Also two documents, but both overlap the query lexically; hybrid retrieval ranked them second each, and one pass collected both. Building a graph for this buys a solved problem at several times the cost.
  5. Then state the cost, which is what makes the answer sound operational: graph building is not one extraction call. Entities need disambiguation, relations need dedup, updates force recomputing affected subgraphs, and you now run a graph store and its update pipeline.
  6. Expect 'what else could you do instead'. Hand multi-hop to agentic retrieval: let the model retrieve the intermediate entity first, then issue a second query with it. Near-zero build cost, paid back in latency and call count per query. Try that before you build a graph.

  答题要点

  • 判据不是『是不是多跳』，而是『第二篇文档跟查询有没有字面或语义重合』——没有重合才轮得到图检索。
  • 该上：审批人那类问题，中间实体是唯一的桥，第二篇文档在候选池里一次都不出现。
  • 不该上：两篇都跟查询有重合的多跳题，混合检索一次就能凑齐。
  • 建图的真实成本是实体消歧、关系去重、增量重算和一套额外的图存储，不是一次抽取调用。
  • 先试 Agentic 检索的两次查询，走不通再考虑建图。

  Key points

  • The test is not 'is it multi-hop' but 'does the second document overlap the query at all' — only zero overlap earns a graph.
  • Justified: the approver question, where an intermediate entity is the only bridge and the second doc never enters the candidate pool.
  • Not justified: a multi-hop question whose documents both overlap the query — hybrid retrieval collects them in one pass.
  • Real graph cost is entity disambiguation, relation dedup, incremental subgraph recomputation and a whole extra store — not a single extraction call.
  • Try two-pass agentic retrieval first; build the graph only when that fails.

D12 Agentic RAG：把检索做成工具，让模型自己决定查不查、查几次、要不要推翻重来

• 什么情况下你会拒绝把一个 RAG 系统做成 Agentic 的？拿什么数据说服你的团队？When would you refuse to make a RAG system agentic, and what data would you use to convince your team?

  国内高频海外高频进阶#agentic-rag#cost#engineering-judgement

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

  1. 这题在考工程判断力，也在考你会不会算账。凡是答「Agentic 更先进所以要上」的，直接出局；面试官想听的是你能主动说出它的代价，并且用数字划出适用边界。
  2. 怎么拆：先承认收益来自哪一类问题，再看这类问题在你的流量里占多大比例。Agentic 的收益几乎全部集中在多跳和检索失败重试上，单文档可答的问题一次检索就够了，多查一轮纯属浪费。
  3. 所以判据不是感觉，是评估集：跑一遍，看 multi 那一档占多少题、涨了多少个点，再对照总调用次数涨了多少倍。在一份 20 题的集合上，我们量到的是多跳召回从 75% 涨到 100%，可答题整体只从 93.8% 涨到 100%，代价是平均检索调用从 1 次涨到 1.75 次、外加同样次数的自评调用——为 100% 的问题付钱，只有 5% 的问题拿到好处。
  4. 三类明确不上：延迟敏感（每多一轮就是一次检索加一次模型往返，首字延迟拉长一到两倍）；问题模式固定（九成是单文档可答，收益接近零）；成本吃紧（真实模型不像离线替身那样老实，成本方差比均值更难受，按均值做的容量规划会在长尾上被打穿）。
  5. 给出替代方案才算完整：分流。先用一次便宜的判断看这一问像不像多跳，像才进循环，不像走固定流程。九成走一次检索、一成走循环，账完全不一样。这也说明循环是一种能力，不是默认值。
  6. 可预期的追问是「那你怎么知道哪些问题像多跳」。答案是从评估集和线上日志里找模式（问句里同时问了两个事实、问的是某个角色背后的人），先用规则跑，跑不动再上小模型分类——顺序不要反。

  How to reason about it · think before answering

  1. This tests engineering judgement and whether you can do arithmetic. Anyone who says 'agentic is more advanced so we should ship it' is out. The interviewer wants you to name the cost and draw the boundary with numbers.
  2. Decompose it: identify which question types actually benefit, then check how much of your traffic they represent. Agentic gains concentrate in multi-hop questions and retrieval retries; single-document questions are answered by one lookup and every extra round is waste.
  3. So the criterion is the evaluation set, not intuition. On a 20-item set we measured multi-hop recall going from 75% to 100% while overall answerable recall moved only from 93.8% to 100%, at the cost of average retrieval calls going from 1 to 1.75 plus the same number of assessment calls - you pay for 100% of traffic so that 5% of it improves.
  4. Three clear refusals: latency-sensitive surfaces, where each round adds a retrieval plus a model round trip and roughly doubles time to first token; fixed question patterns, where nine in ten questions are single-document and the gain is near zero; and tight cost budgets, where a real model is less disciplined than an offline stand-in and the variance, not the mean, is what breaks your capacity plan.
  5. Finish with the alternative: route. Use one cheap check to decide whether a question looks multi-hop, and only then enter the loop. Nine tenths take a single retrieval, one tenth loops, and the economics change completely. Looping is a capability, not a default.
  6. Expected follow-up: how do you know which questions look multi-hop? Mine the eval set and production logs for patterns - two facts requested in one sentence, or a question about the person behind a role - start with rules, and reach for a small classifier only when rules stop working.

  答题要点

  • 收益集中在多跳与检索失败重试，单文档可答的问题上收益接近零。
  • 用评估集算账：multi 档涨了多少点，对照总调用次数涨了多少倍。
  • 实测过的一组数字：多跳召回 75% 到 100%，整体 93.8% 到 100%，检索调用 1 次到 1.75 次外加等量自评调用。
  • 三类不上：延迟敏感、问题模式固定、成本吃紧（方差比均值更难受）。
  • 替代方案是分流：便宜的判断先过滤，像多跳才进循环。
  • 循环是一种能力，不是默认值。

  Key points

  • Gains concentrate in multi-hop and retry cases; single-document questions gain almost nothing.
  • Settle it with the evaluation set: multi-hop delta against the multiplier on total calls.
  • One measured set: multi-hop recall 75% to 100%, overall 93.8% to 100%, retrieval calls 1 to 1.75 plus the same number of assessment calls.
  • Refuse when latency-sensitive, when question patterns are fixed, or when cost is tight - variance hurts more than the mean.
  • Route instead: a cheap check up front, and only multi-hop-looking questions enter the loop.
  • Looping is a capability, not a default.

14 天用 Agent 搭一条 AI 短剧生产线

D3 角色一致性：定妆图、参考图与风格锁定，让同一个人每一镜都还是他

• 生成类资产要做复用，缓存键你会怎么设计，才能既省钱又不会串戏？How would you design the cache key for reusing generated assets so that you save money without serving the wrong asset?

  国内高频海外高频深入#caching#cost#image-generation

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

  1. 这题考的是缓存的两类错误，而且两类的代价完全不对称。少命中只是多花钱，错命中会把上一集的道具塞进这一集——前者可量化，后者是内容事故。
  2. 推导链只有一句：**键必须由所有会改变产物的输入算出来，一项不多一项不少。** 多算了不该算的（比如输出路径），改一次目录结构缓存全部失效，白花一遍钱；少算了该算的（比如提示词），换了描述还命中老图，就是串戏。
  3. 落到这个场景，参与哈希的是：资产类别、归属对象、变体名、完整提示词、参考图标识、随机种子。用 sha1 之类取个短摘要当 id，元数据里再把这几项原样存一份，出问题能照着复现。
  4. 然后主动把边界说清楚，这是加分项：模型 id 与版本要不要进键？要。风格模板改了怎么办？它是提示词的一部分，进键之后天然全部失效——所以模板要谨慎改，或者给它一个版本号，让你能决定失效的范围。
  5. 生产视角还有一条：失败的生成不要写进缓存，否则你会稳定复用一张被审核拦下的空结果。命中缓存的那条路径也要记台账并标成命中，不然你算不出缓存到底省了多少钱。
  6. 可以预期的追问：缓存要不要过期？答案是内容型资产通常不设时间过期，而是靠版本号显式失效；时间过期会在你毫无预期的时候让一整集重新生成一遍。

  How to reason about it · think before answering

  1. This question is about two kinds of cache error with wildly asymmetric cost. A miss only costs money; a wrong hit puts last episode's prop into this one. The first is a number, the second is a content incident.
  2. The derivation is one sentence: the key must be computed from every input that changes the artifact, and nothing else. Include something irrelevant, like the output path, and one directory refactor invalidates everything and you pay again; omit something relevant, like the prompt, and a changed description silently serves the old image.
  3. Concretely, hash the asset kind, the owning entity id, the variant name, the full prompt, the reference image identity and the seed. Take a short digest as the id, and store those fields verbatim in the metadata so any artifact can be reproduced.
  4. Then name the boundaries yourself: does the model id and version belong in the key? Yes. What if the style template changes? It is part of the prompt, so it invalidates everything by construction — which is why templates should carry a version number, letting you choose the blast radius.
  5. One more production note: never cache failed generations, or you will faithfully reuse an empty result that safety review rejected. Cache hits also belong in the cost ledger, flagged as hits, otherwise you cannot report how much caching saved.
  6. Expect the follow-up: should the cache expire? Content assets usually should not expire on time; invalidate explicitly by version instead, because a time-based expiry regenerates a whole episode at the least convenient moment.

  答题要点

  • 键由所有会改变产物的输入算出：资产类别、归属对象、变体名、完整提示词、参考图标识、随机种子，再加模型 id 与版本
  • 不要把输出路径或文件名放进键，改目录结构会让缓存整体失效，白付一遍钱
  • 少算提示词这类输入会导致错命中，那是内容事故，代价远高于少命中
  • 元数据里原样保存参与哈希的各项，出问题能复现；失败的生成不写缓存
  • 命中缓存也要记台账并标成命中，否则算不出缓存省了多少；失效靠显式版本号而不是时间过期

  Key points

  • Derive the key from everything that changes the artifact: asset kind, owner id, variant, full prompt, reference image identity, seed, plus model id and version
  • Keep output paths and filenames out of the key, or one directory refactor invalidates the whole cache and you pay twice
  • Omitting inputs like the prompt causes wrong hits, which are content incidents and far costlier than misses
  • Store the hashed fields verbatim in metadata so any artifact is reproducible, and never cache failed generations
  • Record cache hits in the cost ledger flagged as hits, and invalidate explicitly by version rather than by time

D4 从分镜到镜头：图生视频、异步任务轮询与失败重试

• 生成类接口返回失败，你怎么判断该不该重试？重试几次之后该做什么？When a generation API returns a failure, how do you decide whether to retry, and what happens after the retries run out?

  国内高频海外高频深入#error-handling#retry#cost

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

  1. 这题的题眼是「判断」。按状态码首位数字一刀切是最常见的错误答案，因为生成类接口的业务错误码往往和 HTTP 状态码不在一个层面上——很多厂商的失败是 HTTP 200 加一个响应体里的业务码。
  2. 给一条可复用的判据，比背错误码表有用：问三个问题——等一等会不会好、改输入会不会好、还是必须叫人来。三个问题对应三种处置：退避重试、修请求、立刻告警。
  3. 落到具体：限流和服务端故障属于第一类，程序自己扛；参数无效与内容审核属于第二类，重试一万次都是同一个错，而且会挤占限流额度让真正该重试的排不上号；鉴权失败与余额不足属于第三类，重试只会延迟告警。
  4. 然后单独处理超时，这是最能体现经验的一条：超时不是失败，是状态未知，对方队列里那个任务可能还在跑甚至已经成了。所以超时之后不能直接重提，要先按幂等键查一遍已有产物。
  5. 重试用尽之后要做三件事，缺一不可：把这一条标成失败并记下最后一次的错误码与请求参数、继续跑批次里剩下的任务不要中断、把失败清单汇总成一次可读的告警而不是每条发一次。
  6. 可以预期的追问：重试次数怎么定？按单价定。单价越高，允许的重试次数越少，而且高单价的失败更应该先送人复核再决定要不要重做。

  How to reason about it · think before answering

  1. The hinge is 'decide'. Bucketing by the leading digit of the HTTP status is the classic wrong answer, because generation APIs often return HTTP 200 with a business error code in the body.
  2. Give a reusable test instead of reciting a code table: ask three questions — will waiting help, will changing the input help, or does a human have to step in? They map onto three dispositions: back off and retry, fix the request, alert immediately.
  3. Concretely: rate limits and server errors are the first bucket and the program handles them; invalid parameters and content moderation are the second, where retrying repeats the same error and burns rate-limit budget that genuinely retryable tasks needed; auth failure and insufficient balance are the third, where retrying only delays the alert.
  4. Handle timeout separately — this is the line that signals experience. A timeout is unknown, not failed: the job may still be running, or may have finished. So never resubmit blindly; look up the idempotency key for an existing artifact first.
  5. When retries are exhausted, do three things: mark the item failed with the last error code and the exact request parameters, keep processing the rest of the batch instead of aborting it, and aggregate the failures into one readable alert rather than one per item.
  6. Expect the follow-up: how many retries? Scale it by unit price. The more expensive the call, the fewer automatic retries, and expensive failures should go to a human for review before being redone.

  答题要点

  • 不要按状态码首位一刀切，生成类接口的业务错误码常常藏在 HTTP 200 的响应体里
  • 判据是三个问题：等一等会不会好、改输入会不会好、还是必须叫人来，分别对应退避重试、修请求、立刻告警
  • 限流与服务端故障可重试；参数无效与内容审核重试无用且会挤占限流额度；鉴权失败与余额不足必须告警
  • 超时是状态未知不是失败，重试前先按幂等键查一遍已有产物，否则会重复计费
  • 重试用尽后：标记失败并留下错误码与请求参数、不中断整批、把失败汇总成一次可读告警；重试次数按单价定

  Key points

  • Do not bucket by the leading HTTP digit; generation APIs often hide the business error code inside an HTTP 200 body
  • Use three questions — will waiting help, will changing the input help, or is a human required — mapping to back off, fix the request, alert
  • Rate limits and server errors are retryable; invalid parameters and moderation blocks are not and waste rate-limit budget; auth and balance failures need an alert
  • A timeout is unknown rather than failed: check the idempotency key for an existing artifact before resubmitting, or you pay twice
  • When retries run out, mark the item failed with its error code and request parameters, keep the batch running, and aggregate failures into one alert; scale retry counts by unit price

D10 审片室：能预览、能改词、能重生成单镜的人机协作后台

• 一条自动化流水线要插入人工审核，你会把卡点放在哪几步？为什么？Where would you place human review checkpoints in an automated pipeline, and why there?

  国内高频海外高频基础#human-in-the-loop#pipeline-design#cost

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

  1. 这题在考你有没有成本意识。答「每一步都让人看一眼」是没做过工程的回答——人是最贵的资源，卡点多了流水线就退化成手工作坊。
  2. 给一条可复用的判据：**卡点放在「下游最贵的那一步」之前**。判断某个位置该不该设卡，只问一句「如果这里错了，往后要白花多少钱」。
  3. 按这条判据落到生成式流水线上，会得到三个位置：剧本定稿之后（此时零成本，却决定了后面所有素材的方向）、首帧出来之后视频生成之前（首帧是最便宜的一档，视频是最贵的一档，同一个镜头差出一到两个数量级）、成片合成之后发布之前（这一道拦的不是质量而是合规风险）。
  4. 补一条生产视角：卡点不等于阻塞。第一和第二道可以做成「默认放行、超时自动继续」，只有第三道必须硬卡——合规问题不能靠超时放行。
  5. 结论里要点出一个反直觉的事实：最容易被跳过的恰恰是第一道，因为这时候还没有画面，看起来没什么可审的；但它是唯一一道改起来零成本的闸门。
  6. 可预期的追问是「人来不及审怎么办」。答案是分级：机器先打分，只把低分的推给人，人的时间花在机器拿不准的那部分上。

  How to reason about it · think before answering

  1. This one tests cost awareness. Saying a human should look at every step marks someone who has not run this in production: humans are the expensive resource, and too many gates turn a pipeline back into handwork.
  2. Offer a reusable rule: put the gate immediately before the most expensive downstream step. To decide whether a position deserves a gate, ask how much money is wasted if something is wrong here.
  3. Applied to a generative pipeline that yields three positions: after the script is locked (free to change, yet it steers every asset that follows), after the first frame but before video generation (the frame is the cheapest step and the clip is the most expensive, one to two orders of magnitude apart), and after the final cut but before publishing (this one gates risk, not quality).
  4. Add the production view: a checkpoint is not necessarily blocking. The first two can auto-continue on timeout; only the compliance gate must hard-block, because you cannot let a legal check pass by timing out.
  5. State the counterintuitive part: the first gate is the one people skip, because there are no visuals yet and it looks like there is nothing to review, while it is the only gate where changes cost nothing.
  6. Expected follow-up: what if reviewers cannot keep up. Tier it. Machines score everything, humans only see the low scores, and human attention goes where the machine is unsure.

  答题要点

  • 判据是「卡点放在下游最贵的那一步之前」，问的是这里错了往后白花多少钱。
  • 三个位置：剧本定稿后、首帧出来后视频生成前、成片合成后发布前。
  • 首帧那一道性价比最高：首帧是最便宜的一档，视频是最贵的一档，同一个镜头差出一到两个数量级。
  • 前两道可以默认放行加超时继续，只有合规那一道必须硬卡。
  • 人力不够就分级：机器先打分，人只看低分的那些。

  Key points

  • Rule: place the gate right before the most expensive downstream step, judged by wasted spend if this step is wrong.
  • Three positions: after script lock, after first frame and before video, after final cut and before publish.
  • The first-frame gate pays best: the frame is the cheapest step and the clip the most expensive, one to two orders of magnitude apart.
  • The first two gates can auto-continue on timeout; only the compliance gate hard-blocks.
  • When reviewers are the bottleneck, tier it: machines score everything, humans only see low scores.
• 用户改了中间一步的输入，怎么算出哪些下游需要重做？A user edits an intermediate input. How do you compute which downstream steps must rerun?

  国内高频海外高频进阶#dag#incremental-recompute#cost

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

  1. 这题的区分度在方向和收尾两处，很多人只答出中间那段「沿依赖图传播」，前后都丢了。
  2. 方向：从被改的节点**沿着「谁依赖我」正向传播**，不是往上游找依赖。写反的后果很隐蔽——上游会被一起重跑，结果是对的，钱多花了一倍，测试也发现不了。
  3. 落到实现：把种子节点放进集合，反复扫一遍图，只要某个节点的依赖里有一个已经在集合里就把它也加进来，跑到不动点为止；最后按拓扑序返回，调用方顺着数组跑就不会先跑下游后跑上游。
  4. 收尾这一步最容易漏：**没受影响的节点，产物要从上一版复制过来，不是重新生成**。半径算得再准，少了复制这一步就一分钱没省。
  5. 然后是怎么验证。不要比文件哈希——同样的输入很可能生成逐字节相同的结果，哈希相同证明不了没重跑。要数**接口调用次数**，这才是硬证据，而且在离线与真实两种模式下都成立。
  6. 可预期的追问是「输入没变但你想重跑怎么办」。留一个强制重跑的开关，并且把它和自动判定分开记账，否则你会分不清一次重跑是系统判的还是人手动点的。

  How to reason about it · think before answering

  1. The signal lives at the two ends. Most candidates produce the middle part, propagation over a dependency graph, and drop both the direction and the finish.
  2. Direction: propagate forward along who-depends-on-me from the edited node, not backward to its dependencies. Getting it backward is insidious, because upstream nodes rerun, the output is still correct, the bill doubles, and no test catches it.
  3. Implementation: seed a set, sweep the graph repeatedly adding any node with a dependency already in the set until it stops growing, then return in topological order so the caller can just walk the array.
  4. The finish is what people forget: unaffected nodes must have their artifacts copied from the previous version, not regenerated. A perfect radius saves nothing without that copy.
  5. Then verification. Do not compare file hashes, because identical inputs often produce byte-identical output and a matching hash proves nothing. Count API calls instead; that evidence holds both offline and against a real vendor.
  6. Expected follow-up: what about forcing a rerun when nothing changed. Keep an explicit force flag and account for it separately, or you lose the ability to tell system-decided reruns from human-triggered ones.

  答题要点

  • 从被改的节点沿着「谁依赖我」正向传播，不是反向找依赖。
  • 扫图到不动点，结果按拓扑序返回，保证执行顺序不会颠倒。
  • 没受影响的节点要从上一版复制产物，否则半径算得再准也没省钱。
  • 验证要数接口调用次数，不要比文件哈希——同样的输入可能产出逐字节相同的结果。
  • 另留一个强制重跑开关，并与自动判定分开记账。

  Key points

  • Propagate forward along who-depends-on-me from the edited node, never backward.
  • Sweep to a fixed point and return in topological order so execution never runs downstream first.
  • Copy artifacts for unaffected nodes from the previous version, or the computed radius saves nothing.
  • Verify by counting API calls, not by comparing file hashes, since identical inputs can produce byte-identical output.
  • Keep a separate force-rerun switch and account for it apart from automatic decisions.