eaiadminandClaude Code
c1af86c934
按用户指示做**一包提交**，不按工作流拆分。本提交刻意混合了多条并行线：
· 本地 ASR 接管：audio 成为与 chat/embed/image/video 同等的路由类别
（IsLocalRoute 单一判据、audio 健康探测、default_audio_route、
auto 占位、GET /api/ai/routes/audio、回退云端时界面明示「音频已出网」）
· LLM 调用层：ctx 贯穿、ToolCall/ToolSchema、EmptyCompletionError /
TransientUpstreamError（按错误类型而非文案判重试）
· 编排 Agent：general_assistant orchestrate/persistence/spec_driver
· 联网搜索：internal/search（playwright）
· 网盘：backend + 前端
· 前端 UI：导航/路由/工作台若干页
· 交付文档：DELIVERY.md / AR04 / 部署文档的「无 Python」表述据实改写，
新增 eai_agentplatform-asr.service、asr.env、clonezilla-cleanup 清 ~/asr-poc
不分拆的原因：dev 早期，粒度不该打断工作节奏。且实测过——这些改动
**在编译上是同一个单元**（llm.go 的 ctx 签名变更牵动 12 个调用点，
chat_message.go 的 ctx 改动又与编排重写同处一个 hunk），拆出来的中间态编不过。
详见 TOP_CODING_RULES.md G14.5 与 bugs_and_errors.md E09。
Co-Authored-By: Claude Code <noreply@anthropic.com>
1.4 KiB
1.4 KiB
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 调用失败
- 结论：
- 「对比」被当作编排信号词是设计使然（judgeIntent 强规则要「对比→orchestrated」产出结构化多段）。这是真实业务需要的强规则，不是 bug。
- 因此 run_14 实际测的是编排路径，与 run_13 同根因超时。
- 纯直答基线由 run_09（14s，不触发联网词）单独代表，仍成立。
- 教训：测「直答」必须避开编排信号词（对比/分析/报告/上中下游等）；否则会进入编排路径并被当前超时问题拖住。
三次测试小结（SerpApi 接入后）
- run_12 联网单问：✅ 31.9s（SerpApi 修复 single_search）
- run_13 编排型：❌ 210s 超时
- run_14 含「对比」：❌ 60s 超时（同 run_13，被编排路径拖住）
统一结论：SerpApi 解决了搜索可用性/速度，但编排路径的「超时兜底失效」仍会导致 150s+ 超时且阻塞后续请求——这是下一步必须修的结构问题。