Blog / AI / Deep Article
Đọc đúng thử nghiệm Agensh của Microsoft: kết quả test, cơ chế phối hợp và những giới hạn nhóm phát triển phần mềm cần hiểu trước khi mở rộng AI agent.
Một agent viết mã đã có thể làm nhóm phát triển phần mềm bận rộn với việc kiểm tra đầu ra. Nếu tăng lên 128 hay 1.024 agent, vấn đề sẽ lớn đến đâu? Đừng FOMO vì con số. Điều đáng học nằm ở cách chia việc, trao đổi kết quả và ghép thay đổi, chứ không chỉ ở số lượng cửa sổ AI đang chạy.
Ngày 24/10/2026, Microsoft công bố mã nguồn Agensh. Theo kho mã chính thức và bài nghiên cứu trên arXiv, đây là một hệ thống tổ chức nhiều agent tự nhận tác vụ và phối hợp qua hạ tầng dùng chung, không dựa vào một bộ điều phối trung tâm để giao từng phần việc. Các số đo ban đầu có tiến bộ, nhưng phạm vi thử nghiệm cần được đọc kỹ.
Nhóm tác giả đánh giá năm tác vụ khó nhất của ProgramBench với GPT-5.6-sol ở mức reasoning cao, giới hạn sáu giờ và không có Internet. Khi tăng từ một lên 128 agent, tỷ lệ test vượt qua trung bình tăng từ 19,31% lên 28,78%.
Đây là tỷ lệ các bài kiểm tra được vượt qua trong bộ đánh giá, không phải tỷ lệ dự án phần mềm đã hoàn thành. Chênh lệch là 9,47 điểm phần trăm. Cách nói “tăng khoảng 49%” trong nghiên cứu là mức tăng tương đối so với mốc ban đầu; hai cách diễn đạt không được tráo cho nhau.
Riêng tác vụ Pandoc, mức đạt tăng từ 33,89% với một agent lên 55,06% với 1.024 agent trong cùng giới hạn thời gian. Đó là kết quả của một tác vụ. Không được lấy con số này thay cho mức trung bình của cả năm tác vụ, hay suy ra mọi công việc đều hưởng lợi tương tự.
Agent trong Agensh vẫn cần nơi nhìn thấy công việc, nhận phần việc, trao đổi phát hiện và ghép tiến độ. Kho mã mô tả ba lớp hạ tầng: không gian làm việc chung, giao diện nhắn tin và cơ chế chia sẻ ngữ cảnh.
Vấn đề là mỗi agent chỉ nhìn được một phần công việc. Nếu không biết phần nào đã có người nhận, hai agent có thể cùng sửa một chỗ. Nếu một phát hiện đúng chỉ nằm trong trao đổi riêng, agent khác có thể phải tìm lại từ đầu. Chia được việc thôi chưa đủ; còn phải làm cho kết quả dùng lại được.
Không cần dựng ngay một đội quân hàng nghìn agent để học từ nghiên cứu này. Với một nhóm phát triển nhỏ ở Việt Nam, bài học gần hơn là đặt câu hỏi rõ trước khi tăng mức tự động hóa.
Trước hết, công việc nào có thể tách thành phần nhỏ mà vẫn kiểm tra được? Một tác vụ sửa tài liệu, bổ sung kiểm tra hay khảo sát một module có thể có đầu ra rõ. Còn một yêu cầu mơ hồ như “làm hệ thống tốt hơn” thì khó chia việc và khó biết khi nào đã xong.
Tiếp theo, ai được sửa phần nào? Đội AI mà giẫm chân nhau thì mệt đấy. Một cơ chế nhận việc và báo trạng thái giúp nhóm nhìn thấy xung đột sớm hơn. Đây là gợi ý thực hành cho nhóm sử dụng AI, không phải một tính năng an toàn đã được bài nghiên cứu chứng minh đầy đủ.
Giả sử một SME ở Việt Nam muốn dùng AI xử lý yêu cầu khách hàng đến từ Zalo. Nhóm có thể tách việc phân loại yêu cầu và việc đề xuất sửa mã, rồi kiểm tra đầu ra từng bước. Đây là tình huống minh họa, không phải thử nghiệm trong bài Agensh. Không nên vì cùng làm một quy trình mà cho mọi agent đọc toàn bộ dữ liệu khách hàng.
Một agent báo “đã xong” không phải là bằng chứng thay đổi đã đúng. Nhóm phát triển vẫn cần đối chiếu yêu cầu, xem phần mã thay đổi và chạy những kiểm tra phù hợp. Kết quả test cũng cần được hiểu đúng: bộ kiểm tra chỉ bao phủ những tình huống được thiết kế.
Với lập trình viên Việt Nam đang đưa AI vào quy trình làm việc, một bản bàn giao ngắn có thể hữu ích hơn một chuỗi trao đổi dài. Nó cần nêu phần việc đã làm, bằng chứng kiểm tra, phần chưa chắc và nơi có thể xem lại thay đổi.
Bài học ở đây không phải giao thêm quyền cho agent. Hãy bắt đầu bằng đầu ra có thể kiểm tra. Khi chưa xác định được điều đó, thêm agent có thể chỉ khiến nhóm phải đọc nhiều kết quả chưa được xác minh hơn.
Chia sẻ mọi thông tin không tự động tạo ra hiểu biết chung. Một ghi chú cũ, kết luận thiếu điều kiện hay mô tả trạng thái không còn đúng có thể khiến nhiều agent đi sai cùng một hướng.
Câu hỏi là thông tin nào cần được giữ lại để agent kế tiếp làm đúng việc, thay vì bắt đầu lại hoặc lặp một lỗi cũ? Một ghi chú ngắn có nguồn và trạng thái rõ thường dễ sử dụng hơn một kho trao đổi không được sắp xếp.
Tăng tỷ lệ test vượt qua trong giới hạn sáu giờ không đồng nghĩa hệ thống luôn dùng ít tài nguyên hơn. Những kết quả được dẫn ở đây cũng chưa đủ để kết luận về hiệu quả cho mọi sản phẩm, mức độ an toàn khi triển khai hay khả năng thay thế đội ngũ phát triển.
Các nhóm ở Việt Nam nên nhìn Agensh như một hướng nghiên cứu về phối hợp nhiều agent. Muốn áp dụng vào công việc thật, vẫn phải thử trên tác vụ của mình, theo dõi chất lượng đầu ra và đặt giới hạn quyền phù hợp. Bài học thực tế là đo kết quả trước khi mở rộng, chứ không lấy số lượng agent làm mục tiêu.
Nếu ngày mai thêm vài agent vào quy trình của nhóm, bạn đã biết chúng sẽ nhận việc ở đâu, lưu bằng chứng thế nào và ai sẽ kiểm tra đầu ra chưa?