Любой современный AI-агент — это не принципиально новая форма искусственного интеллекта, а инженерная надстройка над стандартной языковой моделью. Сама по себе LLM способна решать лишь одну задачу: вычислять вероятности и дописывать следующий токен на основе контекста. Чтобы превратить пассивный текстовый генератор в автономного помощника, способного отлаживать код и администрировать сервисы, разработчикам приходится выстраивать многослойную инфраструктуру.
Фундамент: почему чистая LLM не способна действовать
Базовая языковая модель ограничена тремя фундаментальными барьерами:
- Срез знаний: модель осведомлена лишь о том, что вошло в обучающую выборку на момент тренировки.
- Иллюзия компетентности: нейросеть не обладает самосознанием о границах собственной осведомленности. При нехватке данных она генерирует правдоподобные выдумки с той же степенью уверенности, что и точные факты.
- Отсутствие исполнительных механизмов: модель выдает исключительно последовательности символов и не имеет прямого доступа к файловой системе или сети.
Попытка решить эти проблемы «в лоб» — загрузкой всей кодовой базы или корпоративной документации прямо в промпт — упирается в архитектуру видеокарт. Контекстное окно требует колоссальных аппаратных ресурсов: потребление памяти растет линейно, а вычислительная сложность механизма внимания при обработке токенов масштабируется квадратично. Единственный выход — научить модель привлекать инструменты точечно.
Tool Calling: превращение текста в команды
Для взаимодействия с внешними API используется концепция tool calling (вызов инструментов). Модель не выполняет код самостоятельно. Вместо этого в системный контекст передаются описания доступных функций в виде строгих JSON-схем.
{
"name": "get_weather",
"description": "Возвращает текущую погоду в указанном городе",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "Название города на русском языке, например Москва"
}
},
"required": ["city"]
}
}Вместо произвольного текста нейросеть возвращает структурированный JSON с аргументами, руководствуясь текстовым описанием поля description. Механизм выбора инструмента остается тем же предсказанием наиболее вероятного токена. Если описание функции составлено небрежно или пересекается с другими, модель закономерно начнет вызывать неподходящие команды.
Agent Loop: цикл обратной связи
Решение комплексной проблемы (например, исправление упавших автотестов) требует последовательных шагов, где каждое следующее действие опирается на результат предыдущего. Здесь в дело вступает agent loop — цикл управления, который в простейшем виде реализуется через обычный цикл while.
Жизненный цикл сессии строится на обмене сообщениями с четырьмя базовыми ролями:
- System: глобальные директивы, правила безопасности и список инструментов.
- User: формулировка задачи от человека.
- Assistant: ответ модели (текст либо запрос вызова инструмента с идентификатором
call_id). - Tool: реальный результат выполнения скрипта или запроса к API, возвращенный во внешний контекст.
С каждым витком цикла история накапливается и повторно передается модели. Это создает иллюзию оперативного обучения: агент шаг за шагом углубляет понимание проекта. Однако веса модели остаются неизменными, а контекстное окно стремительно заполняется служебными выводами.
RAG и MCP: стандартизация внешних данных
Чтобы предоставить агенту актуальные факты о закрытых репозиториях или тикетах в трекерах, используется агентский RAG. Модель сама решает, когда вызвать поиск по документам или выполнить поиск по файлам проекта, получая результат в роли Tool.
Для исключения дублирования интеграций индустрия пришла к стандарту Model Context Protocol (MCP). Это единый открытый протокол клиент-серверного взаимодействия: сторонний сервис запускает MCP-сервер, а среда выполнения агента подключает его инструменты без модификации движка. Однако у архитектуры есть оборотная сторона — все схемы подключенных серверов обязаны постоянно присутствовать в системном промпте. Подключение нескольких тяжелых MCP-серверов способно отнять десятки тысяч токенов еще до ввода первой пользовательской команды.
Skills: динамическая экономия контекста
Механизм навыков (Skills) оптимизирует работу с памятью. Вместо хранения длинных пошаговых сценариев в контексте агент получает только краткое оглавление. Развернутая markdown-инструкция подгружается исключительно в момент, когда модель распознает соответствие задачи определенному сценарию.
Скиллы жестко фиксируют бизнес-логику: какие шаги пройти, какие скрипты запустить в терминале и в каком формате выдать ответ. Это снижает вероятность того, что агент склеит разнородные задачи или пропустит критические проверки.
Архитектурные уязвимости и роль оператора
Любая агентная схема объединяет ненадежные компоненты: галлюцинирующую языковую модель, внешние API с сетевыми сбоями и терминал ОС. Ошибки этих уровней не нейтрализуют друг друга, а аккумулируются.
Важно: Современные LLM принципиально не способны надежно отличать инструкции пользователя от входящих данных. Текст из задачи в трекере или скачанной веб-страницы может содержать непрямую промпт-инъекцию (indirect prompt injection), переопределяющую поведение агента.
Безопасная эксплуатация агентов требует соблюдения жестких правил:
- Грануляция прав: операции чтения выполняются автоматически, но любые деструктивные действия (модификация файлов, запросы с внешними эффектами, выполнение шелл-команд) требуют обязательного подтверждения человеком.
- Изоляция: агенту нельзя одновременно предоставлять доступ к конфиденциальным секретам окружения и к внешним каналам связи.
- Обязательный аудит: код и конфигурации перед запуском агента должны быть зафиксированы в системе контроля версий (Git), а итоговый результат детерминированно верифицирован человеком.