Почему AI-агенту нужен план B

AI-агент проектируется для выполнения определённой задачи.

Есть входные данные, набор инструментов, правила и ожидаемый результат. В идеальном сценарии всё происходит именно так, как задумано.

Но реальная инфраструктура почти никогда не работает идеально.

Сервис может оказаться недоступен. Документ — нечитабельным. Данные — неполными. Модель — не справиться с задачей. API — вернуть ошибку. Пользователь — изменить запрос посреди процесса.

Если на этот случай предусмотрено только одно действие — «попробовать ещё раз», система быстро упирается в свои ограничения.

Поэтому зрелому AI-агенту нужен план B.

А иногда — C и D.

Допустим, агенту нужно получить информацию о клиенте.

Основной маршрут выглядит просто:

CRM → данные клиента → анализ → результат.

Но что произойдёт, если CRM временно недоступна?

Если агент не имеет альтернативного сценария, процесс останавливается.

Можно разрешить ему повторить запрос.

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

Более надёжная архитектура предусматривает другой путь:

CRM недоступна → проверить резервный источник → если данных нет, сохранить задачу → уведомить ответственного.

Так система не зависит от идеальной работы одного компонента.

Повторить действие и использовать альтернативный сценарий — разные вещи.

Повтор означает:

«Попробуй сделать то же самое ещё раз».

Fallback означает:

«Если основной способ не работает, используй другой способ решения задачи».

Например, если API временно недоступен, повтор может помочь.

Но если API окончательно изменил формат ответа, повторять запрос бессмысленно.

Нужен другой маршрут.

Не обязательно создавать альтернативу абсолютно для каждой операции.

Но чем важнее этап для бизнеса, тем опаснее отсутствие запасного пути.

Особенно это касается:

· получения критичных данных;

· внешних API;

· финансовых операций;

· коммуникации с клиентами;

· проверки документов;

· действий, от которых зависит следующий этап процесса.

Если один сервис останавливает весь workflow, он фактически становится единственной точкой отказа.

Самый очевидный вариант резервирования — альтернативный источник.

Например:

основная база → резервная база → ручная проверка.

Или:

API → локальный кэш → запрос сотруднику.

При этом важно заранее определить, насколько свежими должны быть данные.

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

Если речь идёт о текущем балансе или статусе заказа, использовать устаревшую информацию опасно.

Неудача может произойти не на уровне инструмента.

Сама модель может не справиться с конкретной задачей.

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

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

Получается:

модель A → проверка → модель B → человек при необходимости.

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

Есть опасная ошибка: создать слишком много резервных маршрутов.

Тогда вместо простого процесса получается:

модель A → модель B → модель C → поиск → другой поиск → новый агент → ещё один агент → человек.

Система вроде бы умеет справляться с любыми проблемами.

Но разобраться, почему она приняла конкретное решение, становится почти невозможно.

Поэтому альтернативный маршрут должен быть оправданным.

Для каждого fallback стоит понимать:

какую проблему он решает и почему именно этот вариант лучше остановки процесса.

Система не должна самостоятельно гадать, когда пора менять маршрут.

Нужны конкретные триггеры.

Например:

· сервис вернул определённый тип ошибки;

· данные отсутствуют;

· результат не прошёл проверку;

· превышен лимит времени;

· модель не сформировала требуемую структуру;

· количество попыток достигло ограничения.

Тогда переход на резервный сценарий становится предсказуемым.

Это особенно важно для внешних сервисов.

Некоторые ошибки действительно означают временную проблему.

Например, сервис перегружен.

Но другие говорят о принципиально другой ситуации.

Например:

· доступ запрещён;

· ресурс удалён;

· формат запроса изменился;

· нужного объекта больше не существует.

Повторение в таких случаях только расходует ресурсы.

Поэтому система должна различать типы ошибок.

Не каждый процесс должен иметь альтернативный автоматический маршрут.

Если действие связано с высоким риском, попытка «как-нибудь решить проблему» может быть хуже, чем остановка.

Например, агент не уверен в реквизитах платежа.

Можно попытаться найти их в другом источнике.

Но если данные противоречат друг другу, безопаснее остановить операцию и передать её человеку.

Получается важный принцип:

план B не всегда означает продолжение автоматизации. Иногда это контролируемая остановка.

Если система не может решить задачу автоматически, человек не должен получать сообщение:

«AI не смог выполнить операцию».

Такое уведомление почти бесполезно.

Человеку нужно передать контекст:

· исходную задачу;

· полученные данные;

· выполненные действия;

· обнаруженную проблему;

· использованные источники;

· варианты дальнейшего решения.

Тогда сотрудник подключается не вместо системы, а в конкретной точке, где автоматизация достигла своего предела.

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

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

