技能介绍

问题从哪来

在 Jetson 上排障时，真相往往散落在 tegrastats、jtop、procrank、/sys/kernel/debug/nvmap、nvpmodel、free、swapon、df 和 systemctl 里——你要先记住「哪条命令对应哪一块状态」，智能体更容易在缺少实时数据时猜错 SKU、内存或 GPU 占用。

本技能的目标是：从运行中的 Jetson 主机抓取只读健康快照，让对话基于观测而不是臆测，回答「这是什么板子」「现在跑什么」「为什么变慢/变热/内存吃紧」以及「tegrastats 这一行什么意思」。

怎么工作

默认路径：运行 scripts/snapshot.sh，得到涵盖身份、内存、GPU、温度、电源、磁盘、顶层进程与服务候选的综合 JSON；常用参数包括 --human、--tegra-secs N、--top-procs N。
快速扫一眼内存：用 scripts/mem_summary.sh 输出紧凑的 RAM/GPU/交换摘要（--short、--watch、--interval N）。
平台识别：scripts/detect_jetson.sh 导出规范的 SKU/代/产品线字段，其它 Jetson 相关技能可复用，避免重复写识别逻辑。
解读粘贴输出：单条 tegrastats 见 references/tegrastats-fields.md；NvMap 客户端见 references/nvmap-clients.md。

报告时应只引用脚本返回的字段。gpu_source 标明 GPU 内存归属的数据源（如 nvidia-smi:compute-apps 用于 Thor 栈、nvmap:iovmm-clients 用于 Orin 的 nvgpu 栈、none 表示无权威来源）。变慢/变热类问题应同时看 thermal_c 与 top_processes、gpu_processes、nvmap.top_clients 等负载信号，再交给 jetson-memory-audit、jetson-headless-mode 或 jetson-inference-mem-tune 等操作向技能。

边界与注意

必须在 Jetson 主机上运行，或沙箱/容器能见到主机侧的 Jetson 路径与进程数据；缺少 /proc/device-tree/model、tegrastats、nvpmodel 等时，应说明环境缺乏主机可见性，而非用通用 Linux 数值顶替。
NvMap debugfs 通常需要 root；非特权运行可能得到 gpu_source: "none" 或不完整的 nvmap 字段。
本技能不改电源模式、不清缓存、不停服务、不装包、不调推理参数；工具缺失时保留 JSON 中的 null/空字段并说明哪路信号不可用。

截图预览

使用场景

在 Jetson 上部署 vLLM 或 TensorRT 推理前，先确认 SKU、总内存与当前 GPU/进程占用作为基线
现场设备变慢或风扇拉高时，用 snapshot 对照温度与 top_processes，再决定是否交给 memory-audit 或 headless-mode
用户粘贴一行 tegrastats，需要按字段解释 CPU/GPU 利用率与温度含义
已安装 jetson-llm-benchmark 或 jetson-llm-serve，运行基准或服务前先抓一份只读健康快照

适合人员

在 Orin/Thor 上维护边缘 LLM 服务的工程师，需要区分 nvgpu 下 nvmap 与 nvidia-smi 的 GPU 内存数字
负责 Jetson 产线或客户机交付的运维，要在不改 nvpmodel 的前提下回答「这是什么板子、还剩多少内存」
调试 jetson-inference-mem-tune 或 jetson-package 前，需要 JSON 快照里 services 与 nvmap.top_clients 做交接依据的嵌入式开发者
通过 Agent 远程协助 Jetson 排障的支持人员，希望一次脚本输出替代记忆十余条 tegra 相关命令