Когда бизнесу нужен AI-агент, а когда достаточно сценария?

Допустим, ты хочешь быстрее готовить коммерческие предложения. Система должна прочитать запрос, найти подходящие материалы и собрать документ. Подрядчик предлагает AI-агента. Другой подрядчик обещает решить ту же задачу сценарием из нескольких шагов.

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

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

Чем агент отличается от сценария с нейросетью?

Возьмём архитектурное различие из Building effective agents от Anthropic: в workflow порядок работы задаёт код, а в агенте модель динамически выбирает процесс и использование инструментов. Материал опубликован в 2024 году; здесь мы используем определение, а не рекомендации по конкретным библиотекам.

Сценарий: получить заявку → проверить обязательные поля → дать модели собрать резюме → подставить утверждённые условия → передать документ менеджеру.

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

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

Как это выглядит на примере коммерческого предложения?

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

Компания продаёт три согласованных пакета услуг. Для КП нужны сфера клиента, задача, выбранный пакет и срок. Менеджер проверяет документ перед отправкой.

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

Теперь усложним задачу. Для каждого клиента надо изучить разные продуктовые материалы, сопоставить несколько ограничений, выбрать релевантный кейс и определить, какой документ ещё нужно открыть. Путь заранее описать труднее. Можно испытать агента, которому разрешено искать внутри выбранной базы и предлагать вопросы.

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

Таблица помогает выбрать, что проверять первым. Она не заменяет испытание на своих задачах. Даже сложную работу иногда удобнее разделить: поиск выполняет агент, сборку и проверку документа — обычный сценарий.

Какие правила стоит согласовать до разработки?

Попробуй объяснить задачу новому сотруднику. Где он берёт актуальные условия? Как отличает пример от обязательного требования? Кто отвечает на спорный вопрос?

Если ответа нет, его стоит получить у владельца процесса. В кейсе обучения команды единому стандарту знания из записей звонков организованы в модули и ситуационные упражнения. Для подготовки КП нужна похожая ясность: какими правилами руководствоваться и где остановиться с вопросом.

Для своего пилота я бы записал короткое поручение:

«Подготовь черновик КП по запросу клиента. Используй только указанные продуктовые материалы и утверждённый справочник. Приведи ссылки на основания для выбранного пакета и кейса. Если обязательных данных нет или условия противоречат друг другу, передай вопрос менеджеру. Не меняй цены и не отправляй документ».

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

Как сравнить два решения без соревнования красивых демонстраций?

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

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

Проверку необычных и конфликтных входов рекомендует и руководство OpenAI по оценке систем. Состав заданий и критерии приёмки нужно выбрать под свой процесс; универсального процента успеха для любого бизнеса здесь нет.

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

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

Настораживает поручение «сам найди проблему и сделай всё необходимое», если никто не может назвать допустимые действия. Или предложение оценивать успех по тому, насколько убедительно система объясняет свой ответ.

Для КП результат можно проверить по документам и утверждённым условиям. А если цель звучит как «улучши продажи», нужно сначала выбрать конкретную работу: разбор запросов, поиск материалов, подготовку документа или контроль следующего действия.

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

Что прочитать дальше?

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