BP15 · 评测分数回注与 RT 告警#

定位：面试官追问可观测性与告警设计时的拷问预备。

---

核心口述（30 秒）#

“补齐两处缺口：Rubric 分数回注 Langfuse trace（三条 score + 失败维度 comment），支持按低分筛 bad case trace。工具 RT 告警用 P95 滑动时间窗 + 三态状态机（breached/cleared/滞回）防抖 + hard_ms 兜底低 QPS。refdocs 示例代码四处真错全部更正。“

---

拷问链#

Q: trace_id 为什么不用 ContextVar 传？#

run_agent 跑在 create_task 里——子 task 的 ContextVar.set 不回传父上下文。trace_id 永远是 None。改成返回值显式带。

Q: 三态状态机为什么比两态好？#

两态边界抖动频繁翻转（800→799→801）。三态加滞回带——breached 后须降到 threshold × 0.8 才 cleared，消除毛刺。

Q: 熔断 OPEN 时快速失败 ~0ms 为什么不计入 RT 窗口？#

计入会在故障最重时报”已恢复”——快速失败的 0ms 拉低 P95。只有 status=ok 的正常响应进窗口。

Q: hard_ms 有什么用？#

低 QPS 工具（如 web_search 一天可能只调几次），P95 分位数无统计意义。hard_ms 是绝对阈值兜底。

Q: refdocs 四处真错具体是什么？#

① window_minutes 死字段 ② min_samples=10+P99=max值告警 ③ check_alerts 无调用者（死代码）④ 无 webhook 直接 return（告警消失）

Q: 为什么不用 Langfuse Dataset/Experiment？#

“score 挂 trace” 更轻——不需创建 Dataset/Run。按 rubric_total 降序排就能找所有 bad case trace。

---

压力题#

Q: 告警在进程内存，多 worker 怎么办？#

各算各的 P95，同一次抖动推 N 条。升级路径：挪 Redis 或退回 Prometheus+Alertmanager（/metrics 已就绪）。当前单进程够用。