Files
eaiadminandClaude Code c1af86c934 feat(asr): 本地语音转写接入为一级路由 + 并行工作流合并提交
按用户指示做**一包提交**,不按工作流拆分。本提交刻意混合了多条并行线:

  · 本地 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>
2026-09-26 22:21:39 +08:00

1.6 KiB
Raw Permalink Blame History

run_13

  • 类型:编排型综合任务(具身智能产业链报告)
  • 意图:orchestrated(命中「调研 / 产业链 / 上中下游 / 报告」多信号词)
  • 状态:超时(HTTP 000,客户端 210s 中断,无响应文件)
  • 时间:2026-09-25 21:00 前后
  • 现象:
    • 后端健康(200)正常,但 chat 请求 210s 无返回
    • ai_call_log 近 6 分钟出现 4 条 failed 记录(每次约 20-21s),即编排内部多次 LLM 调用失败而非成功
  • 根因(结合代码 + 日志):
    1. orchestrate.go 的 150s 兜底 ctx 传导失效:编排里 judgeIntent(L180)/planSubTasks(L239)/merge(L403) 调用的 ai.GenerateWithFallback(route, msgs) 不接收 ctx 参数(signature GenerateWithFallback(primary, messages)),内部 client.Generate 走自己的 http timeout,完全不受编排 150s ctx 取消控制。LLM 端慢/失败时只能等各自超时,整体远超 150s/210s。
    2. executeSubTasks 里并发 worker 的 agent.Run(ctx, ...) 虽带 ctx,但上游判断/拆解环节(GenerateWithFallback)已不可中断,链路整体失控。
    3. 编排失败后回收不干净,期间阻塞后续 chat 请求(run_14 在 run_13 排障期间也超时)。
  • 结论:❌ 编排路径依然是超时黑洞,根因是「编排超时兜底未能传导到 LLM 调用链」。SerpApi 解决了搜索速度,但未解决编排超时控制。

横向对照

路径 run_12 单问 run_13 编排
SerpApi 前 run_11 150s 超时 run_06/07/10 超时
SerpApi 后 ✅ 31.9s 成功 ❌ 210s 超时(根因非搜索,是编排超时兜底失效)