Roje agentów AI: tańsze modele piszą kod, gdy drogie planują

Wyobraź sobie zespół programistów, w którym jedni są genialnymi architektami, a drudzy – szybkimi i wydajnymi wykonawcami. Firma Cursor, znana z narzędzi wspomagających kodowanie, przeniosła tę logikę do świata sztucznej inteligencji. Ich najnowszy eksperyment z „rojami agentów” pokazuje, że podział ról między modelami AI może przynieść spektakularne efekty – zarówno pod względem jakości kodu, jak i kosztów. Zamiast polegać na jednym, drogim modelu, Cursor udowodnił, że inteligencja rozłożona na wiele warstw działa wydajniej.

Jak działa podział ról w roju agentów?

Kluczowym pomysłem Cursora jest rozdzielenie odpowiedzialności. W tradycyjnym podejściu jeden agent AI musiał ogarniać cały kontekst – od ogólnego celu po szczegóły bieżącego zadania. To prowadziło do „dryfu”, czyli stopniowego oddalania się od zamierzonego rezultatu podczas długich sesji kodowania. Nowa architektura eliminuje ten problem, tworząc dwie wyspecjalizowane kategorie agentów.

Planiści – mózg operacji

Do roli planistów Cursor wyznaczył najpotężniejsze modele, takie jak Opus 4.8 czy Fable 5. Ich zadaniem nie jest pisanie kodu, ale rekurencyjne rozbijanie głównego celu na mniejsze, łatwiejsze do zarządzania zadania. To oni tworzą „drzewo zadań”, które dynamicznie dostosowuje się w miarę postępu prac. Planiści podejmują kluczowe decyzje projektowe i rozwiązują niejasności, zanim trafią one do wykonawców.

Wykonawcy – precyzja i szybkość

Druga grupa to pracownicy (worker agents), korzystający z tańszych i szybszych modeli, np. Composer 2.5. Ich zadanie jest proste: realizować przydzielone im podzadania bez zastanawiania się nad ogólną strategią. Dzięki temu mogą pracować równolegle i znacznie szybciej. Jak podkreślają twórcy, skala roju nie polega na równoległej pracy, ale na umiejętnym rozdzieleniu kontekstu – planiści decydują, wykonawcy działają.

Rozwiązanie problemu konfliktów i „split-brain”

Wcześniejsze eksperymenty Cursora z rojami przeglądarek internetowych ujawniły poważne wyzwania. Gdy agentów było zbyt wielu, a ich praca nie była odpowiednio koordynowana, dochodziło do sytuacji „split-brain” – dwóch planistów nieświadomie implementowało ten sam pomysł w różnych miejscach i na różne sposoby. Tradycyjny system kontroli wersji, jak Git, nie radził sobie z tempem 1000 commitów na sekundę, generując wąskie gardła zamiast je usuwać.

Cursor musiał więc stworzyć własny system kontroli wersji i nowe reguły współpracy. Aby uniknąć konfliktów, agenci zaczęli zapisywać swoje decyzje we wspólnych dokumentach projektowych. Każda linia kodu była powiązana z konkretną decyzją, a referencje sprawdzano na etapie kompilacji. Gdy mimo wszystko dochodziło do konfliktów scalania, neutralny agent pełnił rolę mediatora. Co ciekawe, Cursor pozwolił agentom celowo „łamać” rzeczy – agent mógł modyfikować kod poza swoim obszarem, a kompilator sam przenosił zmiany w odpowiednie miejsce. To odwrócenie tradycyjnej ostrożności, gdzie agenci uczą się nie ruszać rdzenia systemu, okazało się kluczowe dla elastyczności.

Wyniki benchmarku: jakość i koszty

Aby przetestować nową architekturę, Cursor postawił przed rojem ambitne zadanie: zbudować implementację bazy danych SQLite w języku Rust, mając do dyspozycji jedynie 835-stronicowy podręcznik. Bez dostępu do kodu źródłowego, pakietów testowych ani internetu. Testem weryfikacyjnym był sqllogictest – zestaw zawierający miliony zapytań SQL i znane odpowiedzi. Rój nie wiedział o jego istnieniu.

