Cursor ra mắt Agent Swarm: Kết hợp mô hình giá rẻ và AI cao cấp để tối ưu hóa lập trình

Hệ thống chia các tác nhân (agent) thành hai vai trò: các tác nhân lập kế hoạch (planner agents) sử dụng những mô hình tiên tiến (frontier models) mạnh mẽ để đệ quy chia nhỏ mục tiêu thành các tác vụ nhỏ hơn. Các tác nhân thực thi (worker agents) sử dụng những mô hình nhanh hơn, rẻ hơn để hoàn thành các tác vụ đó. Kết quả là một cây tác vụ có khả năng thích ứng khi công việc tiến triển.

Cursor cho biết việc phân chia vai trò này chủ yếu giải quyết vấn đề về ngữ cảnh. Một tác nhân đơn lẻ phải duyệt qua toàn bộ cây tác vụ trong khi vẫn phải ghi nhớ cả mục tiêu lẫn tác vụ hiện tại. Điều đó giải thích tại sao các tác nhân thường bị chệch hướng trong các công việc dài hơi. Trong hệ thống swarm của Cursor, các tác nhân lập kế hoạch không viết mã nguồn, và các tác nhân thực thi không lập kế hoạch.

Git không thể xử lý 1.000 commit mỗi giây.

Một hệ thống swarm trình duyệt trước đó của Cursor đạt khoảng 1.000 commit mỗi giờ trên Git. Nó sử dụng các tác nhân thực thi, một tác nhân đánh giá (judge agent) và một bộ tích hợp (integrator) để giải quyết xung đột. Bộ tích hợp này cuối cùng lại tạo ra nhiều điểm nghẽn hơn là giải quyết chúng.

Hệ thống swarm mới đạt 1.000 commit mỗi giây, vì vậy Cursor đã tự xây dựng hệ thống kiểm soát phiên bản riêng của mình, bởi vì các tác nhân làm việc ở tốc độ đó tạo ra những kiểu lỗi mà các nhóm kỹ sư con người chưa từng gặp phải.

Trong cái mà Cursor gọi là "thiết kế não phân tách" (split-brain design), hai tác nhân lập kế hoạch có thể vô tình xây dựng cùng một ý tưởng ở những nơi khác nhau và triển khai theo những cách khác nhau. Sự tranh chấp thậm chí còn khó quản lý hơn khi các tác nhân biết về nhau và chặn lẫn nhau bằng các chỉnh sửa đối nghịch.

Cursor 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 gắn liền với một quyết định sẽ được liên kết ngược lại với tài liệu thông qua một tham chiếu được kiểm tra tại thời điểm biên dịch.

Khi xảy ra xung đột hợp nhất (merge conflict), một tác nhân trung lập sẽ can thiệp và giải quyết chúng. Các tác nhân thực thi sẽ gắn cờ các tệp tin cồng kềnh để một tác nhân bên ngoài chia nhỏ chúng thành các module. Vì các tác nhân đã được học cách không chạm vào mã nguồn cốt lõi khi làm việc trong các cơ sở mã hiện có với sự tham gia của con người, Cursor cho phép chúng chủ động phá vỡ mọi thứ. Một tác nhân có thể vá mã nguồn bên ngoài khu vực được chỉ định của nó, và trình biên dịch sẽ đưa thay đổi đó xuyên suốt hệ thống.

Nhiều góc độ đánh giá và một sổ tay hướng dẫn tự duy trì.

Cursor đã thử nghiệm một vài phương pháp đánh giá. Một người đánh giá nhận toàn bộ bản ghi của tác nhân thực thi, người khác chỉ xem kết quả đầu ra, và người thứ ba chỉ xem cơ sở mã. Không một góc nhìn đơn lẻ nào nắm bắt được mọi thứ, nhưng các góc nhìn không tương quan khi kết hợp lại sẽ mang lại độ tin cậy cao hơn.

Cursor cũng thử nghiệm một "sổ tay hướng dẫn" (field guide), một thư mục kiến thức được duy trì bởi chính các tác nhân với giới hạn dòng cố định. Mọi tác nhân đều nhận được nội dung của nó khi khởi động. Vì trọng số mô hình là cố định, việc ghi lại những phát hiện bất ngờ sẽ rất hữu ích để các tác nhân sau này có thể đi đường tắt.

Cursor cung cấp cho hệ thống swarm cuốn hướng dẫn SQLite dài 835 trang và yêu cầu nó xây dựng một bản triển khai bằng Rust. Mã nguồn, bộ kiểm thử, tệp nhị phân SQLite và quyền truy cập internet đều bị hạn chế. Điểm chuẩn là sqllogictest, một bộ kiểm thử với hàng triệu truy vấn SQL và các câu trả lời đã biết. Hệ thống swarm không hề biết đến sự tồn tại của nó.

