面试题库

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

D1 LLM API 基础：messages/roles、token、流式、temperature；Agent 到底是什么

• 为什么 LLM 应用几乎都用流式输出？SSE 和 WebSocket 该怎么选？Why do LLM apps stream responses, and how do you choose between SSE and WebSockets?

  国内高频海外高频进阶#streaming#protocol

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

  1. 第一问考的是对延迟指标的敏感度：要能区分「首字延迟」和「全文延迟」，并说出模型逐 token 生成决定了前者远小于后者。
  2. 把它翻译成产品语言：用户 1 秒内看到反馈 vs 对着空白等 20 秒，这是体验的分水岭，不是锦上添花。
  3. 第二问不要背优缺点表，先问自己「客户端需不需要频繁上行」——这一条几乎决定了答案。
  4. 只需要服务器往下推 token，SSE 就够：它跑在普通 HTTP 上，代理和负载均衡友好，还自带重连。需要语音、协同、频繁打断这类双向高频交互，才值得上 WebSocket。
  5. 给出多数产品的真实形态：请求走普通 POST，回复走 SSE，另配一个取消接口——顺势可以引到「POST 的 SSE 用不了 EventSource 的自动重连」这个坑。

  How to reason about it · think before answering

  1. The first half tests latency literacy: separate time-to-first-token from total latency and tie it to sequential generation.
  2. Translate to product terms: feedback within a second versus twenty seconds of blank screen.
  3. For the second half, skip the pros-and-cons table and ask whether the client needs frequent upstream messages.
  4. Server-to-client tokens only means SSE suffices: plain HTTP, proxy-friendly, with built-in reconnection. Voice, collaboration or frequent interrupts justify WebSockets.
  5. State the common shape: plain POST for the request, SSE for the reply, plus a cancel endpoint — which sets up the trap that POST-based SSE cannot use EventSource auto-reconnect.

  答题要点

  • 模型逐 token 生成，首字延迟远小于全文延迟；流式让用户 1 秒内看到反馈而不是等 20 秒
  • SSE 是单向、基于 HTTP 的文本协议，自动重连、穿透代理容易，天然适合服务器→客户端的 token 流
  • WebSocket 双向、更适合需要客户端频繁上行（语音、协同编辑、打断）的场景，但代理/负载均衡更麻烦
  • 多数聊天产品：请求用普通 HTTP POST，回复用 SSE；需要打断时再加一个取消接口

  Key points

  • Models emit tokens sequentially; time-to-first-token is far lower than full latency
  • SSE is one-way over HTTP with built-in reconnect and easy proxying, ideal for server→client token streams
  • WebSockets are bidirectional, better when the client sends often (voice, collaboration, interrupts) but harder to load-balance
  • Most chat products: plain POST for the request, SSE for the reply, plus a cancel endpoint
• 流式回复到一半网络断了，前端和后端各要做什么？EventSource 的自动重连能用上吗？A streaming reply is cut off mid-way. What do the client and server each do, and can EventSource auto-reconnect help?

  国内高频海外高频进阶#streaming#reliability#sse

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

  1. 这题的陷阱在后半句。很多人背过「SSE 自带重连」，就直接答自动重连能救——那是错的，必须先分清两种 SSE 用法。
  2. 浏览器原生 EventSource 确实按规范自动重连：重连时带 Last-Event-ID 请求头，服务器用 id: 打点、用 retry: 设间隔；但它只能发 GET，且要求响应 Content-Type 是 text/event-stream。
  3. 而 LLM chat API 必须 POST（messages 要放在请求体里），所以实际用的是 fetch 加手写 SSE 解析——EventSource 那套自动重连一行都用不上。
  4. 于是前端职责变成：自己判定断流、自己重试、自己保存已收到的部分。后端职责是让重试是安全的——响应可续、副作用幂等。
  5. 给出续写策略并说清边界：把已收到的内容作为上下文构造续写请求；但工具调用块和思考块无法部分恢复，只能从最近的完整文本块续。
  6. 可预期追问：非 200 响应会重连吗？按规范不会——状态码不是 200 或 Content-Type 不对，连接直接判定失败；服务器还可以用 204 主动叫停重连。

  How to reason about it · think before answering

  1. The trap is the second half: people who memorized 'SSE reconnects automatically' answer yes, which is wrong.
  2. Native EventSource does auto-reconnect per spec, sending Last-Event-ID, with the server marking events via id: and setting the interval via retry: — but it only issues GET and requires Content-Type text/event-stream.
  3. LLM chat APIs require POST because messages go in the body, so real clients use fetch plus hand-written SSE parsing, where none of that machinery applies.
  4. So the client owns detection, retry and buffering of what arrived; the server's job is making retries safe — resumable output and idempotent side effects.
  5. Give the continuation strategy and its limits: feed the received prefix back as context, but tool-use and thinking blocks cannot be partially recovered — resume from the last complete text block.
  6. Follow-up to expect: does a non-200 reconnect? Per spec no — a non-200 status or wrong Content-Type fails the connection, and a 204 tells the browser to stop reconnecting.

  答题要点

  • 先区分两种 SSE：浏览器原生 EventSource 自动重连并带 Last-Event-ID，但只能 GET；LLM API 走 POST，用不上这套
  • 所以前端要自己检测断流、自己重试，并保留已收到的部分内容
  • 续写策略：把已收到的内容作为上下文发起新请求，让模型接着写，而不是整轮重来
  • 边界：tool_use 和 thinking 块无法部分恢复，只能从最近的完整文本块续
  • 后端要保证重试安全：响应可续、工具副作用幂等，并对已产生的用量正确计费

  Key points

  • Separate the two SSE modes: native EventSource auto-reconnects with Last-Event-ID but is GET-only; LLM APIs use POST and cannot rely on it
  • The client must therefore detect the break, retry itself, and keep whatever text already arrived
  • Continuation: send the received prefix as context so the model resumes rather than restarting the turn
  • Limits: tool_use and thinking blocks cannot be partially recovered; resume from the last complete text block
  • The server must make retries safe: resumable responses, idempotent tool side effects, correct billing for tokens already produced
• 移动端 App 里的对话，网络频繁抖动，你会怎么设计重连策略？On mobile, connectivity is flaky. How would you design the reconnection strategy for a chat feature?

  国内高频海外高频进阶#reliability#mobile#streaming

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

  1. 先说明移动端和浏览器的差别：网络在 WiFi 与蜂窝之间切换、App 会被系统挂起、后台执行时间受限，所以不能照搬网页那套。
  2. 重试节奏用指数退避加随机抖动。抖动这一条常被忽略，但它是防止大面积断网恢复后所有客户端同时涌上来把服务打垮的关键。
  3. 要设上限：最大重试次数与最大退避间隔，超过就转成显式的「重新加载」按钮交给用户，而不是无限静默重试。
  4. 区分「短暂抖动」和「真的没网」：监听系统的网络状态变化，没网时直接停止重试并进入离线态，等网络恢复事件再立刻重连，比盲目定时重试省电得多。
  5. 结合上一题的服务端持久化：App 被系统杀掉后重进，靠会话 id 请求恢复端点，而不是指望本地缓存拼出完整回复。
  6. 最后补发送侧：用户在离线时发出的消息进本地队列，恢复后按序重发，且每条带幂等键，避免重复发送。

  How to reason about it · think before answering

  1. Start with what makes mobile different: network switches between WiFi and cellular, the OS suspends apps, background time is limited.
  2. Use exponential backoff with jitter; jitter is the commonly missed part that prevents a thundering herd when a wide outage clears.
  3. Set ceilings: max attempts and max interval, then surface an explicit reload action instead of retrying silently forever.
  4. Distinguish a brief blip from being genuinely offline: subscribe to OS connectivity events, stop retrying when offline, and reconnect on the restore event — far cheaper on battery than blind timers.
  5. Combine with server-side persistence: after the OS kills the app, resume by chat id rather than reconstructing from local cache.
  6. Finally the send path: queue outgoing messages while offline and replay them in order, each with an idempotency key.

  答题要点

  • 移动端特殊性：WiFi 与蜂窝切换、App 被挂起、后台执行时间受限，不能照搬网页策略
  • 指数退避加随机抖动，抖动用于避免大面积恢复时的重连风暴
  • 设最大重试次数与最大间隔，超过后转为显式的重新加载入口，不做无限静默重试
  • 监听系统网络状态：离线直接停重试进入离线态，收到恢复事件再重连，比定时轮询省电
  • 回复恢复依赖服务端持久化，靠会话 id 请求恢复端点；发送侧用本地队列加幂等键按序重发

  Key points

  • Mobile differs: network handoffs, OS suspension, limited background time — do not copy the web strategy
  • Exponential backoff with jitter, where jitter prevents a reconnect storm when an outage clears
  • Cap attempts and interval, then hand the user an explicit reload instead of retrying forever
  • Listen to OS connectivity events: stop while offline, reconnect on restore, which saves battery over polling
  • Resume replies via server-side persistence by chat id; queue outgoing messages with idempotency keys

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

• 什么是 ReAct 模式？它和你手写的工具调用循环是什么关系？What is the ReAct pattern, and how does it relate to a hand-rolled tool-calling loop?

  国内高频海外高频进阶#react#agent-loop#tool-calling

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

  1. 这题最容易答成名词解释。区分度在于你能不能指出 ReAct 和那个 while 循环是同一个东西，而不是两套并列的技术——把它们说成两样，面试官会认为你只读过博客没写过代码。
  2. 先给历史脉络：ReAct 出现时模型接口还没有工具字段，做法是在提示词里跟模型约定一套纯文本格式，让它交替吐出 Thought、Action、Action Input，你用正则把动作抠出来执行，再把 Observation 拼回提示词里继续。
  3. 再做映射，这是拿分的一步：今天的 function calling 把这套口头约定固化成了协议——Thought 对应 message.content，Action 对应结构化的 tool_calls，Observation 对应你追加回去的那条 role 为 tool 的消息。所以 ReAct 是那个循环的名字，不是另一种实现。
  4. 把取舍说出来：文本版脆在解析，模型少写一个换行、把参数写成 JSON、把 Action 和 Thought 换个顺序，正则就崩；结构化版把这个包袱交给了服务端，是今天的默认选择。但文本版没死——本地小模型、老接口不支持 tools 字段时，回退到「提示词约定 + 正则」仍是唯一可行的兜底，代价是解析失败率自己扛。
  5. 可以预期的追问：要不要让模型显式写出 Thought？它多花 token，但复杂任务的准确率通常更好，日志也终于可读。这是一个可调旋钮，不是必选项，按任务复杂度决定。
  6. 第二个追问：ReAct 和先规划后执行（Plan-and-Execute）有什么区别？ReAct 每一步都重新决策，边走边看，适合环境会变、信息要边查边补的任务；先规划后执行一次性出完整计划，步数和成本更可控，但对中途出现的意外不敏感。真实系统常常混用：先出一个粗计划，每一步内部再走 ReAct。

  How to reason about it · think before answering

  1. The trap is answering with a definition. What separates candidates is whether you can say that ReAct and the while loop you wrote are the same thing rather than two parallel technologies.
  2. Give the history first: when ReAct appeared, model APIs had no tool field. The trick was a prompt-level convention — the model emitted Thought, Action and Action Input as plain text, you regex-extracted the action, ran it, and pasted the Observation back into the prompt.
  3. Then map it, which is where the points are: function calling froze that convention into the protocol. Thought became message.content, Action became structured tool_calls, Observation became the tool-role message you append. ReAct is the name of your loop, not an alternative to it.
  4. State the trade-off: the text version is brittle at the parsing layer — a missing newline, JSON where plain text was expected, or a reordered Thought and Action all break the regex. Structured tool calls hand that problem to the server, which is why they are the default today. The text version is still alive though: local small models and older endpoints without a tools field leave you no other option, and you own the parse failure rate.
  5. Expect: should the model write its Thought out loud? It costs tokens, but accuracy on multi-step tasks usually improves and your logs finally become readable. Treat it as a dial, not a requirement.
  6. Second follow-up: ReAct versus plan-and-execute? ReAct re-decides at every step, which suits environments that change or information you have to gather as you go; plan-and-execute commits to a full plan up front, giving predictable step counts and cost but reacting poorly to surprises. Production systems often nest them: a coarse plan on the outside, a ReAct loop inside each step.

  答题要点

  • ReAct 是 Reasoning 加 Acting，让模型交替进行推理与行动，观察结果后再决定下一步
  • 原始形态靠提示词约定纯文本格式加正则解析；function calling 把这套约定固化进了 API 协议
  • 三步一一对应代码：Thought 是 message.content，Action 是 tool_calls，Observation 是回填的 role 为 tool 的消息
  • 结构化调用的好处是不用自己解析，代价是依赖模型支持 tools 字段；不支持时只能回退到文本版并自担解析失败率
  • 与先规划后执行相比，ReAct 每步重新决策、更适应变化，但步数与成本不如前者可控

  Key points

  • ReAct is Reasoning plus Acting: the model alternates thinking and acting, observing each result before deciding the next step
  • The original form was a prompt convention parsed by regex; function calling froze that convention into the API protocol
  • The three words map to code: Thought is message.content, Action is tool_calls, Observation is the tool-role message you append
  • Structured calls remove the parsing burden but require model support; without it you fall back to text ReAct and own the failure rate
  • Versus plan-and-execute, ReAct adapts better to change but has less predictable step count and cost
• 工具执行报错时，应该怎么把错误信息传给模型？有没有不该传的？When a tool fails, how should the error reach the model — and what must never reach it?

  国内高频海外高频进阶#tool-calling#error-handling

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

  1. 题眼在后半句。只答「catch 住、打日志、返回错误」是普通后端思维，答不出「在 Agent 里错误是给模型的反馈」就拿不到区分度分。
  2. 先分类，判据是一句话：这个错误模型改得动吗？参数格式不对、缺了必填项、值不在枚举里、单位没去掉——模型改得动，回传，并且要把「正确的样子」写进错误文案，否则它只会换个花样再错一次。反过来，数据库连不上、下游服务 500、凭证过期，模型改一万遍参数也没用，这类该由代码决定重试还是终止，回传只是让它空转烧钱。
  3. 结论落到形式上：值得回传的错误要变成一条正常的 role 为 tool 的消息，tool_call_id 照样对上，而不是抛异常终止循环。抛了用户看到 500；回传了模型往往下一轮就自己改对，这是 Agent 稳定性最便宜的一份来源。
  4. 接着答「不该传的」：绝不回传原始异常堆栈。堆栈里有文件路径、内部服务名，有时还有连接串，它会原封不动进入下一次请求，也可能被模型复述给用户；而且动辄上千 token，每一轮都跟着历史重发。回给模型的必须是你自己写的一句话，原始堆栈只进日志。
  5. 可以预期的追问：模型一直改不对怎么办？错误也要计入步数，撞上步数上限就终止并给用户一句交代；再进一步，同一个工具连续失败若干次可以直接把它从这一轮的可用工具里摘掉，逼模型换条路。
  6. 第二个追问：这和模型层的 fallback 是一回事吗？是同一套判断的两侧——那边问「换一家 provider 有没有可能变好」，这边问「让模型改一改有没有可能变好」，都是先分类再决定重试，一刀切重试在两边都是错的。

  How to reason about it · think before answering

  1. The second half is the discriminator. 'Catch it, log it, return an error' is ordinary backend thinking; the insight they want is that inside an agent loop an error is feedback to the model, not a failure notification.
  2. Classify first, with one test: can the model fix this? Malformed arguments, a missing required field, a value outside the enum, a unit that should not be there — the model can fix those, so return them, and spell out what correct looks like or it will simply fail differently next time. A database that is down, a 5xx from a downstream service, an expired credential — no amount of re-prompting helps, so code decides whether to retry or abort.
  3. Then the mechanics: a returnable error becomes an ordinary tool-role message with the matching tool_call_id, not an exception that unwinds the loop. Throwing gives the user a 500; returning usually gets the model to correct itself on the very next turn, which is the cheapest reliability you will ever buy.
  4. Now the 'never' half: never hand back a raw stack trace. It carries file paths, internal service names and sometimes connection strings, it enters the next request verbatim, the model may recite it to the user, and it costs a thousand tokens re-sent every turn. Send a sentence you wrote; keep the stack in your logs.
  5. Expect: what if the model never gets it right? Failed calls still count against the step budget, and hitting the cap should end the run with an honest message. Going further, a tool that fails N times in a row can be dropped from the available set for that run, forcing a different route.
  6. Second follow-up: is this the same as provider fallback? Two sides of one judgment. There you ask whether another provider could plausibly succeed; here you ask whether the model could plausibly fix it. Blanket retry is wrong in both places.

  答题要点

  • 先分类：模型改得动的错误（参数格式、缺字段、枚举越界）才值得回传，外部故障应由代码决定重试或终止
  • 回传的形式是一条正常的 role 为 tool 的消息，tool_call_id 照常对应，而不是抛异常中断循环
  • 错误文案里要写清「正确的样子」，模型才知道该怎么改，否则它只会换个花样再错一次
  • 绝不回传原始异常堆栈：内部路径与服务名会进入下一次请求、可能被复述给用户，还白白吃掉上千 token
  • 报错同样计入步数上限；同一工具连续失败可以临时摘掉，避免模型在原地打转

  Key points

  • Classify first: only model-fixable errors (bad arguments, missing fields, enum violations) are worth returning; infrastructure failures are the code's decision
  • Return it as an ordinary tool-role message with the matching tool_call_id, not as an exception that kills the loop
  • Write what correct looks like into the message, otherwise the model just fails a different way
  • Never return raw stack traces: internal paths leak into the next request and to users, and they burn a thousand tokens every turn
  • Failed calls count against the step budget, and a repeatedly failing tool can be removed from the available set

D3 Pi SDK 上手：三层架构、Agent Loop 对照（dg P01/P02/M02/M03）

• 选择使用 Agent 框架还是手写 Agent，你会怎么权衡？How do you decide between adopting an agent framework and hand-rolling the loop?

  国内高频海外高频进阶#framework-design#engineering-tradeoffs

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

  1. 题眼在「权衡」。答「框架更快」或者「手写更可控」都只说了一半，面试官想听的是你有没有一条能当场执行的判据，而不是立场。
  2. 给判据：问自己「我需不需要看见并改动这段循环里的每一步」。需要就手写——学习调试阶段、合规审计要求每次模型调用和工具调用都可拦截可留痕、或者场景本身只有一两个工具两三轮循环，那点代码量的收益抵不过一整棵依赖树。
  3. 不需要就用框架，判断标准是这几件事你是不是迟早都要做：工具数量上去、要把每一步实时推给前端、会话要能重启后继续、上下文满了要压缩、要随时换模型。这些凑齐了就是一个小型框架，自己写等于重新发明一个没人帮你测的版本。
  4. 然后主动说出框架的三笔代价，这是区分度所在：一是排障栈变深，工具没被调用可能是描述、schema、钩子拦截三种完全不同的原因；二是你继承了一堆没写过的默认值，模型、系统提示词、内置工具都是别人替你选的；三是升级会改变你没测过的行为，代码一行没动线上表现却变了，这类问题最难定位。
  5. 结论要给出可落地的折中：先手写一遍把循环吃透，再上框架；上了框架也要显式覆盖掉默认值，并把框架版本锁死。这样既拿到了开发速度，也没把行为的控制权整个交出去。
  6. 可以预期的追问：那你怎么评估一个框架好不好？答看它的分层能不能让你「只要一半」——只要模型调用层、循环自己写行不行；必须整包吞下的框架，迟早要为用不上的那一半付代价。

  How to reason about it · think before answering

  1. The hinge word is 'decide'. 'Frameworks are faster' and 'hand-rolling is more controllable' are each half an answer; what earns points is a criterion you can apply on the spot rather than a preference.
  2. Offer the criterion: ask whether you need to see and change every step inside the loop. If yes, hand-roll — during learning and debugging, under compliance rules that require every model call and tool call to be interceptable and auditable, or when the scenario really is two tools and three turns and the saved lines do not justify a large dependency tree.
  3. If no, take the framework, and justify it by what you will inevitably need anyway: more tools, streaming every step to a UI, sessions that survive a restart, compaction when context fills up, swapping models on demand. Assemble all of those yourself and you have written a small framework — an untested one.
  4. Then volunteer the three costs, which is where the signal is: debugging spans more layers, so a tool that never runs could be a bad description, a schema rejection, or a hook that blocked it; you inherit defaults you never wrote, including the model, the system prompt, and the built-in tools; and upgrades change behavior you never tested, which is brutal to diagnose because your own code did not change.
  5. Land on a practical middle: hand-roll once to internalize the loop, then adopt a framework, override its defaults explicitly, and pin its version. You keep the delivery speed without handing over control of behavior.
  6. Expect the follow-up: how do you judge a framework? By whether its layering lets you take only half of it — model layer only, loop your own. Anything you must swallow whole will eventually bill you for the half you do not use.

  答题要点

  • 判据是「需不需要看见并改动循环里的每一步」，需要就手写，不需要就用框架
  • 手写更合适：学习调试、合规要求每步可拦截可留痕、场景极简、对依赖体积与冷启动敏感
  • 框架更合适：工具多、要事件流、要会话持久化与压缩、要多模型——这些凑齐等于自己造一个框架
  • 框架的三笔代价：排障栈变深、继承一堆没写过的默认值、升级会改变没测过的行为
  • 折中做法：先手写吃透循环再上框架，显式覆盖默认值并锁死版本

  Key points

  • The criterion is whether you need to see and modify every step of the loop
  • Hand-roll for learning and debugging, for compliance that demands interceptable and auditable steps, for genuinely tiny scenarios, and where dependency size or cold start matters
  • Use a framework once you need many tools, an event stream, persistent sessions, compaction, and model swapping — building all of that is writing a framework yourself
  • Three costs: deeper debugging surface, inherited defaults you never wrote, and upgrades that shift untested behavior
  • The middle path: hand-roll once, then adopt, override defaults explicitly, and pin the version

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
• 系统提示词（system prompt）在 Agent 里起什么作用？为什么不能用框架默认的？What does the system prompt do in an agent, and why not rely on the framework default?

  国内高频海外高频进阶#prompt-engineering#system-prompt

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

  1. 前半句是送分题，后半句才是区分度所在——很多人答得出 system prompt 是干什么的，答不出「默认值有什么坑」。
  2. 先说作用：它是唯一一段在整段对话里权重稳定、不会被后续几十轮稀释的指令，用来设定身份、能力边界和输出格式。
  3. 再答「为什么不能用默认的」，要给出三条具体后果而不是泛泛说「不够定制」：一是它不知道你的业务边界，用户问业务外的问题它会热情地答；二是它不约束输出格式，前端样式会被冷不丁冒出的 Markdown 标题打乱；三是最要命的——它会随框架升级而变化，你测好的所有行为建立在一段看不见的文本上，出 bug 时你的代码一行没动，极难排查。
  4. 结论落到工程做法：生产环境的 system prompt 是拼出来的模板，结构是「人设 + 能力边界 + 输出要求 + 动态上下文」，最后一块每次请求现拼。
  5. 可以预期的追问：动态上下文里最容易漏什么？答「当前时间」——模型没有时钟，不告诉它今天几号，它算不出「三天前下的单」是哪天。这个细节很能体现有没有真做过。
  6. 第二个追问：prompt 怎么测试？答案是把它当配置而不是代码——存库、加版本号、支持按比例灰度，因为你没法写单元测试断言「模型语气变友好了」。

  How to reason about it · think before answering

  1. The first half is a warm-up; the discriminating half is why the default is dangerous.
  2. State the role: it is the one instruction block whose weight stays stable across dozens of turns, setting identity, capability boundaries and output format.
  3. Then give three concrete consequences rather than 'not customized enough': it does not know your business boundary so it happily answers off-topic questions; it does not constrain output format so stray Markdown headings break your UI; and worst, it changes when the framework updates — your tested behavior rests on invisible text, and the bug appears with zero code changes.
  4. Land on practice: a production system prompt is assembled from a template — persona, capability boundary, output requirements, dynamic context — with the last part rebuilt per request.
  5. Expect: what gets forgotten in dynamic context? The current time. Models have no clock; without today's date they cannot resolve 'the order I placed three days ago'.
  6. Second follow-up: how do you test a prompt? Treat it as configuration, not code — store it, version it, roll it out to a percentage, because you cannot unit-test 'the tone got friendlier'.

  答题要点

  • system prompt 设定身份、能力边界与输出格式，是对话里权重最稳定、不被后续轮次稀释的一段指令
  • 框架默认人设不知道你的业务边界，会热情回答业务外的问题，浪费 token 且跑题
  • 默认人设不约束输出格式，模型可能吐出 Markdown 标题打乱前端样式
  • 最危险的是默认值会随框架升级而变化，代码一行没动却出现行为回归，极难排查
  • 生产做法：显式拼模板（人设 + 能力边界 + 输出要求 + 动态上下文），当作配置存储、加版本号、可灰度

  Key points

  • The system prompt sets identity, capability boundaries and output format, and keeps stable weight across turns
  • A default persona does not know your business boundary and will cheerfully answer off-topic questions
  • It does not constrain formatting, so stray Markdown can break your UI
  • Most dangerous: defaults change on framework upgrades, producing behavior regressions with no code change
  • Production practice: assemble it explicitly, treat it as versioned configuration, and roll changes out gradually
• 如何在成本和延迟之间给不同任务选择合适的模型？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

D5 工具系统与事件驱动：参数校验、错误回传让模型自纠错、事件订阅（dg P05/P06/M05/M07）

• 工具调用报错或参数非法时，你怎么让模型自己纠正而不是直接失败？When a tool call fails validation or errors out, how do you get the model to correct itself instead of failing the whole turn?

  国内高频海外高频进阶#tool-calling#error-handling

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

  1. 这题在考你有没有真的做过工具循环。只答「把错误告诉模型」是及格线，区分度在两个地方：错误信息长什么样，以及你有没有给它设刹车。
  2. 先给机制，一句话就能说清：错误不是异常，是数据。工具成功时你把结果包成一条 tool 消息追加进 messages 再继续循环，失败时走同一条路，只是内容换成错误描述。异常一路抛出、终止这一轮，是最常见的错误做法。
  3. 再给判据：好错误信息有三个要素——错在哪个字段、期望是什么、一个合法示例。对比三档就很清楚：「工具执行失败」模型只能原样重试或放弃；「order_id 格式不正确」它知道错在哪却不知道对的长什么样，可能试出一个新错法；「参数 order_id 需要 SO 开头加 8 位数字，例如 SO20260901，你传的是数字 12345」基本一次改对。另外校验要一次报全部错误，报了第一条就返回会让模型多跑好几轮。
  4. 然后主动说代价，这是面试官等的：一次自纠错等于多两条消息加一次完整的模型调用，延迟和 token 都翻倍；更凶的是死循环——错误信息含糊时模型会以近乎相同的方式反复重试。所以必须设三道闸：单工具连续失败 2 次就停手转人工、整轮工具调用总次数上限、整轮 token 预算，哪个先到都终止。
  5. 最后划一条边界，它和 D4 的 fallback 判据同源：判断依据是「模型改参数有没有可能变好」。校验失败、订单不存在、日期超范围——回传。数据库连不上、下游 503、密钥过期——模型改一百遍参数也没用，应该直接失败并告警，回传只会让它朝错误方向瞎试。
  6. 可以预期的追问：回传的错误信息里能放什么？只能放字段名、期望格式和示例；栈信息、SQL、内部路径、真实表名一律不能进，因为模型会把它复述给用户。

  How to reason about it · think before answering

  1. This checks whether you have actually built a tool loop. 'Tell the model about the error' is the passing grade; the discriminators are what the error text looks like and whether you put brakes on the loop.
  2. State the mechanism in one line: an error is data, not an exception. On success you append the result as a tool message and continue the loop; on failure you take the same path with error text as the content. Throwing all the way out and killing the turn is the common mistake.
  3. Give the quality bar: a good error names the field, states the expectation, and shows one valid example. Compare three tiers — 'tool failed' leaves the model to retry blindly or give up; 'order_id has the wrong format' tells it where but not what, so it may invent a new wrong form; 'order_id must be SO plus 8 digits, e.g. SO20260901, you sent the number 12345' usually gets fixed in one shot. Also report every validation error at once; returning on the first one costs extra round trips.
  4. Volunteer the cost, which is what they are waiting for: one self-correction adds two messages and a full model call, doubling latency and tokens. Worse is the infinite loop when the error text is vague. So set three brakes — stop after two consecutive failures of the same tool and hand off to a human, cap total tool calls per turn, and cap the token budget per turn.
  5. Draw the boundary, which shares its logic with the D4 fallback rule: the test is whether changing arguments could plausibly help. Validation failures, 'order not found', 'date out of range' — feed back. Database unreachable, downstream 503, expired key — no argument change will help, so fail loudly and alert instead of letting the model flail.
  6. Expect the follow-up: what may go into the error text? Field names, expected formats and examples only. Stack traces, SQL, internal paths and real table names must never reach the model, because it will repeat them to the user.

  答题要点

  • 错误不是异常是数据：把它包成一条 tool 消息追加进 messages，和成功结果走同一条路，模型下一轮就能看到
  • 好错误信息三要素：错在哪个字段、期望是什么、给一个合法示例；校验要一次报全部错误
  • 自纠错不免费：多两条消息加一次模型调用，延迟和 token 翻倍
  • 必须设三道闸：单工具连续失败 2 次转人工、整轮工具调用总次数上限、整轮 token 预算
  • 判据是「模型改参数有没有可能变好」：校验失败该回传，数据库连不上、下游 503 该直接失败并告警
  • 回传文本只能有字段名、期望格式和示例，不能带栈信息、SQL 和内部路径

  Key points

  • An error is data: append it as a tool message on the same path as a successful result so the model sees it next turn
  • A good error names the field, states the expectation and shows a valid example; report all validation errors at once
  • Self-correction is not free — two extra messages plus a full model call double latency and tokens
  • Set three brakes: hand off after two consecutive failures of one tool, cap tool calls per turn, cap the token budget
  • The test is whether changing arguments could help: feed back validation errors, but fail loudly on unreachable databases or downstream 503s
  • Never put stack traces, SQL or internal paths into text the model will read
• Agent 的事件系统一般会暴露哪些生命周期事件？为什么不能只等最终返回值？Which lifecycle events does an agent runtime typically expose, and why is waiting for the final return value not enough?

  国内高频海外高频进阶#event-driven#observability

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

  1. 这题看起来是背清单，实际考的是你有没有做过带界面的 Agent。只报事件名不解释用途，会被判成看过文档但没接过前端。
  2. 先说动机：一次带工具的循环短则几秒长则几分钟，中间要调模型、调工具、可能还失败重试，而返回值只有最后一句话。对调用方来说中间全是黑盒——不知道它在干什么，也不知道该不该再等。
  3. 再报清单并各配一句用途：run:start / run:end / run:error 是一轮的开始与两种结束；model:delta 是模型吐出的文本片段，前端拿它做打字机效果；tool:proposed 是模型决定要调工具但还没执行，权限确认就挂在这个事件上；tool:start / tool:end / tool:error 是工具执行的三个出口，tool:end 带耗时；approval:required 让界面弹确认框。
  4. 然后说出这套设计真正的价值：同一条事件流同时喂三个消费者——界面渲染进度、日志系统做链路追踪、计量系统拿 run:end 的 token 数算成本。不为三件事写三套埋点，这是架构判断而不是 API 罗列。
  5. 补两条实现纪律，能显著拉开差距：事件必须带 runId 和自增序号，因为跨进程传输后顺序不保证；监听器里不写业务逻辑，且监听器抛错不能炸掉主循环——事件是旁路不是主干。
  6. 可以预期的追问：model:delta 一个 token 一条事件会不会太多？会，所以要按时间窗合批，攒 50 毫秒推一次，用户感知不到差别而消息量掉一个数量级。

  How to reason about it · think before answering

  1. It looks like a listing question but it really tests whether you have shipped an agent with a UI. Reciting event names without saying what each one is for reads as documentation-deep only.
  2. Start with the motivation: a tool-using loop runs from seconds to minutes, calling models and tools and sometimes retrying, while the return value is just the final sentence. Everything in between is a black box to the caller, who cannot tell whether to keep waiting.
  3. List them with a purpose each: run:start, run:end and run:error mark the turn and its two endings; model:delta carries text fragments for the typewriter effect; tool:proposed fires when the model has chosen a tool but has not executed it, which is where the approval gate hangs; tool:start, tool:end and tool:error are the three exits of execution, with duration on tool:end; approval:required tells the UI to show a confirmation card.
  4. Then name the real payoff: one event stream feeds three consumers — the UI renders progress, logging gets distributed tracing, and metering reads token counts off run:end. One stream instead of three instrumentation layers is an architecture answer, not an API listing.
  5. Add two implementation rules that separate candidates: every event carries a runId and a monotonic sequence number because ordering is not guaranteed once events cross processes, and listeners must contain no business logic and never let an exception escape into the main loop. Events are a side channel, not the trunk.
  6. Expect the follow-up: isn't one event per token too many? Yes, so batch on a time window — flush every 50ms, which is imperceptible to users and cuts message volume by an order of magnitude.

  答题要点

  • 动机：一轮循环几秒到几分钟，返回值只有最后一句话，中间全是黑盒，调用方无法判断该不该继续等
  • 常见事件：run:start / run:end / run:error、model:delta、tool:proposed、tool:start / tool:end / tool:error、approval:required
  • 同一条事件流同时喂界面、日志链路追踪和成本计量三个消费者，不用写三套埋点
  • 事件要带 runId 和自增序号，跨进程后顺序不保证，消费端要能自己排序
  • 监听器不写业务逻辑，且抛错不能影响主循环；model:delta 要按 50 毫秒时间窗合批

  Key points

  • Motivation: a turn takes seconds to minutes and only returns the final sentence, so the caller cannot tell whether to keep waiting
  • Typical events: run:start/end/error, model:delta, tool:proposed, tool:start/end/error, approval:required
  • One stream serves the UI, distributed tracing and cost metering — no need for three instrumentation layers
  • Every event carries a runId and a sequence number since ordering is not guaranteed across processes
  • Listeners hold no business logic and must not throw into the main loop; batch model:delta on a 50ms window

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
• 会话的持久化、恢复和分叉分别解决什么问题？实现时各有什么坑？What problems do session persistence, restore, and forking each solve, and what goes wrong in each?

  国内高频海外高频进阶#session-management#persistence#forking

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

  1. 题干把三件事并列，考的其实是你能不能分清它们各自的动机——很多人会把三个都答成「存下来」，那就丢掉了全部区分度。
  2. 先一句话各给一个动机：持久化解决「进程重启和跨机器请求」，恢复解决「加载回来还能接着聊」，分叉解决「同一段历史要走出两条不同的后续」。动机不同，所以数据结构的要求也不同。
  3. 持久化的关键选择是只追加还是快照。答只追加并给理由：写入不受历史长度影响、能回放到任意一步、有审计轨迹；快照只是读加速手段，工程上常见的是「只追加为准 + 定期快照」。这一条直接决定了分叉能不能做。
  4. 恢复的两个坑要主动说。一是把当时的系统提示词一起存进了历史，里面有「现在时间」这类动态上下文，三天后读出来模型的日期判断全错——系统提示词不进持久化历史，每次现拼。二是存档存在了工具调用中途，最后一条是没有配对结果的 tool_calls，直接发出去就是 400，加载后必须做完整性校验，补一条「执行被中断」的结果或丢弃这条尾巴。
  5. 分叉最容易被忽视的是「父会话只读」这条语义。分叉不是回滚：回滚砍掉历史继续用，是破坏性的；分叉复制前 k 条长出新枝，两边都能继续。实现上要深拷贝，直接引用父会话的消息对象会让两条分支互相污染。
  6. 可以预期的追问：分叉多了存储怎么办？答按父引用加偏移存、读时拼接，代价是读路径变复杂；再顺手补一句成本要能顺着 parentId 聚合成一棵树，否则账算不清是哪个用户的哪次重试花的钱。

  How to reason about it · think before answering

  1. The question lists three things side by side, so it is really testing whether you can separate their motivations. Answering 'they all save the conversation' throws away the entire signal.
  2. Give one motivation each in a sentence: persistence survives process restarts and multi-instance routing, restore lets a loaded history keep the conversation going, forking lets one history grow two different futures. Different motivations imply different data structures.
  3. The key persistence choice is append-only versus snapshot. Choose append-only and justify it: writes are independent of history length, any point can be replayed, and you keep an audit trail. Snapshots are a read optimization, so production usually means append-only as the source of truth plus periodic snapshots. This choice is what makes forking possible at all.
  4. Volunteer the two restore traps. First, persisting the system prompt inside the history: it carries dynamic context like the current time, so a session loaded three days later has the model reasoning from a stale date. Rebuild the system prompt fresh on every load. Second, a session saved mid tool call ends with an unmatched tool_calls message; replaying it verbatim gets a 400, so validate on load and either append an 'execution interrupted' tool result or drop the dangling tail.
  5. For forking, the overlooked point is that the parent stays read-only. Forking is not rollback: rollback truncates and mutates, forking copies the first k messages into a new branch and both sides continue. Deep-copy the messages — sharing the parent's objects lets the branches contaminate each other.
  6. Expect the follow-up on storage: reference the parent plus an offset and stitch on read, at the cost of a more complex read path. Add that cost must aggregate up the parentId tree, or you cannot tell which user's retry burned which tokens.

  答题要点

  • 持久化解决进程重启与跨实例，选只追加：写入不受历史长度影响、可回放任意一步、有审计轨迹；快照只是读加速
  • 恢复要现拼系统提示词，不能把带「现在时间」的那份存进历史，否则读出来日期判断全错
  • 恢复必须做完整性校验：尾部悬空的 tool_calls 要补一条中断结果或丢弃，否则下一次请求返回 400；压缩水位也要一起恢复
  • 分叉是复制前 k 条并记住父会话与切点，父会话只读——这是它和破坏性回滚的根本区别，实现上必须深拷贝
  • 分叉的代价是存储放大与成本归属，规模上来后改成存父引用加偏移，账要能顺着 parentId 聚合成树

  Key points

  • Persistence handles restarts and multiple instances; prefer append-only for constant-cost writes, replayability and an audit trail, with snapshots purely as a read optimization
  • On restore, rebuild the system prompt fresh — persisting the one containing the current time makes the model reason from a stale date
  • Validate on restore: a dangling tool_calls tail needs an 'interrupted' tool result or must be dropped, or the next request returns 400; restore the compression watermark too
  • A fork copies the first k messages and records parent and cut point, leaving the parent read-only — that is what separates it from destructive rollback, and it requires a deep copy
  • Forking costs storage amplification and muddled cost attribution; at scale store a parent reference plus offset and aggregate spend up the parentId tree

D7 封装成服务：Fastify + SSE + Docker（dg P07）；W1 复盘

• 把一个本地跑的 Agent 脚本改造成生产服务，接口层要重点考虑哪些事？When turning a local agent script into a production service, what does the interface layer have to get right?

  国内高频海外高频进阶#api-design#service-architecture#streaming

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

  1. 这题考的是「你知不知道脚本里有哪些隐含假设」。答成一份笼统的清单（鉴权、日志、监控）拿不到分，要说出脚本时代默认成立、服务里立刻不成立的那几条。
  2. 先把假设列出来，这是最能体现工程视角的一步：只有一个用户（历史可以放模块级变量）、串行执行（不会有两个请求同时改一份状态）、输入可信（参数是自己敲的）、进程和会话同生共死（Ctrl+C 之后不用交代）。四条在服务里全部不成立，而第一条最难查，因为它在本地单人测试时表现完美。
  3. 然后给出四个必须做的决定：接口形状（一次性 JSON 还是流式推送）、会话标识（客户端带 sessionId 还是服务端发 cookie，以及历史存哪里）、鉴权与限流（谁能调、多久能调一次、单次 token 上限）、错误怎么表达。
  4. 第四条要单独展开，它是这题真正的区分点：流式接口一旦写出 200 和第一个字节，状态码就已经发出去了，之后模型超时、余额不足、上游 500，都只能在流里补发一个约定好的 error 事件。所以推流之前必须把能校验的全部校验完，那是你最后一次能用状态码好好说话的机会。
  5. 再补一条生产视角：服务要有健康检查接口。没有它，编排系统和负载均衡就没法判断这个实例能不能接流量，滚动发布时会把请求打给一个还没起好的进程。
  6. 可以预期的追问：单次请求的 token 上限为什么要在接口层限制？因为 Agent 的成本是请求方触发、你来买单，不设上限就等于把钱包交给调用方——限流限的不只是 QPS，还有每次调用能烧多少钱。

  How to reason about it · think before answering

  1. This tests whether you can name the assumptions hidden in a script. A generic checklist (auth, logging, monitoring) scores nothing; name the assumptions that silently break.
  2. List them first: one user (so history can live in a module-level variable), serial execution (no two requests mutating the same state), trusted input (you typed the arguments yourself), and a process whose life equals the session's. All four break in a service, and the first is hardest to catch because single-user local testing looks perfect.
  3. Then give the four decisions: response shape (single JSON versus streamed events), session identity (client-supplied id versus server cookie, and where history is stored), authentication and rate limiting (who may call, how often, and the per-call token ceiling), and how errors are expressed.
  4. Expand the last one — it is where this question is actually won. Once a streaming endpoint has written 200 and the first byte, the status code is already on the wire, so a later timeout, out-of-credit or upstream 500 can only surface as an agreed error event inside the stream. Validate everything you can before the first byte, because that is your last chance to speak in status codes.
  5. Add a production note: ship a health endpoint. Without one, orchestrators and load balancers cannot tell whether an instance is ready, and rolling deploys send traffic to a process that has not finished booting.
  6. Expect the follow-up: why cap tokens per request at the interface layer? Because agent cost is triggered by the caller and paid by you — no cap means handing your wallet to the client. Rate limiting is about money per call, not just QPS.

  答题要点

  • 脚本的四个隐含假设在服务里全部不成立：单用户、串行、输入可信、进程与会话同生共死
  • 会话状态必须按 sessionId 隔离，且要意识到放进程内存意味着重启即丢、无法水平扩容
  • 四个接口决定：响应形状、会话标识、鉴权与限流（含单次 token 上限）、错误表达方式
  • 流式接口推流之后无法用状态码报错，必须约定一个流内的 error 事件，并把校验全部前置到第一个字节之前
  • 提供健康检查接口，否则编排系统无法判断实例能不能接流量

  Key points

  • A script's four assumptions all break in a service: single user, serial execution, trusted input, and a process that dies with the session
  • Session state must be keyed by session id, and in-process storage means data is lost on restart and blocks horizontal scaling
  • Four interface decisions: response shape, session identity, auth and rate limiting including a per-call token ceiling, and error semantics
  • A streaming endpoint cannot report errors by status code after the first byte, so define an in-stream error event and move all validation ahead of it
  • Expose a health endpoint, or orchestrators cannot tell whether the instance is ready for traffic
• 把一个 Node 服务打包成 Docker 镜像，Dockerfile 里有哪些关键决定？What are the key decisions in a Dockerfile that packages a Node service?

  国内高频海外高频进阶#docker#deployment#nodejs

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

  1. 这题看着是背步骤，其实考的是「你有没有为构建速度和安全性做过取舍」。把 FROM、COPY、RUN、CMD 顺着念一遍是最没有区分度的答法。
  2. 第一个决定是指令顺序，也是唯一能立刻量化收益的：镜像是逐层叠出来的，某层的输入没变就复用缓存。所以先只拷 package.json 和 lockfile、装完依赖再拷源码——改一行业务代码只让最后两层失效，依赖那层照旧命中；反过来一上来就 COPY 全部，改一个字都要重装依赖。
  3. 第二个是基础镜像钉版本。写 latest 等于让镜像在某天悄悄升到下一个大版本，可复现性当场归零，而可复现正是用容器的全部理由。
  4. 第三个是运行时配置：容器里必须监听 0.0.0.0，只听 127.0.0.1 的话它只在容器内部可达，宿主机做了端口映射也连不上——这个坑在本机跑的时候完全正常，所以特别常见。另外 EXPOSE 只是声明意图，真正开端口的是 docker run 的 -p。
  5. 第四个是安全：用非 root 用户跑业务进程（容器和宿主机共用内核，逃逸后 root 的破坏面大得多），.dockerignore 排除 node_modules（宿主机的二进制在 Linux 容器里跑不起来，还会让构建上下文暴涨）和 .env（密钥打进镜像等于发给每个能拉到镜像的人，运行时用 --env-file 传）。
  6. 可以预期的追问，也是长连接服务最该主动说的一条：CMD 要用数组形式直接起 node，让它当 PID 1。写成 pnpm start 的话 PID 1 是包管理器，docker stop 的 SIGTERM 未必传得到 node，优雅退出代码永远不执行，只能等十秒超时被 SIGKILL——对 SSE 服务，那意味着所有在途的流被硬切。

  How to reason about it · think before answering

  1. It looks like a recipe question, but it tests whether you have ever traded off build speed against security. Reading FROM, COPY, RUN, CMD in order is the least differentiating answer.
  2. The first decision is instruction order, the only one with an immediately measurable payoff. Images are stacked layers and a layer whose inputs are unchanged is reused, so copy the manifest and lockfile first, install, then copy source. Editing one line of code then invalidates only the last two layers instead of forcing a full reinstall.
  3. Second, pin the base image. Using latest means the image silently jumps a major version some morning, which destroys the reproducibility that was the whole reason to containerize.
  4. Third, runtime configuration: bind to 0.0.0.0 inside a container. Binding 127.0.0.1 leaves the service reachable only from inside, so a published port still refuses connections — and it works perfectly on your laptop, which is why it is so common. Also note EXPOSE only documents intent; the port is actually published by docker run -p.
  5. Fourth, security: run as a non-root user, since containers share the host kernel and root widens the blast radius of an escape. Keep node_modules out via .dockerignore (host binaries will not run in a Linux container and the build context balloons) and keep .env out too, passing secrets at runtime with --env-file.
  6. Expect the follow-up, and it is the one a streaming service should volunteer: use the exec-form CMD to launch node directly so it becomes PID 1. With pnpm start, PID 1 is the package manager, SIGTERM from docker stop may never reach node, your graceful shutdown never runs, and the container is SIGKILLed after the timeout — cutting every in-flight SSE stream.

  答题要点

  • 指令顺序决定缓存命中：先拷依赖清单装依赖，再拷源码，改代码不会触发重装依赖
  • 基础镜像钉版本不用 latest，可复现是用容器的全部理由
  • 容器里监听 0.0.0.0；EXPOSE 只是声明，真正开端口靠 docker run -p
  • 用非 root 用户运行；.dockerignore 排除 node_modules 与 .env，密钥运行时用 --env-file 注入
  • CMD 用数组形式直接起 node 让它当 PID 1，SIGTERM 才能传到进程，优雅退出才有效

  Key points

  • Instruction order drives cache hits: copy the manifest, install, then copy source, so code edits do not reinstall dependencies
  • Pin the base image instead of latest — reproducibility is the entire point of containerizing
  • Bind 0.0.0.0 inside the container; EXPOSE only documents intent while docker run -p publishes the port
  • Run as a non-root user, and keep node_modules and .env out via .dockerignore, injecting secrets at runtime
  • Use exec-form CMD to run node as PID 1 so SIGTERM reaches it and graceful shutdown actually executes

D8 为什么 Gateway/Worker 分离；Postgres 表设计（sessions/runs/messages）+ Drizzle

• 什么是无状态服务？它对水平扩展意味着什么？Worker 算不算有状态？What makes a service stateless, what does that mean for horizontal scaling, and are workers stateful?

  国内高频海外高频进阶#stateless#scalability

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

  1. 这题的陷阱是字面理解。很多人答成「不保存任何数据」，那是错的——无状态服务当然会写数据库。区分度在于你能不能给出准确定义。
  2. 准确定义只有一句：无状态指的是**状态不留在处理请求的那个进程身上**，因此任意一台实例都能处理任意一个请求。把它翻译成一个自检问题就很好用：随便杀掉一台实例，有没有任何用户的数据只存在于那台机器上？答「没有」才是无状态。
  3. 再推出水平扩展的三个后果：新实例不需要预热或同步数据，接上负载均衡立刻能干活；任意实例可以随时被杀，滚动发布和抢占式实例才成立；不需要会话粘连，而粘连一旦存在，扩容时的重新分配就会打断老用户的会话。
  4. Worker 那一问要答得有分寸：它持有的不是用户数据，而是一次执行的进度（跑到第几轮、调了哪些工具、后面还会加上一个租约）。用户数据始终在数据库里。所以说它有状态，指的是「手上有活没交代完」，后果是不能随便杀——必须优雅停机，先拒绝新任务再等手头的跑完。
  5. 可以预期的追问：内存缓存算不算破坏了无状态？答案是看丢了会不会出错。纯粹用于加速、丢了只是变慢的缓存不破坏无状态；一旦某个用户的会话只存在于某台机器的内存里，你就已经在偷偷依赖粘连了，扩容那天必然出事。

  How to reason about it · think before answering

  1. The trap is reading the word literally. Many candidates say 'it stores nothing', which is wrong — stateless services write to databases all day. The discriminator is whether you can define it precisely.
  2. One sentence does it: stateless means state does not live in the process handling the request, so any instance can serve any request. Turn it into a self-check: kill a random instance — does any user's data exist only there? Only 'no' is stateless.
  3. Derive three scaling consequences: a new instance needs no warm-up or data sync and starts serving the moment it joins the load balancer; any instance can be killed at will, which is what makes rolling deploys and spot instances viable; and no sticky sessions are needed, whereas stickiness means rebalancing during a scale-up cuts existing conversations.
  4. Answer the worker half carefully: it holds execution progress, not user data — which turn it is on, which tools it called, and later a lease. User data always lives in the database. So 'stateful' here means 'holding unfinished work', and the consequence is that you cannot kill it freely: drain first, refuse new work, let the current run finish.
  5. Expect the follow-up: does an in-memory cache break statelessness? It depends on whether losing it causes wrong behavior. A pure accelerator that only costs latency is fine; the moment a user's session exists only in one machine's memory you are silently relying on stickiness, and the next scale-up will prove it.

  答题要点

  • 无状态的准确含义是状态不留在处理请求的进程里，任意实例都能处理任意请求，而不是「不存数据」
  • 自检方法：随便杀一台实例，是否有用户的数据只存在于那一台上
  • 水平扩展的三个前提：新实例无需预热、任意实例可被随时杀掉、不需要会话粘连
  • Worker 的有状态指的是持有一次执行的进度而不是用户数据，后果是必须优雅停机而不能随便杀
  • 只加速、丢失只降速的缓存不破坏无状态；承载唯一副本的内存数据等于隐式的会话粘连

  Key points

  • Stateless means the state does not live in the request-handling process, so any instance serves any request — not that nothing is stored
  • Self-check: kill any instance and ask whether any user's data existed only there
  • Three scaling prerequisites: no warm-up, any instance disposable, no sticky sessions
  • Workers are stateful in the sense of holding run progress, not user data, so they need graceful drain rather than a hard kill
  • A pure accelerator cache is fine; in-memory data that is the only copy is implicit stickiness
• sessions / runs / messages 这三张表你会怎么设计主键与索引？为什么不用自增主键？How would you design primary keys and indexes for sessions, runs and messages, and why avoid auto-increment ids?

  国内高频海外高频进阶#database#schema-design#idempotency

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

  1. 这题看着像八股，其实每一个选择背后都有一个具体约束。判断标准是：你能不能为每个决定说出「不这么做会发生什么」。
  2. 先讲为什么是三张表而不是一张：粒度不同。会话是长期容器，一次执行有生命周期且可能失败重来，消息是不可变事实。少了「一次执行」这一层，你就没有地方回答「这次跑完没有」「该不该重试」「这轮花了多少钱」。
  3. 主键选文本型的应用侧 id（UUID 或 ULID），理由是接入层必须在写库之前就把 id 放进 202 响应体返回给客户端；自增主键要等数据库插完才知道值，那次往返就被卡在用户的等待路径上，而且多实例无法预分配。附带好处是将来分库分表不用重编号。
  4. 索引按查询路径建，不按直觉建：按用户拉会话列表要 sessions 的 user_id 索引，按会话拉历史要 messages 的 session_id 索引，外键列本身要索引否则删除父行会全表扫。多余的索引不是免费的，每个都让写入变慢。
  5. 两条唯一约束才是这套设计的灵魂：runs 的幂等键唯一，挡住重复投递；messages 的「run id 加序号」复合唯一，既保证同一次执行的输出顺序稳定，又让断线重连可以按序号幂等回放。序号要从 0 开始、连续、不跳号，否则续传就找不到断点。
  6. 可以预期的追问：ULID 和 UUIDv4 选哪个？答 ULID 或 UUIDv7——它们按时间有序，插入时集中在 B 树右端，不像 UUIDv4 那样随机分布导致页分裂和缓存命中率下降。这个细节能直接体现你关心过写入性能。

  How to reason about it · think before answering

  1. It looks like a trivia question, but every choice sits on a concrete constraint. The test is whether you can say what breaks if you choose otherwise.
  2. Start with why three tables rather than one: the grains differ. A session is a long-lived container, a run has a lifecycle and can fail and be retried, a message is an immutable fact. Without the run layer there is nowhere to answer 'did this finish', 'should we retry', or 'what did this turn cost'.
  3. Use text primary keys generated in the application (UUID or ULID), because the gateway must put the id into the 202 response before the row is written. Auto-increment ids are only known after the insert, which parks a round trip in the user's wait path and cannot be pre-allocated across instances. A bonus is that sharding later needs no renumbering.
  4. Index by query path, not by instinct: sessions need an index on user_id to list a user's conversations, messages need one on session_id to load history, and foreign key columns need indexes or deleting a parent row triggers a full scan. Extra indexes are not free — each one slows writes.
  5. The two unique constraints carry the design: a unique idempotency key on runs blocks duplicate delivery, and a composite unique on run id plus sequence in messages both fixes output ordering for one run and lets a reconnect replay idempotently by sequence. The sequence must start at zero and never skip, otherwise resume cannot find the cut point.
  6. Expect the follow-up: ULID or UUIDv4? Choose ULID or UUIDv7 — they are time-ordered so inserts land at the right edge of the B-tree, whereas random UUIDv4 scatters writes, splits pages and hurts cache hit rates. Mentioning this shows you have watched write performance.

  答题要点

  • 三张表对应三种粒度：会话是长期容器、run 是一次有生命周期的执行、message 是不可变事实；少了 run 就无法回答是否跑完、该不该重试、花了多少钱
  • 主键用应用侧生成的文本 id，因为 Gateway 要在写库之前把 runId 放进 202 响应里，自增主键必须等插入完成且无法跨实例预分配
  • 索引按实际查询路径建：sessions 的 user_id、messages 的 session_id、以及外键列；多余索引会拖慢写入
  • 两条唯一约束是灵魂：runs 的幂等键唯一挡重复投递，messages 的「run id 加序号」复合唯一保证保序与幂等回放
  • id 优先选 ULID 或 UUIDv7 这类时间有序的方案，避免随机 UUID 造成的页分裂与缓存失效

  Key points

  • Three tables for three grains: a long-lived session, a run with a lifecycle, and immutable messages; without runs you cannot answer completion, retry or cost questions
  • Application-generated text ids, because the gateway must return the run id in the 202 before the write, and auto-increment ids cannot be pre-allocated across instances
  • Index the real query paths — user_id on sessions, session_id on messages, plus foreign key columns; extra indexes slow writes
  • Two unique constraints carry the design: a unique idempotency key on runs, and a composite unique on run id plus sequence in messages for ordering and idempotent replay
  • Prefer time-ordered ids such as ULID or UUIDv7 over random UUIDv4 to avoid page splits and cache misses

D9 Redis Streams 消息总线：XADD/XREADGROUP/XACK/XAUTOCLAIM、consumer group、毒消息

• XACK 和 XAUTOCLAIM 分别解决什么问题？XACK 放在业务处理之前和之后有什么区别？What problems do XACK and XAUTOCLAIM each solve, and what changes if you XACK before instead of after doing the work?

  国内高频海外高频进阶#message-bus#redis-streams#error-handling

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

  1. 题眼在后半句。前半句背文档就能答，后半句在考你知不知道 ack 的时机直接决定了整个系统的投递语义——答不出这一点，面试官会判定你没在生产里管过队列。
  2. 先把两个命令的分工说清：XACK 是「销号」，把消息从 pending 清单里删掉，代表这件事真的做完了；XAUTOCLAIM 是「接手」，把闲置超过阈值的 pending 消息改判给另一个消费者，代表原来那个人可能已经死了。一个负责正常收尾，一个负责异常兜底。
  3. 然后回答时机问题，用一句话定性：先 ack 再干活是 at-most-once，先干活再 ack 是 at-least-once。前者进程一崩消息就人间蒸发，pending 清单里查不到、XAUTOCLAIM 也捡不回来；后者最坏是重复执行，而重复可以用幂等挡掉，丢单挡不掉。所以除了埋点日志这类丢一条无所谓的场景，一律先干活再 ack。
  4. 补一个大多数人漏掉的点：处理失败时正确的动作是**什么都不做**，让消息留在 pending 里等 XAUTOCLAIM。很多人会在 catch 里顺手 ack 掉，那等于把失败的消息静默丢弃，比不重试更糟——因为你连丢了什么都不知道。
  5. 再补一条 XAUTOCLAIM 的参数取舍：空闲阈值要大于「一次正常处理的耗时上限」。给太小会把还在正常处理的消息抢走，同一件事被跑两遍；给太大则故障恢复变慢。但要说清，调大阈值只降低重复概率，不消灭重复，兜底始终是消费端的唯一约束。
  6. 可以预期的追问：为什么用 XAUTOCLAIM 而不是 XCLAIM？答：XCLAIM 要你先 XPENDING 查出候选 id 再点名认领，两步之间还有竞态；XAUTOCLAIM 自己扫 pending 并返回游标，一条命令搞定，是 Redis 6.2 之后的推荐做法。

  How to reason about it · think before answering

  1. The hinge is the second half. The first half is documentation; the second asks whether you know that ack timing decides the delivery semantics of the whole system.
  2. Split the two commands: XACK clears a message from the pending list, meaning the work is genuinely finished; XAUTOCLAIM reassigns a pending message that has been idle past a threshold, meaning its previous owner may be dead. One is the normal path, the other is the failure path.
  3. Then answer the timing question categorically: ack-then-work is at-most-once, work-then-ack is at-least-once. In the first, a crash makes the message vanish — it is not in the pending list, so XAUTOCLAIM cannot recover it. In the second, the worst case is duplicate execution, and duplicates can be blocked by idempotency while lost work cannot. Always work first, except for fire-and-forget telemetry.
  4. Add the point most people miss: on failure the correct action is to do nothing and leave the message pending for XAUTOCLAIM. Acking inside the catch block silently discards failures, which is worse than no retry because you no longer know what you lost.
  5. Add the parameter trade-off: the idle threshold must exceed the worst-case normal processing time. Too small and a healthy in-flight message gets stolen and executed twice; too large and recovery is slow. Be explicit that tuning it only lowers the probability of duplicates — the real backstop is a uniqueness constraint on the consumer side.
  6. Expect: why XAUTOCLAIM rather than XCLAIM? XCLAIM needs an XPENDING scan first and then a named claim, with a race in between; XAUTOCLAIM scans and returns a cursor in one command, and is the recommended approach since Redis 6.2.

  答题要点

  • XACK 负责正常收尾：把消息从 pending 清单里销号，代表这件事真的做完了；重复 ack 返回 0，天生幂等
  • XAUTOCLAIM 负责异常兜底：把闲置超过阈值的 pending 消息改判给另一个消费者，解决「消费者死了它手上的消息怎么办」
  • 先 ack 再干活是 at-most-once，崩溃就丢单；先干活再 ack 是 at-least-once，最坏是重复，可以用幂等挡
  • 处理失败时不要 ack，让消息留在 pending 里等接手；在 catch 里顺手 ack 等于静默丢弃失败
  • 空闲阈值要大于正常处理耗时的上限，但调大只降低重复概率，兜底仍是消费端唯一约束

  Key points

  • XACK is the happy-path close-out: it clears the message from the pending list; repeat acks return 0, so it is naturally idempotent
  • XAUTOCLAIM is the failure backstop: it reassigns pending messages idle past a threshold, answering 'what happens to work held by a dead consumer'
  • Ack-before-work is at-most-once and loses work on a crash; work-before-ack is at-least-once and at worst duplicates, which idempotency can absorb
  • Never ack on failure — leave the message pending for takeover; acking in the catch block silently discards failures
  • The idle threshold should exceed worst-case processing time, but tuning it only reduces duplicates; uniqueness constraints are the real guarantee
• Redis Streams 和 Kafka 该怎么选？什么情况下 Streams 明显不够用？How do you choose between Redis Streams and Kafka, and when is Streams clearly not enough?

  国内高频海外高频进阶#message-bus#redis-streams#architecture

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

  1. 这题的坏答案是「看数据量」。吞吐从来不是第一判据——单机 Redis 每秒几万条 XADD 毫无压力，绝大多数业务的量级根本碰不到天花板。答成「量小用 Streams、量大用 Kafka」会被认为没做过选型。
  2. 换成两个真正的判据来推：一、这些消息需要保留多久；二、会不会有第二类消费方。生命周期是「执行一次就没用了」、且只有执行层这一个消费方，Streams 完全够用，还省掉一整套运维；需要「三个月内任意时间点重放」、或者同一份数据要同时喂给实时执行、离线数仓、风控三条链路，那就该上 Kafka。
  3. 再补三条结构性差异：Streams 是内存为主、保留全靠你自己 MAXLEN 或 XTRIM，Kafka 是磁盘顺序写、保留几周是常态；Streams 一个组里加多少消费者都行，Kafka 的消费者数受分区数限制，多了就有人空转；顺序保证的粒度不同，Streams 是单条流内有序而组内分配随机，Kafka 是同 key 落同分区、分区内有序。
  4. 然后主动说出那条最能体现深度的话：Redis 的持久化是有损的。AOF 默认每秒刷盘，最坏丢最后一秒的写入；主从异步复制，故障切换时未同步的消息会消失。所以用 Streams 时架构上必须有一个真相之源——本课是 Postgres 的 runs 表，流只是触发器，丢了消息那个 run 还停在 pending，补投任务会把它捡回来。把总线当唯一数据源是最危险的误用。
  5. 结论落成一句可复用的判断：Streams 适合「触发执行」，Kafka 适合「数据管道」。前者的消息是一次性的命令，后者的消息是需要被多方反复读取的事实。
  6. 可以预期的追问：那 RabbitMQ、SQS 呢？答：RabbitMQ 强在复杂路由和延迟队列（Streams 没有原生延迟投递，要自己带「下次可执行时间」重投）；SQS 强在零运维，代价是没有回放、也没有严格顺序（FIFO 队列另算）。把判据说成「保留时长、消费方数量、路由复杂度、运维预算」四条，比背产品参数强得多。

  How to reason about it · think before answering

  1. The bad answer is 'it depends on volume'. Throughput is never the first criterion — a single Redis node handles tens of thousands of XADDs per second, and most workloads never approach that ceiling. 'Small volume Streams, large volume Kafka' reads as never having run a real evaluation.
  2. Use two real criteria instead: how long the messages must be retained, and whether a second class of consumer will appear. If a message is useless once executed and the execution layer is the only consumer, Streams is plenty and saves an entire operational surface. If you need replay from any point in the last three months, or the same data must feed real-time execution, an offline warehouse and a risk engine, choose Kafka.
  3. Add three structural differences: Streams is memory-first with retention you enforce yourself via MAXLEN or XTRIM, while Kafka does sequential disk writes and keeps weeks by default; a Streams group takes any number of consumers, while Kafka consumers are capped by partition count and extras idle; ordering granularity differs — Streams orders a single stream but dispatches randomly within a group, Kafka pins a key to a partition and orders within it.
  4. Then volunteer the line that shows real depth: Redis persistence is lossy. AOF fsyncs once per second by default, so the last second of writes can vanish, and replication is asynchronous, so a failover can drop unreplicated messages. Using Streams therefore requires a source of truth elsewhere — here the Postgres runs table, with the stream acting only as a trigger; a lost message leaves the run pending and a sweeper republishes it. Treating the bus as the only datastore is the dangerous misuse.
  5. Land on a reusable rule: Streams suits triggering work, Kafka suits data pipelines. One carries one-shot commands, the other carries facts that many parties re-read.
  6. Expect: what about RabbitMQ or SQS? RabbitMQ wins on complex routing and delayed delivery (Streams has no native delay, you republish with a next-eligible timestamp); SQS wins on zero operations at the cost of replay and strict ordering (FIFO queues aside). Framing the criteria as retention, number of consumers, routing complexity and operational budget beats reciting product specs.

  答题要点

  • 第一判据不是吞吐，是「消息要保留多久」和「会不会有第二类消费方」
  • 只有执行层一个消费方、消息执行完即失效：Streams 够用，且大概率你已经有 Redis，零新增运维
  • 需要长期保留与任意时间点回放、或多条下游链路共用同一份数据：选 Kafka
  • 结构差异：Streams 内存为主、保留靠自己裁剪、组内分配随机；Kafka 磁盘顺序写、按 key 分区且分区内有序、消费者数受分区限制
  • Redis 持久化有损（AOF 每秒刷盘、异步复制），所以真相之源必须是数据库，流只当触发器，靠补投任务兜底
  • 一句话判断：Streams 适合触发执行，Kafka 适合数据管道

  Key points

  • The first criterion is not throughput but retention length and whether a second class of consumer will exist
  • One consumer class and messages that expire on execution: Streams is enough, and you probably already run Redis
  • Long retention with arbitrary replay, or one dataset feeding several downstream pipelines: pick Kafka
  • Structural differences: Streams is memory-first with self-managed trimming and random in-group dispatch; Kafka is sequential-disk, key-partitioned with in-partition ordering, and caps consumers at partition count
  • Redis persistence is lossy (per-second AOF fsync, async replication), so the database must be the source of truth with the stream as a trigger plus a republish sweeper
  • One-line rule: Streams triggers work, Kafka moves data
• 一条消息反复处理失败怎么办？请设计一个毒消息隔离机制。What do you do with a message that keeps failing? Design a poison-message isolation mechanism.

  国内高频海外高频进阶#message-bus#error-handling#reliability

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

  1. 这题在考你有没有踩过「一条坏消息拖垮整条流」。判断标准很简单：你的回答里有没有出现一个具体的阈值和一个具体的落地位置，没有就是在讲概念。
  2. 先把故障模式说清楚：按 at-least-once 的规矩，失败就不 ack、留在 pending 等重投，于是一条无论谁来都会失败的消息进入死循环——投递、失败、闲置超时、被接手、再失败。它自己永远好不了，还持续占用消费者的处理能力。
  3. 然后给机制，三个动作缺一不可：一、判定依据用 pending 清单自己记的投递次数，不要另建计数表；二、超过阈值（本课固定 3 次）就把消息搬到一条死信流，字段里带上原始消息 id、投递次数和失败原因；三、对原流 XACK，同时把这次执行标成失败并写入错误原因。只搬不 ack，它还躺在 pending 里等着被接手；只 ack 不搬，消息和失败原因一起消失，用户永远停在「正在思考」。
  4. 阈值的取值要给出权衡：定 1 会让一次网络抖动就把本来能成功的消息判死；定 10 会在一条必死的消息上浪费十次执行的钱和时间。3 次配合每次之间的空闲阈值，足够熬过绝大多数瞬时故障。
  5. 还要主动说出一个缺口：Redis Streams 没有原生的指数退避，重投时机由空闲阈值决定。想要退避就得自己把消息重新投递并带上「下次可执行时间」，那已经是在实现延迟队列了——这一条能体现你知道 Streams 的边界在哪。
  6. 可以预期的追问：死信流建完就完了吗？答：不。死信条数必须接进告警，它从 0 变成非 0 通常意味着有一类输入你的代码处理不了，是真 bug 而不是运气差；还要留一个重放入口——把死信里的字段原样投回原流即可，因为幂等键还在，重放不会产生重复执行。见过团队把死信建起来半年没打开过，那等于把故障静音了。

  How to reason about it · think before answering

  1. This question probes whether you have ever watched one bad message stall an entire stream. The test is simple: does your answer contain a concrete threshold and a concrete place where isolation happens? If not, you are talking theory.
  2. Describe the failure mode first: under at-least-once you do not ack on failure, so the message stays pending and gets redelivered. A message that fails for everyone therefore loops forever — delivered, failed, idle timeout, claimed, failed — never recovering while continuously consuming worker capacity.
  3. Then give the mechanism, three actions and all of them required. One, use the delivery count the pending list already tracks rather than building a counter table. Two, past the threshold (three deliveries in this course) move the message to a dead-letter stream carrying the original id, delivery count and failure reason. Three, XACK the original stream and mark the run failed with the error recorded. Moving without acking leaves it pending for another takeover; acking without moving makes both the message and its reason disappear, leaving the user stuck on 'thinking'.
  4. Justify the threshold: one delivery kills messages that a single network blip would have let through; ten wastes ten executions of money and time on a message that can never succeed. Three deliveries, spaced by the idle threshold, survives almost all transient faults.
  5. Volunteer a limitation: Redis Streams has no native exponential backoff — redelivery timing is governed by the idle threshold. Backoff requires republishing the message with a next-eligible timestamp, which means building a delay queue yourself. Naming this shows you know where Streams ends.
  6. Expect: is creating the dead-letter stream the end of it? No. Its depth must be alerted on, since going from zero to non-zero usually means a class of input your code cannot handle — a real bug, not bad luck. Keep a replay path too: republish the stored fields back to the original stream, and because the idempotency key is preserved, replay cannot cause duplicate execution. Teams that build a dead-letter stream and never open it have simply muted their failures.

  答题要点

  • 故障模式：at-least-once 下失败不 ack，一条永远失败的消息会无限重投并持续占用消费者
  • 判定依据用 pending 清单里记的投递次数，不需要另建计数表
  • 阈值固定 3 次：定 1 会误杀瞬时故障，定 10 会在必死消息上浪费十次执行成本
  • 隔离动作三件缺一不可：搬到死信流（带原始 id、投递次数、失败原因）、对原流 XACK、把这次执行标成失败并写入原因
  • Redis Streams 没有原生指数退避，重投时机由空闲阈值决定，要退避得自己实现延迟投递
  • 死信流要接告警并留重放入口；幂等键还在，重放不会导致重复执行

  Key points

  • Failure mode: under at-least-once you do not ack on failure, so an always-failing message is redelivered forever and keeps consuming worker capacity
  • Use the delivery count already tracked in the pending list rather than a separate counter table
  • Fix the threshold at three deliveries: one kills transient failures, ten wastes ten executions on a message that can never succeed
  • Isolation needs all three actions: move to a dead-letter stream with original id, delivery count and reason; XACK the original stream; mark the run failed with the error stored
  • Redis Streams has no native exponential backoff — redelivery timing follows the idle threshold, so backoff means implementing delayed republishing yourself
  • Alert on dead-letter depth and keep a replay path; the idempotency key survives, so replay cannot duplicate execution

D10 分片与租约：userId 哈希→shard、SET NX + TTL + Lua 续约、同用户顺序、handoff

• 租约为什么必须配合 TTL？续约为什么要用 Lua 脚本，而不是先 GET 再 PEXPIRE？Why must a lease carry a TTL, and why renew it with a Lua script instead of GET followed by PEXPIRE?

  国内高频海外高频进阶#lease#redis#atomicity

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

  1. 这题有两个考点，第二个才是区分度。第一个考点其实是在问「你知不知道租约和分布式锁不是一回事」——先把这条说清：锁的语义是互斥（我持有、你等待，我主动 release 你才拿得到），租约的语义是带过期时间的所有权（持有者不 release 也会失效，因为它可能永远不会回来了）。
  2. 由此推出 TTL 的必要性：持有者会被 kill -9、会断网、会整台机器掉电，它没有机会归还。没有 TTL 就是一把永不释放的锁，那个 shard 从此永久荒废，只能靠人工介入。TTL 的全部意义是「不需要任何人干预，所有权会自己失效」。
  3. 顺手说出 TTL 的取舍，证明你调过：太短则一次垃圾回收停顿或网络抖动就丢租约，shard 反复易主、用户会话来回搬家；太长则真死了之后要等满一个 TTL 才有人接手。常见口径是 TTL 30 秒、续约间隔取 TTL 的三分之一（10 秒），这样能连续失败两次而不丢租约。
  4. 第二个考点是原子性。两步写法的失败时间线要具体讲出来：GET 返回「是我的」，紧接着的两毫秒里租约恰好到期被 Redis 删除、另一个 worker SET NX 抢到，然后你的 PEXPIRE 执行成功——你续的是对手的租约，而自己还以为持有。如果第二步用的是 SET 而不是 PEXPIRE，你还会把对手的名字覆盖成自己，两个进程一起动手。
  5. 结论要落到通用原理上：检查和改动必须是一个不可分割的动作（compare-and-swap）。Redis 单线程执行命令，一整段 EVAL 对其他客户端就是一个原子步骤，所以 Lua 在这里不是为了性能，是为了把 GET 和 PEXPIRE 粘成一条。等价手段还有 Redis 函数、或用 WATCH 加事务重试，但 Lua 最直接。
  6. 可预期的追问：续约返回 0 应该怎么办？答「立刻放手」——把这个 shard 从持有集合里删掉、停止取消息、手上那条没做完的不许再写。返回 0 只打一行警告日志然后继续跑，是脑裂最常见的来源。再加一条自杀规则：距上次成功续约超过 TTL 的三分之二就主动全部放手。

  How to reason about it · think before answering

  1. There are two things being tested and the second is the discriminator. The first is really 'do you know a lease is not a lock': a lock means mutual exclusion (I hold, you wait, you get it when I release), while a lease means ownership with an expiry (it lapses even if the holder never releases, because the holder may never come back).
  2. That gives you the necessity of the TTL: holders get kill -9'd, lose the network, lose the whole machine — they never get to hand anything back. Without a TTL you have a lock that is never released and a shard that is permanently orphaned until a human intervenes.
  3. Volunteer the TTL trade-off to show you have tuned this: too short and a GC pause or a network blip costs you the lease, so shards flap and sessions keep migrating; too long and a genuinely dead worker's shards sit idle for a full TTL. A common setting is a 30 second TTL renewed every 10 seconds (one third), which tolerates two consecutive renewal failures.
  4. The second point is atomicity, and you should spell out the failing interleaving: GET says the lease is yours, then within two milliseconds it expires, Redis drops it, another worker wins it with SET NX, and your PEXPIRE succeeds — you have just extended your rival's lease while believing you still hold the shard. If step two is SET rather than PEXPIRE you also overwrite their owner field and both processes start working.
  5. Land on the general principle: check-and-mutate must be indivisible (compare-and-swap). Redis executes commands single-threaded, so one EVAL is a single atomic step to every other client — Lua here is not about performance, it is about fusing GET and PEXPIRE. Redis Functions or WATCH plus a transaction retry are equivalent, but Lua is the most direct.
  6. Expect the follow-up: what should a renewal returning 0 do? Let go immediately — drop the shard from the held set, stop consuming, and refuse to write the in-flight item. Logging a warning and carrying on is the most common source of split brain. Add a self-kill rule too: if the last successful renewal is older than two thirds of the TTL, release everything.

  答题要点

  • 租约不是锁：锁是互斥，租约是带过期时间的所有权；持有者可能永远不会回来，所以所有权必须能自己失效
  • 没有 TTL 就是永不释放的锁，持有者被 kill 之后那个 shard 永久荒废
  • TTL 30 秒、续约间隔 10 秒（TTL 的三分之一），留出连续两次续约失败的余量
  • 两步续约的窗口里租约可能已易主，你的 PEXPIRE 会替对手延长任期，而自己仍以为持有
  • Lua 的作用是把「比较持有者」和「续期」粘成一个原子步骤，不是为了性能；续约返回 0 必须立刻放手

  Key points

  • A lease is not a lock: locks give mutual exclusion, leases give ownership with an expiry, because the holder may never return
  • Without a TTL you have a never-released lock and a permanently orphaned shard once the holder is killed
  • A 30 second TTL renewed every 10 seconds leaves headroom for two consecutive renewal failures
  • In the two-step window the lease may already have changed hands, so your PEXPIRE extends a rival's term while you still think you hold it
  • Lua fuses the ownership check and the extension into one atomic step; a renewal returning 0 means let go immediately
• 在一个多 worker 的 Agent 服务里，怎么保证同一个用户的消息严格按顺序被处理？In a multi-worker agent service, how do you guarantee that one user's messages are processed in strict order?

  国内高频海外高频进阶#ordering#sharding#distributed-systems

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

  1. 这题是系统设计小题，考的是你能不能把「顺序」拆成分层的保证，而不是丢一个中间件名字。只答「用 Kafka 按 key 分区」不算错，但没有回答「分区之后进程内怎么办」，会被追着问。
  2. 拆法是从消息进入系统到产生副作用，逐层点出谁在保顺序，一共四层。第一层入队有序：接入层落库时给同一会话的消息发连续 seq，并按 seq 投递，总线对同一条流是追加有序的，这层几乎免费。第二层消费者唯一：同一个分片同一时刻只有一个 worker 在读，靠租约实现——这是跨进程的那一半。
  3. 第三层进程内串行：同一个分片内不能并发处理两条消息。这一层最容易被自己破坏——为了提高吞吐把一批消息丢进 Promise.all 或线程池，顺序就在自己的代码里丢掉了。要明确说出「租约保住跨进程的顺序，await 保住进程内的顺序，缺一不可」。第四层在途优先：前任 worker 挂掉时手上可能有一条已领取但没确认的消息，接管者必须先把它 claim 回来再读新消息，否则新消息会插到旧消息前面。
  4. 紧接着说串行的代价，这是面试官判断你有没有上过线的地方：串行意味着一个用户的慢请求会挡住同一个分片上其他用户的消息，一次 20 秒的模型调用能让这个 worker 名下的几十个分片全部停摆。正确做法是按分片并行、分片内串行——每个持有的分片各起一条独立处理链。并行的单位是分片，不是消息。
  5. 主动划边界：这套机制只保证同一个用户的顺序，不保证跨用户的全局顺序。全局有序需要把并行度压到 1，那就没有分布式可谈了。顺序性和并行度是一对反比，分片的意义就是把「必须有序」的范围缩到刚好够用的最小值。
  6. 可预期的追问一：不用租约行不行？可以，Kafka 按 key 分区、或者让 Gateway 直连固定 worker（粘性路由）都能得到亲和性，但代价分别是分区数难改、以及 worker 挂掉时需要额外的故障转移机制——租约恰好把故障转移也一并解决了。追问二：能不能干脆让业务对乱序免疫？部分可以，比如把「追加消息」设计成幂等且可交换的写入，但只要存在不可逆的副作用（退款、发货），顺序就必须保。

  How to reason about it · think before answering

  1. This is a small system-design question testing whether you can decompose ordering into layered guarantees rather than naming a middleware. 'Partition by key in Kafka' is not wrong, but it leaves 'and inside the process?' unanswered, which is exactly where they will push.
  2. Decompose it along the path from ingress to side effect, four layers. One, ordered ingress: the gateway assigns consecutive seq numbers per session on write and publishes in seq order; a single stream is append-ordered, so this layer is nearly free. Two, single consumer: only one worker reads a given shard at a time, enforced by the lease — that is the cross-process half.
  3. Three, in-process serialization: no two messages from the same shard may be handled concurrently. This is the layer people break themselves, by dropping a batch into Promise.all or a thread pool to raise throughput. Say it explicitly: the lease preserves order across processes, await preserves it inside one. Four, in-flight first: a killed predecessor may hold a delivered but unacknowledged message, so the successor must claim it back before reading anything new, otherwise a newer message jumps ahead of an older one.
  4. Then name the cost of serialization, which is where they judge whether you have shipped this: a single slow request blocks other users on the same shard, and one 20-second model call can stall every shard that worker owns. The right shape is parallel across shards, serial within a shard — one independent processing chain per held shard. The unit of parallelism is the shard, not the message.
  5. Volunteer the boundary: this only guarantees per-user order, never a global order across users. Global ordering requires parallelism of one, which defeats the point. Ordering and parallelism trade off directly, so sharding exists to shrink the 'must be ordered' scope to the smallest useful unit.
  6. Expect two follow-ups. Could you skip leases? Yes — Kafka key partitioning or sticky routing from the gateway to a fixed worker also gives affinity, at the cost of rigid partition counts or of needing a separate failover mechanism when a worker dies; the lease happens to solve failover at the same time. Could the business simply tolerate reordering? Partly, if appends are idempotent and commutative, but any irreversible side effect such as a refund or a shipment forces you to preserve order.

  答题要点

  • 把顺序拆成四层：入队有序（连续 seq）、消费者唯一（租约）、进程内串行（逐条 await）、在途消息优先被接管者 claim 回来
  • 租约保住跨进程的顺序，await 保住进程内的顺序，缺一不可——用 Promise.all 提吞吐会当场毁掉顺序
  • 并行的单位是分片不是消息：每个持有的分片各起一条独立处理链，否则一次慢调用会拖停这个 worker 的全部分片
  • 只保证同一用户的顺序，不保证跨用户全局有序；顺序性和并行度是反比，分片就是把有序范围缩到最小
  • 替代方案是 Kafka 按 key 分区或粘性路由，但它们不自带故障转移；只要存在不可逆副作用，顺序就必须保

  Key points

  • Decompose ordering into four layers: ordered ingress with consecutive seq, a single consumer per shard via the lease, in-process serialization with await, and claiming the predecessor's in-flight message first
  • The lease preserves order across processes and await preserves it within one — reaching for Promise.all to raise throughput destroys it
  • The unit of parallelism is the shard, not the message: one chain per held shard, or a single slow call stalls every shard that worker owns
  • Only per-user order is guaranteed, never a global order; ordering trades off against parallelism, so sharding shrinks the ordered scope
  • Alternatives are Kafka key partitioning or sticky routing, but neither brings failover; any irreversible side effect makes ordering mandatory

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

• 多个客户端同时订阅同一次执行的流式输出，怎么保证每个客户端都收到完整且有序的内容？Several clients subscribe to the same run's streaming output at once. How do you guarantee each of them receives the full content in order?

  国内高频海外高频进阶#sse#ordering#fan-out

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

  1. 题眼有两个词：完整、有序。很多人只答有序，漏掉完整——而「完整」那一半恰好是最容易设计错的，因为它取决于你用了哪种读法。
  2. 先给一句能定调的判断：一次执行是执行的单位，一条连接是观看的单位，两者不是一对一。手机和电脑同开、两个标签页、重连瞬间新旧连接并存，都会让同一次执行上挂着多条流。想清楚这句话，「谁先连谁独占」这种锁的方案就自然被排除了。
  3. 接着点出「完整」的真正机关：广播读法与消费组是两种语义。消费组是分摊，一条消息只给一个消费者；这里要的是广播，每个订阅者都要看到全部。用消费组做扇出，结果就是两条连接各拿到半段话——这是这道题最常见的错误答案。
  4. 再答「有序」：每个片段带一个从 0 开始、连续、不跳号的序号，写进流；接收侧维护「下一个该交付的号」，小于它的丢弃，大于它的先入缓冲，连号了再批量推出去。序号同时写进 SSE 的 id 字段，客户端不用另记一套账。
  5. 然后是必须主动说的工程代价：缓冲要有上限。如果 5 号迟迟不到，6 号往后全在内存里排队，一万条连接同时这样就是一次内存事故。做法是给缓冲设条数上限和等待上限，超时就从库里补读，补不到就发 error 让客户端重连——能等，但不能无限等。
  6. 可以预期的追问：扇出实现怎么选？两种——每条连接各自去读一遍流（简单，代价是同一批数据被读 N 次），或进程内只读一次再广播给本地订阅者（省读取，但要维护订阅者表、要处理最后一个订阅者离开，跨实例仍要各读一次）。判据是每次执行的平均订阅者数，多数产品接近 1，那就选前者，别为不存在的规模提前写一层。

  How to reason about it · think before answering

  1. Two words carry the question: complete and ordered. Most candidates answer only ordering and drop completeness — which is the half that is easy to get structurally wrong, because it depends on which read primitive you pick.
  2. Set the frame first: a run is the unit of execution, a connection is the unit of viewing, and they are not one-to-one. Phone plus laptop, two browser tabs, or the overlap window during a reconnect all put multiple streams on one run. Once that is clear, 'first connection wins the lock' schemes fall away on their own.
  3. Name the trap in 'complete': broadcast reads and consumer groups are different semantics. A consumer group divides work — each message goes to exactly one consumer — while here every subscriber must see everything. Using a consumer group for fan-out gives you two connections each holding half the answer, and that is the classic wrong answer here.
  4. Then ordering: every chunk carries a sequence number starting at 0, contiguous, never skipping, and is written to the stream. The reader keeps a 'next to deliver' cursor, discards anything below it, buffers anything above it, and flushes contiguous runs. Put the same number in the SSE id field so the client keeps no separate bookkeeping.
  5. Volunteer the cost: the reorder buffer needs bounds. If chunk 5 is late, 6 onward pile up in memory, and ten thousand connections doing that is an outage. Cap the buffer size and the wait, then backfill the gap from the database, and if that fails emit an error event and let the client reconnect. Wait, but never wait forever.
  6. Expect the fan-out follow-up: either every connection reads the stream itself (simple, at the cost of reading the same data N times) or one read per process broadcast to local subscribers (fewer reads, but you now own a subscriber registry, teardown when the last one leaves, and still one read per instance). Decide by average subscribers per run — usually close to one, so take the simple path.

  答题要点

  • 一次执行是执行单位、一条连接是观看单位，两者不是一对一，不需要「谁先连谁独占」的锁
  • 输出流必须用广播读法而不是消费组：消费组是分摊，会让两条连接各拿到半段话
  • 每个片段带从 0 开始、连续、不跳号的序号，接收侧按序交付：小于当前号丢弃、大于当前号入缓冲、连号批量推
  • 序号同时写进 SSE 的 id 字段，客户端不必自己记账，也是重连续号的依据
  • 缓冲必须有条数与时间上限，超时从库里补读，补不到就发 error 让客户端重连

  Key points

  • A run is the unit of execution and a connection is the unit of viewing; they are not one-to-one, so no first-wins lock is needed
  • Read the output stream as a broadcast, not through a consumer group — a group divides messages and leaves each connection with half the answer
  • Tag every chunk with a contiguous sequence starting at 0; the reader discards older, buffers newer, and flushes contiguous ranges
  • Mirror that sequence into the SSE id field so clients need no extra bookkeeping and can resume from it
  • Bound the reorder buffer by size and time, backfill gaps from the database, and fall back to an error event plus reconnect
• 用户在 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 工具

• pgvector 和专用向量数据库相比，优劣分别是什么？你会怎么选？How does pgvector compare with a dedicated vector database, and how would you choose?

  国内高频海外高频进阶#vector-database#pgvector#architecture

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

  1. 这题考的是选型判断力，不是产品参数背诵。开口就报「Milvus 支持分布式、Qdrant 过滤更强」是最没有区分度的答法——面试官想知道你按什么判据选，以及你有没有算过运维成本。
  2. 先给三个提问维度，把选型变成可推导的：数据量到什么量级、要不要和业务表在同一个事务里提交、过滤条件复不复杂。这三问能覆盖绝大多数真实场景。
  3. pgvector 的赢面几乎全在后两问上：记忆表和业务表在同一个库，写记忆和更新执行记录可以放进同一个事务；按用户过滤就是普通 where 条件；备份、监控、连接池、迁移工具全部复用。**多一个有状态服务的运维成本，通常比向量检索的性能更早成为瓶颈**——这句话最能体现你上过线。
  4. 再诚实地说它的天花板：单表到千万级向量时 HNSW 索引构建吃内存、写入放大明显，ANN 与元数据过滤的融合不如专用库，水平扩展只能靠 Postgres 自己那一套。不肯说缺点的人会被认为在推销。
  5. 结论要能写死：百万级以内、需要和业务表一起过滤或同事务提交、团队人手紧，用 pgvector；上千万条、检索本身就是主要负载、有专人维护，上专用库。别在第一天就选专用库。
  6. 可以预期的追问：以后想换库，迁移成本大不大？答案会让很多人意外——换库不用重算 embedding，向量是模型产出的，跟存它的库无关，导出导入即可，成本主要在双写和灰度。真正要全量重算的是换 embedding 模型，那才是硬锁定。

  How to reason about it · think before answering

  1. This is a judgment question, not a feature-recital. Opening with 'Milvus does sharding, Qdrant filters better' carries no signal — they want your decision criteria and whether you have priced the operational overhead.
  2. Offer three questions that make the choice derivable: what scale, does it need to commit in the same transaction as business tables, and how complex is the metadata filtering.
  3. pgvector wins on the last two: memories live in the same database as the business tables, so writing a memory and updating a run share one transaction; filtering by user is an ordinary WHERE clause; backups, monitoring, pooling and migrations are all reused. The line that shows operational experience is that one more stateful service usually becomes the bottleneck before vector search performance does.
  4. Be honest about the ceiling: past roughly ten million vectors in one table, HNSW index builds eat memory and write amplification shows; ANN plus metadata filtering is weaker than a purpose-built engine; horizontal scaling is whatever Postgres gives you. Refusing to name downsides reads as salesmanship.
  5. Commit to a rule: under a million vectors, needing joins or shared transactions, small team — pgvector. Tens of millions, retrieval as the primary workload, someone owning the service — dedicated store. Do not start with the dedicated store on day one.
  6. Expect the follow-up on migration cost. Switching stores does not require re-embedding — vectors belong to the model, not the store, so export and import; the cost is dual-write and rollout. Switching the embedding model is what forces a full recompute, and that is the real lock-in.

  答题要点

  • 三个判据：数据量级、要不要和业务表同事务提交、元数据过滤复不复杂
  • pgvector 的优势是同库同事务、普通 SQL 过滤、运维零新增——少一个有状态服务往往比性能更值钱
  • pgvector 的天花板：千万级向量时索引构建吃内存、写入放大、ANN 与过滤融合弱、扩展受限于 Postgres
  • 专用向量库给的是分布式分片、更强的过滤与 ANN 融合、混合检索，代价是多一个要备份要监控的有状态服务
  • 换向量库不用重算 embedding；换 embedding 模型才要全量重算，真正的锁定点是模型不是库

  Key points

  • Three criteria: scale, need for same-transaction commits with business tables, and filtering complexity
  • pgvector gives one database, one transaction, ordinary SQL filters and zero new operations — often worth more than raw performance
  • Its ceiling: memory-hungry index builds and write amplification at tens of millions, weaker ANN-plus-filter fusion, scaling limited to Postgres
  • Dedicated stores buy sharding, better filtered ANN and hybrid search, at the price of another stateful service to back up and monitor
  • Changing stores needs no re-embedding; changing the embedding model does — the lock-in is the model, not the database
• chunking 的切分策略会怎么影响检索效果？切多大合适？How does the chunking strategy affect retrieval quality, and how do you pick a chunk size?

  国内高频海外高频进阶#chunking#rag#retrieval-quality

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

  1. 题眼在「怎么影响」。只回答一个数字（比如「切 500 字」）会被追着问为什么，所以要先把两个方向的失效模式讲出来，数字才有落点。
  2. 切太碎的失效模式：单张卡片脱离上下文。「他说要 42 码」检索命中了也没用，代词失去指代，模型拿到一句悬空的话反而更容易编。
  3. 切太整的失效模式更反直觉，也是这题真正的区分点：一块横跨三个主题时，它的向量是这几个主题的平均值，结果对哪个 query 都不太像，命中率反而下降。**块越大信息越全，却越难被检索到**——能说出这句话基本就过了。
  4. 然后给可操作的口径：目标 400 字符、相邻块重叠 80 字符，并优先在句号、换行这类自然边界收尾。重叠的作用要说清楚——一句关键的话被切口劈开时，两块各拿半句，重叠保证它至少在其中一块里是完整的。
  5. 补上代价，这是工程视角：重叠 80 除以 400 等于 20% 的存储放大，向量也跟着多一份；内容高度重叠的两块可能一起被检索出来，白占返回名额，所以要按内容去重。
  6. 可以预期的追问：怎么验证切分策略好不好？答案是准备一批 query 与标注好的期望命中，量召回率和 top-k 命中率，改切分参数后重跑对比——切分是可以被度量的，不该靠感觉调。第二个追问是「对话数据要不要原样切」，答不要：先让模型抽成陈述句再切，否则大量寒暄句会把向量拉平。

  How to reason about it · think before answering

  1. The hinge is 'how does it affect'. Naming a number alone invites a why, so describe both failure modes first and let the number follow.
  2. Too small: a chunk loses its context. 'He wants size 42' retrieves fine but resolves to nothing — pronouns dangle and the model is more likely to fabricate.
  3. Too large is the counter-intuitive half and the real discriminator: a chunk spanning three topics gets a vector that averages them, so it looks only vaguely like any query and recall drops. Bigger chunks carry more information yet are harder to retrieve.
  4. Give an operational default: target 400 characters with 80 characters of overlap, ending on natural boundaries such as sentence stops or newlines. Explain the overlap — when a key sentence lands on a cut, each side holds half of it, and the overlap guarantees at least one chunk holds it whole.
  5. Add the costs: 80 over 400 is 20% storage amplification plus an extra vector per duplicated span, and near-duplicate chunks can both surface and waste result slots, so deduplicate by content before returning.
  6. Expect: how do you validate a chunking strategy? Build a query set with labelled expected hits and measure recall and top-k hit rate, then re-run after changing parameters — chunking is measurable, not a matter of taste. Second follow-up: should raw dialogue be chunked as-is? No — have the model distil it into standalone statements first, or filler turns flatten the vectors.

  答题要点

  • 切太碎：单块脱离上下文，代词失去指代，命中了也用不上
  • 切太整：一块横跨多个主题，向量被平均，对任何 query 都不够像，命中率反而下降
  • 可操作口径：目标 400 字符、重叠 80 字符，优先在句号或换行这类自然边界收尾
  • 重叠的作用是保证被切口劈开的句子至少在一块里完整；代价是约 20% 的存储放大和可能的重复命中
  • 别直接切对话原文，先抽成陈述句；切分效果要用标注好的 query 集测召回率，而不是凭感觉

  Key points

  • Too small: chunks lose context, pronouns dangle, and a hit is useless
  • Too large: one chunk spans several topics, its vector averages them, and recall drops for every query
  • Working default: target 400 characters with 80 characters of overlap, cutting on sentence or newline boundaries
  • Overlap keeps a split sentence whole in at least one chunk, at roughly 20% storage amplification plus possible duplicate hits
  • Distil dialogue into standalone statements before chunking, and validate with a labelled query set measuring recall

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

• 让你从零设计一套 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 复盘

• 多实例部署下，怎么设计心跳和健康检查？两者是同一件事吗？With multiple replicas, how do you design heartbeats and health checks? Are they the same thing?

  国内高频海外高频进阶#observability#deployment#distributed-systems

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

  1. 题眼是「两者是同一件事吗」。答「都是探活」直接失分——面试官想看你能不能把一个词拆成三个不同的问题，因为混起来会造成真事故。
  2. 先拆问题：存活探针回答「这进程要不要被重启」，就绪探针回答「现在能不能给我发流量」，心跳面板回答「集群此刻是什么状态」。三者的读者不同：前两个给编排系统，第三个给人。
  3. 再说心跳为什么不可省：编排系统只能看到进程存活，而 Worker 完全可以进程活着而活儿全停——事件循环被死循环占住、连接池耗尽后取消息全超时、宿主机 CPU 被邻居打满。这类假死恰好是编排系统看不见的那种，只有业务自己上报的心跳能发现。
  4. 方向也要答对：心跳是副本自己 push，不是 Gateway 逐个 pull。因为容器随时换 IP 和主机名，去问的一方需要一份永远在变的名单，而那份名单本身就得靠心跳维护，逻辑绕回来了。上报内容至少三样：时间戳判活、在跑任务数区分闲和忙、版本号在滚动发布时看新旧两批各剩几个。
  5. 最关键的一刀是隔离性：**不要把下游依赖查进就绪探针**。一个 Worker 失联导致所有 Gateway 的就绪探针同时转红，编排系统会把整个接入层摘光——一个非核心故障被自己升级成全站不可用。而实际上那个 Worker 失联根本不影响接单：消息还在流里，没确认的会被别人接手，它的租约会因 TTL 到期而易主。
  6. 可以预期的追问：那 Gateway 怎么判断某个 Worker 可不可用？答「它不判断，也不需要判断」——Gateway 从不指定某个 Worker 干活，派活由消费组和租约决定，心跳的用途是观测和告警，不是路由。答到这里就说明你真的想清楚了分层。

  How to reason about it · think before answering

  1. The hinge is are they the same thing. Answering both check liveness loses the point — the interviewer wants to see you split one word into three distinct questions, because conflating them causes real outages.
  2. Separate them: a liveness probe answers should this process be restarted, a readiness probe answers can you send me traffic now, and a heartbeat dashboard answers what is the cluster's state. The audiences differ: the first two are for the orchestrator, the third is for a human.
  3. Then say why heartbeats are not optional: the orchestrator only sees process liveness, but a worker can be alive while doing no work at all — a blocked event loop, an exhausted connection pool timing out every read, a noisy neighbour saturating host CPU. This kind of zombie is exactly what the orchestrator cannot see, and only an application-level heartbeat catches it.
  4. Get the direction right too: replicas push their own heartbeat rather than the gateway polling each one. Containers change IP and hostname constantly, so a poller needs a roster that is always changing — and maintaining that roster is what heartbeats are for, so the logic is circular. Report at least three things: a timestamp for liveness, in-flight count to distinguish idle from overloaded, and a version so you can watch old and new replicas during a rollout.
  5. The sharpest point is isolation: do not query downstream dependencies inside a readiness probe. One worker going quiet would turn every gateway's readiness red, and the orchestrator would pull the entire ingress layer — turning a non-critical fault into a full outage. In reality that worker's absence does not stop intake at all: messages sit in the stream, unacked ones get claimed by someone else, and its lease changes hands when the TTL expires.
  6. Expect: so how does the gateway decide whether a worker is usable? Answer that it does not, and does not need to — the gateway never assigns work to a specific worker; the consumer group and the lease decide that. Heartbeat data is for observability and alerting, not routing. Getting here shows you actually understand the layering.

  答题要点

  • 一个词要拆成三个问题：存活探针（要不要重启）、就绪探针（能不能发流量）、心跳面板（集群什么状态），前两个给编排系统、第三个给人
  • 编排系统只看得见进程存活，看不见假死（事件循环卡住、连接池耗尽、CPU 被抢），所以业务层心跳不可省
  • 心跳必须是副本 push 而不是 Gateway pull：容器随时换 IP，pull 需要一份靠心跳才能维护的名单，逻辑绕回来了
  • 上报时间戳、在跑任务数、版本号三样，分别用于判活、区分忙闲、观察滚动发布进度
  • 不要把下游依赖查进就绪探针，否则一个 Worker 失联会让整个接入层被摘掉，把非核心故障升级成全站不可用
  • Gateway 不判断 Worker 可用性——派活由消费组和租约决定，心跳只用于观测告警，不用于路由

  Key points

  • Split one word into three questions: liveness (restart me?), readiness (send me traffic?), heartbeat dashboard (what is the cluster doing?) — first two for the orchestrator, third for humans
  • The orchestrator sees process liveness but not zombies (blocked loop, exhausted pool, stolen CPU), so an application-level heartbeat is mandatory
  • Heartbeats must be pushed by replicas, not polled by the gateway: containers change IP constantly and polling needs a roster that heartbeats themselves maintain
  • Report timestamp, in-flight count and version — for liveness, load, and rollout progress respectively
  • Never query downstream dependencies in a readiness probe, or one quiet worker pulls the whole ingress layer and escalates a minor fault into an outage
  • The gateway does not judge worker availability — the consumer group and lease assign work; heartbeats are for observability, not routing
• 什么是优雅停机？为什么直接 kill 进程有风险？请说出具体步骤。What is graceful shutdown, and why is killing a process outright risky? Walk through the steps.

  国内高频海外高频进阶#deployment#reliability#operations

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

  1. 这题考的是「你有没有真的发过版」。答「等任务跑完再退出」只是定义，面试官要的是代价、步骤和顺序。
  2. 先把代价说具体。发版、缩容、机器维护、抢占式实例回收都会先发 SIGTERM、等宽限期、超时 SIGKILL。SIGKILL 拦不住，落到正在跑 Agent 循环的 Worker 身上：这次的 run 永远停在 running，用户界面一直转圈；模型调用的钱已经付了，回复却没落库；没确认的消息要等空闲阈值到了才被别人接手，用户白等一轮。一次发版掐断几十次对话，这就是日常代价。
  3. 然后给三步，强调顺序不能变：第一步拒新——把开关拨过去，消费循环下一轮不再从流里取消息（已经读到手上还没开始的那几条，留在 pending 里由别人接手，比硬扛完一整批更快）；第二步等手头这次执行跑完，但要有上限；第三步主动交还租约、从心跳面板注销，然后退出。
  4. 第二步的上限是加分点：一次卡死的模型调用会让你永远等不到，而宽限期一到照样 SIGKILL。与其被动挨刀，不如自己认输退出——没确认的消息还在 pending 里，别人会接手重做。本课取 20 秒，取法是「一次正常执行的耗时上限」再留余量。
  5. 第三步也是加分点：租约本来靠 TTL 到期自然易主，但那是为进程猝死准备的。计划内下线你明知道自己要走，主动交还能让接手方下一轮扫描就上岗，而不是白等一个 TTL。交还必须带条件——只删还写着自己名字的那把牌子，否则租约已过期、别人刚抢到时，你就把对方的值班牌撕了。
  6. 最后两件配套的事，漏一件前面全白做：宽限期的配置必须大于代码里的等待上限（代码等 20 秒而 compose 默认只等 10 秒，第 10 秒就 SIGKILL，三步只走到一半）；以及信号得真的传到你的进程（启动命令写成包管理器，PID 1 就是包管理器，SIGTERM 未必传得到，停机代码一次都不会执行）。

  How to reason about it · think before answering

  1. This question tests whether you have actually shipped a release. Reciting finish in-flight work before exiting is just the definition; the interviewer wants the cost, the steps, and the ordering.
  2. Make the cost concrete. Deploys, scale-downs, host maintenance and spot reclamation all send SIGTERM, wait a grace period, then SIGKILL. SIGKILL cannot be trapped, and landing it on a worker mid-agent-loop means: the run is stuck in running forever while the user watches a spinner; you already paid for the model call but never persisted the reply; the unacked message waits for the idle threshold before anyone claims it. One deploy cuts off dozens of conversations — that is the everyday cost.
  3. Then give three steps and stress that the order is fixed. One, stop accepting work: flip a flag so the consume loop stops reading from the stream (messages already fetched but not started stay in pending for someone else, which is faster than forcing a whole batch through). Two, wait for the in-flight execution, but with a ceiling. Three, proactively release leases, deregister from the heartbeat dashboard, and exit.
  4. The ceiling in step two earns points: a hung model call means you wait forever, and the grace period will SIGKILL you anyway. Better to concede and exit — the unacked message is still pending and someone will redo it. This course uses 20 seconds, derived from the upper bound of a normal execution plus margin.
  5. Step three also earns points: leases normally change hands via TTL expiry, but that path exists for sudden death. On a planned shutdown you know you are leaving, so releasing proactively lets the successor take over on its next scan instead of waiting out a full TTL. The release must be conditional — delete only the badge that still bears your name, or you will tear down the badge of whoever just claimed it after your lease expired.
  6. Finish with two companions; miss either and the rest is wasted. The configured grace period must exceed the wait ceiling in code (code waits 20s while compose defaults to 10s, so SIGKILL lands at second 10 and your three steps only half-run). And the signal must actually reach your process (if the entrypoint is a package manager, PID 1 is the package manager, SIGTERM may never arrive, and your shutdown code never runs once).

  答题要点

  • 直接 kill 的具体代价：run 永远停在 running、用户界面一直转圈、模型的钱已付但回复没落库、没确认的消息要等空闲阈值才被接手
  • 三步且顺序不能变：拒绝新任务 → 等手头的跑完（有上限）→ 主动交还租约并注销心跳，然后退出
  • 等待必须有上限（本课 20 秒）：卡死的模型调用会让你永远等不到，宽限期一到照样被 SIGKILL，不如自己认输，消息还在 pending 里
  • 主动交还租约让接手方下一轮就上岗，而不是白等一个 TTL；交还必须条件化，只删还写着自己名字的那把
  • 宽限期配置必须大于代码里的等待上限，否则三步只执行到一半（compose 的 stop_grace_period / K8s 的 terminationGracePeriodSeconds）
  • 信号要真传到进程：用 exec 形式直接起业务进程，别让包管理器当 PID 1

  Key points

  • Concrete cost of a hard kill: the run is stuck in running, the user stares at a spinner, the model call is paid for but the reply is unsaved, and the unacked message waits out the idle threshold
  • Three steps in a fixed order: refuse new work, wait for in-flight work with a ceiling, then release leases and deregister before exiting
  • The wait needs a ceiling (20s here): a hung model call never returns and the grace period kills you anyway, so concede — the message is still pending for someone else
  • Releasing leases proactively lets the successor start on its next scan instead of waiting a full TTL; the release must be conditional on still owning it
  • The configured grace period must exceed the in-code wait ceiling, or the three steps only half-run (stop_grace_period / terminationGracePeriodSeconds)
  • Make sure the signal reaches your process: exec the business process directly rather than letting a package manager be PID 1
• 滚动发布时，如何避免正在处理的任务被打断？During a rolling deploy, how do you keep in-flight tasks from being interrupted?

  国内高频海外高频进阶#deployment#reliability#operations

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

  1. 这题是上一题的应用题，区别在于它要求你把编排系统那一侧也讲进来——只讲进程内的三步只答了一半。
  2. 完整骨架是两侧配合：编排系统先摘流量（把就绪探针转红，让负载均衡不再把新请求打过来）、再发 SIGTERM、然后等宽限期；进程在这段时间里把手头的活做完、交还所有权、干净退出。这一句话就是答案的主干，剩下都是细节。
  3. 然后区分两类副本，这是拿分点。Gateway 有入站连接，摘流量对它有意义；Worker 没有任何入站连接，它是自己去总线取活的，所谓「摘流量」对它就是「自己不再取新消息」——也就是停机三步的第一步。**同一个词在两类副本上是两种机制**，能说清这一点说明你理解拉与推的差别。
  4. 接着讲批次与顺序：一次只换一部分副本（compose 里手动分批，K8s 里靠 maxUnavailable / maxSurge），保证任何时刻都有足够的存活副本接得住流量。心跳面板上的版本号字段这时派上用场——你能看到新旧两批各剩几个，而不是盲发。
  5. 还要提一句状态兼容：滚动发布期间新旧代码同时在线，所以数据库迁移必须向后兼容（先加可空列、再双写、最后才删旧列），消息格式也不能一次性改。这是很多人漏掉的一层——进程停得再优雅，新旧版本读不了同一份数据照样出事故。
  6. 可以预期的追问：如果一次执行本来就要跑 5 分钟，宽限期不可能等那么久怎么办？答案不是把宽限期拉到 5 分钟，而是让任务可中断可重入——把长任务切成可保存进度的小步（D11 的 run 状态机和 D9 的 at-least-once 加幂等正好提供了这个基础），被打断的那一步由下一个副本接着做。

  How to reason about it · think before answering

  1. This is the applied version of the previous question, and the difference is that it demands the orchestrator's side too — describing only the in-process steps answers half of it.
  2. The full skeleton is both sides cooperating: the orchestrator first removes traffic (turns readiness red so the load balancer stops sending new requests), then sends SIGTERM, then waits out the grace period; the process uses that window to finish in-flight work, hand back ownership, and exit cleanly. That sentence is the trunk; everything else is detail.
  3. Then distinguish the two kinds of replica, which is where the points are. A gateway has inbound connections, so draining traffic means something for it. A worker has no inbound connections at all — it pulls work from the bus, so draining for it means stop fetching new messages, which is step one of graceful shutdown. The same word is two different mechanisms on the two replica types, and saying so shows you understand pull versus push.
  4. Next, batching and ordering: replace only a subset at a time (manual batches in compose, maxUnavailable / maxSurge in Kubernetes) so enough replicas are always alive to absorb traffic. This is where the version field in the heartbeat payload pays off — you can see how many old and new replicas remain instead of deploying blind.
  5. Also mention state compatibility: during a rolling deploy old and new code run simultaneously, so schema migrations must be backward compatible (add a nullable column, dual-write, drop the old column last) and message formats cannot change in one shot. Many candidates miss this layer — however gracefully processes stop, two versions that cannot read the same data will still cause an incident.
  6. Expect: what if a single execution legitimately takes five minutes and the grace period cannot wait that long? The answer is not to stretch the grace period to five minutes but to make the task interruptible and resumable — break long work into steps that checkpoint progress (the run state machine from D11 plus at-least-once with idempotency from D9 give you exactly this), so the next replica continues the interrupted step.

  答题要点

  • 完整骨架是两侧配合：编排系统先摘流量、再发 SIGTERM、等宽限期；进程在这段时间做完手头的活、交还所有权、干净退出
  • Gateway 和 Worker 的「摘流量」是两种机制：前者靠就绪探针转红让负载均衡停止转发，后者靠自己不再从总线取新消息
  • 分批替换（maxUnavailable / maxSurge 或手动分批），保证任何时刻有足够存活副本；心跳里的版本号让你看到新旧两批各剩几个
  • 新旧代码同时在线，所以数据库迁移必须向后兼容（加可空列 → 双写 → 最后删旧列），消息格式不能一次性改
  • 长任务不该靠拉长宽限期解决，而要做成可中断可重入：切成能保存进度的小步，被打断的那步由下一个副本接着做

  Key points

  • The full skeleton is both sides: orchestrator drains traffic, sends SIGTERM, waits the grace period; the process finishes in-flight work, hands back ownership, exits cleanly
  • Draining means two different things for gateways and workers: readiness turning red versus the worker itself stopping its fetch from the bus
  • Replace in batches (maxUnavailable / maxSurge or manual) so enough replicas stay alive; the version field in heartbeats shows how many old and new remain
  • Old and new code run concurrently, so migrations must be backward compatible (nullable column, dual-write, drop last) and message formats cannot change in one step
  • Long tasks are not solved by a longer grace period but by being interruptible and resumable — checkpointed steps that the next replica can continue

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

• LangGraph 里节点、边、状态分别扮演什么角色？如果不用框架，你自己会怎么实现？In LangGraph, what roles do nodes, edges and state play? If you had no framework, how would you implement it yourself?

  国内高频海外高频进阶#langgraph#orchestration#state-management

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

  1. 题眼在后半句。只答三个概念的定义，面试官会认为你读过文档；能说出「不用框架会难受在哪」，才证明你知道框架替你解决了什么。这类题的通用解法是：先讲自己手写的版本，再讲框架把哪几处收敛了。
  2. 先给手写版：一个循环，里面一串条件判断决定下一步走哪，中间用一个大对象在各步之间传数据。写到第三个分支就会撞上三件事——两步都往同一个字段写，是覆盖还是追加，你要在每个分支里手写一遍合并逻辑；中间过程全在局部变量里，出错只能靠打印；进程一挂就从头重来，已经花掉的模型调用钱白付。
  3. 然后一一对上：节点是一个普通函数，读全量状态、返回只含改动字段的增量；边是节点之间的连接，无条件边写死顺序，条件边在运行时决定去哪；状态是一张字段表，每个字段是一条独立通道，通道上挂着合并规则。
  4. 重点讲第三条，因为它是最容易被略过、也最值钱的一条：**合并规则是声明在字段上的，不是写在节点里的**。这意味着新增节点时不需要考虑「我该怎么和别人的写入合并」，字段自己知道；也意味着并行写同一个字段时行为是确定的，而不是取决于谁先返回。
  5. 配两个具体的坑，证明你真跑过：一是在节点里原地修改状态（比如直接往数组里 push）会绕过合并规则，单线程时察觉不到，并行时变成偶发覆盖；二是加了节点没连边不会报错，表现只是那个节点永远不执行，只能靠逐节点追踪发现。
  6. 可以预期的追问：那你为什么不直接自己写？答：三要素本身很轻，核心逻辑几十行就能手写出来——框架真正值钱的是检查点与恢复、并行执行、以及每一步的可观测，这三样自己写的成本远高于三要素本身。顺带说明 Java 和 Swift 没有官方 LangGraph，真要在这两门语言里做，就是把这三要素手写一遍。

  How to reason about it · think before answering

  1. The hinge is the second half. Defining the three concepts only proves you read the docs; explaining what hurts without a framework proves you know what it buys you. The general move for this family of questions is: describe your hand-rolled version first, then name what the framework collapsed.
  2. Hand-rolled version: a loop, a chain of conditionals picking the next step, and one big object carrying data between steps. By the third branch you hit three walls — when two steps write the same field, is it overwrite or append, and you hand-write that merge in every branch; intermediate state lives in local variables so debugging means print statements; a crash restarts from zero and the model calls you already paid for are wasted.
  3. Then map them: a node is an ordinary function that reads the whole state and returns a delta containing only what it changed; edges connect nodes, unconditional ones fix the order and conditional ones decide at runtime; state is a table of fields where each field is its own channel carrying a merge rule.
  4. Dwell on the third, which is the most skipped and most valuable point: the merge rule is declared on the field, not written inside the node. Adding a node therefore requires no thought about how to combine with other writers, and parallel writes to one field behave deterministically instead of depending on who returns first.
  5. Add two concrete traps to show you have actually run this: mutating state in place inside a node bypasses the merge rule — invisible single-threaded, an intermittent overwrite once things run in parallel; and adding a node without wiring an edge raises no error at all, it simply never executes, which only per-node tracing reveals.
  6. Expect: so why not just write it yourself? Because the three primitives are genuinely light — a few dozen lines. What the framework actually sells is checkpointing and recovery, parallel execution, and per-step observability, all of which cost far more to build than the primitives. Mention too that there is no official LangGraph for Java or Swift, so in those languages you do hand-roll exactly these three.

  答题要点

  • 节点是普通函数：读全量状态，返回只含改动字段的增量，不在节点里原地改状态
  • 边决定执行顺序：无条件边写死，条件边在运行时决定下一步去哪（Supervisor 就靠它）
  • 状态是一张字段表，每个字段一条通道，通道上挂合并规则——规则声明在字段上而不是写在节点里
  • 不用框架会撞三堵墙：合并逻辑在每个分支手写一遍、中间过程只能靠打印、进程挂了从头重来
  • 两个真实的坑：原地改状态绕过合并规则（并行时偶发覆盖）、加了节点没连边不报错只是永不执行
  • 框架真正值钱的不是这三要素，而是检查点恢复、并行执行和逐步可观测

  Key points

  • A node is a plain function: read the full state, return a delta of changed fields only, never mutate in place
  • Edges set execution order: unconditional edges are fixed, conditional edges decide the next hop at runtime — that is what a supervisor uses
  • State is a table of fields, each field a channel carrying a merge rule declared on the field rather than inside nodes
  • Without a framework you hit three walls: hand-written merges in every branch, no visibility into intermediate steps, and full restart after a crash
  • Two real traps: in-place mutation bypasses the merge rule and causes intermittent overwrites under parallelism; an unwired node raises no error, it just never runs
  • What the framework really sells is checkpoint recovery, parallel execution and per-step observability — not the three primitives themselves
• 从单 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

D16 Supervisor 动态路由：structured output 路由、override、routingReason

• 为什么要让模型输出 structured output 而不是自然语言来做路由？自然语言到底差在哪？Why use structured output rather than natural language for routing? What exactly goes wrong with free text?

  国内高频海外高频进阶#structured-output#routing#reliability

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

  1. 这题最容易答成「结构化更规范、更好解析」——这是形容词，不是理由。面试官想听的是一个具体的失败场景，最好是你真的调过的那种。
  2. 把最锋利的一刀先亮出来：**自然语言路由的失败是静默的**。模型回「我觉得这个可以让查订单的同事看一下」，它其实判对了，但说的是人话不是 id，正则匹配不上就落进兜底，日志里只留下一个 smalltalk。模型是对的、解析是错的，而它和「模型判错了」在日志里长得一模一样。你会去调提示词，调两天才发现问题在那三行正则。
  3. 然后给三个漏洞，一条一条对上结构化输出解决了什么：输出会漂移（今天回「订单查询」明天回「查订单」，正则永远追不上，模型小版本升级你就掉准确率）；没有置信度（自然语言里没有「我有多大把握」这个信息，你没法区分它很确定还是在猜）；拼错或自造的路由名要到运行时才炸（枚举是一道编译期就存在的闸门）。
  4. 接着说清机制，别停在「用 zod 更规范」：把 schema 发进请求（response_format 里的 json_schema），模型的解码过程被枚举约束；回来之后**用同一份声明再校验一遍**。一份声明两用，请求与校验不会漂移。
  5. 关键的反直觉点，答到这里就拉开差距了：**结构化输出不等于不用校验**。不是所有网关、所有模型都严格执行 schema，降级到备用模型时更说不准。所以解析函数的返回类型应该是「一段待校验的东西」，而不是「已经是 RouteDecision」。
  6. 可以预期的追问：那不支持 json_schema 的模型怎么办？答案是退回「few-shot 加严格提示词加自己校验」，闸门仍然在你的枚举校验那一步——真正兜底的从来不是模型的自觉，是你的解析层。

  How to reason about it · think before answering

  1. The trap is answering structured output is cleaner and easier to parse. Those are adjectives, not reasons. The interviewer wants a concrete failure you have actually debugged.
  2. Lead with the sharpest point: free-text routing fails silently. The model replies I think the order desk should look at this — it judged correctly, but it spoke prose, not an id. Your regex misses, you fall through to the default, and the log shows only smalltalk. A correct model with a broken parser looks exactly like a wrong model, so you spend two days tuning a prompt that was never the problem.
  3. Then list three holes and map each to what structured output fixes: wording drifts across versions so regexes never catch up; there is no confidence signal, so you cannot tell certainty from guessing; and an invented route name only explodes at runtime, whereas an enum is a gate that exists before the request is even sent.
  4. Explain the mechanism rather than stopping at zod is nicer: send the schema in the request (response_format with a json_schema), so decoding is constrained by the enum, then validate the response with the same declaration. One declaration used twice means request and validation cannot drift apart.
  5. The counterintuitive point that separates candidates: structured output does not remove the need to validate. Not every gateway or model enforces the schema strictly, and a fallback model may not at all. Your parse function should return something-to-be-validated, not an already-typed decision.
  6. Expect: what if the model does not support json_schema? Fall back to few-shot plus a strict prompt plus your own validation. The real gate was never the model's discipline; it is your parsing layer.

  答题要点

  • 自然语言路由的失败是静默的：模型判对了但说的是人话，正则匹配不上就落兜底，和判错在日志里完全一样
  • 三个漏洞：措辞会漂移（正则追不上）、没有置信度（分不清确定与猜）、自造的路由名要到运行时才炸
  • 机制是一份声明两用：schema 随请求发出去约束解码，回来后用同一份声明校验，请求与校验不会漂移
  • 枚举是编译期就存在的闸门，把「拼错的路由名」从线上事故降级成一次解析失败
  • 结构化输出不等于不用校验：网关和降级模型未必严格执行 schema，解析函数的返回类型应该是「待校验」而不是「已经是」

  Key points

  • Free-text routing fails silently: a correct judgement in prose misses your regex and falls through, looking identical to a wrong judgement in the logs
  • Three holes: wording drifts, there is no confidence signal, and invented route names only fail at runtime
  • One declaration used twice: the schema constrains decoding in the request and validates the response, so the two cannot drift
  • An enum is a gate that exists before the call, turning a misspelled route from an incident into a parse failure
  • Structured output does not remove validation — gateways and fallback models may not enforce the schema, so parsing must return an unvalidated value
• routingReason 这类调试信息在生产系统里有什么价值？只是打日志而已吗？What is a field like routingReason actually worth in production? Is it just logging?

  国内高频海外高频进阶#observability#routing#debugging

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

  1. 这题看着像水题，其实在筛「有没有真的排查过线上问题」。答「方便调试」就结束的人，基本没值过班。
  2. 先给一条不可回避的事实：**路由决策是模型做的，而模型不可复现**。同一句话下次未必给同样的判断，你没法重跑一遍去看「当时是怎么想的」。所以理由必须在当时就写下来，否则那次判断永远丢了。这一条把 routingReason 从「日志」抬到了「唯一的审计证据」。
  3. 然后给三个具体用途，每个都要能落地：一是把「模型判错了」和「解析或兜底出错了」分开，前缀写成 fallback 加原因码，一眼就能分辨；二是攒下一版提示词的素材，把一周内落进兜底的请求按原因分组，会看到集中的几类意图缺描述；三是它是离线评估的输入——标准样本集要评的不只是最终回答，还有分诊准不准，而这件事只有当时记了判断和理由才评得了。
  4. 写法上有个细节值得主动说：**结构化的壳加自然语言的芯**。前缀（fallback 加原因、override 加目标）用来聚合统计，后面那句人话用来看具体这一单。整条都写成自然语言，就退回成本章批判的那种东西了。
  5. 再补一条容易被忽略的：兜底和人工改派都不要擦掉模型的原判，原样拼进理由里。否则一周后没人说得清这一单是模型判错了还是本来就被人改过——多写二十个字符，省掉一次翻遍代码的排查。
  6. 可以预期的追问：这些字段会不会带来隐私或成本问题？答案是会，所以理由里只写判断依据不写用户原文，长度设上限（比如 120 字），并且和链路追踪共用同一个 run 标识，别另起一套。

  How to reason about it · think before answering

  1. This looks like a throwaway question but it screens for whether you have ever been on call. Anyone who stops at it helps with debugging has not.
  2. Start with the fact you cannot design around: the routing decision is made by a model, and models are not reproducible. The same sentence may be judged differently next time, so you cannot re-run to see what it was thinking. The reason must be captured at decision time or it is gone forever — that is what turns this field from a log line into the only audit evidence you have.
  3. Then give three concrete uses. One, it separates a wrong model judgement from a parsing or fallback problem, provided the prefix carries a cause code. Two, it is raw material for the next prompt revision: group a week of fallbacks by cause and the missing intent descriptions jump out. Three, it feeds offline evaluation — a golden set should score routing accuracy, not just the final answer, and that is only scorable if the decision and its reason were recorded.
  4. Mention the shape: a structured prefix wrapping a human sentence. The prefix (fallback plus cause, override plus target) is what you aggregate on; the sentence is what you read for one specific case. Making the whole field prose puts you right back in the failure mode this chapter argues against.
  5. Add the detail people skip: neither a fallback nor a human override should erase the model's original judgement — carry it into the reason. Otherwise nobody can later tell whether the model got it wrong or a human redirected it. Twenty extra characters save an afternoon of archaeology.
  6. Expect: do these fields create privacy or cost problems? Yes, so record the basis for the decision rather than the user's raw text, cap the length, and reuse the same run identifier as your tracing instead of inventing a parallel one.

  答题要点

  • 路由决策由模型做出且不可复现，理由必须在当时写下来，否则那次判断永远丢了——它是唯一的审计证据
  • 用途一：把「模型判错」和「解析或兜底出错」分开，靠 fallback 加原因码一眼分辨
  • 用途二：把一周内落进兜底的请求按原因分组，直接得到下一版分诊提示词该补什么
  • 用途三：它是离线评估的输入，分诊准确率这个指标只有记了当时的判断与理由才评得了
  • 写法是结构化的壳加自然语言的芯：前缀用于聚合统计，人话用于看具体这一单
  • 兜底与人工改派都要保留模型原判；理由只写判断依据不写用户原文，长度设上限，并复用链路追踪的 run 标识

  Key points

  • The decision comes from a model and is not reproducible, so the reason must be captured at decision time — it is the only audit evidence you get
  • Use one: it separates a wrong model judgement from a parsing or fallback failure, via a cause code in the prefix
  • Use two: grouping a week of fallbacks by cause tells you exactly what the next routing prompt is missing
  • Use three: it feeds offline evaluation, since routing accuracy can only be scored if the decision and reason were recorded
  • Shape it as a structured prefix around a human sentence: aggregate on the prefix, read the sentence for one case
  • Keep the model's original judgement through fallbacks and overrides; store the basis rather than raw user text, cap the length, and reuse the tracing run id

D17 Planner–Executor–Critic + 共享工作区：workspace state、toolBudget、并行 fan-out、review 回路

• 为什么要给每个子任务设 toolBudget 这样的预算？超了预算之后你会怎么处理？Why give each subtask a tool-call budget, and what do you do when it runs out?

  国内高频海外高频进阶#cost-control#reliability#agent-design

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

  1. 这题的题眼在后半句。前半句几乎人人会答「防止成本失控」，真正拉开差距的是超限之后的动作——答「抛异常」的人基本没做过面向用户的 Agent。
  2. 先把「为什么」说具体。子任务卡住的典型形态不是报错，而是反复查、反复不满意、再查——模型不会喊累，它会把额度花光为止。整轮对话的成本封顶是外层的闸，子任务预算是内层的闸；粒度细到单件事的好处是超支时你能精确指出是哪一件失控了，而不是只看到这次对话贵了。
  3. 再点一个容易被忽略的设计点：预算必须是子任务级的，不是单次执行级的。有评审回路时，被打回重做也得计费，否则打回两次实际额度就翻三倍，这道闸等于没设。
  4. 结论是超限的处理：降级返回已有结果并打上标记，不抛错。理由要说透——抛错等于把「这件事只做了一半」升级成「整个请求失败」，用户等了几秒最后看到一句服务异常，可他其实只是没拿到三件事里的一件。给出两件半的答案并说明哪半件没做成，永远比一个错误页有用。
  5. 降级标记本身也要说：它让降级变成可观测、可统计的事实，而不是日志里的一句话。上层据此决定要不要转人工，监控据此画降级率——两个平均分一样的系统，降级率百分之三十和百分之三完全不是一回事。
  6. 可以预期的追问：预算该设多少？答案是从「这件事正常需要几次工具调用」反推再留一点余量，不是拍脑袋取整数；同时要有第二个维度的闸（挂钟时间或 token 数），因为一次超长的工具调用同样能拖垮请求，而它只算一次。

  How to reason about it · think before answering

  1. The hinge is the second half. Everyone can say it controls cost; what separates people is what happens when the budget runs out. Answering throw an exception usually means you have never shipped a user-facing agent.
  2. Make the why concrete: a stuck subtask rarely errors — it queries, dislikes the result, and queries again. The model never gets tired; it will spend whatever you allow. A per-conversation cap is the outer gate, a per-subtask budget is the inner one, and the finer grain tells you which piece went out of control instead of only that the conversation was expensive.
  3. Add the design point people miss: the budget must be per subtask, not per execution. With a review loop, retries have to draw on the same budget, or two rejections triple the real allowance and the gate is meaningless.
  4. The conclusion is the exhaustion path: degrade — return what you already have with a flag — rather than throw. Explain why: throwing upgrades this piece is half done into the whole request failed. The user waited several seconds and gets an error page, when in reality only one of three pieces is missing. Two and a half answers plus a clear note beats an error page every time.
  5. Say something about the flag too: it turns degradation into an observable, countable fact instead of a log line. The layer above decides whether to escalate to a human, and monitoring plots a degradation rate — two systems with the same average score but 30 percent versus 3 percent degradation are not the same system.
  6. Expect: how big should the budget be? Derive it from how many tool calls the task normally needs plus margin, not a round number pulled from the air. And pair it with a second dimension — wall-clock or tokens — because one very slow tool call can ruin a request while counting as a single call.

  答题要点

  • 子任务卡住的典型形态是反复查而不是报错，模型会把额度花光为止；整轮封顶是外层闸，子任务预算是内层闸，细粒度让你能定位到是哪一件失控
  • 预算必须是子任务级而不是单次执行级，否则被评审打回两次实际额度就翻三倍
  • 超限必须降级返回已有结果并标记，不能抛错——抛错把「做了一半」升级成「整个请求失败」，用户连已经查到的部分都拿不到
  • 降级标记让降级率变成可统计指标，上层据此决定转人工，评估据此区分两个平均分相同的系统
  • 预算大小从这件事正常需要几次工具调用反推并留余量，同时配一个时间或 token 维度的闸

  Key points

  • A stuck subtask loops rather than errors, and the model will spend whatever you allow; a conversation cap is the outer gate, a subtask budget the inner one that localises the blowup
  • The budget must be per subtask, not per execution, or two review rejections triple the real allowance
  • On exhaustion, degrade and flag rather than throw — throwing upgrades half done into whole request failed and discards what was already retrieved
  • The degradation flag makes the degradation rate a real metric for escalation and evaluation
  • Size the budget from the task's normal tool-call count plus margin, and pair it with a wall-clock or token gate
• Critic 的评审回路怎么防止陷入死循环？除了次数上限还有什么要防的？How do you keep a Critic review loop from spinning forever, and what else needs guarding besides a retry cap?

  国内高频海外高频进阶#reflection#loop-guard#reliability

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

  1. 问「除了次数上限还有什么」，说明面试官已经预设你会答上限，真正在考的是你有没有真的跑过这条回路。只答上限的人拿基础分，能说出另外两种失效方式的才算过。
  2. 第一种就是无限打回：每改一版评审者挑一个新毛病，永远收敛不了。上限的作用不是省钱，是**保证流程一定会结束**。本课取最多打回 2 次、共 3 次执行，这个量级的取法是「一次有效的修改通常在第二次就完成，第三次还不行说明判据本身有问题」。
  3. 第二种是打回不说人话：评审者只回一句「不合格」，执行者拿不到可执行信息，第二稿原样再交一遍，于是必然打满上限、白烧三倍的钱。所以打回必须带具体理由，而且理由要回写进子任务的目标里带给执行者——「缺了退款结论，请补上」才是可执行的，「质量不佳」不是。
  4. 第三种最危险也最少被提到：评审者和执行者用同一个模型、同一套提示词时，它倾向于认可自己的输出。同一个模型对「什么算好答案」的偏好是一致的，让它复核自己刚写的东西，通过率会高得离谱，这道工序等于没有。缓解手段按性价比排：给评审者一份可核对的客观验收要求；换一个不同的模型来评审，哪怕更便宜；把评审做成逐条打分而不是一句结论。
  5. 还要点一句框架的兜底与业务上限的区别：编排框架通常自带一个递归步数上限，但那是最后一道保险丝，不能当业务上限用——它是全图的，你不知道是哪条回路失控；而且它触发时抛异常，你连已有结果都拿不到，正好违背「降级返回」的原则。
  6. 可以预期的追问：上限用完了返回什么？答：返回已有结果并标记降级，同时把最后一次的评审意见一起带出去，让上层能判断要不要转人工——这条回路的价值不只是修好，还包括「修不好时说清楚差在哪」。

  How to reason about it · think before answering

  1. Asking what else besides a cap tells you the interviewer already expects the cap. What is really being tested is whether you have run this loop for real. The cap earns baseline credit; naming the other two failure modes is what passes.
  2. Failure one is infinite rejection: every revision draws a new complaint and nothing converges. The cap exists to guarantee termination, not to save money. Two rejections and three executions is a reasonable default, because an effective fix usually lands on the second attempt — if the third still fails, the rubric itself is the problem.
  3. Failure two is a rejection with no actionable content. If the reviewer only says not good enough, the executor has nothing to act on and resubmits the same thing, burning the full cap. Rejections must carry a specific reason, and that reason must be written back into the subtask goal. Missing the refund conclusion, please add it is actionable; poor quality is not.
  4. Failure three is the dangerous one people rarely mention: when reviewer and executor share a model and a prompt, the reviewer tends to approve its own output. A single model has consistent preferences about what a good answer looks like, so pass rates go implausibly high and the review step becomes theatre. Mitigations by value: give the reviewer an objective, checkable rubric; use a different model even a cheaper one; score item by item rather than emitting one verdict.
  5. Also distinguish the framework's safety net from your business cap: orchestration frameworks usually ship a recursion limit, but that is a last-resort fuse — it is graph-wide so you cannot tell which loop ran away, and it throws, which means you lose the partial results you were supposed to degrade to.
  6. Expect: what do you return once the cap is used up? Return what you have, flag it as degraded, and carry the last review comment out with it so the layer above can decide whether to escalate. The loop's value is not only fixing things — it is stating precisely what could not be fixed.

  答题要点

  • 次数上限的作用是保证流程一定会结束，不是省钱；本课取最多打回 2 次、共 3 次执行
  • 打回必须带具体、可执行的理由并回写进子任务目标，只说「不合格」会让执行者原样重交、必然打满上限
  • 最危险的是评审者与执行者同模型同提示词，它倾向于认可自己的输出，通过率虚高、这道工序等于没有
  • 缓解手段：给客观可核对的验收要求、换一个模型来评审、逐条打分而不是一句结论
  • 框架自带的递归上限只是保险丝，不能当业务上限：它是全图的、触发时抛异常，连已有结果都拿不到
  • 上限用完要返回已有结果加降级标记，并把最后一次评审意见带出去，供上层决定是否转人工

  Key points

  • A retry cap exists to guarantee termination, not to save money — two rejections, three executions total
  • Rejections must carry specific, actionable reasons written back into the subtask goal; not good enough guarantees an identical resubmission and a maxed-out cap
  • The most dangerous failure is a reviewer sharing model and prompt with the executor: it approves its own output, pass rates inflate, and the step becomes theatre
  • Mitigate with an objective checkable rubric, a different model for review, and item-by-item scoring instead of a single verdict
  • The framework's recursion limit is a fuse, not a business cap: it is graph-wide and it throws, so you lose the partial results you meant to degrade to
  • When the cap is spent, return what you have with a degraded flag plus the last review comment so the layer above can escalate

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

• 长对话做摘要时，怎么保证关键信息不丢？在多 Agent 场景下这件事有什么特别的？When summarizing a long conversation, how do you keep the critical information from being lost — and what is different about this in a multi-agent system?

  国内高频海外高频进阶#context-compression#multi-agent#reliability

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

  1. 题眼在后半句。只答「保留用户约束、保留最近几轮」是单 Agent 的标准答案，能过但不出彩；面试官问「多 Agent 有什么特别的」，是在看你有没有真的在协作图里踩过这个坑。
  2. 先把单 Agent 那半答扎实：触发用阈值不用定时器，本课口径是消息超过 20 条或估算超过 8000 token（一个字符算一个 token，故意高估，低估会让阈值永远触发不了）；保留最近 6 条原文不动；切口必须对齐到一轮的开头，切在工具调用与工具结果之间会让下一次请求出现悬空消息，多数厂商直接返回 400。
  3. 然后给出多 Agent 那半的关键差别：单 Agent 里摘要丢的是**细节**，多 Agent 里摘要丢的是**判据**。评审者判一份产出合不合格，靠的是分清「这句是待验收的产出、那句是验收要求」；一段把发言人抹平的流水摘要读起来通顺，但评审拿它做不了任何判断。
  4. 所以多 Agent 的摘要有一条额外硬要求：每条被压掉的消息，在摘要里都要留下「第几条 + 谁说的」这两个坐标。实现只有一行——把转录写成带序号和角色前缀的形式再交给模型。
  5. 再补一条边界，这条最能显出你写过：**摘要只对自然语言历史动手，不碰任何结构化字段**。把共享工作区压成一句话，「按 id 找到某条子任务、比对验收要求」就整个失效了，结构化数据压成自然语言就再也回不去。附件字段更是碰不得——它存的是引用不是内容，摘要掉等于把那个对象变成孤儿。
  6. 可以预期的追问：摘要用哪个模型、失败了怎么办？答可以用更便宜的小模型（它只做归纳不做推理），失败时的正确行为是**跳过这一轮压缩继续跑**并告警，而不是让整次执行失败——阈值定在七八成就是为了留出这次抢救余量。

  How to reason about it · think before answering

  1. The hinge is the second half. Answering only keep user constraints and the last few turns is the standard single-agent answer — passable, not memorable. Asking what is different in multi-agent is asking whether you have actually hit this in a collaboration graph.
  2. Get the single-agent half solid first: trigger on thresholds, never a timer. This course uses more than 20 messages or an estimated 8000 tokens, counting one character as one token — deliberately high, because underestimating means the threshold never fires. Keep the last 6 messages verbatim. Align the cut to a turn boundary: cutting between a tool call and its result produces a dangling message and most vendors return 400.
  3. Then name the real difference: in a single agent a summary loses detail; in a multi-agent graph a summary loses the criteria. A critic decides whether output passes by telling apart what is being reviewed from what the requirement was. A smooth narrative summary that flattens speakers reads fine and is useless to the critic.
  4. So multi-agent summarization has one extra hard requirement: every compressed message must leave behind two coordinates — its index and its speaker. The implementation is one line: build the transcript with numbered, role-prefixed entries before handing it to the model.
  5. Add the boundary that shows you have shipped this: summarize natural-language history only, never structured fields. Compressing the shared workspace into a sentence kills every lookup by task id and every comparison against an acceptance requirement, and structured data does not come back. Attachments are even more off-limits — they hold a reference, not content, so summarizing one orphans the underlying object.
  6. Expect the follow-up: which model writes the summary, and what if it fails? A cheaper small model is fine since the job is condensation, not reasoning. On failure the correct behaviour is to skip this round of compression, keep running, and alert — not to fail the whole execution. Setting the threshold at seventy or eighty percent exists precisely to leave that rescue room.

  答题要点

  • 触发用阈值不用定时器：超过 20 条或估算超过 8000 token，token 按一字符一 token 保守高估
  • 保留最近 6 条原文不动，切口必须对齐到一轮开头，否则会出现有调用没结果的悬空消息、请求直接 400
  • 多 Agent 的差别：摘要丢的不是细节而是判据，评审者靠「谁在第几步说的」区分产出与验收要求
  • 所以每条被压掉的消息都要在摘要里留下条号与发言人，实现就是把转录写成带序号和角色的形式
  • 只压自然语言历史，不碰共享工作区这类结构化字段，更不能碰存引用的附件字段
  • 摘要可用更便宜的小模型；摘要调用失败时跳过这一轮压缩并告警，不要让整次执行失败

  Key points

  • Trigger on thresholds, not timers: more than 20 messages or an estimated 8000 tokens, counting one character as one token to stay conservative
  • Keep the last 6 messages verbatim and align the cut to a turn boundary, or you ship a dangling tool call and the request 400s
  • The multi-agent difference: a summary loses criteria, not just detail — the critic needs to know who said what and at which step
  • So every compressed message keeps its index and speaker in the summary; the implementation is a numbered, role-prefixed transcript
  • Summarize natural-language history only — never the shared workspace or other structured fields, and never the attachment references
  • A cheaper small model is fine for summarizing; if the call fails, skip compression for this round and alert rather than failing the run
• 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

D19 跨服务 Agent 集成：用户级 JWT 铸造、JWKS 验签、inject/memory/usage 三类接口、幂等 externalId

• 两个服务之间调用，你会用服务级令牌还是用户级令牌？分别适用于什么场景？For service-to-service calls, would you use a service token or a user token? When does each apply?

  国内高频海外高频进阶#auth#security#api-design

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

  1. 题眼在「分别」。答「用户级更安全」就把一道设计题做成了口号题——面试官想看你能不能说出两者各自成立的条件，以及选错的具体代价。
  2. 先给判断依据，一句话就能拆开：这次调用**有没有一个具体的用户在背后**。有，就必须是用户级；没有（拉配置、上报指标、跑对账批处理），服务级才是对的，硬塞一个用户 id 进去反而是伪造审计记录。
  3. 然后把用户级的三条理由说成代价而不是优点：服务级令牌泄露一次等于全量用户数据泄露，用户级泄露一张只丢一个用户且十五分钟自动作废；服务级在审计日志里只能查到「某服务调了一次」，查不到替谁操作；下游做用户级权限判断时，服务级令牌逼着它去信请求体里的 userId，而那是调用方可以随便写的。
  4. 补一句生产视角：两者不是二选一，真实系统里常常是「服务级令牌用来换用户级令牌」——调用方先用自己的服务凭证证明自己是谁，再申请一张代表某个用户的短期令牌。这样服务凭证只出现在铸造这一步，不出现在每一次业务调用里。
  5. 可以预期的追问一：令牌泄露了怎么办？答案要分两层——短有效期（本课 15 分钟）是止损的主力，撤销列表按 jti 拉黑是补充；不要上来就说「用黑名单」，那等于给每次验签加一次数据库查询，把无状态验签的好处全赔进去了。
  6. 可以预期的追问二：那 scope 该切多细？给一条可操作的判据——按「读写不对称的风险」切，读错了泄露信息、写错了污染数据且会持续影响后续每一轮对话，所以 read 和 write 必须分开；再细就要看有没有真实的调用方只需要其中一半。

  How to reason about it · think before answering

  1. The hinge is each. Answering user tokens are safer turns a design question into a slogan — the interviewer wants the conditions under which each one is correct, and the concrete cost of choosing wrong.
  2. Give the deciding question first: is there a specific user behind this call? If yes, it must be a user token. If not — fetching config, reporting metrics, running a reconciliation batch — a service token is the right answer, and stuffing in a user id would fabricate audit history.
  3. Then state the three reasons as costs, not virtues. A leaked service token means every user's data at once; a leaked user token means one user, and it expires in fifteen minutes. Audit logs with a service token only show that some service called, never on whose behalf. And a downstream service doing per-user authorization is forced to trust a userId in the request body, which the caller writes freely.
  4. Add the production view: it is rarely either-or. Real systems use the service credential to obtain user tokens — the caller proves who it is once, then mints a short-lived token representing one user. The service credential then appears only at the minting step, never on every business call.
  5. Expect: what if a token leaks? Answer in two layers — a short lifetime (fifteen minutes here) does most of the containment, and a jti denylist is the supplement. Do not lead with a denylist: it puts a database lookup in front of every verification and gives away the whole point of stateless verification.
  6. Expect: how fine-grained should scopes be? Offer a usable rule — split along asymmetric risk. A bad read leaks information; a bad write poisons data that keeps influencing every later turn. So read and write always split; finer than that only if a real caller genuinely needs just one half.

  答题要点

  • 判断依据是「这次调用背后有没有一个具体用户」：有就用用户级，没有（配置、指标、对账批处理）才用服务级
  • 服务级令牌泄露的爆炸半径是全量用户，用户级只影响一个用户且短期自动失效
  • 审计要能落到人：只有 sub 字段能回答「当时是替谁操作的」
  • 下游要做用户级权限判断时，服务级令牌逼着它去信请求体里的 userId，而那是调用方可以伪造的
  • 生产里常见组合：服务凭证只用来换取代表某个用户的短期令牌，不出现在每次业务调用里
  • 泄露后的止损顺序是短有效期优先、jti 撤销列表补充，别一上来就上黑名单换掉无状态验签

  Key points

  • The deciding question is whether a specific user stands behind the call: yes means user token, no (config, metrics, reconciliation) means service token
  • A leaked service token exposes every user; a leaked user token exposes one and expires on its own
  • Auditing has to reach a person — only the sub claim answers who the call was made on behalf of
  • With a service token the downstream must trust a userId in the request body, which the caller can forge
  • Common production shape: the service credential only buys short-lived per-user tokens and never appears on business calls
  • After a leak, short lifetimes do the containment and a jti denylist supplements it — do not trade away stateless verification by default
• 跨服务调用的幂等键该怎么设计？由谁生成、存在哪、重复了返回什么？How do you design an idempotency key for cross-service calls — who generates it, where does it live, and what do you return on a repeat?

  国内高频海外高频进阶#idempotency#distributed-systems#api-design

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

  1. 这题的区分度全在实现细节上。概念谁都会说，能不能答对「谁生成、存在哪、返回什么」这三个具体问题，直接暴露你有没有真做过。
  2. 先立一条铁律：**幂等的最终裁判必须是数据库的唯一约束**，不是应用层的「先查一下有没有」。先查后插在单进程测试里永远是对的，一上多实例就出双份——两个副本同时查、同时发现没有、同时插入，这个时间窗压测时窄到复现不出来，上线后每天出几条脏数据。
  3. 再答「谁生成」：由**调用方**生成，因为只有它知道重试的那两次是同一件事；但键必须由事件内容决定，不能是每次重试重新生成的随机 UUID——那等于没有幂等。这条和 D8 的用户消息幂等是同一条判据。
  4. 跨服务比同服务多一个坑，这是本题最有价值的一点：**调用方给的 id 不能直接当键用**。两个不同的调用方各自造出 evt-1 是迟早的事，撞车之后的表现不是报错，而是后来那个用户静默收不到消息——他的事件被当成重复丢掉了，日志里干干净净。所以落库前要加命名空间，用「签发方 + 用户 id + 事件 id」三段拼，而且三段都取自验签后的令牌，伪造不了。
  5. 「返回什么」也是个坑：重复送达要返回 200 并附上第一次的结果，不要返回 409。重复不是错误，是分布式系统的常态；回 409 会让调用方的重试逻辑把它当失败处理，越重试越乱。
  6. 可以预期的追问：这张表会不会无限涨？答「会，所以要有保留期」——按业务能接受的重放窗口设一个 TTL（比如 7 天）定期清理，同时说明清理之后超期的重复请求会被当成新事件，这是一个明确的、可接受的取舍，不是漏洞。

  How to reason about it · think before answering

  1. This question separates people entirely on implementation detail. Anyone can define idempotency; answering who generates the key, where it lives, and what a repeat returns shows whether you have actually built one.
  2. Start with the rule: the final arbiter must be a database uniqueness constraint, not an application-level check-then-insert. Check-then-insert always passes single-process tests and produces duplicates the moment you run two replicas — both check, both find nothing, both insert. The window is too narrow to reproduce under load testing and wide enough to produce dirty rows daily in production.
  3. Who generates it: the caller, because only the caller knows that two retries are the same event. But the key must be derived from the event itself, never a fresh random UUID per retry — that is idempotency in name only. Same criterion as the user-message case from day 8.
  4. Cross-service adds one trap worth the most points: never use the caller's raw id as the key. Two different callers will eventually both produce evt-1, and the failure is not an error — the second user silently receives nothing, because their event is treated as a duplicate and the logs look clean. Namespace it: issuer plus user id plus event id, all three taken from the verified token so none of them can be forged.
  5. What to return also matters: a repeat gets 200 with the original result, not 409. Repeats are normal in distributed systems; a 409 makes the caller's retry logic treat it as a failure and the situation compounds.
  6. Expect: does this table grow forever? Yes, so give it a retention window — a TTL matching the replay window the business tolerates, say seven days, with periodic cleanup. Say plainly that a duplicate arriving after cleanup is treated as new; that is a stated trade-off, not a hole.

  答题要点

  • 最终裁判是数据库唯一约束加 on conflict do nothing，先查后插在多实例下必然出双份
  • 键由调用方生成，但必须由事件内容决定，随机 UUID 等于没有幂等
  • 调用方给的 id 不能直接当键：加命名空间（签发方 + 用户 id + 事件 id），三段都取自验签后的令牌
  • 撞车的后果不是报错而是另一个用户静默收不到消息，日志里看不出异常
  • 重复送达返回 200 加第一次的结果，不要返回 409，否则调用方会当失败继续重试
  • 幂等表要设保留期，超期后的重复会被当成新事件，这是明确取舍不是漏洞

  Key points

  • The arbiter is a unique constraint plus on conflict do nothing; check-then-insert duplicates as soon as you run two replicas
  • The caller generates the key, but it must be derived from the event — a fresh UUID per retry is not idempotency
  • Never use the caller's raw id: namespace it with issuer plus user id plus event id, all taken from the verified token
  • A collision does not raise an error; it silently drops another user's event and leaves clean logs
  • Return 200 with the original result on a repeat, never 409, or the caller's retry logic treats success as failure
  • Give the table a retention window and state that post-cleanup repeats count as new events — a stated trade-off, not a hole

D20 定时 Job 与主动关怀：时区、quiet hours、每日上限、通知 provider 抽象

• quiet hours 和每日发送上限这两条规则你会怎么实现？它们应该放在链路的哪一步判断？How would you implement quiet hours and a per-user daily cap, and where in the pipeline should they be evaluated?

  国内高频海外高频进阶#rate-limiting#quiet-hours#cost-control

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

  1. 这题有两个题眼，很多人只答了前一个。第一个是「怎么判断」（细节题），第二个是「放在哪一步」（架构题），后者才是拿分点。
  2. 先讲 quiet hours 的判断。把时刻折成从午夜起算的分钟数之后，绝大多数人第一次都会写成 start 小于等于 now 且 now 小于 end。这对午休那种同日区间是对的，对 22:00 到 08:00 恒为 false——start 是 1320、end 是 480，条件永远不成立，于是半夜照发。正确写法是 start 小于 end 时用「且」，start 大于 end（跨午夜）时换成「或」。这个 bug 恶劣在只在跨午夜的配置上错，用 13:00 到 14:00 写的单元测试全绿。
  3. 接着是命中之后怎么办：推迟，不是丢弃。判据不该由发送方临时决定，而应该由消息自己带一个过期时刻——过期时刻早于窗口结束的丢弃，其余一律推迟到窗口结束。限时取消提醒过了今晚就没意义，账单提醒明早发一样有效。另外要提一句惊群：所有推迟的消息会算出同一个到期时刻，要加一个按用户标识哈希得出的抖动（不能用随机数，否则线上复现不了）。
  4. 再讲每日上限的两个细节。一是「一天」必须是**用户本地日历日**，写成 UTC 日的话东八区用户早上八点前发的会算进昨天的额度。二是必须先占坑再判断——原子自增拿返回值比上限，超了再把名额还回去；先查后写在并发下两条候选会同时读到同一个值然后一起发出去。渠道明确拒绝时也要把名额还回去。
  5. 最后是架构题那一半，也是最值钱的一段：三道闸必须在**生成内容之前**判断，不是在发送那一步。顺序错了程序照样跑通、发出的消息也一样，唯一区别是每条被拦下的消息你都已经付过一次模型调用的钱。按 1000 用户每天各 3 条候选、拦掉四成、单条约 0.00075 美元算，一个月白花约 27 美元，比这批用户的正常对话开销还高，而且监控上完全看不出来——只有把候选数和实际发送数并排摆出来才看得见差额。
  6. 可以预期的追问：三道闸内部谁先谁后？答时区、安静时段、每日上限，上限必须最后。因为被安静时段推迟的消息明早才发，不该占掉今天的名额；顺序反了用户会发现自己明明没收到几条却被限流了。

  How to reason about it · think before answering

  1. There are two hinges here and most candidates only answer the first. One is how to evaluate the rules (a details question), the other is where in the pipeline (an architecture question) — the second is where the points are.
  2. Start with quiet hours. Once you fold times into minutes-from-midnight, almost everyone first writes start less-or-equal now and now less-than end. That is correct for a same-day window like a lunch break, but for 22:00 to 08:00 it is always false: start is 1320, end is 480, the condition never holds, and you push at 3am. The fix is to use and when start is before end, and or when start is after end. What makes this bug nasty is that it only misfires on the cross-midnight config, so a unit test written around 13:00 to 14:00 passes.
  3. Then what to do on a hit: defer, do not drop. The decision should not be the sender's mood — attach an expiry to each candidate and drop only when it expires before the window ends, deferring everything else to the window's end. A thirty-minute cancellation warning is worthless tomorrow; a billing summary is just as valid at 8am. Mention the thundering herd too: every deferred message resolves to the same due instant, so add jitter derived from a hash of the user id, never a random number, or you cannot reproduce incidents.
  4. Now two details on the daily cap. First, the day must be the user's local calendar day; keying on the UTC date charges an East-Asian user's 8am message to yesterday's budget. Second, increment first and check the returned value, then give the slot back if it exceeded — a read-then-write races, letting two candidates read the same count and both go out. Return the slot on a hard rejection from the channel as well.
  5. Finish with the architecture half, which is the valuable part: all three gates must run before the content is generated, not at the send step. Get the order wrong and the program still works and sends the same messages; the only difference is that you paid for a model call on every message you then threw away. At 1000 users, three candidates each per day, forty percent blocked and roughly $0.00075 per message, that is about $27 a month wasted — more than the normal conversational spend for the same cohort — and it is invisible in monitoring. Only putting candidate count next to sent count reveals the gap.
  6. Expect: what order do the three gates run in? Timezone, quiet hours, daily cap, with the cap last. A message deferred to tomorrow morning must not consume today's quota; reverse the order and users get rate-limited despite having received almost nothing.

  答题要点

  • 跨午夜的安静时段：start 小于 end 用「且」，start 大于 end 换成「或」，朴素写法对 22:00-08:00 恒为 false
  • 命中安静时段是推迟到窗口结束而不是丢弃；只有自带的过期时刻早于窗口结束才丢
  • 推迟会造成惊群，要加按用户标识哈希得出的抖动，不能用随机数
  • 每日上限的「天」必须是用户本地日历日，不是 UTC 日
  • 计数要先占坑再判断（原子自增后比上限，超了还回去），先查后写在并发下会超发
  • 三道闸必须在生成内容之前判断，装晚了每条被拦的消息都已经付过模型调用的钱（示例量级约 27 美元每月）；闸内顺序是时区、安静时段、每日上限，上限最后

  Key points

  • Cross-midnight quiet hours need or when start is after end; the naive and version is always false for 22:00-08:00
  • On a hit, defer to the end of the window rather than drop; only drop when the message's own expiry precedes that
  • Deferral causes a thundering herd, so add jitter hashed from the user id, never a random value
  • The day in a daily cap must be the user's local calendar day, not the UTC date
  • Increment atomically then compare and release on overflow; read-then-write over-sends under concurrency
  • Run all three gates before generating content — otherwise every blocked message has already been paid for (about $27/month at the example scale); order them timezone, quiet hours, daily cap, with the cap last
• 模型调用、支付、通知渠道你都做过 provider 抽象。通知这一份接口和另外两份有什么不同？You have abstracted model calls, payments and notification channels behind providers. How does the notification interface differ from the other two?

  国内高频海外高频进阶#provider-abstraction#api-design#retry-semantics

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

  1. 这题在考你是「会套模式」还是「懂模式」。把三者说成一回事——都是接口加多个实现、换厂商不改业务——只答到了共性那一层，面试官真正想看的是你有没有识别出差异并把它写进接口。
  2. 先给共性，一句话带过：都是把「会被替换的东西」推到接口后面，业务代码只认接口，选择点集中在一处。这一层是对的，但不构成区分度。
  3. 然后给三条差异，这是拿分点。第一，收下不等于送达：支付网关返回成功钱就划走了，通知渠道返回成功只表示它收下了，真正送达是过一会儿通过回执异步告诉你的。所以返回值只能叫 accepted 不能叫 delivered，而且必须带渠道侧的消息标识，回执回来时靠它对上号。
  4. 第二，限流的层次不同：渠道自带每秒条数上限并会用 429 加重试间隔告诉你稍后再来，这是**渠道维度的技术约束**；而每日发送上限是**用户维度的礼貌约束**。两者混成一个概念就没法分别调整——一个说的是这条线路挤不下了，一个说的是这个人今天已经被打扰够了。
  5. 第三，没有撤销：支付有退款，通知发出去就撤不回来，取消只在交给渠道之前有效。所以接口里不能出现 cancel——在接口上留一个做不到的操作比根本没有这个操作更危险，调用方会真的去用它。
  6. 可以预期的追问：那失败重试怎么设计？答分三类：限流按渠道给的时长退避重试；参数错（正文非法、用户已退订）不可重试，直接放弃并把当天的名额还回去；服务端错误或超时可重试但必须带同一个幂等键——数据库里多一行你能删掉，用户手机上多响一声删不掉。再补一条判断抽象好坏的判据：新接一个渠道时如果它只需要实现「把这条消息发出去」，抽象就对了；如果它还得知道现在是不是安静时段、这是今天第几条，说明业务规则泄进了渠道层。

  How to reason about it · think before answering

  1. This question separates applying a pattern from understanding one. Saying all three are the same — an interface with several implementations so you can swap vendors without touching business code — only covers the shared part; the interviewer wants to see whether you spotted the differences and encoded them in the interface.
  2. Acknowledge the commonality in one line: each pushes a replaceable dependency behind an interface, business code depends only on the interface, and the selection point lives in exactly one place. Correct, but not differentiating.
  3. Then give three differences, which is where the points are. First, accepted is not delivered: when a payment gateway returns success the money has moved, but when a notification channel returns success it has merely taken the message, and actual delivery arrives later as an asynchronous receipt. So the result is accepted, never delivered, and it must carry the provider-side message id so the receipt can be correlated.
  4. Second, throttling lives at a different layer: the channel has its own per-second ceiling and tells you to come back later with a 429 plus a retry interval — a channel-level technical constraint — while the daily cap is a user-level courtesy constraint. Collapsing them into one concept makes them impossible to tune separately: one says this line is congested, the other says this person has been interrupted enough today.
  5. Third, there is no undo: payments have refunds, notifications do not. Once handed to the channel the message is gone, and cancel only means anything before that handoff. So the interface must not expose a cancel method — leaving an operation that cannot work is worse than not having it, because callers will actually use it.
  6. Expect: how do you design retries then? Three classes. Throttling backs off for the interval the channel gave you. Parameter errors (invalid body, unsubscribed user) are not retryable, so give up and return the daily slot. Server errors and timeouts are retryable but must carry the same idempotency key — you can delete a duplicate row, you cannot un-buzz a phone. Add a test for the abstraction itself: if a new channel only has to implement send the message, the boundary is right; if it also needs to know whether it is quiet hours or which message of the day this is, business rules have leaked into the channel layer.

  答题要点

  • 共性是把可替换依赖推到接口后面、选择点集中一处，但这只是及格线
  • 收下不等于送达：返回值叫 accepted 不叫 delivered，必须带渠道侧消息标识以便异步回执对号
  • 限流分两层：渠道的每秒上限是技术约束，每日发送上限是用户维度的礼貌约束，不能合并
  • 通知没有撤销，接口里不能有 cancel；留一个做不到的操作比没有更危险
  • 重试分三类：限流按渠道给的时长退避、参数错不可重试并归还名额、服务端错误可重试但必须带同一个幂等键
  • 判断抽象切没切对：新渠道只需实现发送就对了，还要知道安静时段和当天条数就说明业务泄进了渠道层

  Key points

  • The shared part is pushing a replaceable dependency behind an interface with a single selection point — that is only the baseline
  • Accepted is not delivered: name the result accepted and carry a provider message id so async receipts can be correlated
  • Throttling has two layers: the channel's per-second ceiling is technical, the daily cap is a user-level courtesy rule, and they must stay separate
  • Notifications have no undo, so the interface must not expose cancel — an unimplementable operation is worse than none
  • Three retry classes: back off for the channel's interval on throttling, give up and release the slot on parameter errors, retry server errors with the same idempotency key
  • Test the boundary: a new channel should only implement send; needing to know quiet hours or today's count means business rules leaked into the channel

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

• 怎么评估一个 Agent 的效果？和传统后端服务的测试有什么不同？How do you evaluate an agent's quality, and how does it differ from testing a conventional backend service?

  国内高频海外高频进阶#evaluation#testing#agent-quality

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

  1. 题眼是「不同」。只答「建一个测试集跑准确率」拿不到分——那是机器学习的标准答案，面试官想看你能不能说清 Agent 这个场景特殊在哪。
  2. 根子上的差别只有一句：**同样的输入，Agent 不保证给同样的输出**。传统测试的断言是「等于」，而 Agent 的产出没有唯一正确答案，只有「够不够好」。断言从等值变成了判分，整套方法论跟着变。
  3. 这条差别连锁出三个后果，说全了这题就稳了：一是**跑没跑通判断不了质量**——流程没抛错，不等于回复里写明了退款结论；二是**改动的影响是弥散的**，改一个字的提示词可能只影响一类请求，人肉抽查五条恰好没覆盖到，你会得出「没影响」然后上线；三是**多 Agent 又难一层**，一次请求走路由、拆分、并行执行、评审、汇总五道工序，任何一道歪了都表现成「最后那段话不太对」，不分开量就不知道该改哪块。
  4. 所以给出定位：**评估不是测试，评估是给一个随机系统建立一条可比较的基线。** 它的产物不是「通过」或「不通过」，而是一个能和上一次比的数字。既然要比，样本集就必须固定。
  5. 然后落到具体做法：一个小而稳的 golden set（本课 15 条），每条写清期望走哪条路由和一份必备信息清单；用 LLM-as-judge 对照清单打分；把评估结果和链路追踪接到同一块面板上。**清单是关键**——它把「这答得好吗」这种没法验的问题，换成了「这几件事写没写」这种能验的问题。
  6. 可以预期的追问：那还需要单元测试吗？需要，而且分工很清楚——工具函数、状态迁移、reducer 这些确定性的部分照旧用单元测试断言等值，评估只负责模型产出那一段。把两者混成一套，你会得到一堆随机失败的测试，然后所有人开始无视 CI。

  How to reason about it · think before answering

  1. The hinge is differ. Answering build a test set and measure accuracy is the textbook ML answer and misses the point; the interviewer wants to know whether you can articulate what makes agents special here.
  2. The root difference is one sentence: the same input does not guarantee the same output. Conventional tests assert equality, but an agent's output has no single correct answer, only good enough. Once the assertion changes from equality to scoring, the whole methodology changes with it.
  3. That difference cascades into three consequences, and covering all three secures the question. First, whether it ran tells you nothing about quality — the flow not throwing does not mean the reply stated the refund conclusion. Second, the blast radius of a change is diffuse: a one-word prompt edit may affect only one class of request, and hand-checking five samples that happen to miss that class yields no impact, then you ship. Third, multi-agent adds a layer: one request passes routing, planning, parallel execution, review and aggregation, and any one of them going wrong surfaces as that last paragraph seems off — without measuring each stage you cannot tell which to fix.
  4. So frame it: evaluation is not testing. Evaluation establishes a comparable baseline for a stochastic system. Its output is not pass or fail but a number you can compare against last time — and to compare, the sample set must be frozen.
  5. Then get concrete: a small stable golden set (15 items here), each declaring its expected route and a checklist of facts the reply must contain; an LLM-as-judge scoring against that checklist; and evaluation results joined to tracing on one dashboard. The checklist is the key move — it converts is this a good answer, which cannot be verified, into were these facts stated, which can.
  6. Expect: do you still need unit tests? Yes, with a clean split — deterministic parts (tool functions, state transitions, reducers) keep asserting equality in unit tests, while evaluation covers only the model-generated segment. Merge the two and you get a suite that fails randomly, after which everyone starts ignoring CI.

  答题要点

  • 根本差别：同样的输入 Agent 不保证同样的输出，断言从「等于」变成「够不够好」
  • 三个后果：跑通不等于质量合格、改动影响弥散（抽查会漏）、多 Agent 里五道工序任一歪了都表现成同一个症状
  • 定位：评估不是测试，是给随机系统建一条可比较的基线，产物是能和上次比的数字而不是通过与否
  • 做法：小而稳的 golden set + 每条的必备信息清单 + LLM-as-judge 打分 + 与 tracing 同源的面板
  • 清单是关键，它把「答得好吗」换成「这几件事写没写」，从没法验变成能验
  • 单元测试仍然需要，负责确定性部分；两者混在一起会让 CI 随机变红，最后被所有人无视

  Key points

  • The root difference: identical input does not guarantee identical output, so the assertion shifts from equality to good enough
  • Three consequences: running is not quality, change impact is diffuse (sampling misses it), and in multi-agent any of five stages failing looks like the same symptom
  • Framing: evaluation is not testing — it establishes a comparable baseline for a stochastic system, yielding a number rather than pass/fail
  • Method: a small stable golden set, a required-facts checklist per item, an LLM-as-judge, and a dashboard sharing tracing's data source
  • The checklist is the key move: it converts is this good into were these facts stated — unverifiable into verifiable
  • Unit tests remain for deterministic parts; merging the two makes CI fail randomly until everyone ignores it
• 多 Agent 系统的可观测性要看哪些东西？和单 Agent 有什么不一样？What does observability look like for a multi-agent system, and how does it differ from a single agent?

  国内高频海外高频进阶#observability#tracing#distributed-systems

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

  1. 题眼在「不一样」。答「加日志加监控」等于没答，要说清结构上的差别。
  2. 结构差别一句话：**单 Agent 的一次调用是一条线，多 Agent 是一棵树。** 一次请求走监督者路由、规划者拆三件、三个执行者并行、评审者打回一件、那件重跑、最后汇总——按时间平铺看不出谁在谁里面，也看不出哪两个是并行的。
  3. 所以 span 必须带**父指针**，这是全部关键：有它才是树，没它只是一张平铺列表，你知道发生过什么，却不知道谁触发了谁。一条 span 的字段少得出奇——id、父指针、名字、起止时刻、几个属性，就够还原整棵树。
  4. 父子关系怎么传下去也是个考点：**不要在每个函数上加一个 parentSpanId 参数**，每加一个节点都要改签名、漏一处断一截。用语言自带的隐式上下文——JS 的 AsyncLocalStorage、Python 的 contextvars、Swift 的 TaskLocal，Java 用 ScopedValue 或 ThreadLocal 配合线程池的显式传播。
  5. 然后说面板要回答哪四个问题：错了多少（通过率、路由准确率、降级率、兜底率）、慢在哪（p50/p95）、花了多少、**钱花在哪个角色身上**（按节点分摊）。最后一样是多 Agent 特有的，也最有用——实测执行者节点占了成本三分之一强，一眼就知道压成本先压哪儿。
  6. 还有一条地基性的：**面板不是另一套埋点，是 trace 的聚合**。同一份原始数据横着看是树、竖着堆是面板。两套数据来源迟早会对不上，然后没有人相信任何一个。
  7. 最后回指路由：路由决策是模型做的，同一句话下次未必给同样的答案，所以必须把**路由理由**一起记下来——当时不记，那次判断就永远丢了。这是多 Agent 里最容易漏、又最需要事后审计的一条。

  How to reason about it · think before answering

  1. The hinge is differ. Saying add logs and metrics is a non-answer; name the structural difference.
  2. In one sentence: a single agent's call is a line, a multi-agent request is a tree. One request goes supervisor routing, planner splitting into three, three executors in parallel, a critic rejecting one, that one rerunning, then aggregation — flattened by time you cannot see nesting or which two ran concurrently.
  3. So spans must carry a parent pointer; that is the whole game. With it you have a tree, without it a flat list where you know what happened but not what triggered what. A span needs surprisingly few fields — id, parent, name, start and end, a few attributes — to reconstruct the entire tree.
  4. How the parent propagates is itself an interview point: do not thread a parentSpanId parameter through every function, because each new node then changes a signature and one omission breaks the chain. Use the language's implicit context — AsyncLocalStorage in JS, contextvars in Python, TaskLocal in Swift, and ScopedValue or ThreadLocal with explicit propagation across thread pools in Java.
  5. Then the four questions a dashboard must answer: how much is wrong (pass rate, routing accuracy, degradation rate, fallback rate), where is it slow (p50/p95), what did it cost, and which role spent the money (cost attributed per node). That last one is multi-agent specific and the most actionable — measured, executor nodes took over a third of spend, telling you immediately where to optimise.
  6. One foundational point: the dashboard is not a second instrumentation layer, it is an aggregation of traces. The same raw data read across is a tree and stacked up is a dashboard. Two separate sources will eventually disagree, after which nobody trusts either.
  7. Finally, tie back to routing: the routing decision is made by a model and the same sentence may route differently next time, so the routing rationale must be recorded — if you do not capture it then, that judgement is gone forever. It is the easiest thing to omit and the thing most needing post-hoc audit.

  答题要点

  • 结构差别：单 Agent 一次调用是一条线，多 Agent 是一棵树（路由→拆分→并行执行→评审打回→重跑→汇总）
  • span 必须带父指针，否则只是平铺列表，看不出嵌套关系也看不出并行
  • 父子关系用语言自带的隐式上下文传（AsyncLocalStorage / contextvars / TaskLocal），不要在每个函数签名上加参数
  • 面板回答四个问题：错了多少、慢在哪、花了多少、钱花在哪个角色身上（最后一个是多 Agent 特有且最有用）
  • 面板必须是 trace 的聚合而不是另一套埋点，两套数据源迟早对不上
  • 路由理由必须记下来：路由是模型做的决策，当时不记那次判断就永远丢了

  Key points

  • Structural difference: a single agent call is a line, multi-agent is a tree (route, split, parallel execute, critic reject, rerun, aggregate)
  • Spans need a parent pointer, or you have a flat list showing neither nesting nor parallelism
  • Propagate parentage through implicit context (AsyncLocalStorage / contextvars / TaskLocal), not a parameter on every signature
  • The dashboard answers four questions: how much is wrong, where it is slow, what it cost, and which role spent it — the last is multi-agent specific and most actionable
  • The dashboard must be an aggregation of traces, not separate instrumentation; two sources will disagree
  • Record the routing rationale: routing is a model decision, and uncaptured it is lost forever
• 什么时候该用 LangGraph 这类编排框架，什么时候不该用？When should you reach for an orchestration framework like LangGraph, and when should you not?

  国内高频海外高频进阶#architecture#framework-selection#langgraph

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

  1. 这题最怕答成特性对比表。面试官想听的是判据，而且是能反过来说「不该用」的判据——只会说该用的人，通常是没被框架坑过的人。
  2. 先给三条该拆的判据（一条都不命中就别拆，也别引框架）：**提示词里出现了互斥的行为要求**（既要严谨又要俏皮，调好一个另一个就坏）；**工具多到选错率明显上升**；**某一步需要独立的失败与重试语义**（比如查库存失败该重试，拟退款方案失败该转人工，两者不能共用一套策略）。
  3. 然后给框架本身的判据，核心是一句：**要让多个角色并行写同一份状态，就必须显式；不需要并行，显式就是纯负担。** LangGraph 的价值是把合并规则声明在字段上——三个执行者并行写同一个工作区，谁的写入怎么合并，这件事必须有地方声明。反过来，一两个工具、循环最多两轮的场景，一个 while 加一个 switch 就够了，引入框架是净亏。
  4. 对比 Pi 这类高层 SDK 时，用维度而不是特性：上手成本（Pi 默认值多所以快，代价是模型和人设都是它替你挑的）、状态管理的显式程度（Pi 的历史在会话内部你感知不到，所以想改「同一个工作区怎么合并」时根本没有位置可改）、调试形态（Pi 给事件流是一条时间线，LangGraph 给逐节点增量和检查点是一棵可回放可分叉的树——**线性问题看时间线更快，多角色问题必须看树**）。
  5. 跨语言这条值得单独提，因为它常被忽略：**Java 和 Swift 都没有 LangGraph**，跨语言团队要么统一到 TS/Python，要么自己手写同一套结构。选框架的时候把这条算进去，比上线后再发现便宜。
  6. 可以预期的追问：那你怎么选？给一句可执行的：**你更怕看不见的默认值，还是更怕写不完的样板？** 怕前者选显式框架，怕后者选高层 SDK。这句话比任何特性表都实用。

  How to reason about it · think before answering

  1. The trap is answering with a feature matrix. The interviewer wants criteria, specifically criteria that can also say do not use it — people who can only argue for adoption usually have not been burned by a framework.
  2. Start with three criteria for splitting at all (if none holds, do not split and do not add a framework): the prompt contains mutually exclusive behavioural demands (rigorous and playful at once, where tuning one breaks the other); tools have grown numerous enough that selection error is visibly rising; or some step needs its own failure and retry semantics (an inventory lookup should retry, a refund draft should escalate to a human, and they cannot share one policy).
  3. Then the framework criterion, which is one sentence: if multiple roles write the same state concurrently, it must be explicit; if you do not need concurrency, explicitness is pure overhead. LangGraph's value is declaring merge rules on the field — with three executors writing one workspace, how those writes combine has to be declared somewhere. Conversely, with two tools and a loop that runs at most twice, a while and a switch suffice and a framework is a net loss.
  4. When comparing against a higher-level SDK like Pi, use dimensions rather than features: onboarding cost (Pi's defaults make it fast, at the price of it choosing your model and persona); explicitness of state (Pi keeps history inside the session, so when you want to change how one workspace merges there is no place to change it); and debugging shape (Pi gives an event stream, one timeline; LangGraph gives per-node deltas and checkpoints, a replayable and forkable tree — linear problems read faster as a timeline, multi-role problems require the tree).
  5. Cross-language deserves its own mention because it is routinely forgotten: neither Java nor Swift has LangGraph, so a polyglot team either standardises on TS/Python or hand-writes the same structure. Pricing that in during selection is cheaper than discovering it after launch.
  6. Expect: so how do you choose? Give something actionable: do you fear invisible defaults more, or endless boilerplate more? Fear the former and pick the explicit framework; fear the latter and pick the high-level SDK. That sentence is more useful than any feature table.

  答题要点

  • 先答该不该拆：提示词有互斥的行为要求、工具多到选错率上升、某步需要独立的失败与重试语义——一条不命中就别拆也别引框架
  • 框架判据一句话：多个角色并行写同一份状态就必须显式；不需要并行，显式就是纯负担
  • LangGraph 的价值是把合并规则声明在字段上；Pi 的历史在会话内部，想改合并方式根本没有位置可改
  • 调试形态不同：事件流是一条时间线，逐节点增量加检查点是一棵可回放可分叉的树；线性问题看时间线，多角色问题必须看树
  • Java 和 Swift 都没有 LangGraph，跨语言团队要么统一栈要么手写同一套结构，选型时就要算进去
  • 一句可执行的选型判据：更怕看不见的默认值就选显式框架，更怕写不完的样板就选高层 SDK

  Key points

  • First decide whether to split at all: mutually exclusive prompt demands, rising tool-selection error, or a step needing its own retry semantics — none holding means no split and no framework
  • The framework criterion in one line: concurrent writes to shared state require explicitness; without concurrency, explicitness is pure overhead
  • LangGraph's value is declaring merge rules on the field; Pi keeps history inside the session, leaving nowhere to change merge behaviour
  • Different debugging shapes: an event stream is a timeline, per-node deltas plus checkpoints are a replayable forkable tree — timelines for linear problems, trees for multi-role ones
  • Neither Java nor Swift has LangGraph, so polyglot teams standardise or hand-write the structure — price that in at selection time
  • An actionable heuristic: fear invisible defaults, choose the explicit framework; fear endless boilerplate, choose the high-level SDK

D22 安全：prompt injection、工具最小权限、沙箱思路、密钥管理

• Agent 要执行不受信任的代码或命令时，有哪些沙箱隔离思路？你们选了哪一档，为什么？When an agent has to run untrusted code or commands, what sandboxing options do you have? Which tier would you pick and why?

  国内高频海外高频进阶#sandboxing#security#tool-execution

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

  1. 这题的区分度不在于能背出几种隔离手段，而在于你说不说得出每一档挡住了什么、放过了什么。只说「我们用了沙箱」等于没说，面试官下一句一定是「那它挡得住外发数据吗」。
  2. 先说清这类工具为什么特殊：白名单管的是「能不能调」，但「执行一段你给的东西」这类工具一旦进了工具表，白名单就退化成一张通行证，因为危险面在参数里不在工具名里。所以要换一种手段——不判断这段代码坏不坏，而是收窄它能触碰的东西。这和权限侧强制是同一个思路，只是对象从工具换成了进程。
  3. 然后按代价从低到高给三档。进程级：独立子进程、超时必杀、环境变量白名单、只读工作目录；挡住崩溃传染、死循环挂住主进程、密钥被读走；挡不住网络外发和读系统里的其他文件。容器级：无网络、只读 rootfs、非 root、CPU 与内存限额、进程数限额、用完即弃；把外发和越界读写也挡掉；挡不住内核漏洞逃逸。microVM：独立内核的轻量虚拟机，挡住多数逃逸，代价是冷启动和成本。
  4. 给选型判据，这是面试官真正想听的：代码是你写的、只是参数不可信，进程级够用；代码本身来自模型或用户，最低容器级；要跑第三方任意代码还对外提供服务，上 microVM。
  5. 点一个高频实现坑：很多人起了子进程就以为隔离了，却把父进程的环境变量整个传过去——进程是独立了，密钥跟着过去了，子进程一句读环境变量就把 API key 打印出来。子进程的环境必须是白名单拷出来的新对象，而不是继承。
  6. 可以预期的追问：超时之后怎么办？要用能真正杀死进程的信号，并且把「被超时杀掉」当成一个独立的失败类型上报，而不是混进普通报错——它通常意味着有人在试资源耗尽，而不是代码写错了。

  How to reason about it · think before answering

  1. The spread here is not how many isolation techniques you can name, it is whether you can say what each tier stops and what it lets through. 'We use a sandbox' says nothing, and the next question will be 'does it stop data exfiltration?'
  2. First explain why these tools are special: an allowlist governs whether a tool may be called, but for a tool whose whole job is 'run this thing I hand you', the allowlist degrades into a hall pass, because the danger lives in the arguments rather than the name. So you switch technique — instead of judging whether the code is bad, you shrink what it can reach. Same idea as permission enforcement, applied to a process instead of a tool.
  3. Then give three tiers by cost. Process level: a separate child process, a hard timeout, an environment-variable allowlist, a read-only working directory; stops crash propagation, hung loops and secret theft; does not stop network exfiltration or reads elsewhere on the host. Container level: no network, read-only rootfs, non-root user, CPU/memory/pid limits, disposable per run; adds exfiltration and out-of-bounds access; does not stop a kernel escape. MicroVM: a lightweight VM with its own kernel, stops most escapes, at the price of cold start and cost.
  4. Give the selection rule, which is what the interviewer actually wants: if you wrote the code and only the arguments are untrusted, process level is enough; if the code itself comes from the model or a user, container level is the floor; if you run arbitrary third-party code as a service, go to microVM.
  5. Call out the classic implementation bug: people spawn a child process and assume they are isolated, then hand it the parent's entire environment. The process is separate but the secrets went with it, and one line reading an environment variable prints your API key. The child's environment must be a fresh object copied from an allowlist, never inherited.
  6. Expect the follow-up: what happens on timeout? Use a signal that actually kills the process, and report 'killed by timeout' as its own failure class rather than folding it into generic errors — it usually means somebody is probing for resource exhaustion, not that the code has a bug.

  答题要点

  • 执行类工具的危险面在参数里，白名单管不住，要靠隔离：不判断代码坏不坏，而是收窄它能触碰的东西
  • 进程级：子进程 + 超时必杀 + 环境变量白名单 + 只读工作目录；挡崩溃、死循环、密钥泄漏，挡不住外发
  • 容器级：无网络、只读 rootfs、非 root、CPU 内存与进程数限额、用完即弃；挡外发与越界读写，挡不住内核逃逸
  • microVM：独立内核，挡多数逃逸，代价是冷启动与成本；判据是代码来自谁、要不要对外提供服务
  • 最常见的实现坑是把 process.env 整个传给子进程——进程隔离了，密钥跟着过去了

  Key points

  • For execute-style tools the danger is in the arguments, so an allowlist cannot help; isolate instead — shrink what the code can reach rather than judging it
  • Process level: child process, hard timeout, environment allowlist, read-only workdir; stops crashes, hangs and secret theft, not exfiltration
  • Container level: no network, read-only rootfs, non-root, CPU/memory/pid limits, disposable; stops exfiltration and out-of-bounds access, not kernel escapes
  • MicroVM: own kernel, stops most escapes, costs cold start and money; choose by who wrote the code and whether you serve it publicly
  • The classic bug is handing the child process the whole parent environment — isolated process, leaked secrets
• Agent 系统里的密钥应该怎么管理？它绝对不能出现在哪些地方，轮换要怎么做才能不停机？How should secrets be managed in an agent system? Where must they never appear, and how do you rotate them without downtime?

  国内高频海外高频进阶#secrets-management#security#observability

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

  1. 这题看着是送分题，但有一个专属于 Agent 的答案点，答不出来就只是通用后端水平：密钥不能进 LLM 上下文。面试官问的是 Agent 系统，这一条就是他在等的。
  2. 先给四不入，一条一句：不入代码（写死在源码里等于给了所有有仓库读权限的人，而且删掉那一行 git 历史里还在）；不入日志（最高频的泄漏渠道，没人故意打印密钥，但「把请求头整个打出来方便排查」每个团队都干过）；不入 LLM 上下文；不入错误信息（返回给前端的报错和抛给上游的异常都是对外出口）。
  3. 把第三条展开，这是本题的差异点：密钥一旦进了上下文，就意味着它会被送到模型厂商、被存进会话历史、被写进 trace，然后在某一次提示词注入里被完整地念出来。正确的形态是 Agent 需要的是「能调用某个 API」这个能力，而不是那把钥匙本身——密钥留在工具的实现里，模型只看得到工具名和参数。
  4. 再给落地手段：日志出口统一脱敏，不靠调用方自觉。靠每个人写日志时记得手动打码，一定会漏。做法是在唯一的日志出口做替换，两条路一起用——进程里已知的密钥值整段替换，再用通用形状兜底那些不是从环境变量来的密钥。异常处理那一支也要走同一个出口，堆栈里经常夹着带密钥的连接串。
  5. 存储与轮换：本地开发用 .env 加 gitignore；线上走密钥管理服务，进程启动时按自己的身份去取，不要把值烤进镜像或写进部署清单。轮换要双活——同时允许新旧两把 key，流量切到新 key、观察到没有旧 key 的调用了再吊销，一次性替换必然在某个副本上留下失败窗口。
  6. 可以预期的追问：轮换周期定多久？周期是次要的，真正要演练的是「能不能在 5 分钟内换掉一把疑似泄漏的 key」。答得出这一句，说明你想的是事故响应而不是合规打卡。

  How to reason about it · think before answering

  1. It reads like a giveaway, but there is one answer point specific to agents, and missing it makes you sound like a generic backend engineer: secrets must never enter the LLM context. The interviewer asked about an agent system, and that is the line he is waiting for.
  2. Give the four 'nevers', one line each. Never in code — hardcoding hands the secret to everyone with read access, and deleting the line does not remove it from git history. Never in logs — the highest-frequency leak channel; nobody prints a secret on purpose, but 'log the whole request header so we can debug' is universal. Never in the LLM context. Never in error messages — responses to the frontend and exceptions thrown upstream are both outbound channels.
  3. Expand the third one, since it is what differentiates the answer: once a secret is in the context it will be sent to the model vendor, stored in conversation history, written into traces, and eventually read out loud by some prompt injection. What the agent needs is the capability to call an API, not the key itself — the key stays inside the tool implementation, and the model only ever sees the tool name and its arguments.
  4. Then the mechanics: redact at a single logging exit rather than trusting callers. Relying on everyone to mask by hand guarantees a miss. Do it in the one place logs leave the process, with two passes — replace known secret values from the environment, then catch the rest with generic shape patterns. Route the exception path through the same exit, because stack traces routinely carry connection strings with credentials.
  5. Storage and rotation: dotenv plus gitignore locally; in production a secret manager the process reads at startup under its own workload identity, never values baked into an image or a deployment manifest. Rotate dual-key: accept old and new simultaneously, shift traffic to the new one, confirm the old one has no remaining callers, then revoke. A single-shot swap always leaves a failure window on some replica.
  6. Expect the follow-up: how often do you rotate? The interval is secondary — what you should actually rehearse is whether you can revoke and replace a suspected-leaked key within five minutes. Saying that shows you are thinking about incident response rather than a compliance checkbox.

  答题要点

  • 四不入：不入代码、不入日志、不入 LLM 上下文、不入错误信息
  • Agent 特有的一条是不入上下文——进了上下文就会被送到厂商、存进历史、写进 trace，并可能被注入念出来
  • Agent 需要的是「能调用某个 API」的能力而不是钥匙本身，密钥留在工具实现里
  • 日志出口统一 redact，不靠调用方自觉；异常路径走同一个出口，堆栈里常夹着连接串
  • 线上走密钥管理服务按身份拉取；轮换用双活，新旧同时有效、切流量、确认无旧调用再吊销

  Key points

  • Four nevers: never in code, never in logs, never in the LLM context, never in error messages
  • The agent-specific one is the context — anything there reaches the vendor, the history and the traces, and can be read out by an injection
  • The agent needs the capability to call an API, not the key; the key stays inside the tool implementation
  • Redact at one logging exit instead of trusting callers, and route the exception path through it too
  • Use a secret manager with workload identity in production, and rotate dual-key: accept both, shift traffic, verify no old callers, then revoke

D23 MCP 与 Skills：协议、server/client、与 function calling 区别；Claude Agent SDK 一览

• MCP 里 server 和 client 分别承担什么角色？server 能暴露哪几类东西，传输方式有哪些？What roles do the MCP server and client play, what can a server expose, and which transports exist?

  国内高频海外高频进阶#mcp#protocol#transport

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

  1. 这题看着是背概念，实际区分度在两个小地方：一是能不能把宿主和 client 分开说，二是知不知道 tools 之外还有别的原语。只答「server 提供工具、client 调用工具」是及格线以下。
  2. 先把三个角色摆清楚：server 是能力提供方，一个独立进程；client 是宿主里负责跟某一个 server 说话的那一小块，一个 client 只连一个 server；宿主是你的 Agent 应用，它同时持有多个 client。很多人把宿主和 client 当成一个东西，一问「连三个 server 怎么办」就露馅。
  3. server 侧三种原语要一起说，并且要说清谁来选：tools 是可执行的动作，由模型来挑；resources 是按 URI 读的只读数据；prompts 是可复用的提示词模板，后两者通常由用户或宿主来挑。这句「谁来选」比原语名字本身更能体现你真读过协议——把一份大文档做成 resource 而不是 tool，等于把花不花这笔 token 的决定权从模型手里收回给人。
  4. client 侧也能声明能力让 server 反过来请求宿主：sampling 是让宿主跑一次模型补全，roots 是告诉 server 哪些目录可见，elicitation 是请宿主向用户要一条输入。知道有这三样、不展开，分寸刚好。
  5. 传输两种：stdio 用于本地子进程，Streamable HTTP 用于远程。这里有个时间戳式的加分点——旧的 HTTP 加 SSE 双端点传输已经被标为 legacy，只为兼容老客户端保留；把它当现行方案讲，等于告诉对方你看的是去年的文章。
  6. 可以预期的追问：stdio server 有什么特别要注意的？答 stdout 被 JSON-RPC 独占，所有日志必须走 stderr，否则 client 会收到解析不了的消息；另外子进程的生命周期归宿主管，退出时要杀掉，不然留一堆孤儿进程。

  How to reason about it · think before answering

  1. This looks like recall, but it discriminates on two small things: whether you separate host from client, and whether you know there are primitives beyond tools. 'Server provides tools, client calls them' is below the bar.
  2. Lay out three roles: the server is the capability provider and its own process; the client is the piece inside the host that talks to exactly one server; the host is your agent application, holding several clients at once. People who conflate host and client fall apart the moment you ask how they would connect to three servers.
  3. Cover all three server-side primitives and say who chooses each: tools are executable actions chosen by the model; resources are read-only data addressed by URI; prompts are reusable templates — the latter two are normally chosen by the user or host. That 'who chooses' framing shows you actually read the spec: modelling a large document as a resource rather than a tool moves the decision to spend those tokens from the model back to a human.
  4. The client side declares capabilities too, letting the server call back into the host: sampling asks the host to run a model completion, roots tells the server which directories are visible, elicitation asks the host to collect user input. Naming them without elaborating is the right level of detail.
  5. Two transports: stdio for a local subprocess, Streamable HTTP for remote. The dated detail worth knowing is that the older two-endpoint HTTP+SSE transport is now legacy, kept only for backwards compatibility — presenting it as current signals you read last year's blog posts.
  6. Expect the follow-up: anything special about stdio servers? Stdout is reserved for JSON-RPC, so every log line must go to stderr or the client receives unparseable messages; and the host owns the subprocess lifecycle, so it must reap the child on exit or leave orphans behind.

  答题要点

  • server 是能力提供方（独立进程），client 是宿主里连接单个 server 的那一块，宿主可以同时持有多个 client
  • server 侧三种原语：tools 由模型挑，resources 是按 URI 读的只读数据，prompts 是可复用模板，后两者通常由人来挑
  • client 侧还能声明 sampling、roots、elicitation，让 server 反过来请求宿主做事
  • 传输两种：stdio（本地子进程）与 Streamable HTTP（远程）；旧的 HTTP 加 SSE 已是 legacy，不要当现行方案讲
  • stdio server 的 stdout 被 JSON-RPC 独占，日志必须走 stderr；子进程生命周期由宿主负责回收

  Key points

  • The server is the capability provider in its own process; a client connects to exactly one server; the host holds many clients
  • Three server-side primitives: tools chosen by the model, resources as URI-addressed read-only data, prompts as reusable templates — the latter two usually chosen by a human
  • Clients can declare sampling, roots and elicitation so the server can call back into the host
  • Two transports: stdio for local subprocesses and Streamable HTTP for remote; the old HTTP+SSE transport is legacy
  • On stdio, stdout belongs to JSON-RPC so logs must go to stderr, and the host must reap the child process
• 什么场景下应该考虑用 MCP，而不是直接写 function calling？不该用的时候硬上会付出什么代价？When should you reach for MCP instead of plain function calling, and what does it cost when you shouldn't?

  国内高频海外高频进阶#mcp#architecture#trade-offs

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

  1. 题眼在后半句。只会说「MCP 更标准更解耦」的人，等于说「微服务更解耦」——听起来对，但没有判据，面试官会立刻追问「那你们所有工具都做成 MCP server 了吗」。
  2. 先给判据，而且要是可执行的三条：能力要被多个宿主复用、能力由另一个团队或第三方维护、需要不改宿主代码就能增删能力。命中任意一条才考虑，**一条都不命中就直接写本地函数**——把默认答案摆成「不上」，这条比三条判据本身更能体现工程判断。
  3. 每条判据配一句为什么：多宿主复用把 N 乘 M 变成 N 加 M；别人维护时进程边界就是责任边界，他们改他们的、你不用发版；热插拔让加一个内部工具从一次发布降级成一次配置变更。
  4. 然后老实说代价，这是区分「用过」和「读过」的地方：多一个进程要保活、多一次握手要处理超时与重连、排障链路从一段变三段——工具没被调用，现在可能是模型没选、可能是 schema 翻译时丢了字段、也可能是 server 压根没起来。stdio 的子进程还要你自己回收，否则留孤儿进程。
  5. 还有一条容易被忽略但很加分：MCP 不改变你的成本结构。工具描述照样每轮都进上下文，工具多了照样会让模型选错——D5 那条「工具超过一定数量就该合并描述」在接了 MCP 之后一字不变，甚至更需要，因为现在别人可以往你的工具列表里塞东西。
  6. 可以预期的追问：那内部工具一律不上 MCP 吗？不是。有一类值得例外——你希望它能被 IDE 里的助手和运维机器人一起用，那第一条判据就命中了，即使它是你自己维护的。

  How to reason about it · think before answering

  1. The hinge is the second half. Answering only 'MCP is more standard and decoupled' is like saying 'microservices are more decoupled' — true-sounding but with no criterion, and the interviewer will immediately ask whether you turned every tool into an MCP server.
  2. Give three actionable criteria: the capability must be reused by more than one host, owned by another team or a third party, or added and removed without changing host code. Any one of them justifies MCP; none of them means write a local function. Making 'no' the default answer shows more engineering judgment than the criteria themselves.
  3. Attach a reason to each: multi-host reuse turns N times M into N plus M; external ownership makes the process boundary the responsibility boundary, so their change is not your release; hot-swapping demotes adding an internal tool from a deployment to a config change.
  4. Then state the costs honestly, which is where shipped experience shows: another process to keep alive, another handshake with its own timeouts and reconnects, and a debugging path that went from one hop to three — a tool that never got called might mean the model did not pick it, the schema lost fields in translation, or the server never started. On stdio you also own reaping the child process.
  5. One more point that is easy to miss and scores well: MCP does not change your cost structure. Tool descriptions still enter the context every turn, and more tools still degrade tool selection. The rule that you should consolidate tools past a certain count survives MCP unchanged — arguably it matters more, because now other people can add entries to your tool list.
  6. Expect the follow-up: so internal tools never go through MCP? Not quite. If you want the same capability available to an IDE assistant and an ops bot as well, the first criterion is met even though you own the code.

  答题要点

  • 三条判据，命中任意一条才考虑 MCP：多宿主复用、由他人维护、需要不改代码增删能力
  • 默认答案是不上：三条都不命中就直接写本地函数，这是更好的工程决策
  • 代价是多一个进程要保活、多一次握手要处理超时、排障从一段链路变成三段
  • MCP 不改变成本结构：工具描述照样每轮进上下文，工具过多照样会让模型选错，该合并还是要合并
  • 第三方能力接进来之后，工具列表不再完全由你掌控，这本身就是需要设计的一件事

  Key points

  • Three criteria, any one justifies MCP: reuse across hosts, ownership by another team, or add/remove without touching host code
  • The default is no — if none of the three apply, a local function is the better engineering decision
  • Costs: another process to supervise, another handshake with timeouts, and a debug path that grows from one hop to three
  • MCP does not change your cost structure: descriptions still enter context every turn and too many tools still hurt selection
  • Once third-party capabilities are attached, your tool list is no longer fully under your control, which is itself a design problem

D24 RAG 进阶：hybrid search、rerank、引用、recall 评估

• 两路检索结果怎么合并？为什么不能直接加权求和？How do you merge two retrieval rankings, and why not just take a weighted sum of the scores?

  国内高频海外高频进阶#rag#rrf#ranking

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

  1. 题眼在后半句。前半句答「RRF」谁都会，后半句「为什么不能加权求和」才是筛人的地方——它考的是你有没有真的看过两路分数的分布。
  2. 怎么拆：先问自己两个分数是不是同一个量纲。余弦相似度有界（0 到 1）且分布密集，同一批候选常常只差 0.02；BM25 无上界，命中几个稀有词就能到 12 分。**不同量纲的数相加，等于让量纲大的那一路单方面决定结果**，权重只是在调「它说了算的程度」。
  3. 更麻烦的是它不稳定：权重在这批语料上调好了，换一批语料分布就变了，得重调。这是一个永远还不完的技术债。
  4. 结论：改用名次。RRF 把每一路的名次折算成 `1/(k + rank)` 再相加，k 取 60。名次是无量纲的，不需要任何标定。k 的作用是压平头部差距，让「两路都进前列」压过「一路排第一」——共识优先于单点自信。
  5. 一个能当场手算的例子很加分：两路排名 [a,b,c] 与 [c,d,a]，a 得 1/61 + 1/63 ≈ 0.0323；而分数直接相加的版本会把 BM25 里 12 分的 c 顶到第一。
  6. 可预期的追问：同分了怎么办？必须显式定序（比如按 id），否则结果取决于哈希表遍历顺序，同一份输入在不同语言、不同运行里给出不同排序——评估集量出来的数字也就不可复现了。这一条答出来会非常加分，因为它说明你真的跑过多次。

  How to reason about it · think before answering

  1. The second half is the real question. Anyone can say 'RRF'; explaining why weighted sums fail is what separates people who have looked at the score distributions.
  2. Decompose it: are the two scores even the same unit? Cosine similarity is bounded in 0 to 1 and tightly clustered — candidates often differ by 0.02. BM25 is unbounded and a few rare-term hits reach 12. Adding them lets the larger-magnitude channel decide everything; the weight only tunes how much it dominates.
  3. Worse, it is unstable. Weights tuned on one corpus drift on the next, so you re-tune forever.
  4. Conclusion: fuse ranks, not scores. RRF maps each rank to 1/(k + rank) and sums, with k = 60. Ranks are unitless and need no calibration. k flattens the head of the list so that 'top-ranked in both channels' beats 'first in one channel' — consensus over single-source confidence.
  5. A hand-checkable example helps: rankings [a,b,c] and [c,d,a] give a = 1/61 + 1/63 ≈ 0.0323, while a raw score sum promotes c on the strength of its BM25 12.
  6. Expected follow-up: what about ties? You must break them explicitly, e.g. by id. Otherwise ordering depends on hash-map iteration order and differs across languages and runs, which makes your evaluation numbers irreproducible. Mentioning this signals you actually ran it more than once.

  答题要点

  • 用 RRF：每一路的名次折算成 1/(k + rank) 再相加，k 取 60。
  • 不能加权求和是因为两个分数量纲不同——余弦有界密集、BM25 无上界，相加等于让 BM25 单方面决定结果。
  • 而且权重不可迁移：这批语料调好，换一批就得重调，是还不完的债。
  • 名次是无量纲的，不需要标定；k 压平头部差距，让两路共识压过单路自信。
  • 同分必须显式定序（按 id），否则结果依赖哈希表遍历顺序，评估数字不可复现。

  Key points

  • Use RRF: map each channel's rank to 1/(k + rank) and sum, with k = 60.
  • Weighted sums fail because the scores are different units — bounded, tightly clustered cosine versus unbounded BM25, so BM25 decides the outcome.
  • Weights also do not transfer: tuned on one corpus, they drift on the next.
  • Ranks are unitless and need no calibration; k flattens the head so cross-channel consensus outweighs single-channel confidence.
  • Break ties explicitly (by id) or ordering depends on hash iteration order and your evaluation numbers stop being reproducible.
• 重排（rerank）一般怎么实现？它解决了初步检索的什么问题，代价是什么？How is reranking usually implemented, what problem does it solve, and what does it cost?

  国内高频海外高频进阶#rag#rerank#latency

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

  1. 这题最容易答成「再排一次序，更准」。面试官想听的是**为什么第一轮不能直接排准**，以及**为什么重排不能对全库做**。
  2. 怎么拆：第一轮的排序依据是「检索信号」——余弦距离或词频统计，它们是为了能在百万条里快速筛选而设计的，代价就是粗。重排换了一种算法：把 query 和候选**拼在一起**送进同一个模型算相关度（cross-encoder），精度高得多，但复杂度是每条候选一次前向，没法对全库做。所以它必须跟在一个宽召回后面。
  3. 结论要区分两种实现：教学 / 原型可以用 LLM 批量打分（一次调用给 40 条打 0 到 10 分），生产用专门训练的 cross-encoder 重排模型。**代价说清楚：多一次 100 到 300 毫秒的调用，外加一台推理机器**——它不是按 token 计费的 API，是要占资源的。
  4. 把它放进漏斗里说最清楚：召回决定天花板，重排决定天花板上的东西能不能排到前五。实测的样子是——加了关键词那一路，recall@20 从 83% 涨到 95%（天花板抬高）；再加重排，recall@20 只到 98%，但 recall@5 从 80% 跳到 91%、MRR 从 0.732 到 0.908。
  5. 可预期的追问一：重排能不能提高召回？不能。它不引入新候选，只重排已有的那批——所以看 recall@20 判断重排效果是错的指标。
  6. 可预期的追问二：为什么不用 LLM 打分上生产？延迟不可控、成本按 token 走、分数会随提示词措辞漂移，而且没法做批量离线蒸馏。

  How to reason about it · think before answering

  1. The lazy answer is 'sort again, more accurately'. What the interviewer wants is why the first pass cannot rank well, and why reranking cannot run over the whole corpus.
  2. Decompose: the first pass ranks by retrieval signals — cosine distance or term statistics — which are designed to scan millions of items fast, and coarseness is the price. Reranking changes the algorithm: query and candidate go into one model together (a cross-encoder), which is far more accurate but costs one forward pass per candidate. Hence it must sit behind a wide recall stage.
  3. Distinguish two implementations. For teaching or prototypes, batch-score with an LLM (0-10 for 40 candidates in one call). Production uses a trained cross-encoder reranker. Name the cost: an extra 100-300 ms hop plus an inference box — it is not a per-token API, it consumes capacity.
  4. Framing it as a funnel is clearest: recall sets the ceiling, reranking decides whether what is under the ceiling reaches the top five. Measured: adding the keyword channel lifts recall@20 from 83% to 95%; adding reranking moves recall@20 only to 98%, but recall@5 jumps from 80% to 91% and MRR from 0.732 to 0.908.
  5. Expected follow-up 1: does reranking improve recall? No. It introduces no new candidates, so recall@20 is the wrong metric to judge it by.
  6. Expected follow-up 2: why not ship LLM scoring to production? Unpredictable latency, per-token cost, scores that drift with prompt wording, and no clean path to offline distillation.

  答题要点

  • 第一轮按检索信号粗排（余弦、词频），为的是能在大库里快速筛，代价是粗。
  • 重排把 query 和候选拼在一起过同一个模型（cross-encoder），精度高但每条一次前向，只能对几十条做。
  • 教学版可用 LLM 批量打 0 到 10 分；生产用专用重排模型，代价是多一次 100 到 300 毫秒的调用加一台推理机器。
  • 重排不提高召回，它提高的是 recall@5 与 MRR——实测 80% → 91%、0.732 → 0.908，而 recall@20 只从 95% 到 98%。
  • 所以判断重排效果要看前 k 小的指标，不要看 recall@20。

  Key points

  • The first pass ranks by retrieval signals so it can scan a large index fast; coarseness is the trade.
  • Reranking feeds query and candidate through one model together (cross-encoder): much sharper, but one forward pass per candidate, so only tens of items.
  • Batch LLM scoring works for teaching; production uses a dedicated reranker, costing an extra 100-300 ms hop plus an inference box.
  • Reranking does not raise recall — it raises recall@5 and MRR (measured 80% to 91%, 0.732 to 0.908) while recall@20 barely moves from 95% to 98%.
  • So judge a reranker by small-k metrics, never by recall@20.

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

• 流式场景下前端的状态管理要注意什么？为什么不能每个 token 都 setState？What is different about frontend state management under streaming, and why not call setState on every token?

  国内高频海外高频进阶#react#streaming#performance

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

  1. 这题考的是「你有没有在长回复下真的看过掉帧」。答「用 useState 存消息数组，收到 delta 就 setState」在功能上没错，但它暴露的是只在短回复上试过。
  2. 先算一笔账：流式一秒来几十个 token，每个 token 一次 setState 就是一秒几十轮完整渲染。而消息列表是越来越长的，每一轮的代价随对话轮数增长——所以卡顿在回复后半段和长会话里最明显，正好是最不该卡的时候。
  3. 做法是攒批：token 先追加进 ref（不触发渲染），一个定时器每 30 毫秒把攒下的一次性提交。30 毫秒约等于 33 帧每秒，肉眼仍是连续的打字机，渲染次数掉一到两个数量级——实测 200 个 token 只提交 8 次。
  4. 三个必须配套的细节：流结束时强制 flush 一次（否则最后不足一个批次的内容永远留在缓冲里，用户看到回复少半句）；打断时也要 flush（让用户看到停在哪个字）；缓冲状态必须放 ref 不放 state，否则你为了省渲染写的代码本身在触发渲染。
  5. 再往上一层是分层：**流式逻辑应该活在 React 外面。** 解析、事件归并、攒批都是纯函数，store 持有状态并暴露 subscribe 和 getSnapshot，React 侧只用 useSyncExternalStore 订阅。这样做的直接好处是**这套逻辑可以在没有浏览器的环境里跑单元测试**，而不是只能靠手点。
  6. 可预期的追问：为什么不直接用某个状态库？答：状态库解决的是跨组件共享和更新粒度，而流式的难点在生命周期（连接、取消、卸载清理）和批处理频率——这两件事没有哪个库替你做。面试官问这题想听的是你怎么想，不是你会用哪个库。

  How to reason about it · think before answering

  1. This question probes whether you have watched a long reply drop frames. 'Keep messages in useState and setState on each delta' is functionally correct but reveals you only tried short replies.
  2. Do the arithmetic first: streaming delivers tens of tokens per second, so one setState per token means tens of full render passes per second. The message list keeps growing, so each pass gets more expensive as the conversation goes — the jank peaks late in long replies and long sessions, exactly when it hurts most.
  3. The fix is batching: append tokens into a ref without rendering, and flush the accumulated text on a 30 ms timer. Thirty milliseconds is roughly 33 fps, still a smooth typewriter, while render count drops by one to two orders of magnitude — measured, 200 tokens produced 8 commits.
  4. Three details that must ship with it: force a final flush when the stream ends, or the last sub-batch stays in the buffer and the user sees a truncated reply; flush on interrupt too, so the user sees exactly where it stopped; and keep the buffer in a ref, not state, or the code you wrote to avoid renders is itself causing them.
  5. One level up is layering: streaming logic should live outside React. Parsing, event reduction and batching are pure functions; a store holds state and exposes subscribe and getSnapshot; React only calls useSyncExternalStore. The concrete payoff is that this logic can be unit tested with no browser instead of being click-tested.
  6. Expected follow-up: why not just use a state library? Libraries solve cross-component sharing and update granularity, while the hard parts here are lifecycle (connect, cancel, cleanup on unmount) and flush cadence — no library does those for you. The interviewer wants your reasoning, not your library list.

  答题要点

  • 每个 token 一次 setState 等于一秒几十轮全量渲染，而消息列表越长每轮越贵，长回复后半段必然掉帧。
  • 做法是攒批：token 进 ref 不触发渲染，30 毫秒定时 flush 一次，实测 200 个 token 只提交 8 次。
  • 必须配套：流结束和打断时强制 flush；缓冲放 ref 不放 state。
  • 流式逻辑（解析、归并、攒批）应该是 React 之外的纯函数，React 只用 useSyncExternalStore 订阅。
  • 这样分层的直接好处是能脱离浏览器做单元测试，而不是只能手点验证。

  Key points

  • One setState per token means tens of full renders per second, and each render costs more as the list grows — long replies jank at the end.
  • Batch instead: accumulate tokens in a ref and flush every 30 ms; measured, 200 tokens produced only 8 commits.
  • Ship the details with it: force a flush on stream end and on interrupt, and keep the buffer in a ref rather than state.
  • Keep parsing, event reduction and batching as pure functions outside React; subscribe via useSyncExternalStore.
  • The payoff of that split is unit-testable streaming logic with no browser in the loop.
• 失败重试怎么设计才不会产生重复副作用？工具调用过程要不要暴露给用户？How do you design retry so it does not duplicate side effects, and should the tool-call process be visible to the user?

  国内高频海外高频进阶#idempotency#retry#ux

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

  1. 这题把两件事绑在一起问，考的是你能不能看出它们的共同点：**都是「把不可见的中间状态变成可控的」**。分开答也行，但点出这层关系会显得成熟。
  2. 重试这一半的推导链：重试意味着同一句话可能被执行两遍 → 两倍 token，还可能两次不可逆的工具调用（比如退款打两次钱）→ 所以要幂等 → 幂等键必须由**客户端在第一次发送时生成**并在重试时原样带上 → 后端拿它做唯一约束，命中就把已有 run 的流接回来，而不是新建。
  3. 关键判据要说清：**什么时候该换新键？** 判据是「要发送的内容变没变」，不是「用户点了哪个按钮」。同一句话重试用同一个键；用户改了内容重新发，那是新的一句话，必须换新键。
  4. 顺带提一句这一招的复用面会很加分：落库去重、定时任务防止一个 tick 被消费两次、跨服务调用防重复投递、前端重试——同一个形状用在四个层面，最终裁判永远是数据库的唯一约束，不是应用层的先查后写。
  5. 工具可视化这一半：中间过程要暴露，理由有三条——用户能判断要不要打断（不然他只能盲等）；等待变得可以忍受（十几秒的转圈会让人刷新页面，而刷新意味着这一轮的钱白花）；出问题时用户能说清「卡在查订单那一步」，客服和你都省事。
  6. 可预期的追问：全都暴露会不会泄露内部实现？会，所以要过滤——工具名用人话不用函数名，参数里的用户标识、内部 id、密钥一律不显示，错误显示归类后的原因而不是原始堆栈。**可视化的是过程，不是内部结构。**

  How to reason about it · think before answering

  1. The question bundles two topics, and the test is whether you see what they share: both turn invisible intermediate state into something the user can act on. Answering them separately is fine, but naming the link reads as senior.
  2. Chain for retry: retrying means the same message may execute twice, costing double tokens and possibly duplicating irreversible tool calls such as issuing a refund twice. Hence idempotency. The key must be generated by the client on the first attempt and resent unchanged on retry, and the backend enforces it with a unique constraint, reattaching to the existing run instead of creating a new one.
  3. State the decision rule clearly: when do you mint a new key? The rule is whether the content being sent changed, not which button the user pressed. Same message retried keeps the key; edited content is a new message and needs a new key.
  4. Mentioning how far this pattern reaches scores well: write deduplication, cron ticks consumed exactly once, cross-service delivery, and frontend retry — the same shape at four layers, with the database's unique constraint always the final arbiter rather than an application-level check-then-write.
  5. For tool visibility: expose the process, for three reasons. The user can decide whether to interrupt instead of waiting blind; waiting becomes tolerable, since a spinner for fifteen seconds invites a page refresh that wastes the whole turn; and when something breaks the user can say 'it hung on looking up my order', which saves everyone time.
  6. Expected follow-up: does exposing everything leak internals? It can, so filter. Show human-readable tool names rather than function names, hide user identifiers, internal ids and secrets from the arguments, and show classified error reasons rather than raw stack traces. You are surfacing the process, not the internal structure.

  答题要点

  • 重试要带客户端首次生成的幂等键，后端用唯一约束命中后把已有 run 的流接回来，不新建。
  • 换不换键的判据是「内容变没变」：同一句话重试用同一个键，改了内容才换新键。
  • 同一招在落库、定时任务、跨服务调用、前端重试四处复用，最终裁判永远是数据库的唯一约束。
  • 工具调用要可视化：用户才能判断要不要打断、等待变得可忍受、出问题时说得清卡在哪一步。
  • 但要过滤：工具名用人话、参数里的内部 id 与密钥不显示、错误显示归类原因而不是原始堆栈。

  Key points

  • Retry carries the idempotency key minted on the first attempt; the backend hits a unique constraint and reattaches to the existing run.
  • The rule for minting a new key is whether the content changed — same message keeps the key, edited content gets a new one.
  • The same pattern recurs in write dedup, cron ticks, cross-service delivery and frontend retry, always arbitrated by a database unique constraint.
  • Make tool calls visible so users can decide whether to interrupt, tolerate the wait, and describe where it hung.
  • But filter: human-readable tool names, no internal ids or secrets in the arguments, classified error reasons instead of raw stack traces.

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

• 一个多租户的 Agent 服务，数据隔离和计费隔离要怎么设计？什么时候该从共享表升级到独立库？For a multi-tenant agent service, how do you design data isolation and billing isolation, and when do you move from a shared table to a dedicated database per tenant?

  国内高频海外高频进阶#system-design#multi-tenancy#isolation

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

  1. 这题的题眼在「隔离」是复数。只答数据隔离的候选人非常多，而多租户翻车最多的其实是资源那一层——一个租户的洪峰打穿别人的处理能力，数据一条都没串，用户照样投诉。所以第一句先把三层摆出来：数据、资源、计费，缺哪一层对应一类事故。
  2. 数据这一层，判断一个人有没有真做过就看一句话：他说「每条查询都带 tenant_id」还是「靠数据库的行级安全兜底」。前者迟早会漏一处，而漏掉的那处通常是最新加、最没被测过的功能。正确说法是行级安全是闸门，应用层那句 where 只是优化——这和幂等的最终裁判必须是数据库唯一约束，是同一种思路：能在数据层强制的，不要指望每个人写代码时都记得。
  3. 资源这一层给两件具体的东西：每个租户一个独立限流桶，以及 worker 按租户标识哈希分片。分片这一招和「按用户哈希保住同一用户顺序」是同一套机制，只是哈希的输入换了，目的从保序变成隔离洪峰。Agent 场景里噪声邻居格外突出，因为单次执行可能跑三十秒，一个租户灌一千条进来，别人就得排队。
  4. 计费这一层最简单也最容易漏：token 用量台账加一列租户标识，写入时打标。账单、配额、超支降级三件事全靠它。顺带说一句成本口径——单轮 2000 输入加 500 输出约 0.0006 美元，日活 1 万人均 5 轮约每月 900 美元，能报出这个量级说明你真的算过每租户成本。
  5. 然后回答升级判据，这是本题的第二个区分点。三档是共享表加租户列、schema 级、库级；**判据不是租户数量，是「有没有单个租户能把别人拖垮」和「有没有合规硬要求」**。答「超过一百个租户就该分库」是典型的凭感觉，因为一百个小租户共享一张表毫无问题，而一个受监管的大客户哪怕只有一个也可能必须物理隔离。代价要一起说：库级隔离看着干净，但迁移脚本、备份、监控、连接池全部乘以租户数，运维成本是陡增不是线性。
  6. 可以预期的追问，也是最见功力的一问：幂等键在多租户下要不要变？答案是键的算法不用变，但**作用域必须带上租户标识**。不带的话两个租户的客户端各自生成了同一个字符串（都用订单号 order-1024），后来那个会被唯一约束当成重复请求挡掉——一个租户的写入被另一个租户的历史请求吞掉，两边日志都完全正常，是多租户里最难查的一类 bug。

  How to reason about it · think before answering

  1. The hinge is that 'isolation' is plural. Plenty of candidates answer only data isolation, but the layer that actually breaks in production is resources: one tenant's spike starves everyone else, no rows leak, and users still complain. Open with all three — data, resources, billing — and note that each missing layer maps to its own class of incident.
  2. On data, one sentence separates people who shipped this from people who read about it: 'every query carries tenant_id' versus 'row-level security is the backstop'. The first eventually misses a query, and the one it misses is always the newest, least-tested feature. The correct framing is that RLS is the gate and the application-level where clause is just an optimisation — the same reasoning as idempotency being adjudicated by a database unique constraint. Whatever the data layer can enforce should not depend on everyone remembering.
  3. On resources, give two concrete things: a rate-limit bucket per tenant, and workers sharded by a hash of the tenant id. That is the same sharding mechanism used to preserve per-user ordering, with a different hash input and a different purpose — containing spikes rather than serialising. Noisy neighbours hurt more in agent workloads because a single execution can run thirty seconds, so a thousand queued items from one tenant leaves everyone else waiting.
  4. Billing is the simplest and the most often forgotten: add a tenant column to the token usage ledger and tag every write. Invoicing, quotas and over-budget degradation all hang off it. Bring the cost figures too — roughly $0.0006 per turn at 2000 in and 500 out, about $900 a month at 10k daily actives and five turns each — because quoting per-tenant economics shows you actually ran the numbers.
  5. Then the escalation criteria, the second discriminator. Three tiers: shared table with a tenant column, schema per tenant, database per tenant. The trigger is not tenant count, it is whether a single tenant can starve the rest and whether there is a hard compliance requirement. 'Split the database past a hundred tenants' is guesswork: a hundred small tenants share a table happily, while one regulated enterprise customer may require physical separation on its own. State the cost too — a database per tenant looks clean, but migrations, backups, monitoring and connection pools all multiply by tenant count, so operational cost jumps rather than scaling linearly.
  6. Expect the sharpest follow-up: does the idempotency key change under multi-tenancy? The algorithm does not, but its scope must include the tenant id. Without it, two tenants whose clients independently produce the same string — both using order id order-1024 — collide, and the later request is rejected by the unique constraint as a duplicate. One tenant's write is swallowed by another tenant's history, both logs look perfectly normal, and it is the hardest class of multi-tenant bug to find.

  答题要点

  • 三层隔离并列，缺一层对应一类事故：数据、资源、计费
  • 数据靠行级安全兜底，应用层的 where 只是优化——能在数据层强制的不要靠人记得
  • 资源是每租户独立限流桶加按租户标识哈希分片，防的是噪声邻居而不是数据串
  • 计费是台账加一列租户标识，账单、配额、超支降级全靠它
  • 升级到 schema 级或库级的判据是「单租户能否拖垮别人」与「有没有合规硬要求」，不是租户数量
  • 库级隔离的代价是迁移、备份、监控、连接池全部乘以租户数，运维成本陡增
  • 幂等键算法不变，但作用域必须带租户标识，否则两个租户的同名键会互相挡掉请求

  Key points

  • Three parallel layers, each missing one causing its own class of incident: data, resources, billing
  • Data isolation is backstopped by row-level security; the application where clause is only an optimisation
  • Resource isolation is a per-tenant rate-limit bucket plus sharding workers by tenant hash, aimed at noisy neighbours
  • Billing isolation is a tenant column on the usage ledger, powering invoices, quotas and degradation
  • Escalate to schema or database isolation based on starvation risk and compliance mandates, not tenant count
  • Per-tenant databases multiply migrations, backups, monitoring and connection pools — operational cost jumps
  • The idempotency key algorithm stays, but its scope must include the tenant id or identical keys across tenants collide
• 一个 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

D27 简历与项目包装：STAR、README、架构图、demo 视频、英文简历

• 我们点开了你 GitHub 上的项目，你觉得一份好的 README 应该让我看到什么？Suppose I open one of your GitHub projects — what should a good README show me?

  国内高频海外高频进阶#behavioral#documentation#portfolio

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

  1. 这题表面在问文档规范，实际在考「你有没有读者意识」。答成一串小标题清单（简介、安装、使用、贡献指南）会显得像背模板；面试官想听的是你知道读者是谁、他有多少时间、他在找什么。
  2. 先把读者说清楚再列结构，这一步就能拉开差距：看 README 的人预算大约三分钟，而且不打算 clone 下来跑。所以第一屏必须解决「这是什么」和「能不能跑」，深入的东西往后放。
  3. 然后给结构，并且为每一段说出它服务的是哪个读者：一句话定位（筛简历的人）、架构图（想快速建立心智模型的人）、快速开始（想验证能不能跑的人）、关键设计决策（面试官）、已知限制（面试官）、目录导读与许可（真的要读代码的人）。
  4. 重点落在两段上。「快速开始」的硬指标是三条命令之内跑起来，超了说明有隐性依赖；判据是拿一台没跑过的机器照着敲一遍，而不是在自己机器上试。「关键设计决策」每条要含「放弃了什么」，因为这是唯一无法从模板抄来的部分。
  5. 「已知限制」值得单独说一句：主动写出边界不是暴露短板，而是同时证明了自我认知和诚信。而且你先说了，对方就很难再拿它当把柄，最多顺着问「上生产你会先补哪个」——那是你准备好的题。
  6. 可以预期的追问：「你的项目 README 里最花时间的是哪一段？」答「关键设计决策」，然后现场讲一条。这题问的是 README，落点其实是让你讲项目，别错过这个递过来的机会。

  How to reason about it · think before answering

  1. On the surface this is about documentation conventions; underneath it tests reader awareness. Reciting a list of headings sounds like a template. They want to hear that you know who the reader is, how much time he has, and what he is looking for.
  2. Define the reader before listing sections: someone skimming a README has about three minutes and has no intention of cloning the repo. So the first screen must answer 'what is this' and 'can it run'; everything deep goes below.
  3. Then give the structure, naming the reader each part serves: one-line positioning (the resume screener), architecture diagram (anyone building a mental model), quick start (anyone verifying it runs), key design decisions (the interviewer), known limitations (the interviewer), directory guide and license (people who will actually read the code).
  4. Put the weight on two sections. Quick start has a hard bar — running in three commands or fewer; more than that means hidden setup. Verify it on a machine that has never run the project, not on your own. Key design decisions must each state what you gave up, because that is the one part no template can supply.
  5. Known limitations deserve a sentence of their own: stating boundaries is not exposing weakness, it demonstrates self-awareness and honesty at once. And once you have said it, it is hard to use against you — at most they ask which gap you would close first, which you already prepared.
  6. Expect the follow-up: 'which section took you the longest?' Answer 'key design decisions' and then walk through one on the spot. The question is nominally about READMEs, but it is an invitation to talk about your project — take it.

  答题要点

  • 先说读者：三分钟预算、不会 clone 下来跑，所以第一屏解决「是什么」和「能不能跑」
  • 七段结构：一句话定位、架构图、快速开始、关键设计决策 3 条、已知限制、目录导读、许可
  • 快速开始的硬指标是三条命令之内，且要在一台没跑过的机器上验证
  • 关键设计决策每条含「放弃了什么」，这是唯一抄不来的部分，也是面试官挑追问的地方
  • 架构图用 Mermaid 而不是截图：GitHub 原生渲染、改动是文本 diff、不会过期

  Key points

  • Start from the reader: a three-minute budget and no intention of cloning, so the first screen answers what it is and whether it runs
  • Seven sections: one-line positioning, architecture diagram, quick start, three key design decisions, known limitations, directory guide, license
  • Quick start must work in three commands or fewer, verified on a machine that has never run it
  • Every design decision states what was given up — the one part no template provides, and where interviewers pick their follow-up
  • Use Mermaid rather than screenshots: native GitHub rendering, text diffs, and it does not go stale

D28 模拟面试日：国内/海外各一套全流程，自评

• 自我介绍环节最容易出的问题是什么？一段好的自我介绍应该长什么样？What most commonly goes wrong in the self-introduction, and what does a good one look like?

  国内高频海外高频进阶#self-presentation#communication

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

  1. 先看清面试官在这 3 分钟里做什么：一是看你能不能自己组织一段有结构的表达，二是决定接下来 25 分钟挖你哪个项目。看懂第二件事，答案就不是「讲短一点」这么浅了。
  2. 最容易出的问题有一个统一的根因——按时间顺序讲。从大学讲起、顺着简历从上往下念，于是 3 分钟到点时你还没讲到最近、最有价值的那段经历，而那恰恰是唯一有人想听的部分。
  3. 由此推出正确形态：倒序，只留三块——你现在是什么方向的工程师、一到两个带数字的代表作、你为什么来面这个岗位。90 秒讲完主线，把剩下的时间让给对方追问，而不是把 3 分钟填满。留白是主动权，不是浪费。
  4. 第二个高频问题是通篇形容词、没有一个数字。「我做过一个高性能的 Agent 服务」几乎不携带信息；换成一句带约束和指标的话（在什么约束下、为了什么目标、做了什么、把哪个指标从多少改善到多少），才会让对方接着问下去。
  5. 第三个问题最隐蔽：自我介绍里埋了自己不想被问的东西。你说出口的每一个技术名词都是一张邀请函，不熟的栈别写也别说；反过来，希望被问的点要主动埋进去，这是全场唯一由你控制议题的机会。
  6. 可以预期的追问：面试官打断你说「再简单说一下」，说明你已经超时或跑题了。所以要提前排练两个版本，一个 60 秒、一个 90 秒，现场直接切，不要临场压缩——临场压缩的结果通常是把结论也一起删掉了。

  How to reason about it · think before answering

  1. Start from what the interviewer is doing during those three minutes: judging whether you can structure a piece of speech unaided, and deciding which project to spend the next twenty-five minutes on. Once you see the second one, the answer stops being 'keep it short'.
  2. The usual failures share one root cause: telling it chronologically. Starting at university and reading the resume top-down means the three minutes expire before you reach the recent work, which is the only part anyone wants to hear.
  3. That gives the correct shape: reverse order, three blocks only — what kind of engineer you are now, one or two signature pieces of work with a number attached, and why this role. Land the main line in ninety seconds and leave room for follow-up rather than filling the slot. The silence is leverage, not waste.
  4. The second frequent failure is adjectives with no numbers. 'I built a high-performance agent service' carries almost no information; a sentence with a constraint, a goal, an action, and a metric moved from X to Y is what makes someone ask the next question.
  5. The third is the subtlest: seeding things you do not want to be asked about. Every technology you name is an invitation, so leave unfamiliar stacks out — and conversely, plant the topics you want to be asked about, since this is the only moment in the loop where you set the agenda.
  6. Expect this follow-up: if the interviewer cuts in with 'just briefly', you have already run long or drifted. Rehearse two versions, sixty and ninety seconds, and switch between them rather than compressing live — live compression usually deletes the conclusion too.

  答题要点

  • 面试官在这 3 分钟里同时做两件事：判断你的表达结构，决定接下来挖哪个项目
  • 最常见的错是按时间顺序讲，时间用完还没讲到最近最有价值的经历；正确做法是倒序
  • 结构只留三块：现在的技术方向、一到两个带数字的代表作、为什么来面这个岗位
  • 90 秒讲完主线、主动留白给对方追问，比把 3 分钟填满更有利
  • 每个说出口的技术名词都是邀请函：不熟的不提，想被问的主动埋进去；提前排练 60 秒和 90 秒两个版本

  Key points

  • The interviewer is doing two things at once: assessing structure and choosing which project to dig into
  • The common failure is chronological order, which burns the clock before reaching recent work; reverse it
  • Keep three blocks: current engineering focus, one or two signature results with numbers, and why this role
  • Landing the main line in ninety seconds and leaving room for follow-up beats filling all three minutes
  • Every technology you name is an invitation: omit unfamiliar stacks, plant the topics you want asked, and rehearse a sixty-second and a ninety-second version
• 一次模拟面试之后，你怎么做一次客观的自我评估，而不是停在「感觉还行」？After a mock interview, how do you assess yourself objectively instead of settling for 'that felt okay'?

  国内高频海外高频进阶#self-assessment#deliberate-practice

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

  1. 这题在考你有没有把练习工程化。答「录下来多听几遍」只是及格线，真正的区分度在于有没有可重复的评分口径和事先定好的阈值——没有口径，两次模拟之间就没法比较，也就谈不上进步。
  2. 客观的前提是有可回放的证据，所以先固定三件事：全程录音或录屏、按时间盒计时、事后对着回放打分而不是结束时凭感觉打。刚讲完的十几分钟里自我评价偏差最大，讲得顺就全盘肯定，卡过一次就全盘否定。
  3. 然后用固定维度代替整体印象：自我介绍、项目讲解深度、编码、系统设计、沟通与反问，各 1 到 5 分，满分 25。关键是每个维度要写好 1 分、3 分、5 分各长什么样的锚点描述，否则同一个「4 分」在两次之间根本不是同一件事。
  4. 阈值要在打分之前定好，这是防止事后给自己找理由的唯一办法：任何单项低于 3 分就进弱项清单，总分低于 18 分就隔两天把整套流程重跑一次，而不是硬着头皮往下走。
  5. 最后一步才是全部价值所在——把低分翻译成四列：现象、根因、最小动作、怎么验证。现象必须是回放里能指着看的事实（带时间、带原话），「讲得不好」不算，「项目讲解到第 8 分钟还没说到我做了什么」才算；最小动作必须一天内做得完；验证必须可观察，最好带数字门槛。
  6. 可以预期的追问：一个人怎么产生追问？用大模型当面试官，但必须先把追问纪律写进指令——一次只问一个问题、基于我的回答连追三层、全程不评价不夸奖不给答案。不写纪律，它会退化成一个不停鼓励你的助手，那就失去了模拟的意义。

  How to reason about it · think before answering

  1. This asks whether you have engineered your practice. 'Record it and listen again' is the passing floor; the discriminator is a repeatable rubric plus thresholds fixed in advance, because without a rubric two sessions are not comparable and improvement is unmeasurable.
  2. Objectivity requires reviewable evidence, so fix three things first: record audio or screen throughout, run the real time boxes, and score against the recording afterwards rather than on feeling at the buzzer. Self-assessment is at its most distorted in the minutes right after you finish.
  3. Then replace overall impression with fixed dimensions: self-introduction, project depth, coding, system design, and communication plus candidate questions, each scored 1 to 5 for a total of 25. What makes it work is writing anchor descriptions for what a 1, a 3, and a 5 look like — otherwise the same '4' means different things in different sessions.
  4. Set thresholds before scoring, which is the only defense against rationalizing afterwards: any dimension below 3 goes on the weakness list, and a total below 18 means rerunning the whole loop two days later instead of pressing on.
  5. The final step carries all the value: translate low scores into four columns — observation, root cause, smallest drill for tomorrow, and how to verify. An observation has to be a fact you can point at in the recording, with a timestamp and the actual words: 'explained it badly' does not qualify, 'eight minutes into the project story and still had not said what I personally did' does. The drill must fit in one day, and verification must be observable, ideally with a numeric bar.
  6. Expect the follow-up: how do you generate follow-up questions alone? Use a model as the interviewer, but write the interrogation rules into the instructions first — one question at a time, three consecutive layers of follow-up grounded in what you just said, and no praise, no evaluation, no supplying the answer. Without those rules it degrades into an encouraging assistant, which defeats the point.

  答题要点

  • 先有证据再有判断：全程录音或录屏、按时间盒计时、事后对着回放打分，不在结束当场凭感觉打
  • 用固定五个维度（自我介绍、项目讲解深度、编码、系统设计、沟通与反问）各 1 到 5 分、满分 25，并给每个维度写 1/3/5 分的锚点描述
  • 阈值先定后打：任何单项低于 3 分进弱项清单，总分低于 18 分隔两天重跑整套流程
  • 把低分翻译成四列：现象、根因、最小动作、怎么验证；现象必须是回放里能指着看的事实，动作必须一天内做得完
  • 一个人练时用大模型当面试官，但要先写死追问纪律：一次一问、连追三层、不评价不夸奖不给答案

  Key points

  • Evidence before judgment: record throughout, run real time boxes, and score against the replay rather than on feeling at the buzzer
  • Use five fixed dimensions (intro, project depth, coding, system design, communication and candidate questions) scored 1 to 5 out of 25, each with anchors for what 1, 3 and 5 look like
  • Fix thresholds before scoring: any dimension below 3 goes on the weakness list, a total below 18 means rerunning the loop two days later
  • Translate low scores into four columns — observation, root cause, smallest drill, verification — where the observation is a pointable fact and the drill fits in one day
  • Practicing alone, use a model as interviewer but write the rules first: one question at a time, three layers of follow-up, no praise, no evaluation, no answers

D29 弱项补强 + 编码热身：rate limiter、LRU、并发控制、流式 JSON 解析

• 怎么实现一个限制并发数的调度器？为什么不能直接用 Promise.all 或者 asyncio.gather？How would you build a scheduler that caps in-flight async tasks, and why is Promise.all or asyncio.gather not enough?

  国内高频海外高频进阶#concurrency#async

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

  1. 题眼在后半句。面试官在确认你分不分得清「等待一批任务」和「限制同时运行的任务数」——这两件事在 API 名字上很像，在语义上毫无关系。
  2. 先说破错误答案为什么错：把 500 个任务全部映射成 Promise 再一起 await，这段代码的并发度是 500。Promise 一被创建，它内部的请求就已经发出去了，await 只是在等结果；gather 和 CompletableFuture.allOf 是同一个坑的另外两种口音。
  3. 再给正确形状的两条路：固定数量的工人从同一个游标取任务（JS 的惯用法，槽位就是工人本身），或者用信号量挡在任务启动之前（Python 的 asyncio.Semaphore、Java 的 Semaphore）。Swift 要用 TaskGroup 自己开滑动窗口，先塞满 limit 个、每收一个结果补一个。
  4. 本题真正的失分点是槽位泄漏：acquire 之后必须在 finally 里 release，或者把错误在任务内部收敛成结果值。忘了这一步的代码在 happy path 上完全正常，只有下游开始报错时才会一点点变慢直到彻底卡死——这是最难查的那类 bug，因为症状出现在故障之后而不是之中。
  5. 落到 Agent 场景说收益：批量 embedding、并行工具调用、多路子任务都靠它。收益不只是「不打爆下游」，还有同时驻留的内存与并发度同阶而不是与任务数同阶。
  6. 可以预期的追问：如果任务本身还要重试呢？答案是重试要在槽位内部完成（占着槽位退避重试），否则重试风暴会绕过限流；再追一层就是给重试加抖动，避免所有失败任务在同一时刻一起回来。

  How to reason about it · think before answering

  1. The hinge is the second half. They are checking whether you separate 'await a batch' from 'cap how many run at once' — similar API names, unrelated semantics.
  2. Name the wrong answer first: mapping 500 items to promises and awaiting them together runs at concurrency 500. Creating the promise already fired the request; awaiting only collects results. gather and CompletableFuture.allOf are the same trap in other accents.
  3. Then give the two correct shapes: a fixed set of workers pulling from a shared cursor (the JS idiom, where a worker is the slot), or a semaphore gating task start (asyncio.Semaphore, java.util.concurrent.Semaphore). Swift needs a manual window over a TaskGroup — fill limit slots, then add one task per result received.
  4. The real failure mode is slot leakage: release must happen in a finally, or the error must be collapsed into a result value inside the task. Code that misses this looks perfect on the happy path and only degrades once the downstream starts failing, which makes it one of the hardest bugs to trace.
  5. Tie it to agents: batch embedding, parallel tool calls, fan-out subtasks. The benefit is not only sparing the downstream — peak memory now scales with the concurrency limit instead of the task count.
  6. Expect the follow-up: what if tasks retry? Retries must happen inside the slot, otherwise a retry storm bypasses the limiter entirely. One level deeper: add jitter so failed tasks do not all come back at the same instant.

  答题要点

  • Promise.all 与 asyncio.gather 只负责等待，任务在被创建的那一刻就已经启动了，并发度等于任务总数
  • 两种正确形状：固定数量的工人从共享游标取任务，或者用信号量挡在任务启动之前
  • 槽位必须在任何退出路径上归还：Java 写在 finally 里，Python 用 async with，Swift 把错误收敛成结果值，JS 在循环里 try 与 catch
  • 槽位泄漏的症状是「下游一开始报错就越来越慢直到卡死」，happy path 完全看不出来
  • 收益是同时驻留的内存与并发度同阶，而不是与任务总数同阶；重试要占着槽位做，并加抖动

  Key points

  • Promise.all and asyncio.gather only wait; the work started when each promise was created, so concurrency equals the task count
  • Two correct shapes: a fixed worker set pulling from a shared cursor, or a semaphore gating task start
  • The slot must be returned on every exit path — finally in Java, async with in Python, error-to-value inside a Swift task, try/catch inside the JS loop
  • A leaked slot shows up as gradual slowdown to a full stall once the downstream starts erroring, and is invisible on the happy path
  • The payoff is peak memory scaling with the concurrency limit rather than the task count; retries must stay inside the slot and carry jitter

D30 总复盘 + 投递启动：题库全量过一遍、知识地图、第二个月投递节奏、网站公开上线

• 怎么把零散的知识点组织成一张便于复习的知识地图？How do you turn scattered knowledge into a map that is actually useful for review?

  国内高频海外高频进阶#knowledge-organization#interview-prep

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

  1. 题眼在「便于复习」四个字。绝大多数人答成「按模块分类、画个思维导图」，那产出的是目录不是地图——目录任何一本书的前几页都有，它不能告诉你先补哪里。区分度就在这儿。
  2. 怎么拆：一张图有两种元素，节点和边。分层（节点怎么分组）是廉价的、几乎人人做得对；真正的信息量在边上。所以先问自己一个问题——我这张图上有几条边，每条边的含义是什么？答不上来就说明画的是目录。
  3. 给一条可操作的连边判据：只有当「不懂 A 就学不懂 B」时才连 A 指向 B。「A 和 B 都属于消息队列」不算，那是同层并列；「不理解上下文窗口就理解不了为什么要压缩」算。课程的先后顺序也不算——那是日历，不是依赖。
  4. 结论：地图的用法是把你的弱点涂上去。某个节点讲不清，先看它的上游是不是也红——是的话补上游，一次带亮一串。这就是地图相对清单的唯一优势：清单说哪里错了，地图说该从哪儿开始。
  5. 生产视角：这套东西在工作里同样有用。排查一个线上问题时，你脑子里那张「谁依赖谁」的图决定了你先看哪个服务的日志；没有这张图的人只能一个个试。面试时把这个类比说出来，会显得你不是为了背题才画图。
  6. 可预期的追问：那张图应该多大？答案是能在白板上 5 分钟画完——超过这个规模你会开始维护它而不是使用它，节点合并成主题，细节留在题库里。

  How to reason about it · think before answering

  1. The load-bearing phrase is 'useful for review'. Most answers become 'group things by module and draw a mind map', which produces a table of contents, not a map — a contents page cannot tell you what to fix first. That is where candidates separate.
  2. Break it down: a graph has nodes and edges. Grouping nodes is cheap and almost everyone does it correctly; the information lives in the edges. So ask yourself how many edges your diagram has and what each one means. No answer means you drew a contents page.
  3. Give an operational rule for edges: draw A to B only when not understanding A blocks understanding B. 'Both are about message queues' does not qualify — that is sibling grouping. 'You cannot understand context compression without the context window' does. Course order does not qualify either; that is a calendar, not a dependency.
  4. Conclusion: use the map by painting your weak spots onto it. If a node is shaky, check whether its upstream is shaky too — repair upstream and several downstream nodes light up at once. That is the map's one advantage over a checklist: a checklist says what is broken, a map says where to start.
  5. Production angle: the same habit pays off at work. When debugging an incident, the dependency graph in your head decides whose logs you open first; without it you probe services one by one. Saying this shows the map is a working tool, not an exam prop.
  6. Expect the follow-up: how big should it be? Small enough to redraw on a whiteboard in five minutes. Past that you start maintaining the map instead of using it — merge nodes into themes and leave the detail in your question bank.

  答题要点

  • 分层只是分组，任何目录都做得到；地图的信息量全部在边上
  • 连边的判据只有一条：不懂 A 就学不懂 B 才连边，同类并列和课程顺序都不算
  • 把弱项涂到节点上，红点扎堆时优先补上游节点，一次带亮一串下游
  • 跨层的长边最值钱，面试时顺着长边讲能体现体系，孤立节点只能给出零碎答案
  • 规模控制在白板 5 分钟能画完，再细的内容留在题库里而不是图上

  Key points

  • Grouping into layers is what any table of contents does; a map's information is in its edges
  • One rule for edges: draw one only when A is a genuine prerequisite for B — sibling topics and course order do not count
  • Paint your weak spots on the nodes and fix upstream first when reds cluster; one fix lights up several downstream nodes
  • Long cross-layer edges are the valuable ones — following them in an interview shows a system, isolated nodes only produce fragments
  • Keep it redrawable on a whiteboard in five minutes; finer detail belongs in the question bank, not the map

5 天提示词工程零基础

D1 提示词是什么、不是什么：模型如何读指令；角色 / 任务 / 格式 / 约束四要素

• 角色、任务、格式、约束四要素各解决什么问题？如果只能保留三个，你会砍掉哪个，为什么？What problem does each of the four prompt elements — role, task, format, constraints — solve? If you could keep only three, which would you drop and why?

  国内高频海外高频进阶#prompt-basics#four-elements

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

  1. 前半句是送分，后半句才有区分度：它在考你是否知道每个要素对应模型的哪一种「猜」，以及哪种猜错的代价最小。
  2. 拆法：把每个要素映射到一个「模型会猜错的地方」——角色对应视角与关注点，任务对应终点在哪，格式对应输出能否被程序消费，约束对应改动范围与不可碰的边界。
  3. 判断哪个可砍：看缺了之后是「结果不稳定」还是「结果不可用」。缺角色多半是关注点偏了但仍可用；缺任务的完成标准会让模型不知何时停；缺格式会让下游解析失败；缺约束会让改动面失控。
  4. 结论：多数工程场景下角色最可砍，因为任务与格式写得足够具体时视角已经被隐含；但要说明前提是任务里已经写清了关注点。
  5. 追问几乎必然是「那为什么大家还都写角色」——答案是它便宜且能一句话压缩大量隐性偏好，在任务没法写得很细的对话场景里性价比最高。

  How to reason about it · think before answering

  1. The first half is a warm-up; the second half tests whether you can map each element to a specific way the model would otherwise guess, and rank the cost of each wrong guess.
  2. Map them: role fixes perspective and focus, task fixes the finish line, format decides whether downstream code can consume the output, constraints bound the change surface.
  3. To pick the one to drop, ask whether its absence makes results unstable or unusable. Missing role skews focus but stays usable; missing done-criteria means the model never knows when to stop; missing format breaks parsers; missing constraints lets edits sprawl.
  4. Conclusion: in most engineering settings role is the most droppable, because a specific task plus a strict format already imply the perspective — provided the task states what to care about.
  5. Expect the follow-up 'then why does everyone write a role?' Because it is cheap and compresses many implicit preferences into one line, which pays off in chat-style use where the task cannot be fully specified.

  答题要点

  • 角色定视角与关注点；任务定做什么与完成标准；格式定输出形状是否可机械核对；约束定不可碰的边界与理由
  • 每个要素对应模型的一种「猜」，缺哪个就多一种不稳定
  • 可砍的是角色：任务与格式足够具体时视角已隐含，但前提是任务里写清了关注点
  • 任务的完成标准与格式的可核对性最不能省，因为它们直接决定输出能不能被程序消费

  Key points

  • Role sets perspective; task sets the goal and done-criteria; format makes output mechanically checkable; constraints bound scope with reasons
  • Each element removes one kind of guess the model would otherwise make
  • Role is the most droppable once task and format are specific enough to imply the perspective
  • Done-criteria and checkable format are the least negotiable because downstream code depends on them
• 为什么规则要放系统提示而不是用户消息？请从遵从度、管控和成本三个角度说明，并指出系统提示做不到什么。Why do rules belong in the system prompt rather than the user message? Cover adherence, control, and cost, and name what the system prompt cannot guarantee.

  国内高频海外高频进阶#system-prompt#prompt-basics

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

  1. 题眼在「三个角度」和「做不到什么」。只答「系统提示权重高」是背概念，面试官要看的是你有没有在生产里拼过系统提示。
  2. 拆法：遵从度看多轮稀释——用户消息会被后续对话淹没，系统提示全程生效；管控看谁能改——系统提示由后端统一拼装、用户碰不到，规则放这里才能对所有用户一致；成本看缓存——提示缓存按前缀命中，系统提示是最稳定的前缀。
  3. 「做不到什么」是区分度所在：系统提示遵从度高不等于绝对，提示注入可以让模型跑偏，所以安全边界不能只靠系统提示，要在模型外用代码兜底。
  4. 结论：规则进系统提示是为了稳定、一致、省钱；但它是「强建议」不是「硬约束」，硬约束必须在代码层实现。
  5. 追问方向：系统提示可以放在对话末尾吗？可以但不推荐——多数模型对靠前指令更敏感，且会破坏缓存前缀；另一个追问是「哪些内容不该进系统提示」，答案是每次都变的任务细节，放进去会让缓存失效且难以复用。

  How to reason about it · think before answering

  1. The tell is whether you cover all three angles and name a limitation. 'System prompts carry more weight' alone reads as memorized.
  2. Adherence: user turns get diluted as the conversation grows, the system prompt stays in force. Control: the backend assembles the system prompt and users cannot touch it, so rules apply uniformly. Cost: prompt caching matches on prefixes, and the system prompt is the most stable prefix.
  3. The limitation is the differentiator: higher adherence is not a guarantee, prompt injection can still steer the model, so security boundaries need code-level enforcement outside the model.
  4. Conclusion: rules go in the system prompt for stability, consistency and cost, but it is a strong suggestion, not a hard constraint.
  5. Follow-ups: can the system prompt go last? Possible but unwise — models weight early instructions more and it breaks the cache prefix. What should stay out? Per-request task details, which would bust the cache and hurt reuse.

  答题要点

  • 遵从度：用户消息会被多轮对话稀释，系统提示全程生效
  • 管控：系统提示由后端统一拼装，用户碰不到，规则才能对所有人一致
  • 成本：提示缓存按前缀命中，系统提示是最稳定的前缀，不变的内容集中在这里最省钱
  • 做不到的：它不是安全边界，提示注入可以绕过，硬约束必须在代码层兜底

  Key points

  • Adherence: user turns get diluted over a long conversation, the system prompt stays in force
  • Control: the backend assembles it and users cannot edit it, so rules apply to everyone
  • Cost: prompt caching matches prefixes, so stable content in the system prompt maximizes cache hits
  • Limit: it is not a security boundary; prompt injection can bypass it, so enforce hard rules in code

D2 few-shot、思维链、分步与自检；什么时候这些都不管用

• 思维链在什么任务上提升明显，在什么任务上是浪费？它和「分步」有什么区别？Where does chain-of-thought prompting help most, where is it a waste, and how does it differ from splitting a task into steps?

  国内高频海外高频进阶#chain-of-thought#prompt-techniques

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

  1. 题眼在「浪费」和「区别」。只会说「让模型先思考再回答效果更好」的候选人没有算过账，面试官想听的是你什么时候会主动不用它。
  2. 拆法：思维链的价值来自「中间结果可以校验下一步」，所以它在多步推理、算术、需要排除干扰项的判断上提升明显；在单步判断（分类、抽取、格式转换）上几乎没有增益，只有更慢更贵更长的输出。
  3. 区别：思维链是一次调用内让模型写出中间过程，输出预算还是同一份；分步是拆成多次调用，每步有独立的预算、独立的格式、并且后一步可以拿前一步的输出做输入。任务是「想得不够细」用思维链，任务是「一次装不下」用分步。
  4. 结论：先问任务是否需要多步推理，不需要就不用；需要的话再问一次输出装不装得下，装得下用思维链，装不下拆步。
  5. 追问：推理类模型内置了思考过程，还要写思维链吗？多数情况不用再写「一步步想」，但仍要指定最终答案的格式与位置，否则解析会很痛苦；另一个追问是思维链的内容能不能信，答案是它是「看起来合理的过程」而非真实的内部计算，只能当辅助校验不能当证据。

  How to reason about it · think before answering

  1. The discriminators are 'waste' and 'difference'. Anyone can say thinking first helps; the interviewer wants to hear when you deliberately skip it.
  2. Its value comes from intermediate results checking the next step, so it shines on multi-step reasoning, arithmetic and judgments with distractors; on single-step tasks such as classification, extraction or format conversion it adds latency, cost and length with little gain.
  3. Difference: chain-of-thought keeps everything in one call and one output budget; splitting uses several calls, each with its own budget and format, and later steps can consume earlier outputs. Use CoT when the model thinks too shallowly, split when one answer cannot hold the work.
  4. Conclusion: ask whether the task needs multi-step reasoning at all; if yes, ask whether one output can hold it — CoT if so, split if not.
  5. Follow-ups: with reasoning models that think internally, do you still write 'think step by step'? Usually no, but you still pin the answer format and position. And can you trust the written reasoning? It is a plausible narrative, not the actual computation — use it as a check, not as proof.

  答题要点

  • 思维链的价值是中间结果校验下一步，多步推理与算术上提升明显，单步判断上是浪费
  • 代价是更长的输出、更高的延迟与费用，所以不需要推理的任务要主动不用
  • 与分步的区别：思维链是一次调用内写过程，输出预算不变；分步是多次调用，每步独立预算且可传递输出
  • 推理模型内置思考后一般不必再写「一步步想」，但仍要指定答案格式与位置

  Key points

  • CoT helps because intermediate results check the next step; strong on multi-step reasoning and arithmetic, wasted on single-step judgments
  • Cost is longer output, higher latency and spend, so skip it when no reasoning is needed
  • Versus splitting: CoT stays in one call with one budget; splitting uses multiple calls with independent budgets that can chain outputs
  • With reasoning models you rarely need 'think step by step' but still pin the answer format and location
• 提示词写得再好也做不对的任务有哪些特征？遇到这类任务你会怎么办？What are the signs of a task that no amount of prompt engineering will fix, and what do you do when you hit one?

  国内高频海外高频进阶#prompt-limits#failure-modes

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

  1. 这题考的是「知道提示词的边界在哪」。一直往提示词上堆技巧的候选人会被判为缺乏判断力；能说出「这题不该用提示词解」才是成熟的信号。
  2. 拆法：把失效分三类。缺知识——信息在模型训练截止之后或本来就在你的私有数据里，模型不可能知道，还可能编出格式正确的假答案；缺工具——任务需要对外部世界做动作或查询（跑命令、查库、发请求），文字生成做不到；任务写错——需求本身自相矛盾或者你要的其实是另一件事。
  3. 每类给一个判据：缺知识问「这信息是昨天才出现的，模型有可能知道吗」；缺工具问「一个只能打字的人能完成这件事吗」；任务写错问「两个人读这个需求会不会得出相反的做法」。
  4. 结论：缺知识就把资料贴进上下文或接检索；缺工具就接工具调用或在代码里做完再让模型解读；任务写错回去改需求。三种都不是提示词层面的解法。
  5. 追问几乎必然是「格式越严格假答案越像真的怎么办」——答案是对事实类输出要求带出处或可验证的标识，并在代码里校验；以及「怎么在评估里提前发现这类任务」，答案是测试集里放几条模型不可能知道的样本，看它是否老实说不知道。

  How to reason about it · think before answering

  1. This tests whether you know where prompting ends. Piling techniques onto a hopeless task signals poor judgment; saying 'this is not a prompting problem' signals maturity.
  2. Three failure classes. Missing knowledge: the fact postdates training or lives in your private data, and the model may fabricate a well-formatted answer. Missing tools: the task needs an action or query against the world. Wrong task: the requirement is contradictory or you actually want something else.
  3. One test each: could the model plausibly know something that appeared yesterday? Could a person who can only type complete this? Would two readers of the requirement do opposite things?
  4. Conclusion: paste the material or add retrieval for missing knowledge; add tool use or compute in code for missing tools; fix the requirement for a wrong task. None of these is a prompt change.
  5. Follow-ups: stricter formats make fabrications look more credible — require sources or verifiable identifiers and validate in code. And to catch these early, seed the test set with a few unknowable items and check that the model admits it does not know.

  答题要点

  • 三类失效：缺知识（截止日期之后或私有数据）、缺工具（需要对外部世界做动作）、任务写错（需求自相矛盾）
  • 缺知识的危险在于模型会编出格式正确的假答案，格式越严越像真的
  • 解法都在提示词之外：贴资料或接检索、接工具调用或代码先算、回去改需求
  • 测试集里放几条模型不可能知道的样本，检查它会不会老实说不知道

  Key points

  • Three failure classes: missing knowledge, missing tools, and a wrongly specified task
  • Missing knowledge is dangerous because the model fabricates well-formatted answers, and stricter formats make them more convincing
  • Fixes live outside the prompt: paste material or add retrieval, add tool use or compute in code, or fix the requirement
  • Seed the test set with unknowable items to check the model admits ignorance

D3 结构化输出：JSON schema、模板与变量、多语言输出

• 提示词模板里哪些内容该做成变量，哪些该写死？变量多了会有什么问题？In a prompt template, what should become a variable and what should stay constant, and what goes wrong when you have too many variables?

  国内高频海外高频进阶#prompt-template#structured-output

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

  1. 这题看起来是设计题，实际在考「有没有维护过一份跑在生产里的提示词」。没维护过的人会把所有能变的都做成变量，觉得灵活；维护过的人知道每个变量都是一条测试维度。
  2. 拆法：判据只有一条——下一次调用还会一样的是常量，可能不一样的是变量。角色、任务、约束、schema 通常是常量；输入文本、输出语言、团队默认值是变量。
  3. 再答代价：每多一个变量，提示词的可能形态多一个维度，测试集要覆盖的组合翻倍；变量之间还可能互相影响（语言变量与格式说明冲突）。所以变量越少越好，只取过一个值的「变量」应该变回常量。
  4. 结论：模板是一个有名字、有参数签名的函数，变量是它的参数，常量是函数体；这样提示词才有身份，才能版本化、才能写测试。
  5. 追问：多语言应该是变量还是多份模板？变量——只有一份模板，语言只影响给人读的字段，枚举与标识符不跟着变；否则改一条规则要改多份，三个月后一定分叉。

  How to reason about it · think before answering

  1. It looks like a design question but really asks whether you have maintained a prompt in production. The untested instinct is to parameterize everything; experience teaches that every variable is a test dimension.
  2. One rule: what stays the same on the next call is a constant, what may differ is a variable. Role, task, constraints and schema are usually constants; input text, output language and team defaults are variables.
  3. Then the cost: each variable adds a dimension to the space of prompts, doubling the combinations a test set must cover, and variables can interact. Fewer is better; a variable that only ever took one value should become a constant.
  4. Conclusion: the template is a named function with a signature; variables are parameters, constants are the body. That identity is what makes versioning and testing possible.
  5. Follow-up: is multi-language a variable or separate templates? A variable — one template, language affects only human-facing fields, enums and identifiers never change; separate copies drift within months.

  答题要点

  • 判据：下一次调用还一样的是常量，可能不一样的是变量
  • 角色、任务、约束、schema 是常量；输入文本、输出语言、默认值是变量
  • 每个变量都是一条测试维度，变量越少越好，只取过一个值的变回常量
  • 多语言是一个变量，只影响给人读的字段，枚举与标识符不变

  Key points

  • Rule: same on the next call means constant, may differ means variable
  • Role, task, constraints and schema are constants; input text, output language and defaults are variables
  • Every variable is a test dimension, so keep them minimal and fold single-valued ones back into constants
  • Multi-language is one variable affecting only human-facing fields; enums and identifiers stay fixed
• 模型返回的 JSON 解析或校验失败时，你会怎么设计兜底？重试几次、怎么重试、失败之后怎么办？When the model's JSON fails to parse or validate, how do you design the fallback — how many retries, how do you retry, and what happens after the last failure?

  国内高频海外高频进阶#structured-output#error-handling

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

  1. 这题是生产题，考的是「有没有见过模型抽风」。答「加个 try catch 重试三次」是新手答案，它没回答重试时发什么、也没回答最后怎么办。
  2. 拆法：分三层。校验层返回错误列表而不是布尔值；重试层把错误列表拼进用户消息，让模型知道上一次错在哪，原样重发大概率同样的错；降级层返回空值并记录，交调用方决定跳过还是人工处理。
  3. 重试次数：一次就够。两次以上还不对说明问题不在这条输入而在提示词或 schema，应该修模板而不是继续重试；每次重试都是一次完整调用的钱和延迟。
  4. 结论里最重要的一条：降级不要抛异常，也不要把「差一点」的结果凑合着用。抽取失败是正常业务分支；半对的结构化数据比没有数据更危险，因为下游会把它当真的。
  5. 追问方向：怎么区分「模型抽风」和「提示词有问题」？看失败率——偶发是抽风，某类输入稳定失败是提示词或 schema 缺覆盖，应该把那类输入加进测试集；另一个追问是重试会不会放大成本，答案是要有预算上限并监控重试率。

  How to reason about it · think before answering

  1. A production question that checks whether you have seen a model misbehave. 'Wrap it in try/catch and retry three times' is the novice answer — it says nothing about what you resend or what happens at the end.
  2. Three layers. Validation returns an error list, not a boolean. Retry appends that list to the user message so the model knows what to fix; resending verbatim mostly reproduces the error. Degradation returns null and logs, leaving skip-or-human to the caller.
  3. Retry count: one is enough. Persistent failure means the prompt or schema lacks coverage, so fix the template instead of retrying; each retry costs a full call.
  4. The key conclusion: do not throw on degradation, and do not use a near-miss result. Extraction failure is a normal branch; half-correct structured data is worse than none because downstream code trusts it.
  5. Follow-ups: how to tell flakiness from a prompt bug? Failure rate — sporadic is flakiness, a stable failing input class is missing coverage and belongs in the test set. And does retrying inflate cost? Cap it and monitor the retry rate.

  答题要点

  • 三层：校验返回错误列表、带着错误原因重试一次、失败后返回空值并记录
  • 重试时必须把错误列表拼回用户消息，原样重发大概率同样的错
  • 重试一次足够，稳定失败说明模板或 schema 缺覆盖，该修模板不该继续重试
  • 降级不抛异常、不用半对的结果；监控重试率，稳定失败的输入加进测试集

  Key points

  • Three layers: validation returns an error list, one retry carries those errors back, then degrade to null and log
  • Retries must include the error list in the user message; verbatim resends reproduce the error
  • One retry is enough; persistent failure means the template or schema lacks coverage
  • Never throw on degradation or use near-miss output; monitor retry rate and add failing inputs to the test set

D4 迭代与评估：小样本测试集、A/B、版本管理、常见反模式

• 提示词版本化怎么做？它和代码版本管理有什么不同？线上出问题你先做什么？How do you version prompts? How does it differ from versioning code, and what is your first move when production misbehaves?

  国内高频海外高频进阶#prompt-versioning#evaluation

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

  1. 这题是海外面试里提示词工程方向出现频率最高的一道，考的是「有没有把提示词当成生产资产管理过」。答「放进 git」是最低分，面试官要听的是变更记录里写什么、以及为什么和代码不一样。
  2. 拆法：先说形态——提示词正文独立成文件、每版有 id、与业务代码解耦；再说变更记录四件事——改了什么、为什么改（对应哪几条测试失败）、跑出来的通过率、已知回退。通过率必须是脚本跑出来的数字。
  3. 不同点是区分度所在：代码改动通常是局部的，提示词改动是全局的——加一句话可能改变所有输入的行为，所以「已知回退」是必填项而代码提交信息里没有这一栏；另一点是回滚成本几乎为零，只是换一个字符串。
  4. 结论：线上出问题第一步是回滚到上一版，再拿触发问题的输入补进测试集慢慢查——前提是你有版本号可回、有测试集可跑。
  5. 追问：提示词版本要不要和模型版本绑定？要——同一份提示词在不同模型版本上通过率会变，记录里要写清是在哪个模型上测的；另一个追问是多环境怎么灰度，答案是按版本 id 分流并对比两版的线上指标，跟代码灰度一样。

  How to reason about it · think before answering

  1. One of the most frequent prompt-engineering interview questions abroad; it tests whether you have managed prompts as production assets. 'Put it in git' is the floor; the interviewer wants the changelog contents and why prompts differ from code.
  2. Shape first: prompt text in its own file, an id per version, decoupled from business code. Then the changelog's four items: what changed, why (which test cases failed), the measured pass rate, known regressions. The pass rate must come from the script.
  3. The difference is the differentiator: code changes are usually local, prompt changes are global — one added sentence can shift behavior on every input, so 'known regressions' is mandatory where commit messages have no such field. Also rollback is nearly free, just swap a string.
  4. Conclusion: when production misbehaves, roll back to the previous version first, then add the triggering input to the test set and investigate — which only works if you have version ids and a test set.
  5. Follow-ups: bind prompt versions to model versions? Yes — pass rates shift across model versions, so record which model was used. And canarying: route by version id and compare live metrics, same as code.

  答题要点

  • 提示词正文独立成文件、每版有 id，变更记录写改动、原因、脚本跑出的通过率、已知回退
  • 与代码的不同：改动是全局的，所以「已知回退」必填；回滚成本几乎为零
  • 线上出问题先回滚上一版，再把触发输入加进测试集查
  • 版本要记录在哪个模型上测的，换模型版本通过率会变

  Key points

  • Prompt text lives in its own file with a version id; the changelog records change, reason, measured pass rate, known regressions
  • Unlike code, prompt changes are global, so known regressions are mandatory; rollback is nearly free
  • On a production issue, roll back first, then add the triggering input to the test set
  • Record which model version was tested, since pass rates shift across models
• 用模型给模型打分靠谱吗？什么时候可以用，什么时候必须人工看？Is using a model to grade another model's output reliable? When is it acceptable, and when must a human look?

  国内高频海外高频进阶#evaluation#llm-as-judge

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

  1. 这题在考「知道裁判也会错」。答「用更强的模型当裁判就行」的人没校准过裁判；答出「能用字段比对就不用裁判」才说明有判断力。
  2. 拆法：先分任务。输出是固定字段就用代码逐字段比对，不需要裁判；输出是自由文本（摘要、邮件、解释）才没有字段可比，这时裁判是唯一能规模化的办法。
  3. 再说裁判的偏差：偏向长的、格式漂亮的、和自己风格接近的回答；评分标准含糊时打分随意；对事实性错误不敏感。所以评分标准要像便签一样具体——列出信息点、每点一分——而不是「给这段摘要打 1 到 10 分」。
  4. 结论：裁判可以用，前提是先拿十条人工打过分的样本校准它，看它和人的一致率；上线后定期抽样复核；对涉及事实、安全、金额的输出必须人工看。
  5. 追问方向：裁判和被评的模型是同一家会怎样？会有自我偏好，尽量换一家或至少换一个版本；另一个追问是「裁判的成本」，每条评估都是一次完整调用，测试集大了要算钱，所以能用代码判的部分先用代码判掉。

  How to reason about it · think before answering

  1. This tests whether you know the judge is fallible too. 'Use a stronger model as the judge' means you never calibrated one; 'prefer field comparison whenever possible' shows judgment.
  2. Split by task: structured output gets field-by-field code comparison, no judge needed; free text (summaries, emails, explanations) has no fields, and a judge is the only scalable option.
  3. Judge biases: longer and prettier answers score higher, stylistic similarity gets rewarded, vague rubrics produce noisy scores, factual errors are under-penalized. So the rubric must be concrete — list the information points, one point each — not 'rate this summary 1 to 10'.
  4. Conclusion: usable once calibrated against ten human-scored samples with an agreement rate you accept; spot-check regularly; anything involving facts, safety or money still gets human review.
  5. Follow-ups: same vendor for judge and judged? Expect self-preference, so switch vendor or at least version. And cost — every judgment is a full call, so let code handle whatever it can first.

  答题要点

  • 能用字段比对就不用裁判；裁判只用于没有字段可比的自由文本
  • 裁判偏向长的、格式漂亮的回答，评分标准含糊就打得随意，所以标准要具体到信息点
  • 先用十条人工打分样本校准裁判，上线后定期抽样复核
  • 涉及事实、安全、金额的输出必须人工看；裁判尽量换一家或换版本以避免自我偏好

  Key points

  • Prefer field comparison; reserve the judge for free text with nothing to compare
  • Judges favor long, well-formatted answers and score noisily on vague rubrics, so rubrics must list concrete points
  • Calibrate against ten human-scored samples first, then spot-check regularly
  • Facts, safety and money always get human review; use a different vendor or version to avoid self-preference

D5 跨模型迁移：Claude / GPT / 国产模型的差异、system prompt 组织；进入 Claude 课与 Codex 课

• 同一份提示词从一家模型迁到另一家，最常坏在哪里？你怎么区分是提示词的问题还是模型能力的问题？When you move a prompt from one model vendor to another, where does it break most often, and how do you tell a prompt problem from a genuine capability gap?

  国内高频海外高频进阶#model-migration#cross-model

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

  1. 这题在筛「有没有真的迁过」。没迁过的人会说「换个模型效果就差了」；迁过的人知道退步几乎都落在四处，而且多数不是能力差异。
  2. 拆法：四处断裂各配一个识别方法。格式标签——看输出里有没有出现你用来做结构的符号；指令强度——跑边界用例看是照办还是发挥；拒答边界——跑刁难用例看有没有新的拒答或多余说明；长度习惯——对比正常输入的输出长度与条目数。
  3. 区分提示词问题与能力问题：先看失败用例的字段能不能对上四处之一，能对上就改厂商适配块；对不上再看失败的是正常用例还是边界用例——能力差异通常在正常用例上也会体现，而边界用例上的退步几乎都是提示词里藏着只对某一家成立的默认。
  4. 结论：迁移退步十有九是「方言」没隔离，改厂商适配块就能恢复；真正的能力差异少见且会在正常用例上现形。
  5. 可预期的追问：接口兼容（同一份 SDK 调通）是不是就不用管了？不是——接口兼容只说明请求格式一样，四处断裂照样出现，而且更容易被忽略。

  How to reason about it · think before answering

  1. This screens for whether you have actually migrated a prompt. 'The other model is just worse' means no; people who have know failures cluster in four places and are rarely capability gaps.
  2. Four breakage points, each with a detection method: format markers — do your structural symbols leak into the output; instruction strength — does an edge case get followed literally or embellished; refusal boundaries — do adversarial cases trigger new refusals or disclaimers; length habits — compare output length and item counts on normal inputs.
  3. To separate prompt from capability: map failing fields to one of the four; if they match, fix the vendor block. If not, check whether failures are on normal or edge cases — capability gaps show on normal cases too, while edge-only regressions are almost always vendor-specific defaults hiding in the prompt.
  4. Conclusion: nine out of ten regressions are unisolated 'dialect' fixed in the vendor block; genuine capability gaps are rare and surface on normal cases.
  5. Follow-up: if the SDK is API-compatible, is migration free? No — compatible requests do not mean compatible interpretation, and the four breakages are easier to miss precisely because nothing crashed.

  答题要点

  • 四处最常坏：格式标签、指令强度、拒答边界、长度习惯，各有识别方法
  • 先把失败字段对四处对号，对上就改厂商适配块
  • 能力差异会在正常用例上现形；只在边界用例上退步几乎都是提示词的方言
  • 接口兼容不等于行为兼容，代码没改也要跑测试集

  Key points

  • Four usual suspects: format markers, instruction strength, refusal boundaries, length habits, each with a detection method
  • Map failing fields to one of the four first; a match means fix the vendor block
  • Capability gaps show on normal cases; edge-only regressions are almost always prompt dialect
  • API compatibility is not behavioral compatibility — rerun the test set even when no code changed
• 系统提示应该怎么组织才方便跨模型复用？怎么判断某一句该放哪一块？How should a system prompt be organized so it ports across models, and how do you decide which block a given sentence belongs to?

  国内高频海外高频进阶#system-prompt#model-migration

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

  1. 这题看似问结构，实际在考「有没有维护过多家模型共用的一份提示词」。答「写清楚一点就能通用」的人没维护过；维护过的人会先说分块。
  2. 拆法：三块各回答一个问题。通用规则——这一句换一家模型还成立吗，成立放这里（角色、任务、完成标准、带理由的约束、schema）；厂商适配——这一句是不是只对某一家成立，是的放这里（输入包裹方式、示例风格、长度提示、拒答边界表述、结构化输出开关），每家一份整块替换；任务变量——每次调用都在变吗，是的做成参数。
  3. 两条自检是区分度：把厂商块整块删掉，剩下的还是不是一份能读懂的提示词；通用块里搜有没有任何一家的专属词（标签名、API 参数名、风格偏好）。
  4. 结论：分块的收益不只是迁移——通用块是最长最稳定的前缀，放最前面缓存命中最高；厂商块每家固定；任务变量放最后。这跟 D1 讲系统提示要放稳定内容是同一条原则的延伸。
  5. 追问：few-shot 示例算哪一块？示例的内容属于通用规则，示例的书写风格（包裹标签、代码块风格）属于厂商适配，所以示例最好也拆成「内容 + 渲染」两层，或者至少不带厂商专属标签。

  How to reason about it · think before answering

  1. It looks structural but tests whether you have maintained one prompt across vendors. 'Just write it clearly' means no; experienced people start with blocks.
  2. Three blocks, one question each. Common rules — would this sentence still hold on another vendor? Role, task, done-criteria, reasoned constraints, schema. Vendor adaptation — is this true for one vendor only? Input wrapping, example style, length hints, refusal wording, structured-output switch; one per vendor, swapped wholesale. Task variables — does this change per call? Make it a parameter.
  3. Two self-checks are the differentiator: delete the vendor block entirely and see if what remains is still a readable prompt; grep the common block for any vendor-specific token — tag names, API parameter names, style preferences.
  4. Conclusion: the payoff goes beyond migration — the common block is the longest, most stable prefix, so leading with it maximizes prompt-cache hits; vendor block fixed per vendor; variables last. It extends the D1 principle of keeping stable content in the system prompt.
  5. Follow-up: where do few-shot examples go? Their content is common, their rendering (wrapping tags, code-block style) is vendor-specific, so split examples into content plus rendering, or at least keep vendor tags out of them.

  答题要点

  • 三块：通用规则（换模型仍成立）、厂商适配（每家一份整块替换）、任务变量（每次调用的参数）
  • 判据是两个问题：换一家还成立吗；每次调用都在变吗
  • 自检：删掉厂商块剩下的仍可读；通用块里没有任何一家的专属词
  • 顺序通用、厂商、变量，最稳定的前缀在前，缓存命中最高

  Key points

  • Three blocks: common rules that hold across vendors, a per-vendor adaptation block swapped wholesale, and per-call task variables
  • Two deciding questions: does it still hold on another vendor; does it change every call
  • Self-checks: the prompt stays readable with the vendor block removed; no vendor-specific tokens in the common block
  • Order common, vendor, variables so the most stable prefix leads and cache hits are maximized

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

D1 提示词进阶与 Claude 的「性格」：system prompt、XML 标签、让模型先思考、结构化输出

• 为什么用 XML 标签组织长提示词对 Claude 特别有效？和用 Markdown 分段比有什么区别？Why does organizing long prompts with XML tags work so well for Claude, and how does it differ from using Markdown sections?

  国内高频海外高频进阶#xml-tags#long-context

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

  1. 题眼在「为什么」。只答「官方推荐」等于没答；要能从「模型如何分辨内容边界」这个角度解释。
  2. 拆法：长提示词的核心风险是不同性质的内容（材料、指令、示例）混在一起，模型分错边界就会把材料里的句子当指令执行、或把示例当成事实。成对的标签给每一段一个明确的起止和名字，模型分辨边界的准确率更高，也能在回答里精确引用「哪一段」。
  3. 与 Markdown 的区别：Markdown 靠标题和围栏分段，但没有显式的结束标记；当贴进去的材料本身含 Markdown（比如一份 README）时容易串位。XML 标签成对、可嵌套、名字自定义，材料越杂优势越大。
  4. 补一条工程习惯：标签名前后一致，指令放在材料之后，回答时要求引用标签名。三到六个顶层标签是常态，不要过度包装。
  5. 可预期的追问：标签名有没有固定词表？没有，模型看的是结构和语义，但同一个提示词内要一致；另一个追问是「材料本身含 XML 怎么办」——换一个不会撞的标签名，或用 CDATA 式的转义说明。

  How to reason about it · think before answering

  1. The keyword is why. Citing the docs is not an answer; explain it in terms of how the model detects content boundaries.
  2. Breakdown: the core risk in a long prompt is mixing material, instructions, and examples. Paired tags give each part an explicit start, end, and name, so the model separates them reliably and can reference a specific section in its reply.
  3. Versus Markdown: headings and fences delimit but have no explicit closing marker, so pasted material that itself contains Markdown breaks the structure. XML tags are paired, nestable, and freely named, and the benefit grows with messier input.
  4. Add the engineering habits: consistent tag names, instructions after the material, and asking the model to cite tags in its answer. Three to six top-level tags is typical.
  5. Follow-ups: is there a fixed tag vocabulary? No — structure and semantics matter, consistency within one prompt matters. What if the material contains XML? Pick non-colliding names.

  答题要点

  • 长提示词的风险是材料、指令、示例混在一起；成对标签给每段明确的起止和名字
  • 模型分辨边界更准，也能在回答里精确引用某一段
  • Markdown 没有显式结束标记，材料含 Markdown 时会串位；XML 标签成对、可嵌套、可自定义
  • 习惯：标签名一致、指令放材料之后、要求引用标签、顶层标签三到六个

  Key points

  • Long prompts mix material, instructions, and examples; paired tags give each an explicit boundary and name
  • Boundary detection becomes reliable and the model can cite a specific section
  • Markdown has no closing marker and breaks when pasted material contains Markdown; XML tags are paired, nestable, and freely named
  • Habits: consistent names, instructions after material, ask for tag citations, three to six top-level tags
• 什么时候该让模型先写分析再回答，什么时候直接要结构化输出？两者能同时要吗？When should you have the model write its analysis before answering, and when should you go straight to structured output? Can you have both?

  国内高频海外高频进阶#structured-output#reasoning

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

  1. 这题考取舍，判据是「谁消费输出」和「错误的代价」。答「都用」或「看情况」没有信息量，要给出可执行的判断句。
  2. 推导链：分析段是输出 token，按输出价计费，且会让响应变长；它换来的是复杂任务上更高的准确率与可核对的推理过程。所以任务越复杂、错误代价越高、越需要人审计，越该要分析段；批量、简单、程序直接消费的任务，直接要结构化输出。
  3. 「能不能同时要」：一旦传了 JSON Schema，输出被约束成 JSON，自由文本的分析段没地方放。两条路：在 schema 里加一个 reasoning 字段放在其他字段前面（模型会先生成它），或者依赖模型内部的 thinking——它是内部推理，你控制深度不控制内容。
  4. 生产视角：结构化输出解决的是「解析可靠性」，不是「判断正确性」；schema 不支持数值范围与字符串长度约束，这些校验要自己补。
  5. 可预期的追问：分析段会不会被程序误用？会，所以要用标签把分析段与答案段分开，程序只取答案段；另一个追问是 thinking 与分析段的区别——一个内部一个外显，一个控深度一个控内容。

  How to reason about it · think before answering

  1. This is a trade-off question; the criteria are who consumes the output and what an error costs. Give a decision rule, not 'it depends'.
  2. Chain: the analysis is output tokens, billed at output rates and adding latency, in exchange for higher accuracy on complex tasks and an auditable trace. The more complex, high-stakes, or human-reviewed the task, the more you want it; bulk, simple, machine-consumed tasks go straight to structured output.
  3. Can you have both? Once a JSON schema is passed the output is constrained to JSON, so free-text analysis has nowhere to go. Two options: add a reasoning field placed before the other fields, or rely on the model's internal thinking, whose depth you control but not its content.
  4. Production nuance: structured output fixes parsing reliability, not judgment quality; the schema cannot express numeric ranges or string lengths, so validate those yourself.
  5. Follow-ups: can the analysis leak into downstream code? Yes — separate analysis and answer with tags and parse only the answer. Thinking versus a written analysis: internal versus visible, depth versus content.

  答题要点

  • 分析段：输出 token 计费、更慢，但复杂任务更准、过程可核对；适合高风险、需人审的任务
  • 结构化输出：程序直接消费、解析零失败；适合批量、简单、明确的抽取与分类
  • 同时要：在 schema 里加靠前的 reasoning 字段，或依赖内部 thinking
  • 结构化输出保证的是格式不是正确性；范围与长度校验要自己补

  Key points

  • Written analysis costs output tokens and latency but raises accuracy and gives an auditable trace — use for high-stakes, human-reviewed work
  • Structured output is consumed directly by code with zero parse failures — use for bulk, simple extraction and classification
  • To combine: put a reasoning field first in the schema, or rely on internal thinking
  • Structured output guarantees shape, not correctness; add range and length validation yourself

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

• 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
• citations 和在提示词里要求模型「引用原文并注明页码」有什么本质区别？什么场景下不能用 citations？How do API citations fundamentally differ from prompting the model to quote sources with page numbers, and when can't you use them?

  国内高频海外高频进阶#citations#grounding

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

  1. 这题考的是「可信度从哪来」。答成「citations 更方便」是表面；本质区别是谁来保证引用的真实性。
  2. 拆法：提示词方案里，引用和页码都是模型生成的自由文本——它可能顺手改写原文、可能记错页码，你无法区分「真引用」和「自以为引用」。citations 方案里，模型内部以标准格式输出引用意图，API 在服务端解析并核对，返回的 cited_text 一定是文档里真实存在的段落，page_location 的页码由 API 给出。真实性由 API 保证而不是由模型自觉保证。
  3. 附带的两点好处：cited_text 不计入输出 token，比让模型抄原文便宜；返回是结构化的内容块，程序可以直接高亮、跳转，不用正则去猜「第 3 页」出现在哪。
  4. 不能用的场景：与结构化输出（JSON Schema）不兼容，二者同开会报 400；此时要么放弃 API 级引用、在 schema 里留 page 字段让模型自己填（可靠性差一档），要么分两步：先 citations 拿事实，再用结构化输出整理。
  5. 可预期的追问：页码字段的语义？start_page_number 从 1 开始，end_page_number 不包含；多文档时 document_index 区分来源。再追问「能否验证引用质量」——能，用 cited_text 与原文做字符串比对，或抽样人工核对。

  How to reason about it · think before answering

  1. The question is about where trust comes from. 'Citations are more convenient' is surface; the real difference is who guarantees the quote is real.
  2. With prompting, both the quote and the page number are free text the model generates — it may paraphrase, it may misremember the page, and you cannot tell a real quote from an imagined one. With citations, the model emits citation intent in a standard format, the API parses and verifies it server-side, cited_text is guaranteed to exist in the document, and page_location comes from the API. Fidelity is enforced by the API rather than promised by the model.
  3. Two side benefits: cited_text does not count toward output tokens, so it is cheaper than asking the model to copy; and the result is structured content blocks your UI can highlight and jump to without regex guessing.
  4. When you can't: citations are incompatible with structured outputs (JSON Schema) — enabling both returns a 400. Either drop API-level citations and add a page field to the schema (one notch less reliable), or split into two calls: citations for facts, structured output for shaping.
  5. Follow-ups: page semantics — start_page_number is 1-indexed and end_page_number is exclusive; document_index distinguishes sources. Can you audit citation quality? Yes — string-match cited_text against the source, or sample manually.

  答题要点

  • 提示词引用是模型生成的自由文本，可能改写、记错页码，无法区分真假
  • citations 由 API 在服务端解析核对，cited_text 一定存在于文档中，页码由 API 给出
  • cited_text 不计输出 token，返回结构化便于高亮跳转
  • 与结构化输出互斥；需要两者时分两步或在 schema 留 page 字段

  Key points

  • Prompted quotes are free text the model generates — it may paraphrase or misplace pages, and you can't tell
  • Citations are parsed and verified server-side; cited_text is guaranteed to exist and page numbers come from the API
  • cited_text is free of output-token cost and the structured blocks enable highlighting and navigation
  • Mutually exclusive with structured outputs; split into two calls or add a page field to the schema

D3 Claude Code 入门与上下文管理：安装、CLAUDE.md 写法与「删到不能再删」、权限模式、Plan Mode「先探索再计划再写」、/clear /compact /rewind、给 Claude 一个可验证的检查

• 在 Claude Code 里为什么上下文窗口需要主动管理？/clear、/compact、/rewind 分别在什么时候用？Why does the context window need active management in Claude Code, and when do you use /clear, /compact, and /rewind respectively?

  国内高频海外高频进阶#context-window#claude-code

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

  1. 题眼是「主动」。被动等自动压缩也能用，面试官想知道你是否理解「窗口填满之前性能就已经在下降」。
  2. 先说为什么：Claude Code 读的每个文件、跑的每条命令输出、每轮对话都进同一个窗口，一次调试就是几万 token；窗口越满模型越容易忘掉早先的指令、越容易出错，所以不是满了才处理，而是从一开始就控制进什么。
  3. 再分三个命令，判据是「这段历史还有没有用」：任务切换且历史无用——/clear 清零；任务未完但窗口快满、历史有用——/compact 压缩成摘要，可带指令指定保留什么；走错了方向、想回到某个点——/rewind（Esc Esc）恢复对话或代码到检查点，也能只对某一段做摘要。
  4. 补两条经验规则：同一问题纠正两次还不对就 /clear 重开，失败的尝试留在窗口里只会继续污染；旁枝问题用 /btw，答案不进历史；查资料派给 subagent，让它在自己的窗口里翻。
  5. 可预期的追问：什么时候应该让上下文积累？深挖一个复杂问题、历史仍在被引用时；判据是下一步还会不会用到这段历史。再追问 rewind 的边界：只追踪 Claude 用编辑工具做的改动，Bash 改的文件不在其中，不替代 git。

  How to reason about it · think before answering

  1. The keyword is active. Waiting for auto-compaction works, but the interviewer wants to hear that performance degrades before the window is full.
  2. Why: every file read, command output, and turn lands in one window; a single debugging pass can be tens of thousands of tokens; as it fills the model forgets earlier instructions and errs more, so the discipline is controlling what enters from the start.
  3. Then the three commands, keyed on whether the history is still useful: switching tasks with useless history — /clear; mid-task with useful history but a filling window — /compact, optionally with instructions on what to keep; wrong direction — /rewind (Esc Esc) to restore conversation or code to a checkpoint, or summarize just one span.
  4. Two rules of thumb: after two failed corrections, /clear and rewrite the prompt — failed attempts keep polluting; use /btw for side questions that shouldn't enter history; delegate research to a subagent with its own window.
  5. Follow-ups: when should context accumulate? While deep in one problem where history is still referenced. Limits of rewind: it tracks only edits made through Claude's editing tools, not Bash-driven changes, and is no substitute for git.

  答题要点

  • 所有文件读取、命令输出、对话都进同一窗口；越满越容易忘指令、出错，要从一开始控制
  • /clear：切换任务、历史无用时清零；两次纠正无效也清
  • /compact：任务未完、历史有用但窗口快满；可带指令指定保留内容
  • /rewind：回到检查点恢复对话或代码，或只对一段做摘要；不替代 git

  Key points

  • Every read, output, and turn shares one window; fullness degrades adherence, so control inputs from the start
  • /clear between unrelated tasks or after two failed corrections
  • /compact mid-task when history matters but space runs low; pass instructions on what to keep
  • /rewind to a checkpoint for conversation or code, or summarize a span; not a git replacement
• 为什么说「给 Claude 一个可验证的检查」是用好 Agent 的分水岭？检查可以有哪几档硬度？Why is 'give Claude a check it can run' the dividing line for using agents well, and what levels of enforcement can that check have?

  国内高频海外高频进阶#verification#agent-loop

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

  1. 这题考对 Agent 循环的理解。答成「测试很重要」是常识；要说清没有检查时循环在谁那里闭合。
  2. 推导：Agent 在「做、看结果、改」的循环里工作，停下来的信号是「看起来做完了」。没有可运行的检查，「看起来做完了」是唯一信号，验证环落在人身上——每个错误都要等你注意到，你在场它是工具，你不在场它是风险。有了检查（测试、构建退出码、lint、比对脚本、截图对照），循环在机器里闭合：它做、它跑、它读结果、它改到通过，你只审证据。
  3. 硬度分四档：写进提示词（「实现后跑 pnpm test 直到全过」）——今天就能用；设为 /goal——独立评估器每轮复核直到达成；写成 Stop hook——测试不过不允许结束，确定性门禁；交给另一个 subagent 复核——做的人和判的人分开。每升一档多一点配置，换来少一点盯着。
  4. 生产视角：要求展示证据而不是宣布成功——贴测试输出、贴命令与返回值、贴截图；审证据比自己重跑快。
  5. 可预期的追问：检查本身会不会被绕过？会——模型可能改测试让它过。对策是把测试目录放进禁改清单，或让 reviewer subagent 专门核对「有没有为了过而改测试」。

  How to reason about it · think before answering

  1. This tests understanding of the agent loop. 'Tests matter' is common sense; explain where the loop closes without a check.
  2. Chain: an agent works in a do–observe–adjust loop and stops on 'looks done'. Without a runnable check, 'looks done' is the only signal and the verification step falls on you — every mistake waits to be noticed; present, it is a tool, absent, it is a risk. With a check (tests, build exit code, lint, diff-against-fixture, screenshot compare) the loop closes inside the machine: it works, runs, reads, and iterates to green while you review evidence.
  3. Four levels: in the prompt ('run the tests until they pass') — usable today; as a /goal — an independent evaluator re-checks every turn; as a Stop hook — the turn cannot end until the check passes, deterministic; as a reviewer subagent — the one who did the work is not the one grading it. Each step trades setup for attention.
  4. Production nuance: demand evidence, not claims — test output, commands and return values, screenshots; reviewing evidence beats re-running.
  5. Follow-up: can the check itself be gamed? Yes — the model might edit tests to pass. Counter with a deny rule on the test directory or a reviewer specifically checking for test tampering.

  答题要点

  • 没有检查时循环在人身上闭合，每个错误都等你发现；有检查时循环在机器里闭合
  • 检查可以是测试、构建、lint、比对脚本、截图对照，任何能产生通过/失败信号的东西
  • 四档硬度：提示词里要求、/goal 每轮复核、Stop hook 确定性门禁、subagent 独立复核
  • 要证据不要宣言；防止改测试作弊要靠禁改清单或专门的复核

  Key points

  • Without a check the loop closes on you; with one it closes inside the machine
  • A check is anything with a pass/fail signal: tests, build, lint, fixture diff, screenshot compare
  • Four levels: prompt instruction, /goal re-evaluation, Stop hook gate, independent reviewer subagent
  • Demand evidence over claims; guard against test tampering with deny rules or a dedicated reviewer

D4 扩展 Claude Code：hooks（确定性）vs CLAUDE.md（建议性）、skills、subagents、plugins、接 MCP server、CLI 工具优先

• skill 的渐进式加载是怎么回事？为什么能省上下文？description 应该怎么写？What is progressive loading for skills, why does it save context, and how should the description be written?

  国内高频海外高频进阶#skills#context

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

  1. 这题考的是「按需加载」这个设计思想，以及你有没有真写过 skill。第三问是区分度：description 写不好，skill 就形同虚设。
  2. 机制：会话开始时只有每个 skill 的 frontmatter 里那一行 description 常驻上下文；当模型判断当前任务相关、或用户输入 /name 时，正文才被读进来。所以正文长短几乎不影响日常成本，可以放几十步的流程、示例、注意事项。
  3. 对比 CLAUDE.md：它整份每次加载，是固定成本；一周只用两次的流程放进去等于其余时间白占窗口。把这类内容挪到 skill，是「删到不能再删」之后 CLAUDE.md 还能继续变短的主要手段。
  4. description 的写法：说清做什么 + 用户会怎么说（触发词），一百来字；太泛会被无关任务误触发，太窄永远触发不到。有副作用的流程（部署、发消息）加 disable-model-invocation: true 只允许手动 /name 触发。$ARGUMENTS 接参数，allowed-tools 预授权命令。
  5. 可预期的追问：怎么测 skill 有没有被触发？用几个自然语言说法试，看模型是否读了正文；再追问「skill 与 subagent 的区别」——skill 是在当前上下文里加载一份说明书，subagent 是另起一个上下文去做事，两者可以组合。

  How to reason about it · think before answering

  1. This tests the on-demand loading idea and whether you have actually written a skill. The third part separates candidates: a poorly written description makes the skill dead weight.
  2. Mechanism: at session start only each skill's one-line description from the frontmatter is resident; the body loads when the model judges the task relevant or the user types /name. Body length therefore barely affects daily cost, so it can hold long procedures, examples, and caveats.
  3. Contrast with CLAUDE.md: loaded in full every session, a fixed cost; a procedure used twice a week wastes the window the rest of the time. Moving such content into skills is how CLAUDE.md keeps shrinking after pruning.
  4. Writing the description: state what it does plus the phrases a user would say, about a hundred words; too broad triggers on unrelated tasks, too narrow never triggers. Add disable-model-invocation: true for side-effecting workflows so only /name invokes them; $ARGUMENTS takes parameters; allowed-tools pre-approves commands.
  5. Follow-ups: how do you test triggering? Try several natural phrasings and check whether the body loaded. Skill versus subagent: a skill loads a manual into the current context; a subagent opens a separate context to do work; they compose.

  答题要点

  • 只有 description 常驻，正文在被触发时才加载；正文长短几乎不影响日常成本
  • CLAUDE.md 整份每次加载；偶尔用的流程挪进 skill 是让它继续变短的手段
  • description 写「做什么 + 用户会怎么说」，一百来字，不泛不窄
  • 副作用流程加 disable-model-invocation；$ARGUMENTS 接参数

  Key points

  • Only the description is resident; the body loads on invocation, so body length barely costs
  • CLAUDE.md loads in full each time; moving occasional procedures to skills keeps it short
  • Write the description as what it does plus how users phrase it, about a hundred words
  • Side-effecting workflows get disable-model-invocation; $ARGUMENTS carries parameters
• subagent 解决了什么问题？它看得到主会话的历史吗？什么时候不该用？What problem do subagents solve? Do they see the main conversation's history? When should you not use one?

  国内高频海外高频进阶#subagents#context

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

  1. 题眼是「解决了什么问题」——答案是保护主会话的上下文窗口，而不是「并行」或「专业化」这些附带好处。第二问是常见误区，第三问考边界感。
  2. 推导：查资料、审代码这类任务的特征是「读很多、留很少」——读三十个文件只为一段结论。放在主会话里做，三十个文件全进窗口，真正的实现反而没地方放。subagent 拥有独立的上下文窗口，读完只把总结带回来，主会话只付总结的成本。
  3. 第二问：看不到。subagent 起步时只有系统提示、你派给它的任务描述、CLAUDE.md、git 状态快照；主会话的历史、你之前读过的文件、之前加载的 skill 都不在。这是限制也是优点：一个没有「刚写完这段代码」记忆的审查者更容易挑出毛病，D5 的对抗式审查就靠这个性质。
  4. 配置：.claude/agents/<name>.md，frontmatter 的 tools 限定它能用什么（审查者不给 Edit）、model 可以配更便宜或更强的模型；内置的 Explore 只读、Plan 用于计划模式、general-purpose 全能。
  5. 不该用的场景：需要多轮来回讨论的活（每次派出去都要重新交代）、几个阶段要共享大量上下文的活、一句话就能改完的活（交代 + 总结的开销大于任务本身）。可预期的追问：subagent 与 /compact 的关系——一个是不让东西进窗口，一个是进了以后压缩，前者更省。

  How to reason about it · think before answering

  1. The key is the problem solved: protecting the main conversation's context window, not the side benefits of parallelism or specialization. The second part is a common misconception; the third tests judgment.
  2. Chain: research and review tasks read a lot and keep little — thirty files for one conclusion. Done in the main session, all thirty land in the window and crowd out the actual implementation. A subagent has its own context window, reads everything, and returns only a summary; the main session pays only for the summary.
  3. Second part: no. A subagent starts with the system prompt, the task you delegated, CLAUDE.md, and a git status snapshot — not the main history, your earlier file reads, or previously loaded skills. That is both a limit and a strength: a reviewer without the memory of having just written the code finds more faults, which is what adversarial review in D5 relies on.
  4. Configuration: .claude/agents/<name>.md with tools restricting what it may use (no Edit for a reviewer) and model to pick a cheaper or stronger model; built-ins are Explore (read-only), Plan (plan mode research), and general-purpose.
  5. When not to: tasks needing multi-turn back-and-forth (every dispatch re-explains), phases that share heavy context, and one-line fixes where dispatch plus summary costs more than the work. Follow-up: subagent versus /compact — one keeps content out of the window, the other compresses it afterward; the former is cheaper.

  答题要点

  • 解决的是主会话上下文被「读很多留很少」的任务撑满；subagent 独立窗口，只带回总结
  • 看不到主会话历史，只有任务描述、CLAUDE.md、git 快照；因此审查更客观
  • tools 限定权限、model 选模型；内置 Explore / Plan / general-purpose
  • 不该用：多轮讨论、多阶段共享上下文、一句话能改完的小活

  Key points

  • Solves the main window being flooded by read-heavy, keep-little tasks; a subagent has its own window and returns a summary
  • It does not see the main history — only the task, CLAUDE.md, and a git snapshot — which makes its review more objective
  • tools restricts permissions, model picks the model; built-ins are Explore, Plan, general-purpose
  • Avoid for multi-turn discussion, heavy shared context across phases, and one-line fixes

D5 自动化与规模化：headless -p 进 CI、并行会话与 worktree、Writer / Reviewer 双会话、对抗式审查、常见失败模式；Agent SDK 20 行最小 agent

• 把 claude -p 放进 CI 时要控制哪三件事？具体用哪些参数？为什么推荐加 --bare？What three things must you control when running claude -p in CI, with which flags, and why is --bare recommended?

  国内高频海外高频进阶#headless#ci#permissions

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

  1. 这题考无人值守的风险意识。答「加个 API key 就能跑」会被判没上过线；面试官想听权限、预算、可复现三道锁，以及每道锁对应的参数。
  2. 权限：无人值守时没人回答「允许吗」，所以要么白名单放行（--allowedTools "Read,Grep" 或 "Bash(git diff *)"，注意 * 前的空格），要么定基线（--permission-mode dontAsk 一律拒绝白名单外的动作；acceptEdits 允许改文件），再加 --permission-prompts none 把本来要问人的动作直接拒掉。-p 模式的起始档位是 Manual，必须显式传。
  3. 预算：--max-turns 限轮数、--max-budget-usd 限花费，到了就停并报错。没有它们，一个卡在循环里的任务能耗尽额度；有 Stop hook 时要给足轮数，否则会以「轮数耗尽」而不是「测试通过」结束。
  4. 可复现：--bare 跳过 hooks、skills、插件、MCP、CLAUDE.md 的自动发现，让每台 runner 结果一致、启动更快；同时也是安全措施——不加它，clone 下来的陌生仓库里别人写的 hook 会在 -p 下无提示地执行（无头模式没有信任对话框）。配合 --no-session-persistence 不落盘，提示词与 --append-system-prompt 进版本控制。
  5. 可预期的追问：--bare 之后怎么认证？它不读订阅登录，必须设 ANTHROPIC_API_KEY；再追问怎么判断成败——--output-format json 的 is_error / subtype / total_cost_usd，退出码非零脚本就 fail。

  How to reason about it · think before answering

  1. This tests awareness of unattended risk. 'Add an API key and run it' reads as no production experience; the interviewer wants the three locks — permissions, budget, reproducibility — each with its flags.
  2. Permissions: nobody answers 'allow?' unattended, so either allowlist tools (--allowedTools "Read,Grep" or "Bash(git diff *)", mind the space before *) or set a baseline (--permission-mode dontAsk denies anything outside the allowlist; acceptEdits permits file edits), plus --permission-prompts none to deny anything that would have prompted. -p starts in Manual on every plan, so pass the mode explicitly.
  3. Budget: --max-turns caps turns, --max-budget-usd caps spend; both stop with an error. Without them a looping task can drain your quota; with a Stop hook, allow enough turns or the run ends on 'max turns' rather than 'tests pass'.
  4. Reproducibility: --bare skips auto-discovery of hooks, skills, plugins, MCP, and CLAUDE.md so every runner behaves the same and starts faster — and it is a security measure, since a cloned repo's hooks would otherwise run silently under -p (no trust dialog). Add --no-session-persistence and keep the prompt and --append-system-prompt in version control.
  5. Follow-ups: authentication under --bare — it ignores subscription login, so set ANTHROPIC_API_KEY. Judging success — is_error, subtype, and total_cost_usd from --output-format json; fail the job on a non-zero exit.

  答题要点

  • 权限：--allowedTools 白名单 + --permission-mode dontAsk / acceptEdits + --permission-prompts none；-p 默认 Manual 必须显式传
  • 预算：--max-turns 与 --max-budget-usd，到了就停；有 Stop hook 时给足轮数
  • 可复现：--bare 跳过本机配置自动发现，也防陌生仓库的 hook 在 CI 上跑；--no-session-persistence
  • --bare 需要 ANTHROPIC_API_KEY；成败看 --output-format json 的 is_error 与退出码

  Key points

  • Permissions: --allowedTools allowlist plus --permission-mode dontAsk or acceptEdits and --permission-prompts none; -p defaults to Manual
  • Budget: --max-turns and --max-budget-usd stop the run; leave headroom for Stop hooks
  • Reproducibility: --bare skips local auto-discovery and keeps a cloned repo's hooks from running in CI; --no-session-persistence
  • --bare requires ANTHROPIC_API_KEY; judge success from is_error in the JSON and the exit code
• 为什么 Writer / Reviewer 双会话的审查比同一个会话自查更有效？审查者报出来的问题要全改吗？Why is a Writer / Reviewer two-session review more effective than self-review in one session, and should you fix everything the reviewer reports?

  国内高频海外高频进阶#review#subagents

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

  1. 题眼是「为什么」和后半句。答「多一双眼睛」是常识；要说清上下文在这里扮演的角色，以及审查的副作用。
  2. 推导：写完实现的会话，上下文里装满了「我为什么这么写」的推理；让它自审，它倾向于确认而不是质疑——这不是态度问题，是上下文偏置。Reviewer 换一个全新的上下文，只看到 diff 和你给的标准，不知道 Writer 的理由，所以挑的是代码本身的毛病。这和人类 code review 要求「非作者审」是同一个道理。
  3. 形态有三种：两个终端手动传递输出；一个 subagent 做对抗式审查（独立上下文天然就是无记忆的审查者，而且结果直接回到主会话可以立刻修）；内置的 /code-review 在新 subagent 里审当前 diff。同样的思路可以反过来用：一个会话写测试，另一个写实现去通过。
  4. 后半句是区分度：不要全改。被要求找问题的审查者一定会报出问题来，哪怕代码没毛病；照单全收会导致过度工程——多余抽象、防御不存在情况的代码、测不可能发生的用例。审查提示词里要写「只报告影响正确性或明确需求的差距，其余视为可选」，最终由人判断。
  5. 可预期的追问：Reviewer 需要什么输入？diff、计划或需求（PLAN.md）、明确的判据；给它 Writer 的推理过程反而会削弱独立性。再追问「能不能自动化」——能，-p 模式里一条命令跑 Reviewer，结果贴回 PR。

  How to reason about it · think before answering

  1. The point is the why and the second half. 'A second pair of eyes' is common sense; explain the role of context and the side effect of review.
  2. Chain: the session that wrote the code has a context full of its own reasoning; asked to review, it tends to confirm rather than challenge — a context bias, not an attitude problem. A Reviewer in a fresh context sees only the diff and your criteria, not the Writer's reasons, so it critiques the code itself. Same principle as non-author code review among humans.
  3. Three shapes: two terminals passing output by hand; a subagent doing adversarial review (its isolated context is the memoryless reviewer, and findings land back in the main session for immediate fixing); the built-in /code-review that reviews the current diff in a fresh subagent. The idea also inverts: one session writes tests, another writes the implementation to pass them.
  4. The second half separates candidates: don't fix everything. A reviewer told to find gaps will report some even in sound code; accepting all of it leads to over-engineering — extra abstraction, defensive code for impossible cases, tests for unreachable paths. Tell it to flag only gaps affecting correctness or stated requirements, and let a human decide.
  5. Follow-ups: what does the Reviewer need? The diff, the plan or requirements, explicit criteria; feeding it the Writer's reasoning weakens independence. Can it be automated? Yes — run the Reviewer via -p and post results to the PR.

  答题要点

  • 自审受上下文偏置：装满自己推理的会话倾向于确认而非质疑
  • Reviewer 用全新上下文，只看 diff 与判据，挑的是代码本身的毛病
  • 形态：双终端、subagent 对抗式审查、内置 /code-review；反向可用于测试先行
  • 不要全改：审查者必报问题，照单全收导致过度工程；限定只报影响正确性的差距

  Key points

  • Self-review suffers context bias: a session full of its own reasoning confirms rather than challenges
  • A Reviewer in a fresh context sees only the diff and criteria, so it critiques the code itself
  • Shapes: two terminals, an adversarial subagent, built-in /code-review; invert for test-first
  • Don't fix everything: reviewers always report something; limit findings to correctness and stated requirements

Codex 与 OpenAI Agents SDK 高效使用

D1 Codex CLI 入门：安装、AGENTS.md、审批模式与沙箱、常用命令

• Codex 把「什么时候问用户」和「能碰到什么」拆成 approval_policy 和 sandbox_mode 两组独立开关。为什么要拆？各自解决什么问题？Codex splits 'when to ask the user' and 'what can be touched' into two independent settings, approval_policy and sandbox_mode. Why separate them, and what does each solve?

  国内高频海外高频进阶#coding-agent#security#sandbox

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

  1. 题眼是「为什么拆」。只背出每组的取值等于没答，面试官要听的是两者正交带来的好处。
  2. 先给定义：审批策略是流程控制，决定动作执行前要不要人点头；沙箱是权限控制，决定即使模型想做、操作系统允不允许。
  3. 再说为什么正交：你可能想要「不打扰我，但绝不许出工作区」（on-request 加 workspace-write），也可能想要「每步都问，但只让它读」（untrusted 加 read-only）；合成一个滑杆就表达不了这两种组合。
  4. 落到实现：沙箱靠操作系统机制（macOS Seatbelt、Linux bubblewrap），不是靠模型自觉，所以它是硬约束；审批则是唯一由人把关的环节。
  5. 可预期的追问：为什么网络默认关？因为联网是把内部代码送出去或把外部代码拉进来的通道，风险等级和改本地文件不同，需要单独授权。

  How to reason about it · think before answering

  1. The discriminating part is 'why separate'; reciting the values without explaining orthogonality earns little.
  2. Define both: approval policy is process control, whether a human must nod before an action; sandbox is permission control, whether the OS allows the action at all.
  3. Then justify orthogonality with combinations a single slider cannot express: 'do not interrupt me but never leave the workspace' versus 'ask every time but read-only'.
  4. Ground it in implementation: the sandbox uses OS mechanisms (Seatbelt on macOS, bubblewrap on Linux) rather than model goodwill, so it is a hard limit, while approval is the one human checkpoint.
  5. Expect the follow-up: why is network off by default? Because network is the channel for code leaving or entering the machine, a different risk class from local edits.

  答题要点

  • approval_policy 管流程：untrusted / on-request / on-failure / never 决定动作前是否要人确认
  • sandbox_mode 管权限：read-only / workspace-write / danger-full-access 决定操作系统放行什么
  • 两者正交才能表达「不打扰但不越界」和「步步问但只读」这类组合
  • 沙箱是操作系统级硬约束，审批是唯一的人工把关点；网络默认关闭需单独放开

  Key points

  • approval_policy governs process: untrusted / on-request / on-failure / never decide whether a human confirms first
  • sandbox_mode governs permission: read-only / workspace-write / danger-full-access decide what the OS allows
  • Orthogonality lets you express 'no interruptions but stay in the workspace' and 'ask each step but read-only'
  • The sandbox is an OS-level hard limit, approval is the human checkpoint, and network is off by default
• 你要在团队里引入一个能在本地执行命令的 coding agent，怎么向不放心的同事解释它的风险边界？You want to introduce a coding agent that runs commands locally. How do you explain its risk boundary to skeptical teammates?

  国内高频海外高频进阶#coding-agent#security#communication

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

  1. 这题考的是沟通加工程两层：既要说清技术上的边界，又要用对方能验证的方式说，不能只说「它很安全」。
  2. 拆成三层防线来讲：第一层文字规则（AGENTS.md）管习惯；第二层沙箱管能力，只读或只能写工作区、网络默认关；第三层审批管例外，越界的每一步都要人批。
  3. 给出可验证的承诺：所有改动都在 git 工作区里，`git diff` 能看、`git checkout` 能撤；脱手运行只跑在一次性分支或容器里。
  4. 主动说出剩余风险：模型可能误读需求写出错误但能通过的代码，所以审查和测试不能省；密钥不要放在它能读到的文件里。
  5. 可预期的追问：能不能完全禁止它联网？可以，沙箱默认就不通网，需要装依赖时逐次批准，或在配置里给一个允许的域名清单。

  How to reason about it · think before answering

  1. This tests communication as much as engineering: state the technical boundary in terms the listener can verify, not just 'it is safe'.
  2. Present three layers of defense: written rules (AGENTS.md) shape habits; the sandbox limits capability to read-only or workspace-only writes with network off; approvals gate every exception.
  3. Offer verifiable guarantees: every change lands in the git working tree, visible via diff and revertable via checkout; unattended runs stay on throwaway branches or containers.
  4. Name the residual risk yourself: the model can misread a requirement and produce wrong but passing code, so review and tests remain mandatory, and secrets stay out of readable files.
  5. Expect the follow-up: can network be fully blocked? Yes, the sandbox is offline by default; approve installs case by case or configure an allow-list of domains.

  答题要点

  • 三层防线：文字规则管习惯、沙箱管能力、审批管例外
  • 改动全在 git 工作区，可 diff 可撤销；脱手运行只在一次性分支或容器
  • 主动说明剩余风险：错误但能通过的代码、密钥暴露，所以审查与测试不能省
  • 网络默认关闭，联网按次批准或配置允许域名清单

  Key points

  • Three layers: written rules for habits, the sandbox for capability, approvals for exceptions
  • All edits live in the git working tree and are diffable and revertable; unattended runs use throwaway branches or containers
  • State residual risks yourself: wrong-but-passing code and secret exposure, hence mandatory review and tests
  • Network is off by default; approve per request or configure an allow-list

D2 Codex 进阶：云端任务、代码审查、MCP 接入、自定义指令、IDE 集成

• 云端 coding agent 能同时跑很多任务，但没有人在旁边点头。它的审批边界应该画在哪里？A cloud coding agent can run many tasks in parallel with nobody around to approve steps. Where should its approval boundary sit?

  国内高频海外高频进阶#coding-agent#cloud#approvals

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

  1. 这题考的是你有没有意识到「审批模型变了」：本地是逐步审批，云端只能事先授权、事后审阅。答成「跟本地一样弹窗」说明没用过。
  2. 拆法是把边界分成三个时间点：任务开始前（环境配置决定能联网什么、有哪些变量、装什么依赖）、任务执行中（容器隔离，改动只在容器里）、任务结束后（人审 diff 再决定开不开 PR）。
  3. 结论是：云端的审批边界就是「环境配置 + PR 前人工审阅」这两道门，中间不再有人；所以生产密钥不能进环境、公网默认关、合并权限保留在人手里。
  4. 补一条工程视角：并行任务之间的边界也要画——互相会改同一批文件的任务不要同时派，否则合并成本吃掉并行收益。
  5. 可预期的追问：能不能让它自动合并？可以在低风险仓库对通过全部测试的 PR 这么做，但要保留回滚手段，并且把「自动合并」本身当成一个需要审批的配置变更。

  How to reason about it · think before answering

  1. This checks whether you noticed the approval model changed: local means step-by-step approval, cloud means authorize upfront and review afterwards.
  2. Split the boundary across three moments: before the task (environment config decides network, variables, dependencies), during (container isolation), after (a human reviews the diff before any PR).
  3. Conclude that the cloud boundary is two gates, environment config plus pre-PR human review, with nobody in between; hence no production secrets, network off by default, merge rights stay human.
  4. Add the engineering angle: draw boundaries between parallel tasks too; tasks that touch the same files should not run concurrently.
  5. Expect the follow-up: can it auto-merge? Only in low-risk repos for fully green PRs, with rollback in place, and treat enabling auto-merge as a change that itself needs approval.

  答题要点

  • 云端没有逐步审批，边界变成事前的环境配置与事后的人工审阅两道门
  • 环境里不放生产密钥、公网默认关、合并权限保留给人
  • 并行任务之间也要画边界：会改同一批文件的任务不同时派
  • 自动合并只适用于低风险仓库且全绿的 PR，并保留回滚

  Key points

  • No step-wise approval in the cloud; the boundary becomes upfront environment config plus post-hoc human review
  • Keep production secrets out, network off by default, merge rights with humans
  • Draw boundaries between parallel tasks: never run file-overlapping tasks concurrently
  • Auto-merge only for low-risk repos with fully green PRs, with rollback ready
• 让同一个模型既写代码又审代码，审查还有意义吗？怎么让审查更独立？If the same model both writes and reviews code, is the review still meaningful? How do you make it more independent?

  国内高频海外高频进阶#code-review#coding-agent#workflow

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

  1. 题眼在「还有意义吗」——直接答「没意义」或「有意义」都不及格，要说清它能抓什么、抓不到什么。
  2. 先说能抓的：审查时输入变了（看 diff 而不是需求）、立场变了（找问题而不是完成任务），这种角色切换能抓出漏掉的边界情况、没同步的调用方、明显的风格违规。
  3. 再说抓不到的：审查者和生成者共享同一份对需求的理解，需求理解错了两边一起错；也共享同样的盲区与偏好。
  4. 结论给三条提高独立性的手段：换一家模型审、给审查者不同的信息（需求原文加验收标准而不是只给 diff）、用确定性工具（测试、lint、类型检查）做第一道审查。
  5. 可预期的追问：审查意见要不要自动应用？不要，审查是输入不是判决，误报与漏报都存在，最终判断留给人。

  How to reason about it · think before answering

  1. The crux is 'still meaningful'; a flat yes or no fails. Explain what it catches and what it misses.
  2. What it catches: the input changes (diff instead of requirements) and the stance changes (find faults instead of finish the job), which surfaces missed edge cases, unsynced callers and style violations.
  3. What it misses: reviewer and author share one understanding of the requirement, so a misread requirement passes; they share blind spots too.
  4. Conclude with three independence levers: review with a different vendor's model, feed the reviewer different information (original requirement plus acceptance criteria, not just the diff), and run deterministic checks first.
  5. Expect the follow-up: auto-apply review comments? No; review is input, not verdict, and both false positives and misses exist.

  答题要点

  • 有意义：输入与立场的切换能抓出边界情况、未同步的调用方、风格违规
  • 抓不到与需求理解相关的错误，因为审查者与生成者共享同一份理解
  • 提高独立性：换一家模型审、给审查者需求原文与验收标准、先跑确定性检查
  • 审查意见是输入不是判决，不要自动应用

  Key points

  • Yes: the switch of input and stance catches edge cases, unsynced callers and style issues
  • It misses requirement misreads because author and reviewer share one understanding
  • Increase independence: a different vendor's model, richer reviewer context, deterministic checks first
  • Treat comments as input, never auto-apply

D3 Responses API 与内置工具：函数调用、web search / file search / computer use、结构化输出

• 平台内置的工具（web search、file search、computer use）和自己写的函数工具，各适合什么场景？为什么 computer use 要单独对待？When do you use platform built-in tools (web search, file search, computer use) versus your own function tools, and why does computer use deserve special treatment?

  国内高频海外高频进阶#tools#responses-api#security

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

  1. 题眼有两个：一是「谁来执行」，二是「副作用有多大」。只答功能对比不谈执行方与风险，就是没做过工程。
  2. 先给执行方的判据：内置工具由平台在服务端执行，你只声明、不回填、也控制不了它怎么搜；函数工具由你执行，样样自己写，但每一步都在你手里。
  3. 落到场景：数据在外面且通用（公网、你上传的文档）用内置工具；数据在你系统里（数据库、内部服务、业务逻辑）写函数；生产系统几乎总是混用。
  4. 再按副作用排一条光谱：web search 只读公网，file search 只读你给的文件，函数调用的副作用由你的代码决定，computer use 由模型直接产生副作用——越往右能力越强，需要的隔离越重。
  5. computer use 单独对待的原因：它能点任何按钮、输任何文字，还可能被页面内容诱导，所以正确起点是隔离环境、受限账号和站点与动作白名单，不是代码。
  6. 可预期的追问：内置的 file search 和自己搭 RAG 怎么选？前者是托管版，省掉切分、向量化、检索三步，代价是可控性与可观测性弱，需要自定义切分或重排时才自己搭。

  How to reason about it · think before answering

  1. Two cruxes: who executes the tool, and how large its side effects are; comparing features alone signals no production experience.
  2. Executor test: built-in tools run server-side, you declare but never fill results and cannot steer the search; function tools run in your code, more work but full control.
  3. Map to scenarios: external, generic data (the web, your uploaded documents) fits built-ins; data inside your systems (databases, internal services, business logic) needs functions; production mixes both.
  4. Order by side effects: web search reads the public web, file search reads your files, function calls have whatever side effects your code allows, computer use lets the model act directly; more capability demands heavier isolation.
  5. Computer use is special because it can click anything, type anything and be steered by on-screen content, so the starting point is an isolated environment, a restricted account and an allow-list, not code.
  6. Expect the follow-up: built-in file search versus your own RAG? The built-in is a managed pipeline that skips chunking, embedding and retrieval work at the cost of control and observability; build your own when you need custom chunking or reranking.

  答题要点

  • 内置工具由平台执行、不用回填、不可干预；函数工具由你执行、全部可控
  • 外部通用数据用内置工具，系统内数据与业务逻辑写函数，生产混用
  • 按副作用排序：web search、file search、函数调用、computer use，能力越强隔离越重
  • computer use 的起点是隔离环境与白名单，不是代码

  Key points

  • Built-ins run on the platform with no result filling and no steering; functions run in your code with full control
  • External generic data suits built-ins, in-system data and business logic need functions, production mixes both
  • Rank by side effects: web search, file search, function calls, computer use; more power needs more isolation
  • Computer use starts with an isolated environment and an allow-list, not with code
• 结构化输出的 strict 模式解决了什么问题，没解决什么问题？拿到输出之后代码里还要做什么？What does strict mode in structured outputs solve, what does it not solve, and what must your code still do after receiving the output?

  国内高频海外高频进阶#structured-output#responses-api#validation

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

  1. 这题考的是对「格式正确」与「内容正确」的区分，答成「有了 strict 就不用校验了」是典型的错误。
  2. 先说解决了什么：strict 加 json_schema 保证输出一定能通过 schema 校验——枚举只会是给定值、必填字段一定在、类型不会错，解析层的 try/catch 与重试基本可以删掉。
  3. 再说没解决什么：schema 管不了语义。verdict 一定是两个枚举之一，但判断可能是错的；数字一定是数字，但可能是编的。业务层校验一行不能省。
  4. 然后是拒答分支：模型因安全原因拒绝时返回 refusal 类型的内容块，而不是硬塞一个不合法的 JSON；不处理它，下游会拿到空的解析结果直接崩，处理了才能区分「不愿意」与「没做对」。
  5. 给出代码里的顺序：先查 refusal，再读 output_parsed，再做业务校验（范围、引用是否存在、与上下文是否一致），最后才落库或执行。
  6. 可预期的追问：strict 对 schema 有什么限制？每个对象都要 additionalProperties 为 false、字段都要在 required 里，可选字段用可空类型表达；这些限制正是它能给出保证的原因。

  How to reason about it · think before answering

  1. This tests the distinction between well-formed and correct; claiming strict mode removes the need for validation is the classic mistake.
  2. What it solves: strict plus json_schema guarantees the output validates against the schema, so enums are always allowed values, required fields exist and types are right; parsing-layer try/catch and retries can largely go.
  3. What it does not solve: semantics. The verdict is one of two enums but may be wrong; a number is a number but may be invented. Business validation stays.
  4. Then refusals: a safety refusal comes back as a refusal content block, not malformed JSON; unhandled, downstream code crashes on an empty parse, handled, you can separate unwilling from incorrect.
  5. Give the order in code: check refusal, read output_parsed, run business checks (ranges, referenced entities exist, consistency with context), then persist or act.
  6. Expect the follow-up: schema restrictions under strict? Every object needs additionalProperties false and all fields in required, optional fields become nullable; these constraints are exactly what makes the guarantee possible.

  答题要点

  • 解决：输出保证符合 schema，解析层防御代码可以删
  • 没解决：语义正确性，业务校验一行不能省
  • 先查 refusal 再读 output_parsed，再做业务校验，最后落库
  • strict 要求 additionalProperties 为 false、字段全在 required 里，可选用可空类型表达

  Key points

  • Solves: output is guaranteed to match the schema, so parsing defenses can go
  • Does not solve: semantic correctness, so business validation stays
  • Check refusal first, then output_parsed, then business checks, then persist
  • Strict requires additionalProperties false and all fields required, optional fields become nullable

D4 OpenAI Agents SDK：agents、handoffs、guardrails、sessions、tracing

• 什么时候该把一个 Agent 拆成多个、用 handoff 交接？什么时候「一个大 Agent 加很多工具」反而更好？When should you split one agent into several connected by handoffs, and when is a single agent with many tools the better design?

  国内高频海外高频进阶#agents-sdk#handoffs#architecture

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

  1. 这题考的是拆分判据，不是会不会用 API。答「工具多了就拆」是最常见的错误，工具数量不是判据。
  2. 先说清 handoff 与工具的区别：调工具是替你去问一句再回来，handoff 是把对话整个交给另一个 Agent，之后由它负责；实现上 handoff 也是一个名为 transfer_to_xxx 的工具，但语义是转移控制权。
  3. 判据是「指令会不会互相打架」：两组任务需要的背景知识、约束、语气彼此独立且冲突时，塞进一份 instructions 会让模型反复切换上下文、提示越长越贵、出错率上升，这时拆；工具虽多但共享同一套背景的，不拆。
  4. 补拆分的代价：多一次模型调用（分诊那一跳）、路由可能错、输入护栏只在第一个 Agent 上跑、跨 Agent 的历史要靠 inputFilter 裁剪。
  5. 可预期的追问：分诊错了怎么办？用 RECOMMENDED_PROMPT_PREFIX 提高交接准确率，用 lastAgent 做回归断言，用 tracing 看交接发生在哪一轮，必要时让专家 Agent 也能交接回分诊台。

  How to reason about it · think before answering

  1. This tests your splitting criterion, not API fluency; 'split when there are many tools' is the common wrong answer.
  2. First separate handoffs from tools: a tool call fetches an answer and returns; a handoff transfers the whole conversation so the receiving agent owns it, even though it is implemented as a transfer_to_xxx tool.
  3. The criterion is whether instructions conflict: when two task groups need independent, clashing background, constraints and tone, one instruction block forces constant context switching, longer prompts and more errors, so split; many tools sharing one background do not justify a split.
  4. Name the costs: an extra model call for triage, possible misrouting, input guardrails only on the first agent, and history trimming across agents via inputFilter.
  5. Expect the follow-up: what if triage misroutes? Use RECOMMENDED_PROMPT_PREFIX, assert on lastAgent in regression tests, inspect the handoff turn in tracing, and allow experts to hand back.

  答题要点

  • handoff 转移的是对话控制权，工具调用只是取一次结果
  • 拆分判据是指令是否互相打架，不是工具数量
  • 拆的代价：多一跳、可能路由错、输入护栏只在第一个 Agent 生效
  • 用前缀提示、lastAgent 断言与 tracing 控制路由质量

  Key points

  • A handoff transfers conversational control; a tool call only fetches a result
  • Split on conflicting instructions, not on tool count
  • Costs: an extra hop, possible misrouting, input guardrails only on the first agent
  • Control routing quality with the recommended prefix, lastAgent assertions and tracing
• Agents SDK 的 session 和 Responses API 的 previous_response_id 都能记住多轮，怎么选？tracing 在这里起什么作用？Both Agents SDK sessions and the Responses API's previous_response_id remember multi-turn state. How do you choose, and what role does tracing play?

  国内高频海外高频进阶#agents-sdk#sessions#tracing

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

  1. 这题考的是对「状态放在谁手里」的敏感度，是 30 天课 D1「历史靠你自己搬」在 SDK 层的翻版。
  2. 拆法是问三件事：历史能不能审计、能不能裁剪或重放、能不能满足数据驻留要求。previous_response_id 的历史在服务端，请求最小、代码最简，但三个问题都答不好；session 的历史在你手里（内存、SQLite、Redis），三个都能做，代价是自己管存储。
  3. 结论：原型与内部工具用 previous_response_id 省事；面向用户的生产系统至少自己落一份历史，session 是现成的落法；两者可以同时用。
  4. session 的四个接口（取、追加、弹出最后一条、清空）里 pop_item 值得点出：用户撤回上一句时把最后一轮拿掉再重跑，这是自己持有历史才能做的事。
  5. tracing 的作用是让多 Agent 系统的行为可解释：默认开启，每次 run 一条，记录每轮、每次工具调用、交接与护栏判断；用 withTrace 或 group_id 把一段对话归到一起；敏感数据场景用环境变量关掉或换成自己的导出器。
  6. 可预期的追问：tracing 会不会把用户数据传出去？默认会传到平台面板，所以合规场景要么关、要么 setTraceProcessors 换成自己的后端。

  How to reason about it · think before answering

  1. This probes your sensitivity to who holds the state, the SDK-level echo of 'you carry the history yourself'.
  2. Ask three questions: can the history be audited, trimmed or replayed, and kept within data-residency rules? previous_response_id keeps history server-side with minimal requests but answers all three poorly; sessions keep it in your store and answer all three, at the cost of managing storage.
  3. Conclude: prototypes and internal tools take previous_response_id; user-facing production keeps its own copy, for which sessions are the ready-made path; both can coexist.
  4. Of the four session operations, pop_item deserves mention: removing the last turn to honor a user's undo is only possible when you own the history.
  5. Tracing makes multi-agent behavior explainable: on by default, one trace per run recording turns, tool calls, handoffs and guardrail results; group a conversation with withTrace or group_id; disable via env var or swap in your own exporter for sensitive data.
  6. Expect the follow-up: does tracing ship user data out? By default it goes to the platform dashboard, so regulated settings must disable it or replace the processors.

  答题要点

  • previous_response_id 历史在服务端，请求小代码简，但难审计、难裁剪、难满足数据驻留
  • session 历史在自己手里，可审计可重放，pop_item 支持撤回；生产至少自己落一份
  • tracing 默认开、每次 run 一条，记录每轮工具、交接与护栏，用 group_id 归组
  • 敏感数据场景用 OPENAI_AGENTS_DISABLE_TRACING 关掉或换成自己的导出器

  Key points

  • previous_response_id keeps history server-side, small and simple, but weak on audit, trimming and residency
  • Sessions keep history in your store, auditable and replayable, with pop_item for undo; production keeps its own copy
  • Tracing is on by default, one trace per run, capturing turns, tools, handoffs and guardrails, grouped via group_id
  • For sensitive data disable it with OPENAI_AGENTS_DISABLE_TRACING or swap in your own exporter

D5 Claude 与 Codex 选型与协作：同一任务双工具实测对比、一个写一个审的混用工作流

• 团队要在两家 coding agent 之间选一个，你怎么给出一套可以向团队解释、也能被验证的对比维度？Your team must pick between two coding agents. How do you propose a comparison that teammates can both understand and verify?

  国内高频海外高频进阶#coding-agent#evaluation#decision-making

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

  1. 这题考的是方法论而不是结论。上来就说「我觉得 X 好」会被判为没有工程判断；面试官想听的是你怎么让比较可复现。
  2. 先给维度：交代（写多少需求、准备多少说明文件）、审批（中断几次、为了什么）、验证（是否主动跑测试、红了怎么办）、成本（时间、token、钱）。这四项都能在自己的仓库里量出来。
  3. 再给可比性的前置条件：同一个起点 commit、同一段需求文字、说明文件同内容、默认权限、都要求跑完测试再汇报；有一项不同，差异就说不清来源。
  4. 然后是读数的顺序：先查可比性，再看结构性差异（权限模型、说明文件的位置与措辞导致的行为差别），最后才看能力差异，而且能力差异要多次运行取中位数。
  5. 落到团队沟通：报告里每一行差异都标「来自工作方式还是能力」，工作方式的差异靠配置弥补，能力差异才影响选型。
  6. 可预期的追问：榜单为什么不够？榜单测标准题，团队干的是有历史包袱的仓库里的改动，且榜单只给一个分数、不给四个维度。

  How to reason about it · think before answering

  1. This tests methodology, not a verdict; leading with 'I prefer X' signals weak engineering judgment. Show how you make the comparison reproducible.
  2. Give the dimensions: instruction effort (prompt and instruction-file size), approvals (how many interruptions and why), verification (does it run tests unprompted, what happens on red), cost (time, tokens, money). All are measurable in your own repo.
  3. State the preconditions for comparability: same starting commit, identical requirement text, identical instruction-file content, default permissions, and 'run tests before reporting' on both sides.
  4. Then the reading order: check comparability, then structural differences (permission model, placement and wording of rules), and only then capability differences, which need several runs and a median.
  5. For the team: label every differing row as 'workflow' or 'capability'; workflow gaps are closed by configuration, capability gaps drive the choice.
  6. Expect the follow-up: why not benchmarks? They score standard problems with one number, while teams change legacy repos and care about four dimensions.

  答题要点

  • 四个可量维度：交代、审批、验证、成本，全部在自己仓库里测
  • 可比性前置：同起点、同需求、同说明文件、默认权限、都要求跑测试
  • 读数顺序：可比性、结构性差异、能力差异；能力差异要多次运行取中位数
  • 每行差异标「工作方式还是能力」，前者靠配置弥补，后者才决定选型

  Key points

  • Four measurable dimensions: instruction effort, approvals, verification, cost, all measured in your own repo
  • Comparability first: same commit, same prompt, same instruction file, default permissions, tests required
  • Read in order: comparability, structural differences, then capability, with medians over several runs
  • Label each gap as workflow or capability; only capability gaps should drive the decision
• 「一家写、另一家审」的混用工作流收益在哪？什么情况下不值得？Where does the 'one vendor writes, the other reviews' workflow pay off, and when is it not worth it?

  国内高频海外高频进阶#code-review#workflow#coding-agent

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

  1. 题眼在「不值得」。只讲收益不讲代价，是没在预算表前坐过的人的答法。
  2. 先说收益的来源：同一家模型写与审共享同一份对需求的理解，需求理解偏差抓不出来；换一家审，最大的增量正是这类偏差，其次是不同模型的盲区互补。
  3. 再说怎么做才有收益：审查方必须拿到需求原文与验收标准而不只是 diff，否则退化成 lint；必须要求结构化输出，否则无法统计采纳率；最后一步必须由人裁决。
  4. 不值得的三种情况：任务小到审查成本高于任务本身；团队只有一家的额度，跨家意味着双份账单且多抓出的问题不值这笔钱；审查意见没人认真看，多一家只是多一层噪音。
  5. 最值的三种情况：改动影响多个调用方、需求本身有歧义、改动要上生产——抓出一个理解偏差就回本。
  6. 可预期的追问：能不能自动化？两家都有脱手模式，写与审都能脚本化，但「人裁决」这一步不能省，否则前两步就是浪费。

  How to reason about it · think before answering

  1. The crux is 'not worth it'; listing benefits without costs reads as never having sat in front of a budget.
  2. Source of value: when one model both writes and reviews, they share one reading of the requirement, so misreads slip through; a second vendor catches exactly those, plus complementary blind spots.
  3. How to make it pay: the reviewer needs the original requirement and acceptance criteria, not just the diff, or it degrades into lint; demand structured output so acceptance can be measured; a human makes the final call.
  4. Not worth it when the task is smaller than the review, when only one vendor's quota exists and the extra bill outweighs extra findings, or when nobody reads review comments carefully.
  5. Most worth it when a change touches many callers, the requirement is ambiguous, or the change ships to production; one caught misread pays for it.
  6. Expect the follow-up: can it be automated? Both vendors have headless modes so writing and reviewing can be scripted, but the human adjudication step cannot be removed.

  答题要点

  • 收益来自独立的需求理解：换一家审能抓出同家审查抓不到的理解偏差
  • 审查方要拿到需求原文与验收标准、输出结构化意见，最后由人裁决
  • 不值得：任务太小、只有一家额度、没人认真看意见
  • 最值：影响多个调用方、需求有歧义、要上生产

  Key points

  • Value comes from an independent reading of the requirement, catching misreads a same-vendor review misses
  • The reviewer needs the requirement and acceptance criteria, must output structured findings, and a human adjudicates
  • Not worth it for tiny tasks, single-vendor budgets, or teams that do not read reviews
  • Most valuable for multi-caller changes, ambiguous requirements and production deploys

7 天 MCP：把工具接进任何 Agent

D1 为什么需要一个协议：host / client / server 三角、JSON-RPC 消息与三种原语

• MCP 规范为什么规定一个客户端只连一个服务端？多路复用不是更省资源吗？Why does the MCP spec require one client per server instead of multiplexing many servers over one connection?

  国内高频海外高频进阶#architecture#security

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

  1. 这题看着在问性能，其实在问安全边界。只从连接数和资源占用切入的回答会被判为没读过设计原则那一节。
  2. 拆法：先问「共享一条通道之后，谁能看见谁」。规范写死了两条原则——服务端不应该读到整段对话，也不应该看得见别的服务端；一对一是实现这两条最直接的手段。
  3. 举一个具体后果：接一个第三方天气服务端时，一对一隔离让它只能看到你传的城市名；共享通道则可能让它读到你和内部数据库服务端之间的往来，那就是一次数据泄露。
  4. 结论：完整对话历史留在宿主，服务端只拿到这次真正需要的参数；宿主是唯一的安全边界执行者，也是唯一做跨服务端编排的地方。
  5. 代价要主动说：接 N 个服务端就有 N 条连接、N 套生命周期要管，客户端实现的复杂度大头正是在这里，而不是在发报文上。
  6. 可预期的追问：那多个服务端的工具重名怎么办？答案是聚合与消歧是宿主侧的职责，规范建议加服务端标识前缀，并且明确说不要依赖服务端自报的名字，因为它不保证唯一也未经验证。

  How to reason about it · think before answering

  1. It reads like a performance question but is really about security boundaries. Answering only in terms of connection count signals you never read the design principles.
  2. Ask who can see whom once a channel is shared. The spec fixes two principles: servers should not read the whole conversation, and should not see into other servers. One-to-one is the most direct way to enforce both.
  3. Concrete consequence: with isolation, a third-party weather server sees only the city you passed. On a shared channel it could observe traffic between you and an internal database server — a data leak.
  4. Conclusion: full history stays with the host, each server receives only the arguments this call needs, and the host is the single place where boundaries are enforced and cross-server orchestration happens.
  5. State the cost yourself: N servers means N connections and N lifecycles, and that is where most client complexity lives, not in sending messages.
  6. Likely follow-up: how do you handle tool name collisions across servers? Aggregation and disambiguation belong to the host; the spec suggests prefixing with a server identifier and explicitly warns against relying on the server's self-reported name, which is neither unique nor verified.

  答题要点

  • 一对一是安全设计而非性能设计：服务端读不到整段对话，也看不见别的服务端
  • 完整历史留在宿主，服务端只收到本次调用真正需要的参数
  • 跨服务端的聚合、消歧、授权都由宿主统一做，边界只有一处需要加固
  • 代价是连接与生命周期管理，这是客户端实现复杂度的主要来源

  Key points

  • One-to-one is a security decision, not a performance one: servers cannot read the conversation or see peers
  • Full history stays in the host; a server receives only the arguments for the current call
  • Aggregation, disambiguation, and authorization all happen in the host, so there is a single boundary to harden
  • The cost is connection and lifecycle management, which dominates client implementation complexity

D2 写第一个 MCP server：stdio 传输、官方 SDK、参数 schema、工具注解与 Inspector 调试

• 什么时候该返回 JSON-RPC 的 error，什么时候该返回 isError 为真的工具结果？给我一个判据。When should a tool return a JSON-RPC error versus a result with isError set to true? Give me a decision rule.

  国内高频海外高频进阶#error-handling#tool-design

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

  1. 这题几乎是 MCP 服务端的入门分水岭。能背出「两类错误」只算及格，区分度在于能不能给出一条可执行的判据，以及知不知道错误文案是写给谁的。
  2. 拆法：问「谁能修好这个错」。请求本身不合法——工具名不存在、参数不满足调用工具的 schema、服务端内部异常——模型再怎么改参数都没用，这类走 JSON-RPC 的 error，典型是 -32602。工具跑了但业务没成——下游 API 失败、日期格式不对、金额越界——模型换个参数就可能成功，这类走 result 里的 isError。
  3. 判据一句话：**模型换个参数有没有可能成功？有就用 isError，没有就用 error。** 注意 isError 仍然是一个成功的 JSON-RPC 响应，resultType 照样是 complete。
  4. 结论要带上文案要求：规范说客户端应当把执行错误交给模型自我纠正，所以文案是写给模型看的，要列出可选值、正确格式、边界条件。写「参数错误」等于让模型瞎猜。
  5. 生产视角的坑：最危险的不是分错类，而是**两类都不返回**——不做校验，让非法输入算出 NaN 或空结果静默返回。模型会把错误答案当正确答案用下去，且不留痕迹。靠输出 schema 校验去兜底也不算处理，因为模型拿到的是一段 schema 堆栈。
  6. 可预期的追问：客户端要不要把协议错误也喂给模型？规范说可以，但基本没用，因为模型改不了；更该做的是记日志报警，那是你的 bug 不是模型的。

  How to reason about it · think before answering

  1. This is close to a pass/fail line for MCP server work. Reciting 'two kinds of errors' is baseline; the discriminator is producing an actionable rule and knowing who the error text is written for.
  2. Ask who can fix it. If the request itself is invalid — unknown tool, arguments failing the call-tool schema, an internal server fault — no amount of parameter tweaking helps, so return a JSON-RPC error, typically -32602. If the tool ran but the business case failed — downstream API error, bad date format, amount out of range — a different argument might work, so return isError in the result.
  3. The rule in one line: could the model succeed by changing an argument? If yes use isError, if no use error. Note that isError is still a successful JSON-RPC response with resultType complete.
  4. Carry the text requirement into the conclusion: the spec says clients should hand execution errors to the model for self-correction, so the message is written for the model. List allowed values, the correct format, the boundary. 'Invalid parameter' just makes it guess.
  5. The production trap is not misclassifying but returning neither — skipping validation so an illegal input yields NaN or an empty result that is silently returned. The model then uses a wrong answer with no trace. Leaning on output-schema validation is not handling it either, since the model receives a schema stack trace.
  6. Likely follow-up: should clients feed protocol errors to the model too? The spec permits it but it rarely helps, because the model cannot fix them. Log and alert instead — that one is your bug.

  答题要点

  • 协议错误走 JSON-RPC 的 error：未知工具、请求不满足 schema、服务端内部错，模型改参数也无济于事
  • 执行错误走结果里的 isError 为真：下游失败、业务校验不过，它仍是成功的 JSON-RPC 响应
  • 判据是模型换个参数有没有可能成功，有就 isError，没有就 error
  • 执行错误的文案写给模型看，要列出可选值与正确格式；最危险的是两类都不返回、静默给出错误结果

  Key points

  • Protocol errors use the JSON-RPC error field: unknown tool, schema-invalid request, internal fault — unfixable by the model
  • Execution errors use isError true in the result and remain a successful JSON-RPC response
  • The rule: if a different argument could succeed, use isError; otherwise use error
  • Write execution-error text for the model with allowed values and formats; the worst case is neither, silently returning a wrong result

D3 resources 与 prompts：URI 模板、变更通知、进度与日志、分页，以及客户端能力

• MCP 的分页游标为什么必须是不透明的？如果客户端去解析它，会出什么问题？Why must MCP pagination cursors be opaque, and what breaks if a client parses them?

  国内高频海外高频进阶#pagination#api-design

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

  1. 这题表面考规范条文，实际考「有没有做过带分页的对外接口」。只背出「规范说不透明」拿不到分，要能说出解析之后具体哪一步会崩。
  2. 拆法：先问游标里到底装的是什么。服务端可以装偏移量、主键、时间戳、甚至一段加密状态，而且**换实现时它随时会变**。客户端一旦按某种格式解析，服务端从偏移量换成主键那天，所有客户端一起挂——这是把服务端的内部实现变成了公开契约。
  3. 第二个坑是伪造。客户端自己造一个 offset:9999 递给服务端，等于绕过了服务端对翻页范围的控制；如果游标里编了权限或过滤条件，伪造它就是一次越权。
  4. 第三个坑最阴：把空字符串当成结束。规范写死了只有 nextCursor **缺失**才代表没有下一页，空串是完全合法的游标。判错的表现是最后一页数据被静默丢掉，而且不报错，测试也很难发现。
  5. 结论：客户端对游标只允许做一个判断——nextCursor 在不在。页大小同理不得假设固定值，服务端随时可以改。非法游标服务端应当回 -32602，而不是静默返回第一页，否则客户端会陷进死循环。
  6. 可预期的追问：那服务端这边有什么坑？偏移量式游标要求列表顺序稳定，中途插入一条会让后面全部错位，所以要么先排序、要么把游标编成上一条的主键。

  How to reason about it · think before answering

  1. It looks like a spec-recitation question but really tests whether you have shipped a paginated public API. Quoting the rule earns nothing; naming the concrete failure does.
  2. Start from what a cursor holds. A server may encode an offset, a primary key, a timestamp, or encrypted state, and it may change that at any time. A client that parses one format breaks everywhere the day the server switches, because parsing turned an internal detail into a public contract.
  3. Second failure is forgery. A client that fabricates offset:9999 bypasses the server's control over paging range, and if the cursor encodes filters or permissions, forging it is a privilege escalation.
  4. Third and nastiest: treating an empty string as the end. The spec is explicit that only a missing nextCursor ends the sequence; an empty string is a valid cursor. Getting this wrong silently drops the last page with no error, which tests rarely catch.
  5. Conclusion: a client may make exactly one judgment about a cursor — whether nextCursor is present. Page size likewise must not be assumed fixed. Servers should reject invalid cursors with -32602 rather than silently returning page one, which would loop the client forever.
  6. Likely follow-up: what bites the server side? Offset cursors require a stable ordering, since an insertion shifts everything after it, so either sort first or encode the last item's key instead.

  答题要点

  • 游标内容是服务端的内部实现，解析它等于把实现细节变成公开契约，服务端换实现时客户端全挂
  • 伪造游标可以绕过服务端对翻页范围的控制，游标里若编了过滤或权限条件就是越权
  • 只有 nextCursor 缺失才代表结束，空字符串是合法游标，判错会静默丢掉最后一页
  • 页大小由服务端决定不得假设固定，非法游标服务端应回 -32602 而不是静默回第一页

  Key points

  • Cursor contents are server internals; parsing them turns an implementation detail into a public contract that breaks on any change
  • Forged cursors bypass server-side paging control, and become privilege escalation if the cursor encodes filters or permissions
  • Only a missing nextCursor ends the sequence — an empty string is valid, and getting it wrong silently drops the last page
  • Page size is server-decided and must not be assumed fixed; invalid cursors should return -32602 rather than silently resetting

D4 远程 MCP：Streamable HTTP 绑定、无状态模型与请求元数据、OAuth 2.1 授权、容器部署

• 2026-07-28 去掉了协议级会话。那一个需要跨调用保存状态的远程服务端——比如购物车、数据库事务——应该怎么设计？The 2026-07-28 revision removed protocol-level sessions. How should a remote server that needs cross-call state — a shopping cart, a database transaction — be designed?

  国内高频海外高频进阶#statelessness#api-design

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

  1. 这题在筛「有没有把无状态当成设计约束」。答「用 Mcp-Session-Id 头」的当场出局，那个头这一版已经删了；答「存在服务端内存里按连接查」的同样出局，因为客户端根本不保证复用连接。
  2. 先给结构：状态必须由客户端携带，服务端只认请求里带来的东西。落地成两种形态——一是服务端铸造的显式句柄，创建工具返回一个 id，后续调用把它当普通工具参数传回来；二是签过名的不透明状态串，比如多轮请求里的 requestState，服务端把上下文签进去，重试时原样收回。
  3. 两者的差别在于「谁存数据」：句柄背后的购物车内容还是存在服务端的库里，句柄只是主键；requestState 是把上下文本身编码进字符串，服务端零存储。前者适合长期存在的业务对象，后者适合一次交互内的续接。
  4. 结论：不管哪种，服务端内存里都不为某个客户端留东西，所以任何副本都能处理任何请求，扩容不需要粘性路由——这正是这次改动想换来的东西。
  5. 安全是必须主动补的一句：句柄是名字不是凭证。要用安全随机数生成、绑定到已认证的主体（按 user_id 加 handle 做键）、设过期时间，并且每次调用重新校验调用者身份。规范明确写了服务端不得把持有句柄当成身份认证。requestState 同理，它经客户端转手，是攻击者可控输入，必须 HMAC 或 AEAD 验签，并把主体、原请求标识、短过期签进去。
  6. 可预期的追问：多副本时 requestState 怎么办？答案是所有副本共享签名密钥即可，这仍然是无状态的——状态在客户端手里，副本只负责验签。追问二可能是「怎么保证一次性」，答案是签名只能缩小重放窗口，真要单次消费得自己在服务端加一层消费记录。

  How to reason about it · think before answering

  1. The screen is whether you treat statelessness as a design constraint. Answering 'use Mcp-Session-Id' fails immediately — that header was removed. So does 'keep it in server memory keyed by connection', since clients are not required to reuse connections.
  2. Give the structure first: state must travel with the client, and the server trusts only what arrives in the request. Two concrete shapes — a server-minted explicit handle returned by a creation tool and passed back as an ordinary tool argument, or a signed opaque blob like the requestState used by multi round-trip requests.
  3. The difference is who stores the data. A handle is just a primary key into server-side storage; a requestState encodes the context itself, so the server stores nothing. Handles suit long-lived business objects, requestState suits continuing a single interaction.
  4. Conclusion: either way the server keeps nothing per client in memory, so any replica can serve any request and scaling needs no sticky routing — which is exactly what the change was buying.
  5. Volunteer the security half: a handle is a name, not a credential. Generate it from a secure random source, bind it server-side to the authenticated principal (key storage as user id plus handle), expire it, and re-authorize on every call — the spec says possession of a handle must not be treated as authentication. requestState passes through the client, so it is attacker-controlled input and must be integrity-protected with HMAC or AEAD, carrying the principal, an originating-request identifier, and a short expiry.
  6. Likely follow-up: what about requestState across replicas? Share the signing key; it is still stateless because the state lives with the client and replicas only verify. A second follow-up is single use — signing bounds the replay window but does not guarantee one-time consumption, which needs a server-side redemption record.

  答题要点

  • 状态必须由客户端携带：服务端铸造显式句柄，作为普通工具参数在后续调用里传回
  • 一次交互内的续接可以用签名的不透明状态串，服务端零存储，多副本共享签名密钥即可
  • 句柄不是凭证：安全随机生成、绑定已认证主体、设过期，每次调用重新鉴权
  • 收益是任何副本能处理任何请求，扩容不需要粘性路由，重启后重发即可

  Key points

  • State travels with the client: the server mints an explicit handle that later calls pass back as an ordinary tool argument
  • Within one interaction, a signed opaque blob works with zero server storage; replicas just share the signing key
  • A handle is not a credential: securely random, bound to the authenticated principal, expiring, re-authorized on every call
  • The payoff is that any replica serves any request, so scaling needs no sticky routing and retries are cheap
• Streamable HTTP 要求 Mcp-Method 头必须和请求体里的 method 一致。为什么要抄一遍？不校验会有什么风险？Streamable HTTP requires the Mcp-Method header to match the method in the request body. Why mirror it at all, and what breaks if the server does not validate the match?

  国内高频海外高频进阶#transport#security

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

  1. 这题的题眼在后半句。只答「方便网关路由」是答了一半，面试官等的是「不一致会怎样」——能不能自己举出攻击场景，是区分「读过规范」和「理解规范」的地方。
  2. 先说为什么镜像：中间层不该为了做决策去解析请求体。负载均衡想按方法分流、限流器想给 tools/call 单独设阈值、可观测探针想打标签，只看头就够了，不用把几十 KB 的 body 反序列化一遍。同理还有 Mcp-Name（取自 params.name 或 params.uri）和 MCP-Protocol-Version。
  3. 再推风险：既然中间层按头决策、服务端按体执行，两个事实来源就分叉了。举个具体的：网关配了「tools/list 免鉴权、tools/call 要鉴权」，攻击者把头写成 tools/list、体写成 tools/call，鉴权就被绕过去了。同样的套路可以绕限流、绕审计、绕按参数值做的地域隔离。
  4. 结论：所以规范规定处理请求体的服务端必须校验头体一致，不一致必须回 400 加 -32020（HeaderMismatch）。这不是格式洁癖，是把「两个事实来源」重新合并成一个。
  5. 实现上有个坑值得主动说：头值只能是可见 ASCII，非 ASCII 的工具名或资源 URI 要用 =?base64?...?= 哨兵格式编码，服务端必须先解码再比对，否则自己的校验会把正常请求判成不一致。整数值应当按数值比较而不是按字符串比较。
  6. 可预期的追问：中间层自己要不要校验？规范建议按头做策略的中间层先确认 MCP-Protocol-Version 指向的是一个要求头体校验的版本，版本更老或头缺失时应当直接拒绝，而不是信任未经校验的头值。

  How to reason about it · think before answering

  1. The real question is the second half. 'It helps gateways route' is half an answer; the interviewer is waiting for a concrete attack, which separates having read the spec from having understood it.
  2. Why mirror: intermediaries should not parse the body to make decisions. A load balancer routing by method, a rate limiter capping tools/call, an observability probe tagging spans — all can read a header instead of deserializing tens of kilobytes. The same applies to Mcp-Name (from params.name or params.uri) and MCP-Protocol-Version.
  3. Then derive the risk: if intermediaries decide on the header and the server executes on the body, there are two sources of truth. Concretely, a gateway configured as 'tools/list is unauthenticated, tools/call is authenticated' is bypassed by sending the header as tools/list and the body as tools/call. The same trick evades rate limits, audit tagging, and per-parameter regional isolation.
  4. Conclusion: the spec therefore requires any server that processes the body to validate the match and reject with 400 plus -32020 (HeaderMismatch). It is not pedantry — it collapses two sources of truth back into one.
  5. Volunteer the implementation trap: header values are visible ASCII only, so non-ASCII tool names or resource URIs use the =?base64?...?= sentinel, and the server must decode before comparing or its own check will reject valid requests. Integer values should be compared numerically, not as strings.
  6. Likely follow-up: should intermediaries validate too? The spec advises that any intermediary enforcing policy from mirrored headers first confirm MCP-Protocol-Version names a revision that mandates header-body validation, and otherwise reject rather than trust unvalidated headers.

  答题要点

  • 镜像是为了让网关、限流器、探针不用解析请求体就能路由和打标签
  • 不校验就有两个事实来源：头写 tools/list、体写 tools/call 可以绕过按方法配置的鉴权与限流
  • 规范要求处理请求体的服务端必须校验一致性，不一致回 400 与 -32020
  • 非 ASCII 值用 base64 哨兵格式，服务端必须先解码再比对；整数按数值比较

  Key points

  • Mirroring lets gateways, rate limiters, and probes route and tag without parsing the body
  • Skipping validation creates two sources of truth: header tools/list with body tools/call bypasses per-method auth and limits
  • The spec requires any body-processing server to validate the match and return 400 with -32020 on mismatch
  • Non-ASCII values use the base64 sentinel, so decode before comparing; compare integers numerically

D5 写一个 MCP client：在自己的 Agent 循环里发现并调用工具、多 server 聚合与命名冲突

• 你的客户端同时连了五个 MCP 服务端，其中两个都有一个叫 search 的工具。合并成一张工具表给模型时，重名该怎么处理？为什么不能直接拿服务端名做前缀？Your client is connected to five MCP servers and two of them expose a tool called search. How do you merge them into one tool list for the model, and why can't you just prefix with the server's name?

  国内高频海外高频进阶#client#tool-naming

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

  1. 这题在筛「有没有真的聚合过多个服务端」。只答「加个前缀」能拿一半分，题眼在后半句——为什么不能用服务端自报的那个名字。
  2. 先把前提摆正：规范只保证工具名在**单个服务端内**唯一，并且明确说聚合多个服务端的客户端或代理可能遇到重名，应当实现一套消歧策略。也就是说重名不是异常情况，是设计上就允许的，消歧责任在客户端这一层，服务端管不着。
  3. 再答后半句：服务端在 serverInfo 里自报的 name **不保证跨服务端唯一**，规范明说不应当拿它来消歧。它由服务端自己填，两个不相干的服务端都叫 github 完全合法；更糟的是它是不可信输入，一个恶意服务端可以故意把自己报成别人的名字，让模型把请求发到错的地方。所以前缀必须来自客户端自己的配置——用户在配置文件里给每个服务端起的本地别名，别名重复时在启动阶段直接报错，因为那是配置错误。
  4. 接着说名字怎么拼。MCP 允许字母数字下划线连字符和点、长度建议 128 以内；模型 API 那边通常更严，比如只允许字母数字下划线连字符、最长 64。取交集，超长就截断并缀一段短哈希——要主动说出为什么加哈希：截断本身会制造新的重名，哈希是把唯一性补回来的。
  5. 结论也是最容易被追问的一条：客户端必须留一张反查表，从带前缀的名字映射回「哪个服务端 + 原来的工具名」。调用时发给服务端的必须是**原名**，服务端根本不认识带前缀的那个。绝不能靠切字符串反推，因为工具原名里本来就允许有下划线，截断过的名字更是拆不回来。
  6. 可预期的追问一：光靠名字前缀够不够？答不够，模型选工具看的是描述，所以还应当把来源写进描述里。追问二：工具列表变了怎么办？服务端支持 listChanged 时会发通知，客户端收到就重新拉取并重建反查表；同时注意频繁增删工具会打掉提示缓存，因为工具表在缓存前缀里。

  How to reason about it · think before answering

  1. The screen is whether you have actually aggregated multiple servers. 'Add a prefix' is half the answer; the real question is the second half, why the server's own name will not do.
  2. Set the premise straight: the spec guarantees tool-name uniqueness only within a single server, and explicitly says clients or proxies that aggregate multiple servers may hit collisions and should implement a disambiguation strategy. Collisions are permitted by design, and disambiguation is the client's job.
  3. Now the second half: the name a server reports in serverInfo is not guaranteed to be unique across servers, and the spec says it should not be relied upon for disambiguation. The server fills it in itself, two unrelated servers may both call themselves github, and worse, it is untrusted input, so a malicious server can impersonate another. The prefix must come from the client's own configuration, a local alias the user assigns per server, with duplicate aliases rejected at startup as a configuration error.
  4. Then the naming mechanics. MCP allows letters, digits, underscore, hyphen and dot with a suggested 128-character limit; model APIs are usually stricter, often letters, digits, underscore and hyphen with a 64-character cap. Take the intersection, and on overflow truncate plus append a short hash — say why: truncation itself creates new collisions, and the hash restores uniqueness.
  5. The conclusion, and the most likely follow-up: keep a reverse map from the prefixed name back to server plus original tool name. The call sent to the server must carry the original name, since the server has never heard of the prefixed one. Never recover it by string splitting, because original names may legitimately contain underscores and truncated names cannot be split back at all.
  6. Likely follow-ups: is the prefix enough? No, the model chooses by description, so put the source in the description too. And what about list changes? Servers declaring listChanged send a notification, on which the client refetches and rebuilds the map, keeping in mind that churning the tool list invalidates prompt caching because the tool array sits in the cached prefix.

  答题要点

  • 唯一性只在单个服务端内成立，聚合时重名是设计允许的，消歧责任在客户端
  • 前缀必须来自客户端配置的本地别名，服务端自报的 name 不保证唯一且是不可信输入
  • 名字取 MCP 与模型 API 的字符集与长度交集，超长截断并缀短哈希补回唯一性
  • 留一张反查表，调用时发原名；不能靠切字符串反推，工具原名里本来就有下划线

  Key points

  • Uniqueness holds only within one server; collisions are expected on aggregation and the client owns disambiguation
  • The prefix must come from a client-configured local alias, since the server-reported name is neither unique nor trustworthy
  • Build names from the intersection of MCP and model-API charset and length limits; truncate plus a short hash on overflow
  • Keep a reverse map and send the original name on calls; never split the prefixed string, as original names contain underscores
• 线上一个 MCP 服务端超时了。你的 Agent 循环应该怎么反应？One of your MCP servers times out in production. How should your agent loop react?

  国内高频海外高频进阶#client#reliability

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

  1. 这题看的是工程直觉：能不能把「一个依赖挂了」和「这一轮对话失败」分开。答「重试三次」是把问题往后推了一步，面试官会立刻追问重试期间用户在等什么。
  2. 先分阶段。超时发生在两个完全不同的时刻：发现阶段（server/discover 或 tools/list）和调用阶段（tools/call）。两个阶段的正确反应不一样，混着答就会露怯。
  3. 发现阶段：逐个服务端 try/catch，失败的记进一张掉线表并继续下一个。整张工具表少几个工具，但循环照常起得来。记的必须是原因而不是一个布尔值，因为事后你要能回答少了什么、为什么少。
  4. 调用阶段：把失败翻译成一条 isError 为真的工具结果喂回模型，不要抛。理由是 MCP 本来就用 isError 表达「工具执行失败但协议是成功的」，模型看得见这句话就有机会换个工具或换个参数；抛出去只会把整轮对话打断，而且用户什么解释都得不到。
  5. 接着补三件配套的事。一是**每条请求都必须有超时**，stdio 上服务端不回你就永远不回；二是**幂等性决定能不能重试**，工具注解里的 idempotentHint 是提示不是保证，写操作的重试要靠客户端自己的去重键；三是**掉线要让用户看得见**，把掉线的服务端标在界面上或写进系统提示，否则模型会表现得像那个能力从来不存在，一本正经地说查不到。
  6. 结论：一个服务端超时，最坏的后果应该是少几个工具加一条明确的说明，而不是这一轮对话失败。
  7. 可预期的追问：要不要熔断？连续失败到阈值就把这个服务端标记为不可用一段时间，避免每一轮都白等一次超时；恢复用探活或下一次会话重连。再追问会问到超时值怎么定——按工具而不是按服务端定，一个跑三十秒的分析工具和一个查缓存的工具不该共用一个阈值。

  How to reason about it · think before answering

  1. This probes engineering instinct: can you separate 'one dependency is down' from 'this turn fails'. Answering 'retry three times' just moves the problem, and the interviewer will ask what the user is staring at meanwhile.
  2. Split by phase first. A timeout happens at two very different moments: discovery (server/discover or tools/list) and invocation (tools/call). The correct reaction differs, and blurring them shows you have not built this.
  3. Discovery: wrap each server in its own try/catch, record the failure with its reason in a down list, and continue to the next server. The tool table loses a few entries but the loop still starts. Record the reason, not a boolean, because afterwards you must be able to say what is missing and why.
  4. Invocation: translate the failure into a tool result with isError true and feed it back to the model rather than throwing. MCP already uses isError for 'the tool failed but the protocol succeeded', so the model can switch tools or arguments; throwing kills the turn and leaves the user with no explanation.
  5. Then three supporting points. Every request needs a timeout, because on stdio a silent server is silent forever. Idempotency decides whether a retry is safe, and the idempotentHint annotation is a hint, not a guarantee, so writes need a client-side dedup key. And outages must be visible, surfaced in the UI or in the system prompt, or the model will behave as if the capability never existed and confidently report nothing found.
  6. Conclusion: the worst outcome of one server timing out should be a few missing tools plus an explicit note, never a failed turn.
  7. Likely follow-ups: should you add a circuit breaker? Yes, after consecutive failures mark the server unusable for a while so you stop paying a timeout every turn, with recovery by health check or reconnect on the next session. And how do you set the timeout? Per tool rather than per server, since a thirty-second analysis tool and a cache lookup should not share a threshold.

  答题要点

  • 分阶段：发现阶段逐个服务端 try/catch 记进掉线表并继续，调用阶段一律不抛
  • 调用失败翻译成 isError 为真的工具结果喂回模型，让它换工具或换参数
  • 每条请求必须设超时；能不能重试取决于幂等性，注解只是提示不是保证
  • 掉线必须对用户和模型可见，否则会变成静默降级，模型会假装那个能力不存在

  Key points

  • Split by phase: per-server try/catch during discovery with a recorded reason, and never throw during invocation
  • Translate call failures into isError tool results so the model can switch tools or arguments
  • Every request needs a timeout; retry safety depends on idempotency, and the annotation is a hint, not a guarantee
  • Outages must be visible to user and model, otherwise silent degradation makes the model deny the capability ever existed

D6 安全与治理：工具描述里的提示注入、混淆代理、最小权限、审计日志与工具白名单

• 为什么说 MCP 工具的描述是不可信输入？作为客户端作者，你会做哪些防护？Why is an MCP tool's description untrusted input, and what protections would you build as a client author?

  国内高频海外高频进阶#prompt-injection#client

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

  1. 这题在筛「有没有把模型上下文当成一条数据入口来看」。答「加个过滤器拦关键词」会被追问到崩，因为基于文本的过滤挡不住改写。
  2. 先讲清为什么不可信。工具描述由服务端作者写，会原封不动进入给模型的工具表，和你自己写的系统提示处在同一个信任层级——没有引号、没有边界、没有来源标注。它的前置条件低到离谱：攻击者不需要凭证、不需要中间人、不需要用户点任何东西，只要能影响一段会被读进上下文的文本。三条现实路径是发一个服务端等人装、拿下已被信任服务端的发布权限在小版本里改一个字段、或者服务端本身干净但描述里嵌了从数据库读出来的内容。第二条最难防，因为用户只在安装时审过一遍，清单变更通知只说变了、不说哪句话变了。
  3. 顺手把注解也归进来：规范要求客户端必须把工具注解当成不可信输入，除非来自可信服务端。readOnlyHint 为真不是安全证明，只是服务端的自我声明。
  4. 然后是防护，关键是**给出顺序**：先挡后果，再挡入口。因为所有基于文本的防御都是概率性的，没有一条能保证挡住，而后果那一层是确定性的。
  5. 挡后果的三条：破坏性工具执行前一律向人确认，且确认框展示**实际参数**（规范建议把工具输入展示给用户，正是为了挡住工具名人畜无害但参数在外发数据这一类）；界面上必须显示每一次工具调用，否则注入里那句「不要告诉用户」是真的会生效的；判据用本地策略为主、注解为辅——注解只能用来多拦一个，不能用来放行。
  6. 挡入口的三条：把描述当外部数据渲染，加来源标注与边界标记，并把边界符本身转义掉；工具返回同样处理，还要加长度上限；服务端清单变更时把描述的 diff 展示给用户复核，而不是只提示「工具列表变了」。
  7. 可预期的追问一：那能不能干脆让模型别听描述里的指令？只能降低概率，不能保证，所以它不能是唯一防线。追问二：工具返回算不算同一类问题？算，而且更严重，因为它每次都不一样、量更大；多服务端场景里官方还专门说过，一个服务端的结果对另一个服务端来说是不可信输入。

  How to reason about it · think before answering

  1. The screen is whether you treat the model's context as a data ingress. Answering 'filter for keywords' collapses under follow-up, because text filters do not survive paraphrase.
  2. Establish why it is untrusted. The description is written by the server author and lands verbatim in the tool list handed to the model, at the same trust level as your own system prompt, with no quoting, boundary, or provenance. The precondition is absurdly low: no credentials, no man in the middle, no user click, just the ability to influence text that will be read into context. Three real paths are publishing a server and waiting for installs, taking over an already-trusted server's release rights and changing one field in a patch, or a clean server whose descriptions embed database content. The second is hardest to defend, since users audit only at install time and list-changed notifications say that something changed, not which sentence.
  3. Fold annotations in: the spec requires clients to treat tool annotations as untrusted unless they come from trusted servers. readOnlyHint being true is not proof of safety, only the server's own claim.
  4. Then the defenses, and the ordering is the point: block consequences first, entry second, because every text-based defense is probabilistic while the consequence layer is deterministic.
  5. Consequences: require human confirmation before destructive tools and show the actual arguments (the spec recommends showing tool inputs to the user precisely to catch an innocuous-looking tool exfiltrating via its arguments); render every tool call in the UI, or the injected 'do not tell the user' genuinely works; and decide what is destructive from local policy first, using annotations only to catch extra cases, never to waive one.
  6. Entry: render descriptions as external data with provenance and boundary markers, escaping the markers themselves; apply the same treatment plus a length cap to tool results; and on list changes show the user a diff of the descriptions rather than a bare 'the tool list changed'.
  7. Likely follow-ups: can you just instruct the model to ignore instructions in descriptions? That lowers the probability but cannot guarantee, so it must not be the only line. And do tool results count? Yes, and worse, because they change every call and are larger; official guidance also notes that one server's results are untrusted input to another.

  答题要点

  • 描述由服务端作者写、原样进上下文，和系统提示同一个信任层级，前置条件低到不需要任何凭证
  • 注解同样不可信：规范要求客户端把注解当不可信输入，readOnlyHint 不是安全证明
  • 防护顺序是先挡后果再挡入口：破坏性操作人工确认（展示实际参数）、界面显示每次调用
  • 入口侧给描述与返回加来源标注与边界标记并转义边界符；清单变更时展示描述的 diff

  Key points

  • Descriptions are author-written, land verbatim in context at system-prompt trust level, and need no credentials to exploit
  • Annotations are equally untrusted: the spec says treat them as such, and readOnlyHint proves nothing
  • Order matters: block consequences first with human confirmation showing actual arguments, plus visible tool calls
  • At the entry, wrap descriptions and results with provenance and escaped boundary markers, and diff descriptions on list changes
• 2026-07-28 之后协议是无状态的，服务端要保存状态就得铸一个句柄让客户端带回来。这会带来什么新的攻击面？怎么防？Since the protocol is stateless, a server that needs state mints a handle for the client to carry back. What attack surface does that create, and how do you close it?

  国内高频海外高频进阶#statelessness#security

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

  1. 这题在考「换了机制之后有没有重新想过威胁模型」。上一版的会话劫持大家都熟，这一版会话没了，很多人就默认问题跟着消失了——其实只是换了个名字叫状态句柄劫持。
  2. 先描述攻击，四步很短：服务端为已认证用户铸一个句柄并放在工具结果里返回；攻击者拿到或猜到这个句柄；攻击者把它当成普通工具参数发过来；服务端没检查这个句柄属不属于调用者，于是操作了原用户的状态。
  3. 拆「拿到或猜到」这一层很关键，因为它决定了防线该架在哪。猜到，说明句柄可预测（自增 id、时间戳、短随机数）；拿到，路径就多了——它出现在工具结果里，而工具结果会进模型上下文、会进日志、可能被另一个服务端看到，也可能被一次提示注入骗着吐出来。所以「句柄不会泄漏」这个假设不能要。
  4. 防线按规范分三层答。硬性的：实现了授权的服务端**必须**校验所有入站请求，并且**绝不能**把持有句柄当成身份认证——这是整题的题眼，句柄是名字不是凭证。应当层：用安全随机数生成，避免可预测或连续的标识，并设过期。最管用的一层也是应当：**在服务端把句柄绑定到已认证的主体**，比如存储的键做成「用户 id 加句柄」，用户 id 从校验过的令牌里取而不是客户端传，别的主体拿着同一个句柄来就查不到。这样即使猜中也冒充不了别人。
  5. 然后主动把 requestState 归到同一类：它是多轮请求里由服务端签发、经客户端转手带回的不透明状态，规范要求把它当成攻击者可控输入，用 HMAC 或 AEAD 做完整性保护、验签用定长比较，并把认证主体、原请求标识、短过期一起签进去，分别挡跨用户、跨请求和超时三种重放。
  6. 结论一句话：无状态没有消灭状态，只是把状态挪到了客户端手里，于是「谁能出示它」和「谁有权用它」必须被分开对待。
  7. 可预期的追问一：签名能不能保证一次性？不能，签名只缩小重放窗口，真要单次消费得在服务端加一层消费记录。追问二：多副本部署怎么办？句柄背后的数据本来就在共享存储里，requestState 只需要各副本共享签名密钥——这仍然是无状态的，因为服务端内存里没有为某个客户端留东西。

  How to reason about it · think before answering

  1. This checks whether you re-derived the threat model after the mechanism changed. Everyone knows session hijacking from the previous revision; sessions are gone now, so many assume the problem left with them. It only got renamed to state handle hijacking.
  2. Describe the attack in four steps: the server mints a handle for an authenticated user and returns it in a tool result; the attacker obtains or guesses it; the attacker sends it back as an ordinary tool argument; the server never checks whether the handle belongs to the caller and operates on the original user's state.
  3. Unpack 'obtains or guesses', because it decides where the defense goes. Guessing means the handle is predictable, such as a sequential id, a timestamp, or too little entropy. Obtaining has many paths: the handle appears in a tool result, so it enters the model context, the logs, possibly another server's view, and it can be coaxed out by a prompt injection. The assumption that handles stay secret is not available to you.
  4. Answer the defenses in the spec's tiers. Mandatory: servers implementing authorization MUST verify all inbound requests and MUST NOT treat possession of a handle as authentication. That is the crux, a handle is a name, not a credential. Recommended: generate handles from a secure random source, avoid predictable or sequential identifiers, and expire them. The most effective recommendation is binding: key server-side storage as user id plus handle, with the user id derived from the verified token rather than supplied by the client, and reject a handle presented by any other principal, so guessing it still buys nothing.
  5. Volunteer that requestState belongs to the same family: a server-signed opaque blob carried back through the client in multi round-trip requests, which the spec requires you to treat as attacker-controlled input, protect with HMAC or AEAD, verify with a constant-time comparison, and bind to the authenticated principal, an originating-request identifier, and a short expiry, covering cross-user, cross-request, and timeout replay.
  6. One-line conclusion: statelessness did not remove state, it moved it into the client's hands, so 'who can present it' and 'who is allowed to use it' must be judged separately.
  7. Likely follow-ups: does signing guarantee single use? No, it only bounds the replay window; true one-time consumption needs a server-side redemption record. And what about replicas? The data behind a handle already lives in shared storage, and requestState only needs a shared signing key, which is still stateless because nothing per client sits in a replica's memory.

  答题要点

  • 新攻击面叫状态句柄劫持：拿到或猜到句柄的人可以操作别人的状态
  • 句柄会出现在工具结果、上下文与日志里，不能假设它不泄漏
  • 硬性要求：必须校验所有入站请求，绝不能把持有句柄当成身份认证
  • 做法：安全随机、设过期、按「主体加句柄」在服务端绑定；requestState 同理，验签并签进主体与短过期

  Key points

  • The new surface is state handle hijacking: anyone who obtains or guesses a handle can act on another user's state
  • Handles surface in tool results, model context and logs, so secrecy is not a safe assumption
  • Mandatory: verify every inbound request and never treat possession of a handle as authentication
  • Use secure randomness, expiry, and server-side binding keyed by principal plus handle; requestState needs signing bound to principal and a short expiry

D7 生产化与复盘：给工具写评估、版本化、发布到 npm 与 registry、可观测与综合项目

• 怎么评估一个 MCP 工具做得好不好？你会设计哪几类测试用例？How do you evaluate whether an MCP tool is any good, and what categories of test cases would you design?

  国内高频海外高频进阶#eval#tooling

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

  1. 这题在筛「有没有真的上线过工具」。答「写单元测试」是答错了赛道——单元测试测的是给定参数输出对不对，而 MCP 工具最先出问题的地方是模型压根没选它，参数根本到不了你的函数。
  2. 先把要评估的对象说清：评估评的是**选中率**，也就是给一句用户的话和一张工具表，模型会不会选中该选的那个。工具本身的正确性归单元测试，两层不要混。
  3. 然后给三类用例，这是本题的正面回答。正例：意图明确时选得中，比如「帮我搜一下发布流程文档」。边界：意图靠语义而不是关键词，比如「release-process 这篇讲了什么」——没有任何动词提示，只有一个像 slug 的词，最容易被误判成搜索。诱导误选（负例）：不该调的时候一个都不调，比如「谢谢，不用查文档了」「文档这个词英文怎么说」「你都能干什么」。占比我一般给四三三。
  4. 第三类是分水岭，要主动强调：只有正例的评估集会给你一个 100% 的假象，它测不出过度触发，而线上大多数投诉恰恰是过度触发——用户随口一句否定，助手转头就去干了，还带副作用。
  5. 接着讲断言，这里有个最常见的写法错误：expected 为 null 的用例被当成「随便都行」，于是负例永远绿。正确的断言两个方向都判：期待某个工具时选中它才算过，期待不调用时什么都不选才算过。我会额外拿一个「总是选同一个工具」的假选择器再跑一遍，要求负例全部失败——这验的不是选择器，是我的断言真的在起作用。
  6. 最后是工程约束：评估集要能一条命令跑完，一分钟以内，用便宜的小模型跑。跑得慢的评估集等于没有，因为改描述的人不会等。结果也不要只看总分，按三类分开看才有行动价值：正例掉了说明描述写糊了，边界掉了说明缺了区分相似工具的那句话，负例掉了说明描述写得太热情。
  7. 可预期的追问：什么时候跑？描述、schema、工具增删这三类改动都必须跑，把它挂进 CI。再追问会问到「模型换了怎么办」，答案是评估集是跨模型的资产，换模型时先跑一遍拿到基线，这也是它值得投入的原因之一。

  How to reason about it · think before answering

  1. The screen is whether you have shipped tools. 'Write unit tests' answers the wrong question: unit tests check that given arguments produce the right output, while the first thing to break on an MCP tool is the model not selecting it at all, so the arguments never reach your function.
  2. Define the target: an eval measures selection accuracy, meaning given a user utterance and a tool list, does the model pick the right tool. Correctness of the tool itself belongs to unit tests, and the two layers should not be blurred.
  3. Then the three categories, which is the direct answer. Happy path: unambiguous intent, such as 'find me the release process doc'. Edge: intent carried by semantics rather than keywords, such as 'what does release-process say', which has no verb cue and only a slug-shaped token, and is most often misread as a search. Traps: cases where nothing should be called, such as 'thanks, no need to look it up', 'how do you say document in English', and 'what can you do'. I usually weight them four, three, three.
  4. Stress that the third category is the dividing line: an eval set of only happy paths reports a comfortable hundred percent while measuring nothing about over-triggering, which is what most production complaints actually are, and over-triggering has side effects.
  5. Then the assertion, where the classic bug lives: treating an expected value of null as 'anything goes', which makes negatives permanently green. The correct assertion judges both directions. I also rerun the whole set with a deliberately wrong selector that always picks the same tool and require every negative to fail, which validates the assertion rather than the selector.
  6. Finally the engineering constraints: one command, under a minute, on a cheap small model, because a slow eval is no eval, since whoever edits a description will not wait. And report per category rather than one number: happy-path drops mean a vague description, edge drops mean the sentence distinguishing two similar tools is missing, trap drops mean the description over-claims.
  7. Likely follow-ups: when do you run it? On any change to descriptions, schemas, or the tool set, wired into CI. And what if the model changes? The eval set is a cross-model asset, so you rebaseline on a model switch, which is part of why it pays for itself.

  答题要点

  • 评估评的是选中率，不是工具正确性；后者归单元测试，两层不能混
  • 三类用例缺一不可：正例、边界、诱导误选，建议四三三
  • 断言两个方向都判：期待 null 时必须什么都不选；再用故意选错的选择器验证断言本身
  • 一条命令一分钟内跑完，按类别分开看分数，描述与 schema 改动必须触发

  Key points

  • Evals measure selection accuracy, not tool correctness; the latter is unit-tested and the layers must not blur
  • Three categories are mandatory: happy path, edge, and traps, weighted roughly four three three
  • Assert both directions: an expected null must mean nothing was called, and validate the assertion with a deliberately wrong selector
  • One command, under a minute, scored per category, and triggered by any description or schema change
• 给一个 MCP 服务端做版本管理时，什么样的改动算破坏性变更？为什么说改一句工具描述比改一个字段名更危险？When versioning an MCP server, what counts as a breaking change, and why is editing a tool description more dangerous than renaming a field?

  国内高频海外高频进阶#versioning#tooling

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

  1. 这题的前半句是常识题，后半句才是筛子。能把「描述也是接口」说明白的人，基本都真的运维过工具。
  2. 先答常规的四类，官方在讲扩展演进时给过定义，直接可用：删除或重命名字段、改字段类型、改变现有行为的语义、新增必填字段。这四类的共同点是会让已有实现直接失败或者行为不正确。
  3. 然后补 MCP 特有的第五类：**改工具描述**。理由是描述是模型选工具的唯一依据，改一句描述就是一次行为变更。举个具体的：某个服务端把描述从「在内部文档库里按关键词搜索」精简成「搜索文档」，代码一行没动，两周后用户反馈助手变笨了——模型不再选它了。
  4. 接着讲为什么它**更**危险，这是题眼：改字段名会让调用方立刻报错，错误是响亮的，五分钟内就有人来找你；改描述不报任何错，单元测试全绿、服务端零错误、日志干净，它只会让选中率悄悄掉几个点，最后以「最近变笨了」这种没法定位的形式浮上来。响亮的错误比安静的退化好处理得多，所以描述改动反而更需要闸门。
  5. 闸门是什么要说出来：一份三类齐全的评估集，描述改了必须跑一遍，选中率掉了就别合。这也是评估集要能一条命令快速跑完的原因。
  6. 顺带把兼容技巧补上：加字段要加成可选的，因为老客户端不会传新参数；要改语义就换个工具名而不是原地改，旧的标弃用、描述里写明替代品、留一段时间再删，因为你不知道多少人的提示词里写死了那个名字。
  7. 可预期的追问一：协议自己怎么做版本？MCP 用 YYYY-MM-DD，标的是最后一次破坏性变更的日期，向后兼容的改动不递增版本；弃用的特性至少保留十二个月才可能移除。追问二：发到注册表之后怎么改？改不了——版本号唯一且发布后元数据不可变，打错字只能往上加一个版本，而且范围形式的版本号会被直接拒收。

  How to reason about it · think before answering

  1. The first half is common knowledge; the second half is the filter. Anyone who can explain that the description is part of the interface has actually operated tools in production.
  2. Give the four conventional categories, which the official guidance on extension evolution defines directly: removing or renaming fields, changing field types, altering the semantics of existing behavior, and adding new required fields. All four make existing implementations fail or behave incorrectly.
  3. Then add the MCP-specific fifth: editing a tool description. The description is the model's only basis for selecting a tool, so changing a sentence is a behavior change. Concretely, a server shortened 'search the internal doc library by keyword' to 'search documents', shipped no code changes, and two weeks later users reported the assistant had gotten dumber, because the model stopped choosing it.
  4. Now the crux, why it is more dangerous. Renaming a field makes callers fail loudly and someone finds you within five minutes. Editing a description raises nothing: unit tests pass, the server reports zero errors, logs are clean, and selection accuracy quietly drops a few points, surfacing weeks later as an undiagnosable 'it got worse'. Loud failures are far easier than silent degradation, so description changes need the stronger gate.
  5. Name the gate: an eval set with all three case categories, run on every description change, blocking the merge when selection accuracy drops. That is also why the eval must run fast from one command.
  6. Add the compatibility techniques: new fields must be optional, since old clients will not send them; to change semantics, introduce a new tool name rather than mutating in place, mark the old one deprecated with the replacement named in its description, and remove it only after a grace period, because you cannot know how many prompts hardcode that name.
  7. Likely follow-ups: how does the protocol version itself? MCP uses YYYY-MM-DD marking the last breaking change, backwards-compatible updates do not bump it, and deprecated features stay for at least twelve months before removal. And can you fix metadata after publishing to the registry? No: versions are unique and immutable once published, a typo costs a new version, and range-looking version strings are rejected outright.

  答题要点

  • 常规四类：删除或重命名字段、改字段类型、改变现有行为语义、新增必填字段
  • 第五类是 MCP 特有的：改工具描述，因为描述是模型选工具的唯一依据
  • 它更危险是因为不报错：测试全绿、日志干净，只有选中率悄悄下滑，几周后才浮上来
  • 闸门是评估集；加字段要可选，改语义要换新工具名并给旧的一段弃用期

  Key points

  • The four usual categories: removing or renaming fields, changing types, altering semantics, adding required fields
  • The MCP-specific fifth is editing a tool description, since the description is the model's only selection signal
  • It is more dangerous because nothing fails: tests pass and logs are clean while selection accuracy silently drops
  • The gate is the eval set; new fields must be optional, and semantic changes need a new tool name plus a deprecation window
• 线上有人反馈某个 MCP 工具「总是调不对」。你按什么顺序排查？A user reports that one of your MCP tools is 'always getting it wrong' in production. In what order do you investigate?

  国内高频海外高频进阶#observability#debugging

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

  1. 这题考的是排查的**顺序**，不是知识点的多少。上来就贴日志和堆栈的人会被追问「你怎么知道问题在服务端」。
  2. 第零步是把「调不对」翻译成三种互斥的现象，这一步不做后面全是猜：一是**没被调**（模型压根没选这个工具）；二是**调了但参数错**；三是**调了参数也对，但结果不对**。问一句「那次它是没动，还是动了但做错了」，或者直接去日志里看有没有这条调用记录，就能分开。
  3. 对应三条不同的路。没被调，问题在**描述**：去跑评估集，看正例还是边界掉了；正例掉说明描述写糊，边界掉说明缺了区分相似工具的那句话。参数错，问题在 **schema**：看字段名是不是有歧义、描述里有没有写清格式、必填项是不是标对了；这类问题的信号是错误率里工具执行错误持续偏高——那通常不是模型笨，是 schema 没说清。结果不对才是代码问题，这时候才轮到单元测试和日志。
  4. 指标层面的顺序也说一下：**先看错误率，再看选中率**。错误率正常但用户说不好用，八成是选不中；错误率飙了才去看代码和上游。耗时看 P95 不看平均值，远程服务端上一个工具从 200 毫秒退化到 8 秒，平均值可能只动一点点。
  5. 还有两条容易被忽略但很常见的原因，要主动提。一是**聚合冲突**：客户端连了多个服务端，两个工具重名，模型选中的是另一个服务端的那个——这时候「你的工具」根本没被调，查你的服务端永远查不出来。二是**版本或缓存**：列表结果带 ttlMs 缓存提示，客户端可能拿着旧的工具清单；工具清单变了要靠 listChanged 通知才会重新拉。
  6. 结论：这条链上有四个环节——描述、schema、聚合与缓存、实现。**按模型看得见的顺序从前往后查**，因为越靠前的环节越不产生错误日志，也就越容易被跳过。
  7. 可预期的追问：怎么留证据？每次调用记一条结构化日志，字段里要有工具名、参数摘要与字段名、是否 isError、耗时、以及这次调用有没有经过人工确认；最后那一栏是事后区分「用户授意」和「模型自作主张」的唯一依据。

  How to reason about it · think before answering

  1. This tests ordering, not breadth. Anyone who opens with logs and stack traces gets asked how they know the problem is server-side at all.
  2. Step zero is translating 'getting it wrong' into three mutually exclusive symptoms, without which everything after is guesswork: it was never called, it was called with wrong arguments, or it was called correctly and returned the wrong thing. Asking whether it did nothing or did the wrong thing, or simply checking whether a call was logged, separates them.
  3. Each symptom has its own path. Never called means the description is at fault: run the eval set and see whether happy paths or edges dropped, since happy-path drops mean a vague description and edge drops mean the sentence distinguishing similar tools is missing. Wrong arguments means the schema is at fault: ambiguous field names, unstated formats, wrong required markers. The signal is a persistently high tool-execution error rate, which usually means the schema is unclear rather than the model being dumb. Only a wrong result is a code problem, and only then do unit tests and logs matter.
  4. State the metric ordering too: error rate first, selection accuracy second. A normal error rate with unhappy users almost always means the tool is not being chosen; a spiking error rate sends you to the code and upstream. Watch P95, not the mean, because a remote tool degrading from 200 milliseconds to 8 seconds barely moves an average.
  5. Volunteer two commonly missed causes. Aggregation collisions: the client is connected to several servers, two tools share a name, and the model picked the other one, so your server was never called and investigating it will never find anything. And version or caching: list results carry ttlMs cache hints, so the client may hold a stale tool list, and refresh depends on a listChanged notification.
  6. Conclusion: the chain has four links, description, schema, aggregation and caching, and implementation. Walk it in the order the model sees it, because the earliest links produce no error logs and are therefore the ones people skip.
  7. Likely follow-up: how do you keep evidence? Emit one structured log per call with tool name, an argument digest plus field names, the isError flag, duration, and whether a human confirmed the call, that last column being the only way to distinguish user intent from the model acting on its own.

  答题要点

  • 先把「调不对」分成没被调、参数错、结果错三种互斥现象，再决定查哪里
  • 没被调查描述并跑评估集；参数错查 schema；结果错才轮到代码与日志
  • 指标顺序是先错误率再选中率；耗时看 P95 不看平均值
  • 别漏掉聚合重名（选中的是别的服务端的同名工具）和工具清单缓存这两类原因

  Key points

  • First split 'getting it wrong' into never called, wrong arguments, or wrong result; the split decides where to look
  • Never called points at the description and the eval set; wrong arguments at the schema; only a wrong result at the code
  • Check error rate before selection accuracy, and read P95 rather than the mean
  • Do not miss aggregation collisions, where another server's same-named tool was chosen, or a stale cached tool list

7 天 Agent Skills：把经验做成可复用能力

D1 Skills 是什么：SKILL.md 规范、目录结构与三阶段渐进式加载

• 渐进式加载的三个阶段分别加载什么？为什么不能一次性把所有 skill 全加载进去？What does each of the three progressive disclosure stages load, and why not just load every skill up front?

  国内高频海外高频进阶#agent-skills#progressive-disclosure

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

  1. 这题在考你对机制的记忆精度，同时也在考工程感。只背出三个阶段的名字拿不到分，要说出每一阶段加载的**是哪些字段、哪些文件**。
  2. 拆法很简单，按加载的粒度从粗到细数：阶段一只加载 name 与 description，量级是每个 skill 五十到一百个 token；阶段二加载整份 SKILL.md 正文，建议不超过五千 token 与五百行；阶段三按文件粒度加载脚本、引用与资源。
  3. 回答「为什么不全加载」时给一个具体的数：二十个 skill 各三千 token 的正文加上引用文件，全量是十几万 token，超过很多模型的窗口，而且每一轮都要重发。渐进式加载后总量落在一万上下。
  4. 补一条更本质的理由：省下来的不只是钱，是窗口位置。腾出来的空间要留给真正在做的这件事的代码和数据，这就是上下文工程的核心取舍。
  5. 可预期的追问是「阶段三怎么触发」。答案是正文里必须写明读取条件——写「细节见 references 目录」等于没写，写「接口返回非 200 时读 references 里的错误码文件」才真正把时机交给了模型。

  How to reason about it · think before answering

  1. This tests both recall precision and engineering sense. Naming the three stages is not enough; say which fields and which files each stage pulls in.
  2. Order them by granularity: stage one loads only name and description, roughly fifty to a hundred tokens per skill; stage two loads the full SKILL.md body, recommended under five thousand tokens and five hundred lines; stage three loads individual scripts, references and assets.
  3. Answer the why with a number: twenty skills at three thousand tokens of body plus reference files is well over a hundred thousand tokens, past many context windows, and resent every turn. Progressive loading lands around ten thousand.
  4. Add the deeper reason: what you save is window space, not just money, and that space belongs to the actual task.
  5. Expected follow-up: how does stage three fire? The body must state the loading condition. See the references folder is useless; read the error-code reference when the API returns a non-200 hands the timing to the model.

  答题要点

  • 阶段一发现：只加载 name 与 description，每个 skill 约五十到一百 token。
  • 阶段二激活：读入完整 SKILL.md 正文，建议不超过五千 token 与五百行。
  • 阶段三执行：按需读取 scripts、references、assets 里的单个文件，不是整目录倒进来。
  • 全量加载会撑爆窗口且每轮重发，渐进式加载能把量级压到十分之一左右。
  • 阶段三能不能被触发，取决于正文有没有写清「什么条件下读哪个文件」。

  Key points

  • Discovery: only name and description, about fifty to a hundred tokens per skill.
  • Activation: the full SKILL.md body, ideally under five thousand tokens and five hundred lines.
  • Execution: individual files from scripts, references or assets, loaded one at a time on demand.
  • Loading everything up front blows the window and is resent every turn; progressive loading cuts it to roughly a tenth.
  • Stage three only fires if the body spells out which file to read under which condition.
• SKILL.md 的 name 与 description 有哪些硬性约束？规范为什么要把 name 卡得这么死？What hard constraints does the spec put on the name and description fields, and why is name so tightly constrained?

  国内高频海外高频进阶#agent-skills#spec

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

  1. 这题看着像背规范，其实题眼在后半句「为什么」。能把约束背全只算及格，能说出这些约束是为了解决什么工程问题才是加分项。
  2. 先把 name 的五条约束数完：长度一到六十四个字符、只能用小写字母数字和连字符、不能以连字符开头或结尾、不能有连续两个连字符、必须与父目录名一致。
  3. 再给 description 的两条：长度一到一千零二十四个字符；内容上要同时说清做什么和什么时候用，而不是只说做什么。
  4. 解释「为什么卡这么死」：name 是这个 skill 在整个生态里的唯一标识，要拼进目录名、命名空间、斜杠命令，还要在两个 skill 撞名时用来判优先级。任何一处大小写或分隔符不一致，都会变成一个很难查的「装了却调不到」。
  5. 补一个真实的坑：很多客户端在实现时故意放宽了「name 等于目录名」这条，不一致只打警告仍然加载。于是你本地一切正常，换个严格实现就整个消失。
  6. 可预期的追问是「description 写到一千个字符会怎样」。答案是它每次会话都要付一遍，二十个 skill 都写满上限，光目录就要八千 token，这时候该做的是把描述写短而不是删 skill。

  How to reason about it · think before answering

  1. It looks like spec recall, but the real question is the why. Listing the constraints is a pass; explaining which engineering problem they prevent is the differentiator.
  2. Name has five constraints: one to sixty-four characters, lowercase letters digits and hyphens only, no leading or trailing hyphen, no consecutive hyphens, and it must match the parent directory name.
  3. Description has two: one to one thousand twenty-four characters, and it must convey both what the skill does and when to use it.
  4. The reason name is strict: it is the skill's identity across the ecosystem, feeding directory lookup, namespacing, slash-command invocation and collision precedence. One casing mismatch becomes an installed but uncallable skill.
  5. Mention the real-world wrinkle: many clients deliberately relax the name-matches-directory rule and only warn, so a skill can work locally and vanish under a stricter implementation.
  6. Expected follow-up: what if the description runs to a thousand characters? You pay for it every session. Twenty maxed-out descriptions cost eight thousand tokens of catalog, so shorten the text rather than dropping skills.

  答题要点

  • name：一到六十四字符、小写字母数字与连字符、首尾不能是连字符、不能有连续连字符、必须等于父目录名。
  • description：一到一千零二十四字符，必须同时说清做什么与什么时候用。
  • name 卡死是因为它是唯一标识，要参与目录查找、命名空间、命令调用与撞名优先级。
  • 很多客户端对 name 做宽松校验，本地能跑不代表换个客户端也能跑。
  • description 是每次会话都要付的固定开销，能短则短。

  Key points

  • Name: one to sixty-four characters, lowercase alphanumerics and hyphens, no leading or trailing hyphen, no double hyphens, must equal the directory name.
  • Description: one to one thousand twenty-four characters, stating both what it does and when to use it.
  • Name is strict because it is the skill's identity for lookup, namespacing, invocation and collision precedence.
  • Many clients validate name leniently, so working locally does not guarantee working elsewhere.
  • The description is a fixed per-session cost, so keep it as short as it can be while still triggering.

D2 写第一个 skill：description 的触发词怎么写、结构怎么分层、怎么装进客户端

• skill 的 description 写得太泛会怎样？太窄又会怎样？你怎么找到中间那个点？What goes wrong when a skill description is too broad, and what goes wrong when it is too narrow? How do you find the middle?

  国内高频海外高频进阶#agent-skills#skill-description

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

  1. 这题的题眼在「代价」两个字。只说「太泛会误触发、太窄会不触发」是把题目复述了一遍，面试官等的是后面那句：误触发到底损失了什么。
  2. 先说太泛的代价，而且要说满三层：这个 skill 的正文白占了上下文位置；它的指令会干扰当前任务；更麻烦的是模型一旦选定了一个 skill，就更不容易再去选真正对的那个。**一个太泛的 skill 会拖累整个技能库**，这一句是拿分点。
  3. 再说太窄的代价：它只在用户按你预想的说法提问时才触发，而真实用户几乎不会那样说话。太窄的 skill 通常不是不好用，是根本没被用过，所以你连它不好用都不知道。
  4. 找中间点的方法要给成一套动作而不是感觉：写覆盖多种说法而不是多个关键词，末尾补一句边界排除相邻能力，然后用一组正例加近似负例把触发率量出来，按结果改描述。
  5. 补一个容易被忽略的事实：有些任务简单到模型觉得自己就能干，这时候描述写得再匹配也不会触发。判断描述好不好之前，先确认这个任务值不值得一个 skill。
  6. 可预期的追问是「改描述时怎么避免过拟合」。答案是不要把失败查询的原话抄进描述，要归纳出它代表的那一类说法，并留一部分查询不参与优化、只用来验证。

  How to reason about it · think before answering

  1. The hinge word is cost. Saying too broad misfires and too narrow never fires just restates the question; the interviewer wants to know what a misfire actually costs.
  2. Give three layers of cost for over-broad descriptions: the body wastes context, its instructions interfere with the current task, and once the model has committed to one skill it is less likely to reach for the right one. One over-broad skill degrades the whole library.
  3. For too narrow: it only fires when the user phrases things exactly as you imagined, and real users never do. Such a skill is usually not bad, it is simply never exercised, so you never learn that it is bad.
  4. Give the middle as a procedure, not a feeling: cover phrasings rather than keywords, add a boundary clause that excludes adjacent capabilities, then measure trigger rate against positives and near-miss negatives and revise from the data.
  5. Add the often-missed fact that agents typically only consult skills for tasks beyond what they handle alone, so a trivially easy task will not trigger no matter how well the description matches.
  6. Expected follow-up: how do you avoid overfitting when revising? Never paste the failing query verbatim; generalize to the category it represents, and hold out a validation split.

  答题要点

  • 太泛的三层代价：占上下文、干扰当前任务、挤掉真正该用的那个 skill。
  • 太窄的代价是根本没被触发过，问题被掩盖，你连它好不好用都测不出来。
  • 写法上覆盖「多种说法」而不是「多个关键词」，末尾补一句边界排除相邻能力。
  • 用正例加近似负例量出触发率，按数据改描述，不靠手感。
  • 任务本身太简单时不会触发任何 skill，这不是描述的问题。

  Key points

  • Three costs of over-broad: wasted context, interference with the current task, and crowding out the correct skill.
  • Over-narrow means it never fires, which hides the problem rather than surfacing it.
  • Cover phrasings rather than keywords, and add a closing boundary clause that excludes adjacent capabilities.
  • Measure trigger rate with positives and near-miss negatives, then revise from the data.
  • A task simple enough for the model alone will not trigger any skill; that is not a description problem.
• skill 的正文应该写什么、不应该写什么？为什么「坑」那一段必须留在 SKILL.md 里而不是挪到引用文件？What belongs in a skill body and what does not, and why must the gotchas stay in SKILL.md rather than move to a reference file?

  国内高频海外高频进阶#agent-skills#skill-authoring

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

  1. 这题考的是你有没有真写过 skill。没写过的人会答「写清楚步骤」，写过的人会先给一条判据。
  2. 判据只有一句：**不写这一条，模型会不会做错？** 不会就是废话，删掉。解释什么是 PDF、什么是数据库迁移，模型本来就知道，写进去纯粹在稀释注意力。
  3. 该写的三类是：项目特有的约定、非显然的边界情况、以及指定用哪个工具或接口。这三类的共同点是模型的通用知识里没有。
  4. 输出格式那一段要单独强调：给模板比用文字描述可靠，因为模型对具体结构做模式匹配的能力远强于读一段散文式的格式说明。
  5. 「坑」为什么不能挪走，答案是一个先后顺序问题：**模型得先知道有坑，才会去查坑**。放进引用文件就要求它在还没撞上的时候预判自己会撞上，这个前提不成立。引用文件适合放「我知道会用到，只是现在还不需要」的材料。
  6. 可预期的追问是「那什么该挪进 references」。答案是长、且用不用得上有明确判断条件的材料，并且正文里必须写出那个条件，比如「接口返回非 200 时读错误码文件」。

  How to reason about it · think before answering

  1. This separates people who have written skills from people who have read about them. The untested answer is write clear steps; the tested answer starts with a test.
  2. The test is one sentence: would the model get this wrong without this line? If not, cut it. Explaining what a PDF is only dilutes attention.
  3. Three things belong: project-specific conventions, non-obvious edge cases, and which tool or API to use. All three are absent from the model's general knowledge.
  4. Call out output format specifically: a concrete template beats prose, because models pattern-match against structures far better than they parse a described format.
  5. Gotchas cannot move because of ordering: the model must know a trap exists before it will look it up. Putting them in a reference file assumes it can predict a collision it has not hit yet.
  6. Expected follow-up: what does belong in references? Long material whose need has a clear trigger condition, and the body must state that condition, such as read the error-code file when the API returns a non-200.

  答题要点

  • 判据是「不写这一条模型会不会做错」，不会就删。
  • 该写：项目特有约定、非显然的边界、指定的工具与接口。
  • 输出格式给模板，不要用文字描述格式。
  • 坑必须留在正文，因为模型要先知道有坑才会去查坑。
  • 引用文件放长材料，且正文必须写出「什么条件下读它」。

  Key points

  • The test: would the model get this wrong without the line? If not, delete it.
  • Include project conventions, non-obvious edge cases, and the specific tool or API to use.
  • Give a template for output format instead of describing it in prose.
  • Gotchas stay in the body because the model must know a trap exists before looking it up.
  • References hold long material, and the body must state the condition for loading each one.

D3 设计方法：从重复任务提炼、检查清单式与参考手册式、四种反模式与触发测试

• 怎么测一个 skill 的 description 好不好？自己试几句话够吗？How do you evaluate whether a skill description is good? Is trying a few prompts yourself enough?

  国内高频海外高频进阶#agent-skills#evaluation

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

  1. 题眼在后半句。答「自己试几句就行」直接出局，但只答「要写测试集」也不够——面试官要看你知不知道这个测试集该怎么设计。
  2. 先说为什么抽查不够：一个 skill 时够用，装到第十个就不行了，因为你既记不住十个描述之间会不会互相抢，也没法在改完一句话后判断是改好了还是改坏了。
  3. 然后给三件东西。第一是带标注的查询集，约 20 条，正负各半。正例要在措辞、显式程度、详略、复杂度四个维度上铺开；**最有价值的正例是那些确实该用但字面看不出来的**，字面已经念了一遍功能的查询任何描述都能命中，测不出区别。
  4. 负例是设计的重点：毫无重叠的句子测不出任何东西，真正有用的是近似负例——共享关键词或概念但目标动词不同。对 CSV 分析 skill，「改 Excel 预算表的公式」和「把 CSV 每行写进数据库」都是好负例。
  5. 第二是重复跑取触发率：模型是不确定的，每条跑三次算命中比例，阈值取 0.5。第三是训练验证拆分，六比四，验证集全程不看。
  6. 可预期的追问是「怎么判断一条查询触发了没有」。答案是把所有 skill 的名字与描述拼成目录，连同这句话交给模型问它该用哪一个——这正是客户端在发现阶段做的事，只是单独拎出来跑。

  How to reason about it · think before answering

  1. The hinge is the second half. Saying a few prompts is enough fails immediately, but saying write a test set is not enough either; the interviewer wants the design.
  2. Explain why spot checks fail: fine with one skill, useless at ten, because you cannot hold ten descriptions in your head nor tell whether an edit helped or hurt.
  3. Then give three ingredients. First, a labeled query set of about twenty, balanced positive and negative. Vary positives along phrasing, explicitness, detail and complexity; the most valuable positives are the ones where the skill applies but the wording does not say so.
  4. Negatives are where the design effort goes: unrelated sentences test nothing. Near-misses that share keywords but need something else are what matters, such as editing Excel formulas or loading CSV rows into a database for a CSV-analysis skill.
  5. Second, repeat runs for a trigger rate, since model behavior is nondeterministic: three runs per query with a 0.5 threshold. Third, a roughly sixty-forty train and validation split with the validation set untouched.
  6. Expected follow-up: how do you decide whether a query triggered? Build the catalog of names and descriptions, hand it plus the query to the model and ask which skill applies. That is exactly what a client does at discovery, run standalone.

  答题要点

  • 抽查在一个 skill 时够用，多个 skill 互相干扰时完全不够。
  • 约 20 条带标注查询，正负各半，正例在措辞、显式程度、详略、复杂度四维上铺开。
  • 负例必须是近似负例：共享关键词但目标动词不同，无关句子测不出东西。
  • 每条跑三次取触发率，阈值 0.5，因为模型行为不确定。
  • 训练验证六四拆分，训练集指导改写，验证集只用来选版本。

  Key points

  • Spot checks work for one skill and break down once several skills compete.
  • About twenty labeled queries, balanced, with positives varied by phrasing, explicitness, detail and complexity.
  • Negatives must be near-misses that share keywords but need a different action.
  • Three runs per query for a trigger rate with a 0.5 threshold, because behavior is nondeterministic.
  • Split roughly sixty-forty; train guides revision, validation picks the winning version.

D4 带脚本的 skill：可执行附件、依赖与沙箱、跨平台，以及文档处理类 skill 的拆解

• 给 Agent 用的命令行脚本，接口设计上和给人用的有什么不同？How does designing a command-line script for an agent differ from designing one for a human?

  国内高频海外高频进阶#agent-skills#scripts#cli-design

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

  1. 题眼是「不同」。能列出五条通用 CLI 最佳实践的人很多，能说清哪几条是因为「使用者是模型」才成立的人少。
  2. 先给根本差异：人会读文档、会试错、会凭经验猜；Agent 只能读你打印的那几行字然后决定下一步。**它的全部信息就是你的输出**。
  3. 由此推出五条。绝对不能交互，这是硬要求不是最佳实践，Agent 在非交互终端里回答不了提示，会一直挂到超时。
  4. 帮助信息就是接口文档，但要短——这段输出原样进上下文，跟别的东西抢位置，这是给人用的 CLI 完全不必考虑的约束。
  5. 错误信息决定它下一次会不会做对：写清哪一项错了、期望什么、实际是什么、可选值有哪些。**错误信息本质上是给模型的提示词**，这一句是拿分点。
  6. 剩下两条：输出结构化并把数据与诊断分流到标准输出与标准错误；输出体量要可控，因为很多 Agent 环境会静默截断超长输出。再补幂等、有意义的退出码、危险操作给预演开关。
  7. 可预期的追问是「怎么验证接口设计得好」。答案是把帮助输出和一条错误信息单独发给一个没看过这个 skill 的人，他能照着敲对改对，模型大概率也能。

  How to reason about it · think before answering

  1. The hinge is the difference. Many can list CLI best practices; few can say which ones exist specifically because the caller is a model.
  2. State the root difference: humans read docs, experiment and guess from experience; an agent has only the lines you printed before deciding the next move.
  3. From that: never prompt interactively. This is a hard requirement, not a nicety, because agents run in non-interactive shells and will hang until timeout.
  4. Help output is the interface documentation, but it must be short, since it enters the context window and competes with everything else. A human CLI never faces this constraint.
  5. Error messages decide the next attempt: say what failed, what was expected, what was received, and which values are allowed. Error messages are effectively prompts for the model.
  6. Then: structured output with data on stdout and diagnostics on stderr, and bounded output size because many harnesses truncate silently. Add idempotency, meaningful exit codes, and a dry-run flag for destructive work.
  7. Expected follow-up: how do you validate the design? Hand the help text and one error message to someone who has never seen the skill; if they can act on it, the model probably can too.

  答题要点

  • 根本差异：Agent 的全部信息就是你打印的输出，它不会读文档也不会试错。
  • 绝不能交互，否则在非交互终端里会挂到超时。
  • 帮助信息就是接口文档，但必须短，因为它原样占用上下文。
  • 错误信息要写清哪项错、期望什么、实际什么、可选值有哪些，它本质是给模型的提示词。
  • 结构化输出并分流标准输出与标准错误，输出体量要可控，危险操作给预演开关。

  Key points

  • The agent's only information is what you printed; it does not read docs or experiment.
  • Never prompt interactively; a non-interactive shell will hang until timeout.
  • Help text is the interface documentation and must be short because it consumes context.
  • Error messages must state the field, the expectation, the actual value and the allowed set; they are prompts for the model.
  • Emit structured data on stdout and diagnostics on stderr, bound output size, and offer a dry-run for destructive operations.

D5 手写一个 skill 运行时：扫描、frontmatter 解析、注入系统提示、按需读取正文

• 如果让你自己给一个 Agent 实现 skill 支持，发现阶段和激活阶段各要做什么？为什么要分成两步？If you implemented skill support in your own agent, what happens in the discovery stage versus the activation stage, and why split them?

  国内高频海外高频进阶#agent-skills#runtime#progressive-disclosure

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

  1. 这题在考你有没有把渐进式加载当成一个可实现的机制，而不是一句口号。只复述「发现、激活、执行」三个词是不够的，要落到每一步读了什么、写进了哪里。
  2. 发现：扫描约定目录，把所有含 SKILL.md 的文件夹找出来，解析出名字与描述，拼成一份清单注入系统提示。**这一步正文一个字都不进来**，清单里只有名字、描述、位置三样。
  3. 激活：模型判断当前任务命中了某条描述，才去读那一份完整的 SKILL.md，把正文放进上下文，同时告诉它技能目录在哪、附带哪些资源文件。
  4. 分两步的理由是成本结构不对称，这是本题的核心句：**披露的成本每一轮都要付，激活的成本只付一次。** 系统提示随每次请求重发，清单每多一个字都要乘会话轮数；正文只在被激活的那一轮进上下文，之后作为历史消息留着。
  5. 由这条不对称性可以顺手解释规范里的硬约束：为什么描述有长度上限而正文没有，为什么描述必须写触发条件而不是使用说明——描述是每轮都在花钱的那一段。
  6. 可预期的追问是「位置这一项能不能省」。不能：模型要靠它知道去读哪个文件，而且它的父目录是正文里所有相对路径的解析基准。

  How to reason about it · think before answering

  1. This tests whether progressive disclosure is a mechanism you could build, not a slogan. Repeating the three stage names is not enough; say what each stage reads and where it writes.
  2. Discovery: scan the conventional directories, find every folder containing SKILL.md, parse out name and description, and assemble a catalog injected into the system prompt. No body text enters here; each entry carries only name, description and location.
  3. Activation: once the model judges that a task matches a description, read that full SKILL.md into context, along with the skill directory path and a list of bundled resource files.
  4. The reason for the split is an asymmetry in cost: disclosure is paid every turn, activation is paid once. The system prompt is resent with every request, so each extra character in the catalog is multiplied by the number of turns.
  5. That asymmetry also explains the spec's hard limits: descriptions are capped and bodies are not, and descriptions must state trigger conditions rather than usage instructions, because the description is the part that keeps costing money.
  6. Expected follow-up: can the location field be dropped? No. The model needs it to know which file to read, and its parent directory is the base for every relative path in the body.

  答题要点

  • 发现阶段扫描目录、解析名字与描述、拼成清单注入系统提示，正文不进来。
  • 激活阶段才读完整 SKILL.md，并附上技能目录与资源文件名清单。
  • 分两步的根据是披露每轮付费、激活只付一次这条不对称性。
  • 这条不对称性解释了描述为什么有长度上限、为什么要写触发条件而不是使用说明。
  • 清单里位置字段不能省，它既是读取目标也是相对路径的解析基准。

  Key points

  • Discovery scans directories, parses name and description, and injects a catalog into the system prompt with no body text.
  • Activation reads the full SKILL.md and adds the skill directory plus a list of bundled resource filenames.
  • The split exists because disclosure is paid every turn while activation is paid once.
  • That asymmetry explains why descriptions are length-capped and must state triggers rather than usage.
  • The location field is required: it is both the read target and the base for relative paths.
• 你的运行时解析到一份不合规范的 SKILL.md，是拒绝加载还是降级加载？另外，两个作用域里有同名 skill 时你怎么处理？When your runtime parses a SKILL.md that violates the spec, do you refuse to load it or degrade gracefully? And how do you handle a name collision across scopes?

  国内高频海外高频进阶#agent-skills#runtime#error-handling

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

  1. 两个小问共用一个立场：**运行时是给人干活的，不是校验器。** 先把这句说出来，后面两半都好答。
  2. 宽松加载这一半要给出可判定的边界，不能只说「尽量宽松」。**唯一的硬性淘汰是缺 description**——少了它这个 skill 在发现阶段没有触发面，永远不会被选中，留在清单里只是白占 token。
  3. 其余一律只告警仍然加载：名字与目录名不一致、名字用了大写或下划线、描述超过上限。它们影响质量，不影响能不能用。
  4. 举一个最常见的畸形做证据：YAML 值里没加引号的冒号会让正规解析器判整行非法，进而拒绝整个文件。正确的兜底顺序是先用完整 YAML 解析，失败了再退回按行取值，只抠出认识的那几个标量字段。
  5. 同名冲突这一半，方向不是重点，**处理方式才是**。跨客户端通行约定是项目级压过用户级，但 Claude Code 的顺序是企业级、个人级、项目级由高到低，两种都合理，关键是固定一种并保持一致。
  6. 最糟的做法是静默丢弃：用户改了项目里那份，行为一点没变，他会去怀疑缓存和保存，就是不会想到别处有个同名的。**必须留一条警告并把两个路径都打出来**，那条日志是排查这类问题的第一现场。
  7. 可预期的追问是「宽松会不会把坏 skill 放进来」。答案是这两件事的层次不同：宽松说的是格式容错，安全靠的是来源信任与工具权限，不能拿格式校验当安全边界。

  How to reason about it · think before answering

  1. Both halves share one stance: a runtime exists to get work done, not to validate. State that first.
  2. For loose loading, give a decidable boundary. The only hard rejection is a missing description: without it the skill has no trigger surface, can never be selected, and only wastes catalog tokens.
  3. Everything else warns and still loads: a name that differs from the directory, a name using capitals or underscores, an over-long description. These hurt quality but not usability.
  4. Cite the most common malformation as evidence: an unquoted colon inside a YAML value makes a strict parser reject the whole file. The right fallback order is full YAML parsing first, then a line-wise field reader that extracts only the scalar fields you know.
  5. For collisions, the direction matters less than the handling. The cross-client convention is project over user, while Claude Code orders enterprise, personal, then project. Both are defensible; pick one and stay consistent.
  6. The worst handling is silent discard. The user edits the project copy, nothing changes, and they suspect caching or a failed save rather than a same-named skill elsewhere. Always log a warning that prints both paths.
  7. Expected follow-up: does loose loading let bad skills in? These are different layers. Looseness is format tolerance; safety comes from source trust and tool permissions, not from schema validation.

  答题要点

  • 立场是运行时不是校验器，默认降级加载。
  • 唯一硬性淘汰是缺 description，因为它没有触发面、永远不会被选中。
  • 名字不一致、名字不合规、描述超长都只记诊断仍然加载。
  • 解析顺序是先完整 YAML、失败再按行取值兜底，专治值里没加引号的冒号。
  • 同名冲突要固定一种优先级并保持一致，绝不静默丢弃，警告里要带上两个路径。

  Key points

  • A runtime is not a validator; degrade by default.
  • The only hard rejection is a missing description, which leaves no trigger surface.
  • Name mismatches, invalid names and over-long descriptions warn but still load.
  • Parse with full YAML first, then fall back to line-wise field reading for unquoted colons.
  • Fix one collision priority, keep it consistent, and never discard silently: log both paths.

D6 组织与分发：插件与市场、版本与团队共享，以及函数调用、MCP、Skills 三者的分工

• 函数调用、MCP 和 Skills 三者的关系是什么？什么时候用哪个？How do function calling, MCP and Agent Skills relate, and when do you use which?

  国内高频海外高频进阶#agent-skills#mcp#tool-calling#architecture

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

  1. 这是本课最高频的一题。答错的典型是把三者摆成竞争关系，说「Skills 比 MCP 更轻量所以更好」——它们解决的根本不是同一个问题。
  2. 先给一句能背下来的分工：**MCP 管接线，Skills 管经验**，而函数调用是接线之前那根最短的线。
  3. 再落到缺口上。函数调用与 MCP 补的是**能力**：模型本来读不到你的数据库、发不出工单，给它工具它就能了。Skills 补的是**经验**：模型本来就会写提交信息，只是不知道你们这儿的格式。能力的缺口用工具补，经验的缺口用技能补。
  4. 然后给两条对比里最有信息量的差异。第一，上下文成本：工具定义每一轮都要重发，而 skill 每轮只有名字与描述，正文按需加载。第二，装不上时的降级：工具与协议是二值的，接不上就没有；**一个 skill 装不上仍然是一份人能读的 Markdown**，这正是它能在几十家客户端铺开的原因——它不要求宿主实现协议，只要求宿主会读文件。
  5. 选型给一条能当场走的流程：先分缺能力还是缺做法。缺能力时按复用面选，只有这一个应用要用就写函数调用，多个 Agent 都要用才值得做成 MCP 服务端。缺做法时按确定性选，靠指令说清楚就写进 skill 正文，结果必须逐字一致就配脚本。
  6. 最后一定要说配合。三者常态是叠着用：MCP 服务端把工单系统接进来成为工具，skill 的正文里写「先用工单查询工具拉出本周工单，再按这份模板归类」。**工具给它手，skill 给它章法。**
  7. 可预期的追问是「那什么时候不该用 MCP」。答案是只有一个应用要用、动作又只有两三个的时候——为它起一个服务端是过度设计，直接写函数调用更短。

  How to reason about it · think before answering

  1. The most common question in this course. The classic mistake is framing the three as competitors and saying skills are lighter than MCP, when they do not solve the same problem.
  2. Lead with the one-line division: MCP handles wiring, Skills handle experience, and function calling is the shortest wire of all.
  3. Then name the gaps. Function calling and MCP supply capability: the model cannot reach your database or file a ticket until you give it a tool. Skills supply experience: the model can already write a commit message, it just does not know your format.
  4. Give the two most informative contrasts. Context cost: tool definitions are resent every turn, while a skill costs only its name and description per turn with the body loaded on demand. Degradation: tools and protocols are binary, but a skill that fails to install is still readable Markdown, which is exactly why the format spread across dozens of clients. It requires the host to read files, not to implement a protocol.
  5. For selection give a runnable decision path. First separate missing capability from missing method. For capability, choose by reuse surface: one application means function calling, several agents justify an MCP server. For method, choose by determinism: instructions go in the skill body, byte-identical results go in a bundled script.
  6. Close on composition. The normal case stacks them: an MCP server exposes the ticket system as a tool, and a skill body says to pull this week's tickets with that tool and then group them by a template. Tools give hands, skills give procedure.
  7. Expected follow-up: when should you not use MCP? When only one application needs it and there are just two or three actions. Standing up a server is over-engineering.

  答题要点

  • 分工是 MCP 管接线、Skills 管经验，函数调用是接线之前最短的线。
  • 能力的缺口用工具或协议补，经验的缺口用技能补，三者不是竞争关系。
  • 工具定义每轮重发，skill 每轮只有名字与描述，正文按需加载。
  • skill 装不上仍是一份人能读的 Markdown，这是它跨客户端铺开的根本原因。
  • 选型先分缺能力还是缺做法：能力按复用面选，做法按确定性选；常态是三者叠着用。

  Key points

  • MCP is wiring, Skills are experience, function calling is the shortest wire.
  • Capability gaps need tools or a protocol; experience gaps need skills. They do not compete.
  • Tool definitions cost every turn; a skill costs only name and description until activated.
  • A skill that fails to install is still readable Markdown, which is why it spread across clients.
  • Choose by capability versus method: capability by reuse surface, method by determinism, and expect to combine all three.
• 一个团队要共享十几个 skill，你会怎么组织和分发？A team needs to share more than a dozen skills. How would you organize and distribute them?

  国内高频海外高频进阶#agent-skills#distribution#team-governance

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

  1. 这题考工程治理，不是考命令。面试官想听的是你按什么切包、按什么选分发路径，而不是背几条安装命令。
  2. 先讲组织。判据是**它们是否一起被采纳、一起被淘汰**：都围着同一套团队规范转、谁装了都得装全套，那就是一个包；一个是团队规范一个是你的个人习惯，凑在一起只会逼别人接受不想要的那半边。十几个 skill 通常应该切成三四个包，不是一个巨包也不是十几个碎包。
  3. 包的两条硬规矩要点出来：**包名就是命名空间**，包里的技能会被前缀成「包名冒号技能名」，撞名问题在这一层解决，所以包名要一次想好；组件目录必须在插件根下，不能塞进放清单的那个目录里，这是官方标出来的最常见错误。
  4. 再讲分发，给三条路径和各自的判据。随仓库走：直接放进项目目录跟着代码提交，零基础设施、评审走原来的流程，但只对这个仓库成立——**只跟某一个代码库有关的规范就选它**。
  5. 走市场：一个仓库加一份清单 JSON，成员各自添加一次，之后按需安装并自动收更新。一处维护多处生效、有版本、有升级说明，代价是要推动每个人添加一次。跨仓库的团队规范选它。**私有就是把市场仓库设成私有，没有中心服务器这回事。**
  6. 走组织托管：管理侧统一下发，不能随便关掉，覆盖率有保证、可审计，但流程重迭代慢，只有必须强制且不装就出事的规范才值得，比如安全合规那几条。
  7. 最后说三条不互斥，稳定组合是安全合规走托管、跨仓库规范走市场、项目独有的怪癖随仓库走。
  8. 可预期的追问是「十几个 skill 会不会把目录撑爆」。答案是发现阶段的开销只和描述总长有关，所以治理重点是**审描述的长度与互斥性**，而不是限制数量。

  How to reason about it · think before answering

  1. This tests governance, not commands. The interviewer wants your criteria for splitting packages and choosing a distribution path.
  2. Organization first. The criterion is whether they are adopted and retired together. Skills orbiting the same team convention belong in one package; a team convention and your personal habit do not, because bundling forces people to take the half they did not want. A dozen skills usually becomes three or four packages.
  3. Name two hard rules. The package name is the namespace, so skills are prefixed as package colon skill, which is where collisions are resolved; pick the name once. And component directories must sit at the plugin root, never inside the manifest directory, which is the documented top mistake.
  4. Then the three distribution paths with criteria. Ship with the repository: commit the skills alongside code, zero infrastructure, reviewed through the existing pull request flow, but scoped to that repository. Choose it for conventions tied to one codebase.
  5. Use a marketplace: a repository plus a catalog JSON, added once per person, then installed on demand with automatic updates. One place to maintain, real versions and upgrade notes, at the cost of getting everyone to add it. Private simply means a private repository; there is no central server.
  6. Organization-managed distribution: pushed centrally and not easily disabled, with guaranteed coverage and auditability, but heavy process and slow iteration. Reserve it for rules that must be enforced, such as security and compliance.
  7. Close by noting the three combine: compliance centrally managed, cross-repository conventions via a marketplace, project quirks with the repository.
  8. Expected follow-up: will a dozen skills blow up the catalog? Discovery cost scales with total description length, so governance means auditing description length and mutual exclusivity, not capping the count.

  答题要点

  • 切包的判据是它们是否一起被采纳、一起被淘汰，十几个通常切成三四个包。
  • 包名就是命名空间，撞名在这一层解决；组件目录必须在插件根下。
  • 只跟一个仓库有关的规范随仓库走，零基础设施但不跨仓库复用。
  • 跨仓库的团队规范走市场，市场就是一个仓库加一份清单 JSON，私有仓库即私有市场。
  • 必须强制的合规规范走组织托管，三条路径可以组合使用。

  Key points

  • Split by whether skills are adopted and retired together; a dozen usually becomes three or four packages.
  • The package name is the namespace where collisions are resolved, and component directories live at the plugin root.
  • Repository-scoped conventions ship with the repository: no infrastructure, no cross-repository reuse.
  • Cross-repository conventions go through a marketplace, which is just a repository plus a catalog JSON; private repo means private marketplace.
  • Mandatory compliance rules go through organization-managed distribution, and the three paths combine.

D7 综合与复盘：把一套团队规范做成 skill 包并驱动子代理完成一次真实任务

• 一份三十页的团队规范文档要拆成几个 skill，按什么切？How many skills should a thirty-page team convention document become, and how do you split it?

  国内高频海外高频进阶#agent-skills#design#decomposition

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

  1. 这题看着开放，其实有明确的对错。答「按章节切」几乎必错，能说清为什么错才是拿分点。
  2. 先给错的那条：**章节结构是为人的阅读顺序服务的**，通常从概念讲到细节；而 skill 的边界必须为触发场景服务——模型是在「用户刚说了一句话」这个时刻决定要不要翻开它。这两种结构几乎从不重合。
  3. 然后给正确的三步。第一步通读文档，只记「什么时候有人会用到这一段」，记场景不记内容，三十页通常能压出十来个场景。
  4. 第二步把场景按**同一个时刻**聚类。提交信息的格式、类型的取值、正文写什么，可能分散在三章里，但都在「我要提交了」这一刻被用到，它们是一个 skill；同一章里的「怎么写提交信息」和「怎么拆提交」是两个时刻，要拆开。
  5. 第三步为每个聚类写一句描述并检查互斥：各写三句会触发的话、两句形似但不该触发的话，跑一遍看有没有互相抢。**抢了说明聚类没聚干净，回第二步。**
  6. 还要主动说一件面试官爱追问的事：**文档里有一大半内容不该进任何 skill**。背景、沿革、当初为什么这么定，对人有价值，对模型是纯负担。判据仍是「不写这条，模型会不会做错」。三十页压成三四百行是正常的。
  7. 最后补一类特殊内容：确定性的规则（类型只能是这六个、版本号必须匹配某个格式）更适合沉淀成校验脚本，正文只留一句「写完跑一次校验」。
  8. 可预期的追问是「到底该切几个」。答案是数量由聚类结果决定而不是先定，但如果切出七八个还互相抢，通常是场景记得太细了；如果只切出一个，说明你还是按文档整体在想。

  How to reason about it · think before answering

  1. It sounds open-ended but has a clear wrong answer. Splitting by chapter is almost always wrong, and explaining why is where the points are.
  2. Chapter structure serves a human reading order, usually concept then detail. A skill boundary must serve the trigger moment, because the model decides whether to open it right after the user speaks. The two structures rarely coincide.
  3. Give three steps. First, read the document recording only when someone would need each passage. Record situations, not content; thirty pages usually yields a dozen situations.
  4. Second, cluster situations by shared moment. Commit message format, allowed types and body content may sit in three chapters but all apply at the moment of committing, so they are one skill. Writing a commit message and splitting commits share a chapter but are two moments, so they split.
  5. Third, write one description per cluster and test mutual exclusivity with three triggering phrases and two near-miss non-triggers each. If they compete, the clustering is not clean; go back to step two.
  6. Raise something interviewers probe: most of the document belongs in no skill. Background and history matter to people and are pure overhead for a model. The test remains whether omitting a line would make the model get it wrong. Thirty pages compressing to a few hundred lines is normal.
  7. Add the special case: deterministic rules such as an allowed type set or a version format belong in a validation script, leaving the body to say run the validator.
  8. Expected follow-up: how many exactly? The count follows the clustering. Seven or eight that still compete usually means the situations were recorded too finely; exactly one means you were still thinking about the document as a whole.

  答题要点

  • 不能按章节切，章节服务人的阅读顺序，skill 边界服务触发时刻。
  • 三步：只记使用场景、按同一个时刻聚类、写描述并用正负例查互斥。
  • 互相抢说明聚类没聚干净，要退回重聚，不是改描述糊过去。
  • 文档里一大半内容不进任何 skill，判据是不写这条模型会不会做错。
  • 确定性规则沉淀成校验脚本，正文只留一句跑校验。

  Key points

  • Do not split by chapter: chapters serve reading order, skill boundaries serve trigger moments.
  • Three steps: record situations, cluster by shared moment, write descriptions and test with positive and negative examples.
  • Competing descriptions mean bad clustering; go back rather than patching the wording.
  • Most of the document enters no skill; the test is whether omitting it would cause a mistake.
  • Deterministic rules become a validation script, leaving one line in the body.

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.
• 提示词工程和上下文工程的分界在哪？什么时候该从前者切换到后者？Where is the line between prompt engineering and context engineering, and when do you switch?

  国内高频海外高频进阶#prompt-engineering#context-engineering#scoping

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

  1. 这题最容易答成「上下文工程是提示词工程的升级版」，那是营销话术。面试官想听的是一条能当场用来分类问题的判据。
  2. 怎么拆：先给对象的差别。提示词工程处理的是内容——一段话怎么写才准确；上下文工程处理的是预算分配——整只箱子里各块占多少、什么时候该扔。前者是单次调用内的优化，后者是跨多轮的状态管理。
  3. 再给一条现场可用的分类法，用症状反推：同一个问题问一次答错、换个说法就对，是提示词问题；前五轮正常、第二十轮开始违反最初约束，是上下文问题；明明查到了数据模型却说没有，也是上下文问题——信息在窗口里，只是被淹没了。
  4. 结论：切换的时机不是「提示词写得够好了」，而是「问题的成因从单次表达变成了多轮累积」。加了工具、加了检索、开始多轮长跑，这三件事任何一件发生，都意味着该切换了。
  5. 可预期的追问：那上下文工程包含提示词工程吗？答：系统提示是上下文四块里的一块，所以提示词工程是上下文工程的一个子问题，但它解决不了另外三块——工具定义、历史和工具结果都不是靠把话写好能管住的。

  How to reason about it · think before answering

  1. The trap is answering that context engineering is just prompt engineering leveled up. Interviewers want a rule they can apply to classify a live problem.
  2. Start with the object of each. Prompt engineering shapes content: how to phrase one instruction precisely. Context engineering allocates budget: how much of the window each part gets and when to drop things. One optimizes inside a single call, the other manages state across turns.
  3. Then give a symptom-based test. Wrong once but right after rephrasing means a prompt problem. Fine for five turns and violating the original constraints by turn twenty means a context problem. Retrieving the data and then claiming it does not exist is also a context problem: the information is in the window but buried.
  4. Conclusion: you switch not when the prompt is good enough, but when the cause moves from single-turn phrasing to multi-turn accumulation. Adding tools, adding retrieval, or running long sessions each trigger the switch.
  5. Expect the follow-up: does context engineering subsume prompt engineering? The system prompt is one of the four parts, so prompt engineering is a subproblem, but it cannot touch tool definitions, history, or tool results.

  答题要点

  • 提示词工程处理内容，上下文工程处理预算分配；一个在单次调用内，一个跨多轮。
  • 症状分类法：换个说法就对是提示词问题；跑久了开始违反约束是上下文问题；查到了却说没有也是上下文问题。
  • 切换时机是问题成因从单次表达变成多轮累积，通常发生在加工具、加检索、开始长跑之后。
  • 系统提示只是上下文四块之一，所以写好提示词管不住另外三块。

  Key points

  • Prompt engineering shapes content; context engineering allocates budget across turns.
  • Classify by symptom: fixed by rephrasing is a prompt issue; drifting after many turns is a context issue; retrieved but reported missing is also a context issue.
  • Switch when the cause moves from single-turn phrasing to multi-turn accumulation, typically after adding tools, retrieval, or long-running sessions.
  • The system prompt is one of four parts, so good phrasing alone cannot control the other three.

D2 系统提示与指令层次：高度适中、持久指令文件、渐进披露，少即是多

• 系统提示的高度怎么把握？写太具体和写太笼统各会出什么问题？How do you calibrate the altitude of a system prompt, and what goes wrong at each extreme?

  国内高频海外高频进阶#system-prompt#altitude

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

  1. 这题在考你有没有一把可操作的尺子。凡是答「要恰到好处」「要具体但不要太具体」的，都会被归到没做过工程那一类，因为这句话不能指导任何一次具体修改。
  2. 怎么拆：先把两端的病症说清楚。写太具体是把业务逻辑硬编码进了自然语言——七种订单状态写成七条分支，加一个状态就要改提示词，而且没有任何测试会告诉你改漏了。写太笼统是一段读起来无可指摘、删掉之后模型行为却完全不变的话。
  3. 给尺子：你能为这条规则写出一个自动检查它有没有被遵守的断言吗。写不出来说明飞太高；写得出来但断言要列举七种情况说明飞太低；写得出来且断言很短，高度就合适。这把尺子的好处是能当场逐条判定，不需要争论。
  4. 结论加修法：太低的修法是挪走而不是缩写——留下入口规则，把分支细节搬进引用文件按需读取；太高的修法是把它当初对应的那次事故翻译成可核对的规则，而不是直接删掉，否则同一个事故会再来一次。
  5. 可预期的追问：那怎么知道一条规则当初是为什么加的？答：加规则的时候就在旁边记下它是为哪个失败案例加的。没有这句注释，半年后没人敢删任何一条。

  How to reason about it · think before answering

  1. This tests whether you have an operational yardstick. Answering that it should be specific but not too specific fails, because that sentence cannot guide a single concrete edit.
  2. Name both failure modes. Too low means business logic hardcoded into prose: seven order states become seven branches, every new state forces a prompt edit, and no test tells you when you missed one. Too high means text that reads well and changes nothing if deleted.
  3. Give the yardstick: can you write an automated assertion that checks whether the rule was followed? If not, the rule is too high. If the assertion needs to enumerate seven cases, the rule is too low. A short assertion means the altitude is right.
  4. Then the fixes. For too low, relocate rather than shorten: keep the entry rule and push branch detail into a reference file loaded on demand. For too high, translate the incident that produced it into a checkable rule instead of just deleting it, or the incident recurs.
  5. Expect the follow-up: how do you know why a rule was added? Record the failing case beside the rule when you add it. Without that note, nobody will dare delete anything six months later.

  答题要点

  • 高度太低是把业务分支硬编码进自然语言，脆且改漏无人知；太高是删掉也不改变行为的废话。
  • 判据：能不能为这条规则写出一个自动断言，断言写不出或要列举七种情况都是高度不对。
  • 太低的修法是把细节挪进引用文件、主提示只留入口规则；太高的修法是把对应事故翻译成可核对的规则。
  • 每加一条规则就记下它对应的失败案例，这是将来敢不敢删它的唯一依据。

  Key points

  • Too low hardcodes business branches into prose: brittle, and silent when it goes stale. Too high is text that changes nothing when removed.
  • Test: can you write an automated assertion for the rule? No assertion, or one that enumerates seven cases, means the altitude is wrong.
  • Fix too low by relocating detail into on-demand reference files and keeping only the entry rule; fix too high by translating the originating incident into a checkable rule.
  • Record the failing case beside every rule you add; it is the only basis for deleting it later.
• 哪些内容该进系统提示，哪些该进持久指令文件，哪些该按需加载？What belongs in the system prompt, what belongs in a persistent instruction file, and what should be loaded on demand?

  国内高频海外高频进阶#instruction-hierarchy#progressive-disclosure

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

  1. 这题在考分层意识。只回答「常用的放系统提示」是循环论证——问题恰恰是怎么定义常用。面试官想听的是一条排序明确的判定流程。
  2. 怎么拆：给三问，第一个答是就落定。第一问，模型不看这条会做错吗，不会就删除；第二问，是不是每一类任务都用得上，不是就下沉到引用文件、主提示里只留一句索引；剩下的保留，并重写成能被机械核对的一句话。
  3. 补一层常被漏掉的划分：还有一类内容根本不属于以上三者——随时间变化的运行时事实，比如当前是不是夜间、是不是节假日延迟期、本次会话的订单号。它们看着像规则，写死在系统提示里就会在半天之后开始骗用户，应该由工具返回或每次拼进用户消息。
  4. 结论：判据是稳定程度加使用频率。越稳定越靠前，越少用越靠后；而每次都变的东西根本不进系统提示。附带一个工程收益——按稳定程度排序之后，缓存前缀才有机会命中，改一条任务变量不会打掉整段缓存。
  5. 可预期的追问：下沉是不是比删除安全？不是。搬进引用文件的内容仍然要维护、仍然会在需要时占上下文，只是晚一点少一点。真正没用的条目要删，「先留着以防万一」正是提示词膨胀的主因。

  How to reason about it · think before answering

  1. This tests layering. Answering that frequently used content goes in the system prompt is circular, since defining frequently used is the actual question. Give an ordered decision procedure instead.
  2. Three questions, first yes wins. Would the model get it wrong without this rule? If not, delete. Is it needed for every class of task? If not, push it into a reference file and leave a one-line index. Whatever remains stays, rewritten as a mechanically checkable sentence.
  3. Add the category people miss: runtime facts that change over time, such as whether it is currently night hours, whether holiday shipping delays apply, or this session's order id. They look like rules but start lying to users hours later. They belong in tool output or in the user message.
  4. Conclusion: sort by stability and frequency. The more stable, the earlier; the rarer, the later; anything that changes every call never enters the system prompt. Bonus: this ordering is what makes a cache prefix hittable, so editing a task variable does not invalidate everything.
  5. Expect the follow-up: is pushing content down safer than deleting it? No. Reference files still have to be maintained and still consume context when read, just later and less often. Keeping things just in case is the main cause of prompt bloat.

  答题要点

  • 三问定去处：模型不看会做错吗（不会就删）、每类任务都用得上吗（不是就下沉）、剩下的保留并重写成可核对的一句话。
  • 第四类是运行时事实（时间、节假日、本次订单号），不属于系统提示，应由工具返回或拼进用户消息。
  • 分层顺序按稳定程度排，稳定的在前，这样缓存前缀才有机会命中。
  • 下沉不是免罪符：引用文件仍要维护、仍会占上下文，没用的要删掉。

  Key points

  • Three questions decide placement: would the model err without it (no means delete), is it needed by every task class (no means push down), and the rest stays as a checkable sentence.
  • A fourth category is runtime fact (time of day, holiday delays, this session's order id); it belongs in tool output or the user message, not the system prompt.
  • Order layers by stability so the cache prefix stays hittable.
  • Pushing down is not free: reference files still cost maintenance and context, so genuinely useless rules should be deleted.

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

• Agent 挂了三十个工具，明显吃不消了。你会怎么裁？依据是什么？An agent has thirty tools mounted and it is clearly struggling. How do you cut the list, and on what basis?

  国内高频海外高频进阶#tool-design#tool-budget

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

  1. 这题在考你能不能区分两类完全不同的代价。只答「工具定义占 token」的人只看到了一半，面试官真正在意的是另一半——选择成本。
  2. 怎么拆：先分两类问题。预算问题是工具定义每一轮都重发，3 个工具约 308 token、8 个约 731，挂三十个就是两千多，每轮都在花。选择问题是工具越多模型越容易选错，判据很硬：如果一个人类工程师都说不清什么时候该用哪个工具，那模型也做不到。
  3. 给四条可执行的裁剪判据，按顺序问：职责有没有重叠（有就合并或把边界写进描述）、过去一百次真实会话里被调用过几次（零次直接摘掉）、任务类型能不能提前判断（能就按任务动态挂载）、能不能把几个查询合并成一个带参数的工具。
  4. 结论：第三条通常收益最大。多数 Agent 的工具清单是静态的，启动时挂全集挂到会话结束，而一次会话往往只属于两三类任务中的一类，按任务大类动态挂载一步就能砍掉一半。
  5. 可预期的追问：动态挂载有什么副作用？工具定义排在缓存前缀最前面，改它会让整段前缀失效，所以只能按任务大类切几档，不能每轮重算——会话开始时定一次，中途除非任务类型真变了否则不动。

  How to reason about it · think before answering

  1. The question separates people who see only the token bill from people who also see the selection cost. Answering with token count alone covers half the problem.
  2. Two distinct costs. Budget: tool definitions are resent every turn, roughly 308 tokens for three tools and 731 for eight, so thirty tools burn a couple thousand tokens per turn. Selection: more tools means more wrong choices, and the sharp test is that if a human engineer cannot say which tool applies, the model cannot either.
  3. Give four ordered criteria: overlapping responsibility (merge, or write the boundary into the description), call frequency across the last hundred real sessions (zero calls means remove), whether the task type can be determined up front (if so, mount per task), and whether several query tools can collapse into one parameterized tool.
  4. Conclusion: the third usually wins biggest. Most agents mount the full set at startup and keep it for the whole session, while any given session belongs to only two or three task classes, so per-task mounting typically halves the definitions immediately.
  5. Expect the follow-up on side effects: tool definitions sit at the very front of the cache prefix, so changing them invalidates everything after. Mount by coarse task class once at session start rather than recomputing every turn.

  答题要点

  • 两类代价：预算（工具定义每轮重发，随数量线性增长）与选择（重叠工具让模型在决策点上摇摆）。
  • 判据：人类说不清该用哪个，模型也做不到。
  • 四条裁剪顺序：合并职责重叠的、摘掉零调用的、按任务类型动态挂载、把多个查询合并成带参数的一个。
  • 动态挂载收益最大，但会打掉缓存前缀，所以按任务大类切档、会话内不再变。

  Key points

  • Two costs: budget (definitions resent every turn, growing with count) and selection (overlapping tools make the model waver at decision points).
  • Test: if a human cannot say which tool applies, neither can the model.
  • Four cuts in order: merge overlaps, drop never-called tools, mount per task type, collapse several queries into one parameterized tool.
  • Per-task mounting pays most but invalidates the cache prefix, so switch by coarse task class once per session.
• 按需加载和预先检索怎么选？混合策略应该怎么搭？How do you choose between just-in-time loading and pre-inference retrieval, and how would you combine them?

  国内高频海外高频进阶#retrieval#just-in-time#hybrid

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

  1. 这题在考场景判断。答「按需加载更先进」的会被当成跟风，因为预先检索在很多场景里就是更好的选择，说不出它好在哪说明没做过。
  2. 怎么拆：用三个问题分开。需要的资料范围事先能不能确定（能就预先检索）、资料变化快不快（变得快索引一建就旧，偏按需加载）、一次能不能取完（要顺着线索翻好几层就只能按需）。
  3. 把两者的本质差别点出来：预先检索把「取什么」的决定权交给检索算法，在推理之前一次性做完；按需加载把这个决定权交给模型自己，在推理过程中分多次做。前者延迟低、可预测，后者能应付事先不知道要什么的情况。
  4. 结论是混合：把最稳定最常用的一小部分预先放进去（比如项目的常驻说明文件），其余靠运行时的搜索原语现取。这样既有起步速度，又不会被过期索引拖住。这也是编码类 Agent 的主流做法。
  5. 可预期的追问：按需加载的成本在哪？多了几轮往返，延迟更高，而且每一次取回的正文都会留在上下文里继续占预算——所以它必须和裁剪配套，取回来的东西该扔的时候要扔。

  How to reason about it · think before answering

  1. This tests situational judgment. Calling just-in-time more advanced reads as trend-following, because pre-inference retrieval is genuinely better in many cases.
  2. Separate with three questions: can the needed material be scoped in advance (yes favors pre-retrieval), how fast does the material change (fast means indexes go stale, favoring just-in-time), and can it be fetched in one shot (multi-hop exploration forces just-in-time).
  3. Name the underlying difference: pre-retrieval hands the what-to-fetch decision to a retrieval algorithm and settles it before inference; just-in-time hands it to the model and spreads it across the run. The first is faster and more predictable, the second handles not knowing in advance.
  4. Conclusion is hybrid: preload the small, stable, always-relevant slice such as a project's standing instruction file, and use runtime search primitives for the rest. That gives a fast start without stale indexing, which is what coding agents converge on.
  5. Expect the follow-up on cost: just-in-time adds round trips and latency, and every fetched body stays in context consuming budget, so it must be paired with trimming.

  答题要点

  • 三个判断：范围能不能事先确定、资料变化快不快、一次能不能取完。
  • 预先检索把取什么的决定交给检索算法并在推理前做完；按需加载把它交给模型并分多次做。
  • 多数真实项目是混合：稳定常用的一小部分预加载，其余靠运行时搜索原语现取，避开索引过期。
  • 按需加载的代价是多轮往返与延迟，且取回的正文会继续占预算，必须和裁剪配套。

  Key points

  • Three questions: can scope be fixed in advance, how fast does the data change, and can it be fetched in one shot.
  • Pre-retrieval delegates the fetch decision to an algorithm before inference; just-in-time delegates it to the model during the run.
  • Most real systems are hybrid: preload the stable core, use runtime search for the rest, avoiding stale indexes.
  • Just-in-time costs round trips and latency, and fetched bodies keep consuming budget, so pair it with trimming.

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

• 什么时候该压缩上下文，什么时候该直接换一个更大的窗口？When should you compact the context, and when should you just move to a larger context window?

  国内高频海外高频进阶#compaction#context-rot

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

  1. 这题在考你有没有把窗口当容量、把注意力当预算。只回答「窗口不够就压缩」的人漏掉了一半——很多时候窗口还很空，但已经该压了。
  2. 怎么拆：先把两个问题分开。窗口不够是容量问题，换大窗口确实能解决；但换大窗口解决不了上下文腐烂——上下文越长模型准确回忆的能力越差，这是一条缓坡，标称窗口大不等于在那个长度上表现稳定。所以「装得下」和「用得好」是两件事。
  3. 给判据：看两个指标而不是一个。窗口占用率高就该压（容量问题）；占用率不高但有效信息占比很低，也该压（注意力问题）——后者最容易被忽略，因为看起来毫无压力。
  4. 再给顺序上的结论：压缩不是第一手段。先清掉旧的工具结果（不用调模型、确定、可逆），不够再摘要历史。反过来做的人很多，因为摘要听起来更高级，但摘要要多花一次调用、要承担丢信息的风险，而它治的往往不是大头。
  5. 可预期的追问：那什么时候压缩也不够？当状态是渐进积累的账本而不是可总结的结论时——比如精确计数、地图、长期计划。这类东西要写到窗口外面的文件里，不能靠摘要保住。

  How to reason about it · think before answering

  1. This checks whether you treat the window as capacity and attention as a budget. Answering only that you compact when it does not fit misses half the cases, since plenty of sessions should be compacted while the window is still mostly empty.
  2. Separate the two problems. Not fitting is capacity, and a bigger window fixes it. But a bigger window does not fix context rot: recall degrades as context grows, on a gradient, so a large nominal window is not a promise of stable behavior at that length. Fitting and being used well are different.
  3. Give the test: watch two signals, not one. High window occupancy means compact for capacity. Low occupancy with a low share of actually-useful tokens also means compact, for attention. The second is the one people miss because nothing looks urgent.
  4. Then order the tactics. Compaction is not the first move. Clear stale tool results first, since that needs no model call, is deterministic, and is reversible. Only then summarize history. Doing it the other way costs an extra call and risks losing information while usually treating the smaller bucket.
  5. Expect the follow-up: when is compaction itself not enough? When the state is an accumulating ledger rather than a summarizable conclusion, such as exact tallies, maps, or a long-term plan. Those belong in files outside the window.

  答题要点

  • 窗口不够是容量问题，换大窗口能解决；上下文腐烂是注意力问题，换大窗口解决不了。
  • 两个触发信号：窗口占用率高，或占用率不高但有效信息占比很低。
  • 顺序上先清旧工具结果（不调模型、确定、可逆），不够再摘要历史。
  • 如果状态是渐进积累的账本（计数、地图、长期计划），压缩救不了，要写到窗口外的文件里。

  Key points

  • Not fitting is capacity and a larger window solves it; context rot is attention and a larger window does not.
  • Two triggers: high window occupancy, or low occupancy with a low share of useful tokens.
  • Clear stale tool results first (no model call, deterministic, reversible), then summarize history.
  • If the state is an accumulating ledger such as tallies, maps, or a plan, use external files instead of compaction.

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

• 上下文出问题的时候，你怎么定位是四块里的哪一块？When context is the problem, how do you localize which of the four buckets is at fault?

  国内高频海外高频进阶#diagnostics#metrics

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

  1. 这题在考排查路径。答「先看日志」「多试几次」的会被判成没有方法论，面试官想听的是从现象到指标再到改动的一条固定链路。
  2. 怎么拆：先给两个指标。窗口占用率是单轮输入除以窗口上限，管的是会不会撑爆；有效信息占比是后续步骤真正用到的 token 除以总 token，管的是值不值。后者可以用裁剪器近似量：裁完还剩的那部分就是分子。
  3. 再给四种失败模式与各自的指纹：塞太满（漏读早期指令，占用率高）、找不到（信息在窗口里但模型说没有，有效信息占比低）、说不清（同类问题答法摇摆，占用率不高但错误率高）、越走越偏（跑久了违反最初约束，压缩前后的保留检查出现失败项）。
  4. 结论给最容易误判的两种。「找不到」常被误判成模型能力不足，判据是把上下文打印出来人肉搜一遍那条信息在不在——在就是上下文问题，不是模型问题。「说不清」常被误判成模型不稳定，实际多半是系统提示里有互相矛盾的规则，或者两个职责重叠的工具让模型在决策点上横跳。
  5. 可预期的追问：两个指标冲突时听谁的？答：占用率低但有效信息占比也低的情况最危险，因为看起来毫无压力却在按原价搬运垃圾，同时还在稀释注意力。这时应该以有效信息占比为准。

  How to reason about it · think before answering

  1. This tests a diagnostic path. Answering with check the logs or try again reads as having no method; interviewers want a fixed chain from symptom to metric to change.
  2. Start with two metrics. Window occupancy is per-turn input over the window limit and governs whether you will overflow. Useful-token share is the tokens later steps actually use over total tokens and governs whether the spend is worth it. Approximate the latter with your trimmer: whatever survives trimming is the numerator.
  3. Then four failure modes with their fingerprints: overstuffed (early instructions ignored, high occupancy), buried (the fact is in the window yet the model denies it, low useful share), underspecified (answers waver across identical questions, low occupancy but high error rate), and drifting (original constraints violated late in the session, retention checks failing after compaction).
  4. Highlight the two most misdiagnosed. Buried is routinely blamed on model capability; the test is to print the context and search for the fact by hand, and if it is there the problem is context, not the model. Underspecified is blamed on instability, when it usually means contradictory rules in the system prompt or two overlapping tools making the model waver.
  5. Expect the follow-up on conflicting metrics. Low occupancy with a low useful share is the dangerous combination, because nothing looks urgent while you pay full price to move noise and dilute attention. Trust the useful-token share there.

  答题要点

  • 两个指标：窗口占用率管会不会撑爆，有效信息占比管值不值，后者可用裁剪器近似量。
  • 四种模式各有指纹：塞太满看占用率、找不到看有效信息占比、说不清看错误率、越走越偏看压缩后的保留检查。
  • 找不到最容易被误判成模型能力问题，判据是把上下文打印出来人肉搜一遍。
  • 说不清多半是规则互相矛盾或工具职责重叠，去搜矛盾比换模型有用。

  Key points

  • Two metrics: occupancy for overflow risk, useful-token share for whether the spend earns its place, approximated with a trimmer.
  • Each mode has a fingerprint: occupancy for overstuffed, useful share for buried, error rate for underspecified, post-compaction retention checks for drifting.
  • Buried is most often misdiagnosed as model capability; print the context and search by hand.
  • Underspecified usually means contradictory rules or overlapping tools; hunt the contradiction rather than swapping models.
• 上下文工程做到什么程度算够？你怎么知道该停手了？How much context engineering is enough, and how do you know when to stop?

  国内高频海外高频进阶#tuning#stopping-criteria

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

  1. 这题是开放题，但它有明确的好坏。答「越优化越好」的人会被判成没有成本意识，因为上下文工程是个能无限做下去的活，不定停手判据就一定会做过头。
  2. 怎么拆：先说清过度优化的具体代价，不要停在「浪费时间」。裁得太狠会把后面才用得上的字段裁掉，压得太狠会丢掉不像结论的硬性要求，工具裁得太少会让模型没法完成任务。这些都不报错，只在正确率上体现，而正确率是最贵的一笔账。
  3. 给可核对的停手条件，至少三条：有效信息占比稳定在一个合理区间（比如 50% 以上）且连续几次测量没有上升空间；最长那条用例上的单轮窗口占用率不超过 50%；最近一次改动带来的账单降幅低于 5%。
  4. 结论落在第三条：降幅低于 5% 说明剩下的都是必要开销，继续压就是在拿正确率换钱。这条比前两条更重要，因为它是唯一一条与具体项目无关、可以直接复用的判据。
  5. 可预期的追问：那怎么保证停手之后不退化？把这套度量固化成回归：一批固定用例、每次改动都重跑、账单与两个指标进监控。上下文工程不是一次性项目，模型换代、工具增减、下游接口改字段，任何一件都会让它重新变差。

  How to reason about it · think before answering

  1. This is open-ended but has a clear right shape. Saying more optimization is always better reads as lacking cost awareness, because context work is unbounded and will be overdone without a stopping rule.
  2. Name the concrete cost of overdoing it rather than stopping at wasted time. Trim too hard and you cut fields needed later; compact too hard and you lose hard requirements that do not read like conclusions; cut tools too far and the agent cannot finish the task. None of these raise errors; they show up only in accuracy, the most expensive bill.
  3. Give at least three checkable stopping conditions: useful-token share stable in a healthy band such as above fifty percent with no headroom across several measurements; per-turn occupancy under fifty percent on your longest case; and the last change delivering less than a five percent bill reduction.
  4. Land on the third: a sub-five-percent gain means what remains is necessary overhead, and squeezing further trades accuracy for money. It matters most because it is the only condition that transfers across projects unchanged.
  5. Expect the follow-up on preventing regression. Freeze the measurement into a regression suite: fixed cases, rerun on every change, bill and both metrics under monitoring. Model upgrades, tool churn, and downstream field changes each degrade it again.

  答题要点

  • 过度优化的代价不报错，只在正确率上体现：裁掉后面才用的字段、压掉不像结论的硬性要求、工具少到做不完任务。
  • 三条停手判据：有效信息占比稳定且无上升空间、最长用例的单轮占用率不超过 50%、最近一次改动账单降幅低于 5%。
  • 第三条最通用：降幅低于 5% 说明剩下的是必要开销，再压就是拿正确率换钱。
  • 停手后要固化成回归：固定用例、每次改动重跑、账单与两个指标进监控。

  Key points

  • Overdoing it fails silently in accuracy: fields needed later get cut, hard requirements get summarized away, and too few tools leave the task unfinishable.
  • Three stopping conditions: a stable useful-token share with no headroom, per-turn occupancy under fifty percent on the longest case, and a last change worth under five percent of the bill.
  • The third transfers best: under five percent means what remains is necessary overhead and further squeezing trades accuracy for money.
  • After stopping, freeze it into regression: fixed cases, rerun on every change, and monitor the bill plus both metrics.

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

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

• BM25 里的词频饱和与文档长度归一化分别在解决什么问题？把 k1 和 b 都设成 0 会发生什么？In BM25, what problems do term-frequency saturation and document length normalisation each solve? What happens if you set both k1 and b to zero?

  国内高频海外高频进阶#bm25#ranking#information-retrieval

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

  1. 这题考的是你有没有真的读过公式，而不是有没有调过库。判据很明确：能不能把 k1 和 b 各自对应到公式里的哪一项，并说出去掉之后会被什么样的文档钻空子。
  2. 先说朴素词频的两个漏洞：一是重复刷词，一篇文章把关键词写五十遍就能霸榜；二是长文占便宜，文档越长越容易蒙中查询里的词。这两个漏洞正好对应两个修正。
  3. k1 管第一个漏洞。分子分母里都有词频 f，所以词频涨上去之后整个分式趋近一个上界而不是线性增长——写五十遍确实比写五遍相关，但绝不该相关十倍。k1 越小饱和越快。
  4. b 管第二个漏洞。归一化项是 1 减 b 加上 b 乘以本文长度除以平均长度，b 等于 0 时完全不看长度，b 等于 1 时完全按长度比例惩罚，0.75 是长期折中的默认值。
  5. 回到题干那个陷阱：k1 设成 0 会让分式退化成常数，词出现一次和一百次得分完全一样，等于只剩「有没有出现过」的布尔匹配；b 设成 0 则长度信息彻底消失。两个一起设成 0，BM25 就退化成对逆文档频率求和，跟词频再无关系。
  6. 可预期的追问：那逆文档频率去掉行不行？答案是不行，去掉之后「的」「我们」这类高频词会淹没一切——而且要顺带说明 BM25 因此天然不需要停用词表，这一句最能体现你读懂了公式。

  How to reason about it · think before answering

  1. This checks whether you have actually read the formula rather than merely called a library. The test is whether you can map k1 and b onto specific terms and name the failure each one prevents.
  2. Start with the two holes in raw term frequency: keyword stuffing lets one document dominate by repeating a word, and long documents win by accident because they contain more words overall.
  3. k1 closes the first hole. Term frequency appears in both numerator and denominator, so the ratio approaches a ceiling instead of growing linearly. Fifty mentions are more relevant than five, but not ten times more relevant. A smaller k1 saturates sooner.
  4. b closes the second. The normalisation factor is one minus b plus b times document length over average length: at b equal to zero length is ignored entirely, at one it is fully penalised, and 0.75 is the conventional compromise.
  5. Now the trap in the question: k1 equal to zero collapses the ratio to a constant, so one occurrence scores the same as a hundred and matching becomes boolean. b equal to zero removes length entirely. Set both to zero and BM25 degenerates into a plain sum of inverse document frequencies.
  6. Expected follow-up: can you drop the IDF term? No. Without it, ubiquitous words drown everything else, and it is precisely IDF that lets BM25 work without a stopword list.

  答题要点

  • 词频饱和由 k1 控制，防的是重复刷词：词频涨大后得分趋近上界而非线性增长。
  • 长度归一化由 b 控制，防的是长文档靠词多蒙中查询，用本文长度比平均长度把它压回去。
  • k1 设 0 会退化成布尔匹配，词出现一次和一百次同分；b 设 0 则完全不考虑文档长度。
  • 两者都设 0 时 BM25 只剩逆文档频率求和，等于放弃了词频信息。
  • 逆文档频率是第三块，让稀有词权重更高，也让 BM25 天然不需要停用词表。

  Key points

  • k1 controls saturation and prevents keyword stuffing: the score approaches a ceiling rather than growing linearly with frequency.
  • b controls length normalisation and stops long documents from winning by sheer word count.
  • Setting k1 to zero degenerates the scorer into boolean matching; one occurrence scores the same as a hundred.
  • Setting b to zero removes document length from the equation entirely; both at zero leaves only a sum of IDF terms.
  • IDF is the third component: it up-weights rare terms and removes the need for a stopword list.
• 一个检索增强生成系统答错了，你怎么定位是检索的锅还是生成的锅？A retrieval-augmented generation system gave a wrong answer. How do you determine whether retrieval or generation is at fault?

  国内高频海外高频进阶#debugging#failure-modes#evaluation

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

  1. 题眼在「怎么定位」，不在「有哪些原因」。答成一串可能原因的罗列就输了，面试官想听的是一个有先后顺序、能落到具体动作的排查流程。
  2. 先给最省时间的第一步：把这次检索出来的几段原文原样打印出来，自己读一遍。正确答案不在里面就是检索的锅，在里面而模型没用上才是生成的锅。这一步三十秒，能省掉大半天的瞎猜。
  3. 然后把链路展开成五个环节——切块、建索引、检索、组装上下文、生成——并给出「排查从右往左、修复从左往右」这条口径：从右往左是因为你最先看到的是生成结果，从左往右是因为左边的错会被右边放大。
  4. 补充几个能把环节钉死的症状：答案「半对」多半是切块把一条完整规则切断了；检索结果里混着一眼不相干的东西多半是解析没做干净；模型无视材料用先验知识作答，通常是提示词里少了「只能依据资料回答」；引用编号和内容对不上，那是生成侧漏读或串了行。
  5. 最后落到工程做法：这套排查要能重复做，就必须把每次请求的检索结果、进上下文的段落、最终回答一起记下来，否则线上出问题时你根本复现不了。到了要批量做的时候，就得换成一批固定问题加指标，而不是一条条人工看。
  6. 可预期的追问：如果检索确实没捞到，改提示词有没有用？答案是没用——材料里没有的东西，再好的指令也只能换一种编法。这句话最能证明你分清了两层。

  How to reason about it · think before answering

  1. The question asks how you localise the fault, not what the possible causes are. Listing causes loses; the interviewer wants an ordered procedure that ends in concrete actions.
  2. Give the cheapest first step: print the retrieved passages verbatim and read them. If the correct answer is not in there, retrieval is at fault. If it is in there and the model ignored it, generation is at fault. Thirty seconds, and it removes most of the guesswork.
  3. Then lay out the five stages — chunking, indexing, retrieval, context assembly, generation — with the rule: diagnose right to left, fix left to right. You see the generated answer first, but an error on the left is amplified by everything to its right.
  4. Add symptoms that pin down a stage: half-correct answers usually mean a rule was split across chunks; obviously irrelevant hits usually mean dirty parsing; the model ignoring the supplied material usually means the prompt never said it must; citation numbers that do not match their content point at generation.
  5. Land it in engineering terms: to run this procedure repeatedly you must log the retrieved hits, the passages that entered the context, and the final answer together, otherwise production issues are unreproducible. At scale this becomes a fixed question set with metrics rather than case-by-case reading.
  6. Expected follow-up: if retrieval missed the document, will prompt tuning help? No. Nothing in the prompt can conjure material that was never supplied.

  答题要点

  • 第一步永远是把检索出来的原文打印出来读一遍，判断正确答案在不在里面。
  • 把链路拆成切块、建索引、检索、组装上下文、生成五个环节，排查从右往左、修复从左往右。
  • 用症状钉环节：半对多半是切块问题，混入无关结果多半是解析问题，无视材料多半是提示词缺约束，引用与内容对不上是生成问题。
  • 检索没捞到时改提示词没有意义，材料里没有的东西模型只能编。
  • 要能重复排查就必须把检索结果、进上下文的段落和最终回答一起记录下来。

  Key points

  • Always start by printing the retrieved passages and checking whether the correct answer is present at all.
  • Split the pipeline into chunking, indexing, retrieval, context assembly and generation; diagnose right to left, fix left to right.
  • Use symptoms to pin the stage: half-correct answers point at chunking, irrelevant hits at parsing, ignored material at the prompt, mismatched citations at generation.
  • If retrieval missed the document, prompt changes cannot help; the material simply is not there.
  • Log retrieved hits, the passages that entered the context, and the final answer together, or production failures are unreproducible.

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.
• 为什么有些 embedding 模型要求查询和文档加不同的前缀？不加会怎样，你怎么在上线前发现这个问题？Why do some embedding models require different prefixes for queries and documents? What happens if you skip them, and how would you catch it before shipping?

  国内高频海外高频进阶#embeddings#model-selection#evaluation

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

  1. 这题的题眼是「静默失效」。会背「e5 要加 query 和 passage 前缀」只能拿基础分，能说清它为什么不报错、以及怎么在上线前抓住它，才是做过的人。
  2. 先讲原因：这一族模型是拿成对数据训练的，一侧是短问句、一侧是长段落，两者的分布本来就不一样。前缀是训练时给模型的角色标记，告诉它这一段该按查询编码还是按文档编码。推理时不给，模型就落在了训练分布之外。
  3. 再讲后果的性质：不加前缀模型照样输出向量、照样能算距离、名次照样有先后，只是整体质量下滑。**没有任何报错**——这跟忘了归一化是同一类问题：错误不会自己浮出来。
  4. 怎么发现：唯一可靠的办法是一小份标注问题集，用同一批文档跑两遍（加前缀与不加前缀），比命中率。这就是第 8 天要做的评估闸门，它的价值恰恰在于抓这类静默错误。上线前跑一遍，比读十遍文档管用。
  5. 补一个更容易踩的变体：**建库时加了前缀、查询时忘了加**，或者两边加成同一个前缀。这种情况下所有向量都在同一个坐标系里，看起来更「正常」，但查询与文档的对齐关系是错的，掉分同样查不出来。所以前缀应该封装在 embed 的调用约定里，而不是散在各处手拼。
  6. 可预期的追问：OpenAI 的模型要不要加前缀？不需要——它不属于这一族。所以这不是一条普遍规则，而是**每换一个模型都要重新读模型卡片确认**的事。

  How to reason about it · think before answering

  1. The core of this question is silent failure. Reciting 'e5 needs query: and passage: prefixes' is the baseline; explaining why nothing errors out and how you would catch it is what shows experience.
  2. The reason: these models are trained on pairs, short questions on one side and longer passages on the other, two genuinely different distributions. The prefix is a role marker learned during training. Omit it at inference and you are off-distribution.
  3. The consequence: the model still returns vectors, distances still compute, results still have an order, quality just degrades. Nothing throws, exactly like forgetting to normalise.
  4. How to catch it: run a small labelled question set against the same corpus twice, with and without prefixes, and compare hit rate. That is the evaluation gate built on day 8, and catching silent regressions is precisely what it is for.
  5. Mention the sneakier variant: prefixing at index time but not at query time, or using the same prefix on both sides. Everything sits in one coordinate space and looks healthier, yet the query-document alignment is wrong and the loss is just as invisible. Encapsulate prefixes in the embedding call convention rather than hand-writing them everywhere.
  6. Expected follow-up: do OpenAI models need prefixes? No, they are not in that family, so this is not a universal rule but a per-model detail you re-check on the model card every time you switch.

  答题要点

  • 这类模型用问句与段落的成对数据训练，前缀是区分两种角色的标记，缺了就落在训练分布之外。
  • 不加前缀不会报错，只会整体掉分，属于静默失效。
  • 唯一可靠的发现方式是拿一份标注问题集跑 A/B 对比命中率。
  • 更隐蔽的错法是两边前缀不一致或用了同一个前缀，看起来更正常但对齐是错的。
  • 前缀应封装在 embed 的调用约定里；换模型必须重读模型卡片，它不是普遍规则。

  Key points

  • These models are trained on question-passage pairs; the prefix marks which role a text plays, and omitting it puts you off-distribution.
  • Skipping prefixes never errors, it only degrades quality, so the failure is silent.
  • The reliable detection is an A/B run over a small labelled question set, comparing hit rate.
  • A subtler bug is mismatched or identical prefixes on both sides, which looks healthier but misaligns queries and documents.
  • Keep prefixes inside the embedding call convention, and re-read the model card whenever you switch models.
• 向量检索能完全取代关键词检索吗？举一个向量必然失手的查询，并说说你会怎么补。Can vector search fully replace keyword search? Give a query where vectors are bound to fail, and say how you would fix it.

  国内高频海外高频进阶#hybrid-search#embeddings#retrieval-failure

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

  1. 这题是典型的「立场题」，答「能」或「不能」都不重要，重要的是你能不能举出一个具体到能复现的反例。举不出例子，前面说得再漂亮也会被判成没做过。
  2. 先给失手的类型，一次给全：错误码与状态码（429、E1032）、版本号与型号（v2.3.1、X20 Pro）、人名与工号、订单号与文档编号、以及否定表达。前四类的共同点是**这些词的价值在于字面唯一，而向量只保留语义邻近**，模型会把 429 和「限流」「超时」这些话题相近的东西编到一起，反而把真正写着 429 的那篇挤下去。
  3. 拿一个能复现的例子说：问「限流超了返回 429 吗」，BM25 稳稳命中写着 429 的接口文档，向量却可能把话题相近但没提 429 的产品手册排在前面。这个现象在本课第 2 天的实验里就能亲眼看到。
  4. 否定表达要单独强调：「支持导出 PDF」和「不支持导出 PDF」在向量空间里几乎重合，因为它们谈的是同一件事。指望向量区分肯定与否定一定翻车，这一层要靠生成侧读原文来判断。
  5. 怎么补：两路并行跑再融合，关键词一路用 BM25、向量一路用最近邻，用倒数排名融合把两个名次合成一个。这就是混合检索，本课第 9 天展开。要点是**两套的错法不一样**，所以合起来才有增益——如果两套错在同一批查询上，融合是白做的。
  6. 可预期的追问：那关键词一路能不能扔掉、改成让模型改写查询？可以缓解一部分（第 10 天的查询改写），但改写救不了字面唯一的标识符——你没法把 429 改写成别的说法。

  How to reason about it · think before answering

  1. This is a stance question where the stance matters less than the counter-example. Without a concrete, reproducible failing query, the rest of the answer reads as theory.
  2. Enumerate the failure classes up front: error and status codes, version numbers and SKUs, names and employee IDs, order or document identifiers, and negation. The first four share one property: their value lies in exact literal identity, which embeddings deliberately blur into semantic neighbourhoods.
  3. Give a reproducible example: ask whether rate limiting returns 429. BM25 lands on the API document that literally contains 429, while vector search may rank a topically similar product manual that never mentions the code.
  4. Call out negation separately: 'supports PDF export' and 'does not support PDF export' sit almost on top of each other because they discuss the same thing. Vectors cannot carry that distinction; the generation step reading the source has to.
  5. The fix: run both retrievers and fuse the rankings, BM25 on the lexical side and nearest neighbour on the vector side, combined with reciprocal rank fusion. That is hybrid search, covered on day 9. Fusion helps precisely because the two systems fail on different queries.
  6. Expected follow-up: could you drop the keyword path and rewrite queries instead? Rewriting helps with vocabulary mismatch, but it cannot rescue exact identifiers, since there is no paraphrase of 429.

  答题要点

  • 不能取代：错误码、版本号、人名、单号这类词的价值在于字面唯一，向量只保留语义邻近。
  • 具体反例：问「限流超了返回 429 吗」，BM25 命中写着 429 的文档，向量把话题相近却没提 429 的文档排前面。
  • 否定表达是另一类失手：肯定句与否定句在向量空间里几乎重合。
  • 补法是混合检索：两路并行再用倒数排名融合合并名次。
  • 融合有增益的前提是两套的错法不同；查询改写能缓解词汇不匹配，但救不了字面唯一的标识符。

  Key points

  • No: codes, version numbers, names and IDs matter as exact literals, which embeddings blur into neighbourhoods.
  • Concrete example: asking whether rate limiting returns 429, where BM25 hits the document containing 429 and vectors surface a topically similar one that never mentions it.
  • Negation is a second failure class, since affirmative and negative statements sit almost on top of each other.
  • The remedy is hybrid retrieval: run both paths and merge with reciprocal rank fusion.
  • Fusion pays off because the two paths fail differently; query rewriting helps vocabulary mismatch but not exact identifiers.

D3 文档进来这一关：PDF 与 HTML 解析、表格与扫描件、清洗规则和必须留下的元数据

• 一份 PDF 解析出来的文字顺序是乱的，你会怎么排查和修复？The text extracted from a PDF comes out in the wrong order. How do you diagnose and fix it?

  国内高频海外高频进阶#pdf-parsing#ingestion#data-quality

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

  1. 这题在考你有没有真的动手解析过 PDF。区分度在第一句：能不能说出「PDF 里根本没有阅读顺序」这个前提。答不出这句的人，后面只会说「换个库试试」。
  2. 先给排查顺序：把抽出来的文本片段连同页码、坐标、字号一起打印出来，别只看拼好的字符串。乱序的原因几乎都藏在坐标里，看纯文本永远看不出来。
  3. 然后按现象分三类。左右两栏一行一行地交替，是多栏没识别；同一段话被拆成很多短片段且 y 值有回跳，是内容流按绘制顺序写的；文字整体没问题但夹着重复出现的短句，那不是乱序，是页眉页脚没剔。
  4. 修法对应着来：多栏就重建阅读顺序——把每页文字块的左边界排序找最大空隙当分栏线，再按「栏号、y 从大到小、x 从小到大」重排；页眉页脚按固定的 y 值带切掉，并打印剔除条数确认没误伤。
  5. 补一条能证明你在生产里干过的话：修完要有可回归的判据，不能靠肉眼。用乱序疑似度——顺着排好的顺序走一遍，统计「同栏内往回跳」和「从右栏跳回左栏」的比例，它不需要标准答案，可以挂进流水线天天跑。
  6. 可预期的追问：多栏识别错了怎么办？回答分两头——把分栏判定做保守（空隙不够宽、或者一侧内容占比太低就按单栏处理），并且让断言在双栏被误判成单栏时同样会报警，宁可漏修也不要悄悄改错。

  How to reason about it · think before answering

  1. This checks whether you have actually parsed a PDF yourself. The first sentence is the differentiator: a PDF has no reading order at all, only drawing instructions with coordinates.
  2. Start with the diagnostic step: dump the extracted fragments together with page, x, y and font size instead of looking at the concatenated string. The cause is always in the coordinates.
  3. Then classify the symptom. Lines alternating between left and right means multi-column layout was not detected. Fragments with y jumping backwards means the content stream was written in drawing order. Clean text sprinkled with a repeated short line is not disorder at all, it is a header or footer that was never stripped.
  4. Match the fix to the symptom. For columns, rebuild the order: sort the left edges of the fragments on each page, take the widest gap as the column boundary, then sort by column, then y descending, then x ascending. For headers and footers, cut fixed bands at the top and bottom and print how many fragments you dropped so you can confirm you did not cut into the body.
  5. Add the production-grade part: the fix needs a regression signal, not an eyeball check. Compute an out-of-order score by walking the sorted fragments and counting backward jumps within a column plus right-to-left column jumps. It needs no ground truth, so it can run on every ingest.
  6. Expected follow-up: what if column detection is wrong? Keep the detector conservative, treating a narrow gap or a lopsided split as single column, and make sure the assertion still fires when a two-column page is misread as one. Missing a fix is better than silently corrupting the order.

  答题要点

  • 前提先说清：PDF 只存「在某页某坐标画某段文字」，段落和阅读顺序都是解析时推出来的。
  • 排查时把片段连同页码、坐标、字号一起打印，纯文本看不出乱序的原因。
  • 三种典型成因：多栏没识别、内容流按绘制顺序写、页眉页脚没剔除。
  • 多栏的修法是找最大 x 空隙定分栏线，再按「栏号、y 降序、x 升序」重排。
  • 修完要有不依赖标准答案的回归指标，比如乱序疑似度，能挂进摄取流水线。

  Key points

  • State the premise: a PDF stores only drawing instructions, so paragraphs and reading order are inferred, not read.
  • Debug by dumping fragments with page, coordinates and font size; plain text hides the cause.
  • Three common causes: undetected multi-column layout, content stream written in drawing order, and headers or footers left in.
  • Fix columns by finding the widest gap between left edges and sorting by column, then y descending, then x ascending.
  • Add a ground-truth-free regression metric such as an out-of-order score so the fix stays fixed.
• 文档解析阶段应该保留哪些元数据？少了其中某一项会在哪个环节出问题？Which metadata should a document parsing stage preserve, and which downstream feature breaks if you drop each one?

  国内高频海外高频进阶#metadata#ingestion#access-control

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

  1. 这题最容易答成列清单。区分度不在你能列出几个字段，而在能不能给每个字段配一个具体的下游功能——列了八个字段却说不出谁在用，等于没设计过。
  2. 用一条判据把字段选出来：删掉之后还能不能从原件重新恢复。不能恢复的，解析时就必须留；能恢复的（比如格式、空白）可以放心丢。
  3. 然后一一对应地说：块编号支撑可验证的引用，没有它引用就只能靠模型自觉；标题路径支撑「这句话出自哪一节」和按结构切块；页码支撑引用精确到页；权限标签支撑检索层过滤；更新时间支撑材料冲突时的取舍；内容指纹支撑增量同步。
  4. 挑两个讲透代价。权限标签少了，等到要做访问控制时只能全量重新解析一遍；更糟的是有人会图省事在生成阶段过滤，那等于内容已经进了上下文，泄露已经发生。
  5. 内容指纹少了，每次同步都是全量重建：重新解析、重新切块、重新向量化。一份几千篇的知识库每天重算一次，光 embedding 的账单就够说服任何人。
  6. 可预期的追问：字段拿不准要不要留怎么办？答保守——存储是整条链路上最便宜的一环，加一个字段的代价远小于重跑一次全量解析。

  How to reason about it · think before answering

  1. The trap here is answering with a bare list. The differentiator is pairing every field with a concrete downstream feature. Listing eight fields without naming who consumes them shows you never designed one.
  2. Give the selection rule first: can this be recovered from the original file later? If not, it must be captured at parse time. Formatting and whitespace can be dropped because the original still has them.
  3. Then map fields to consumers: a stable chunk id makes citations verifiable, a heading path tells the user which section a sentence came from and enables structure-aware chunking, page numbers make citations land on the right page, an access-control label enables filtering inside retrieval, an updated-at date resolves conflicting sources, and a content hash enables incremental sync.
  4. Take two of them all the way to cost. Without the access label you must re-parse the whole corpus when access control lands, and worse, people work around it by filtering at generation time, which means the content already reached the context and the leak already happened.
  5. Without a content hash, every sync is a full rebuild: re-parse, re-chunk, re-embed. For a few thousand documents synced daily, the embedding bill alone settles the argument.
  6. Expected follow-up: what about a field you are unsure of? Be conservative. Storage is the cheapest part of the pipeline, and adding a field costs far less than re-running a full parse.

  答题要点

  • 判据是「删了还能不能从原件恢复」，不能恢复的必须在解析时留下。
  • 块编号服务于可验证的引用，标题路径服务于定位与按结构切块，页码服务于引用精确到页。
  • 权限标签必须在解析时打上，否则做访问控制时要全量重解析，且容易被错误地放到生成阶段过滤。
  • 更新时间用于材料冲突时并列两种说法，内容指纹用于增量同步，少了它每次都要全量重建。
  • 拿不准就保守保留：加一个字段的成本远低于重跑一次全量解析。

  Key points

  • The rule is recoverability: if it cannot be recovered from the original later, capture it at parse time.
  • Chunk ids back verifiable citations, heading paths back localisation and structure-aware chunking, page numbers make citations land precisely.
  • Access-control labels must be attached during parsing, otherwise enabling ACL means re-parsing everything, and teams end up filtering at generation time where the leak has already occurred.
  • Updated-at lets you present conflicting sources side by side; a content hash enables incremental sync instead of full rebuilds.
  • When unsure, keep the field: storage is far cheaper than a full re-parse.

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

• 你怎么决定切块大小？说出你会看的两个指标和一个反例。How do you decide on chunk size? Name two metrics you would look at, and one counterexample.

  国内高频海外高频进阶#chunking#evaluation

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

  1. 这题的题眼是「怎么决定」，不是「多大合适」。答一个具体数字（512 token、1000 字符）就已经输了——面试官想看的是你有没有一套定法，而不是你记得住哪个默认值。
  2. 先把矛盾摆出来：块大则信噪比低、上下文贵，块小则单块缺语境、模型答不出所以然。切块大小就是在这两头之间找位置，所以两个指标必须分别对应这两头。
  3. 第一个指标是检索侧的命中率——答案文档有没有进上下文。第二个是生成侧的可用性，最省事的代理指标是切碎率，也就是有多少块结尾停在半句话上；再往前一步就是忠实度和引用是否可定位。
  4. 关键补一句：两个指标必须在**同一个 token 预算**下比，不能按「取前 k 块」比。k 固定时块越大塞进去的字越多，大块切法会赢在买得多而不是切得准上。这一句往往是这道题的区分点。
  5. 反例要具体。最好用的一个是：把块从 400 字调到 1200 字，命中率不降反升——但那是因为一整篇短文档被当成一块塞了进去，检索其实什么都没做，等于退化成了全文投喂。指标涨了，系统更差了。
  6. 可预期的追问是「那你第一次上手时从哪个数字起步」。答：先按文档类型选切法（有标题层级就按结构切），块长从 300 到 500 字起步、重叠取一到两成，然后立刻建一组标准问题跑评估，用两三轮迭代把它调到位。起步值是起步值，不是结论。

  How to reason about it · think before answering

  1. The question is about method, not about a number. Answering with a specific default (512 tokens, 1000 characters) already loses it — the interviewer wants to hear that you have a procedure.
  2. State the tension first: large chunks dilute the signal and cost context; small chunks lose the surrounding meaning so the model cannot use them. The two metrics you name should map onto those two failure modes.
  3. Metric one is retrieval-side hit rate: did a document that actually answers the question make it into the context. Metric two is generation-side usability, cheaply proxied by the fraction of chunks that end mid-sentence, and more seriously by faithfulness and whether citations resolve.
  4. Add the point that separates candidates: both metrics must be compared under the same token budget, never under a fixed top-k. With fixed k, bigger chunks simply buy more text and win for the wrong reason.
  5. Make the counterexample concrete: raising chunk size from 400 to 1200 characters can lift hit rate purely because whole short documents now fit in one chunk, which means retrieval stopped doing anything and you are back to stuffing full documents. The metric improved while the system got worse.
  6. Expect the follow-up: where do you start on day one. Pick the strategy from the document type first (structural splitting whenever headings exist), start around 300 to 500 characters with 10 to 20 percent overlap, then build a golden set immediately and iterate. A starting point is not a conclusion.

  答题要点

  • 先按文档类型选切法，再调长度：有标题层级就按结构切，没有结构才谈固定长度或语义。
  • 看两个指标：检索侧的命中率，生成侧的切碎率（进一步是忠实度与引用可定位性）。
  • 两个指标必须在同一个 token 预算下比，不能按「取前 k 块」比，否则大块只是买得更多。
  • 反例：块调大后命中率上升，但那是因为整篇被当成一块，检索退化成全文投喂。
  • 起步值 300 到 500 字、重叠一到两成，然后靠一组固定问题迭代，不靠直觉定稿。

  Key points

  • Choose the strategy from the document type first, then tune length: split on headings whenever the structure survives parsing.
  • Watch two metrics: retrieval hit rate on one side, mid-sentence break rate (then faithfulness and citation resolvability) on the other.
  • Compare under an equal token budget, never a fixed top-k, or larger chunks win by buying more text.
  • Counterexample: hit rate rises after enlarging chunks because whole documents now fit in one chunk and retrieval has effectively stopped working.
  • Start near 300 to 500 characters with 10 to 20 percent overlap, then iterate against a fixed question set instead of guessing.
• 父子切块的收益是什么？它在什么情况下反而会拖慢系统？What does parent-child chunking buy you, and when does it slow the system down instead?

  国内高频海外高频进阶#chunking#parent-child

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

  1. 这题考的是你有没有意识到「检索单位」和「上下文单位」可以是两个东西。答不出这句话，后面说什么都是复述。
  2. 收益一句话说清：小块进索引，信噪比高、容易被找到；命中之后顺着父指针把整节回填给模型，语境完整。精度和完整度这次不用二选一。
  3. 拖慢的场景要从代价一条条推。第一条是上下文预算：每命中一个新子块可能拖进来一整个父节，同样的 token 预算装不下几条，检索结果的多样性反而变差。
  4. 第二条是写入侧：父子两套都要维护，文档更新时两边都要重算，块 id 的稳定性也更难保证，增量同步的复杂度明显上升。
  5. 第三条是收益消失的条件：当文档本身的小节就不长时，父块和子块差不多大，你付了两套索引的钱，什么也没多买到。所以父子切块适合长节、深层级的文档，不适合结构本来就细碎的知识库。
  6. 可预期的追问是「那和直接把块切大有什么区别」。答：切大是把噪声一起放进索引，父子是只把噪声放进上下文、不放进索引——被检索的那一段始终是干净的短文本，这是本质区别。

  How to reason about it · think before answering

  1. This question checks whether you know that the retrieval unit and the context unit can be two different things. Without that sentence, everything else is recitation.
  2. State the benefit compactly: small chunks go into the index so they are easy to match, and once a child is hit you follow the parent pointer and hand the model the whole section. You stop trading precision against completeness.
  3. Derive the slowdown from the costs. First, the context budget: every new child may drag in an entire parent, so an equal budget holds fewer distinct pieces and result diversity drops.
  4. Second, the write path: two levels to maintain, both recomputed on every document update, and chunk ids become harder to keep stable, which makes incremental sync noticeably more complex.
  5. Third, the condition under which the benefit disappears: when sections are already short, the parent and the child are nearly the same text, so you paid for two indexes and bought nothing. Parent-child suits long sections and deep hierarchies, not already fine-grained knowledge bases.
  6. Expect the follow-up: how is this different from simply using bigger chunks. Bigger chunks put the noise into the index; parent-child puts the noise only into the context. What gets matched stays short and clean.

  答题要点

  • 核心是把检索单位和上下文单位拆开：小块负责被找到，大块负责被读懂。
  • 收益是精度与完整度同时拿到，不用在信噪比和语境之间二选一。
  • 代价一：一次命中可能拖进整个父节，同样的上下文预算装得下的条数变少，结果多样性下降。
  • 代价二：父子两套索引都要维护与重算，文档更新时增量同步的复杂度明显上升。
  • 失效场景：文档小节本来就短时父子块差不多大，多付一套成本却没多买到东西。

  Key points

  • The core idea is decoupling the retrieval unit from the context unit: small chunks get found, large chunks get understood.
  • The payoff is precision and completeness at the same time instead of trading one for the other.
  • Cost one: a single hit can drag in a whole parent, so an equal context budget holds fewer distinct results and diversity suffers.
  • Cost two: two index levels to maintain and recompute, which makes incremental sync on document updates considerably harder.
  • It stops paying off when sections are already short, because parent and child are nearly identical and you bought nothing for the extra cost.

D5 向量索引与库选型：HNSW 与倒排文件、量化省内存、带过滤的查询与多租户隔离

• 分层可导航小世界图和倒排文件索引你会怎么选？各说一个必须选它的场景，以及各自最该调的参数。How do you choose between an HNSW index and an IVFFlat index? Give one scenario that forces each choice, and name the parameter you would tune first in each.

  国内高频海外高频进阶#vector-index#hnsw#ivfflat

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

  1. 这题的区分度不在能不能背出两种结构，而在你会不会给出触发条件。只说「HNSW 快、IVFFlat 省内存」的人一抓一大把，面试官等的是「什么情况下我必须选另一个」。
  2. 先用两句话把结构说清：HNSW 是分层的邻居图，查询从稀疏的上层跳到稠密的下层，逐步逼近；IVFFlat 是先聚类成若干个列表，查询时只在最近的几个列表里扫。一个是图上导航，一个是分区搜索。
  3. 再把参数对应上去：HNSW 建图有 m 与 ef_construction，查询有 ef_search；IVFFlat 建索引有 lists，查询有 probes。**先调查询侧参数**，因为它不用重建索引、能逐次查询调整，是唯一一个上线之后还能动的旋钮。
  4. 给两个反向的必须场景：数据分钟级高频写入、且内存和建索引窗口都紧张时必须选 IVFFlat，因为 HNSW 的图会持续膨胀、重建代价高；反过来，数据相对静态、查询延迟有硬性 SLA 时必须选 HNSW，因为同等召回下它的延迟更低。
  5. 补一条容易被忽略的工程细节：IVFFlat 的聚类是建索引那一刻的数据决定的，数据分布漂移之后召回会悄悄下滑，所以它需要一条定期重建的运维流程；HNSW 没有这个包袱，但它的索引往往比表本身还大。
  6. 可预期的追问：probes 和 ef_search 的默认值分别是多少？答 1 和 40，并且要主动说出 IVFFlat 默认 probes = 1 意味着只看一个列表，建完索引不设 probes 基本等于没调过——这是新手最常见的事故。

  How to reason about it · think before answering

  1. The differentiator is not describing both structures, it is naming the condition that forces one over the other. Saying 'HNSW is faster, IVFFlat is cheaper' is what everyone says.
  2. Describe the structures in one line each: HNSW is a layered neighbour graph you navigate from sparse upper layers down to dense lower ones; IVFFlat clusters vectors into lists and only scans the lists closest to the query.
  3. Map the knobs: HNSW builds with m and ef_construction and queries with ef_search; IVFFlat builds with lists and queries with probes. Tune the query-side knob first, because it needs no rebuild and is the only one you can still move after launch.
  4. Give two forcing scenarios in opposite directions. Minute-level write traffic with tight memory and a short build window forces IVFFlat, since an HNSW graph keeps growing and is expensive to rebuild. A largely static corpus with a hard latency SLA forces HNSW, since it hits the same recall at lower latency.
  5. Add the operational detail people forget: IVFFlat clusters reflect the data at build time, so recall degrades silently as the distribution drifts and you need a scheduled rebuild. HNSW avoids that but its index is often larger than the table.
  6. Expected follow-up: what are the defaults? probes is 1 and ef_search is 40. Volunteer that leaving probes at 1 means scanning a single list, which is the single most common IVFFlat mistake.

  答题要点

  • HNSW 是分层邻居图，IVFFlat 是先聚类再局部扫描；前者查询质量优先，后者建索引与内存开销优先。
  • 先调查询侧参数：HNSW 调 ef_search，IVFFlat 调 probes，两者都不需要重建索引。
  • 高频写入、内存与建索引窗口紧张选 IVFFlat；数据相对静态、延迟有硬性要求选 HNSW。
  • IVFFlat 的聚类会随数据漂移失真，需要定期重建；HNSW 没这个问题但索引常常比表还大。
  • 默认值要记住：probes 是 1、ef_search 是 40，建完索引不调 probes 等于没用上索引的能力。

  Key points

  • HNSW is a layered neighbour graph; IVFFlat clusters first and scans a subset of lists. HNSW favours query quality, IVFFlat favours build cost and memory.
  • Tune the query-side knob first: ef_search for HNSW, probes for IVFFlat. Neither needs a rebuild.
  • Heavy write traffic with tight memory and build windows points to IVFFlat; a static corpus with a hard latency SLA points to HNSW.
  • IVFFlat clusters drift with the data and need scheduled rebuilds; HNSW does not, but its index is often larger than the table.
  • Know the defaults: probes 1, ef_search 40. Leaving probes at 1 wastes the index.
• 把向量从全精度换成半精度或二值量化，你会用什么方法确认召回没有明显下降？If you switch your vectors from full precision to half precision or binary quantisation, how do you verify that recall has not dropped materially?

  国内高频海外高频进阶#quantization#evaluation#recall

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

  1. 这题表面问量化，实际问的是你会不会做评估。只回答「跑几个问题看看结果对不对」的人会被直接判为没做过——面试官想听的是一套可复现的量法。
  2. 先把真值这件事说死：真值必须来自暴力全量比对，也就是把索引关掉、全表算距离取前 k。拿索引结果当真值是最常见的自欺，因为那样量出来的召回永远接近 100%，你会以为量化无损。
  3. 然后给流程：固定一批查询（几十条起步，覆盖长短查询和不同主题），先用全精度算出真值，再换量化重跑，计算召回率@k。同时记录三件事——索引大小、建索引耗时、查询延迟的中位数与 p95，只报召回是不够的。
  4. 补一条判据：量化损失有多大取决于向量分布，别人的数字不能抄。稀疏向量对二值量化尤其不友好，因为二值化只保留符号位，零和负数会被压成同一个值，信息几乎被抹平。所以换方案必须在自己的数据上重新量一次。
  5. 结论要给可操作的建议：半精度通常近乎无损，还能把建索引维度上限从 2000 提到 4000，是默认可以先上的一档；二值量化损失明显，标准用法是拿它粗筛一批候选，再用原始向量在这一小批里精排，粗筛窗口越宽召回补得越多、延迟也越高。
  6. 可预期的追问：召回掉了多少算可以接受？答这取决于下游——后面还有重排时，粗排召回掉两三个点通常无感；如果检索结果直接进提示词，掉一个点就意味着每一百次回答里多一次缺材料。要把这个判断挂到业务指标上，而不是拍一个阈值。

  How to reason about it · think before answering

  1. The question looks like it is about quantisation, but it is really about whether you know how to evaluate. Answering 'try a few queries and eyeball it' fails immediately.
  2. Pin down ground truth first: it must come from an exhaustive scan with the index disabled. Using index results as ground truth is the classic self-deception, because recall then looks close to 100% no matter what you changed.
  3. Give the procedure: fix a query set of at least a few dozen covering short and long queries across topics, compute ground truth at full precision, rerun with the quantised representation, and report recall at k. Report index size, build time, and median plus p95 latency alongside it, because recall alone is not a decision.
  4. Add the judgement rule: quantisation loss depends on your vector distribution, so published numbers do not transfer. Sparse vectors suffer badly under binary quantisation because only the sign bit survives and zeros collapse together.
  5. Land on something actionable: half precision is usually near lossless and raises the indexable dimension ceiling from 2000 to 4000, so it is a safe first step. Binary quantisation loses real recall and should be used as a cheap first pass, re-ranked with the original vectors over a wider candidate window.
  6. Expected follow-up: how much loss is acceptable? It depends on what comes next. With a re-ranker downstream, a couple of points off first-stage recall is usually invisible; if retrieval feeds the prompt directly, one point means one more unanswerable question per hundred. Tie the threshold to a product metric, not to a number you made up.

  答题要点

  • 真值必须来自关掉索引的暴力全量比对，拿索引结果当真值会让召回永远接近 100%。
  • 固定一批查询，量化前后跑同一批，报召回率@k，同时报索引大小、建索引耗时和延迟分位数。
  • 量化损失取决于向量分布，别人的数字不能抄，必须在自己的数据上重新量。
  • 半精度通常近乎无损，还能把索引维度上限从 2000 提到 4000，可以作为默认第一档。
  • 二值量化损失明显，正确用法是粗筛加原始向量重排，粗筛窗口越宽召回补得越多、延迟越高。

  Key points

  • Ground truth must come from an exhaustive scan with indexes disabled; using index output as truth pins recall near 100%.
  • Run one fixed query set before and after, report recall at k together with index size, build time and latency percentiles.
  • Quantisation loss depends on your own vector distribution, so measure it on your data instead of quoting benchmarks.
  • Half precision is usually near lossless and raises the indexable dimension limit from 2000 to 4000, making it a safe default.
  • Binary quantisation loses real recall; use it as a cheap first pass and re-rank with the original vectors over a wider window.
• 什么时候应该把向量搬出 PostgreSQL？给出可量化的触发条件，也说说不该搬的理由。When should you move your vectors out of PostgreSQL into a dedicated vector database? Give measurable triggers, and also make the case for staying.

  国内高频海外高频进阶#vector-database#architecture#trade-offs

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

  1. 这题考的是工程判断，不是技术偏好。开口就说「专用向量库更专业」的人会被追问到答不上来；面试官想看的是你有没有把迁移成本算进去。
  2. 先给默认立场并给出理由：第一版留在 PostgreSQL，因为事务、备份、时间点恢复、权限、跟业务表 JOIN 和现成的运维工具全是白送的。多一个数据库就多一份同步、一份一致性问题、一份值班负担，这些成本很少被写进选型文档。
  3. 然后给四条可量化的触发线：数据量（判据不是行数而是索引还塞不塞得进内存）、写入频率（分钟级流式更新会让聚类失真、让图持续膨胀）、过滤复杂度（十几个属性的任意组合让部分索引和分区都排列组合不过来）、团队运维能力（没人愿意长期照看第二个数据库，前三条再成立也别搬）。
  4. 第三条要展开一点，因为它最常是真正的原因：专用向量库把过滤做进了索引结构本身，而不是扫完索引再筛，所以在复杂过滤下天然占优。把这一点说出来，说明你理解的是机制而不是口碑。
  5. 还要主动给一条常被忽略的替代路径：很多「向量检索不够用」的问题，真正的解法是混合检索加重排，而不是换数据库。先把关键词一路加回来、把重排接上，再决定要不要搬——顺序搞反了会白搬一次。
  6. 可预期的追问：真要搬怎么迁？答分三步——先双写并在影子流量上比对两边的召回与延迟，再把读流量按比例切过去，最后才停掉旧路径。中间任何一步指标不达标就停下，这比一次性切换安全得多。

  How to reason about it · think before answering

  1. This tests engineering judgement, not tooling preference. Opening with 'dedicated vector databases are better' invites follow-ups you cannot answer.
  2. State the default position and justify it: keep the first version in PostgreSQL, because transactions, backups, point-in-time recovery, permissions, joins with business tables and the tooling your team already knows all come free. A second datastore adds synchronisation, a consistency surface and an on-call burden that selection documents rarely price in.
  3. Then give four measurable triggers: data volume (the test is whether the index still fits in memory, not the raw row count), write frequency (minute-level streaming updates distort clusters and inflate graphs), filter complexity (arbitrary combinations of a dozen attributes defeat both partial indexes and partitioning), and operational capacity.
  4. Expand on filter complexity, because it is most often the real reason: dedicated vector databases push filtering into the index structure instead of applying it after the scan, which is a mechanical advantage rather than a reputational one.
  5. Volunteer the alternative people skip: many 'vector search is not good enough' problems are actually solved by hybrid retrieval plus re-ranking, not by a new database. Add the keyword path and a re-ranker first, then decide.
  6. Expected follow-up: how would you migrate? Dual-write, compare recall and latency on shadow traffic, shift read traffic gradually, and only then retire the old path. Stop at any step where the metrics regress.

  答题要点

  • 默认留在 PostgreSQL：事务、备份、恢复、权限、JOIN 和现成运维都是白送的，多一个库就多一份同步与值班成本。
  • 触发线一是数据量，判据是索引还塞不塞得进内存，而不是行数本身。
  • 触发线二是写入频率，分钟级流式更新会让聚类失真、让图持续膨胀。
  • 触发线三是过滤复杂度，专用库把过滤做进索引结构，复杂过滤下有机制上的优势。
  • 触发线四反过来看：没有长期运维第二个数据库的人手，前三条成立也不该搬；很多问题的真正解法是混合检索加重排。

  Key points

  • Default to staying in PostgreSQL: transactions, backups, recovery, permissions, joins and familiar tooling are free, and a second store adds sync and on-call cost.
  • Trigger one is data volume, measured by whether the index still fits in memory rather than by row count.
  • Trigger two is write frequency: minute-level streaming updates distort clusters and inflate graphs.
  • Trigger three is filter complexity: dedicated stores push filtering into the index structure, a mechanical advantage under complex predicates.
  • Trigger four cuts the other way: without people to run a second database, do not move even if the first three hold. Often hybrid retrieval plus re-ranking is the real fix.

D6 生成这一侧：上下文怎么排、引用怎么标、什么时候必须拒答，以及流式回答

• 怎么让模型的引用是真的而不是编的？说出一个不依赖模型自觉的方案。How do you make sure a model's citations are real rather than fabricated? Describe a scheme that does not rely on the model behaving well.

  国内高频海外高频进阶#citation-verification#grounding#hallucination

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

  1. 题眼在「不依赖模型自觉」这半句。回答里只要出现「在提示词里强调请确保引用准确」，这题就答砸了——面试官问的正是提示词管不住的那部分。
  2. 先把问题拆成两半：引用要能验证，前提是它是一个**闭集里的符号**，不是一段自由文本。所以第一步是组装上下文时给每块材料一个编号，提示词里明确只能引用发出去的编号。让模型写「根据《某某手册》」是没法验证的，标题是它可以随口生成的字符串。
  3. 第二步是事后核对，两道闸缺一不可。第一道查编号存在性：发出去的是 1 到 5，出现 8 就一定是编的，一行代码判掉。第二道查实质重合：编号是真的、内容却对不上，这类更隐蔽，要算这句话的词元有多大比例能在被引块原文里找到，低于阈值判不通过。
  4. 算重合度时有个坑要主动说出来：先剔掉在多数块里都出现的高频词元，否则「文件」「系统」这种词会让随便哪一块都及格。这跟 BM25 用逆文档频率压常见词是同一个道理。
  5. 校验不过怎么办：把具体原因写成反馈打回去重生成一次，只给一次机会；连着两版都编说明材料本来就不支持，该走拒答而不是第三次重试。另外校验必须拿原文比对，不能拿压缩或改写过的材料比对，否则「校验通过」保证不了用户点开看到的东西。
  6. 可预期的追问：为什么不让模型自己再检查一遍？因为自检和生成是同一个模型的同一种倾向，它对自己编的东西没有独立信息源；而编号核对是一个确定性判断，成本几乎为零、结果可复现，这两点自检都做不到。

  How to reason about it · think before answering

  1. The phrase to catch is 'not relying on the model behaving well'. Any answer that boils down to 'tell the model to be accurate in the prompt' fails, because the prompt is exactly the part that cannot enforce this.
  2. Split the problem in two. Verifiability requires that a citation be a symbol from a closed set, not free text. So step one is numbering the blocks at assembly time and telling the model it may only cite the numbers it was given. 'According to the storage handbook' cannot be checked, because the title is a string the model can invent.
  3. Step two is post-hoc checking, with two gates. Gate one is existence: you handed out 1 through 5, so an 8 is fabricated, and that is a one-line check. Gate two is substantive overlap, which catches the sneakier case where the number is real but the block says something else. Measure what fraction of the sentence's terms appear in the cited block and reject below a threshold.
  4. Mention the trap in the overlap metric: drop terms that appear in most blocks first, otherwise generic words let any citation pass. It is the same reasoning behind inverse document frequency in BM25.
  5. On failure, feed the specific reason back and regenerate once, not repeatedly. Two fabricated drafts in a row means the material does not support the question, so refuse instead. Also verify against the original chunk text, never against a compressed or rewritten version, otherwise 'verified' says nothing about what the user sees.
  6. Expected follow-up: why not ask the model to self-check? Self-checking shares the generator's bias and has no independent source of truth, whereas number checking is deterministic, essentially free, and reproducible.

  答题要点

  • 引用必须是块编号这种闭集符号，不能是自由文本的文档标题——可验证性来自闭集，不来自措辞。
  • 两道闸：编号存在性，以及这句话与被引块原文的实质重合度，后者才拦得住「编号是真的、内容对不上」。
  • 算重合度前剔掉在多数块里都出现的高频词元，否则随便引哪一块都能及格。
  • 校验不过就带着具体原因打回重生成一次，只给一次机会，两版都编就转拒答。
  • 校验对象必须是用户能点开看到的原文，不是压缩或改写后的材料。

  Key points

  • Citations must be closed-set symbols such as block numbers, not free-text titles: verifiability comes from the closed set, not from wording.
  • Two gates: the number must exist, and the sentence must substantively overlap the cited block's original text, which is what catches real-number-wrong-content fabrication.
  • Strip terms that occur in most blocks before scoring overlap, or any citation will pass.
  • On failure, regenerate once with the concrete reason fed back; two bad drafts means refuse instead.
  • Always verify against the original text the user can open, never against a compressed or rewritten copy.

D7 第一周综合：把六天的零件装成一个可一键启动的检索问答服务并复盘

• 摄取链路和查询链路应该共享哪些代码？强行复用会带来什么具体问题？What should the ingestion path and the query path share, and what concretely goes wrong when you over-share?

  国内高频海外高频进阶#architecture#ingestion#retrieval

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

  1. 题眼在「强行」两个字。面试官想看的是你能不能说出复用的边界，而不是背诵「不要重复自己」。
  2. 先说清两条链路的性质差异：摄取是批处理，几十秒跑完，失败重跑一遍就行；查询是在线请求，几百毫秒要出结果，失败用户当场看到。错误处理、超时、并发策略天然不同。
  3. 所以结论是：**共享接口，不共享流程**。两边唯一该共享的是存储层的那个接口，以及 embedding 的函数签名——注意后者共享的是签名和模型选择，不是调用流程。
  4. 给出强行复用的具体症状：抽出来的公共模块里开始出现 isIngest 这类分支，一个改动要同时验证两条链路，最后没人敢动它。
  5. 补一条真正必须一致的东西：给块算向量和给问题算向量必须用同一个模型。这不是复用代码，是复用配置——而且要把模型名写进向量表，否则模型换了没人发现，检索会静默地返回垃圾。
  6. 可预期的追问：那切块逻辑呢？查询侧压根不切块，所以它只属于摄取链路；真要在查询侧用到（比如 D11 的父子回填），走的也是存储层读回大块，不是把切块器搬过来。

  How to reason about it · think before answering

  1. The word to notice is 'over-share'. The interviewer wants the boundary, not a recital of DRY.
  2. Start from how the two paths differ. Ingestion is batch: tens of seconds, and a failure just means rerunning it. Query is online: hundreds of milliseconds, and a failure is visible to the user immediately. Error handling, timeouts and concurrency are simply not the same problem.
  3. Hence the rule: share the interface, not the flow. The only genuinely shared thing is the storage interface, plus the embedding function signature.
  4. Name the symptom of over-sharing: the extracted module fills up with isIngest branches, every change has to be verified on both paths, and eventually nobody dares touch it.
  5. Add the one thing that truly must match: chunks and queries must be embedded by the same model. That is shared configuration, not shared code, and the model name belongs in the vector table so a silent mismatch is detectable.
  6. Expected follow-up: what about chunking? The query path never chunks. Even when it needs a parent block, it reads it back through storage rather than importing the chunker.

  答题要点

  • 共享接口不共享流程：唯一的交界是存储层，加上 embedding 的函数签名。
  • 两条链路的错误处理与延迟约束根本不同，批处理可以重跑，在线请求必须快速失败。
  • 强行复用的症状是公共模块里长出 isIngest 分支，改一次要验两条链路。
  • 必须一致的是模型选择而不是代码：块与查询要用同一个 embedding 模型，并把模型名记进向量表。
  • 切块只属于摄取；查询侧需要大块时通过存储层读回，而不是把切块器搬过去。

  Key points

  • Share the interface, not the flow: storage is the only boundary, plus the embedding signature.
  • The two paths have different error handling and latency budgets; batch can rerun, online must fail fast.
  • Over-sharing shows up as isIngest branches and changes that must be verified twice.
  • What must match is the model choice, not the code: record the model name alongside every stored vector.
  • Chunking belongs to ingestion only; the query path reads larger units back through storage.
• 一个检索问答服务上线前你会做哪三项检查？为什么偏偏是这三项？What three checks would you run before shipping a retrieval QA service, and why those three?

  国内高频海外高频进阶#production-readiness#citations#refusal

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

  1. 这题的区分度不在你能列几项，而在你能不能说清「为什么是这三项」。列十项而每项都不给理由，反而说明你没有排过优先级。
  2. 推导方式是按后果排序：哪种故障用户看不出来、又损失最大，哪一项就该排在前面。
  3. 第一项是引用可查证：每条引用的编号都能回查到真实存在的块，且那一块确实与该句有实质重合。这一项排第一是因为引用错了用户根本发现不了，而它恰恰是这类系统唯一的信任来源。
  4. 第二项是该拒答时真的拒答：构造一个语料里没有答案的问题，看它是回那句拒答话术还是开始编。这一项也属于用户看不出来的故障，且一旦编造被发现，整个系统的可信度归零。
  5. 第三项是摄取到检索的一致性：摄取完之后新文档立刻能被检索到，且关键词与向量两路的覆盖数量对得上。这一项防的是「一路能查一路查不到」这种最难排查的故障。
  6. 可预期的追问：为什么延迟和成本不在前三？因为它们是**看得见**的故障——慢了用户会抱怨，贵了账单会告诉你；而上面三项不检查就永远不会有人告诉你。

  How to reason about it · think before answering

  1. The discriminator is not how many checks you list but whether you can justify the three. Ten items with no ranking suggests you have never had to prioritise.
  2. Derive them by consequence: the failures that are invisible to users and most damaging go first.
  3. First, citations must be verifiable: every cited id resolves to a real chunk, and that chunk genuinely overlaps the sentence citing it. This ranks first because a wrong citation is undetectable by the user, and citations are the only source of trust this system has.
  4. Second, refusal must actually fire: ask a question the corpus cannot answer and confirm the system says so instead of inventing. Also invisible, and one discovered fabrication zeroes out trust in the whole product.
  5. Third, ingestion-to-retrieval consistency: freshly ingested documents are retrievable immediately, and the keyword and vector paths cover the same set. This guards against the 'one route finds it, the other does not' failure, which is the hardest to diagnose.
  6. Expected follow-up: why not latency and cost? Because those failures are visible. Users complain about slowness and the bill reports overspending; nobody will ever report the three above.

  答题要点

  • 先给排序依据：优先检查用户发现不了、但后果最重的故障。
  • 第一项引用可查证：编号能回查到真实的块，且该块与被引的那句话有实质重合。
  • 第二项拒答生效：用一个语料里没有答案的问题验证系统会说查不到，而不是开始编。
  • 第三项摄取与检索一致：新入库的文档立刻可检索，关键词与向量两路覆盖对得上。
  • 延迟和成本重要但排在后面，因为它们是看得见的故障，会自己找上门。

  Key points

  • State the ranking rule first: prioritise failures users cannot see but that cost the most.
  • Check one, verifiable citations: every id resolves to a real chunk that overlaps the sentence citing it.
  • Check two, refusal actually fires on a question the corpus cannot answer.
  • Check three, ingestion and retrieval agree: new documents are immediately retrievable on both routes.
  • Latency and cost matter but rank lower because those failures announce themselves.

D8 评估先行：搭 golden set、算召回与排序指标、用模型当裁判判忠实度

• 让你从零给一个公司知识库的 RAG 系统建评估集，你会怎么做？多少题才算够用？You need to build an evaluation set from scratch for a RAG system over a company knowledge base. How would you do it, and how many questions are enough?

  国内高频海外高频进阶#evaluation#golden-set#rag

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

  1. 这题的区分度在「出题方向」和「规模的理由」两处。开口就说「找几百个用户真实问题」的，多半没真做过——真实问题的答案在哪篇文档里，没人标得出来。
  2. 先给方向：从语料反向出题，打开每一篇读它能回答什么，出题的那一刻答案文档就已经确定了，标注成本几乎为零。反方向（先想问题再找答案）会得到一堆自己都不知道答案的题。
  3. 再给结构：每题记问题、答案文档列表、类型三个字段；类型至少分单文档、多跳、无答案三类，并说明多跳必须全部答案文档命中才算命中，无答案不参与召回率而是考拒答。
  4. 规模的理由要给出来，不能只报一个数字：20 题能把「完全不能用」和「基本能用」分开，够做冒烟；100 到 200 题才有资格判断「涨了两个点」是真的还是噪声。上线之后每次线上出问题就把那个问题补进集合——评估集是长出来的。
  5. 补一句成本与保鲜：出题是人力活，20 题两小时是正常量级；语料更新后要复核答案文档还在不在，否则集合会悄悄腐烂，指标下跌你会误以为是系统坏了。
  6. 可预期的追问是「怎么防止评估集被过拟合」。答案是留一份不参与调优的保留集，并且定期从线上真实问题里补充新题，只用来验收不用来调参。

  How to reason about it · think before answering

  1. The discriminator here is the direction you generate questions in, and whether you can justify a size rather than name one.
  2. Go corpus-first: read each document and write the questions it can answer. The answer document is fixed at authoring time, so labeling is nearly free. Question-first gives you items whose answers nobody can locate.
  3. Give the schema: question, answer document ids, and a type. At minimum three types - single-document, multi-hop, and unanswerable. Multi-hop counts as a hit only when every answer document makes it into the context; unanswerable items are scored on abstention, not recall.
  4. Justify the size: 20 items separate 'broken' from 'usable' and are enough for a smoke gate; 100 to 200 are needed before a two-point delta means anything. Then grow the set - every production failure becomes a new item.
  5. Mention cost and decay: roughly two hours for 20 items, and answer labels must be rechecked whenever the corpus changes, or the set rots and you misread the drop as a system regression.
  6. Expected follow-up: how do you avoid overfitting to the eval set? Keep a held-out slice that never informs tuning, and refresh it from real production questions.

  答题要点

  • 从语料反向出题，出题时答案文档就已确定，标注成本最低。
  • 每题标类型：单文档、多跳、无答案，三类缺一不可。
  • 多跳要求全部答案文档命中；无答案不算召回率，考的是拒答。
  • 20 题够冒烟，100 到 200 题才能判断小幅变化；线上故障持续补题。
  • 留一份不参与调优的保留集，防止对评估集过拟合。

  Key points

  • Author corpus-first so the answer document is known at authoring time.
  • Label every item with a type: single-document, multi-hop, unanswerable.
  • Multi-hop requires all answer documents; unanswerable items score abstention, not recall.
  • 20 items for a smoke gate, 100 to 200 to trust small deltas, and keep growing it from production failures.
  • Hold out a slice that never informs tuning to avoid overfitting the set.
• 召回率、平均倒数排名、归一化折损累计增益，这三个检索指标分别在什么故障下会先掉下来？只盯一个会漏掉什么？Recall, mean reciprocal rank, and normalized discounted cumulative gain - which failure mode does each one catch first, and what do you miss by watching only one?

  国内高频海外高频进阶#retrieval-metrics#evaluation#ranking

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

  1. 这题考的是「知不知道指标之间的盲区」，不是背定义。能把三者按「有没有 / 靠不靠前 / 整体好不好」分层的，基本就答对了一半。
  2. 推导链是这样的：召回率是布尔的——答案文档在不在最终上下文里。它对「压根没捞到」最敏感，但答案从第 1 名掉到第 8 名它一动不动，只要还在预算内。
  3. 倒数排名只看第一条相关结果的名次，所以「答案还在但被挤到后面」它立刻掉。反过来它有个盲区：前十条里有一条命中还是五条命中，它给的分完全一样。
  4. 归一化折损累计增益把前 k 名里每一条相关结果都按名次折算再累加，所以它对「整体排序质量」敏感，是重排最直接的优化目标。它的盲区是不告诉你「有没有」——召回率为零时它也是零，看不出是没捞到还是排得差。
  5. 结论：三个一起看才能定位故障层。召回率掉说明检索或切块出了问题，要动召回策略；召回率不动而倒数排名掉，说明排序退化，该上重排；两者都稳而 nDCG 掉，说明前几名里混进了更多噪声。
  6. 可预期的追问是「指标顶格了怎么办」。真实答案是把题目做难：指标撞天花板说明评估集失去区分度，这时候继续优化系统是在瞎调。

  How to reason about it · think before answering

  1. This tests whether you know each metric's blind spot, not whether you can recite definitions. Layer them as 'did it show up / how high / how good overall' and you are halfway there.
  2. Recall is boolean: is the answer document in the final context. It catches 'never retrieved', but it does not move when the answer slips from rank 1 to rank 8, as long as it still fits the budget.
  3. MRR looks only at the rank of the first relevant hit, so ranking degradation shows up immediately. Its blind spot: one relevant item in the top ten scores exactly the same as five.
  4. nDCG discounts every relevant hit in the top k by its position, so it tracks overall ranking quality and is the direct optimization target for reranking. Its blind spot is existence - it is zero both when nothing was retrieved and when ranking is terrible.
  5. Conclusion: together they localize the failure. Recall drops means retrieval or chunking; recall flat but MRR down means ranking degraded, reach for a reranker; both stable but nDCG down means more noise crept into the top results.
  6. Expected follow-up: what if a metric saturates? Make the questions harder - a saturated metric means the eval set lost its discriminative power, and further tuning is blind.

  答题要点

  • 召回率管「有没有进上下文」，对完全没捞到最敏感，对名次变化不敏感。
  • 平均倒数排名管「第一条排第几」，对排序退化最敏感，但分不清命中一条还是五条。
  • 归一化折损累计增益管「前 k 名整体质量」，是重排的直接优化目标，但看不出有没有。
  • 三者组合才能定位故障在召回层、排序层还是噪声层。
  • 命中口径要说清：按 token 预算装上下文，不是按固定条数取前 k。

  Key points

  • Recall answers 'did it make it into the context', sensitive to total misses, blind to rank shifts.
  • MRR answers 'how high is the first hit', sensitive to ranking degradation, blind to how many hits there are.
  • nDCG answers 'how good is the top k overall', the direct target for reranking, blind to existence.
  • Only the combination localizes the failure to retrieval, ranking, or noise.
  • State the hit criterion: context is packed against a token budget, not a fixed top-k.

D9 混合检索与重排：两路召回、倒数排名融合，再用交叉编码器把前几名重新排一遍

• 混合检索为什么普遍用倒数排名融合，而不是把两路分数归一化之后加权相加？加权那条路在什么情况下会失控？Why do hybrid retrieval systems usually use reciprocal rank fusion instead of normalizing both scores and adding them with weights? When does the weighted approach break down?

  国内高频海外高频进阶#hybrid-search#rank-fusion

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

  1. 这题的题眼在「分数」两个字。只答「RRF 更简单」是背概念，面试官想听的是你知道分数为什么不可比。
  2. 先给量纲差异：BM25 是一堆对数项累加，没有上界，同一套索引里不同查询的第一名可以从 5 分到 50 分；余弦被钉死在负一到正一。两个读数相加没有意义。
  3. 再点出归一化的静默失败：除以本路最高分之后，分母随查询浮动。一个语料里根本没有答案的问题，向量那一路最高分只有 0.09，归一化之后照样是满分 1.0 带权重进融合——你以为在比相关性，其实在比「本路矮子里有多高」。
  4. 然后是权重的维护成本：1 比 0.6 这个配比要靠跑评估调出来，两路是二维搜索，加上多路查询就是四维五维，而且换一个 embedding 模型全部作废。RRF 只有一个 k，而且 60 这个默认值几乎不用动。
  5. 结论：名次是两路唯一可比的东西。RRF 主动扔掉分数，是为了不被不可比的量误导。
  6. 可预期的追问：那 k 是干什么的？答 k 是压平器——k 越大，头几名之间的差距越小，于是「两路都排进前列」比「一路排第一」更有分量，这正是混合检索想要的交叉验证效果。再追问同分怎么办，答必须按文档 id 兜底排序，否则跨次运行名次会飘、评估数字跟着抖。

  How to reason about it · think before answering

  1. The hinge word is `scores`. Answering `RRF is simpler` is reciting a concept; the interviewer wants to hear that you know why the two scores are not comparable in the first place.
  2. Start with scale: BM25 is an unbounded sum of log terms, and on one index the top hit can range from 5 to 50 depending on the query; cosine is pinned between -1 and 1. Adding those two readings is meaningless.
  3. Then name the silent failure of normalization: dividing by the per-route maximum makes the denominator float with the query. For a question with no answer in the corpus, the vector route's best hit may score 0.09 and still normalize to a perfect 1.0, entering the fusion at full weight. You think you are comparing relevance; you are comparing `tallest among the short`.
  4. Then the maintenance cost of weights: a 1-to-0.6 ratio has to be tuned against an eval set, tuning two routes is a 2-D search, adding multi-query retrieval makes it 4-D or 5-D, and swapping the embedding model invalidates all of it. RRF has a single k, and the default of 60 rarely needs touching.
  5. Conclusion: rank is the only thing the two routes share. RRF throws the scores away on purpose so that an incomparable quantity cannot mislead it.
  6. Expected follow-up: what does k do? It flattens — the larger k is, the smaller the gap between the top few ranks, so `ranked well by both routes` outweighs `ranked first by one route`, which is exactly the cross-validation effect hybrid retrieval is after. A second follow-up on ties: you must fall back to sorting by document id, or ranks drift between runs and every eval number wobbles with them.

  答题要点

  • BM25 无上界、余弦有界，两个量纲不可比，直接相加没有意义。
  • 按本路最高分归一化的分母随查询浮动，无答案的查询里最不相干的结果也能拿到满分。
  • 权重要跑评估调，路数一多就是高维搜索，换模型还得重来；RRF 只有一个常数 k。
  • RRF 只吃每一路的有序 id 列表，名次是两路唯一可比的东西。
  • k 越大越奖励「两路都排进前列」；同分必须按 id 兜底排序才可复现。

  Key points

  • BM25 is unbounded, cosine is bounded; the two scales are not comparable, so adding them is meaningless.
  • Per-route max normalization has a denominator that floats with the query, so the least relevant hit of an unanswerable query still normalizes to 1.0.
  • Weights must be tuned against an eval set, the search is high-dimensional once you add routes, and swapping models invalidates it; RRF has a single constant k.
  • RRF consumes only the ordered id list from each route, because rank is the one thing the routes share.
  • Larger k rewards `ranked well by both routes`; ties must fall back to document id so results are reproducible.

D10 查询侧优化：改写、假设文档嵌入、多路查询、后退提问与意图路由

• 假设文档嵌入（HyDE）为什么有效？它在什么情况下会把检索带偏？Why does HyDE (hypothetical document embeddings) work, and when does it steer retrieval in the wrong direction?

  国内高频海外高频进阶#hyde#query-transformation#retrieval-quality

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

  1. 这题的题眼在后半句。前半句网上到处都能抄到，能不能说清「什么时候不该用」才是区分度所在——只答前半句的人，多半没在真实语料上跑过。
  2. 先给机制：向量检索比的是语义相似度，而用户的疑问句和文档里的制度条文在文体、句式、用词上都不同类。HyDE 先让模型编一段「长得像目标文档」的假文本，用它的向量去找邻居，等于把查询搬进了文档所在的那个语域。
  3. 紧接着点破一个常见误解：这段假文本的**事实对不对根本不重要**，因为它不给用户看，只贡献一个向量方向。理解到这一层，才算真懂它为什么不怕模型瞎编。
  4. 带偏有两种典型情况。一是模型编得太具体，给出语料里根本不存在的字段名或流程名，向量朝着一个不存在的方向去了；二是语料里压根没有答案，本该拒答的问题被编出来的假文档匹配到几个「看起来挺像」的邻居，拒答率掉下去、瞎编率涨上来。
  5. 说完风险要给对策，这一步最见工程经验：门槛卡在**每一路检索器的原始分**上而不是融合分上（融合分是相对的，最不相干的一批也能拿最高分）；以及把假设文档当成**第二个检索式与原问题融合**，而不是直接替换原问题——替换在模型编歪时会把原问题的信号一起丢掉。
  6. 可预期的追问是「它多花多少钱」。答：假设文档要写上百字，输出 token 是查询改写的十几倍，是查询侧四种手法里最贵的一次调用，而且检索次数翻倍。所以它通常不该默认打开，应该进 A/B 队列。

  How to reason about it · think before answering

  1. The tell is in the second half. Anyone can recite why HyDE works; only someone who has run it on real data can say when it hurts.
  2. Give the mechanism first: dense retrieval compares semantic similarity, but a user's question and a policy paragraph differ in register, syntax and vocabulary. HyDE has the model draft a fake passage that looks like the target document, then retrieves with that vector — effectively moving the query into the documents' register.
  3. Then kill the common misreading: the factual accuracy of the draft does not matter, because it is never shown to the user. It only contributes a direction in embedding space.
  4. Two failure modes. The model invents an over-specific field or process name that does not exist in the corpus, and the vector chases something imaginary. Or the corpus genuinely has no answer, and the fabricated passage finds plausible-looking neighbours anyway — abstention rate drops and hallucination rate climbs.
  5. Pair the risk with a mitigation: gate admission on each retriever's raw score, never on the fused score (fused scores are relative, so even the worst batch tops out at 1.0); and treat the hypothetical document as a second query fused with the original rather than a replacement, so a bad draft can only dilute the signal, not erase it.
  6. Expect the follow-up on cost. The draft runs to a hundred-plus output tokens, an order of magnitude more than a rewrite, and it doubles retrieval calls. That is why it belongs in an A/B queue, not in the default config.

  答题要点

  • 有效的原因是语域对齐：疑问句和制度条文本来不在一个语义邻域，假设文档把查询搬到了文档那一侧。
  • 假文本的事实对错不重要，它只贡献一个向量方向，不展示给用户。
  • 带偏的两种情况：编得太具体，追一个语料里不存在的方向；本该拒答的问题被假文档匹配上，拒答率下降。
  • 两条护栏：门槛卡原始分不卡融合分；把假设文档当第二个检索式融合，而不是替换原问题。
  • 成本上它是查询侧最贵的一项（长输出加检索次数翻倍），默认关闭、按场景 A/B。

  Key points

  • It works by register alignment: a question and a policy paragraph sit in different neighbourhoods, and the fake passage moves the query into the document's.
  • The draft's factual accuracy is irrelevant — it only supplies a direction and is never shown to the user.
  • It misfires when the model invents over-specific details, or when the corpus has no answer and the fabrication finds plausible neighbours anyway.
  • Two guardrails: gate on raw per-route scores, not fused ones; fuse the hypothetical document with the original query instead of replacing it.
  • It is the most expensive query-side technique (long output plus doubled retrievals), so keep it off by default and A/B it.
• 意图路由判错了会怎样？你会怎么设计兜底？What happens when intent routing misclassifies, and how would you design the fallback?

  国内高频海外高频进阶#intent-routing#fallback#observability

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

  1. 这题在考「有没有想过错误的方向」。路由是分类器，分类器一定会错；只答「多加训练数据提高准确率」的，等于没回答兜底怎么设计。
  2. 先把错误按方向拆开，这一步是整题的骨架：三条路（直接回答、单跳检索、多跳检索）两两误判，代价完全不对称。把该检索的判成直接回答，模型手里一点材料都没有，只能编，这是最贵的一种错；把闲聊判成单跳，只是白花一次检索；把多跳判成单跳，只是少查一轮、答得不全。
  3. 结论顺势就出来了：**兜底方向要偏向「多花一点钱」，判不出来一律退回单跳检索。** 单跳是三条路里错得最轻的一条，而且它的错误是可恢复的——材料不全模型还能说「资料里只查到一半」，材料为空它就只能编。
  4. 再补一层运行时兜底，比事前分类更管用：分类成直接回答之后，如果模型的回答里出现了具体数字、金额、日期这类需要出处的内容，就回退去检索一次再答；分类成单跳之后，如果检索侧一条都没过门槛，就升级走多跳或直接拒答。**用后一步的观测结果纠正前一步的判断**，这是路由系统最实用的一条设计。
  5. 还要提一句可观测性：路由的每一次判定都要落日志，带上原始问题、判定结果、后续是否发生了兜底升级。没有这份日志，你既不知道路由准不准，也没法攒出下一版的训练集。
  6. 可预期的追问是「什么时候干脆别做路由」。答：流量里闲聊占比很低、且多跳问题很少时，路由省下的钱还不够付分类调用的钱，这时候直接全部走单跳更划算——我们在 30 篇语料的实验里就看到，路由真正的收益并不在省检索，而在于认出多跳之后给它更高的上下文预算。

  How to reason about it · think before answering

  1. This tests whether you have thought about the direction of the error. A router is a classifier and classifiers misfire; "add more training data" is not a fallback design.
  2. Break the errors down by direction — that is the backbone of the answer. Across three routes (direct answer, single-hop, multi-hop) the six confusions carry wildly asymmetric costs. Routing a retrieval-worthy question to a direct answer leaves the model with no material at all, so it fabricates: the most expensive error. Routing chit-chat to single-hop merely wastes one retrieval. Routing multi-hop to single-hop just yields an incomplete answer.
  3. The conclusion follows: bias the fallback toward spending a little more, and default to single-hop retrieval whenever the classifier is unsure. Single-hop is the cheapest error to make, and it is recoverable — with partial material the model can still say it only found half the answer; with no material it can only invent one.
  4. Add a runtime fallback, which beats better up-front classification: after a direct-answer routing, if the draft reply contains figures, amounts or dates that need a source, fall back to retrieval and answer again; after a single-hop routing, if no candidate clears the admission gate, escalate to multi-hop or abstain. Correcting the earlier decision with the later observation is the single most useful pattern in routing systems.
  5. Mention observability: log every routing decision with the raw question, the label, and whether a fallback fired. Without that log you know neither how accurate the router is nor what to train the next version on.
  6. Expect "when should you skip routing entirely?" When chit-chat is a small share of traffic and multi-hop questions are rare, the classification call costs more than it saves. In our 30-document lab the real gain from routing was not saved retrievals but the ability to give recognised multi-hop questions a larger context budget.

  答题要点

  • 三条路的误判代价不对称：把该检索的判成直接回答最贵（模型没材料只能编），把闲聊判成单跳只是白花一次检索。
  • 兜底方向偏向多花钱：判不出来一律退回单跳检索，它是错得最轻且可恢复的一条路。
  • 加运行时兜底：直接回答里出现需要出处的数字就补一次检索；单跳检索一条都没过门槛就升级或拒答。
  • 每一次路由判定都落日志（原始问题、判定结果、是否触发兜底），既用于监控也用于攒下一版训练集。
  • 闲聊与多跳占比都很低时，路由省的钱付不起分类调用，直接全走单跳更划算。

  Key points

  • The three routes have asymmetric error costs: sending a retrieval-worthy question to a direct answer is the worst, while routing chit-chat to single-hop only wastes one retrieval.
  • Bias the fallback toward spending more: default to single-hop whenever the classifier is unsure, since that error is the mildest and is recoverable.
  • Add runtime fallbacks: re-retrieve if a direct answer contains figures that need a source; escalate or abstain if no single-hop candidate clears the gate.
  • Log every routing decision — raw question, label, whether a fallback fired — for both monitoring and the next training set.
  • When chit-chat and multi-hop are both rare, the classification call costs more than it saves; route everything to single-hop instead.

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

• 父子索引和上下文检索都在补『块被切碎』这个问题，它们的差别到底在哪？Parent-child indexing and contextual retrieval both patch the same problem — chunks losing their context. What actually distinguishes them?

  国内高频海外高频进阶#indexing#contextual-retrieval#chunking

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

  1. 这题的题眼是『补的是哪一半』。答成『一个是切块技巧、一个是加提示词』就是在描述实现，面试官想听的是它们各自作用在检索管道的哪一段。
  2. 拆的办法是把管道分成两段问：检索时看到什么、生成时看到什么。父子索引改的是**生成侧**——检索单位还是小块，只是命中之后把上下文单位换成大块；上下文检索改的是**检索侧**——块头拼进去是为了让这一块能被检索到，模型生成时并不需要它。
  3. 结论：父子索引解决『找到了但看不全』，上下文检索解决『看得全但找不到』。前者不改变谁被检索到，后者不改变模型看到多少。它们正交，可以叠加。
  4. 这个差别还决定了它们各自要用什么指标去量：上下文检索动的是名次，用召回率和 nDCG 量得到；父子索引动的是『材料够不够答』，召回率这种二值指标量不出来。我们那份 20 题评估集单文档档已经 100% 饱和，父子索引在表里跟基线持平——那不是它没用，是尺子量不了它。
  5. 顺着这条差异能推出一个立刻能用的优化：既然块头只服务检索，就不该进上下文。它进了上下文就是在每一次查询里白占预算，而且这笔钱是长期的。我们的实验里把这个开关一改，五列指标一个不变，600 token 的预算里多装进了 36 个 token。
  6. 代价也不同：父子索引的代价是索引条目变多、每次装进上下文的东西变大；上下文检索的代价是一次性要给每块调一次模型，加上索引 token 永久变大。前者是空间，后者是时间加空间。
  7. 可预期的追问是『那我全都上』。答案是先看失败案例：日志里是『材料不完整』多，还是『压根没检索到』多。没有对应的失败模式就不该上，这两个手法都不是免费的。

  How to reason about it · think before answering

  1. The hinge is which half of the pipeline each one fixes. Answering 'one is a chunking trick, the other adds a prompt' just describes implementations; the interviewer wants to know where each acts.
  2. Split the pipeline in two and ask separately: what does the retriever see, and what does the generator see. Parent-child changes the generation side — retrieval still runs on small chunks, but a hit is swapped for its parent. Contextual retrieval changes the retrieval side — the header exists so the chunk can be found at all, and the generator does not need it.
  3. Conclusion: parent-child fixes 'found it but can't read it'; contextual retrieval fixes 'readable but never found'. Neither changes what the other changes, so they compose.
  4. That difference also dictates which metric can see each one. Contextual retrieval moves rank, so recall and nDCG catch it. Parent-child moves 'is the evidence sufficient to answer', which a binary recall metric cannot see. Our 20-question set is already saturated at 100% on single-document questions, so parent-child comes out level with the baseline — that is the ruler failing, not the technique.
  5. That difference yields a free optimization: since the header only serves retrieval, keep it out of the context window. Leaving it in pays rent on every single query. Flipping that one switch in our lab freed 36 tokens inside a 600-token budget with every metric unchanged.
  6. The costs differ too. Parent-child costs index entries and a bigger context unit. Contextual retrieval costs one model call per chunk up front plus a permanently larger index. One is space; the other is time and space.
  7. Expect the follow-up 'why not both'. Look at the failure logs first: are you mostly seeing incomplete evidence, or nothing retrieved at all? Without the matching failure mode, neither is worth its price.

  答题要点

  • 父子索引作用在生成侧：检索单位是小块，上下文单位换成父块，解决『找到了但看不全』。
  • 上下文检索作用在检索侧：块头让块能被检索到，解决『看得全但找不到』。
  • 两者正交可叠加；块头只该进索引不该进上下文，否则每次查询都在为它付钱。
  • 父子索引的代价是索引条目与上下文单位变大；上下文检索的代价是一次性建索引调用加永久变大的索引。
  • 选哪个看失败案例：材料不完整选前者，压根没检索到选后者。

  Key points

  • Parent-child acts on the generation side: retrieve small, swap in the parent for context. It fixes 'found but unreadable'.
  • Contextual retrieval acts on the retrieval side: the header makes the chunk findable. It fixes 'readable but never found'.
  • They are orthogonal and compose; keep the header in the index only, never in the context window.
  • Parent-child costs more index entries and a larger context unit; contextual retrieval costs one call per chunk plus a permanently larger index.
  • Pick based on the observed failure: incomplete evidence points to the former, zero retrieval to the latter.
• 同一份语料建了三套索引，检索时你怎么决定走哪一套？You have built three different indexes over the same corpus. How do you decide which one a query goes to?

  国内高频海外高频进阶#index-routing#evaluation#architecture

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

  1. 这题是送分还是丢分，取决于你有没有先反问一句『真的需要三套吗』。上来就答路由策略的人，默认了一个没被验证的前提。
  2. 第一步是承认多数情况下答案是『都不走，走默认那套』。我们在 30 篇语料上把五种索引结构各测一遍，**召回率全部停在 93.8%，没有一种跑赢基线**；唯一动了的是 nDCG@10（块头把它从 0.6438 抬到 0.7218），而两段式的摘要索引还掉到了 87.5%。每种结构补的都是一个特定短板，你没有那个短板时它只带来成本。
  3. 第二步才是路由，而判据不是『哪套准』——那是离线评估该回答的问题，不是运行时能知道的。运行时能拿到的只有**问题的形状**：细节型（答案落在某一段）、概括型（要全库的一个概括）、多跳型（要跨实体串联）。按形状分流，正好对应块级索引、树状聚合索引、图索引。
  4. 实现上就是一个轻量意图分类器，跟前一天的意图路由是同一套东西，不必再造一个。分类结果作为元数据带进请求，方便事后拿评估集回看分错了多少。
  5. 兜底策略要说清楚：分类错了**回落到默认那一套**，不要并行全查一遍再融合。并行看着稳，实际上把延迟和成本按索引套数翻倍，而多出来的那两路大概率一条都进不了上下文预算。
  6. 可预期的追问是『怎么知道分类器分对了』。答案是把路由决策记进日志，定期拿标准答案集回放：对每个问题分别走三套索引，看分类器选的那套是不是指标最好的那套。这是一个能持续跑的离线作业，不需要人工标注。

  How to reason about it · think before answering

  1. Whether this is an easy point or a lost one depends on whether you first ask 'do we actually need three?'. Jumping straight to routing accepts an unverified premise.
  2. Step one is admitting the answer is usually 'none of them — use the default'. Across 30 documents we measured five index structures and every one landed at 93.8% recall, none beating the baseline. The only metric that moved was nDCG@10, which headers lifted from 0.6438 to 0.7218, while the two-stage summary index fell to 87.5%. Each structure patches one specific weakness; without that weakness it is pure overhead.
  3. Step two is routing, and the criterion is not 'which index is more accurate' — that is an offline evaluation question, not something you know at request time. What you do have at request time is the shape of the question: detail-seeking, summarizing, or entity-chaining. Those map onto the chunk index, the tree-summary index and the graph index.
  4. Implementation is a lightweight intent classifier — the same one from the previous day's intent routing, no need to invent another. Carry the decision as request metadata so you can replay it later.
  5. Spell out the fallback: on a misclassification, fall back to the default index rather than fanning out across all three and fusing. Fan-out looks safe but multiplies latency and cost by the number of indexes, and the extra routes usually never make it into the context budget anyway.
  6. Expect 'how do you know the classifier is right'. Log every routing decision and replay the golden set periodically: run each question through all three indexes and check whether the classifier picked the best-scoring one. It is a standing offline job that needs no human labelling.

  答题要点

  • 先反问是否真需要三套：实测五种索引结构召回率全部持平在 93.8%，没有对应短板就是纯成本。
  • 运行时的判据是问题的形状——细节型、概括型、多跳型，分别对应块级、树状摘要、图索引。
  • 复用前一天的意图路由做分类，把路由决策记进请求元数据。
  • 分类错了回落到默认索引，不要并行全查再融合——延迟和成本按套数翻倍。
  • 用标准答案集定期回放，检验分类器选的那套是不是指标最好的那套。

  Key points

  • First challenge the premise: all five index structures landed at the same 93.8% recall in our measurement, so an index without a matching weakness is pure cost.
  • At request time the usable signal is question shape — detail, summary, or entity-chaining — mapping to chunk, tree-summary and graph indexes.
  • Reuse the previous day's intent router for classification and record the routing decision as request metadata.
  • Fall back to the default index on misclassification instead of fanning out and fusing, which multiplies latency and cost.
  • Replay the golden set periodically to check whether the classifier picks the best-scoring index.

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

• 自反思式检索会反复改写查询重试。你怎么保证它一定会停下来，而不是在同一个查询上原地打转？Self-reflective retrieval rewrites the query and retries. How do you guarantee it terminates instead of spinning on the same query forever?

  国内高频海外高频进阶#agentic-rag#self-reflection#reliability

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

  1. 这题在考「有没有真让循环跑过」。只答「设一个最大轮数」的能拿一半分，因为最大轮数只拦住了一类失控，剩下两类照样漏出去。
  2. 怎么拆：把失控分成三种形态，每种配一道闸。一是「每轮都在推进但永远推进不完」，用最大轮数拦；二是「每轮都不超标但累计爆掉」，用累计 token 预算拦——四轮各读 600 token 没有一轮超标，可送进模型的材料已经是单轮的四倍；三是「原地打转」，用重复查询检测拦。
  3. 重复查询检测有两个实现细节，答出来就说明真写过：一是要放在检索之前，否则要白花一次调用才发现自己在转圈；二是判重要对查询做归一化，只看词的集合，否则「主备切换 审批」和「审批 主备切换」会被当成两个不同的查询，圈照转不误。
  4. 还要说清停下来之后怎么办：停止原因必须分类记录，「查够了」「主动认输」「撞到轮数」「撞到预算」「原地打转」是五种不同的结局。把它们混成一个「循环结束」，你就永远看不见系统在多大比例的问题上其实是放弃了。
  5. 一个容易被忽略的点：闸门装了不等于验过。默认预算如果比实际用量高一大截，跑多少遍都踩不响它，等于没装。每一道闸都要构造一个用例把它踩响，这是验收的一部分。
  6. 可预期的追问是「模型自己说不够，但其实已经够了怎么办」。答案是自评要给结构化输出（覆盖了哪些要素、缺哪些），缺失项为空却仍判不够时按「够了」处理——让判断可审计，而不是信一个布尔值。

  How to reason about it · think before answering

  1. This checks whether you have actually run such a loop. 'Set a max iteration count' is half an answer: it stops one failure mode and lets two others through.
  2. Split runaway behaviour into three shapes and give each its own brake. Progress that never completes is capped by max rounds. Per-round budgets that pass individually but blow up in aggregate need a cumulative token budget - four rounds of 600 tokens each never trips a per-round check yet quadruples what reaches the model. Spinning in place needs duplicate-query detection.
  3. Two implementation details prove you have written it: the duplicate check belongs before the retrieval call, otherwise you pay for a call to learn you are looping; and queries must be normalized to a set of terms, or 'failover approval' and 'approval failover' count as two distinct queries and the loop keeps turning.
  4. Say what happens after it stops: stop reasons must be recorded as distinct categories - satisfied, gave up, hit round cap, hit token budget, duplicate query. Collapsing them into 'loop finished' hides how often the system simply surrendered.
  5. An easy miss: installing a brake is not testing it. If the default token budget sits far above real usage it never fires, which is the same as not having one. Every brake needs a case that trips it.
  6. Expected follow-up: what if the model says 'not enough' when it actually is? Make the assessment structured - which elements are covered, which are missing - and treat an empty missing list as sufficient, so the decision is auditable rather than a bare boolean.

  答题要点

  • 三道闸缺一不可：最大轮数、累计 token 预算、重复查询检测。
  • 累计预算拦的是「每轮都不超但加起来爆掉」，轮数闸看不见这件事。
  • 重复查询检测要放在检索之前，且查询要归一化成词的集合再判重。
  • 停止原因分类记录：查够了、主动认输、撞轮数、撞预算、原地打转是五种结局。
  • 每一道闸都要构造用例踩响，装了没验过等于没装。
  • 自评输出结构化的覆盖与缺失项，让「不够」这个判断可审计。

  Key points

  • Three brakes, none optional: max rounds, cumulative token budget, duplicate-query detection.
  • The cumulative budget catches rounds that each pass but blow up together - the round cap cannot see that.
  • Check for duplicates before retrieving, and normalize the query to a term set before comparing.
  • Record stop reasons as distinct categories rather than one 'finished' bucket.
  • Every brake needs a case that actually trips it; an untested brake is no brake.
  • Have the assessor emit covered and missing elements so 'not enough' is auditable.
• 什么情况下你会拒绝把一个 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.

D13 上生产：增量同步与去重、按权限过滤、缓存分层、链路追踪与成本延迟账

• 文档更新之后，你怎么做到只重算受影响的块？被删掉的文档又怎么保证一定从索引里消失？After a document changes, how do you recompute only the affected chunks? And how do you guarantee a deleted document really disappears from the index?

  国内高频海外高频进阶#incremental-sync#content-hash#index-maintenance

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

  1. 这题有两半，区分度全在后半。前半几乎人人答得出「算个哈希比一比」，能不能拿到分取决于你有没有主动讲删除——那是同一套机制里唯一不对称的一种变更。
  2. 先给增量的骨架：拿来源的全集和索引的全集做三向对账。来源有、索引没有是新增；两边都有但内容指纹不同是修改；索引有、来源没有是删除。修改的处理是整篇替换，先删旧块再写新块，不能只追加——不然改短了的文档会在索引里留下一截尾巴。
  3. 接着讲指纹本身，这是给分点：sha256 取前若干位，但**算之前必须先做换行归一化再去首尾空白**。同一份文件从 Windows 传一次、从 Mac 传一次，字节不同内容相同，不归一化就每次都判成变了，等于天天在做全量重建。这个 bug 不报错，只体现在账单上。
  4. 然后是删除这一半的关键判断：**删除不是一个事件，是一个缺席**。文件变动类的通知只告诉你哪些东西变了，永远不会有人发一条「我不存在了」。所以删除检测必须反着来——遍历索引，找出来源里已经没有的 id。只监听变更事件的同步器永远等不到这条消息。
  5. 落到存储上：文档、块、向量三张表用外键级联删除，删文档只写一条语句，剩下的交给数据库。手写三条删除的版本迟早会漏掉一条，而漏掉的那条就是索引里的幽灵。收尾时报一个可验证的指标：块数与向量数必须相等，不等就说明有孤儿。
  6. 可预期的追问：来源系统本身就不可靠、拉不全怎么办？那就把「本次拉取是否完整」当成删除检测的前置条件——拉取不完整时只做新增和修改，不做删除，否则一次拉取失败会把半个索引清空。另外给删除加软删标记和保留期，误删还能回滚。

  How to reason about it · think before answering

  1. There are two halves here and the second one separates candidates. Almost everyone can say 'hash it and compare'; the score comes from bringing up deletion yourself, because it is the one asymmetric case in the whole mechanism.
  2. Give the skeleton first: a three-way reconciliation between the full set from the source and the full set in the index. In source but not indexed is an add; in both but with different content hashes is a modify; indexed but absent from the source is a delete. A modify must replace the document wholesale, deleting old chunks before writing new ones, otherwise a shortened document leaves a tail behind in the index.
  3. Then the fingerprint itself, which is where points are won: sha256 truncated, but normalize line endings and trim before hashing. The same file uploaded from Windows and from macOS differs byte-wise but not in content; skip normalization and every re-upload counts as a change, which is a full rebuild in disguise. It never raises an error, it only shows up on the bill.
  4. The key insight in the second half: a deletion is not an event, it is an absence. Change feeds tell you what changed; nobody ever sends 'I no longer exist'. So deletion detection has to run in the opposite direction — walk the index and find ids the source no longer has. A synchronizer that only listens to change events will wait forever.
  5. At the storage layer, cascade the foreign keys across documents, chunks and embeddings so deleting a document is a single statement and the database does the rest. Hand-written three-step deletes eventually miss one, and the one they miss is a ghost in the index. Close with a verifiable invariant: chunk count must equal embedding count, and a mismatch means orphans.
  6. Expected follow-up: what if the source system itself is unreliable and a pull comes back incomplete? Make pull completeness a precondition for deletion: on a partial pull, apply adds and modifies only, or one failed fetch wipes half your index. Also soft-delete with a retention window so a mistake is recoverable.

  答题要点

  • 三向对账：新增、修改、删除，缺一不可；修改是整篇替换，先删旧块再写新块。
  • 内容指纹算之前必须先做换行归一化再 trim，否则跨系统重传会被误判为修改，等于天天全量重建。
  • 删除是缺席不是事件，必须反过来遍历索引找出来源里已消失的 id，不能只监听变更通知。
  • 文档、块、向量用外键级联删除，删文档只写一条语句；用「块数等于向量数」当可验证的收尾指标。
  • 来源拉取不完整时只做新增与修改、跳过删除，并给删除加软删与保留期以便回滚。

  Key points

  • Three-way reconciliation covering adds, modifies and deletes; a modify replaces the whole document, old chunks first.
  • Normalize line endings and trim before hashing, or cross-platform re-uploads look like edits and you are doing a full rebuild every night.
  • Deletion is an absence, not an event: walk the index for ids the source no longer has instead of waiting on a change feed.
  • Cascade deletes from documents to chunks to embeddings so one statement suffices; assert chunk count equals embedding count to catch orphans.
  • On an incomplete pull, apply adds and modifies only, and soft-delete with a retention window so mistakes are reversible.
• RAG 系统里有哪些东西可以缓存？各自的失效条件是什么？What can be cached in a RAG system, and what are the invalidation conditions for each?

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

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

  1. 这题看起来是送分题，实际是筛人题。答成「把问答结果缓存起来」只拿到三分之一，面试官等着听的是「分几层」和「各自什么时候失效」。
  2. 先给一条能迁移到别的题上的判断依据：**「什么时候必须失效」这个问题，等价于「key 里有没有把那样东西算进去」。** key 少放一样，那样东西变了缓存就不会失效。有了这条，三层的答案自己就长出来了。
  3. 然后逐层给：答案层缓存问题到最终答案，key 要有问题、权限范围、索引版本、模型与提示词版本；检索层缓存检索式到命中块列表，key 要有问题、权限范围、topK、索引版本、向量后端，但不需要模型；向量层缓存文本到向量，key 只有文本和向量后端。
  4. 重点讲向量层的反直觉之处：它是**内容寻址**的，文本没变、模型没变，向量就不会变，所以**不能把索引版本放进它的 key**。放进去的话一次同步就作废几万条向量，正好绕回全量重建——你加缓存想省的那笔钱又花回去了。这一层可以放很久甚至持久化。
  5. 给一个具体的失效手法：用**索引版本号**而不是精确删除。同步只要真的改动了索引就把版本号加一，旧 key 再也算不出来，自然没人读得到。精确删除要求你能列出「这次改动影响了哪些问题」，而那是列不出来的。
  6. 可预期的追问：能举一个「该失效却没失效」的真实例子吗？答：答案缓存的 key 只放了问题本身，文档里的上限从 200 MB 改成 500 MB、索引已经更新，再问同一个问题仍然返回 200 MB。它不报错，日志上是一次漂亮的缓存命中；同一个 key 还会让另一个部门的用户直接命中别人的答案。

  How to reason about it · think before answering

  1. This looks like a giveaway and is actually a filter. 'Cache the question and answer' earns a third of the credit; the interviewer is waiting for the layering and the per-layer invalidation rules.
  2. Lead with a transferable rule: 'when must this be invalidated' is the same question as 'is that thing part of the key'. Leave something out of the key and changes to it will never invalidate the entry. With that rule the three layers derive themselves.
  3. Then go layer by layer. The answer layer maps a question to a final answer; its key needs the question, the permission scope, the index version, and the model plus prompt version. The retrieval layer maps a query to a hit list; its key needs the question, scope, topK, index version and embedding backend, but not the generation model. The embedding layer maps text to a vector; its key is just the text and the backend.
  4. Emphasize the counterintuitive part of the embedding layer: it is content-addressed, so the index version must not be in its key. Put it there and a single sync invalidates tens of thousands of vectors, which is exactly the full rebuild you added caching to avoid. This is the one layer that can live a long time, even on disk.
  5. Offer a concrete invalidation mechanism: version numbers rather than targeted deletion. Bump an index version whenever a sync actually changes something and old keys simply stop being computed. Targeted deletion would require enumerating which questions a change affected, and that list cannot be produced.
  6. Expected follow-up: can you give a real 'should have expired but didn't' case? Yes: an answer cache keyed only on the question. A document's limit changes from 200 MB to 500 MB, the index is updated, and the same question still returns 200 MB. Nothing errors; the log shows a clean cache hit. The same key also serves one department's answer to a user from another.

  答题要点

  • 分三层：答案、检索、向量，三者的寿命差着数量级，不能当成一件事。
  • 判断依据是「什么时候必须失效」等价于「key 里有没有算进那样东西」，key 少一样就永远失效不了。
  • 答案层 key 要有问题、权限范围、索引版本、模型与提示词版本；检索层去掉模型、加上 topK 与向量后端。
  • 向量层是内容寻址的，key 只有文本与后端；把索引版本放进去会让每次同步都退化成全量重建。
  • 用索引版本号做失效比精确删除可靠，因为「这次改动影响了哪些问题」根本列不出来。

  Key points

  • Three layers — answer, retrieval, embedding — with lifetimes orders of magnitude apart; treating them as one thing is the mistake.
  • The rule is that 'when must it expire' equals 'is it in the key'; anything left out of the key can never invalidate the entry.
  • The answer key carries question, permission scope, index version, model and prompt version; the retrieval key drops the model and adds topK and the embedding backend.
  • The embedding layer is content-addressed and keyed only on text plus backend; adding an index version turns every sync back into a full rebuild.
  • Version-based invalidation beats targeted deletion because you cannot enumerate which questions a given change affected.