Агенти-рої (Agent Swarms) та нова економіка моделей — Як мультиагентні системи змінюють розробку

Вступ: Світанок нової парадигми агентів

У липні 2026 року Cursor опублікував дослідницький блог-пост, який сколихнув всю AI-індустрію. Компанія порівняла два покоління мультиагентних систем — стару та нову — виконуючи одне монументальне завдання: створення повноцінного рушія бази даних SQLite з нуля на Rust, використовуючи лише 835-сторінкову документацію як джерело. Результати вражають: нова система не лише показала вищу якість за всіма показниками, але й зробила це за значно меншу вартість — з $10,565 до $1,339.

Це більше, ніж поступове технічне вдосконалення. Це фундаментальний зсув у тому, як ми мислимо економіку використання AI-моделей. Підхід Cursor демонструє, що майбутнє належить не одній монолітній дорогій frontier-моделі, яка робить все. Натомість майбутнє належить інтелектуально скоординованим командам агентів — роям — де кожна модель використовується відповідно до своїх порівняльних переваг.

Як працює агентний рій Cursor

У центрі нової системи лежать дві різні ролі: Планувальники (Planners) та Працівники (Workers). Планувальники, які працюють на найрозумніших (і найдорожчих) frontier-моделях, розбивають велику ціль на частини та делегують їх. Працівники — зазвичай швидші та значно дешевші моделі — виконують ці частини.

Цей дизайн є надмножиною більш жорстких систем оркестрації. Замість нав'язування фіксованої топології задачі, форма рою природно розростається, щоб покрити контури проблеми. Обчислювальна потужність і контекст масштабуються пропорційно до складності завдання. Саме тому цей підхід узагальнюється на такі різноманітні завдання, як створення браузера, розв'язання математичних задач, оптимізація GPU-ядер, пошук вразливостей у відкритому коді та генерація мільярдів токенів синтетичних тренувальних даних.

Команда Cursor виявила, що ключова перевага — це не паралелізм як такий, а ефективність контексту. Коли один агент береться за повне завдання, йому доводиться самостійно проходити все дерево — спускатися до кожного листка, утримуючи в контексті предків, поточну позицію та загальну мету. Це пояснює, чому довготривалі одиночні агенти збиваються: вони або фокусуються на роботі перед собою і втрачають загальну картину, або тримають загальну картину і гірше виконують конкретну частину.

У рої планувальник ніколи не імплементує, тому його контекст ніколи не заповнюється низькорівневими деталями. Працівник ніколи не планує, тому може витратити весь свій контекст на одну вузьку частину роботи. Відлуння цієї структури можна знайти в теорії організацій — економіст Рональд Коуз стверджував, що витрати на координацію зростають швидше, ніж сама робота, тому організації формують обмежені рівні, а не дозволяють усім спілкуватися з усіма.

Власна система контролю версій: 1000 комітів за секунду

Одне з найбільш вражаючих технічних досягнень у новій системі Cursor — це власна система контролю версій. У той час як старий рій досягав приблизно 1000 комітів на годину в Git, нова система досягає близько 1000 комітів за секунду. Традиційні механізми блокування Git, розроблені для людей-розробників, просто не витримують такого темпу.

За такої екстремальної пропускної здатності рій стикається з режимами відмов, з якими людські команди ніколи регулярно не стикаються:

• Split-brain дизайн — Два планувальники, не знаючи один про одного, реалізують ту саму концепцію по-різному в різних частинах кодової бази. Cursor виправив це через промптінг: планувальники повинні гарантувати, що жодні два делеговані піддерева не вирішують те саме питання.
• Merge-конфлікти — Старий запуск накопичив понад 70,000 конфліктів, перш ніж був зупинений. Новий запуск зафіксував менше тисячі. Рішення: нейтральний сторонній агент втручається в merge-конфлікти та вирішує їх неупереджено.
• Мегафайли — Певні файли стають настільки популярними, що виникають постійні колізії. Працівники тепер можуть позначати роздуті файли, блокуючи нові коміти, доки зовнішній агент не розкладе перерослий файл на менші модулі.
• Осифікація — Агенти навчилися не торкатися основного коду, навіть коли це потрібно. Рішення Cursor: «ліцензоване навмисне поламання». Агент, який вважає зміну ядра вартою, робить цілеспрямований патч і залишає коментар із поясненням. Компілятор проводить зміну далі — все, що залежить від старої конструкції, не будується, і кожен агент, який натрапляє на помилку, знаходить коментар і оновлює свою частину.

Експеримент SQLite: Цифри, які говорять самі за себе

Cursor протестував новий рій у чотирьох конфігураціях моделей: GPT-5.5 (і планувальник, і працівник), Grok 4.5 (обидві ролі), Opus 4.8 + Composer 2.5 (гібрид), та Fable 5 + Composer 2.5 (інший гібрид). Прогрес вимірювався за допомогою sqllogictest — тестового набору, що містить мільйони SQL-запитів з відомими правильними відповідями.

