Есть сцена, которая в рассказах про «прорывных ИИ-агентов» выглядит совсем невыразительно. Конвейер собирает материал, а на последнем шаге сервис отдаёт ошибку. Обычный workflow делает ровно то, что в него заложили: ждёт десять секунд, повторяет тот же запрос и после третьей неудачи помечает задачу как проваленную.
На этом месте расходятся два подхода, и разница между ними измеряется не тем, насколько складно модель пишет текст. Вопрос в том, кто выбирает следующий шаг — заранее написанный код или система, которая сначала оценивает состояние, а уже потом решает, что делать дальше.
Маршрут выбирает код или модель
Команда Anthropic в инженерном разборе разводит два подхода почти по этому же признаку: в workflow модель и инструменты идут по заранее определённым программным маршрутам, а в агенте модель сама управляет процессом и решает, когда и какой инструмент использовать. В руководстве OpenAI такой сценарий к агентам не относят: приложение, где языковая модель вызывается внутри жёсткого сценария, агентным не считается, даже если модель отвечает буквально на каждом шаге. Агентными признаками там названы управление ходом задачи, определение момента завершения, исправление действий после неудачи и динамический выбор инструментов с учётом текущего состояния.
Общепринятого определения термина при этом нет — Anthropic прямо замечает, что «агентом» называют и полностью автономные системы, и довольно жёсткие конвейеры. Поэтому дальше критерий у нас будет один, и он архитектурный: смотреть не на число моделей и не на громкость названий, а на то, кто принимает решение о следующем действии.
Retry, который не превращает систему в агента
Повтор после ошибки — не новость и не признак интеллекта. В документации AWS этот механизм описан давно и скучно: заранее указываются типы ошибок, которые имеет смысл повторять, максимальное число попыток и интервалы с exponential backoff и jitter, а после исчерпания попыток сценарий просто завершается ошибкой. Там же сказано, что повторы нужно ограничивать: бесконечные попытки повышают нагрузку и создают очередь задач, которые всё равно не решатся.
Для действий с внешними последствиями добавляется ещё одно требование — идемпотентность. Повтор не должен случайно создать второй заказ, второй платёж или вторую публикацию. Это инженерная гигиена, и к агентности она отношения не имеет.
Простой retry остаётся workflow, потому что решение после ошибки известно заранее: подождать, повторить, сдаться. Никакой оценки состояния тут нет — есть только счётчик попыток и таймер.
Что меняется, если система сначала диагностирует
Другая картина начинается тогда, когда после сбоя выполняется оценка состояния, а маршрут выбирается по её результату. В общем виде это выглядит примерно так:
- сервис временно недоступен — подождать и повторить;
- превышен лимит запросов — отложить задачу или перейти на другой доступный сервис;
- ответ не соответствует ожидаемой схеме — запросить исправление формата;
- не хватает источников — вернуть задачу на этап исследования;
- текст не прошёл редакционную проверку — отправить на доработку;
- причина непонятна или действие рискованно — остановиться и позвать человека.
Важная оговорка: конструкция вида «если ошибка 429 — подождать» сама по себе остаётся программным workflow, даже если веток в ней много. Агентность появляется там, где состояние интерпретирует модель и выбирает действие, не сведённое к одному заранее прописанному переходу. И отдельно стоит развести диагностику и исправление: система может распознать тип ошибки и при этом не иметь ни полномочий, ни инструмента, чтобы её устранить.
Когда я даю ИИ право самому продолжать работу после ошибки, речь ровно про такую проверку состояния, а не про то, что модель «поняла» сбой и «не сдалась». Такие формулировки годятся только как метафора: технически система классифицирует состояние и выбирает разрешённое действие. В проектируемой схеме для конвейера Auto-Dzen после неудачи сначала определяется состояние задачи, и только потом выбирается следующий шаг. Это пока проект конструкции, а не список уже работающих функций, и путать одно с другим я не собираюсь.
Цепочка агентов — всё ещё workflow
Google Cloud описывает последовательный multi-agent шаблон: специализированные исполнители идут друг за другом в фиксированном линейном порядке, а оркестрация в таком шаблоне не обязана обращаться к модели. Такой конвейер остаётся детерминированным, даже если каждый его узел назван агентом. Динамическая оркестрация начинается там, где система планирует, делегирует и координирует задачи без заранее зафиксированного маршрута.
Разница хорошо видна на ролях исследователя, автора и редактора. Если исследователь всегда передаёт материал автору, а автор всегда редактору, то это линейный конвейер с красивыми названиями: три «агента», ноль решений. Если после проверки состояния оркестратор выбирает между повторным исследованием, другим исполнителем, дополнительной проверкой или завершением задачи, появляется настоящая динамика.
Разделение на нескольких исполнителей вообще оправдано не названием, а специализацией: задачи действительно разные, инструкции слишком сложны для одного исполнителя, или у него скопилось слишком много похожих инструментов. OpenAI в такой ситуации советует multi-agent архитектуру, но не как решение по умолчанию — дополнительные исполнители добавляют вызовов, денег, задержки и сложности в диагностике.
Подтверждение человека — это граница полномочий
Логика approval layer описана у OpenAI просто: входы, выходы и вызовы инструментов можно проверять автоматически, а перед действиями с внешними последствиями процесс приостанавливается для человеческого подтверждения. Речь именно о необратимых операциях — удалении и редактировании данных, отмене действий, выполнении команд.
В проектируемой схеме Auto-Dzen черновик собирается и проверяется автоматически: длина, структура, ссылки, запрещённые формулировки. Публикация при этом ждёт подтверждения редактора. Это не недоделанная автоматизация, а сознательное ограничение полномочий перед необратимым внешним действием, и оно не отменяет агентности предыдущих этапов: исследование, сборка и проверки в такой схеме идут без человека, а человек появляется только на самом последнем шаге.
Для Market GPT я описываю похожую градацию — и тоже как проектируемую модель контроля: прочитать данные и сформировать рекомендацию можно автоматически, подготовить черновик изменения — тоже, а менять карточку, цену, бюджет или публичный контент — только после подтверждения. Пока это план, а не работающий механизм, и называть его иначе я не буду.
Сколько стоит право на следующий шаг
Anthropic честно предупреждает: агентные системы обменивают предсказуемость на гибкость. Они обычно дороже и медленнее обычных workflow, а длинные автономные цепочки накапливают ошибки — одна неудачная развилка тянет за собой следующие. Отсюда практический вывод: тестировать такое в изолированной среде, ставить guardrails и переходить к агентной архитектуре только тогда, когда более простые решения уже не дают нужного результата.
Право на следующий шаг — это и есть та черта, за которой автоматизация становится агентом. И одновременно самая дорогая часть конструкции: за него платят временем, деньгами и усложнением диагностики. Поэтому выбор между агентом и workflow стоит делать по задаче, а не по моде — часть процессов прекрасно живёт на жёстком маршруте и не страдает от этого.
Если хочется разбирать такие вещи на живых примерах, а не по пресс-релизам, заходите в GPT-Лабораторию — там мы обсуждаем автоматизацию, агентов и практику применения нейросетей: Telegram, ВКонтакте, MAX.
