当一个开源项目积累了大量 GitHub Issue，真正消耗维护者时间的往往不是写补丁，而是确认问题能否复现、判断报告是否完整，以及验证修复是否真的有效。Astro 的维护实践给出了一个值得借鉴的方向：把人工 Issue 验证拆成多个运行在 GitHub Actions 中的隔离式 AI 子代理，让它们负责复现 Bug、检查补丁并生成预览版本。
根据文章摘要，这套流程让 Astro 的开放 Issue 数量减少了 85%。这里的关键并不是“让 AI 自动处理所有 Issue”，而是把维护流程改造成一条可审计、可重复执行的软件工厂流水线。
从人工排队到自动验证
传统 Issue 流程通常是线性的：维护者阅读报告，尝试复现，猜测根因，编写补丁，再手动验证。每一步都可能因为环境不同、信息缺失或维护者时间不足而停滞。
软件工厂的思路是把流程拆成几个边界清晰的阶段：
- 报告整理：提取运行环境、复现步骤、期望行为和实际行为。
- 问题复现：在临时工作区中安装依赖，运行测试或最小复现项目。
- 补丁生成：让代理根据复现结果提出修改，并限制修改范围。
- 补丁验证：在干净环境中重新运行回归测试，避免“修复只在代理自己的工作区有效”。
- 预览发布：对于适合验证的变更，构建一个预览版本或临时产物，交给维护者和 Issue 提交者检查。
每个子代理只需要完成一个小任务，并输出结构化结果，例如 reproduced、root_cause、tests_run 和 recommendation。这样，维护者看到的不是一段泛泛的 AI 总结，而是一份可以继续决策的验证报告。
为什么一定要隔离运行
让 AI 代理直接在主仓库或维护者电脑上执行命令，会放大安全和稳定性风险。Issue 内容来自外部用户，可能包含恶意命令、危险脚本或诱导代理泄露凭据的提示。因此，复现代理应当运行在临时分支、容器、临时虚拟机或受限权限的 GitHub Actions Runner 中。
隔离环境至少应具备这些约束：
- 使用最小权限的
GITHUB_TOKEN，默认只读。 - 不向处理外部 Issue 的任务暴露生产凭据和长期密钥。
- 限制 CPU、内存、磁盘和执行时长。
- 每次运行使用全新的工作目录，避免不同 Issue 之间污染状态。
- 将代理输出、测试日志和生成的补丁作为可追踪工件保存。
- 对任何自动创建 Pull Request、发布包或修改标签的动作增加人工审批。
隔离并不会让代理变得更聪明，但会让失败变得可控。一个错误的补丁最多污染临时分支，一个恶意的复现步骤也不应直接接触项目的发布凭据。
一个可以改造的 GitHub Actions 骨架
下面的示例展示一种简化的实现方式。它假设仓库中有一个 scripts/issue-agent.py，负责读取 Issue 内容、调用你选择的模型，并在当前工作区中运行复现和验证命令。示例中的模型调用是项目自有逻辑，接入时需要替换为实际 SDK 或内部服务。
把 ISSUE_NUMBER 作为手动输入，是为了避免未经筛选的外部 Issue 自动触发高权限任务：
name: issue-verification
on:
workflow_dispatch:
inputs:
issue_number:
description: "GitHub issue number to verify"
required: true
type: string
permissions:
contents: read
issues: read
jobs:
reproduce:
runs-on: ubuntu-latest
timeout-minutes: 20
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 1
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version-file: ".nvmrc"
cache: npm
- name: Install dependencies
run: npm ci
- name: Run isolated issue agent
env:
ISSUE_NUMBER: ${{ inputs.issue_number }}
GH_TOKEN: ${{ github.token }}
AI_API_KEY: ${{ secrets.AI_API_KEY }}
run: |
python scripts/issue-agent.py \
--issue "$ISSUE_NUMBER" \
--mode reproduce \
--output artifacts/reproduction.json
- name: Upload verification report
if: always()
uses: actions/upload-artifact@v4
with:
name: issue-${{ inputs.issue_number }}-verification
path: artifacts/
运行前需要确认三件事：仓库已经提交 .nvmrc，npm ci 可以在干净环境中完成，scripts/issue-agent.py 不会执行未经允许的任意高风险命令。若代理需要修改代码，可以把 --mode reproduce 和 --mode verify 分成两个 Job，并让验证 Job 从临时补丁分支或上传的 diff 工件开始。
代理的提示词也应该强调边界，而不是只要求“修复这个 Bug”：
你是一个负责复现 GitHub Issue 的工程代理。
任务：
1. 只根据仓库代码、Issue 内容和锁定的依赖进行调查。
2. 先尝试构造最小复现，不要直接修改默认分支。
3. 记录实际执行的命令、退出码和关键输出。
4. 如果无法复现，明确说明缺失信息和下一步建议。
5. 如果提出补丁，只修改解决问题所需的文件，并给出回归测试。
6. 不读取、输出或尝试绕过环境中的凭据。
最终输出 JSON：
{
"reproduced": true,
"root_cause": "...",
"commands": ["..."],
"tests_run": ["..."],
"patch_files": ["..."],
"recommendation": "..."
}
预览发布是验证闭环的一部分
仅仅让测试变绿，并不能证明用户遇到的问题已经解决。对于框架、构建工具和插件生态，行为通常取决于真实项目配置、浏览器环境或不同版本的依赖。预览发布可以把验证从维护者本地扩展到真实使用场景：构建一个带有临时版本号的包，或者部署一个只用于当前 Issue 的预览环境。
不过，预览发布需要明确生命周期：
- 预览包必须使用独立的版本标识，不能覆盖正式版本。
- 发布任务应与复现任务分离，并要求显式审批。
- 预览环境应自动过期，避免长期占用资源。
- Issue 中只发布必要的安装命令和验证结果，不泄露内部日志中的敏感信息。
- 验证完成后，保留补丁、测试结果和用户反馈，形成最终 Pull Request 的依据。
落地时的取舍清单
这类软件工厂最适合从低风险、重复性高的 Issue 开始，例如缺少最小复现、已有测试失败、依赖版本冲突或可以通过固定命令验证的回归问题。不要一开始就把安全漏洞、数据迁移和复杂架构变更交给全自动流程。
可以用下面的清单评估是否适合接入：
- Issue 是否包含足够的复现信息？
- 代理是否拥有完成任务所需的最小权限？
- 每次运行是否都有独立环境和超时限制？
- 结果是否包含命令、日志、测试和补丁，而不只是自然语言结论？
- 人工是否可以在发布或合并前拦截结果？
- 失败任务是否能明确区分“无法复现”“环境不足”和“代码确有问题”？
Astro 的案例说明，减少 Issue 积压不一定依赖更多人工排班，也可以依靠更细的任务拆分、更严格的执行隔离和更完整的验证闭环。AI 子代理适合承担高频调查工作，但最终的项目决策、权限控制和正式发布仍应由维护者掌握。