Porównano cztery konfiguracje: samodzielne modele GPT-5.5 i Grok 4.5 oraz hybrydy (Opus + Composer, Fable + Composer). Wyniki były jednoznaczne. Nowy system przewyższył stary w każdej konfiguracji. Po czterech godzinach nowe roje osiągały od 73 do 85 procent poprawności, podczas gdy stare – od 11 do 77 procent. Co więcej, każda konfiguracja nowego systemu ostatecznie osiągnęła 100 procent. Stary roj generował 68,000 commitów w dwie godziny (70 razy więcej niż nowy), ale większość tej pracy była daremna. Narobił ponad 70,000 konfliktów scalania, podczas gdy nowy utrzymał się poniżej 1,000. Najbardziej konfliktowy plik w starym systemie odnotował 7,771 konfliktów od 1,173 agentów – w nowym było to zaledwie 47.

Różnica w jakości architektury przełożyła się na rozmiar kodu. W konfiguracji z Fable 5, stary roj potrzebował 64,305 linii kodu silnika, nowy – 9,908. W przypadku Opusa, stary system wyprodukował 19,013 linii przy 97-procentowej skuteczności, a nowy osiągnął 100 procent z 4,645 liniami. To redukcja kodu nawet o 85 procent przy tych samych lub lepszych wynikach testów.

Gdzie leżą prawdziwe oszczędności?

Koszty całkowite wahały się od $1,339 dla hybrydy Opus do $10,565 dla samodzielnego GPT-5.5. W każdej konfiguracji wykonawcy odpowiadali za co najmniej 69 procent tokenów, a często ponad 90 procent. Tokeny planistów były droższe, więc proporcje kosztów wyglądały inaczej – w hybrydzie Opus, planista wygenerował mały ułamek tokenów, ale stanowił dwie trzecie rachunku. Największą różnicę zrobił jednak wybór modelu wykonawcy. W przypadku GPT-5.5, sami wykonawcy kosztowali $9,373. W konfiguracji Opus + Composer, cała flota wykonawców kosztowała $411 przy porównywalnej jakości. Różnica sprowadza się do cennika – Composer 2.5, oparty na Kimi K2.5, kosztuje zaledwie $0,50 za milion tokenów wejściowych i $2,50 za milion wyjściowych, a dorównuje wydajnością modelom za kilkadziesiąt razy więcej.

Jak podsumowuje Michael Truell, założyciel Cursora, tylko kilka elementów dużego zadania wymaga inteligencji modeli granicznych: rozbicie na podzadania i kluczowe decyzje projektowe. Gdy planista rozwiąże niejasności, tańsze modele mogą śledzić jego plan. Mimo to, jakość planisty wciąż ma znaczenie – Fable 5 używał mniej tokenów planistycznych niż Opus, ale jego wykonawcy potrzebowali znacznie więcej tokenów, by dokończyć pracę, co podniosło całkowity koszt.

Cursor opisuje swoje roje jako rodzaj probabilistycznego kompilatora, który krok po kroku tłumaczy intencje na wykonywalną pracę. Firma udostępniła kod źródłowy z eksperymentu na GitHubie jako minisqlite. Co ważne, te eksperymenty nie są już tylko laboratoryjne – przedpremierowa wersja Fable 5 przepisała większość kodu Buna z Ziga na Rusta, a 64 instancje napisały ponad milion linii kodu w 11 dni za około $165,000. Jednak w produkcji wygląda to inaczej – badanie z końca 2025 roku wykazało, że 68 procent agentów używanych w produkcji nie wykonało więcej niż dziesięć kroków przed interwencją człowieka. Dla 47 procent limit wynosił mniej niż pięć kroków. To pokazuje, że droga od spektakularnego eksperymentu do codziennego narzędzia wciąż jest długa.