Результати однозначні: нове середовище перевершило старе у всіх комбінаціях. Гібрид Fable 5 пройшов приблизно дві третини набору вже в першу годину. На чотиригодинній позначці нові запуски показували від 73% до 85%, тоді як старі — від 11% до 77%. Кожна нова конфігурація згодом досягала 100% проходження.

Але найбільш вражаюча різниця — у самому коді. У комбінації Fable 5 обидва рої врешті пройшли повний набір, але старому знадобилося 64,305 рядків коду рушія, тоді як новий впорався лише за 9,908 рядків. Комбінація Opus показує ту саму картину: 19,013 рядків при 97% у старому середовищі проти 4,645 рядків при 100% у новому.

Дані про merge-конфлікти розповідають схожу історію. Старий запуск накопичив понад 70,000 конфліктів, прискорюючись замість стабілізації. Найгарячіший файл зібрав 7,771 конфлікт, яких торкнулися 1,173 різних агенти. У новому запуску найбільш оспорюваний файл у всій кодовій базі мав лише 47 конфліктів. Старий запуск розрісся до 54 крейтів (включно з трьома окремими SQL-пакетами); новий зупинився на дев'яти крейтах і більше не додавав жодного.

Економіка моделей: Головне відкриття

Це найважливіший розділ посту Cursor. Хоча кожна комбінація моделей дала схожу якість, витрати кардинально відрізнялися — від $1,339 для гібриду Opus 4.8 до $10,565 для одного GPT-5.5.

Дані про токени розкривають причину. Структура витрат була однаковою в усіх запусках: працівники становили щонайменше 69% токенів, а в більшості випадків — понад 90%. Але долари розподілялися інакше, ніж токени, тому що токени планувальників дорожчі. У комбінації Opus 4.8 + Composer 2.5, Opus-як-планувальник створив невелику частку токенів, але приблизно дві третини вартості, тоді як Composer-як-працівник обробив переважну більшість токенів за третину вартості.

Висновок Cursor вражає: «Лише кілька моментів у великому завданні дійсно потребують frontier-інтелекту» — початкове розбиття, дизайнерські рішення та певні компроміси. Щойно frontier-планувальник перетворив невизначеність на детальну, явну інструкцію, менш дорогі моделі просто мають її виконувати. Це величезне джерело потенційної економії.

Цифри говорять самі за себе: у запуску з GPT-5.5 для обох ролей, самі лише працівники коштували $9,373. У запуску, де Opus 4.8 планував, а Composer 2.5 працював, весь флот працівників коштував $411 — у 22 рази менше.

Польовий посібник: Самовторене спільне знання

Один із найбільш інноваційних експериментів Cursor — це «Польовий посібник» (Field Guide) — папка, яка повністю належить агентам, чий index.md автоматично впроваджується кожному агенту при запуску. Агенти самі вирішують, що потрапить до посібника; їхнє єдине обмеження — бюджет рядків.

Це базується на біологічному принципі стигмергії — механізмі, за допомогою якого мурахи та терміти координуються через формування середовища, а не пряму комунікацію. Логіка елегантна: ваги моделей заморожені, тому саме несподівані зустрічі варто фіксувати, щоб траєкторія наступного агента була коротшою. Польовий посібник — це ще ранній експеримент, але його наслідки глибокі: навчання моделей писати для своїх наступників, де кращий запис веде до кращих результатів, відкриває цілий новий напрям досліджень.

Специфікації як промпти: Нова одиниця роботи

Cursor робить глибоке спостереження: кожен стрибок у можливостях AI підняв рівень абстракції, на якому може працювати інженер. Автодоповнення дозволяло працювати по одному рядку. Ранні моделі підняли це до блоку коду. Агенти підняли до файлу або функції. З роями одиницею роботи стає специфікація.

Подивившись так, рій починає нагадувати компілятор. Компілятор перекладає вихідний код у машинний через серію проміжних кроків. Рій робить щось подібне з наміром (intent). Планувальники розбирають ціль на дерева завдань, потім опускають її крок за кроком до виконуваної роботи. Різниця в тому, що компілятор зберігає значення на кожному кроці, тоді як рій імовірнісний на кожному з них. Все, описане в пості Cursor, існує, щоб закрити цю прогалину.

Що це означає для українських розробників

Дослідження Cursor має прямі наслідки для того, як будь-яка команда має мислити про використання AI. Мультиагентні системи більше не є виключною сферою великих корпорацій; вони стають доступними для будь-якої команди, яка хоче оптимально використовувати AI.

Якщо дешеві моделі (як Composer 2.5) можуть виконувати 90% роботи, а дорогі моделі використовуються лише для стратегічних рішень, економіка використання AI радикально змінюється. Для агенцій на кшталт SiTech, які активно використовують AI у клієнтських проєктах, цей підхід може стати конкурентною перевагою: нижчі витрати, вища якість і швидша доставка. Головний висновок очевидний — майбутнє AI-асистованої розробки не у великих моделях, а в розумнішій координації між моделями різних можливостей і вартості.

Cursor зробив код публічним на github.com/cursor/minisqlite — кожен може на власні очі побачити, що може створити добре скоординований агентний рій.

📖 Джерело