diagnoselisted

# Diagnose 昇腾问题的核心诊断循环。你是辅助定位工具——**fix 是你给的建议，由人手动应用到客户环境，你不自动改生产**。 ## 何时用 出现训练或推理问题（中断 / 精度 / 性能），且你在能执行 bash 的 agent 中。被打断后续接 → `/skill:resume-diagnosis`。 ## 紧急情况（生产中断） 客户说“紧急 / 生产挂了 / 先恢复”时，诊断目标从“查根因”变成“**先 stabilize**”： 1. **还是先查知识库**——如果有匹配的 case（比如已知的安全回滚），直接给，这最快。知识库里的具体解药永��优于通用急救口诀。 2. **没有快速匹配时**，根据客户已提供的信息，一步步给 stabilize 建议： - 问客户最近 24-48h 改过什么（脚本/配置、框架版本、驱动/固件/CANN、数据、模型代码）——事故多半源于最近的改动 - 基础健康检查：`npu-smi info`（卡活着吗）、`hccl top`（通信拓扑正常吗） - 看日志栈尾，定位哪层炸的 - 能否先恢复：回滚上个 checkpoint 重启 / 降配（关 EP、降 batch）/ 重启 daemon 3. **不钻深度排查、不写 postmortem**——事后用 `/skill:to-postmortem` 补。 ## 流程（核心循环详见 references/diagnosis-procedure.md） > **执行模型**：你不访问任何环境。所有信息——日志、版本、报错、环境变量——都由工程师从客户那提供（粘贴进来）。你的主动角色是**信息不够时，明确提示工程师需要向客户要什么**。case 里的 `command` 是“要确认的检查”：对照已提供的信息判断，或让客户跑后把输出贴回来——不是你直接执行 `pip`/`env`/`grep`。 > > **续接**：若存在未完成的 `diagnosis_state-*.yaml`（每个并发诊断一个文件），先问“有未完成的诊断，要 `/skill:resume-diagnosis` 续接吗？”——别让工程师自己记着跑 resume。 1. **收集症状 + 确认框架**（全部来自工程师提供的信息） - ���误信息、`HCCL_*`/`ASCEND_*`/`NPU_*` 环境变量值、**版本组合**（引擎版本 + CANN + HDK/驱动 + 架构 A2/A3/A5）——都从客户那要来 - **信息不全就主动问**：若没说清，主动问——①症状（什么报错/什么时候挂）②客户的版本组合（引擎/CANN/HDK/架构）③日志/profiler 在哪（贴相关 rank + 栈尾）。别干等 - **框架从提供的信息/报错判断**（日志里 mindspeed/vllm 字样等）；判断不了就直接问工程师“客户跑的什么框架”，**不要跑 `pip list`**（那是你本地环境，跟客户无关） - **主动裁剪日志**：让工程师只贴失败 rank + 报错栈尾，绝不灌全量 profiler——诊断 session 的 context 八成是日志，全量灌进来会滑出 smart zone（~120K token 推理最锐利），推理质量暴跌 2. **分类 → 加载 `triage-tree.yaml`（Tier 1）** - 症状匹配分支 → 路由到 namespace（先 `training|infere