Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D1 LLM API Basics: messages/roles, Tokens, Streaming, Temperature; What an Agent Actually Is

• A streaming reply is cut off mid-way. What do the client and server each do, and can EventSource auto-reconnect help?流式回复到一半网络断了，前端和后端各要做什么？EventSource 的自动重连能用上吗？

  Common in ChinaCommon overseasIntermediate#streaming#reliability#sse

  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.

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

  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 主动叫停重连。

  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

  答题要点

  • 先区分两种 SSE：浏览器原生 EventSource 自动重连并带 Last-Event-ID，但只能 GET；LLM API 走 POST，用不上这套
  • 所以前端要自己检测断流、自己重试，并保留已收到的部分内容
  • 续写策略：把已收到的内容作为上下文发起新请求，让模型接着写，而不是整轮重来
  • 边界：tool_use 和 thinking 块无法部分恢复，只能从最近的完整文本块续
  • 后端要保证重试安全：响应可续、工具副作用幂等，并对已产生的用量正确计费
• On mobile, connectivity is flaky. How would you design the reconnection strategy for a chat feature?移动端 App 里的对话，网络频繁抖动，你会怎么设计重连策略？

  Common in ChinaCommon overseasIntermediate#reliability#mobile#streaming

  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.

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

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

  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

  答题要点

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

D4 Model Integration and System Prompts: a Multi-Provider Abstraction With Fallback, Overriding the Default Persona (dg P03/P04/M04)

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

  Common in ChinaCommon overseasIntermediate#model-routing#reliability#cost

  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.

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

  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. 可以预期的追问：怎么知道该摘多久？答案是指数退避 + 半开状态试探，和数据库连接池的熔断是同一套思路。

  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

  答题要点

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

D9 A Redis Streams Message Bus: XADD/XREADGROUP/XACK/XAUTOCLAIM, Consumer Groups, Poison Messages

• What do you do with a message that keeps failing? Design a poison-message isolation mechanism.一条消息反复处理失败怎么办？请设计一个毒消息隔离机制。

  Common in ChinaCommon overseasIntermediate#message-bus#error-handling#reliability

  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.

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

  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 而不是运气差；还要留一个重放入口——把死信里的字段原样投回原流即可，因为幂等键还在，重放不会产生重复执行。见过团队把死信建起来半年没打开过，那等于把故障静音了。

  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

  答题要点

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

D14 Deployment and Operations: Multi-Worker Compose, Heartbeats, Health Checks, Graceful Shutdown, Dev/Prod Isolation; Week Two Retrospective

• What is graceful shutdown, and why is killing a process outright risky? Walk through the steps.什么是优雅停机？为什么直接 kill 进程有风险？请说出具体步骤。

  Common in ChinaCommon overseasIntermediate#deployment#reliability#operations

  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).

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

  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 未必传得到，停机代码一次都不会执行）。

  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

  答题要点

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

  Common in ChinaCommon overseasIntermediate#deployment#reliability#operations

  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.

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

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

  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

  答题要点

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

D16 Dynamic Routing With a Supervisor: Structured-Output Routing, Override, routingReason

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

  Common in ChinaCommon overseasIntermediate#structured-output#routing#reliability

  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.

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

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

  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

  答题要点

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

D17 Planner-Executor-Critic Plus a Shared Workspace: Workspace State, toolBudget, Parallel Fan-Out, a Review Loop

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

  Common in ChinaCommon overseasIntermediate#cost-control#reliability#agent-design

  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.

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

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

  答题要点

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

  Common in ChinaCommon overseasIntermediate#reflection#loop-guard#reliability

  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.

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

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

  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

  答题要点

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

D18 History Fidelity and Summarization, Multimodal Placeholders, Checkpointer Persistence

• 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?长对话做摘要时，怎么保证关键信息不丢？在多 Agent 场景下这件事有什么特别的？

  Common in ChinaCommon overseasIntermediate#context-compression#multi-agent#reliability

  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.

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

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

  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

  答题要点

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

MCP in 7 Days: Wire Tools Into Any Agent

D5 Writing an MCP Client: Discovering and Calling Tools Inside Your Own Agent Loop, Multi-Server Aggregation and Name Collisions

• One of your MCP servers times out in production. How should your agent loop react?线上一个 MCP 服务端超时了。你的 Agent 循环应该怎么反应？

  Common in ChinaCommon overseasIntermediate#client#reliability

  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.

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

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

  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

  答题要点

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

RAG in 14 Days: From Retrieval to Trustworthy Answers

D12 Agentic RAG: Turning Retrieval Into a Tool So the Model Decides Whether to Search, How Many Times, and Whether to Start Over

• Self-reflective retrieval rewrites the query and retries. How do you guarantee it terminates instead of spinning on the same query forever?自反思式检索会反复改写查询重试。你怎么保证它一定会停下来，而不是在同一个查询上原地打转？

  Common in ChinaCommon overseasIntermediate#agentic-rag#self-reflection#reliability

  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.

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

  1. 这题在考「有没有真让循环跑过」。只答「设一个最大轮数」的能拿一半分，因为最大轮数只拦住了一类失控，剩下两类照样漏出去。
  2. 怎么拆：把失控分成三种形态，每种配一道闸。一是「每轮都在推进但永远推进不完」，用最大轮数拦；二是「每轮都不超标但累计爆掉」，用累计 token 预算拦——四轮各读 600 token 没有一轮超标，可送进模型的材料已经是单轮的四倍；三是「原地打转」，用重复查询检测拦。
  3. 重复查询检测有两个实现细节，答出来就说明真写过：一是要放在检索之前，否则要白花一次调用才发现自己在转圈；二是判重要对查询做归一化，只看词的集合，否则「主备切换 审批」和「审批 主备切换」会被当成两个不同的查询，圈照转不误。
  4. 还要说清停下来之后怎么办：停止原因必须分类记录，「查够了」「主动认输」「撞到轮数」「撞到预算」「原地打转」是五种不同的结局。把它们混成一个「循环结束」，你就永远看不见系统在多大比例的问题上其实是放弃了。
  5. 一个容易被忽略的点：闸门装了不等于验过。默认预算如果比实际用量高一大截，跑多少遍都踩不响它，等于没装。每一道闸都要构造一个用例把它踩响，这是验收的一部分。
  6. 可预期的追问是「模型自己说不够，但其实已经够了怎么办」。答案是自评要给结构化输出（覆盖了哪些要素、缺哪些），缺失项为空却仍判不够时按「够了」处理——让判断可审计，而不是信一个布尔值。

  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.

  答题要点

  • 三道闸缺一不可：最大轮数、累计 token 预算、重复查询检测。
  • 累计预算拦的是「每轮都不超但加起来爆掉」，轮数闸看不见这件事。
  • 重复查询检测要放在检索之前，且查询要归一化成词的集合再判重。
  • 停止原因分类记录：查够了、主动认输、撞轮数、撞预算、原地打转是五种结局。
  • 每一道闸都要构造用例踩响，装了没验过等于没装。
  • 自评输出结构化的覆盖与缺失项，让「不够」这个判断可审计。