В последние годы вокруг больших языковых моделей сформировалась отдельная инженерная дисциплина — проектирование агентных систем. Если о внутреннем устройстве трансформеров написано уже немало, то прикладная сторона работы LLM остаётся менее освещённой. Именно ей и посвящён разбор, описывающий, как языковая модель превращается из генератора текста в исполнителя задач, способного вызывать внешние функции, получать результаты и корректировать своё поведение. Речь идёт не о новой архитектуре нейросети, а о способе организации взаимодействия с уже существующими моделями. Этот сдвиг важен концептуально: агент — это не отдельная модель и не новый тип нейросети, а набор инженерных решений, надстраиваемых поверх обычного инференса. Соответственно, и обсуждать здесь стоит не математику внимания, а протоколы, форматы и стратегии управления состоянием.

Отправная точка работы любой LLM — контекст, то есть блок текста, подаваемый на вход. Модель не хранит состояние между запросами: каждый раз она получает весь необходимый материал заново и генерирует его продолжение, завершая фрагмент специальным токеном остановки. Ограничение на размер контекста долгое время было одним из главных технических барьеров: если на раннем этапе прорывом считались 32 тысячи токенов, то сегодня индустриальным стандартом становится миллион. После генерации нового фрагмента его можно дописать к контексту и повторить цикл — так формируется базовая механика пошаговой работы агента. Из этого простого факта вытекает почти вся дальнейшая архитектура: раз модель не помнит ничего между вызовами, вся «память» агента — это то, что в данный момент лежит в контексте, и именно поэтому управление контекстом превращается в центральную инженерную задачу.

Чтобы модель могла обращаться к внешним функциям, её обучают специальному форматированию вызовов, которое различается у разных поставщиков. Сами инструменты требуется предварительно задекларировать — обычно в начале контекста, в так называемом системном промпте. Формально эта часть ничем не отличается от остального текста, кроме специального токена-разделителя, содержимое до которого модель обучена не раскрывать. Для описания инструментов используется стандарт JSON Schema: по сути это документация на естественном языке, где указываются имя функции, её назначение, входные параметры и примеры значений. Имея такие описания, модель генерирует структурированный вызов с именем функции и уже разобранными аргументами. Показательно, что качество описания инструмента напрямую влияет на качество его вызова: чем точнее сформулировано назначение функции и описаны параметры, тем реже модель ошибается с выбором инструмента и аргументов. По сути, промпт-инжиниринг здесь превращается в документирование API для нечеловеческого читателя.

Набор доступных модели инструментов сегодня принято называть harness, а для подключения внешних систем существует индустриальный стандарт MCP (Model Context Protocol). Фактически он описывает межпроцессное взаимодействие между агентом и сторонними сервисами, причём обмен в обоих случаях идёт по JSON-RPC 2.0. Различается лишь транспорт: для локального процесса-сервера это стандартные потоки ввода-вывода, для внешних систем — HTTP. API провайдеров при этом возвращает не сырой текст, а типизированные JSON-объекты, и единого официального стандарта здесь пока нет. Наиболее распространён формат OpenAI Tools API, который воспроизводят опенсорсные движки вроде Ollama и vLLM; у Anthropic собственная схема, где вызов приходит отдельным блоком с идентификатором, именем и уже разобранным объектом аргументов, а признаком незавершённого хода служит поле stop_reason со значением tool_use. Разница между подходами не только синтаксическая: в формате OpenAI аргументы приходят строкой, которую нужно парсить самостоятельно, тогда как Anthropic отдаёт уже готовый объект. Для разработчика это означает разный объём кода-обвязки и разную устойчивость к ошибкам парсинга.

Отдельного внимания заслуживает механизм обработки ошибок, который замыкает обратную связь в агентском цикле. Результат выполнения инструмента возвращается новым сообщением с ролью пользователя и блоком tool_result, ссылающимся на идентификатор вызова. Если инструмент упал — команда вернула ненулевой код, файл не нашёлся, тест не прошёл — устанавливается флаг is_error, а в содержимое помещается текст ошибки. С точки зрения цикла ничего экстраординарного не происходит: ошибка является таким же результатом, как и успешное выполнение, и агент просто делает следующий ход, уже зная, что, например, забыт импорт модуля. Раньше модель писала код вслепую, теперь она видит последствия своих действий и может исправить их на следующей итерации. Именно этот механизм отличает агента от простого генератора: наличие петли обратной связи превращает разовую генерацию в итеративный процесс, где каждая ошибка становится входными данными для следующего шага.

Управление контекстом остаётся одной из главных практических проблем при построении агентов. Здесь важно различать два лимита: формальный, указанный в спецификации модели, при превышении которого API вернёт ошибку, и рабочий, на котором модель ещё сохраняет качество. Второй заметно меньше первого, поскольку на длинном контексте внимание распределяется неравномерно: начало и конец остаются в фокусе, а середина начинает выпадать. Для борьбы с этим применяют вытеснение объёмных выводов инструментов во временные файлы с передачей в контекст лишь пути и небольшого фрагмента, а также компактификацию — сжатие накопленной истории. Эти приёмы позволяют удерживать рабочий объём в допустимых пределах без потери ключевой информации. На практике именно стратегия работы с контекстом, а не выбор конкретной модели, часто определяет, насколько долго и стабильно агент способен работать над задачей.

Значение описанной архитектуры для рынка выходит за рамки отдельного продукта: фактически формируется слой инфраструктуры, стандартизирующий взаимодействие моделей с внешним миром. Появление MCP и унификация форматов вызова инструментов снижают зависимость разработчиков от конкретного поставщика модели и упрощают перенос агентов между платформами. Для российского рынка ИИ это означает, что ставка на собственные модели сама по себе не решает задачу: ценность всё больше смещается к агентной обвязке, инструментам и инфраструктуре, которые можно строить поверх моделей разных вендоров. Открытыми остаются вопросы надёжности таких систем, стоимости длинных контекстов и безопасности вызовов внешних функций — особенно когда агент получает доступ к реальным сервисам и командам. Тем не менее именно агентский цикл с обратной связью превращает языковую модель из генератора текста в инструмент решения практических задач, и дальнейшее развитие этой области будет определяться балансом между автономностью агентов и контролем со стороны человека.