Phương pháp nhà máy phần mềm (một vòng lặp tác nhân khép kín chạy trên đám mây) đang ngày càng trở nên phổ biến, nhưng việc áp dụng nó có thể gây e ngại. Trong bài viết này, tôi sẽ hướng dẫn các bước "bò, đi, chạy" để chuyển đổi từ các tác nhân tương tác cục bộ sang phát triển tự động hóa trên đám mây.
Bò
Nhiều lãnh đạo kỹ thuật và kỹ sư nền tảng mà tôi trao đổi đã bắt đầu giai đoạn "bò" trong quá trình xây dựng nhà máy phần mềm bằng cách tạo ra các quy trình tự động đơn giản sử dụng tác nhân đám mây.
Hãy hình dung những quy trình tự động này theo mô hình: Kích hoạt → Hoạt động của Tác nhân.
Ví dụ:
- Tái hiện và phân loại vấn đề: cho phép tác nhân xem xét tất cả các vấn đề mới được báo cáo, tái hiện chúng và gắn nhãn.
- Đánh giá mã nguồn: Tự động đánh giá các Yêu cầu Kéo (PR) ngay khi chúng được mở và để lại bình luận.
- Giám sát: có một tác nhân phản hồi cảnh báo từ Sentry, gỡ lỗi và sửa chữa sự cố.
- Tự chữa lành CI: sửa chữa CI bị hỏng bằng cách xác định các PR cần hoàn tác hoặc xung đột hợp nhất cần giải quyết.
- Tự cập nhật tài liệu: cập nhật tài liệu dành cho người dùng và tạo nhật ký thay đổi (changelog).
- Xác minh: các tác nhân browser-use và computer-use thực hiện kiểm tra chất lượng trực quan và xác minh các thay đổi.
- Sửa lỗi đơn giản: các tác nhân xác định và sửa chữa những vấn đề do người dùng báo cáo ở mức độ đơn giản.
Điểm chung của tất cả các phương pháp tiếp cận này là chúng tự động hóa một phần riêng biệt trong vòng đời phần mềm. Bắt đầu với các quy trình tự động đơn giản là cách tiếp cận rủi ro thấp, chi phí thấp và giúp xây dựng trực giác về cách sử dụng hiệu quả các tác nhân trong những nhiệm vụ phức tạp, đa giai đoạn hơn.
Quy trình tự động mẫu cho giám sát cảnh báo
Những quy trình tự động này có thể được xây dựng bằng cơ sở hạ tầng tự phát triển (ví dụ: đưa Claude Code SDK vào một container Docker và kết nối một máy chủ để kích hoạt nó), hoặc có thể sử dụng một nền tảng tự động hóa tác nhân đám mây chung được thiết kế để chạy các tác nhân dựa trên các điều kiện kích hoạt. Chúng cũng có thể sử dụng toàn bộ một nền tảng chuyên dụng cho một giai đoạn cụ thể của chu trình (ví dụ: một công cụ đánh giá mã nguồn dựa trên AI chuyên dụng hoặc SRE AI).
Việc bắt đầu với một mạng lưới các giải pháp tự động hóa điểm là ổn, nhưng hầu hết các nhóm cuối cùng đều gặp phải giới hạn với cách tiếp cận này.
Cụ thể:
- Tùy thuộc vào cách thiết lập, các quy trình tự động này có thể không chia sẻ ngữ cảnh. Điều đó có nghĩa là khi bạn cải thiện một khía cạnh (chẳng hạn như đánh giá mã nguồn), những cải tiến đó không lan tỏa sang các giai đoạn khác như phân loại và QA.
- Không có cái nhìn tổng quan về việc liệu tất cả các quy trình tự động riêng lẻ này có thực sự cải thiện năng suất tổng thể hay không, và không có cách thức hệ thống nào để thử nghiệm và cải thiện các chỉ số cấp cao mà bạn quan tâm như chi phí mỗi PR, thời gian chu kỳ, tỷ lệ tự động hóa, v.v. Để theo dõi những chỉ số này, bạn cần một hệ thống hoạt động xuyên suốt các giai đoạn phát triển.
- Mỗi giải pháp điểm đều tạo ra gánh nặng riêng về thiết lập và bảo trì. Chúng mở rộng bề mặt bảo mật cần quản lý. Chúng không có giao diện thống nhất cho khả năng quan sát. Các nhóm cuối cùng sẽ muốn cấu hình tập trung, kiểm toán và quản trị.
Đi
Tất cả những vấn đề này chỉ ra nhu cầu về một cách tiếp cận toàn diện hơn. Các tổ chức đã trải qua giai đoạn "bò" tự hỏi: "Hệ thống nào chúng ta cần để thực sự mở rộng quy mô phát triển dựa trên tác nhân?"
Cụ thể hơn, họ đặt ra các câu hỏi:
- Việc phát triển nên diễn ra ở đâu? Cục bộ hay trên đám mây? Thông qua những giao diện nào?
- Một quy trình phát triển tự động thành công trông như thế nào? Các chỉ số chính là gì?
- Lập trường về chủ quyền AI của chúng ta là gì? Việc sở hữu dữ liệu tác nhân lập trình quan trọng như thế nào? Chúng ta nên phụ thuộc bao nhiêu vào các nhà cung cấp mô hình?
- Làm thế nào chúng ta lên kế hoạch cải thiện quy trình phát triển theo thời gian? Làm sao để kiểm soát chi phí trong khi đẩy nhanh tốc độ tung sản phẩm? Làm sao để biết chúng ta đang cải thiện?
- Chúng ta chuẩn bị sẵn sàng cho tương lai như thế nào khi các mô hình và tác nhân ngày càng tốt hơn? Chúng ta có tính đến rủi ro pháp lý có thể ảnh hưởng đến quyền truy cập vào các mô hình không?
- Chính xác thì các kỹ sư nên tham gia vào quy trình phát triển như thế nào? Tương tự đối với các nhà thiết kế, PM và những người xây dựng khác?
- Chúng ta bảo mật quy trình phát triển như thế nào? Kế hoạch của chúng ta là gì nếu quy trình sản xuất phần mềm bị xâm phạm?
Hầu hết các lãnh đạo kỹ thuật và nhóm nền tảng suy nghĩ kỹ về những câu hỏi này đều đi đến một giải pháp giống như phương pháp nhà máy phần mềm trên đám mây. Họ mong muốn:
- Phát triển trên đám mây mặc định, vì việc cung cấp môi trường sandbox cho các tác nhân an toàn hơn là để chúng hoạt động tự do trên máy cục bộ.
- Quản trị tập trung các tác nhân lập trình cùng các công cụ và hệ thống mà chúng truy cập.
- Dấu vết đầy đủ về những gì các tác nhân đã thực hiện, phục vụ cho mục đích kiểm toán và hiểu rõ năng suất.
- Tính linh hoạt trong lựa chọn mô hình và khung làm việc (harness), nhằm giảm thiểu rủi ro và tối ưu hóa hiệu suất.
- Tích hợp quy trình phát triển vào tất cả các công cụ mà nhóm của bạn đã sử dụng (ví dụ: Slack/Teams, Jira, Github, v.v.).
- Các lối thoát hiểm để con người can thiệp, bằng cách điều khiển các tác nhân trực tiếp hoặc đưa công việc vào vòng lặp phát triển nội bộ.
- Một lớp ngữ cảnh chia sẻ hoạt động xuyên suốt các tác nhân ở mọi giai đoạn phát triển.
- Một cách tiếp cận cho phép thử nghiệm, đánh giá và benchmark để nhóm của bạn tin tưởng rằng hệ thống đang cải thiện theo thời gian.
Một khi công ty quyết định áp dụng phương pháp nhà máy, câu hỏi đặt ra là: làm thế nào để đạt được điều đó từ các quy trình tự động hóa điểm hiện tại? Điều này thường quy về việc (1) bạn xây dựng thêm cơ sở hạ tầng xung quanh các quy trình tự động đó hay (2) bạn chuyển đổi sang một nền tảng như Warp Factories, nơi cung cấp cơ sở hạ tầng nhà máy.
Lưu ý rằng tôi không coi đây là quyết định truyền thống giữa "xây dựng" và "mua". Dù chọn con đường nào, bạn nên dự kiến đội ngũ nội bộ vẫn phải thực hiện một số công việc xây dựng, bởi vì để phương pháp nhà máy hoạt động hiệu quả, nhà máy đó phải được tích hợp sâu vào ngữ cảnh và quy trình làm việc của nhóm bạn. Vấn đề nằm ở chỗ bạn xây dựng cơ sở hạ tầng tự động hóa hoàn toàn từ đầu, hay hợp tác với những bên cung cấp cho bạn một lợi thế khởi đầu.
Ví dụ, bất kể con đường nào bạn chọn, bạn nên dự kiến phải xây dựng các kỹ năng đặc thù cho tổ chức và tinh chỉnh chúng cho codebase của mình. Bạn nên dự kiến phải expose và cấu hình các MCP đặc thù cho tổ chức và các nguồn ngữ cảnh nội bộ. Tuy nhiên, bạn có thể không muốn tự xây dựng cơ sở hạ tầng đám mây để chạy và quản lý các tác nhân, điều khiển chúng, bàn giao công việc, đo lường hiệu quả, thực hiện computer use, v.v. Quy tắc ngón tay cái là tập trung vào việc xây dựng những phần đặc thù cho tổ chức của bạn, chứ không phải những phần mà mọi tổ chức đều cần.
Dù chọn cách tiếp cận nào, tôi gợi ý rằng cột mốc lớn nhất trong giai đoạn đi là triển khai nhà máy đầu tiên end-to-end trên một bề mặt sản phẩm đơn giản. Đây có thể là trang web marketing hoặc một ứng dụng nội bộ.
Bắt đầu với một dự án đơn giản có ưu điểm là khởi động được toàn bộ vòng lặp với rủi ro thấp và độ phức tạp tối thiểu. Việc thêm nhiều repo, dòng code, phụ thuộc dịch vụ, các bên liên quan là con người, v.v. sẽ làm tăng độ phức tạp và có thể dẫn đến cảm giác rằng bạn chưa sẵn sàng cho tự động hóa. Tốt hơn là hãy tinh chỉnh một vòng lặp đơn giản trước.
Mục tiêu là một hệ thống đa tác nhân đi từ phân loại → đặc tả → triển khai → đánh giá → xác minh → giám sát. Chi tiết hơn:
- Vấn đề mới đi vào hệ thống, thông qua con người hoặc tác nhân giám sát.
- Tác nhân phân loại chạy và cố gắng hiểu cũng như tái hiện vấn đề. Nếu nó xác định nhiệm vụ có thể tự động hóa → chuyển cho tác nhân Triển khai. Nếu cần đặc tả do phạm vi → yêu cầu tác nhân đặc tả lặp lại với con người để đưa ra đặc tả. Nếu mơ hồ → lấy ý kiến con người và chạy lại, hoặc quyết định tạm dừng vấn đề.
- [Nếu cần] Tác nhân đặc tả chạy, con người xem xét đặc tả, sau đó chuyển cho tác nhân triển khai.
- Tác nhân triển khai viết code.
- Tác nhân đánh giá mã nguồn xem xét code.
- Tác nhân xác minh thực hiện computer-use hoặc các phương pháp xác minh khác.
- Con người xem xét code và kết quả xác minh. Nếu cần, quay lại bước 2, 3, 4 hoặc 5.
- CI / CD.
- Tung sản phẩm (Ship it).
- Tác nhân giám sát chạy và tạo ra các vấn đề mới nếu cần, hoàn thành vòng lặp.
Nội bộ tại Warp, nhà máy giai đoạn đi của chúng tôi tự động hóa khoảng 75% các thay đổi đối với warp.dev, trang web marketing của chúng tôi. Khác với Warp Terminal (65k sao GitHub, gần một triệu dev hoạt động, 1 triệu dòng Rust native), trang web marketing của chúng tôi là một ứng dụng khá đơn giản. Lưu ý rằng bằng "tự động hóa", tôi có nghĩa là đi từ đầu vào của con người đến một tính năng được tung ra hoàn toàn thông qua nhà máy, với sự can thiệp tối thiểu của con người ngoài việc mô tả thay đổi mong muốn, thông qua Slack hoặc công cụ quản lý task của chúng tôi.
Chạy
Chỉ khi bạn đã thiết lập được vòng lặp cơ bản trên một dự án đơn giản, bạn mới nên mở rộng quy mô sang các dự án phức tạp hơn. Việc mở rộng quy mô các nhà máy đòi hỏi cơ sở hạ tầng mạnh mẽ hơn.
Cụ thể, khi bạn mở rộng quy mô, một số nút thắt cổ chai sẽ xuất hiện:
- Việc làm cho môi trường phát triển từ xa hoạt động trơn tru trên các dự án lớn là rất khó khăn. Nhiều repo hơn, dòng code hơn, phụ thuộc dịch vụ hơn đều làm cho tự động hóa trở nên khó khăn hơn.
- Khi bạn có nhiều kỹ năng và code hơn, v.v., việc biết chắc chắn rằng những thay đổi bạn thực hiện đối với các nhà máy đang có tác động tích cực đến phát triển hay chỉ gây ra xáo trộn trở nên khó khăn hơn.
- Bạn đương nhiên gặp rủi ro chi phí cao hơn khi các tác nhân làm việc trên các codebase phức tạp hơn vì bạn cần các mô hình mạnh mẽ hơn và các tác nhân cần chạy lâu hơn. Việc định tuyến mô hình và lựa chọn harness trở nên quan trọng hơn.
- Bảo mật và kiểm toán trở nên quan trọng hơn khi bạn áp dụng phương pháp nhà máy cho các ứng dụng người dùng then chốt.
- Càng nhiều bên liên quan ứng dụng nghĩa là càng nhiều sự phối hợp và phê duyệt từ con người. Bạn sẽ muốn một giải pháp nhà máy cho phép đầu vào đa người dùng và dấu vết kiểm toán.
- Chắc chắn các PR sẽ bắt đầu chồng chất, vì vậy bạn sẽ muốn có một chiến lược rõ ràng về việc những gì được đánh giá mã nguồn, cách bạn sử dụng xác minh và QA dựa trên tác nhân.
- Bạn sẽ muốn các công cụ mạnh mẽ hơn để đóng vòng lặp, đảm bảo rằng các thay đổi được tung ra môi trường production có chất lượng cao, không bị crash, v.v.
Theo quan điểm của tôi, việc vận hành các nhà máy ở quy mô lớn sẽ là một trong những thách thức kỹ thuật phần mềm thú vị nhất trong vài năm tới; kỹ thuật phần mềm đang trở thành kỹ thuật nhà máy. Các tổ chức có thể làm cho nhà máy của họ vững chắc, đáng tin cậy và tự cải thiện sẽ có thể tung sản phẩm nhiều hơn với chi phí tốt hơn và có lợi thế cạnh tranh.
Để các nhà máy thực sự vận hành trơn tru đòi hỏi đầu tư đáng kể. Tại Warp, chúng tôi coi đây là việc xây dựng đầy đủ stack nhà máy của bạn:
Tôi đi sâu vào từng lớp này trong bài viết sau:
https://x.com/zachlloydtweets/status/2097739116720910619
Một số điểm chính cần lưu ý mà có thể không hiển nhiên:
- Factories-as-code: một trong những lựa chọn quan trọng bạn có thể đưa ra là định nghĩa các nhà máy dưới dạng code. Điều này cho phép thử nghiệm các cấu hình nhà máy khác nhau để xem cấu hình nào hiệu quả nhất, chất lượng cao nhất, v.v.
- Đa mô hình & đa harness: bạn nên đảm bảo rằng các nhà máy của mình có thể sử dụng các mô hình mới nhất, cả frontier và open-weight, và sử dụng các harness tác nhân lập trình khác nhau như Claude Code và Codex.
- Sở hữu dữ liệu: bạn nên đảm bảo lưu trữ và sở hữu tất cả dữ liệu sinh ra từ nhà máy của mình - đây là nguyên liệu thô để cải thiện hoạt động của nó.
Trong một nhà máy vận hành trơn tru, đặc điểm chính là nó là một hệ thống vòng lặp khép kín, có thể đo lường và cải thiện được. Đây nên là mục tiêu. Trong một hệ thống như vậy, mọi người đều làm việc dựa trên cùng một ngữ cảnh, công khai, theo cách được kiểm toán và quan sát đầy đủ. Bản thân các tác nhân đang quan sát các kỹ năng và cấu hình thúc đẩy hệ thống và đề xuất các cải tiến. Các kỹ sư nền tảng có thể mở rộng hệ thống để tích hợp nó vào tất cả các hệ thống nội bộ. Các lãnh đạo kỹ thuật có thể xem các chỉ số năng suất và hiểu những thay đổi nào đang được thực hiện để cải thiện chúng. Toàn bộ hệ thống vận hành dựa trên dữ liệu thực nghiệm, không phải dựa trên cảm tính.
Tại Warp, chúng tôi đang tiến gần hơn đến tầm nhìn này. Mỗi ngày, tất cả chúng tôi đều làm việc công khai, tinh chỉnh nhà máy, giảm chi phí và cải thiện thông lượng cũng như chất lượng.
Sứ mệnh của chúng tôi là cung cấp cho các nhóm kỹ thuật tốt nhất thế giới những công cụ để xây dựng, đo lường và tối ưu hóa quy trình làm việc của riêng họ bằng cách sử dụng bất kỳ mô hình và harness cơ bản nào trên cơ sở hạ tầng mở. Những khả năng này sẽ giúp các nhóm tung ra phần mềm tốt hơn một cách nhanh chóng và hiệu quả hơn.
Warp Factories hiện đang trong giai đoạn truy cập sớm. Các công ty đủ điều kiện nhận được $10k giá trị sử dụng nhà máy.
