人人都在谈论软件工厂：即 AI 智能体可以被组装成一条流水线，自行产出可运行的软件，就像工厂把原材料加工成成品一样。关于这是否真的可行、自动化究竟能走多远，以及人们演示的那些“循环”是否真有价值，争论没完没了。有些人已经把它们判定为失败。
与此同时，还有一场更安静、也更令人担忧的讨论：开源维护者正在精疲力竭。AI 热潮让生成 issue、拉取请求和安全报告几乎零成本，却让维护者通读这一切变得极其昂贵。过去维持项目健康的老办法，在这样的数量冲击下正在崩塌。
两个话题人人都有犀利观点。我们认为自己能提供更稀缺的东西：真实的结果。过去几个月里，我们在 Astro 仓库上运行了一条自动化分诊流水线。它读取新提交的 bug 报告，在沙箱中复现，诊断根因，并发布预览版本供报告者验证。其底层引擎后来发展成了 Flue，一个用于构建这类智能体自动化的开放框架，你同样可以用这个工具来构建自己的流水线。
这并非一蹴而就。但经过大量迭代，我们用它把未关闭的 issue 从 200 多个降到了约 30 个，并预计下个月内某个时间降到零。这将是这个已有 5 年以上历史的仓库第一次出现零个未关闭 issue。
我们不是靠宣布“issue 破产”、自动关闭冷门工单或无视报告做到的。我们靠的是，用一队运行在 GitHub Actions 内部、相互隔离的 AI 子智能体来自动化 issue 分诊。下面讲讲我们是怎么走到这一步的，以及你可以带回自己项目的经验。
从一个智能体技能开始
年初，我们把重点放在自动化开发中的一个具体环节：issue 分诊。对开源项目来说，手动分诊 issue 是最耗时、最缺乏回报的工作之一。有时单个 issue 光是复现就要花上数小时，更不用说修复。这是我们开启自动化之旅的自然起点（却常被忽视）。
我们首先开发了一个智能体技能（agent skill）。这样，作为维护者，我们可以在本地开发和测试这套自动化，在自己的机器上运行编码 harness。随后，我们可以在仓库的 GitHub Action 中运行同一个 harness，完全复用同一个分诊工作流技能。
这个分诊技能完全复刻了我们手动解决 issue 时的步骤：
- 复现：克隆提供的复现仓库，验证所报告的问题。
- 诊断：对代码库进行插桩并加入日志，定位 bug 的根因。
- 验证：查阅相关测试套件、代码注释和文档，判断该行为究竟是 bug 还是预期功能。
- 修复：把复现转换成失败的单元测试，依据架构指南确定合适的解决方案，并部署修复。
LLM 常常倾向于在 bug 可能并不存在时硬凑一个解决方案，为防止这种偏差，每个阶段都由一个隔离的子智能体执行。这些子智能体把各自的发现汇总到一个 report.md 文件中，依次向后传递信息。
把技能变成自动化
在对分诊技能进行初步内部测试之后，我们的重点转向构建全自动流水线。我们特别希望把这套逻辑直接集成到 GitHub 工作流中，确保完全透明，让任何人都能轻松审计智能体的先后推理过程和操作步骤。
在接线的过程中，我们意识到整条流水线其实就是一个由 issue 标签驱动的状态机。每个新提交都以 triage needed 标签开始，一旦用户确认修复有效，就转为 fix verified。除了这些标签转换之外，流水线自身不保存任何状态；它只是回头读取 issue 现有的评论，来判断某个 issue 当前处于什么位置、接下来该做什么。
此后流程会自行运转。当智能体找到修复方案时，流水线会用 pkg.pr.new 启动一个预览版本，并把所有内容回帖到 issue 上：发现内容的摘要、完整日志，以及安装预览版的说明。原报告者随后可以在自己的项目上试用这个补丁；如果确认有效，自动化就会打开一个关联该 issue 的拉取请求。
从分诊到框架
在构建的过程中，我们不断发现，这套东西其实没有任何部分是 GitHub 专属的。响应事件、运行一连串隔离的子智能体，并把它们的推理与被允许采取的行动分开，这一切不过是一个工作流。它既可以由 GitHub issue 触发，也同样可以由 Slack 消息、定时任务或 webhook 触发。把这一认识推广成一个运行时，使其无论部署在哪里、驱动哪个模型，工作方式都相同，就成了 Flue：一个开放的、与平台无关的框架，用于构建持久化的智能体和工作流。
智能体自动化的好处
刚上线这套自动化系统时，我们共同担心它的效果，以及它可能对开发者社区产生的负面影响。当时有一种合理的担忧：依赖自动机器人回复可能显得冷冰冰，在我们维护者与用户群体之间再多添一层隔阂。
这并没有发生。如果说有什么变化，那就是我们现在与用户交流得更多了，只是换到了更有用的地方：
- 在 Discord 中直接与社区成员交流。
- 积极参与 RFC 讨论，处理新的功能请求。
- 与贡献者紧密合作，帮助把他们的想法整合进框架。
关于自动生成补丁的质量，我们的核心理念是：AI 智能体应当成功解决绝大多数新进 issue。当智能体未能找到正确的解决方案时，我们把这种失败视为代码库中潜在的架构或文档问题的信号，指向以下三个方面之一：
- 晦涩的抽象：如果智能体无法理解组件之间的边界，人类开发者很可能同样难以理解这样的代码结构。
- 文档缺失：关键代码段缺少说明其实现缘由的明确注释。
- 测试不足：代码库缺乏全面的测试覆盖，尤其是单元测试。
一个典型的例子是一系列相关的热模块替换（HMR）bug。分诊机器人反复尝试修改某个特定的 if 条件来解决问题。这一改动虽然修好了目标 bug，却因为该特定条件缺乏测试覆盖而在别处引入了回归。当我们加上一条描述性注释，解释支配该语句的确切逻辑之后，机器人就适应了，不再尝试在该区域做出错误的修改。
每次我们追查到这类失败，并补上缺失的注释、测试或更清晰的边界，机器人在代码库这一部分的表现就会明显变好，下一位处理这部分的人类开发者也同样受益。
把工作流变成 GitHub Action
最初，我们的分诊逻辑直接放在 Astro 单体仓库（monorepo）里。这种耦合让迭代变得困难；升级 Flue 或修改工作流，感觉就像在没有安全网的情况下对线上基础设施动手术。为解决这个问题，我们把逻辑解耦到一个独立、可测试的仓库中：triagebot-action。这种隔离让我们得以引入自动化测试，并在触碰主代码库之前确保稳定性。
如今，这个 action 为 Astro 的 issue 管理提供动力，并由此扩散开来。其他几个团队已经采用了它，有的直接使用，有的则 fork 它来构建适合自己项目的自动化“工厂”。后一条路径才是重点：triagebot-action 还很年轻，仍在积极演进，所以我们分享它，与其说是一个成品，不如说是一份可以阅读、学习和改造的可用参考。
该 action 本身的接线方式如下：
- uses: withastro/triagebot-action@v1
with:
read-token: ${{ secrets.GITHUB_TOKEN }}
write-token: ${{ secrets.BOT_GITHUB_TOKEN }}
cloudflare-api-key: ${{ secrets.CLOUDFLARE_API_KEY }}
cloudflare-account-id: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
triage-model: cloudflare-workers-ai/@cf/moonshotai/kimi-k2.7-code
verification-model: cloudflare-workers-ai/@cf/moonshotai/kimi-k2.6
triage-skill: .agents/skills/triage
或者让你自己的智能体指向该仓库，让它读完整套配置，包括添加状态机所依赖的标签。
无论你选哪条路，背后的理念都比我们的具体实现更重要：一个可持续的反馈循环，让维护者能专注于框架本身，而不是忙于管理积压的待办事项。代码是开放的。你可以 fork 它、精简它，或者只借用适合你项目的部分。
想构建类似的东西？请深入阅读 triagebot-action 的代码了解它如何运作，或者 fork 它作为你自己仓库自动化的起点。如果你要更认真地构建基于智能体的基础设施，那正是 Flue 的用武之地：深入了解 Flue 框架，构建属于你自己的版本。我们很期待看到你的作品。欢迎到 Astro Discord 分享你的“工厂”故事。