[任务]: GitHub Action CI 故障诊断SKILL

[tfhddd]

任务描述

GitHub Action CI 故障诊断项目

欢迎来到 GitHub Action CI 故障诊断项目！

项目目标：构建 github-action-diagnose AI SKILL，实现 CI 故障从日志获取、问题定界、根因定位到修复方案推荐的全链路自动化诊断，覆盖基础设施异常、业务代码缺陷、三方依赖等主要故障类型。

为统一、规范、透明地向全体开发者同步 CI 诊断 SKILL 建设相关工作，本文档用于同步所有相关计划、进展和成果，确保开发者能够及时了解项目状态。我们会定期更新进度，并在此处记录关键里程碑、任务清单、风险及决策。

---

项目建设总体里程碑计划

阶段一 3.30 前
核心 SKILL 功能开发验证与小范围试点：完成原型验证，选取 10~20 个典型 CI 失败案例（覆盖基础设施异常/代码 Bug/三方依赖三类场景）并使用 SKILL 完成诊断，对比验证自动化定界准确率

阶段二 4.15 前
扩展诊断场景，提升根因分析准确性：联合各业务团队，针对 Ascend NPU 集群（ARC/K8s）的高频故障模式进行测试调优，完善日志解析、节点溯源与三方依赖问题识别能力；同步验证基础设施集群部署结构 AI 可读化改造

阶段三 4.30 前
全面落地：完成文档上线、开发者培训，收集首批用户反馈，建立 CI 问题自动诊断体系

---

Task

NO	step	假设	验证	ai native改造目标	措施
1	日志获取	AI agent 可以直接获取 CI 日志，并提取其中的关键错误信息	nok，完整读取日志需要消耗大量 token（单次2W+）	每个 CI 问题的 token 消耗不随日志大小波动，固定在 2000 token 以内	通过工具脚本（fetch-run.sh）对日志分层预过滤（过滤 tiling 噪声、按错误优先级压缩），再交给 AI 推理
2	问题定界	分工边界在 skill 中明确写出，AI 可自动判断故障类型（基础设施/业务代码/三方依赖）	ok	不涉及	不涉及
3.1	问题属于基础设施	skill 通过读取基础设施日志，分析具体问题	nok，当前基础设施日志存于华为云 LTS，AI 无法直接拉取	基础设施服务日志能够被 agent 读取（需鉴权），K8s 集群节点状态可通过 kubectl 自动查询	验证 LTS 日志 API 开放及鉴权接入方案
3.2	问题属于 vllm-ascend 代码本身	通过 gh CLI 获取 PR diff、issue、变更文件列表，结合日志堆栈分析已知问题和代码 Bug	ok，gh CLI 可获取相关信息	不涉及	不涉及
3.3	问题属于其他项目的代码（三方依赖）	通过搜索上游仓库 issue 和文档，识别已知问题或版本兼容性缺陷	待验证	不涉及	不涉及
4	修复方案推荐	AI 针对不同类型问题给出对应的修复建议	ok，当前 skill 已可输出修复建议	不涉及	不涉及

---

Baseline

current：CI 问题定位依赖开发者人工逐步排查，需手动翻阅大量日志、登录 LTS 平台查询基础设施状态、人工判断问题边界、逐条查阅三方依赖文档

duration：单次 CI 故障定位耗时 0.5~1 天；涉及多层依赖或跨集群节点的问题可能超过 1 天；多问题并发时人力消耗成倍增长

failure：

• 日志量大（含大量 tiling DEBUG 噪声），人工筛查关键错误行效率低
• 基础设施信息（节点、NPU 状态）在k8s、 LTS 等多个平台，获取路径长
• 问题定界主观性强，易将基础设施故障误归因为代码问题（或反之），导致责任方处理延误
• 三方依赖问题需手动查阅文档和 issue，解决周期不可控
• 相同类型故障反复消耗人力，缺乏知识沉淀和复用机制

---

Target

duration：主流故障类型（基础设施/代码 Bug）5 分钟内完成定界与根因定位，生成可操作的诊断报告

