Astro 如何用 AI 自动化把 GitHub Issue 从 200 多个降到约 30 个
背景：开源维护正在被 Issue 淹没
围绕“软件工厂”的讨论越来越多：把多个 AI Agent 组织成流水线，让它们像工厂一样从需求或问题报告中产出可工作的软件。与此同时，开源维护者面对的压力也在上升。AI 让生成 Issue、Pull Request 和安全报告变得更容易，但维护者逐条阅读、复现和判断这些内容的成本却很高。
Astro 团队过去几个月在其仓库中运行了一套自动化 Issue 分诊流水线。它会读取新提交的 Bug 报告，在沙箱中复现问题，诊断根因，并在找到修复方案后发布预览版本供报告者验证。
这套流程并非一开始就成功。经过多轮迭代后，Astro 的开放 Issue 数量从 200 多个降到约 30 个，减少约 85%。团队预计有机会在下个月达到 0 个开放 Issue；如果实现，这将是该仓库 5 年多历史上的首次。
值得注意的是，这不是通过“Issue 破产”、批量关闭冷门问题或忽略报告实现的，而是通过在 GitHub Actions 中运行一组隔离 AI 子代理来自动化分诊流程。
从一个 Agent 技能开始
Astro 团队最初聚焦在一个具体场景：Issue 分诊。对开源项目来说，手动分诊往往耗时且回报感较低。一个 Issue 有时仅复现就需要数小时，更不用说后续修复。
他们先开发了一个可本地运行的 Agent 技能，让维护者能够在自己的机器上测试自动化流程。随后，同一套流程可以在仓库的 GitHub Action 中运行，实现复用。
这套分诊技能模拟了维护者手动处理问题的步骤：
- 复现：克隆用户提供的复现仓库，确认报告的问题是否存在。
- 诊断：为代码库添加日志或插桩，定位 Bug 根因。
- 验证：查看测试、注释和文档，判断该行为是 Bug 还是预期功能。
- 修复：将复现案例转成失败的单元测试，依据架构说明寻找合适修复方案，并实现修复。
为了减少大语言模型倾向于“强行给出解决方案”的问题，每个阶段都由独立子代理执行。子代理之间不共享完整上下文，而是按顺序把发现整理到一个 report.md 文件中，再传递给下一阶段。
用 Issue 标签驱动状态机
在内部测试之后，团队把这套分诊技能改造成完整自动化流水线，并集成到 GitHub 工作流中。
他们发现，这套系统本质上是一个由 Issue 标签驱动的状态机：
- 新提交的问题会被标记为需要分诊。
- 用户确认修复有效后，问题会进入修复已验证状态。
- 流水线自身不保存额外状态，而是读取 Issue 中已有评论和标签，判断当前阶段以及下一步应执行的动作。
当 Agent 找到修复方案后，流水线会生成预览版本，并把以下内容回写到 Issue：
- 自动诊断摘要
- 完整运行日志
- 预览版本安装说明
原始报告者可以在自己的项目中验证补丁。如果确认有效，自动化系统会创建一个关联该 Issue 的 Pull Request。
从分诊流程扩展成通用框架
在实现过程中，团队意识到这套机制并不只适用于 GitHub。它的核心模式包括：
- 响应某个事件
- 运行一组隔离子代理
- 区分代理的推理过程与允许执行的动作
- 在多个步骤之间传递结构化结果
这些流程同样可以由 Slack 消息、定时任务或 Webhook 触发。基于这一抽象，团队将相关能力泛化为一个平台无关的 Agent 工作流框架，用于构建可持久运行的自动化流程。
自动化带来的维护方式变化
团队最初担心自动化 Bot 会让社区体验变得冷漠，减少维护者与用户之间的直接交流。但实际结果相反：维护者仍然与用户沟通，只是把时间更多花在更有价值的地方，例如：
- 在社区讨论中直接回应用户
- 参与 RFC 和新功能请求讨论
- 与贡献者协作，将想法合入框架
对于自动补丁的质量，团队形成了一个判断：如果 Agent 无法找到正确方案，这往往暴露出代码库本身存在某种可改善的问题，例如：
- 抽象边界不清晰：Agent 无法理解组件边界时，人类开发者可能也会遇到类似困难。
- 文档缺失：关键代码缺少解释设计原因的注释。
- 测试不足：仓库缺少覆盖关键逻辑的单元测试。
一个具体例子是若干热模块替换相关 Bug。分诊 Bot 多次尝试修改某个 if 条件来修复问题。虽然修改解决了目标 Bug，却因为该条件缺少测试覆盖，在其他地方引入回归。团队随后为该逻辑补充了描述性注释，明确说明该判断的边界和原因。之后，Bot 不再尝试对该位置做出错误修改。
这说明，自动化失败并不只是工具问题，也可能提示项目需要补充测试、注释或更清晰的架构边界。而这些改进同样会帮助后续的人类维护者。
把流程封装成独立 GitHub Action
最初，Astro 的分诊逻辑直接放在主仓库中。这导致迭代困难：升级底层框架或修改工作流都像是在生产环境中做手术。
为了解决这个问题，团队将逻辑拆分为独立、可测试的仓库，并封装成 GitHub Action。这样可以先在独立环境中加入自动化测试，确认稳定后再用于主代码库。
目前，这个 Action 已用于 Astro 的 Issue 管理，也被其他团队采用。有些团队直接使用，有些则 fork 后改造成适合自身项目的自动化流程。
团队也强调，这套 Action 仍然年轻并在持续演进，更适合作为可阅读、可学习、可改造的参考实现，而不是一个完全成熟的通用产品。
对开源项目的启发
这套实践的关键不在于某个具体工具，而在于一种可持续反馈循环：
- 用自动化承担重复、耗时的 Issue 复现与初步诊断
- 让维护者把更多时间投入架构、社区讨论和关键决策
- 将 Agent 的失败转化为改善代码库文档、测试和抽象边界的信号
- 用透明的日志、评论和状态标签保证流程可审计
对大型开源项目来说，Issue 分诊可能是 AI Agent 自动化最现实的切入点之一。它不要求完全替代维护者，而是把大量前置验证工作自动化，让维护者在更高质量的信息基础上做判断。