Теперь в работу вступает модель-исполнитель или генератор. Это уже более тяжелая модель, например GPT-4o или Claude 3.5 Sonnet. Генератор должен уметь превращать абстрактные пункты плана в конкретный JSON с правильными параметрами. Он должен понимать структуру вызовов инструментов, правильно формировать пути к файлам и обрабатывать краевые случаи. Модель-исполнитель генерирует не текст, а JSON с вызовом инструмента поиска файлов с параметром nano_gpt.py. Клиент Cursor, десктопное приложение, перехватывает этот JSON и реально идет в файловую систему компьютера, ищет файл и читает его содержимое. Содержимое файла отправляется обратно в оркестратор. Оркестратор решает, что план выполнен частично, и передает содержимое файла следующей модели в цепочке.
Шаг третий. Проверка зависимостей и запрос разрешения на терминал.
Модель-ревьювер или аналитик получает содержимое файла и текущий пункт плана. Это снова тяжелая модель, сравнимая по размеру с генератором, потому что ей нужно глубоко понимать код и его зависимости. Ревьювер находит в коде импорт PyTorch и понимает, что менять размер слоев без проверки зависимостей рискованно. Она добавляет новый пункт в план: проверить, что PyTorch установлен и имеет правильную версию. Модель-исполнитель (генератор) снова вызывается и генерирует JSON с вызовом терминальной команды pip show torch.
В этом месте Cursor не выполняет команду автоматически. Вместо этого пользователь видит на экране диалоговое окно: "Агент хочет выполнить команду: pip show torch. Разрешить? Запретить? Разрешить всегда для этой сессии". Это сделано для безопасности. Агент не имеет права исполнять произвольный код на вашем компьютере без вашего ведома.
Пользователь нажимает "Разрешить". Клиент Cursor выполняет команду, получает вывод с версией PyTorch и отправляет этот вывод обратно в оркестратор. Оркестратор передает результат модели-ревьюверу, которая убеждается, что библиотека есть.
Если бы PyTorch не был установлен, модель-ревьювер приняла бы решение остановить выполнение. Оркестратор передал бы пользователю сообщение от модели-генератора: "В проекте используется PyTorch, но он не найден в системе. Установите его командой pip install torch и повторите запрос". После этого агент остановился бы и не трогал код, потому что понимает, что изменения приведут к ошибкам.
Шаг четвертый. Изменение файла.
Теперь снова вызывается модель-генератор. Она генерирует вызов инструмента записи файла с конкретным изменением. Генератор не перезаписывает весь файл, а генерирует патч, разницу между старым и новым содержимым. Вместо старой строчки n_embd = 768 появляется n_embd = 2048. Генератор использует самую свежую и умную модель, потому что от качества сгенерированного кода зависит итоговый результат.
Но и здесь агент не останавливается. После записи оркестратор вызывает внешний статический анализатор кода - это не LLM, а отдельная программа, Language Server Protocol, которая проверяет синтаксис и типы намного быстрее и точнее любой нейросети. Если анализатор находит проблему, например, что где-то дальше по коду размерность тензора не совпадает, эта ошибка отправляется в модель-ревьювер. Модель-ревьювер, которая по "умности" находится на уровне GPT-4o или Claude 3.5, анализирует ошибку и передает оркестратору указание: "Нужно исправить еще одну строчку". Оркестратор снова вызывает модель-генератор, та генерирует новый JSON с исправлением. Этот цикл может повторяться несколько раз, без участия пользователя, пока все ошибки не будут устранены.
Шаг пятый. Проверка работоспособности.
Если у агента есть разрешение на выполнение терминальных команд, оркестратор может передать команду на запуск измененного скрипта в тестовом режиме: python nano_gpt.py --dry-run. Результат выполнения возвращается модели-ревьюверу. Если скрипт упал с ошибкой, например не хватило памяти видеокарты, модель-ревьювер анализирует ошибку и предлагает альтернативное решение через модель-генератор. Модель-генератор пишет пользователю: "Я поменял размер на 2048, но ваша видеокарта не тянет. Предлагаю уменьшить размер батча до 4 или оставить 1024".