Вы когда-нибудь запускали AI-агента в корпоративном контуре и с ужасом наблюдали, как он делает один звонок к API, радостно сообщает «Задача выполнена!», хотя на самом деле ничего не сделал? Или хуже — агент выполняет действие, получает ошибку, но не пытается её исправить, а просто выдаёт отговорку. Знакомо?
Проблема в том, что большинство современных AI-агентов построены вокруг концепции single tool call — «вызвал инструмент, получил ответ, на этом всё». В мире Hello World это работает. В корпоративном мире с его многошаговыми BPM-процессами, десятками подсистем и проклятием долгоживущих транзакций — это путь к катастрофе.
Решение, которое мы обкатываем в продакшене последние полгода, называется Agent Loop. Это не просто ReAct (хоть он и лёг в основу). Это инженерный подход, который превращает одноразового болванчика в настоящего корпоративного сотрудника, способного делать паузу, перепроверять, перепланировать и возвращаться с докладом.
💡 Если вы ещё не читали статью про ReAct и Advanced RAG — самое время. Agent Loop надстраивается поверх этой архитектуры.
Почему single tool call — это яд для корпоративных агентов
Давайте честно: LLM не умеют «думать» в том смысле, который мы вкладываем в это слово. Они предсказывают следующий токен. Поэтому, когда вы даёте агенту задачу «Найди в ERP заказ №12345, проверь статус оплаты, если оплачен — отправь уведомление клиенту, если нет — создай задачу в CRM на повторную отправку счёта», вы просите модель совершить логический прыжок через пропасть.
Single tool call — это прыжок с закрытыми глазами. Агент пытается угадать, какой инструмент вызвать первым, и часто ошибается. Вот типичные симптомы:
- Галлюцинации контекста — агент «вспоминает» несуществующие поля или статусы, потому что не проверил реальные данные.
- Потеря состояния — между вызовами инструмента агент забывает, что уже сделал, и начинает заново.
- Нулевая отказоустойчивость — если внешняя система вернула ошибку или timeout, агент не знает, что делать, и падает.
- Отсутствие итеративности — корпоративная задача редко завершается за один шаг. Нужно проверить результат предыдущего действия, прежде чем двигаться дальше.
⚠️ Самый опасный кейс: агент, который в production делает один вызов, получает ошибку «недостаточно прав», и вместо того чтобы запросить refresh токена, сообщает пользователю «Задача выполнена». Мы видели такое в трёх разных компаниях. Не делайте так.
В статье «AI-агенты как сотрудники» я сравнивал агентов с джуниорами. Single tool call — это джун, который после первой же ошибки бросает задачу и уходит пить кофе. Нам нужен senior, который умеет решать проблемы итеративно.
Agent Loop: что внутри
Agent Loop — это не библиотека и не фреймворк. Это паттерн проектирования, в котором агент работает в цикле: Планирование → Выполнение → Оценка → Коррекция плана → ... → Финал. Каждый шаг цикла имеет собственную ответственность и может быть реализован на базе разных моделей или обычной логики.
| Компонент | Что делает | Типичная реализация |
|---|---|---|
| Planner | Формирует последовательность действий на основе задачи и доступных инструментов | LLM (GPT-4o, Claude 3.5 Sonnet) + structured output (JSON) |
| Executor | Запускает один шаг плана, вызывает инструменты, собирает результат | Функции-адаптеры, MCP-серверы, REST-клиенты |
| Evaluator | Проверяет, успешно ли выполнен шаг, не противоречит ли результат ожиданиям | LLM-валидатор или rule-based проверка (например, статус 200, наличие полей) |
| Memory | Сохраняет историю шагов, ошибок, выводов для планирования следующих итераций | Список сообщений с ролями, векторная БД (например, ChromaDB) для долгосрочного контекста |
| Orchestrator | Управляет циклом: решает, когда остановиться, когда перепланировать, когда эскалировать человеку | Счётчик шагов, лимит токенов, тайм-аут, callback на человеческое решение |
Ключевое отличие от классического ReAct: Evaluator. Без него агент просто генерирует следующее действие, даже если предыдущее провалилось. Evaluator заставляет агента посмотреть на результат со стороны и решить: «Сделано хорошо? Продолжаем. Сделано плохо? Надо переделать или уточнить план». Это и есть та самая «рефлексия», о которой все говорят, но мало кто внедряет.
Пошаговый план: как собрать Agent Loop без кода (ну, почти)
Сразу предупреждаю: я не дам готовый Python-скрипт. Давать код под абстрактный кейс — значит обманывать читателя. Вместо этого опишу рецепт, который вы сможете адаптировать под свою инфраструктуру. Если вам нужен production-ready код — почитайте статью «Production-ready AI-агенты», там есть примеры на FastAPI.
1 Копай глубже: декомпозируй задачу
Прежде чем запускать Agent Loop, вы должны понять, из каких шагов вообще состоит бизнес-процесс. Не пытайтесь засунуть всё в один промпт. Возьмите лист бумаги (серьёзно) и распишите: какие данные нужны на входе, какие решения принимаются, какие системы участвуют. Это будет ваш «золотой сценарий».
Пример для задачи «Обработать заказ клиента»:
- Шаг 1: Проверить наличие товара на складе (API ERP).
- Шаг 2: Если есть — зарезервировать; если нет — найти альтернативу или предложить ожидание.
- Шаг 3: Рассчитать стоимость доставки (API TMS).
- Шаг 4: Отправить подтверждение клиенту (email/SMS).
- Шаг 5: Создать запись в CRM.
Каждый шаг — это потенциальный вызов инструмента. Но заметьте: шаг 2 ветвится. Single tool call здесь не сработает.
2 Планирование: пусть LLM напишет план, а не код
Здесь используем structured output. Вы даёте LLM описание всех доступных инструментов (в формате OpenAPI, MCP или JSON Schema) и просите вернуть JSON-план. Пример промпта:
{
"plan": [
{"step": 1, "tool": "check_stock", "params": {"product_id": "A123"}},
{"step": 2, "tool": "reserve_item", "params": {"order_id": "O789"}},
{"step": 3, "tool": "calculate_shipping", "params": {"destination": "NYC"}}
]
}Планировщик может работать на более дешёвой модели, потому что точность здесь не критична — ошибки исправит цикл. Используйте GPT-4o-mini или Llama 3 70B, если держите локально.
3 Выполнение с гарниром из проверок
Executor запускает шаги последовательно. После каждого вызова собирается результат. Если результат — ошибка, он передаётся Evaluator, который решает: повторить с другими параметрами, пропустить шаг, запросить уточнение у пользователя или перепланировать.
Важное правило: никогда не доверяй LLM, что вызов прошёл успешно. Всегда проверяй фактический ответ от API. Для этого можно использовать небольшой rule-based валидатор (проверка HTTP статуса, наличие обязательных полей, формат даты). LLM-валидатор подключайте только для семантических проверок (например, «содержимое ответа соответствует запросу»).
4 Оценка и коррекция: где спрятана надежность
Здесь ключевой момент: после выполнения всех шагов нужно оценить весь результат целиком. Не каждый шаг по отдельности, а конечный итог. LLM смотрит на собранные данные и отвечает на вопрос: «Достигнута ли цель пользователя?». Если нет — цикл повторяется с новым планированием, но уже с учётом накопленного опыта (Memory).
Без этого шага вы получите просто ReAct, который может бесконечно повторять одни и те же ошибки. Я называю это «эффектом заезженной пластинки». Agent Loop с Evaluator ломает этот паттерн.
🚫 Типичная ошибка: ставить Evaluator на каждое действие, но не ставить его на финальный результат. Вы получаете идеально выполненные шаги, которые вместе не решают задачу. Проверяйте конец-то-конец.
Как НЕ надо: грабли, которые мы собирали
Мы внедряли Agent Loop в трёх крупных проектах (логистика, финтех, HR). Каждый раз наступали на одни и те же грабли. Вот список того, что я бы сделал иначе, зная финал:
- Бесконечный цикл. Без лимита шагов и тайм-аута агент может перепланировать 50 раз. Обязательно ставьте максимум (обычно 5-10 итераций) и callback человеку.
- Перепланирование без причины. Если Evaluator постоянно просит переделать план, значит у вас кривые промпты или инструменты. Не пытайтесь лечить это увеличением лимита шагов.
- Забыли про память. Без сохранения контекста между шагами агент будет каждый раз «забывать», что уже проверил склад, и проверять снова. Используйте stateful контекст (Redis, PostgreSQL).
- Одна модель на всё. Планировщик, исполнитель и оценщик могут быть разными. Исполнитель вообще может быть rule-based. Не перегружайте одну LLM.
- Стоимость. Каждый шаг цикла — это вызов LLM. Если ваш процесс из 10 шагов делает в среднем 3 итерации, то это 30 вызовов. Для высоконагруженных систем считайте бюджет заранее.
Когда нужен Agent Loop, а когда хватит старого доброго workflow
Честно: не каждая задача требует цикла с итеративным планированием. Если у вас простой RAG на 10 документов и вопрос «какая столица Франции?» — Agent Loop только замедлит ответ. Но если бизнес-процесс включает ветвления, внешние API, долгие транзакции — цикл становится необходимостью.
| Тип задачи | Подход | Пример |
|---|---|---|
| Однократный запрос-ответ | Single call или Simple Chain | Ответить на вопрос по документации |
| Многошаговый с фиксированной последовательностью | Workflow (DAG) | Обработка заказа с фиксированными шагами |
| Многошаговый с ветвлением и ошибками | Agent Loop | Автоматическое урегулирование страхового случая |
| Долгоживущий процесс с человеческим контролем | Agent Loop + Human-in-the-loop | Согласование договора с юристом |
Кстати, на рынке уже появляются инструменты, которые упрощают создание Agent Loop. Например, LangSmith Agent Builder позволяет собирать динамических агентов без кода — и там как раз реализован цикл с памятью и перепланированием. Правда, для глубокой кастомизации всё равно придётся писать код.
Неочевидный совет под конец
Самое ценное, что мы вынесли из опыта с Agent Loop — не пытайтесь сделать агента полностью автономным. В корпоративной среде всегда есть ситуации, когда решение должен принять человек. Закладывайте в цикл точку эскалации с самого начала. Пусть агент делает 95% работы, но на 5% он честно говорит: «Я не могу однозначно решить, нужна помощь оператора». Это спасёт вас от имитации бурной деятельности, за которую никто не хочет отвечать.
И ещё: через год-два Agent Loop станет стандартным шаблоном в любом AI-фреймворке. Точно так же, как сегодня ReAct считается базой. Но те, кто освоит его сейчас, получат преимущество перед конкурентами. Потому что строить надёжных корпоративных агентов — это не про хайп, а про инженерную культуру.
