Cloudflare dùng 'nhà máy phần mềm' AI để xử lý sạch lỗi trên GitHub của Astro

Mọi người đang bàn tán về các "nhà máy phần mềm" (software factories): ý tưởng rằng các AI agent có thể được lắp ráp thành một quy trình tự động tạo ra phần mềm hoàn chỉnh, giống như cách một nhà máy biến nguyên liệu thô thành thành phẩm. Có vô vàn tranh luận về việc liệu điều này có thực sự khả thi hay không, mức độ tự động hóa có thể đạt tới đâu, và liệu các "vòng lặp" mà mọi người đang trình diễn có thực sự mang lại giá trị gì không. Một số người đã sớm coi đây là một thất bại.

Song song với đó là một cuộc trò chuyện trầm lắng và đầy lo âu hơn: những người duy trì dự án mã nguồn mở (open source maintainers) đang dần kiệt sức. Cơn sốt AI đã khiến việc tạo ra các issue, pull request và báo cáo bảo mật trở nên gần như miễn phí, nhưng lại cực kỳ tốn kém đối với người duy trì khi phải đọc qua tất cả. Những cách thức cũ để giữ cho một dự án khỏe mạnh đang dần sụp đổ trước khối lượng công việc khổng lồ này.

Ai cũng có những ý kiến trái chiều về cả hai chủ đề trên. Chúng tôi tin rằng mình có một thứ hiếm hoi hơn để chia sẻ: kết quả thực tế. Trong vài tháng qua, chúng tôi đã vận hành một quy trình phân loại tự động trên kho lưu trữ Astro. Nó đọc các báo cáo lỗi gửi đến, tái hiện chúng trong các môi trường sandbox, chẩn đoán nguyên nhân gốc rễ và xuất bản các bản phát hành thử nghiệm (preview releases) để người báo cáo xác minh. Công cụ cốt lõi bên dưới đã phát triển thành Flue, một framework mở để xây dựng loại hình tự động hóa bằng agent này, và đó cũng chính là công cụ bạn có thể sử dụng để xây dựng hệ thống của riêng mình.

Nó không thành công ngay lập tức. Nhưng thông qua rất nhiều lần lặp lại, chúng tôi đã sử dụng nó để giảm số lượng issue mở từ hơn 200 xuống còn khoảng 30, và chúng tôi dự kiến sẽ đạt con số 0 vào tháng tới. Đó sẽ là lần đầu tiên kho lưu trữ này không còn issue mở nào trong suốt hơn 5 năm lịch sử của nó.

Chúng tôi không đạt được điều đó bằng cách tuyên bố "phá sản issue", tự động đóng các ticket cũ hay phớt lờ các báo cáo. Chúng tôi thực hiện điều đó bằng cách tự động hóa việc phân loại issue với một đội ngũ các AI subagent biệt lập chạy ngay bên trong GitHub Actions. Đây là câu chuyện về cách chúng tôi đã làm được điều đó và những gì bạn có thể áp dụng cho các dự án của riêng mình.

Bắt đầu với một kỹ năng của agent

Vào đầu năm, chúng tôi tập trung vào việc tự động hóa một lĩnh vực phát triển cụ thể: phân loại issue (issue triage). Là một dự án mã nguồn mở, việc phân loại issue thủ công có thể là một trong những phần tốn thời gian và ít mang lại sự hài lòng nhất. Đôi khi chỉ riêng việc tái hiện một issue duy nhất đã mất hàng giờ đồng hồ, chưa nói đến việc sửa lỗi. Đây là một điểm khởi đầu tự nhiên (nhưng thường bị bỏ qua) cho hành trình tự động hóa của chúng tôi.

Chúng tôi bắt đầu bằng việc phát triển một kỹ năng cho agent. Điều này cho phép chúng tôi phát triển và kiểm thử tính năng tự động hóa cục bộ với tư cách là người duy trì, chạy một bộ khung mã hóa (coding harness) trên chính máy tính của mình. Sau đó, chúng tôi có thể chạy chính bộ khung đó trong một GitHub Action trên repo của mình và tận dụng hoàn toàn kỹ năng quy trình phân loại đó.

