面试题库

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

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

• 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