CI 分类智能体

自动化失败 CI 调查，生成摘要，提议修复，并通过问题和 pull request 跟踪。

当你的 GitHub Actions 管道失败时，找到根本原因通常需要读取日志、理解上下文和做出判断。AI 驱动的 CI 分类智能体可以 24/7 自动化此过程。

智能体做什么

CI 分类智能体持续监视你的 CI 运行，当构建失败时：

读取 CI 日志 — 获取 GitHub Actions 日志并解析错误输出
分析上下文 — 审查最近的提交、PR 和代码变更
生成摘要 — 写出简明的根本原因分析及代码片段
提议修复 — 建议具体改变或调试步骤
采取行动 — 创建 GitHub 问题、打开 PR 草稿或评论原始 PR
跟踪解决 — 在 PR 合并时用修复状态更新问题

设置

先决条件

AACWorkflow 工作区且有活跃智能体（参见快速入门）
GitHub 集成已启用（设置 → 集成）
智能体有 GitHub API 访问权限（repo、actions scope）

步骤 1：创建 CI 分类智能体

转到设置 → 智能体并点击新智能体
选择你的运行时和提供商（Claude Code、Codex 或类似）
命名为 ci-triage 或 build-doctor
打开其配置并添加技能或自定义提示：

角色：CI 失败调查者
任务：当 GitHub Actions 作业失败时：
1. 从 GitHub API 获取构建日志
2. 解析错误消息和堆栈跟踪
3. 检查失败提交的 git diff
4. 用 2-3 个要点总结根本原因
5. 提议单行修复或调试命令
6. 创建带标签 "ci-failure" 的 GitHub 问题
7. 将问题链接到源 PR

背景：简明扼要。专注于什么坏了，而不是什么有效。

步骤 2：接线触发器

添加 GitHub Actions 工作流 .github/workflows/notify-ci-triage.yml：

name: Notify CI Triage Agent

on:
  workflow_run:
    workflows: ["Build", "Test"]
    types: [completed]

jobs:
  notify:
    if: failure()
    runs-on: ubuntu-latest
    steps:
      - name: Trigger CI triage agent
        run: |
          curl -X POST https://aacworkflow.com/api/webhooks/ci-failed \
            -H "Authorization: Bearer ${{ secrets.AACWORKFLOW_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{
              "workflow_run_id": "${{ github.run_id }}",
              "repository": "${{ github.repository }}",
              "branch": "${{ github.ref }}"
            }'

用你的 AACWorkflow 实例的端点替换 webhook URL（或作为替代使用 Zapier/Make 集成）。

步骤 3：分配任务

将 GitHub 问题分配给 ci-triage 智能体，标签为 ci-failure。智能体会醒来并进行调查。

示例输出

输入： GitHub Actions 作业在数据库迁移测试期间因「connection timeout」失败。

智能体摘要：

根本原因： 迁移脚本超时。测试池只有 2 个连接；并行迁移耗尽池。

修复： 在测试环境中增加 DB_POOL_SIZE=5。

PR 草稿： #1437 含修复。已请求测试重新运行。

采取的行动： 创建问题 #1436 "CI: DB pool exhaustion on migration tests"，打开 PR #1437 为草稿，在原始 PR 上评论摘要。

提示和最佳实践

不要过度自动化。 智能体应调查并提议；人类应审查和合并。使用 draft PR 和 GitHub 问题评论让人类保持循环。

标签模式 — 用一致的标签（ci-failure、ci-blocking、ci-flaky）标记 CI 失败，以便你可以过滤和排序优先级
Slack 集成 — 将智能体发现传输到 Slack 频道以在团队中提高可见性
修复后重试 — 一旦修复合并，让智能体重新触发 CI 作业以确认其通过
浪费测试检测 — 如果测试在重试时通过，将其标记为浪费并创建单独的调查任务