Фиксированный workflow или агентный маршрутизатор: что выбрать для задачи

Если входные данные каждый раз проходят одинаковые шаги, фиксированный workflow обычно надёжнее и дешевле в сопровождении. Если задача меняется от случая к случаю и требует выбрать один из нескольких инструментов, агентный маршрутизатор может сэкономить ручные переключения. Но слово «агент» не превращает процесс в более умный автоматически: он добавляет вариативность, дополнительные вызовы и новый класс ошибок. Выбор зависит от того, сколько решений действительно нельзя заранее описать правилами.

Один сценарий для сравнения

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

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

Сравнение по шести критериям

Повторяемость. Фиксированный workflow выигрывает, когда входы структурированы. Агентный роутер может выбрать другой путь, поэтому нужны логи выбора, ограничения на число вызовов и контрольная выборка.

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

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

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

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

Обслуживание. Workflow проще объяснить новому сотруднику, но он может разрастись в сложную схему. Агент сокращает количество ручных переходов, однако требует наблюдаемости: версия правил, выбор инструмента, причина эскалации и итог проверки.

Проведите честный пилот

Соберите 50–100 обезличенных заявок и разделите их на типовые, неоднозначные и исключения. Для каждой заранее запишите правильный статус и действие. Прогоните один и тот же набор через простой workflow и ограниченного агента. Не подключайте внешнюю отправку: пусть оба варианта формируют черновик, а оператор выставляет метку «принято», «исправлено» или «эскалация».

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

Решение без модного ярлыка

Выберите workflow, если шаги стабильны, ошибки дороги, а вход можно привести к форме. Оставьте агенту только узкий участок, где действительно есть выбор между инструментами или нестандартная формулировка. Часто лучшая система гибридная: детерминированный каркас задаёт права и последовательность, а модель помогает извлечь смысл или выбрать допустимую ветку. Проверяйте границу каждого перехода и не позволяйте свободной генерации выполнять необратимое действие.

FAQ

Можно ли начать сразу с агента? Можно, но на пилоте ограничьте инструменты и оставьте финальное действие человеку.

Какой вариант дешевле? Это зависит от числа исключений и повторов; измеряйте стоимость полного обработанного случая, включая время сотрудника.

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

Практическая граница ответственности

Для каждого шага полезно задать один вопрос: может ли здесь система изменить внешний мир? Классификация обращения обычно только готовит решение; отправка ответа клиенту уже влияет на человека. Даже если модель уверенно выбирает категорию, перевод денег, изменение записи и публикацию лучше оформлять отдельным действием с проверкой прав и подтверждением. Такой рубеж делает сравнение вариантов честнее: оценивается не красота демо, а способность безопасно довести задачу до результата.

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