Cursor thử nghiệm mô hình AI đa tác nhân: Phân chia 'Người lập kế hoạch' và 'Người thực thi' giúp tăng hiệu suất vượt trội

Đầu năm nay, chúng tôi đã thực hiện các thử nghiệm để kiểm tra giới hạn của việc mở rộng quy mô các tác nhân (agents) nhằm hợp tác hướng tới một mục tiêu chung. Giả thuyết của chúng tôi là điều này sẽ mở ra một cấp độ mới về quy mô và độ phức tạp của tác vụ.

Dự án tiêu biểu là một đàn tác nhân (swarm) hoạt động lâu dài để xây dựng một trình duyệt web từ con số không. Dự án đã thành công với tư cách là một bằng chứng khái niệm (proof of concept), nhưng vẫn còn cách rất xa so với một phần mềm hoàn thiện.

Công việc đó mang tính thực nghiệm có chủ đích. Chúng tôi bắt đầu từ một trang giấy trắng và dần cải thiện để hướng tới một hệ thống ổn định, hiệu quả. Kể từ đó, mục tiêu của chúng tôi là hiểu rõ về đàn tác nhân đủ để có thể thiết kế nó một cách chủ động.

Để kiểm chứng sự tiến bộ đó, chúng tôi quay lại với một tác vụ mà đàn tác nhân cũ từng gặp khó khăn: xây dựng SQLite từ đầu, bằng ngôn ngữ Rust, chỉ dựa trên tài liệu của nó.

Kết quả ban đầu rất hứa hẹn. Chúng tôi đã chạy đàn tác nhân cũ và mới trên cùng một tác vụ, với cùng các mô hình và cùng ngân sách thời gian, sau đó đo lường xem mỗi bên có thể vượt qua bao nhiêu phần trăm trong bộ kiểm thử SQL độc lập.

Đàn tác nhân mới hoạt động tốt hơn ở mọi cấu hình mô hình. Sử dụng Grok 4.5, nó đạt 80% trong bốn giờ, trong khi đàn tác nhân cũ bị mất kiểm soát và phải tạm dừng trước giờ thứ hai.

Chúng tôi cũng thay đổi việc mô hình nào đảm nhận công việc gì. Trong một số lần chạy, một mô hình xử lý mọi thứ, trong khi ở những lần khác, một mô hình tiên phong (frontier model) thực hiện lập kế hoạch còn một mô hình nhanh, chi phí thấp thực hiện công việc. Mọi sự kết hợp đều mang lại chất lượng tương đương, nhưng chi phí lại chênh lệch rất lớn.

Cây và lá

Các mô tả về tác vụ lớn thường có hình dạng giống như những cái cây, với mục tiêu nằm ở gốc và phân nhánh đệ quy thành các đơn vị công việc cơ bản. Đàn tác nhân của chúng tôi có hai vai trò, cả hai đều được tổ chức xung quanh cấu trúc phân rã dạng cây đó:

Thiết kế này là một tập siêu của các hệ thống điều phối cứng nhắc hơn. Thay vì áp đặt một cấu trúc liên kết cố định lên vấn đề, hình dạng của đàn tác nhân phát triển để bao phủ các đường nét của vấn đề, đồng thời khả năng tính toán và ngữ cảnh được mở rộng tương ứng với độ phức tạp của tác vụ.

Chúng tôi cho rằng đây là lý do tại sao thiết kế này có thể khái quát hóa cho các tác vụ đa dạng như xây dựng trình duyệt, giải toán và tối ưu hóa các nhân GPU. Chúng tôi cũng đã sử dụng nó nội bộ để tìm và sửa các lỗ hổng trong phần mềm mã nguồn mở, nâng cao độ bao phủ kiểm thử trên chính cơ sở mã của mình và tạo ra hàng tỷ token dữ liệu huấn luyện tổng hợp.

Cây làm được gì cho bộ nhớ

Khi một tác nhân đơn lẻ đảm nhận toàn bộ tác vụ, nó phải tự mình đi hết toàn bộ cái cây, đi xuống từng chiếc lá trong khi vẫn phải duy trì ngữ cảnh về các nút cha, vị trí hiện tại và mục tiêu rộng lớn hơn trong suốt quá trình.

Chúng tôi nghĩ rằng điều này giải thích tại sao các tác nhân đơn lẻ hoạt động lâu dài lại bị chệch hướng. Chúng hoặc là tập trung vào công việc trước mắt mà quên mất bức tranh toàn cảnh, hoặc là giữ bức tranh toàn cảnh nhưng lại làm kém hiệu quả ở từng phần việc nhỏ.

Trong một đàn tác nhân, người lập kế hoạch không bao giờ thực thi, vì vậy ngữ cảnh của nó không bị lấp đầy bởi các chi tiết cấp thấp; và người thực thi không bao giờ lập kế hoạch, vì vậy nó có thể dành toàn bộ ngữ cảnh cho một phần công việc hẹp.

Chúng tôi nghi ngờ rằng khả năng mở rộng của đàn tác nhân đến từ hiệu quả ngữ cảnh này, hơn là từ chính khả năng xử lý song song. Hiệu quả đó hiện diện trong đàn tác nhân ở mọi quy mô, đó là lý do tại sao sự phân rã này giúp cải thiện hiệu suất của tác nhân ngay cả với các tác vụ có quy mô vừa phải.

Có những điểm tương đồng với cấu trúc này ở những nơi khác. Nhà kinh tế học Ronald Coase, khi đặt câu hỏi tại sao các công ty tồn tại, đã lập luận rằng chi phí điều phối tăng nhanh hơn chính khối lượng công việc, vì vậy các tổ chức ổn định ở các cấp đơn vị giới hạn thay vì để mọi người đều nói chuyện với mọi người.

