面试题库

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

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

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