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>
2.6 KiB
2.6 KiB
run_18（编排路径 · 重度搜索型 · 预算放宽后）
- 用例：
message="请写一份关于\"人形机器人产业链上中下游\"的分析报告，重点包括上游核心零部件、中游整机制造、下游应用场景，并对比国内外主要玩家。" - 意图：orchestrated（产业链/上中下游/对比 → 强编排信号）
- 跨预算验证：150s → 240s（
overallTimeout放宽），并加宽 worker 死循环收敛阈值（toolRounds >= 5） - 结果：⚠️ HTTP 200，240.0s（踩新的 240s 兜底边界返回），6.4KB
- 时间：2026-09-25 22:12:38
两次对比
| 项 | 预算150s（run_18首次） | 预算240s（本次） |
|---|---|---|
| 收敛 | 150s 兜底 | 240s 兜底 |
| 产物 | S1 框架 + 4.6KB | S1 框架（更完整、含玩家清单/章节大纲）+ 6.4KB |
| worker 报告 | S2-S6 空 | S2-S6 仍空 |
ai_call_log（关键诊断）
- 338：planSubTasks 拆解 19.3s success；
- 339：主编排 240.0s；
- ⚠️ worker 一条
text_gen记录都没有——说明 5 个 worker 的agent.Run均未跑完返回（runOne 未落日志），worker 卡在首轮/多轮generateWithTools的 HTTP 等待中，直到编排 ctx 截止。
根因判断（重视）
路由 chat_route_lmuai_deepseek_v4_flash 的 timeout_seconds: 90。run_18 的 worker prompt 属「长输入、报告型」，3 个 worker 并发发起时 LLM 服务端响应极慢/挂起，单次调用逼近 90s 仍无返回，多轮叠加远超编排预算 → worker 无法在预算内写出报告。
- 这不是「编排空回复/死循环」逻辑问题（对比 run_14 HTTP 对比 94s 正常完成、run_16/17 优秀）；而是 LLM 服务端对「长 prompt + 并发报告型」请求的响应能力/排队导致单次调用卡满 timeout。
编排侧已尽力的优化（本次已改）
overallTimeout150s → 240s，给重度搜索型 worker 更多写稿预算；RunWithUsagetool 死循环收敛由「仅纯工具轮统计」放宽为「工具轮数 >= 5 即收敛」，并在历史含搜索素材时用无工具纯文本重生成结论。
待决策（超出「修」范围）
- 调用级超时：给编排 worker 的每次
generateWithTools设一个更短的调用超时（如 30s），使慢调用快速失败、跳过该类 worker，避免单个慢 LLM 拖死整个编排； - 路由/并发：评估为编排 worker 换一条对长 prompt 响应更稳的路由，或降低
maxConcurrent、减少长 prompt 并发排队； - 预算再放宽：若接受更长等待，可把编排预算提到 300s+，但需权衡用户体验。