Как и в случае с любым инструментом, понимание того, как ИИ-агенты для разработки устроены изнутри, помогает принимать более взвешенные решения о том, как именно их применять.

Агент для разработки — это программа, которая служит оболочкой для LLM, расширяя возможности этой модели за счет дополнительных функций, задаваемых скрытыми промптами и реализованных в виде вызываемых инструментов.

Большие языковые модели 

В основе любого агента для разработки лежит большая языковая модель, или LLM. Это модели вроде GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro или Qwen3.5-35B-A3B.

LLM — это модель машинного обучения, способная продолжать текстовую фразу. Если дать модели начало предложения «кот сидит на…», она почти наверняка предложит слово «подоконнике» как следующее слово в этой фразе.

По мере того как такие модели становятся больше и обучаются на все более крупных объемах данных, они начинают продолжать и более сложные фразы — например: «Функция Python для загрузки файла по URL-адресу выглядит следующим образом: “def download_file(url): “».

LLM на самом деле работают не напрямую со словами, а с токенами. Последовательность текста преобразуется в последовательность целочисленных токенов, так что строка «кот сидит на…» превращается в [3086, 9059, 10139, 402, 290, 220]. Это важно понимать, потому что поставщики LLM берут плату исходя из числа обработанных токенов и ограничены тем, сколько токенов модель может учитывать одновременно.

Вы можете поэкспериментировать с токенизатором OpenAI и посмотреть, как это работает, на platform.openai.com/tokenizer.

Входные данные для LLM называются промптом. Текст, который возвращает LLM, называется completion (ответ модели) или просто ответ.

Сегодня многие модели являются мультимодальными, то есть умеют принимать на вход не только текст. Визуальные LLM (vLLM) могут принимать изображения как часть входных данных, поэтому им можно передавать изображения, фото или скриншоты. Распространенное заблуждение состоит в том, что такие данные сначала проходят через отдельный процесс оптического распознавания текста (OCR) или анализа изображений, но на деле они тоже преобразуются в дополнительные целочисленные токены и затем обрабатываются так же, как текст.

Шаблоны промптов в формате чата 

Первые LLM работали как движки для дополнения текста: от пользователя ожидалось, что он задаст запрос, который модель затем продолжит, как в двух примерах выше.

Это было не слишком удобно для пользователей, поэтому модели в основном перешли на шаблоны запросов в формате чата, где взаимодействие с моделью представлено как имитация диалога.

По сути, это все та же форма запроса на дополнение текста, только в специальном формате, который выглядит примерно так.

Пользователь: напиши функцию на Python для загрузки файла по URL-адресу
Ассистент:

Естественным продолжением такого запроса будет ответ асситсента, представленного LLM, на вопрос пользователя с помощью фрагмента кода на Python.

LLM не хранят состояние: каждый раз, когда они выполняют запрос, они начинают с одного и того же пустого состояния.

Чтобы поддерживать имитацию диалога, программное обеспечение, которое взаимодействует с моделью, должно само хранить состояние и заново передавать модели весь предыдущий разговор каждый раз, когда пользователь вводит новый запрос в чате:

Пользователь: напиши функцию на Python для загрузки файла по URL-адресу
Ассистент: def download_url(url):
    return urllib.request.urlopen(url).read()
Пользователь: используйте библиотеку requests вместо этого
Ассистент:

Поскольку поставщики моделей берут плату и за входные, и за выходные токены, это означает, что с ростом длины диалога каждый новый запрос становится дороже, потому что число входных токенов каждый раз увеличивается.

Кэширование токенов 

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

ИИ-агенты для разработки проектируются с учетом этой оптимизации: они стараются не изменять более раннее содержимое диалога, чтобы кэш использовался максимально эффективно.

Вызов инструментов

Ключевая особенность LLM-агента состоит в том, что такие агенты могут вызывать инструменты. Но что вообще считается инструментом?

Инструмент — это функция, которую оболочка агента делает доступной для LLM.

На уровне самого запроса это выглядит примерно так

Система: Если вам нужно получить доступ к погоде, завершите свой запрос с помощью команды <tool>get_weather(city_name)</tool>
Пользователь: Какая погода в Санкт-Петербурге?
Ассистент:

