OpenClaw gây bão toàn cầu: Chuyện hậu trường từ những người duy trì và bảo mật dự án nguồn mở

Chỉ từ một thử nghiệm cá nhân cuối tuần vào tháng 11/2025, OpenClaw đã nhanh chóng trở thành dự án nguồn mở có tốc độ tăng trưởng ấn tượng nhất trong lịch sử GitHub. Với gần 388.000 sao, 81.000 fork và hơn 80.000 commit chỉ trong vòng 6 tháng, dự án trợ lý AI cá nhân này không chỉ đặt ra những câu hỏi mới về cách cộng đồng mã nguồn mở vận hành mà còn hé lộ những thách thức bảo mật chưa từng có tiền lệ.

Trong bài phỏng vấn video được thực hiện đúng vào thời điểm dự án tròn 6 tháng tuổi, Peter Steinberger (người sáng lập) cùng các maintainers khác đã chia sẻ những bài học xương máu về quản lý dòng pull request từ AI, cách xây dựng lại niềm tin giữa một rừng đóng góp, và tầm quan trọng của việc bảo mật chuỗi cung ứng phần mềm. Dưới đây là 10 bài học đáng chú ý nhất từ cuộc trò chuyện.

Kỷ nguyên mới: Pull request giờ đây là "prompt request"

1. Làn sóng đóng góp tự động từ AI

Các maintainers của OpenClaw không còn gọi chúng là pull request (PR) nữa. Họ gọi chúng là "prompt request" – những yêu cầu được tạo ra tự động bởi các tác nhân AI. Peter Steinberger chia sẻ:

Tôi thậm chí không gọi chúng là pull request. Tôi gọi chúng là prompt request.

Josh Lehman, một maintainer khác, cho biết có những người đóng góp mở tới hàng trăm pull request cùng lúc bằng cách chạy các "nhà máy phần mềm tự động" – chương trình quét toàn bộ mã nguồn để tìm vấn đề và tạo PR hàng loạt. Thách thức không còn là thu hút sự tham gia mà là tìm ra những đóng góp thực sự có giá trị giữa một biển hoạt động có thể làm quá tải khâu review của con người.

2. Giữ cánh cửa rộng mở cho người mới

Dù phải đối mặt với lượng PR khổng lồ, các maintainers vẫn muốn chào đón những người đóng góp lần đầu, kể cả những người không phải lập trình viên chuyên nghiệp hay những người dùng AI agent để hỗ trợ. Thay vì từ chối những đóng góp chưa hoàn chỉnh, họ tìm kiếm những ý tưởng tiềm năng và sẵn sàng làm việc cùng người đóng góp để hoàn thiện.

Tôi biết cảm giác khi nhiều năm trước, pull request đầu tiên của mình được chấp nhận là như thế nào.

Peter Steinberger nhớ lại.

Vincent Koc, kiến trúc sư trưởng của OpenClaw Foundation, bổ sung: "Một tỷ lệ đáng kể những pull request đầu tiên được merge đến từ những người không phải lập trình viên. Họ chỉ là những người có một vấn đề cụ thể và một nhu cầu."

3. AI agent giúp tiết kiệm thời gian nhưng khiến việc "dừng lại" khó hơn

Công nghệ AI mang lại hai mặt đối lập: giúp con người giải phóng thời gian nhưng cũng khiến họ khó rời xa công việc hơn. Val Alexandar từ OpenCoven chia sẻ:

Tôi đã thấy mặt còn lại của vấn đề, khi mọi người quá yêu thích nó và nhận ra rằng, nếu không ngủ đêm nay, tôi có thể hoàn thành việc mà trước đây phải mất cả một tuần.

Ngược lại, Josh Lehman dùng OpenClaw để quản lý các agent làm việc thay mình: "Tôi có ba đứa con còn rất nhỏ. OpenClaw cho phép tôi quản lý các agent làm việc để tôi có thể quay lại chơi với các con."

Sally O'Malley, kỹ sư phần mềm cao cấp tại Red Hat, tiết lộ một thực tế khác: "Đôi khi các maintainers sẽ vào kênh chat và nói: 'Tôi sẽ đi chạm cỏ đây. Tôi sẽ nghỉ vài giờ.'"

