面试题库

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

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

• 路由不确定或者路由错误时，系统应该怎么兜底？阈值该怎么定？How should the system handle an uncertain or wrong routing decision, and how do you pick the threshold?

  国内高频海外高频深入#routing#fallback#reliability

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

  1. 题眼在「不确定」和「错误」是两件事。多数人只答重试或人工接管，那是把两个问题揉成一个。区分度在于你能不能先给出一条价值判断，再给策略。
  2. 先立论：**路由到错的子 Agent，比路由失败糟糕得多**。失败你至少知道自己失败了，可以追问一句；错了，接手的子 Agent 完全不知道自己接错了活，会用笃定的语气给出一个格式完整的错误答案，用户不会怀疑，会照着去操作。一个自信的错误答案比一句「我没听清」贵一百倍。
  3. 再给可执行的策略，数字要具体：模型给的置信度低于 0.6，或者路由名不在合法名单里，一律落到兜底的 smalltalk，并在 routingReason 里打上 fallback 前缀加原因码（低置信度、未知路由、结构非法各一种）。兜底那位的人设是「信息不足先追问一句缺的关键信息，不要猜」——兜底的本质是把不确定性还给用户。
  4. 阈值怎么定这一问是重点，别背数字：**取决于两类错误哪一类更贵**。客服场景里多问一句只是用户小小的不耐烦，派错可能变成一条错误的退款承诺，所以宁可保守取 0.6；内部工具型 Agent 里多问一句反而更烦人，阈值就该放低。再补一句可落地的定法：拿标准样本集扫一遍，画出不同阈值下的误派率与追问率，选拐点。
  5. 必须点破的一个坑：**置信度是模型自己报的，它不是概率**。模型说 0.9 不代表有九成对。它只是同一模型、同一提示词下相对可用的排序信号，只能当闸门用，不能拿去算期望值。真正的准确率要靠离线评估去量。
  6. 可以预期的追问：兜底会不会把问题掩盖掉？答案是不会，前提是你记了原因码——把一周内落进兜底的请求按原因分组，能直接看出分诊提示词缺了哪一类描述。兜底是止血，原因码才是治本的输入。

  How to reason about it · think before answering

  1. The hinge is that uncertain and wrong are two different failures. Most candidates answer retry or escalate to a human, collapsing both into one. The discriminator is stating a value judgement before giving a policy.
  2. The claim first: routing to the wrong sub-agent is far worse than failing to route. A failure announces itself and lets you ask a clarifying question. A wrong route does not — the receiving agent has no idea it got the wrong job and will produce a confident, well-formatted, wrong answer that the user will act on. A confident wrong answer costs a hundred times more than I did not catch that.
  3. Then give a concrete policy with real numbers: if the model's confidence is below 0.6, or the route name is not in the allowed list, fall back to the small-talk agent and stamp the reason with a fallback prefix plus a cause code (low confidence, unknown route, invalid shape). The fallback agent's job is to ask for the one missing detail rather than guess — falling back means handing the uncertainty back to the user.
  4. The threshold question is the real test, so do not recite a number: it depends on which error is more expensive. In customer support one extra question costs mild annoyance while a misroute can become a wrong refund promise, so stay conservative. For an internal tool the extra question is the bigger cost, so lower it. Then give a method: sweep thresholds over a golden set, plot misroute rate against clarification rate, and pick the knee.
  5. Name the trap: the confidence number is self-reported and is not a probability. Nine tenths does not mean nine in ten are right. It is a usable ranking signal within one model and one prompt — good as a gate, useless for expected-value math. Real accuracy comes from offline evaluation.
  6. Expect: does falling back just hide the problem? Not if you record cause codes. Group a week of fallbacks by cause and you can see exactly which intent the routing prompt fails to describe. The fallback stops the bleeding; the cause code is what fixes it.

  答题要点

  • 先分清两件事：路由失败可以追问，路由错误会让子 Agent 自信地给出错误答案，后者贵得多
  • 策略：置信度低于 0.6 或路由名不在名单里，一律落兜底的 smalltalk，并在 routingReason 打上 fallback 前缀加原因码
  • 兜底不是随便找个人接，而是把不确定性还给用户——兜底那位应当追问缺失的关键信息而不是猜
  • 阈值取决于两类错误哪一类更贵：客服场景多问一句便宜、派错很贵，所以保守；定法是拿标准样本集扫阈值找拐点
  • 置信度是模型自报的，不是概率，只能当闸门用；真正的准确率要靠离线评估量
  • 落兜底时记原因码，按原因分组就能看出分诊提示词缺了哪一类描述

  Key points

  • Separate the two: a failed route can ask a clarifying question, a wrong route produces a confident wrong answer, and the second is far costlier
  • Policy: confidence below 0.6 or a route outside the allowed list falls back to small talk, stamped with a fallback prefix and a cause code
  • Falling back is not picking someone at random — the fallback agent asks for the missing detail instead of guessing
  • The threshold depends on which error costs more; sweep it over a golden set and pick the knee between misroutes and clarifications
  • Self-reported confidence is not a probability — use it as a gate only, and measure real accuracy offline
  • Record cause codes on every fallback; grouping them shows which intent the routing prompt fails to describe