Bốn cấu hình đã được thử nghiệm. GPT-5.5 độc lập, Grok 4.5 độc lập, Opus 4.8 làm lập kế hoạch với Composer 2.5 làm thực thi, và Fable 5 làm lập kế hoạch với Composer 2.5 làm thực thi. Hệ thống mới đánh bại hệ thống cũ trong mọi cấu hình. Sau bốn giờ, các lượt chạy mới đạt từ 73 đến 85 phần trăm, trong khi các lượt chạy cũ chỉ đạt từ 11 đến 77 phần trăm. Mọi cấu hình của hệ thống mới sau đó đều đạt 100 phần trăm.

Hệ thống swarm cũ tạo ra nhiều công việc hơn là hoàn thành chúng.

Các lượt chạy của Grok 4.5 cho thấy lý do tại sao hệ thống cũ bị tụt hậu. Hệ thống swarm cũ tạo ra 68.000 commit trong hai giờ, gấp khoảng 70 lần so với hệ thống mới. Phần lớn hoạt động đó là công việc lãng phí. Lượt chạy cũ tích lũy hơn 70.000 xung đột hợp nhất, trong khi lượt chạy mới duy trì dưới 1.000 trong suốt quá trình thử nghiệm.

Tệp tin bị tranh chấp nhiều nhất trong lượt chạy cũ ghi nhận 7.771 xung đột từ 1.173 tác nhân, so với 47 trong lượt chạy mới. Vấn đề "não phân tách" tương tự cũng xuất hiện trong cấu trúc gói. Lượt chạy cũ chia dự án thành 54 crate Rust với ba gói SQL riêng biệt. Lượt chạy mới đã sớm thống nhất ở con số chín crate.

Trong cấu hình Fable 5, hệ thống swarm cũ cần 64.305 dòng mã engine, trong khi hệ thống mới chỉ cần 9.908 dòng. Trong cấu hình Opus, hệ thống cũ tạo ra 19.013 dòng và đạt 97 phần trăm. Hệ thống mới đạt 100 phần trăm với 4.645 dòng.

Các mô hình thực thi rẻ hơn tạo ra mức tiết kiệm lớn nhất.

Tổng chi phí dao động từ 1.339 đô la cho mô hình lai Opus đến 10.565 đô la cho GPT-5.5 chạy độc lập. Các tác nhân thực thi chiếm ít nhất 69 phần trăm số token trong mọi lượt chạy và thường là hơn 90 phần trăm. Token của tác nhân lập kế hoạch đắt hơn, vì vậy cơ cấu chi phí trông có vẻ khác biệt. Trong mô hình lai Opus, tác nhân lập kế hoạch chỉ tạo ra một phần nhỏ số token nhưng chiếm tới hai phần ba tổng hóa đơn.

Mô hình thực thi tạo ra khoảng cách chi phí lớn nhất. Trong lượt chạy GPT-5.5, riêng các tác nhân thực thi đã tốn 9.373 đô la. Trong lượt chạy sử dụng Opus và Composer, toàn bộ đội ngũ tác nhân thực thi chỉ tốn 411 đô la với chất lượng tương đương. Sự khác biệt gần như hoàn toàn nằm ở giá cả. Composer 2.5 đạt điểm chuẩn ở mức của Opus 4.7 và GPT-5.5 nhưng chỉ tốn 0,50 đô la cho mỗi triệu token đầu vào và 2,50 đô la cho mỗi triệu token đầu ra. Theo nhà sáng lập Cursor Michael Truell, mô hình này dựa trên Kimi K2.5.

Cursor lập luận rằng chỉ một vài phần của một tác vụ lớn mới cần đến trí thông minh của một mô hình tiên tiến, bao gồm việc chia nhỏ tác vụ và các quyết định thiết kế quan trọng. Một khi tác nhân lập kế hoạch tiên tiến giải quyết được sự mơ hồ, các mô hình rẻ hơn có thể tuân theo kế hoạch đó, mặc dù các lượt chạy lai cho thấy chất lượng của tác nhân lập kế hoạch vẫn rất quan trọng. Tác nhân lập kế hoạch Fable 5 sử dụng ít token lập kế hoạch hơn Opus, nhưng các tác nhân thực thi của nó lại cần nhiều token hơn để hoàn thành công việc. Tổng thể lượt chạy Fable tốn kém hơn.

Cursor mô tả các hệ thống swarm như một loại trình biên dịch xác suất giúp chuyển đổi ý định thành công việc có thể thực thi từng bước một. Công ty cho biết việc mô tả chính xác ý định đó là hạn chế chính trong thí nghiệm. Cursor đã công bố cơ sở mã từ lượt chạy Opus độc lập dưới tên minisqlite trên GitHub.

Những lượt chạy như thế này không còn giới hạn trong các thí nghiệm phòng lab. Một phiên bản tiền phát hành của Fable 5 đã xử lý phần lớn quá trình viết lại Bun từ Zig sang Rust. 64 phiên bản đã viết hơn một triệu dòng mã trong 11 ngày với chi phí khoảng 165.000 đô la. Việc sử dụng trong thực tế vẫn có sự khác biệt. Một nghiên cứu được công bố vào cuối năm 2025 cho thấy 68 phần trăm các tác nhân được sử dụng trong thực tế không hoàn thành quá mười bước trước khi con người can thiệp. Đối với 47 phần trăm, giới hạn này là dưới năm bước.