Как работает ИИ-агент: цикл от цели до результата (Agent Loop)

Работа ИИ-агента строится не вокруг одного ответа языковой модели, а вокруг последовательности решений, действий и обратной связи. Ниже разберём весь механизм одного запуска: от постановки задачи и выбора действия до обработки ошибок, проверки прогресса и корректного завершения.

Как работает ИИ-агент по шагам: базовый цикл Agent Loop

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

Такой механизм называют циклом ИИ-агента, или Agent Loop. Его смысл не в простом повторении запросов к языковой модели, а в том, что каждое новое решение учитывает фактические последствия предыдущих действий.

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

Упрощённый алгоритм работы ИИ-агента можно представить так:

ЗАПУСК / ВХОДНАЯ ЗАДАЧА
        ↓
ЦЕЛЬ + ИНСТРУКЦИИ
        ↓
ДОСТУПНЫЕ ДЕЙСТВИЯ + АКТУАЛЬНЫЕ ДАННЫЕ
        ↓
ВЫБОР СЛЕДУЮЩЕГО ДЕЙСТВИЯ
        ↓
ИНСТРУМЕНТ / ОПЕРАЦИЯ
        ↓
РЕЗУЛЬТАТ / ОШИБКА / ОБРАТНАЯ СВЯЗЬ
        ↓
ОБНОВЛЕНИЕ ИНФОРМАЦИИ
        ↓
ПРОВЕРКА ПРОГРЕССА
        ↓
ЧТО ДЕЛАТЬ ДАЛЬШЕ?
        │
        ├── ПРОДОЛЖИТЬ → НОВАЯ ИТЕРАЦИЯ
        ├── ПОВТОРИТЬ → НОВАЯ ИТЕРАЦИЯ
        ├── ИЗМЕНИТЬ ПУТЬ → НОВАЯ ИТЕРАЦИЯ
        ├── ПЕРЕДАТЬ ЧЕЛОВЕКУ → ПАУЗА / ПРОДОЛЖЕНИЕ
        └── ЗАВЕРШИТЬ → ИТОГ

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

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

Так ИИ-агент работает с меняющимися данными, а не с одной статичной последовательностью команд. Более широкий архитектурный контекст разобран в материале «Общая архитектура ИИ-агента» .

Цель и инструкции (Goal и Instructions): с чего начинается работа агента

Цель определяет, какого результата должен добиться ИИ-агент, а инструкции задают правила и границы его работы. Цель отвечает на вопрос «чего достичь?», инструкции — «как и в каких пределах разрешено действовать?».

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

Однако одного общего намерения мало. Агенту нужны критерии успеха — признаки, по которым можно проверить завершение работы. Например: исходный тест проходит, связанные проверки тоже успешны, публичный API не изменён, заданные ограничения соблюдены.

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

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

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

Разрешённые действия (Available Actions): что ИИ-агент может сделать

Набор инструментов и других разрешённых возможностей определяет, какие действия ИИ-агент может выполнять в конкретной системе.

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

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

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

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

Как технически устроены Function Calling, обращения к API и взаимодействие с интерфейсами, подробнее разбирается в статье «Инструменты ИИ-агента: Function Calling и Computer Use» .

Текущее состояние (Current State): какие данные агент учитывает перед новым решением

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

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

Вернёмся к примеру с тестированием. Сначала ИИ-агент видит сообщение об ошибке. Открыв связанный файл, он получает новые данные о функции, которая могла вызвать сбой. Внеся изменение и запустив тест, агент узнаёт, помогла ли правка. Если обнаруживается новая проблема, она тоже должна учитываться при дальнейшем анализе.

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

При этом текущее состояние и память — не одно и то же. Здесь речь идёт об информации, необходимой для выполнения конкретной задачи. Долговременное хранение сведений, работа между сессиями и виды памяти относятся к другому архитектурному слою. Подробнее: «Context, State и Memory ИИ-агента» .

Как ИИ-агент выбирает следующее действие

ИИ-агент принимает решение на основе текущих данных, цели, инструкций и доступных действий. Если новая информация меняет ситуацию, агент может скорректировать свои действия вместо продолжения прежнего пути.

Например, при анализе проблемы в коде агент может понять, что информации недостаточно, и открыть ещё один файл. Если причина уже найдена, логичнее перейти к исправлению. Когда правка внесена, нужно проверить её. Если предполагаемое действие требует особых прав, вместо самостоятельного выполнения агент может запросить участие человека.

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

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

Всегда ли ИИ-агент сначала строит план?

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

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

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

Вызов инструмента (Tool Call): модель выбирает действие, программа его исполняет

Вызов инструмента (Tool Call) — это запрос на выполнение разрешённого действия. Языковая модель может выбрать подходящий инструмент и сформировать параметры, но фактическое изменение файла, запрос к API или другую внешнюю работу обычно выполняет среда выполнения (runtime).

Выражение «агент вызвал API» поэтому скрывает несколько отдельных стадий:

ЯЗЫКОВАЯ МОДЕЛЬ
↓
ВЫБИРАЕТ ДЕЙСТВИЕ
↓
УКАЗЫВАЕТ ИНСТРУМЕНТ И ПАРАМЕТРЫ
↓
СРЕДА ВЫПОЛНЕНИЯ
↓
ИСПОЛНЯЕТ ДЕЙСТВИЕ
↓
ПОЛУЧАЕТ ФАКТИЧЕСКИЙ ОТВЕТ
↓
ВОЗВРАЩАЕТ ДАННЫЕ АГЕНТУ

Например, модель определяет, что нужно найти функцию в репозитории или запросить определённую запись из CRM. Само чтение диска, отправку сетевого запроса или изменение объекта выполняет другой компонент программы.