Kỹ năng phân loại này phản ánh chính xác các bước chúng tôi thực hiện trong quá trình giải quyết issue thủ công:

Để ngăn chặn xu hướng thường thấy của LLM là ép buộc đưa ra giải pháp ngay cả khi lỗi có thể không tồn tại, mỗi giai đoạn được thực hiện bởi một subagent biệt lập. Các subagent này chuyển tiếp thông tin một cách tuần tự bằng cách tổng hợp những gì chúng tìm thấy vào một tệp report.md.

Biến kỹ năng thành một quy trình tự động

Sau khi kiểm thử nội bộ ban đầu về kỹ năng phân loại, trọng tâm của chúng tôi chuyển sang xây dựng một quy trình hoàn toàn tự động. Chúng tôi đặc biệt muốn tích hợp logic này trực tiếp vào một workflow của GitHub, đảm bảo tính minh bạch hoàn toàn để bất kỳ ai cũng có thể dễ dàng kiểm tra quá trình suy luận tuần tự và các bước vận hành của agent.

Khi kết nối mọi thứ lại, chúng tôi nhận ra toàn bộ quy trình thực chất chỉ là một máy trạng thái (state machine) được điều khiển bởi các nhãn (labels) của issue. Mỗi bài đăng mới bắt đầu với nhãn "triage needed", và khi người dùng xác nhận bản sửa lỗi, nó sẽ chuyển sang "fix verified". Ngoài các chuyển đổi nhãn đó, quy trình không lưu giữ trạng thái riêng; nó chỉ đơn giản đọc lại các bình luận hiện có của issue để xác định issue đó đang ở đâu và điều gì nên xảy ra tiếp theo.

Từ đó, luồng công việc tự chạy. Khi các agent tìm ra bản sửa lỗi, quy trình sẽ khởi chạy một bản phát hành thử nghiệm với pkg.pr.new và đăng mọi thứ trở lại issue: tóm tắt những gì nó tìm thấy, nhật ký đầy đủ và hướng dẫn cài đặt bản thử nghiệm. Người báo cáo ban đầu sau đó có thể thử bản vá trên dự án của họ, và nếu họ xác nhận nó hoạt động, hệ thống tự động sẽ mở một pull request liên kết với issue đó.

Từ phân loại đến một framework

Khi xây dựng hệ thống này, chúng tôi nhận thấy không có gì trong đó thực sự chỉ dành riêng cho GitHub. Phản ứng với một sự kiện, chạy một chuỗi các subagent biệt lập và tách biệt quá trình suy luận của chúng khỏi các hành động mà chúng được phép thực hiện — tất cả chỉ là một workflow. Một workflow có thể chạy tốt từ một tin nhắn Slack, một cron job hoặc một webhook cũng như từ một GitHub issue. Việc khái quát hóa nhận thức đó thành một runtime hoạt động giống nhau bất kể nó được triển khai ở đâu, hoặc nó đang điều khiển mô hình nào, chính là Flue: một framework mở, không phụ thuộc vào nền tảng để xây dựng các agent và workflow bền vững.

Lợi ích của tự động hóa bằng agent

Khi chúng tôi lần đầu ra mắt hệ thống tự động này, chúng tôi đã chia sẻ những lo ngại về hiệu quả của nó và những tác động tiêu cực tiềm ẩn đối với cộng đồng nhà phát triển. Có một nỗi sợ chính đáng rằng việc dựa vào các phản hồi tự động của bot có thể tạo cảm giác thiếu cá nhân và tạo thêm một khoảng cách giữa chúng tôi với tư cách là người duy trì và cộng đồng người dùng.

Điều đó đã không xảy ra. Ngược lại, giờ đây chúng tôi trò chuyện với người dùng nhiều hơn, chỉ là ở những nơi hữu ích hơn:

