GitHub CI 检查修复触发器

GitHub CI 检查修复触发器功能让你在 pull request 的 CI 检查失败时，自动分配一个「修复」智能体。该智能体分析失败日志并尝试修复问题（如失败测试、lint 错误、类型不匹配）并生成后续提交。

工作原理

完整流程

1. PR 创建 → 智能体创建或更新 PR
2. CI 检查运行 → GitHub Actions、CircleCI 或其他 CI 运行测试
3. 检查失败 → (lint、测试、安全扫描等)
4. 触发器触发 → AACWorkflow 检测到失败
5. 分配修复智能体 → 自动分配修复智能体修复问题
6. 智能体分析 → 读取失败日志和错误信息
7. 实现修复 → 提交更改到 PR 分支
8. CI 重新运行 → 检查在新提交上再次运行
9. 成功或升级 → 若检查通过，PR 可合并；若仍失败，升级给人工

审批政策

你控制哪些 CI 失败触发自动修复：

• 所有失败 — 任何失败的检查触发修复
• 特定检查 — 仅特定检查（如「测试」但不「安全」）
• 可信检查 — 仅已知可修复的检查（如 lint、格式化）

设置

启用 CI 修复触发器

转到设置 → GitHub → CI 检查政策。

1. 切换自动修复 CI 检查失败 → 开启

2. 选择哪些检查可自动修复：

   • ✓ Lint 错误（通过 eslint --fix、gofmt 等修复）
   • ✓ 类型错误（通常通过 TypeScript 推断修复）
   • ✓ 格式（通过 Prettier、格式化工具自动修复）
   • ✗ 安全扫描（需审查）
   • ✗ 自定义工作流（通常需手动干预）

3. 选择修复智能体（或留空使用默认「code-fixer」）

4. 设置最大重试次数（默认：2）

5. 点击保存

分配修复智能体

默认情况下，AACWorkflow 使用自动配置的「code-fixer」智能体。要使用特定智能体：

1. 转到设置 → GitHub → CI 检查政策
2. 下拉菜单修复智能体 → 选择智能体（如「Frontend Fixer」、「Backend Fixer」）
3. 保存

选中的智能体必须：

• 对仓库有写入权限（通过 GitHub token）
• 知道如何修复你的 CI 检查的错误类型
• 可用（未被其他任务过度占用）

修复智能体如何工作

步骤 1：检测失败

当 PR 的 CI 检查失败时，AACWorkflow 从 GitHub 读取失败日志（通过 GitHub API）：

{
  "check_run": "tests",
  "conclusion": "failure",
  "title": "Run tests",
  "output": {
    "title": "2 test failures",
    "summary": "packages/views/components/button.test.tsx:42 - expect....",
    "annotations": [
      {
        "path": "packages/views/components/button.test.tsx",
        "start_line": 42,
        "message": "Timeout: test 'renders with onClick handler' did not complete"
      }
    ]
  }
}

步骤 2：分析和规划

修复智能体：

1. 本地克隆 PR 分支
2. 读取失败日志和错误注解
3. 分类失败：
   • 可修复： 语法错误、lint 违规、缺失类型、测试超时
   • 升级： 权限拒绝、基础设施失败、测试逻辑问题
4. 规划修复（如「为 async 测试添加 await」、「删除未使用变量」）

步骤 3：实现修复

修复智能体提交更改到 PR 分支：

git checkout feature/aac-42-oauth
# 修复问题（语法、类型、lint、测试）
git add .
git commit -m "fix: resolve CI check failures

- packages/views/components/button.test.tsx:42 - add await for async test
- server/cmd/server/main.go:18 - gofmt formatting
"
git push

GitHub 自动触发新 CI 运行（因为分支已更新）。

步骤 4：重试或升级

修复提交后：

• CI 通过 ✅ → PR 现可合并（仍需人工审查）
• CI 再次失败 ❌ → 若未超过 max_retry_attempts，重试逻辑启动：
  • 分析新失败
  • 规划新修复
  • 再次提交
• 超过最大重试 → 升级给人工：
  • 评论：「I've attempted 2 fixes but CI still fails. See details below.」
  • 将 PR 分支留在最佳状态
  • 分配给人工审查者

示例

示例 1：Lint 错误（自动可修复）

CI 失败： ESLint 报告 apps/web/app/page.tsx:15 中未使用变量

修复行动：

1. 检测：unused variable 'tempUser'
2. 运行：eslint --fix apps/web/app/page.tsx
3. 提交：fix: remove unused variable
4. 推送
5. CI 重新运行并通过 ✅

