Простая схема выглядит так: goal -> plan -> act -> observe -> decide. Сначала агент понимает цель. Затем выбирает действие: поиск по базе знаний, tool call, уточняющий вопрос, создание черновика, handoff человеку. После действия он смотрит на результат и решает, что делать дальше.
Agent loop отличает агента от обычного одноразового запроса к LLM. В обычном чате модель отвечает один раз. В агенте модель может сделать несколько шагов: найти документ, вызвать API, проверить ответ, вызвать второй tool, подготовить action candidate и отправить его на approval.
Самая важная часть agent loop - условия остановки. Агент должен понимать, когда задача выполнена, когда данных недостаточно, когда превышен лимит шагов, когда tool вернул ошибку, когда нужен человек и когда продолжать опасно. Без stop conditions агент может зациклиться, тратить деньги, повторять один и тот же запрос или выполнять лишние действия.
В code-first фреймворках вроде LangGraph loop часто описывают через state machine или graph: узлы, переходы, состояние, условия и выходы. В no-code workflow вроде n8n или Flowise цикл обычно собирается из блоков: LLM, tool, проверка, ветвление, retry, approval. В обоих случаях важно не оставлять модель полностью свободной.
Безопасный agent loop включает guardrails, action allowlist, лимиты на шаги, rate limits, таймауты, retries с ограничением, sandbox для новых tools, audit log и observability. Для действий с деньгами, договорами, персональными данными или внешними сообщениями loop должен уходить в human-in-the-loop.
Главные ошибки: не задавать лимит шагов, не проверять результат tools, позволять агенту вызывать любые действия, не хранить состояние, не логировать шаги, не различать временную ошибку и нерешаемую задачу, а также пытаться спрятать всю логику цикла в длинном промпте. Хороший loop проектируют как рабочий процесс, а не как магическую просьбу модели «действуй сам».
Примеры
- Агент поддержки получает вопрос, ищет по базе знаний, проверяет найденный фрагмент, готовит ответ и останавливается, если источник найден.
- CRM-агент анализирует сделку, видит отсутствие следующего шага, предлагает action candidate, отправляет его менеджеру и завершает loop до подтверждения.
- Агент ресерча делает web search, сохраняет источники, сравнивает факты, замечает противоречие и делает handoff человеку вместо уверенного вывода.
- В LangGraph loop может идти по узлам: classify request, retrieve context, call tool, validate result, ask approval, final response.
- Плохой loop: агент при ошибке API снова и снова вызывает один и тот же tool без лимита. Хороший loop после 2-3 попыток пишет ошибку в audit log и передает задачу человеку.
Где используется
- пошаговое выполнение задач AI-агентом
- tool calling с проверкой результата после каждого шага
- RAG-агенты, которые ищут источники и решают, достаточно ли данных
- multi-step workflow в CRM, поддержке, документах и аналитике
- state machine в LangGraph и похожих agent frameworks
- approval и human-in-the-loop внутри agent workflow
- контроль retries, timeout и rate limit
- защита от бесконечных циклов и лишних tool calls
- observability: traces, logs, стоимость и качество шагов
- тестирование агента через evals и regression scenarios
Связанные термины
Частые вопросы
Что такое agent loop простыми словами?
Это цикл работы агента: понять задачу, выбрать следующий шаг, выполнить его, посмотреть результат и решить, продолжать или остановиться. Так агент может решать задачу не одним ответом, а несколькими управляемыми шагами.
Чем agent loop отличается от обычного ответа LLM?
Обычная LLM обычно отвечает на запрос один раз. Agent loop позволяет модели делать последовательность действий: искать данные, вызывать tools, проверять результат, уточнять и передавать задачу человеку.
Почему важны stop conditions?
Без условий остановки агент может зациклиться, тратить токены и деньги, повторять ошибки или выполнять лишние действия. Stop conditions говорят: задача выполнена, данных недостаточно, лимит шагов исчерпан или нужен человек.
Какие лимиты нужны для agent loop?
Обычно задают максимум шагов, timeout, лимит tool calls, retry limit, rate limit, бюджет токенов и список действий, которые требуют approval. Для рискованных задач добавляют human-in-the-loop.
Как понять, что loop работает плохо?
Признаки: агент делает много лишних шагов, повторяет одинаковые tool calls, не умеет признать нехватку данных, часто уходит в ошибки, не логирует причины решений и дает разные результаты на похожих сценариях.
Где лучше описывать agent loop: в промпте или в коде?
Общие правила поведения можно указать в промпте, но критичную логику loop лучше держать в коде или workflow: переходы, лимиты, проверки, allowlist, retries, approval и условия завершения.