autonomy：从日志获取到问题定界到根因分析到修复建议的全流程提供 AI 可调用工具能力链；基础设施类问题自动关联节点信息，代码类问题自动关联 PR diff 与修复方案

verification：通过 AI agent 调用相关 skills 链完成 CI 诊断，常见故障类型（基础设施/代码 Bug/三方依赖）自动定界准确率达到 85%+，根因定位准确率达到 70%+，较人工排查人力消耗降低 60%+

---

风险与挑战

日志可获取性与结构化：当前基础设施问题日志存储于华为云 LTS，AI 无法直接拉取；集群部署结构信息未对 AI 开放，导致节点溯源和环境故障定位存在信息盲区，需验证基础设施侧 AI 可读化改造

日志 token 消耗：单次 CI 日志体积可达数百 MB，完整摄入对 token 消耗极大，需在日志预过滤策略（噪声过滤/按错误类型分层）和诊断准确率之间持续权衡

三方依赖信息获取：依赖包的 issue 和文档分散于 PyPI、GitHub、npm 等多个平台，自动获取链路复杂，信息时效性难以保障

边界模糊问题：部分故障兼具基础设施和代码特征（如概率性挂死），自动定界难度高，需持续积累样本优化分类模型

[tfhddd]

GitHub Action CI 故障诊断项目 — 进展追踪

最后更新：2026-04-02

任务	进展状态	责任人	详细进展
Task 1 日志获取	✅ 已完成	陶飞虎/张扬	完成 fetch-run.sh 脚本开发，实现日志分层预过滤，将原始日志压缩至 ~20 行关键内容；支持 Run URL / Job URL / Run ID 三种输入；Annotations 已含根因时自动跳过完整日志拉取
Task 2 问题定界	✅ 已完成	陶飞虎/张扬	SKILL.md Step 2 明确生命周期分诊规则；classification-guide.md 补充 A/B/C/D/E 五类故障判断树及 5 种混淆场景处理规则；每个问题标注责任方
Task 3.1 基础设施问题定位	🔄 部分完成	陶飞虎/张扬	常见模式已沉淀至 common-patterns.md；华为云 LTS 日志 API 接入方案尚未验证，深层日志仍需人工查阅
Task 3.2 vllm-ascend 代码问题定位	✅ 已完成	陶飞虎/张扬	gh CLI 自动拉取 PR 变更文件与日志堆栈交叉比对；vllm-ascend.md 沉淀仓库专属知识；B 类/C 类识别与区分逻辑完整；高频易误判场景（tiling 警告、exit 255、error code 分段）已写入参考文档
Task 3.3 三方依赖问题定位	待定	陶飞虎/张扬	上游仓库 issue/文档自动检索未实现
Task 4 修复方案推荐	✅ 已完成	陶飞虎/张扬	差异化建议输出：A 类给出重跑/上报运维指引，B/C/D 类定位到具体文件和修改方向，E 类给出概率性问题排查步骤；当前阶段仅提供建议，不含自动代码修改

[KadenZhang3321]

Issue 进展报告：github-action-diagnose Skill 增强

📋 概述

对 github-action-diagnose Skill 进行了全面增强，实现了从纯静态分析到 AI Agentic 工作流 的升级，并集成了 MCP（Model Context Protocol） 集群日志查询能力。

---

✅ 已完成的工作

1. Python 脚本替换（跨平台兼容）

文件	说明
scripts/collect_failed_runs.py	替换原 JS 版本，收集失败 CI 并输出 xlsx
scripts/fetch_run.py	替换原 bash 脚本，跨平台获取 Job 日志和元数据
scripts/diagnose_job.py	新增 单条诊断脚本，AI Agentic Loop 核心
scripts/batch_diagnose.py	新增 批量诊断脚本，支持断点续传
scripts/mcp_client.py	新增 MCP 客户端封装

• 删除了 collect-failed-runs.js 和 diagnose-ci-runs.js
• 修复了 Windows 编码问题（UTF-8 输出）
• fetch_run.py 优先使用 Python 执行，避免 bash 在 Windows 上的编码问题

