Как Cursor делает AI-агента лучше: от guardrails к динамическому контексту
Cursor опубликовала инсайты о совершенствовании AI-агента для разработки. Главное: нужно менять архитектуру контекста — от жёстких ограничений к динамическому з

Cursor опубликовала подробное исследование о разработке и постоянном совершенствовании своего AI-агента для кодирования. Главный вывод: одного мощного языковой модели недостаточно. Даже самые продвинутые модели нуждаются в хорошем «каркасе» (harness) — системе промптов, инструментов, управления контекстом и метрик оценки. Статья рассказывает не просто о результатах, но о методологии: как Cursor тестирует гипотезы, измеряет качество и адаптирует архитектуру к новым возможностям моделей.
Эволюция контекстного окна
Когда Cursor в конце 2024 разрабатывал своего первого кодирующего агента, языковые модели были ещё не очень умны в самостоятельном выборе, что включать в контекст. Поэтому команда потратила месяцы на разработку guardrails — жёстких ограничений и правил, которые направляли агента в нужное русло. Старый подход выглядел так: После каждого редактирования подсовывала агенту ошибки линтера и type-checker Переписывала запросы файлов, если агент запрашивал недостаточно строк кода Ограничивала количество инструментов, которые агент может вызвать за один цикл Предоставляла массу статического контекста — структуру папок, сниппеты и сжатые версии файлов Получалось примитивно, но работало.
Модель была слаба и нуждалась в направлении. Но с быстрым ростом способностей моделей Cursor постепенно отказывалась от guardrails. Современный подход совсем другой: агент получает минимум статического контекста — в основном только информацию об ОС, git-статус, текущие и недавно просмотренные файлы.
Всё остальное агент запрашивает динамически, по мере надобности. Он сам ищет нужные файлы в кодбейсе, запрашивает документацию и анализирует ошибки в реальном времени. Вот что значит, что модель повзрослела.
Как измеряют реальное качество
Определить, действительно ли улучшение работает, — это нетривиальная задача для продукта. Cursor использует двухуровневый подход, комбинируя синтетические тесты и реальные данные от пользователей. На первом уровне — публичные бенчмарки (вроде CursorBench), которые дают быстрый снимок качества и позволяют сравнивать результаты во времени.
Но бенчмарки, даже хорошие, только приблизительно отражают реальное использование. Агент может отлично пройти тест в лабораторных условиях, но в реальной работе не сработать. Поэтому на втором уровне Cursor запускает A/B-тесты на реальных пользователях, сравнивая несколько вариантов harness'а одновременно.
Здесь появляются метрики, которые действительно важны: Latency — как быстро агент даёт первый ответ Token efficiency — сколько токенов потратил на один запрос Tool call count — сколько раз обратился к инструментам Cache hit rate — как часто переиспользовал закешированный контекст Но самая важная метрика — Keep Rate. Это доля кода, который остаётся в кодбейсе спустя неделю, месяц после выполнения задачи. Если пользователь часто переделывает сгенерированный код или вынужден вручную исправлять ошибки — Keep Rate падает.
Это сигнал: агент не справился.
Что это означает
Подход Cursor показывает важную истину: качество AI-агента зависит не только от модели, но и от архитектуры вокруг неё. Жёсткие guardrails помогают слабым моделям, но замораживают их. Динамический контекст открывает потенциал лучшим моделям, позволяя им самостоятельно исследовать проблему. Главный вывод: не спешите ждать идеальной модели. Потратьте время на архитектуру harness'а и способность быстро тестировать гипотезы. Потому что качество агента определяет не скорость ответа и не объём токенов — определяет то, остаётся ли результат его работы в коде спустя время.