Mọi người đều nói về Học Liên tục (Continual Learning) như thể nó chỉ có một ý nghĩa duy nhất: cập nhật trọng số mô hình. Nhưng có một sự thật bất tiện về hệ sinh thái agent — phần lớn các agent đang được đưa vào sản xuất hiện nay đều tận dụng các mô hình tiên tiến đóng (closed frontier models). Khi bạn không sở hữu trọng số, chắc chắn bạn không thể tinh chỉnh chúng. Đối với hầu hết những người xây dựng agent, việc học liên tục ở cấp độ trọng số là điều không thể, đặc biệt khi làm việc ở rìa xa nhất của khả năng (hãy nghĩ đến Fable 5 hay GPT 5.6).
Điều đó không có nghĩa là agent không thể học. Các hệ thống agent có thể cải thiện ở ba lớp — mô hình (model), dây cương (harness) và ngữ cảnh (context) [0] — và hai lớp cuối hoàn toàn nằm trong tầm kiểm soát của bạn. Đây chính là nơi ẩn chứa cơ hội lớn (nhưng thường bị bỏ qua): học ở cấp độ dây cương cho phép bạn khai thác các dấu vết sản xuất để cải thiện một cách có hệ thống mã nguồn, công cụ và hướng dẫn cung cấp năng lượng cho mọi phiên bản agent của bạn, trong khi học ở cấp độ ngữ cảnh cho phép bạn cá nhân hóa ở cấp độ agent, người dùng và tổ chức, để sản phẩm của bạn ngày càng tốt hơn sau mỗi lần tương tác. Làm được tất cả những điều trên, bạn sẽ tích lũy được những cải tiến mà bạn có thể triển khai hàng ngày.
Trong phần còn lại của bài viết này, tôi sẽ trình bày chi tiết cách chúng tôi đã áp dụng học liên tục cho Replit Agent trong năm qua và chia sẻ tất cả những bài học kinh nghiệm mà chúng tôi đã học được trên đường đi.
Đánh giá và cải thiện Replit Agent trên quy mô lớn
Hầu hết người dùng Replit Agent đều bắt đầu với một ý tưởng. Họ mô tả mục tiêu bằng ngôn ngữ tự nhiên — mà không có kho lưu trữ (repo), bộ kiểm thử hay framework đã chọn — và mong đợi agent biến nó thành một ứng dụng hoạt động. Kết quả có thể là một trang web, một bản trình chiếu (slide deck), một ứng dụng di động, một số tạo phẩm được kết nối với nhau, hoặc một thứ gì đó hoàn toàn khác.
Các lập trình viên theo phong cách "vibe coding" thường không kiểm tra sự khác biệt (diffs) hay đầu ra của bài kiểm tra. Thành công của Replit Agent đơn giản một cách đánh lừa: ứng dụng sẽ hoạt động khi người dùng nhấp vào.
Điều đó làm thay đổi công việc đánh giá. Một điểm số duy nhất có thể giúp ích cho một quyết định triển khai cụ thể, nhưng nó không thể cho chúng tôi biết, tuần này qua tuần khác, liệu Replit Agent có đang trở nên tốt hơn cho người dùng hay không. Để trả lời câu hỏi đó, việc đánh giá phải trở thành một phần của vòng lặp cải tiến.
Phòng Điều khiển Trung tâm của Trung tâm Nghiên cứu Lewis NASA trong Tòa nhà Nghiên cứu Động cơ, năm 1968 — Đo lường có ý nghĩa khi nó thay đổi những gì được triển khai.
Đánh giá bây giờ phải làm được nhiều hơn thế
Đánh giá Agent trước đây thường giống như một quy trình một chiều: chạy đánh giá, tạo ra điểm số và đưa ra quyết định triển khai. Điều này hiệu quả khi các bản phát hành diễn ra chậm và thứ được đo lường hiếm khi thay đổi. Nó sẽ sụp đổ khi các mô hình, lời nhắc (prompts), công cụ và bề mặt sản phẩm đều thay đổi nhanh chóng.
Vòng lặp cũ khiến việc đánh giá có vẻ bị giới hạn. Nhưng Replit Agent thay đổi quá nhanh để một điểm số duy nhất có thể đưa ra toàn bộ quyết định. Một điểm số có thể so sánh hai ứng viên trên một lát cắt nhiệm vụ. Nó không thể giải thích người dùng quan tâm đến điều gì, sản xuất đang hỏng ở đâu, hoặc cần cải thiện điều gì tiếp theo.
Đánh giá phải chuyển từ kiểm tra phát hành sang vòng lặp cải tiến.
Công việc đánh giá cũ kết thúc ở quyết định triển khai của con người; công việc mới nuôi dưỡng một hệ thống liên tục học hỏi từ sản xuất và triển khai các agent đã được cải tiến.
Hệ thống có hai trụ cột đo lường và một vòng lặp tối ưu hóa. Các điểm chuẩn ngoại tuyến (offline benchmarks) cho chúng tôi biết liệu các thay đổi ứng viên có thể hoàn thành các nhiệm vụ xây dựng ứng dụng mô phỏng trước khi chúng tôi triển khai chúng hay không. Các thử nghiệm A/B trực tuyến và dấu vết sản xuất cho thấy người dùng thực tế bị ảnh hưởng như thế nào sau khi các thay đổi được triển khai. Những tín hiệu đó sau đó được đưa trở lại vào các đánh giá và quyết định triển khai.
Không có lớp nào là đủ một mình. Các điểm chuẩn phát hiện hồi quy trước khi phát hành. Các thử nghiệm A/B cho thấy liệu hành vi sản xuất có thay đổi hay không. Các cụm dấu vết giải thích các lỗi ẩn dưới các chỉ số tổng hợp. Phán đoán của con người giữ cho vòng lặp cải tiến hướng đến các kết quả kỹ thuật và sản phẩm phù hợp. Hình dạng tương tự như mô hình phô mai Thụy Sĩ trong kỹ thuật an toàn: mỗi lớp đều có lỗ hổng, nhưng cùng nhau chúng bắt được nhiều hơn bất kỳ lớp đơn lẻ nào.
Các điểm chuẩn hiện tại không chạm tới người dùng
Các điểm chuẩn mã hóa agent như SWE-bench [1] và Terminal-Bench [2] chấm điểm mã trong các môi trường có thể lặp lại và bị ràng buộc. Các điểm chuẩn này có giá trị và được áp dụng rộng rãi, nhưng chúng bỏ lỡ tín hiệu mà một lập trình viên "vibe coding" quan tâm.
Replit Agent thường tạo mã nguồn từ đầu. Người dùng không mang theo các route, chữ ký hàm, bộ chọn hay bài kiểm tra cố định; họ mang theo một yêu cầu sản phẩm. Agent chọn ngăn xếp công nghệ (stack), lược đồ (schema), route, thành phần và luồng tương tác.
Điều đó tạo ra một khoảng cách về tính đúng đắn chức năng. Một agent có thể thỏa mãn các ràng buộc cục bộ của một điểm chuẩn mã hóa và vẫn thất bại ở những gì người dùng thấy: liệu ứng dụng đã hoàn thành có làm được những gì được yêu cầu hay không. Đối với "vibe coding", mục tiêu đánh giá chính là tạo phẩm: nó có tải không, quy trình làm việc cốt lõi có hoạt động không và kết quả có khớp với yêu cầu không?
Giới thiệu ViBench
Nhu cầu về phong cách đánh giá đầu cuối này chính xác là lý do tại sao chúng tôi xây dựng ViBench [3], điểm chuẩn công khai của chúng tôi cho "vibe coding", đo lường một tín hiệu đơn giản nhưng quan trọng: ứng dụng do agent xây dựng có đáp ứng đặc tả kỹ thuật không?
ViBench bắt đầu với một tài liệu yêu cầu sản phẩm (PRD) bằng tiếng Anh đơn giản được rút ra từ các dấu vết sản xuất ẩn danh của Replit. Từ đó, agent nhận được PRD và xây dựng một ứng dụng đang chạy từ đầu, mà không bị giới hạn bởi các scaffolding, route hoặc tham chiếu mà các điểm chuẩn mã hóa truyền thống yêu cầu.
Tuy nhiên, sự linh hoạt tương tự khiến ViBench trở nên thực tế đòi hỏi một agent đánh giá cũng linh hoạt không kém, một agent luôn bám sát PRD. Trong các điểm chuẩn kiểu SWE-bench, dự án đã tồn tại, do đó bề mặt đánh giá là cố định. Trong "vibe coding", agent chọn ngăn xếp, route, thành phần và luồng. Việc đánh giá phải khám phá bất cứ thứ gì nó đã phát minh ra.
Để đạt được điều đó, mỗi nhiệm vụ ViBench kết hợp PRD với một bộ các kế hoạch kiểm thử ngôn ngữ tự nhiên mô tả các tương tác và khẳng định ở cấp độ tính năng mà ứng dụng đã hoàn thành phải đáp ứng. Agent đánh giá sử dụng Playwright như một xương sống linh hoạt, cho phép nó thực hiện các tính năng phức tạp như mô phỏng ngoại tuyến, thao tác tệp và đa đối tượng thuê (multi-tenancy). Bởi vì nó không biết các bộ định vị (locators) hoặc cấu trúc của ứng dụng a priori, nó hoạt động trong một môi trường notebook, dần dần khám phá cách ứng dụng được xây dựng và tương tác với nó từng bước một, một cách tiếp cận được rút ra từ nghiên cứu trước đây của Replit về tự động kiểm thử [4].
Việc chạy ViBench và các đánh giá của chúng tôi nói chung, ở quy mô Replit cũng đòi hỏi sự hỗ trợ cơ sở hạ tầng mạnh mẽ [5]. Nội bộ, chúng tôi dựa vào cùng một cơ sở hạ tầng sản xuất cho phép chúng tôi khởi tạo các sandbox biệt lập, có đầy đủ tài nguyên để xây dựng ứng dụng và chạy các agent của mình. Bởi vì chúng tôi có thể nhanh chóng fork các sandbox đó [6], chúng tôi chạy phần lớn việc đánh giá song song, mà không có nguy cơ nhiễm chéo giữa các đánh giá.
Ngoài việc xây dựng ứng dụng từ đầu, cùng một nền tảng ViBench, một PRD ngôn ngữ tự nhiên được chấm điểm bởi các kế hoạch kiểm thử ngôn ngữ tự nhiên, thích ứng với một loạt các tình huống "vibe coding". Để đánh giá cách một agent hoạt động bên trong một ứng dụng hiện có, gần hơn với khối lượng công việc giữa quỹ đạo (mid-trajectory workloads) của Replit, chúng tôi bắt đầu nó trên một mã nguồn hiện có và đo lường mức độ tốt của nó trong việc triển khai các phần mở rộng tính năng từ một PRD tính năng. Mã nguồn đó có thể đến từ các triển khai tham chiếu của chính chúng tôi hoặc từ các ứng dụng mà chính agent đã "vibe-code", mà chúng tôi gọi là Vibe-to-ref và Vibe-on-Vibe trong ấn phẩm của mình. Khi chúng tôi triển khai các bề mặt sản phẩm mới, cùng một xương sống cho phép chúng tôi nhanh chóng rút ra các vấn đề mới để đánh giá các mẫu tương tác mới lạ, như chúng tôi đã làm cho các phân rã song song-và-hợp nhất (parallel-and-merge) và subagent của Agent 4.
ViBench giữ cố định bộ đánh giá hành vi trong khi thay đổi chiến lược đầu vào và xây dựng.
Các kết quả ViBench ban đầu đã cho chúng tôi hai bài học hữu ích. Thứ nhất, điểm số điểm chuẩn mã hóa tiên tiến không phải lúc nào cũng chuyển giao được cho việc xây dựng ứng dụng đầy đủ, đặc biệt là đối với các mô hình trọng số mở (open-weight models). Thứ hai, hầu hết các mô hình đều trở nên tồi tệ hơn khi mở rộng mã của chính chúng, vì các lỗi thường kết hợp với nhau. Cùng với nhau, những bài học đó cho chúng tôi một ngọn đồi tốt hơn để leo: không chỉ viết mã vượt qua các bài kiểm tra, mà còn xây dựng các ứng dụng có thể tồn tại qua yêu cầu tiếp theo của người dùng.
A/B là cách chúng tôi giữ cho mình trung thực
Chúng tôi tin tưởng sâu sắc vào các đánh giá ngoại tuyến, nhưng chúng không phải là thẩm phán duy nhất. Chúng tôi đã thấy đủ nhiều bản cập nhật agent trông có vẻ tốt trong các môi trường được kiểm soát, chỉ để làm giảm hành vi của người dùng thực tế, để biết rằng sản xuất cần lớp đo lường riêng của nó.
Người dùng là không có kịch bản, luôn hoạt động và hoạt động ở quy mô mà không có điểm chuẩn ngoại tuyến nào có thể tái tạo hoàn toàn. Họ từ bỏ dự án, thay đổi ý định, kết hợp các tính năng theo những cách đáng ngạc nhiên và khám phá ra các chế độ lỗi mà chúng tôi không biết để kiểm tra.
Vì vậy, chúng tôi thử nghiệm A/B hầu hết các bản cập nhật ảnh hưởng đến agent: lời nhắc, công cụ, sửa đổi dây cương, hoán đổi mô hình và các thay đổi hành vi lớn hơn. Nhiều thử nghiệm thường chạy đồng thời — với sự phân bổ được giữ rõ ràng để tránh che giấu các hiệu ứng tương tác. Các thử nghiệm A/B cho thấy hành vi, tình cảm và sự thành công của người dùng: người dùng có tiếp tục không, chi phí có hoạt động bất thường không, tình cảm có thay đổi không và người dùng có triển khai thứ gì đó không?
Các thử nghiệm A/B cho chúng tôi một kết quả có kiểm soát về hành vi sản xuất, nhưng các chỉ số tổng hợp không tự giải thích được. Đây có phải là một chiến thắng? Thay đổi hành vi gốc là gì?
Một thách thức với thử nghiệm A/B là kết quả rất khó diễn giải. Nếu thời gian chạy tăng lên, agent đã làm được nhiều việc hữu ích hơn hay nó bị kẹt? Nếu chi phí giảm, chúng tôi đã cải thiện hiệu quả hay agent đã âm thầm ngừng làm điều gì đó có giá trị? Nếu tình cảm giảm, trường hợp sử dụng nào đã bị thoái lui, chế độ lỗi nào là mới và người dùng nào đã bỏ cuộc?
Telescope: những gì đang bị hỏng
Thử nghiệm A/B cho chúng tôi biết khi nào hành vi sản xuất thay đổi. Telescope — hệ thống phân tích và phân cụm dấu vết của chúng tôi — giúp giải thích lý do.
Ở quy mô sản xuất, không có kỹ sư nào có thể đọc mọi dấu vết. Telescope tổ chức các mẫu lặp đi lặp lại thành các cụm vấn đề mà các kỹ sư và agent có thể hành động. Nó tóm tắt các quỹ đạo lỗi, nhúng chúng, phân cụm các trường hợp tương tự và phân loại các phiên mới khi phân phối thay đổi. Mục tiêu không chỉ là đếm các lỗi, mà còn là khám phá những lỗi ẩn giấu ở nơi dễ thấy.
GIF
Phân cụm những gì chúng tôi không biết để tìm kiếm.
Telescope sử dụng các khía cạnh ngắn gọn, dựa trên bằng chứng được lấy cảm hứng từ cùng một cách tiếp cận từ dưới lên như Clio [7]. Đối với các dấu vết, nó tái tạo lại phiên từ tin nhắn người dùng, phản hồi agent hiển thị, lệnh gọi công cụ, lỗi, siêu dữ liệu và các ngữ cảnh khác. Từ đó, Telescope tóm tắt những gì đã sai, nhúng các bản tóm tắt đó và sử dụng phân cụm dựa trên mật độ [8] để hình thành các nhóm vấn đề mới nổi.
Các khía cạnh làm cho việc điều tra nhanh hơn, đặc biệt là khi chỉ phân cụm là không đủ. Khi các báo cáo hỗ trợ chỉ ra một vấn đề rộng, chẳng hạn như lỗi cổng, các kỹ sư và agent có thể tìm kiếm lớp nhỏ gọn trước, khám phá các khía cạnh có liên quan, sau đó đi sâu vào các phiên đại diện với nhật ký và bối cảnh quan sát được cần thiết để giải thích nó.
Nhìn chung, cùng một cấu trúc biến các lỗi rải rác thành các câu hỏi sản phẩm: quy trình làm việc nào chiếm ưu thế, quy trình nào bị bỏ rơi, điều gì hỏng lặp đi lặp lại và liệu một biện pháp giảm thiểu có đang thu hẹp cụm mục tiêu hay không.
Để biết thêm về kiến trúc cơ bản này, hãy xem bài đăng chuyên sâu về Topics từ các cộng tác viên của chúng tôi tại Braintrust [9].
Vòng lặp: từ bằng chứng đến cải tiến agent
Khi đã có phép đo, nút thắt cổ chai sẽ di chuyển. ViBench, các thử nghiệm A/B và Telescope có thể cho chúng tôi biết điều gì đã thất bại, nó thất bại ở đâu và nó xảy ra thường xuyên như thế nào. Chúng tôi vẫn phải biến bằng chứng đó thành các bản sửa lỗi khả thi.
Chúng tôi chuyển sang một vòng lặp tự cải tiến để giải quyết vấn đề này. Nguyên tắc hoạt động rất đơn giản: nếu các agent hữu ích cho việc xây dựng phần mềm, thì chúng cũng nên hữu ích cho việc cải thiện agent. Mỗi lần chạy bắt đầu bằng cách đọc nhật ký sản xuất, các cụm dấu vết và các lỗi gần đây để tìm ra một giả thuyết đáng để theo đuổi. Sau đó, nó xây dựng một ứng viên, mở một PR nháp kèm theo lý do, đo lường kết quả dựa trên ViBench, kết quả A/B, dữ liệu quỹ đạo và các đường cơ sở gần đây, và đề xuất có nên triển khai, lặp lại hay loại bỏ nó hay không.
Vòng lặp tối ưu hóa khám phá các vấn đề, đề xuất các thay đổi agent, đánh giá chúng và quyết định có nên triển khai, lặp lại hay loại bỏ.
Việc triển khai không trở nên tự động. Vòng lặp có thể chuẩn bị bằng chứng và triển khai bước đầu; các kỹ sư vẫn xem xét kết quả và sở hữu quyết định phát hành.
Mỗi lần chạy ghi lại những gì nó đã thử và những gì đã xảy ra, bao gồm cả các lỗi. Bản ghi đó cải thiện vòng lặp theo thời gian: các lần chạy trong tương lai có thể tái sử dụng những gì đã hiệu quả, tránh các ngõ cụt đã biết và đề xuất các thay đổi có tính khái quát hóa.
Việc lặp lại agent trở nên nhanh hơn mà không từ bỏ quyền kiểm soát kỹ thuật. Với một mô hình, bề mặt sản phẩm hoặc mục tiêu độ tin cậy mới, vòng lặp có thể chủ động tìm ra các chỉnh sửa lời nhắc, đề xuất kỹ năng, sửa lỗi công cụ và thay đổi dây cương trong khi các kỹ sư giữ cho hệ thống hướng tới mức tối ưu sản phẩm lớn hơn.
Một ví dụ cụ thể
Một lần chạy gần đây bắt đầu với một cụm Telescope nhỏ nhưng đang phát triển. Thiết lập môi trường đang âm thầm suy giảm trên một loạt dài các tình huống khởi động nguội. Các phiên này không rõ ràng từ các chỉ số tổng hợp, nhưng cụm này cho thấy một mẫu đáng để điều tra.
Sau khi đưa ra mẫu, vòng lặp đọc các quỹ đạo bị ảnh hưởng, đề xuất một bản vá, thêm một bài kiểm tra hồi quy và chạy ứng viên dựa trên ViBench để xác nhận rằng đường dẫn hạnh phúc (happy path) không bị thoái lui. Các kỹ sư đã xem xét bằng chứng, phê duyệt thay đổi và đẩy nó vào sản xuất cùng ngày.
Sau khi bản vá được triển khai, tình cảm đã phục hồi và những người dùng bị ảnh hưởng đã được gỡ bỏ chặn. Đây là hình dạng chúng tôi muốn — một vòng lặp tìm ra một mẫu lỗi thực tế, kết nối nó với những người dùng bị ảnh hưởng, đề xuất mức sửa lỗi phù hợp và mang lại đủ bằng chứng để một người quyết định có nên triển khai hay không.
Nơi gu thẩm mỹ của con người vẫn quan trọng nhất
Phần lớn điều này có thể chạy tự động: phân cụm các lỗi, đề xuất giả thuyết, xây dựng ứng viên, chạy đánh giá và tập hợp bằng chứng. Con người vẫn đặt ra hướng đi và kiểm soát hầu hết các lối ra, bao gồm:
- Lựa chọn giả thuyết. Một hệ thống có thể đưa ra hàng nghìn lỗi, nhưng con người quyết định câu hỏi nào xứng đáng với ngân sách qua đêm của vòng lặp. Không phải cụm nào cũng quan trọng như nhau, và không phải mọi sự thoái lui đều chỉ ra đúng vấn đề sản phẩm.
- Kiến trúc triển khai. Các dấu vết có thể cho thấy người dùng đang từ bỏ một quy trình làm việc, nhưng việc quyết định có nên làm mượt con đường đó, thay đổi hành vi của agent hay thiết kế lại bề mặt là một phán đoán kỹ thuật và sản phẩm.
- Quản lý đánh giá. Đây không phải là công việc hành chính; nó định hình ngọn đồi mà agent leo lên. Nếu đánh giá thưởng cho hành vi sai, vòng lặp tối ưu hóa sẽ trung thành tối ưu hóa theo hướng sai.
- Phê duyệt phát hành. Triển khai một thay đổi agent không chỉ là đọc một con số. Phê duyệt phát hành có nghĩa là đọc bằng chứng, hiểu bán kính ảnh hưởng, quyết định xem rủi ro có chấp nhận được không và sở hữu việc triển khai.
Sự cân bằng đó rất quan trọng: vòng lặp có thể thực hiện nhiều hơn việc tìm kiếm, đo lường và tổng hợp. Các kỹ sư vẫn chọn hướng đi, đưa ra các quyết định về sản phẩm và quyết định những gì được triển khai.
Khép kín vòng lặp
Đánh giá không còn chỉ là một cánh cổng trước khi phát hành. Nó giúp quyết định sửa chữa gì, kiểm tra gì và phát hành gì.
Công việc không phải là tạo ra một con số tốt hơn. Đó là biến những thất bại của người dùng thành những bản phát hành tốt hơn, để nhiều ý tưởng hơn trở thành ứng dụng mà mọi người tự hào khi xuất bản.
Chúng tôi rất vui mừng được tiếp tục đẩy mạnh ranh giới của các agent tự động, tập trung vào độ tin cậy cho các nhiệm vụ mã hóa phức tạp nhất. Nếu bạn quan tâm đến việc làm việc trên các agent mã hóa tự động, tôi luôn tuyển dụng cho nhóm AI của Replit — hãy liên hệ với tôi qua [email protected]
Tác giả: Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta
Tài liệu tham khảo
[0] Học liên tục cho các agent AI
[1] SWE-bench: Liệu các Mô hình Ngôn ngữ có thể Giải quyết các Vấn đề GitHub trong Thế giới Thực?
[2] Terminal-Bench: Đánh giá các Agent về các Nhiệm vụ Khó, Thực tế trong Giao diện Dòng lệnh
[3] ViBench: Một Điểm chuẩn về Vibe Coding
[4] Cho phép Agent 3 Tự Kiểm tra ở Quy mô Lớn với Xác minh Dựa trên REPL
[5] Định lượng nhiễu cơ sở hạ tầng trong các đánh giá mã hóa agent
[6] Bên trong Công cụ Snapshot của Replit: Công nghệ Giúp Agent AI An toàn
[7] Clio: Thông tin chi tiết về Quyền riêng tư trong Sử dụng AI trong Thế giới Thực
[8] Ước tính Mật độ Phân cấp để Phân cụm Dữ liệu, Trực quan hóa và Phát hiện Ngoại lệ
[9] Cách chúng tôi giúp khả năng thông minh dấu vết liên tục trở nên khả thi ở quy mô lớn
