Пожалуй, сейчас каждая кликбейт новость идёт про создание ИИ-агентов. Почти все корпорации бигтех арены так или иначе участвуют в гонке агентов. Далеко зарубеж ходить не надо - например, Яндекс создает Алису с возможностью использования тулов, гигачат делает свое агентское IDE (Giga Code) и мультимодальную модель с походом в тулы (если кого-то обидел и какие-то отечественные компании тоже заводят амбициозные агентские системы, то пишите в комментах).
Давайте разберемся, что из себя представляет агент и как это работает на примере того (в общих чертах, разумеется без особой подноготной), как работает Cursor.
Допустим у нас есть крутая модель, например GPT-5.5, является ли она агентом априори? Де факто нет. Сама модель решает задачу пользователя одноэтапно отвечая на его запрос:
User: "Кто решил гипотезу Римана?" Assistant: "Пока что никто, но вы можете быть первым!"
Модель сама после ответа на запрос не проверяет сама себя. Мы можем промптить модель бесконечно, пока не придем к какому то решению.
Но, что, если мы в chat gpt зададим запрос, включив тулу web-поиска?
User: "Что говорят в новостях (интересуют исключительно лево направленные издания) про Илона Маска? Основывайся только на реальных цитатах и ссылках с источников" tool: web-search
Тут уже ассистент сформирует json с названием тулы, параметрами запроса. Далее клиент gpt сходит в поиск, вернет результат и вставит в контекст модели-ассистента, которая даст ответ запрос.
Но все еще, это одноэтапный формат, пусть и с тулами. Итак, мы уже ближе к пониманию того, что такое агент.
Теперь давайте посмотрим, чем Cursor отличается от этой схемы. Разберем на конкретном примере.
Пишем в Cursor запрос: "В моем проекте есть файл nano_gpt.py, поменяй в нем размер скрытых слоев на 2048".
Шаг нулевой. Классификация запроса.
Прежде чем запускать какие-либо модели, запрос пользователя попадает в классификатор. Это самая маленькая и быстрая модель, например специально обученный классификатор на базе BERT или DistilBERT, или даже обычный набор правил с регулярными выражениями. Классификатор не генерирует текст, он просто определяет тип запроса и маршрутизирует его дальше. Его задача - понять, что это за запрос: просьба написать новый код, запрос на изменение существующего кода, вопрос о проекте, команда запустить тесты или просто разговорный вопрос. В нашем случае классификатор определяет, что это запрос на изменение существующего кода, и направляет его не в обычный чат, а в агентский пайплайн с планировщиком и исполнителями. Если бы это был простой вопрос о том, как работает функция, запрос пошел бы по другому маршруту, к обычной модели для ответов на вопросы. Классификатор экономит ресурсы: тяжелые модели не вызываются, если задача этого не требует.
Шаг первый. Планирование.
После классификации запрос попадает в модель-планировщик. Это отдельная инстанция LLM, и здесь важно понимать - для планирования не нужна самая большая и умная модель. Cursor может использовать для планировщика модель поменьше и подешевле, например GPT-4o-mini или специально обученную небольшую модель. Планировщику не нужно генерировать сложный код, ему нужно только разбить задачу на логические шаги. Модель-планировщик получает промпт: "Сначала составь план действий. Не генерируй код, только последовательность шагов". Она генерирует внутренний план, который пользователь не видит:
1. Найти файл nano_gpt.py в корневой папке проекта. 2. Прочитать его содержимое. 3. Найти параметр, отвечающий за размер скрытых слоев (обычно это переменная n_embd или hidden_size). 4. Изменить значение этого параметра с текущего на 2048. 5. Проверить, не сломался ли синтаксис после замены. 6. Проверить, что все зависимости (библиотеки) установлены. 7. Если что-то пошло не так - скорректировать действия.
Это первый признак агента: он ставит подцели и продумывает последовательность, а не просто генерирует ответ. План передается дальше, в оркестратор.
Шаг второй. Чтение файла через вызов инструмента.