- Cursor đã thử nghiệm liệu có thể chạy song song các agent lập trình tự động trong nhiều tuần để hoàn thành những dự án quy mô lớn hay không
- Ban đầu, họ dùng cấu trúc cộng tác động, nhưng đã phát sinh nút thắt do xung đột lock và công việc bị trùng lặp
- Sau đó, họ tách vai trò thành Planner và Worker, giúp cải thiện đáng kể tính song song và hiệu quả
- Với cấu trúc này, họ đã triển khai một trình duyệt web từ đầu, với hàng trăm agent viết hơn 1 triệu dòng mã
- Kết quả thử nghiệm cho thấy cấu trúc đơn giản và thiết kế prompt phù hợp là chìa khóa để mở rộng tự động lập trình dài hạn
Giới hạn của agent đơn lẻ
- Agent lập trình đơn lẻ hiện tại hiệu quả với các tác vụ đơn giản, nhưng chậm khi xử lý dự án phức tạp
- Chạy nhiều agent song song là hướng mở rộng tự nhiên, nhưng điều phối công việc lại rất khó
- Ban đầu, họ thử phương thức cộng tác động mà không có kế hoạch trước
- Mỗi agent quan sát trạng thái của các agent khác và tự quyết định công việc tiếp theo
Quá trình học cách cộng tác
- Họ áp dụng cấu trúc trong đó mọi agent có quyền ngang nhau và phối hợp công việc qua các tệp dùng chung
- Mỗi agent kiểm tra trạng thái của agent khác, nhận việc và cập nhật trạng thái
- Để tránh trùng lặp, họ dùng cơ chế lock
- Vấn đề
- Agent giữ lock quá lâu hoặc không nhả lock, khiến tốc độ toàn hệ thống giảm xuống chỉ còn mức của 2~3 agent trên tổng số 20
- Xảy ra bất ổn hệ thống như thất bại khi vẫn đang giữ lock, hoặc sửa tệp mà không có lock
- Sau đó chuyển sang optimistic concurrency control
- Đọc thì tự do, còn ghi sẽ thất bại nếu trạng thái đã thay đổi
- Cách này đơn giản và ổn định, nhưng trong cấu trúc không có phân cấp, agent lại có xu hướng hành xử quá né rủi ro
- Chúng né các vấn đề khó, chỉ lặp lại những chỉnh sửa nhỏ, tạo thành vòng lặp công việc không có tiến triển
Cấu trúc Planner và Worker
- Sau đó chuyển sang pipeline phân cấp có tách vai trò
- Planner: khám phá codebase để tạo công việc, và khi cần thì sinh ra planner cấp dưới
- Worker: chỉ thực hiện công việc được giao và push thay đổi sau khi hoàn thành
- Ở mỗi chu kỳ, một judge agent quyết định có chuyển sang bước tiếp theo hay không
- Cấu trúc này giải quyết được hầu hết vấn đề cộng tác, qua đó đảm bảo khả năng mở rộng cho các dự án lớn
Thử nghiệm chạy dài hạn
- Mục tiêu thử nghiệm: triển khai một trình duyệt web từ đầu
- Chạy trong khoảng 1 tuần, viết hơn 1 triệu dòng mã trong 1.000 tệp
- Hàng trăm worker cùng lúc push vào cùng một branch, nhưng xung đột được giảm xuống mức tối thiểu
- Mã nguồn kết quả đã được công khai trên GitHub
- Các thử nghiệm bổ sung
- Di chuyển Solid → React: trong 3 tuần, thay đổi +266K/-193K, xác nhận khả năng gộp mã
- Cải thiện dựng hình video: phiên bản Rust nhanh hơn 25 lần, bổ sung các tính năng zoom·pan·motion blur
- Mã tương ứng dự kiến sớm được đưa vào production
Các bài học chính
- Sau khi tiêu tốn hàng chục tỷ token, họ xác nhận rằng dù chưa hoàn toàn hiệu quả, kết quả vẫn tốt hơn kỳ vọng
- Lựa chọn mô hình là yếu tố cốt lõi cho tác vụ tự động dài hạn
- GPT-5.2 vượt trội về duy trì tập trung, tuân thủ chỉ thị và triển khai chính xác
- Opus 4.5 có xu hướng kết thúc sớm
- GPT-5.2 phù hợp với vai trò planner hơn GPT-5.1-codex
- Họ chọn mô hình tối ưu theo từng vai trò
- Loại bỏ sự phức tạp giúp cải thiện hiệu năng
- Vai trò tích hợp chất lượng (
integrator) lại trở thành nút thắt cổ chai
- Các worker có thể tự giải quyết xung đột
- Cấu trúc đơn giản là hiệu quả nhất
- Lý thuyết hệ thống phân tán hay mô hình thiết kế tổ chức chỉ đúng một phần
- Quá ít cấu trúc thì dễ xung đột và trùng lặp, quá nhiều thì làm tăng độ mong manh
- Thiết kế prompt ảnh hưởng mang tính quyết định đến hành vi hệ thống
- Đóng vai trò then chốt trong việc duy trì tập trung dài hạn, ngăn hành vi bệnh lý và thúc đẩy cộng tác
Bài toán sắp tới
- Điều phối đa agent vẫn là một vấn đề khó
- Cần cải thiện để planner có thể tự động lập kế hoạch bước tiếp theo khi công việc hoàn tất
- Một số agent chạy quá lâu nên cần khởi động lại định kỳ
- Tuy nhiên, với câu hỏi cốt lõi là “liệu tăng số lượng agent có thể mở rộng tự động lập trình hay không”
- Họ đã xác nhận rằng hàng trăm agent có thể cộng tác trong nhiều tuần và tạo ra tiến triển thực tế
- Công nghệ này dự kiến sẽ được phản ánh vào tính năng agent của Cursor trong tương lai
1 bình luận
Ý kiến Hacker News
Tôi đang làm việc liên quan đến bài viết của Steve Yegge Welcome to Gas Town nên thấy khá thú vị.
Trong bài dự đoán về LLM mà tôi chia sẻ gần đây, tôi nói rằng đến khoảng năm 2029, việc dùng AI hỗ trợ để tạo ra một trình duyệt sẽ không còn là điều đáng ngạc nhiên, và dự án lần này của Cursor là nỗ lực thứ hai. Một ví dụ khác có thể xem trong bài đăng Reddit này.
Tôi đã tự chạy các bài test của kho mã và thấy đầy lỗi cùng cảnh báo, còn CI thì đã thất bại từ rất lâu. Tôi không chắc trạng thái như vậy có thể gọi là một “ví dụ thành công” hay không. So với lập trình hoàn toàn tự động, tôi nghĩ cách tiếp cận hỗ trợ lấy con người làm trung tâm thực tế hơn.
Tôi tò mò vì sao PR đó vẫn chưa được merge. Tương lai nơi một bầy tác tử AI hoàn thành phần mềm phức tạp trong dài hạn nghe rất tuyệt, nhưng ví dụ hiện tại quá yếu. Điểm hợp tác với con người mới là thứ quan trọng hơn.
Tôi tiếc là họ không thử nghiệm bằng cách tăng độ khó theo từng bước. Nếu mở rộng dần theo trình tự React CRUD → bản sao Paint → trình quản lý tệp → trình duyệt, ta đã có thể thấy rõ các giai đoạn tiến bộ.
Tôi cũng từng làm tjs theo cách tương tự. Đây là trình xác thực JSON Schema nhanh và chính xác nhất thế giới, và mẫu planner/delegate dùng git subtree đã tỏ ra hiệu quả. Với những phần mềm có tiêu chuẩn và bài test được xác định rõ ràng, các tác tử AI có thể nhanh chóng viết lại và tối ưu hóa. Có thể xem lệnh liên quan tại spawn-perf-agents.md.
Việc tạo một trình duyệt từ đầu là cực kỳ khó, nhưng nội dung bài viết đưa ra lại thiếu phân tích chi tiết. Nếu chỉ dừng ở mức “biên dịch được” thì ý nghĩa không lớn. Kiểm chứng thật sự là liệu có thể hợp nhất ổn định các thay đổi tiếp theo hay không.
Theo blog, họ đã dùng hàng nghìn tỷ token, mà nếu tính theo đơn giá API của OpenAI thì tương đương hàng chục triệu USD. Với mức đó, có lẽ tốt hơn là đem quyên góp cho một đội ngũ làm trình duyệt.
Tôi đã tự build thử và gặp hơn 100 lỗi biên dịch. Hầu hết các commit đều ở trạng thái CI fail, và trên thực tế đây là sự kết hợp của nhiều thư viện mã nguồn mở. quickjs, wgpu, winit, egui, html parser cùng các thành phần hiện có khác được mang vào gần như nguyên trạng, nhưng CEO lại khẳng định đó là “custom JS VM”, điều này gây hiểu nhầm. Dù vậy, việc AI có thể tự động thực hiện kiểu tích hợp này vẫn rất ấn tượng.
Mã trông rất mong manh và thiếu ổn định. Ví dụ, hàm render_placeholder có vẻ chỉ là mã tạm để lấp đầy frame buffer. Tôi tò mò đoạn mã này thực sự đóng vai trò gì, và chi phí token/thời gian cho từng bài test là bao nhiêu.