结果： PR 变绿；人工审查代码。

示例 2：测试超时（通常可修复）

CI 失败： packages/core/agents/agents.test.ts:120 中测试超时

修复行动：

1. 读取错误：「Test 'should handle concurrent requests' did not complete」
2. 打开文件，看到 async 操作缺少 await
3. 在 async 调用前添加 await
4. 提交：fix: add missing await in concurrent test
5. 推送
6. CI 重新运行；测试在 500ms 内完成 ✅

结果： PR 变绿。

示例 3：类型错误（可修复性差异）

CI 失败： TypeScript 报告 packages/core/api/client.ts:45 类型错误

修复行动：

1. 读取：Type 'undefined' is not assignable to type 'string'
2. 检查上下文；无法推断正确值
3. 尝试：添加类型守卫（如 ?? ''）
4. 提交并推送
5. CI 重新运行；类型检查通过 ✅

结果： PR 变绿（但人工应审查类型守卫确保正确）。

示例 4：安全检查（升级）

CI 失败： Snyk 在 package.json 中检测到易受攻击的依赖

修复行动：

1. 读取 Snyk 输出：「lodash < 4.17.21 is vulnerable」
2. 检查升级是否安全：npm update lodash
3. 测试：npm test — 全部通过 ✅
4. 但：安全检查有 require_approval: true
5. 评论：「Found vulnerable dependency; attempting upgrade.」
6. 等待人工批准后再推送修复

结果： 升级给人工；修复等待 OK。

审批与安全

信任级别

按检查类型配置信任级别：

最大重试次数

设置修复在升级前应重试的次数：

• 1 — 一次尝试；任何失败都升级
• 2 （默认）— 两次尝试；第二次失败后升级
• 3 — 三次尝试；大多数问题到第三次会被修复

API 和自动化

手动触发修复

若自动修复禁用，你可手动触发：

POST /api/workspaces/{ws}/github/pr/{pr_number}/trigger-fix

Body：

{
  "check_run_id": 12345,
  "agent_id": "550e8400-e29b-41d4-a716-446655440000"
}

为特定 PR 禁用修复

若要为单个 PR 禁用自动修复（如手动调查）：

PATCH /api/workspaces/{ws}/github/pr/{pr_number}

Body：

{
  "auto_fix_ci_enabled": false
}

重新启用：

{
  "auto_fix_ci_enabled": true
}

查询修复尝试

GET /api/workspaces/{ws}/github/pr/{pr_number}/fix-history

返回：

{
  "pr_number": 123,
  "fix_attempts": [
    {
      "attempt": 1,
      "triggered_at": "2025-06-22T15:30:00Z",
      "check_run": "tests",
      "failure_summary": "2 tests failed (timeouts)",
      "agent_id": "550e8400-e29b-41d4-a716-446655440000",
      "fix_commit": "abc123def456",
      "result": "success"
    },
    {
      "attempt": 2,
      "triggered_at": "2025-06-22T15:35:00Z",
      "check_run": "lint",
      "failure_summary": "3 ESLint violations",
      "agent_id": "550e8400-e29b-41d4-a716-446655440000",
      "fix_commit": "def456abc123",
      "result": "escalated"
    }
  ]
}

最佳实践

1. 从高信任检查开始 — lint 和格式最安全自动修复
2. 审查前几次自动修复 — 在完全信任前验证修复的判断
3. 使用专用修复智能体 — 针对错误分析和修复训练的智能体
4. 监控升级 — 若经常升级，可能是 CI 错误信息不清楚；改进日志
5. 设置合理重试限制 — 2-3 次通常能解决可修复问题

故障排除

"修复在做错误的修复"

1. 检查修复智能体的指令（设置 → 智能体）
2. 审查过去的修复尝试查找模式
3. 添加更具体的上下文到 CI 检查日志（更好的错误信息有帮助）
4. 考虑使用不同的修复智能体或添加审批关卡

"修复不断升级而不是修复"

1. 检查失败可能不可修复（如安全、基础设施）
2. 修复智能体可能缺乏上下文；检查其指令和能力
3. 若太低则增加 max_retry_attempts
4. 在智能体系统提示中添加示例指导决策

"需要手动修复但自动修复先运行了"

1. 转到 GitHub 的 PR
2. 设置 auto_fix_ci_enabled: false (通过 API 或设置)
3. 调查并手动修复根本问题
4. 问题明确后重新启用自动修复

相关功能

• GitHub 集成 — 见 GitHub 集成
• GitHub PR 创建 — 见 GitHub PR 创建流程
• 审批政策 — 见 审批政策