AstroのAIトリアージボットが未解決問題を200件から30件に削減——そしてオープンソース化

ソフトウェアファクトリーの議論はほとんどが空論だ。CloudflareのAstroチームは、もっと珍しいものを持っている：実際に機能する例だ。彼らは、受け取ったバグ報告を読み、サンドボックスで再現し、根本原因を診断し、報告者が検証するためのプレビューリリースを提供する自動トリアージパイプラインを構築した。これはすべてGitHub Actions内で実行され、Astroの未解決問題を200件以上から約30件に削減した——リポジトリの5年以上の歴史で初めてゼロが見えている。

パイプラインは、イシューラベルによって駆動されるステートマシンだ。新しいイシューはすべてtriage neededから始まる。ボットはイシューのコメントを読み、現在の状態と次に何をすべきかを判断する。再現、診断、検証、修正の4つのフェーズを実行し、それぞれが独立したサブエージェントによって処理される。サブエージェントはreport.mdファイルを介して発見事項を引き継ぎ、バグが存在しない可能性がある場合にLLMが解決策を強制するのを防ぐ。

修正が完了すると、ボットはpkg.pr.newでプレビューリリースを起動し、サマリー、ログ、インストール手順をイシューに投稿する。報告者がそれをテストする。動作が確認されれば、ボットはPRを開く。全体が透明で、誰でもイシュースレッドでエージェントの推論を監査できる。

チームはこのワークフローを、耐久性のあるエージェントとワークフローを構築するためのオープンでプラットフォームに依存しないフレームワークであるFlueに一般化した。GitHub Action自体は、独自のテストを持つ独立したリポジトリであるtriagebot-actionに分離されている。他のいくつかのチームがこれを採用し、中には独自のファクトリーを構築するためにフォークしたチームもある。

ボットの失敗が教えてくれたこと

チームの哲学：エージェントがバグを修正できない場合、それはコードベースにアーキテクチャまたはドキュメントの問題があるというシグナルだ。3つの原因：不透明な抽象化、コメントの欠落、不十分なテスト。具体的な例：ボットはHMRコードのif条件を変更しようとし続け、1つのバグを修正したが、その条件にテストカバレッジがなかったため他のバグを壊した。ロジックを説明する説明的なコメントを追加すると、ボットはその間違いを犯さなくなった。

すべての失敗は、ボットと次の人間のコントリビューターの両方に役立つコードベースへの修正となる。これが本当の勝利だ——自動化は単にイシューを閉じるだけでなく、プロジェクトの健全性を向上させている。

配線は簡単だ。アクションをワークフローに追加し、いくつかのシークレットを設定し、トリアージスキルを指定する：

      - 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

コードはオープンだ。フォークして、削ぎ落として、または合う部分を借用してほしい。根底にあるアイデアは実装よりも重要だ：メンテナーがバックログの管理ではなくフレームワークに集中できるようにする持続可能なフィードバックループ。