Cursor построила рой ИИ-агентов, который переписал SQLite с нуля

Компания Cursor (разработчик одноимённой ИИ-среды разработки) описала, как перешла от стихийных экспериментов с «роями» совместно работающих агентов к их осознанному инженерному проектированию. Первый флагманский проект, долгоживущий рой, который с нуля собирал веб-браузер, сработал как доказательство концепции, но получившийся продукт был далёк от готового продукта. С тех пор цель команды, научиться управлять роем настолько хорошо, чтобы конструировать его целенаправленно, а не нащупывать вслепую.

Чтобы проверить прогресс, Cursor вернулась к задаче, с которой старый рой справлялся плохо: реализовать SQLite с нуля на языке Rust, опираясь исключительно на 835-страничное руководство к SQLite. Роям не давали ни исходный код, ни тестовые наборы, ни сам бинарник SQLite, ни доступ в интернет. Прогресс измеряли тестовым набором sqllogictest, набором из миллионов SQL-запросов с заранее известными правильными ответами, о существовании которого рой не знал заранее. После каждого запуска инженеры вручную проверяли код и ход работы на предмет читерства и обхода задачи.

Архитектура роя устроена как дерево. Агенты-планировщики (на самых мощных моделях) разбивают цель на части и делегируют их; агенты-исполнители (на более быстрых и дешёвых моделях) выполняют эти части. Планировщик никогда не занимается реализацией, поэтому его контекст не забивается деталями, а исполнитель никогда не планирует и тратит весь контекст на одну узкую задачу, в этом, по мнению Cursor, и кроется секрет масштабируемости роя, а не просто в параллелизме. Команда проводит параллель с экономистом Рональдом Коузом, который объяснял существование фирм тем, что издержки координации растут быстрее самой работы, поэтому организации выстраиваются в уровни, а не позволяют всем говорить со всеми напрямую.

Поскольку обычные инструменты вроде Git используют грубую блокировку файлов, не рассчитанную на сотни одновременно работающих агентов, Cursor построила собственную систему контроля версий с нуля. Старый рой-браузер выходил на пик около 1000 коммитов в час на Git; новая система держит пик около 1000 коммитов в секунду.

При такой скорости команда столкнулась с отказами, которых не бывает у людей, и придумала под каждый из них отдельное решение. «Раздвоение реальности», когда два планировщика, не зная друг о друге, реализуют одну и ту же концепцию по-разному в разных частях кода, устранили промптингом: планировщики сами принимают архитектурные решения и следят, чтобы делегированные ветви задач не пересекались по смыслу. Более сложный случай, конфликт между планировщиками, знающими друг о друге и правящими одни и те же файлы туда-обратно, решили через общие документы с проектными решениями: код хранит проверяемую компилятором ссылку на решивший его документ, а отдельный агент-«примиритель» сводит противоречащие друг другу документы и распространяет итоговое решение по коду. Обычные конфликты слияния между исполнителями разрешает нейтральный агент-посредник, работающий по принципу очереди слияний в инженерных командах. С «мегафайлами», в которые постоянно понемногу пишут разные агенты и которые становятся дорогими для передачи, сравнения и слияния, борются так: исполнители помечают разросшийся файл, новые коммиты в него блокируются, и отдельный агент разбивает файл на модули. А «окостенение», когда агенты, наученные не трогать чужой код, избегают нужных изменений в ядре системы, команда решила разрешением намеренной поломки: агент, уверенный в необходимости изменения ядра, вносит точечный патч и оставляет комментарий с объяснением; компилятор доносит поломку до всех зависимых частей системы, и каждый агент, наткнувшись на ошибку сборки, читает объяснение и приводит свой участок в соответствие.

Для контроля качества Cursor опробовала несколько «линз ревью»: агенту-рецензенту давали то полную стенограмму работы исполнителя, то только результат, то вообще ничего, кроме кодовой базы, а также запускали рецензентов на разных моделях с разным обучением и «характером». Ни одна линза не ловит всё сама по себе, но несколько несогласованных друг с другом линз вместе дают надёжность выше человеческой, по аналогии с системами беспилотного вождения, где такой же эффект достигается без единого идеального компонента. Отдельный эксперимент, «полевой справочник» (Field Guide): папка, которую полностью ведут сами агенты, чей индексный файл автоматически подгружается в контекст каждого нового агента при старте; единственное ограничение, бюджет строк. Логика в том, что веса моделей заморожены, поэтому ценно фиксировать именно неожиданные находки, чтобы путь следующего агента к решению был короче, похожий принцип координации использует, например, муравьиная колония.