Это увеличивает стоимость и может создать новые ошибки.

Лучше сохранить состояние:

этапы 1–4 завершены → этап 5 не выполнен → продолжить с этапа 5 по резервному маршруту.

Для долгих workflow это особенно важно.

Есть ещё одна распространённая проблема.

Основной агент получил сомнительный результат.

Workflow не смог пройти проверку.

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

В таком случае fallback ничего не исправляет.

Он просто распространяет исходную ошибку дальше.

Поэтому при смене маршрута нужно понимать:

какие данные можно сохранить, а какие нужно получить заново.

План B — не обязательно копия основного сценария.

У него могут быть другие ограничения.

Например, основной маршрут позволяет автоматическое действие.

Резервный — только подготовку черновика.

Основная модель может работать автономно.

Резервная требует дополнительной проверки.

Основной источник может использоваться в реальном времени.

Резервный — только для предварительного анализа.

Это нормально.

Fallback должен решать задачу с учётом того, что условия изменились.

Нельзя ждать реального сбоя, чтобы проверить план B.

Если резервный сценарий критичен, его нужно запускать искусственно.

Отключить API.

Вернуть пустой ответ.

Передать повреждённый документ.

Сделать модель недоступной.

Создать конфликт данных.

И посмотреть, действительно ли система переходит на предусмотренный маршрут.

Именно такие тесты показывают, существует ли fallback на самом деле или он существует только на архитектурной схеме.

Один сбой — относительно простой случай.

Гораздо интереснее посмотреть, что произойдёт, если не работает сразу несколько компонентов.

Например:

основной API недоступен → резервный источник тоже не отвечает → что делает система?

Если ответа нет, значит у процесса нет последней границы.

Для критичных операций такой сценарий должен заканчиваться понятным состоянием:

остановлено → создана задача для человека → данные сохранены → повторный запуск возможен.

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

Это не всегда плохо.

Но её нужно осознавать.

Наличие альтернативного маршрута позволяет пережить:

· временную недоступность;

· изменение API;

· изменение цен;

· изменение лимитов;

· ухудшение качества;

· прекращение работы сервиса.

Не обязательно иметь полноценную копию всей инфраструктуры.

Иногда достаточно иметь понятный сценарий деградации.

Это нормально.

План B не обязан быть самым дешёвым способом выполнения задачи.

Его задача — сохранить работоспособность процесса, когда основной путь недоступен.

Например, основная обработка выполняется автоматически.

При сбое задача уходит сотруднику.

Стоимость второй схемы выше.

Но если простой процесса обходится бизнесу ещё дороже, такая архитектура оправдана.

Не все процессы должны восстанавливаться одинаково быстро.

Для одной задачи допустимо ждать несколько часов.

Для другой — несколько минут.

Поэтому fallback-сценарии должны учитывать критичность процесса.

Можно заранее определить:

· допустимое время простоя;

· допустимый уровень ручной работы;

· максимальное время ожидания;

· условия остановки;

· порядок восстановления.

Тогда система не пытается одинаково срочно спасать абсолютно всё.

В идеальном случае клиент вообще не понимает, что основной маршрут не сработал.

Например:

основной сервис → ошибка → резервный сервис → результат.

Пользователь получает ответ без лишних подробностей.

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

Надёжность важнее иллюзии беспроблемной работы.

Иногда резервный маршрут оказывается опаснее основного.

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

Поэтому fallback нужно оценивать не только по вопросу:

«Работает ли он?»

Но и:

«Можно ли доверять его результату в этом сценарии?»

Если резервный маршрут используется постоянно, это уже не fallback.

Это основной процесс.

Например, компания планировала, что резервная модель будет использоваться в 2% случаев.

Через несколько месяцев она используется в 35%.

Это сигнал, что основной маршрут требует пересмотра.

Поэтому полезно отслеживать:

· частоту переходов на fallback;

· причины переключения;

· успешность резервного маршрута;

· стоимость;

· время выполнения;

· долю ручных вмешательств.

Это один из самых ценных источников информации.

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

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

Вместо бесконечного улучшения fallback нужно изменить архитектуру основного процесса.

Надёжная агентная система проектируется сразу с несколькими вариантами поведения:

нормальный сценарий; временный сбой; неполные данные; неожиданный результат; критичная ошибка; ручная эскалация.

Тогда система не оказывается беспомощной при первом отклонении от идеального сценария.

Автономность AI-агента определяется не тем, насколько много он умеет делать самостоятельно.

Она определяется ещё и тем, насколько хорошо он умеет вести себя, когда что-то идёт не по плану.

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

А у зрелой системы есть ещё один важный принцип:

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

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

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