# 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。

## 编排侧已尽力的优化（本次已改）
1. `overallTimeout` 150s → **240s**，给重度搜索型 worker 更多写稿预算；
2. `RunWithUsage` tool 死循环收敛由「仅纯工具轮统计」放宽为「工具轮数 >= 5 即收敛」，并在历史含搜索素材时用无工具纯文本重生成结论。

## 待决策（超出「修」范围）
- **调用级超时**：给编排 worker 的每次 `generateWithTools` 设一个更短的调用超时（如 30s），使慢调用快速失败、跳过该类 worker，避免单个慢 LLM 拖死整个编排；
- **路由/并发**：评估为编排 worker 换一条对长 prompt 响应更稳的路由，或降低 `maxConcurrent`、减少长 prompt 并发排队；
- **预算再放宽**：若接受更长等待，可把编排预算提到 300s+，但需权衡用户体验。