用途：把 SGLang 服务的线上故障转成可复现的调试路径。适用于 /health 或 /health_generate 异常、延迟或吞吐回退、健康正常但队列增长、某类请求超时或挂起、仅部分请求后崩溃、部署或权重切换后输出改变、以及已知好/坏提交之间的回归排查。核心流程为一条循环：先采集基线包，再保存失败请求或崩溃转储，然后在干净目标上复现，最后才切换更深入的调试工具；不要一上来就做性能剖析。
主要能力：采集只读的在线基线包（脚本 scripts/incident_artifact_tool.py collect-bundle，含 /health、/health_generate、/model_info、/server_info、/v1/loads、/metrics、/hicache/storage-backend 等），并用 summarize-bundle 生成要点；保存失败请求（崩溃路径用 --crash-dump-folder，非崩溃路径开启请求转储）；在干净目标上回放（如 replay_request_dump.py）；必要时开启 CUDA coredump、调整 OTel trace 级别、或转交更专注的技能。输出契约包含：问题分类、已检查项、最强信号、当前最佳猜测、已排除项、下一步与生产风险。
使用方式：先 collect-bundle 采集，再用 summarize-bundle 快速阅读健康状态、拓扑与运行参数、队列与 token 用量、TTFT/E2E/队列时间启发式；若服务器受保护可加 --token "$SGLANG_BEARER_TOKEN"。用 summarize-dump 汇总转储后再回放。回放若指向 CUDA 崩溃，可设 SGLANG_CUDA_COREDUMP=1 并指定 SGLANG_CUDA_COREDUMP_DIR 重启复现，再用 cuda-gdb 查看。需注意 /hicache/storage-backend/clear 会清空缓存内容，属破坏性操作，仅在可接受丢失缓存时使用。
工具边界：回放加 coredump 指向 CUDA 崩溃时转 debug-cuda-crash；明显 TP/PP/DP/EP 挂起转 debug-distributed-hang；问题已缩小到计算侧时转 llm-torch-profiler-analysis。两提交间回归应先用确定性复现脚本做 git bisect，再回来继续。
限制：资料未提供价格、平台、效果数据及是否收费等信息，均暂未提供；实际行为取决于 SGLang 版本与部署环境。