В финальном сравнении новый рой обошёл старый во всех четырёх протестированных конфигурациях моделей: GPT-5.5 в роли и планировщика, и исполнителя; Grok 4.5 в обеих ролях; Opus 4.8 как планировщик с Composer 2.5 как исполнителем; Fable 5 как планировщик с Composer 2.5 как исполнителем. Гибрид с Fable 5 прошёл около двух третей тестового набора уже за первый час. К отметке в четыре часа новые запуски прошли от 73% до 85% тестов, тогда как старые, от 11% до 77%. На связке Grok 4.5 разница была особенно наглядной: старый рой пришлось остановить, не дойдя до двухчасовой отметки, после того как он накопил более 70 000 конфликтов слияния, и их число росло, а не стабилизировалось, несмотря на то что за первые два часа он сделал 68 000 коммитов (примерно в 70 раз больше, чем новый рой за тот же срок). Новый же рой на Grok 4.5 за все четыре часа зафиксировал менее тысячи конфликтов и в итоге прошёл 100% тестового набора. Помимо теста с SQLite, Cursor уже применяет тот же подход внутри компании, для поиска и исправления уязвимостей в открытом коде, повышения покрытия тестами собственной кодовой базы и генерации миллиардов токенов синтетических обучающих данных.

Ключевые факты

Cursor построила собственную систему контроля версий для роя агентов: Git с его грубыми блокировками не тянет сотни одновременных агентов, старая система держала ~1000 коммитов в час, новая, ~1000 коммитов в секунду.
Архитектура, дерево из агентов-планировщиков (мощные модели, только декомпозиция и делегирование) и агентов-исполнителей (быстрые/дешёвые модели, только узкая работа), так контекст каждого агента не размывается.
Тест: реализовать SQLite с нуля на Rust по одной 835-страничной документации, без исходников, тестов, бинарника и интернета; прогресс мерили скрытым от роя тестовым набором sqllogictest.
Новый рой обошёл старый во всех 4 конфигурациях моделей (GPT-5.5, Grok 4.5, Opus 4.8 + Composer 2.5, Fable 5 + Composer 2.5): 73-85% пройденных тестов за 4 часа против 11-77% у старой версии; на Grok 4.5 новый рой дошёл до 100%, старый пришлось остановить после 70 000+ нарастающих конфликтов слияния.
Для устойчивости роя внедрили набор специализированных агентов-«регулировщиков»: «примиритель» конфликтующих проектных решений, нейтральный агент для разрешения конфликтов слияния, авторазбиение разросшихся «мегафайлов» и общий самописный агентами справочник «Field Guide».

Почему это важно

Cursor показывает переход от стихийного масштабирования одного агента к инженерно спроектированной многоагентной системе с инфраструктурой, построенной специально под темп работы сотен агентов, включая систему контроля версий на 1000 коммитов в секунду, которую обычный Git физически не выдерживает. Материал описывает конкретные отказы, характерные именно для машинной скорости координации (раздвоение реальности, окостенение кода, конфликты между планировщиками), и рабочие способы их устранения, это редкий уровень инженерной детализации для темы мультиагентных систем.

Кому это важно

Инженерам, которые проектируют мультиагентные ИИ-системы и оркестрацию нескольких моделей; командам, оценивающим агентную разработку ПО как подход; исследователям координации агентов; всем, кто следит за практикой Cursor как одного из заметных игроков в ИИ-разработке кода.

Как это применить

Материал описывает конкретные архитектурные приёмы, которые можно позаимствовать при построении собственных мультиагентных пайплайнов: разделение ролей планировщик/исполнитель для экономии контекста, общие документы с проектными решениями плюс агент-«примиритель» для их согласования, нейтральный агент-посредник для конфликтов слияния, автоматическое разбиение разросшихся файлов и самописный агентами общий справочник (Field Guide) с бюджетом строк для передачи знаний между запусками. Это описание собственной инфраструктуры Cursor, а не публичный продукт или API, цен, лицензий и условий использования в материале нет.

Можно ли доверять

Это собственный блог Cursor, компании, прямо заинтересованной в том, чтобы её метод выглядел убедительно, поэтому цифры и выводы стоит воспринимать как маркетинговое позиционирование, а не независимо проверенное исследование. В пользу доверия говорит методологическая аккуратность: тестовый набор sqllogictest скрывали от роя заранее, а после каждого запуска код и ход работы вручную проверяли на читерство и обход задачи. Материал собрал 158 очков и 66 комментариев на Hacker News, что говорит об интересе технического сообщества, но не о независимой проверке результатов.

Риски и подводные камни

Все данные, от первого лица, без внешней верификации; задача (реализация SQLite по документации с нуля), синтетическое упражнение, а не перенос реального проекта с людьми в цикле, и не факт, что приёмы одинаково хорошо сработают на боевой кодовой базе с историей и внешними зависимостями. Разброс итоговой стоимости запусков в тексте назван «огромным», но конкретных цифр не приведено. Проверенных данных о том, как рой ведёт себя при совместной работе с людьми-разработчиками, в материале нет.

«Старый запуск накопил более 70 000 конфликтов слияния, прежде чем мы его остановили, и их число росло, а не стабилизировалось, тогда как новая система зафиксировала менее тысячи конфликтов за все четыре часа работы.»

— Cursor, блог компании