综合模拟面试 5 · 故障排查面#

面试官画像: SRE / 平台稳定性负责人，给场景让你现场排查时长: 40 分钟 · 难度: ★★★★☆ 覆盖方向: 给定故障场景，候选人现场分析根因和解法

场景 1：子 Agent 全超时#

面试官: 5 个子 Agent 全部超时了，用户什么都没拿到。怎么排查？

候选人: 分三步。

第一步看 Langfuse trace——每个子 Agent 有独立 trace，看哪一步卡住了。如果都卡在 LLM 调用 → LLM provider 问题（限流/宕机）。如果卡在 Qdrant → 向量库问题。

第二步看 Prometheus /metrics——工具 RT P95 是否飙升、断路器状态是否 OPEN。如果 reranker 断路器 OPEN → SiliconFlow API 不可用，子 Agent 每次精排都在等超时。

第三步确认兜底——5 个全超时，主 loop 收到 5 段超时文本，走 chat_fallback 告诉用户”搜索暂时不可用”。如果这一步也没走 → 检查主超时和终结纪律是否生效。

场景 2：偏好丢失#

面试官: 用户说”不要塑料”，第一轮正常过滤了，第二轮（新会话）推了塑料商品。

候选人: 检查点：① curator 是否提取了偏好 → 看 Store 里有没有 “dislike-hard:material:plastic” ② 如果有，注入是否生效 → 看 system prompt 的 <user_long_term_preferences> 区块 ③ 如果注入了，item_picker 硬过滤是否生效 → 看候选列表里塑料商品是否被淘汰

常见根因：① curator 没跑（会话异常终止跳过了 curator）② 中文”塑料”跨语言匹配失效（英文商品标题是 “plastic”）→ 加了中文原子词→英文映射 ③ dedup_key 派生错误导致偏好覆盖

场景 3：评测分数突然跌#

面试官: 改了 prompt 后重跑 Rubric，均分从 55 跌到 40。怎么排查？

候选人: 先分清是 Agent 退步还是 judge 变了。

① 对比 P0 fail 数量——如果新增 P0 fail → Agent 问题（改 prompt 引入红线违反）② 对比 P1/P2 细项——找到分数变化最大的维度 ③ 检查是否改了 judge 的评分纪律或细则模板——judge 改了但没意识到也会导致分数变化

关键：先确认尺子没变再看 Agent。

场景 4：延迟退化#

面试官: 上周端到端 40s，这周变成 70s。

候选人: ① 看 Langfuse trace 对比——哪个工具/LLM 调用变慢了 ② 检查是否 reasoning 被意外开启（reasoning 开关配置或 reasoning_boost Hook 逻辑改了）③ 检查是否主 loop 轮数增加了（planner 确定性预置是否失效 → 多了一轮 LLM 往返）④ 检查 LLM provider 是否降速（限流/排队）

最常见根因：reasoning 开关状态变了——开/关 reasoning 对延迟影响 10x。

场景 5：WebSocket 事件丢失#

面试官: 前端看不到 fork 事件。

候选人: ① 检查 fork 事件上报时机——fork 事件在进子 thread_scope 之前上报，路由到父 thread。如果代码改了先进 thread_scope 再上报 → 路由到子 thread，前端连的是父 thread 收不到 ② 检查 ConnectionManager 是否注册了该 thread → connect-first 协议是否正常走完 ③ 检查 Redis Stream 有没有该事件 → 如果有但前端没收到 → WS 断连且没有自动重连