Chiến lược mới trong việc duy trì dự án

4. Kiếm niềm tin bằng cách tìm nơi mình có thể tạo giá trị

Không có con đường duy nhất để trở thành maintainer OpenClaw. Một số đến từ việc đóng góp bảo mật, số khác qua tích hợp hoặc tham gia cộng đồng. Điểm chung là họ tìm cách tạo ra giá trị và dám chịu trách nhiệm.

Hành trình của Vincent Koc bắt đầu theo cách khá hài hước: "Peter phớt lờ tôi, nên tôi nghĩ, làm sao để thu hút sự chú ý của anh ấy đây? Bảo mật." Brad Groux đến từ hướng tích hợp: "Tôi là người quen dùng sản phẩm Microsoft, nên tôi nghĩ, có plugin nào cho Microsoft Teams không?" Val Alexandar thì chọn cách đi sâu vào cộng đồng: "Tôi vào voice chat, thấy mọi người hỏi rất nhiều câu hỏi, và tôi tự hỏi, làm sao tôi có thể tạo giá trị trong những cuộc trò chuyện này?"

5. Tín hiệu niềm tin mới: Chứng minh quá trình làm việc

Khi số lượng đóng góp không còn là thước đo đáng tin cậy, nhóm đã xác định những bằng chứng giúp một pull request nổi bật: transcript của agent, ảnh chụp màn hình, kết quả kiểm thử, và lời giải thích về cách người đóng góp suy nghĩ.

Nếu bạn cung cấp transcript, chúng tôi thực sự có thể thấy cách bạn đi đến pull request và cuộc thảo luận của bạn với agent. Điều đó cực kỳ có giá trị. Nếu bạn thêm ảnh chụp màn hình, bạn có thể chứng minh rằng bạn đã kiểm thử điều này.

Peter giải thích.

Câu hỏi quan trọng không phải là code do con người hay AI viết, mà là liệu người đóng góp có thực sự hiểu tính năng đó và đã cân nhắc cách nó tương tác với phần còn lại của dự án hay không. Như Peter nhấn mạnh: "Không ai quan tâm bạn có viết code hay không, nhưng chúng tôi quan tâm bạn có thực sự suy nghĩ về tính năng này."

6. Maintainers review code AI bằng chính AI

Các maintainers ngày càng dựa vào công cụ AI để review các đóng góp do AI tạo ra, đồng thời chủ động sửa code được gửi lên hơn. Val Alexandar chia sẻ: "Mỗi khi nhận được pull request từ AI, tôi thích dùng GitHub Copilot để review tất cả. Chỉ cần nhấn một nút. Nó review và tạo ra sự rõ ràng về tất cả các tệp đính kèm, ý nghĩa của các tệp và cách chúng thay đổi."

Josh Lehman nhận thấy một sự thay đổi văn hóa: "Đây là dự án đầu tiên tôi thấy việc maintainers chỉnh sửa trực tiếp pull request của người khác trở nên bình thường. Bạn chỉ cần sửa cho đúng."

Thách thức bảo mật trong kỷ nguyên AI

7. Uy tín trở thành bề mặt tấn công

Lịch sử đóng góp cũng có thể bị thao túng. Các maintainers OpenClaw phát hiện ra việc nhân bản pull request để tạo uy tín giả. Vincent Koc giải thích:

Mọi người về cơ bản sao chép pull request của người khác. Điều họ đang cố làm là xây dựng uy tín, vì chúng tôi có những huy hiệu như số lần merge. Càng nhiều merge, đó là tín hiệu niềm tin đối với chúng tôi.

Peter kể về một công ty dùng pull request tự động để quảng bá sản phẩm của họ. Nhóm phải xác định các công việc trùng lặp và phân biệt pull request nào là bản gốc. Điều này cho thấy mã nguồn không phải thứ duy nhất cần đánh giá, mà các tín hiệu xã hội được dùng để quyết định niềm tin cũng cần được xem xét lại.

8. "An toàn mặc định" phụ thuộc vào bạn hỏi ai

