Bot phân loại AI của Astro giảm issue mở từ 200 xuống 30 — và nó là mã nguồn mở
Nhóm Astro của Cloudflare đã xây dựng một pipeline phân loại issue hỗ trợ AI chạy trong GitHub Actions, tái tạo lỗi, chẩn đoán nguyên nhân gốc và gửi bản sửa lỗi xem trước. Nó đã giảm issue mở từ hơn 200 xuống khoảng 30, và mã nguồn hiện được mở dưới dạng triagebot-action.

Cuộc tranh luận về nhà máy phần mềm chủ yếu là lời nói suông. Nhóm Astro của Cloudflare có thứ hiếm hơn: một ví dụ hoạt động. Họ đã xây dựng một pipeline phân loại tự động đọc các báo cáo lỗi đến, tái tạo chúng trong sandbox, chẩn đoán nguyên nhân gốc và gửi bản phát hành xem trước để người báo cáo xác minh. Nó chạy hoàn toàn trong GitHub Actions và đã giảm issue mở của Astro từ hơn 200 xuống khoảng 30 — với con số gần bằng không lần đầu tiên trong lịch sử hơn 5 năm của repo.
Pipeline là một máy trạng thái được điều khiển bởi nhãn issue. Mỗi issue mới bắt đầu với triage needed. Bot đọc các bình luận của issue để xác định vị trí và bước tiếp theo. Nó chạy bốn giai đoạn — tái tạo, chẩn đoán, xác minh, sửa lỗi — mỗi giai đoạn được xử lý bởi một subagent cô lập. Các subagent chuyển tiếp phát hiện qua tệp report.md, ngăn LLM ép buộc giải pháp khi lỗi có thể không tồn tại.
Khi bản sửa lỗi được áp dụng, bot khởi động bản phát hành xem trước với pkg.pr.new và đăng tóm tắt, nhật ký và hướng dẫn cài đặt trở lại issue. Người báo cáo kiểm tra. Nếu họ xác nhận nó hoạt động, bot mở một PR. Toàn bộ quy trình minh bạch — bất kỳ ai cũng có thể kiểm tra lý luận của agent trong chuỗi issue.
Nhóm đã khái quát hóa quy trình thành Flue, một framework mở, không phụ thuộc nền tảng để xây dựng agent và quy trình bền vững. Bản thân GitHub Action được tách thành triagebot-action, một repo độc lập với các bài kiểm tra riêng. Một số nhóm khác đã áp dụng, một số fork để xây dựng nhà máy của riêng họ.
Những gì thất bại của bot đã dạy họ
Triết lý của nhóm: nếu agent không sửa được lỗi, đó là tín hiệu cho thấy codebase có vấn đề về kiến trúc hoặc tài liệu. Ba thủ phạm: trừu tượng hóa mờ, thiếu bình luận và kiểm tra không đủ. Một ví dụ cụ thể: bot liên tục cố sửa điều kiện if trong mã HMR, sửa một lỗi nhưng phá vỡ lỗi khác vì điều kiện đó không có kiểm tra. Khi họ thêm một bình luận mô tả giải thích logic, bot ngừng mắc lỗi đó.
Mỗi thất bại trở thành một bản sửa lỗi cho codebase giúp cả bot và người đóng góp tiếp theo. Đó là chiến thắng thực sự — tự động hóa không chỉ đóng issue mà còn cải thiện sức khỏe dự án.
Kết nối đơn giản. Thêm action vào workflow của bạn, đặt một vài secret, trỏ nó vào kỹ năng phân loại của bạn:
- 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/triageMã nguồn mở. Fork nó, tinh giản nó hoặc mượn các phần phù hợp. Ý tưởng cốt lõi quan trọng hơn triển khai: một vòng phản hồi bền vững giải phóng người bảo trì để tập trung vào framework thay vì quản lý backlog.
Mỗi lần chúng tôi truy tìm một trong những thất bại này và thêm bình luận còn thiếu, bài kiểm tra hoặc ranh giới rõ ràng hơn, bot trở nên tốt hơn đáng kể ở phần đó của codebase, và cả người tiếp theo làm việc trên nó cũng vậy.