Về chất lượng của các bản vá tự động, triết lý cốt lõi của chúng tôi là các AI agent phải giải quyết thành công phần lớn các issue gửi đến. Khi một agent không xác định được giải pháp đúng, chúng tôi coi thất bại đó là dấu hiệu của một vấn đề kiến trúc hoặc tài liệu tiềm ẩn trong codebase, chỉ ra một trong ba lĩnh vực:

Một ví dụ rõ ràng đã xảy ra với một loạt các lỗi liên quan đến Hot Module Replacement (HMR). Bot phân loại đã nhiều lần cố gắng sửa đổi một điều kiện "if" cụ thể để giải quyết vấn đề. Mặc dù thay đổi này đã sửa được lỗi mục tiêu, nhưng nó lại gây ra lỗi ở những nơi khác do thiếu độ bao phủ kiểm thử (test coverage) cho điều kiện cụ thể đó. Khi chúng tôi thêm một bình luận mô tả giải thích chính xác logic điều khiển câu lệnh đó, bot đã thích nghi và ngừng cố gắng thực hiện các sửa đổi không chính xác ở khu vực đó.

Mỗi khi chúng tôi truy vết một trong những thất bại này và thêm bình luận, bài kiểm tra hoặc ranh giới rõ ràng còn thiếu, bot lại trở nên tốt hơn đáng kể ở phần đó của codebase, và người tiếp theo làm việc với nó cũng vậy.

Biến workflow thành một GitHub Action

Ban đầu, logic phân loại của chúng tôi nằm trực tiếp trong monorepo của Astro. Sự kết hợp này khiến việc lặp lại trở nên khó khăn; việc nâng cấp Flue hoặc sửa đổi workflow giống như thực hiện phẫu thuật trên cơ sở hạ tầng đang hoạt động mà không có lưới an toàn. Để giải quyết vấn đề này, chúng tôi đã tách logic thành một kho lưu trữ độc lập, có thể kiểm thử: triagebot-action. Sự cô lập này cho phép chúng tôi giới thiệu kiểm thử tự động và đảm bảo tính ổn định trước khi chạm vào codebase chính.

Ngày nay, action này vận hành việc quản lý issue trong Astro và đã lan rộng từ đó. Một số đội ngũ khác đã sử dụng nó, một số dùng trực tiếp, và những người khác thì fork nó để xây dựng các "nhà máy" tự động hóa riêng phù hợp với dự án của họ. Con đường thứ hai đó thực sự là mục đích chính: triagebot-action còn non trẻ và vẫn đang tích cực phát triển, vì vậy chúng tôi chia sẻ nó không phải như một sản phẩm hoàn thiện mà như một tài liệu tham khảo thực tế để bạn có thể đọc, học hỏi và điều chỉnh.

Cấu trúc kết nối cho chính action này trông như sau:

Hoặc hướng agent của riêng bạn vào kho lưu trữ và để nó đọc qua phần thiết lập, bao gồm cả việc thêm các nhãn mà máy trạng thái dựa vào.

Dù bạn chọn con đường nào, ý tưởng cốt lõi vẫn quan trọng hơn cách triển khai cụ thể của chúng tôi: một vòng lặp phản hồi bền vững giúp người duy trì tập trung vào chính framework thay vì quản lý backlog. Mã nguồn đã được mở. Hãy fork nó, tinh giản nó, hoặc chỉ cần mượn những phần phù hợp với dự án của bạn.

Bạn muốn xây dựng một thứ như thế này? Hãy tìm hiểu mã nguồn của triagebot-action để xem cách nó hoạt động, hoặc fork nó làm điểm khởi đầu cho việc tự động hóa kho lưu trữ của riêng bạn. Và nếu bạn đang xây dựng cơ sở hạ tầng dựa trên agent một cách nghiêm túc hơn, đó chính xác là mục đích của Flue: hãy đi sâu vào framework Flue để tự xây dựng hệ thống của mình. Chúng tôi rất mong được thấy những gì bạn tạo ra. Hãy đến chia sẻ câu chuyện "nhà máy" của bạn trong Astro Discord.