Điều gì an toàn với người dùng này lại có thể bị xem là quá hạn chế với người khác. Sự đánh đổi thể hiện rõ trong thực tế: các giới hạn không gian làm việc chặt chẽ hơn tạo ra phàn nàn từ người dùng, trong khi nới lỏng có thể dẫn đến các sự cố bảo mật.

Thực sự là một trò chơi khó để tìm ra sự cân bằng giữa việc tạo sự thuận tiện tối đa cho người dùng và xây dựng một thứ gì đó đủ an toàn làm mặc định.

Peter thừa nhận.

Các mặc định an toàn phải tính đến khả năng của agent, mức độ hiểu biết của người dùng và những gì môi trường cụ thể sẵn sàng cho phép.

9. Hiểu rõ những dependency bạn đang phụ thuộc

Các cuộc tấn công chuỗi cung ứng gần đây buộc nhóm phải suy nghĩ kỹ hơn về các dependency họ sử dụng cũng như mối quan hệ với các dự án phía sau chúng. Vincent Koc cho biết:

Chúng tôi đã rà soát các dependency bằng chiếc lược dày. Kết quả là chúng tôi giảm được các dependency cốt lõi, nhưng cũng tạo dựng được mối quan hệ với các maintainers mà chúng tôi phụ thuộc.

Peter bổ sung thêm một góc nhìn quan trọng: "Không phải mặc định là các công ty thực sự cố gắng đóng góp ngược lại thay vì chỉ duy trì một fork và không quan tâm."

Hỗ trợ từ chương trình GitHub Secure Open Source Fund

10. Giá trị của sự kết nối giữa các maintainers

Những người tham gia mô tả GitHub Secure Open Source Fund như một trải nghiệm học hỏi về bảo mật lẫn cơ hội kết nối với các maintainers đang đối mặt với những vấn đề tương tự, thường là quá sức chịu đựng. Josh Avant nhớ lại bài học đầu tiên: "Người thuyết trình nói rằng, trước tiên, hãy đi lấy một tách cà phê. Bước một, hít thở. Nó kết nối chúng tôi với khía cạnh con người của việc làm maintainer."

Chương trình cũng giúp các maintainers hiểu cách "ra lệnh" cho agent hiệu quả hơn. Josh Lehman chia sẻ: "Chúng tôi có các agent và chúng có thể làm gần như bất cứ điều gì bạn yêu cầu, nhưng bạn vẫn phải biết mình cần yêu cầu chúng làm gì. Giờ tôi có khả năng biết phải yêu cầu điều gì."

Vincent nhấn mạnh giá trị của việc gặp gỡ các maintainers khác đang trải qua những khó khăn tương tự trong việc bảo mật các dự án nguồn mở. Chương trình tạo ra một cộng đồng để các nhà duy trì có thể học hỏi và dựa vào nhau khi những thách thức tiếp tục xuất hiện.

Kết luận

Câu chuyện của OpenClaw là một minh chứng rõ ràng cho thấy hệ sinh thái mã nguồn mở đã bước sang một kỷ nguyên mới – nơi AI không chỉ viết code mà còn định hình lại cách chúng ta cộng tác, tin tưởng và bảo mật phần mềm. Khi các đóng góp tăng nhanh hơn khả năng review của con người, những bài học từ đội ngũ OpenClaw sẽ là kinh nghiệm quý giá cho bất kỳ dự án nào đang phải vật lộn với sự trỗi dậy của AI trong phát triển phần mềm.

Các maintainers của OpenClaw trong buổi phỏng vấn

Đối với cộng đồng lập trình viên Việt Nam, câu chuyện này cũng là lời nhắc nhở rằng việc tham gia vào các dự án nguồn mở lớn không chỉ là cơ hội học hỏi mà còn là trách nhiệm đóng góp và bảo mật. Khi AI ngày càng phổ biến trong quy trình phát triển, việc hiểu rõ cách thức hoạt động, xây dựng niềm tin và bảo vệ chuỗi cung ứng phần mềm sẽ trở thành kỹ năng sống còn cho mọi lập trình viên.

Những bài học về bảo mật từ GitHub Secure Open Source Fund