Модель отвечает за смысловой выбор и последующую интерпретацию данных. Среда выполнения проверяет доступные права, исполняет вызов, фиксирует технический статус и передаёт полученную информацию обратно агенту.

Сформированный Tool Call ещё не означает, что внешнее действие действительно выполнено. Это различие особенно важно при тайм-аутах и повторных запросах: агенту необходимо установить, что произошло на самом деле, прежде чем принимать новое решение.

Результат действия (Observation): какую обратную связь получает ИИ-агент

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

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

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

Обратной связью поэтому может быть ответ API, найденная информация, статус операции, падение теста, тайм-аут, отсутствие сведений или сообщение пользователя. Агент анализирует эти данные и использует их при новом выборе.

Без такой обратной связи агент не смог бы надёжно адаптироваться к изменениям: каждое новое действие опиралось бы на предположение, а не на фактические данные.

Обновление состояния и проверка прогресса: что изменилось после действия

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

Например, агент открыл файл и нашёл использование устаревшего API. До проверки ему был известен только текст ошибки; теперь появилась вероятная причина. На новой итерации нет смысла действовать так, будто файл ещё не анализировали.

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

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

Обновление состояния — не обучение модели

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

В обычном Agent Loop меняется информация, доступная в рамках текущего выполнения задачи. Веса модели при этом не обязаны меняться. Машинное обучение, fine-tuning и другие способы изменения самой модели — отдельные процессы и не являются необходимой частью каждой итерации.

Что происходит при ошибке: повторить действие или скорректировать подход

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

Например, инструмент может вернуть тайм-аут, API — отказать в доступе, файл — отсутствовать, а поиск — не найти нужных сведений. Эти ситуации нельзя обрабатывать одинаково. Временный сетевой сбой и отсутствие разрешения требуют разных действий.

Повторная попытка (Retry) или альтернативный путь (Alternative Path)

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

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

ПОВТОРНАЯ ПОПЫТКА

ЗАПРОС К API
↓
ВРЕМЕННЫЙ СБОЙ
↓
ПОВТОР ЗАПРОСА


АЛЬТЕРНАТИВНЫЙ ПУТЬ

ИСТОЧНИК A
↓
НУЖНЫХ ДАННЫХ НЕТ
↓
ПРОВЕРКА ИСТОЧНИКА B

Retry повторяет действие после потенциально временной проблемы. Alternative Path меняет способ решения, когда прежний подход больше не помогает.

Почему некоторые действия нельзя повторять вслепую

Особенно осторожно нужно обращаться с вызовами, которые изменяют внешние системы. Например, ИИ-агент отправляет письмо и получает тайм-аут. Такой статус ещё не доказывает, что письмо не ушло: сервис мог принять команду, а подтверждение потерялось.

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

Когда ИИ-агент должен остановиться

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

Поэтому утверждение «агент сам решает, когда остановиться» слишком упрощает архитектуру. Часть условий оценивает модель, часть контролирует программа, а некоторые ограничения определяются внешними правилами.

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

Подробнее о границах самостоятельности: «Автономность ИИ-агента и Human-in-the-Loop» .

Сквозной пример: как ИИ-агент исправляет падающий тест

Возьмём один запуск целиком и посмотрим, как решение ИИ-агента меняется в зависимости от новых данных.

Разработчик ставит задачу: в проекте падает автоматический тест. Нужно устранить причину и добиться успешной проверки. Одновременно задаются ограничения: сам тест удалять нельзя, публичный API менять нельзя, а исправление должно пройти связанные тесты.

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

Агент изменяет реализацию и запускает исходный тест. Проверка проходит успешно. Однако критерии успеха ещё не выполнены полностью: необходимо проверить связанные тесты. Поэтому ИИ-агент продолжает работу и запускает дополнительное тестирование.

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

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

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

Agent Loop и ReAct: почему это не одно и то же

ReAct — известный паттерн, который популяризировал чередование рассуждения и действия. Agent Loop — более широкое понятие: современный ИИ-агент не обязан публично работать по схеме Thought → Action → Observation.

ReAct

РАССУЖДЕНИЕ
↓
ДЕЙСТВИЕ
↓
НАБЛЮДЕНИЕ


Agent Loop

АКТУАЛЬНЫЕ ДАННЫЕ
↓
ВЫБОР ДЕЙСТВИЯ
↓
ДЕЙСТВИЕ
↓
ОБРАТНАЯ СВЯЗЬ
↓
УЧЁТ НОВОЙ ИНФОРМАЦИИ
↓
НОВОЕ РЕШЕНИЕ

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

Внутренний механизм принятия решений может быть устроен по-разному. Отдельный текстовый Thought не обязан быть доступен приложению или пользователю, поэтому превращать Thought → Action → Observation в универсальное описание всех современных ИИ-агентов некорректно.

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

Почему работа ИИ-агента может сломаться

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

Бесконечное повторение и одинаковые вызовы

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

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

Слишком раннее и слишком позднее завершение

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

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

Уход от исходной задачи и неспособность изменить подход

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

Другой риск — неспособность отказаться от способа, который перестал работать.

Устаревшие или противоречивые данные

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

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

Что делает работу ИИ-агента управляемой

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

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

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

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

Как работает ИИ-агент: короткая формула

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

Это и есть базовая логика Agent Loop.

FAQ

Главный вывод

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

Главная особенность Agent Loop в том, что новое решение принимается на основе информации, которая появилась уже во время выполнения задачи. Если данных недостаточно, агент может продолжить поиск. Если возник временный сбой — ограниченно повторить запрос. Если прежний способ перестал помогать — адаптироваться и выбрать иной вариант. Когда критерии успеха выполнены, работа завершается.

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