Hệ thống kiểm soát phiên bản cho các tác nhân

Trong một bài viết trước về đàn tác nhân, chúng tôi đã lưu ý rằng các công cụ như Git và Cargo dựa vào các khóa thô (coarse locks) để kiểm soát tính đồng thời. Điều này ổn với một lập trình viên nhưng không khả thi với khối lượng công việc do hàng trăm tác nhân đồng thời tạo ra.

Đàn tác nhân xây dựng trình duyệt từ đầu năm nay đạt đỉnh khoảng 1.000 commit mỗi giờ trên Git. Hệ thống mới đạt đỉnh khoảng 1.000 commit mỗi giây.

Để tạo điều kiện cho tốc độ hoạt động này, chúng tôi đã xây dựng một hệ thống kiểm soát phiên bản (VCS) mới từ đầu. Thông lượng không phải là lý do duy nhất để sở hữu lớp này. Mọi thay đổi trong hệ thống đều đi qua VCS, vì vậy đây là nơi các xung đột xuất hiện rõ ràng nhất, và một số cơ chế điều phối trong phần tiếp theo được triển khai trực tiếp bên trong nó.

Các dạng lỗi ở tốc độ 1.000 commit mỗi giây

Các đội ngũ kỹ sư con người có các cơ chế điều phối tiêu chuẩn như đánh giá mã (code review), quyền sở hữu, họp nhanh (standups) và hàng đợi hợp nhất (merge queues). Các hệ thống đó hoạt động ở nhịp độ con người, nhưng với tốc độ commit của đàn tác nhân, chúng tôi thấy các dạng lỗi mà các đội ngũ con người không thường xuyên gặp phải.

Thiết kế "bộ não phân tách" (Split-brain)

Hai người lập kế hoạch, không biết về nhau, triển khai cùng một khái niệm theo những cách khác nhau ở các phần khác nhau của cơ sở mã.

Chúng tôi đã khắc phục điều này thông qua việc nhắc lệnh (prompting). Những người lập kế hoạch tự đưa ra các quyết định thiết kế thay vì ủy quyền chúng, và chúng tôi yêu cầu họ đảm bảo rằng không có hai cây con được ủy quyền nào quyết định cùng một vấn đề.

Sự tranh chấp giữa các người lập kế hoạch

Một dạng tranh chấp khó hơn là khi hai người lập kế hoạch biết về nhau và tranh đấu thông qua các thay đổi qua lại trên cùng một tệp tin.

Vấn đề nằm ở hai bức tranh thực tế khác nhau, và công cụ hợp nhất không thể sửa chữa sự bất đồng. Thay vào đó, chúng tôi yêu cầu các tác nhân ghi lại các quyết định vào các tài liệu thiết kế dùng chung. Mã nguồn phụ thuộc vào một quyết định sẽ mang theo một tham chiếu đã được kiểm tra biên dịch ngược lại tài liệu đó. Khi các người lập kế hoạch vô tình mâu thuẫn với nhau, một bộ hòa giải sẽ hợp nhất các tài liệu và các tham chiếu sẽ truyền tải giải pháp đó xuống phía dưới.

Xung đột hợp nhất (Merge conflicts)

Trong đàn tác nhân, các tác nhân liên tục va chạm trên cùng một tệp tin. Để giải quyết xung đột, chúng sẽ phải dừng lại, tiếp nhận ngữ cảnh của tác nhân kia và hợp nhất xung quanh nó. Các tác nhân thực thi làm việc này rất kém và trên thực tế, chúng thường ghi đè lên thay đổi của bên kia hoặc từ bỏ thay đổi của chính mình.

Để khắc phục điều này, chúng tôi đã tạo ra một hệ thống nơi một tác nhân bên thứ ba trung lập can thiệp vào các xung đột hợp nhất và giải quyết chúng thay mặt cho tất cả các bên. Mục tiêu duy nhất của nó là sự công bằng và hiệu quả, tương tự như cách các hàng đợi hợp nhất hoạt động trong các đội ngũ kỹ thuật.

Các tệp tin khổng lồ (Megafiles)

Một số tệp tin là nơi đặc biệt phổ biến để các tác nhân làm việc. Mỗi tác nhân có thể chỉ thêm một lượng nhỏ mã nguồn, và không có tác nhân đơn lẻ nào chịu trách nhiệm giữ cho các tệp tin đó nhỏ gọn.

Những "tệp tin khổng lồ" này làm nghẽn mọi thứ. Chúng rất tốn kém để vận chuyển, so sánh (diff) và hợp nhất, đồng thời trở thành nơi xảy ra các va chạm liên tục.

Để khắc phục điều này, chúng tôi đã cung cấp cho các tác nhân thực thi một cách để gắn cờ các tệp tin bị phình to. Khi đã được gắn cờ, chúng tôi chặn các commit mới và một tác nhân bên ngoài sẽ phân rã tệp tin quá khổ đó thành các mô-đun nhỏ hơn.

Sự xơ cứng (Ossification)

Các tác nhân đã học được, từ việc làm việc trong các cơ sở mã hiện có với con người trong vòng lặp, là không nên đụng vào mã cốt lõi ngay cả khi nó cần thay đổi.

Để khắc phục điều này, chúng tôi cho phép việc phá vỡ có chủ đích. Một tác nhân đánh giá rằng một thay đổi cốt lõi là xứng đáng có thể thực hiện một bản vá tập trung bên ngoài phạm vi của nó và để lại bình luận giải thích lý do tại sao nó làm như vậy.