2. AI Agentic 工作流实现

核心机制：

• 使用百炼 API（Qwen3.6-Plus 模型）通过 OpenAI 兼容接口调用
• 实现 15 个工具 的 Function Calling：
  • GitHub 数据获取（6 个）：fetch_run_script, fetch_job_info, fetch_job_logs, fetch_annotations, fetch_run_info, fetch_pr_diff
  • MCP 集群日志查询（4 个）：mcp_get_runner_logs, mcp_list_pods, mcp_export_logs, mcp_get_export
  • 通用工具（5 个）：bash_execute, read_file, grep_file, glob_file, write_file

诊断流程：

3. MCP 集群日志集成

flowchart TD
    A[用户输入 Job URL] --> B[Step 1: fetch_run_script<br>运行 fetch_run.py 脚本，一次性获取：<br>- Job 基本信息（名称、Runner、失败步骤）<br>- PR 上下文和变更文件<br>- Annotations（通常直接揭示根因）<br>- 预过滤的运行时或编译错误日志]
    B --> C{AI 分析：信息足够吗？}
    C -- ✅ 足够（如 Annotations 已明确 ETIMEDOUT） --> D[直接输出诊断报告]
    C -- ❌ 不足（如只有 exit code 1，无具体错误） --> E[Step 2: mcp_get_runner_logs<br>一键获取 Runner Pod 集群日志：<br>- 自动查找 Pod（按 runner_name 模糊匹配）<br>- 按关键词过滤导出（Error、Failed、OOM 等）<br>- 自动下载并解析日志内容]
    E --> F[AI 分析集群日志<br>- 结合 GitHub 日志 + 集群日志综合判断<br>- 参考 SKILL.md 分类规则（类型 A 至 E）<br>- 确定根因、责任方、处理建议]
    F --> D
    D --> G[输出诊断报告<br>- 定性（类型 A、B、C、D、E）<br>- 根因分析<br>- 关键错误标识<br>- 责任方（基础设施团队 或 PR 作者）<br>- 处理建议]

Loading

4. SKILL.md 更新

• 更新脚本引用，同时支持 bash 和 Python 脚本
• 新增 Step 1e：集群日志查询（MCP）说明
• 明确诊断流程和工具调用指引

5. 批量诊断能力

• 支持从 xlsx 文件读取 Job URL 列表
• 串行逐条诊断，结果写回 xlsx 的"诊断结果"列
• 支持断点续传（跳过已诊断的行）
• 支持 --limit 参数限制诊断数量
• 每完成一条立即保存，防止中断丢失

---

📊 效果对比

指标	优化前	优化后
诊断轮数	14-20 轮	5-8 轮
工具调用	分步调用多个工具	一键获取（fetch_run_script + mcp_get_runner_logs）
跨平台	仅 Linux/macOS（bash）	Windows/Linux/macOS 全平台
批量诊断	无	支持，断点续传
集群日志	无法查询	支持 MCP 查询
日志过滤	无	自动关键词过滤
费用	-	~¥0.02-0.06/条

---

🚧 待优化项

1. MCP 工具增强 — 当前 MCP 只能查询日志，不支持 kubectl describe pod 查看 Pod Events，无法定位 NPU 资源不足、镜像拉取失败等 Event 层面的根因
2. 并发诊断 — 当前为串行，可考虑并发提升速度（需控制 API 限流）

[pkking]

目标：减少基础设施投入在CI稳定定位中的时间

进展：

• 基础设施稳定性问题，通过传统确定性的手段，可以提前与用户感知，https://github.com/KadenZhang3321/CI_stable/blob/master/Architecture%20Design/multi-cluster_infrastructure_monitoring.md 5月完成，可以解决历史问题中资源不足，
• 基础设施日志优化：因为用户错误输入，但是基础设施的日志不够清晰的情况，解决方案：优化基础设施的日志
  • 输入不存在的docker 镜像
  • 输入不存在的NPU runner规格