analyze-github-action-logs

分析 GitHub Actions 日志

获取并分析指定工作流最近的 GitHub Actions 运行记录。检查 Agent/步骤的表现，找出浪费的精力和错误，并生成包含可执行改进措施的报告。

输入

需要提供：

• workflow（必填）——工作流文件名或 ID（例如：issue-triage.yml、deploy.yml）。
• repo（可选）——采用 OWNER/REPO 格式的 GitHub 仓库。默认为 withastro/astro。
• count（可选）——要分析的最近已完成运行记录数量。默认为 5。

第 1 步：列出最近的运行记录

获取该工作流最近已完成的运行记录。使用 --status=completed 进行筛选：

gh run list --workflow=<workflow> -R <repo> --status=completed -L <count>

列出这些记录以便了解情况：运行 ID、标题、状态（成功/失败）和耗时。选择要分析的运行记录——如果可能，尽量兼顾成功和失败的记录；优先选择执行了更多步骤的记录（较长的运行通常会经过更多阶段，而较短的运行可能会提前退出）。

第 2 步：获取日志

对于每条要分析的运行记录，将完整日志保存到临时文件：

gh run view <run_id> -R <repo> --log > /tmp/actions-run-<run_id>.log

第 3 步：确定步骤/技能边界

在每个日志文件中搜索可标记步骤或技能开始和结束位置的标记。标记取决于工作流，请留意以下模式：

• Flue 技能标记：[flue] skill("..."): starting / completed
• GitHub Actions 步骤标记：日志输出中的步骤名称标题
• 自定义标记：工作流使用的任何 START/END 或类似分隔符

grep -n "skill(\|step\|START\|END\|starting\|completed" /tmp/actions-run-<run_id>.log | head -50

据此确定每个步骤/技能对应的行范围。同时查找结果标记：

grep -n "RESULT_START\|RESULT_END\|extractResult" /tmp/actions-run-<run_id>.log

注意：某些日志文件可能包含二进制字节或空字节。必要时使用 grep -a。

第 4 步：分析每个步骤（使用子 Agent）

对于每个已运行的步骤/技能，启动一个子 Agent，分析该部分日志。这对于避免将数千行日志塞入上下文至关重要。

为每个子 Agent 提供：

1. 日志文件路径以及该步骤对应的行范围
2. 如果工作流有技能指令文件，要求子 Agent 先阅读，以了解背景
3. 运行记录的标题/上下文，以便子 Agent 理解执行内容
4. 以下分析标准

分析标准

要求每个子 Agent 评估：

1. 正确性——该步骤的最终结果/结论是否正确？
2. 效率——耗时多久？合理的基准是什么？哪些地方浪费了时间？
3. 错误——错误的工具调用、未做改动便重试失败的命令、不必要的重新构建等。
4. 指令遵循情况——如果有技能指令，Agent 是否遵循了这些指令？在哪些地方有所偏离？
5. 范围蔓延——Agent 是否执行了本应由其他步骤完成的工作？
6. 建议——提出具体、可执行的改动，以避免发现的问题。

要求每个子 Agent 按结构化格式返回结果，包含：摘要、时间分析、发现的问题（附每项预估浪费的时间）以及改进建议。

第 5 步：汇总报告

所有子 Agent 返回结果后，将其综合为一份报告。结构如下：

各次运行摘要表

对于每条已分析的运行记录，包含一张表：

步骤/技能	时间	结果	浪费的时间	主要问题

跨运行共性模式

找出在多次运行或多个步骤中反复出现的问题。这些是最有价值的改进方向。常见模式包括：

• 滥用 TodoWrite — Agent 在自动化运行期间浪费时间管理任务列表
• 服务管理失败 — 端口冲突、进程终止失败、日志文件过期
• 工具误用 — 使用 curl 而不是 gh、找不到 jq 等
• 范围蔓延 — 某个步骤执行了本应由其他步骤完成的工作
• 不必要的重新构建 — 在没有变更的情况下多次构建软件包
• 测试超时 — 运行耗时较长的 E2E/Playwright 测试并发生超时
• 违反指令 — Agent 执行了指令明确禁止的操作
• 重复工作 — 重复读取文件、重复运行搜索、重复安装依赖

优先级建议

根据所有运行中预计节省的时间，对改进建议排序。每项建议需说明：

1. 修改内容 — 要编辑哪些文件，以及要添加或修改什么
2. 原因 — 该建议针对的模式，以及运行记录中的证据
3. 预计影响 — 每次运行可节省多少时间

输出

提交完整的汇总报告。不要编辑任何工作流或技能文件——只报告发现和建议。用户将决定应用哪些更改。