# run_14
- 类型：预期「纯知识直答」（HTTP/2 vs HTTP/3 对比）
- 意图误判：本意测直答基线，但 prompt 含「对比」→ 命中 judgeIntent 强规则（编排信号词：对比），被判 **orchestrated**，实际走了编排路径
- 状态：超时（HTTP 000，60s 无返回）；两次尝试均失败
- 时间：2026-09-25 21:03（第二次，后端已恢复后仍超时）
- 证据：近 6 分钟 ai_call_log 有 failed 记录（20s 级），为编排内部 LLM 调用失败
- 结论：
  1. **「对比」被当作编排信号词**是设计使然（judgeIntent 强规则要「对比→orchestrated」产出结构化多段）。这是真实业务需要的强规则，不是 bug。
  2. 因此 run_14 实际测的是**编排路径**，与 run_13 同根因超时。
  3. 纯直答基线由 run_09（14s，不触发联网词）单独代表，仍成立。
- 教训：测「直答」必须避开编排信号词（对比/分析/报告/上中下游等）；否则会进入编排路径并被当前超时问题拖住。

## 三次测试小结（SerpApi 接入后）
- run_12 联网单问：✅ 31.9s（SerpApi 修复 single_search）
- run_13 编排型：❌ 210s 超时
- run_14 含「对比」：❌ 60s 超时（同 run_13，被编排路径拖住）

统一结论：**SerpApi 解决了搜索可用性/速度，但编排路径的「超时兜底失效」仍会导致 150s+ 超时且阻塞后续请求**——这是下一步必须修的结构问题。