В этом случае ассистент может ответить следующим текстом:

<tool>get_weather("Санкт-Петербург")</tool>

После этого программное обеспечение оболочки модели извлекает из ответа запрос на вызов функции — вероятно, с помощью регулярного выражения — и выполняет соответствующий инструмент.

Затем результат возвращается модели в виде сформированного запроса, который выглядит примерно так:

Система: Если вам нужно получить доступ к погоде, завершите свой запрос с помощью <tool>get_weather(city_name)</tool>
Пользователь: Какая погода в Санкт-Петербурге?
Ассистент: <tool>get_weather("Санкт-Петербурге")</tool>
Пользователь: <tool-result>11°, Переменная облачность</tool-result>
Ассистент:

Теперь LLM может использовать результат работы инструмента, чтобы с его помощью сгенерировать ответ на вопрос пользователя.

Большинство агентов для разработки определяют для вызова агентом десяток или больше инструментов. Наиболее мощные из них позволяют выполнять код — например, инструмент Bash() для выполнения команд терминала или Python() для запуска Python-кода.

Системный запрос 

В предыдущем примере я включил начальное сообщение с пометкой «system», которое сообщало LLM о доступном инструменте и о том, как его вызывать.

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

Такие системные запросы могут занимать сотни строк. Вот, например, системный запрос для OpenAI Codex по состоянию на март 2026 года — это наглядный и полезный пример тех инструкций, благодаря которым такие ИИ-агенты для разработки вообще работают.

Рассуждение (reasoning)

Одним из крупнейших достижений 2025 года стало появление режима рассуждения в передовых семействах моделей.

Рассуждение, которое в интерфейсе иногда отображается как «thinking», означает, что модель тратит дополнительное время на генерацию текста, в котором разбирает задачу и возможные пути ее решения, прежде чем выдать пользователю ответ.

Это может напоминать то, как человек размышляет вслух, и производит схожий эффект. Что особенно важно, такой режим позволяет моделям тратить больше времени и больше токенов на работу над задачей, чтобы, как можно надеяться, получить более качественный результат.

Рассуждение особенно полезно при отладке кода, потому что дает модели возможность проходить по более сложным путям выполнения, сочетая это с вызовами инструментов и используя фазу рассуждения, чтобы проследить вызовы функций вплоть до возможного источника проблемы.

Во многих агентах для разработки есть настройки, позволяющие увеличивать или уменьшать интенсивность рассуждения, побуждая модель тратить больше времени на разбор более сложных задач.

LLM + системный промпт + инструменты в цикле 

Как ни странно, этого уже достаточно, чтобы собрать кодирующего агента.

Если вы хотите глубже разобраться в том, как всё это работает, полезное упражнение — попробовать создать собственного агента с нуля. Простейший цикл работы с инструментами можно реализовать всего за несколько десятков строк кода поверх существующего API LLM.

Хорошо реализованный цикл инструментов требует значительно больше усилий, но его базовые механики на удивление просты.

Другие статьи об ИИ-агентах:

Когда становится ясно, что ИИ-агент — это не магия, а набор архитектурных решений с инструментами, ограничениями и ценой ошибки, уже недостаточно просто «подключить модель». Курс «AI-архитектор» как раз про это: как спроектировать RAG, агентные сценарии, данные, инференс, проверку качества и эксплуатацию так, чтобы решение работало не в демо, а в реальной системе. Это хороший следующий шаг для тех, кто хочет не просто пользоваться ИИ-инструментами, а понимать, как их собирать и за что именно в этой архитектуре отвечать.

Чтобы узнать больше о формате обучения и познакомиться с преподавателями, приходите на бесплатные уроки:

  • 13 апреля, 20:00. «Flutter GenUI: когда ИИ-агент собирает ваш интерфейс». Записаться

  • 16 апреля, 20:00. «Архитектура ИИ-сервисов для High-Load и Low-Latency инференса». Записаться

  • 30 апреля, 20:00. «Поиск в базе знаний: где векторы ошибаются, а графы помогают». Записаться