Агентный цикл: как устроен loop perceive-plan-act-reflect

Осенью 2024 года почти каждый крупный игрок рынка выкатил свою обёртку для «агентов»: OpenAI показала Operator, Anthropic — Computer Use для Claude, Google встроила агентные сценарии в Gemini. За маркетинговым словом «агент» стоит вполне конкретная инженерная конструкция — цикл из четырёх шагов, который модель проходит раз за разом, пока не выполнит задачу или не упрётся в лимит. Его называют agentic loop, и по-английски четыре стадии звучат как perceive — plan — act — reflect. Понимание этого цикла отделяет тех, кто строит рабочие агенты, от тех, кто удивляется, почему бот зациклился и сжёг токенов на пару долларов за один запрос.

Что такое agentic loop и чем он отличается от чат-бота

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

Один оборот петли выглядит так: модель смотрит на текущее состояние мира, решает, что делать дальше, делает это через инструмент, а затем оценивает результат и решает, крутиться дальше или остановиться. Четыре стадии — не жёсткий стандарт из спецификации, а удобная рамка, которую используют разработчики фреймворков вроде LangGraph, AutoGPT и CrewAI. Названия шагов у всех немного разные, но логика одна.

Perceive: собрать контекст

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

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

Plan: решить, что делать дальше

Модель на основе воспринятого состояния выбирает следующее действие. Здесь используются два основных приёма. Первый — ReAct (reasoning + acting): модель вслух рассуждает о том, что нужно сделать, и лишь затем выбирает инструмент. Второй — планирование наперёд, когда агент сначала строит список подзадач, а потом идёт по нему.

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

Act: выполнить действие через инструмент

Планы без действий бесполезны, поэтому агенту дают инструменты (tools): вызовы функций, обращения к API, поиск, запуск кода, клики по интерфейсу. Модель возвращает структурированный вызов — имя инструмента и аргументы, — а окружение (runtime) его исполняет и возвращает результат. Именно здесь агент выходит за пределы текста и трогает реальный мир: отправляет письмо, делает запрос к базе, оформляет заказ.

Reflect: оценить и решить, продолжать ли

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

Где цикл ломается на практике

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

• Зацикливание. Агент повторяет одно и то же действие, ожидая другого результата. Лечится жёстким лимитом на число итераций и детекцией повторов.
• Переполнение контекста. История разрастается быстрее, чем полезная информация. Отсюда — сжатие и внешняя память.
• Накопление ошибок. Модель неверно поняла результат одного шага и строит на этом все следующие. Один сбой на восприятии отравляет весь дальнейший цикл.
• Стоимость. Каждый оборот — это отдельный вызов модели, и он оплачивается по токенам. Задача, которую человек решает в три клика, у агента может занять двадцать оборотов.
• Небезопасные действия. Инструмент, который умеет тратить деньги или удалять данные, требует подтверждения человеком (human in the loop), иначе цена ошибки становится реальной.

Как это реализовано в популярных подходах

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

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

Кому это пригодится и кому нет

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

Пригодится, если:

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

Не пригодится, если:

• задача решается одним вызовом модели — тогда agentic loop только добавит стоимость и точки отказа;
• шаги фиксированы и известны заранее — обычный конвейер (pipeline) без петли надёжнее и дешевле;
• цена ошибки высока, а надзор человека невозможен — автономный агент с доступом к деньгам или удалению данных без подтверждения слишком рискован.

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

** Контекстное окно — максимальный объём текста в токенах, который модель может держать «в голове» за один вызов. За его пределами информация теряется.

*** RAG (retrieval-augmented generation) — приём, при котором модель перед ответом подтягивает нужные фрагменты из внешнего хранилища, а не полагается только на то, что уместилось в контекст.