ИИ-агенты для бизнеса: где нужен агент, а где хватит обычной автоматизации
Две заявки могут содержать одну просьбу: в первой клиент заполнил форму, во второй написал всё обычным сообщением. ИИ-агенты для бизнеса дают модели право самой выбирать следующие действия. Но свободный текст ещё не требует агента: модель может извлечь из него данные, а дальше программа пройдёт заранее заданные шаги. Право самой выбирать следующие действия имеет смысл давать модели там, где путь к результату действительно меняется.
Мы проверили это на одной операции: подготовке ответа на заявку об аренде оборудования. Для учебной модели придумали клиентов, заказы, цены и шесть обращений. Реальный бизнес, наличие оборудования и отправку сообщений не подключали. Сначала обработали набор обычными правилами, затем добавили разбор текста моделью и отдельно прошли те же обращения в агентном режиме. Разница оказалась полезнее очередного списка возможностей ИИ: она показала, какую именно свободу можно оставить за пределами автоматизации.
Почему одна заявка проходит автоматически, а другая попадает человеку?
Представим владельца проката, которому нужно готовить расчёты аренды. Для этой операции нужны дата начала, срок и состав оборудования с количеством. Дальше действует прайс: стоимость каждой позиции за сутки умножают на количество и число дней. До подтверждения заказа человек должен проверить наличие и условия выдачи.
Первую учебную заявку мы передали в готовых полях: два проектора, один экран, два дня с 1 декабря 2026 года. В вымышленном прайсе проектор стоит 1800 рублей в сутки, экран — 600. Обычная функция посчитала (1800 × 2 + 600) × 2 и вернула 8400 рублей.
Во второй заявке клиент сообщил то же самое одним предложением: «С 1 декабря 2026 на два дня нужны два проектора и один экран. Подготовьте расчёт». Для человека содержание совпадает с первой заявкой. Однако наш исходный обработчик принимал заполненные поля. Свободное сообщение он передал оператору, как и было предусмотрено.
Это рабочая граница конкретной настройки. Правила не дали неправильную сумму: у них не было предусмотренного способа достать исходные данные из такого сообщения. Обработчик можно расширять, например добавлять варианты формулировок. В нашем прогоне следующим шагом стал разбор текста языковой моделью.
Для собственника здесь возникает первое практическое решение. Если клиентам удобно отвечать на несколько закрытых вопросов, вход можно сразу привести к нужному виду. В публичном примере клуба с квизом для сайта Рома, основатель клуба, заменил бота, который должен был доводить клиента до предоплаты, линейной формой с вопросами о дате, количестве гостей и формате. Ответы уходят в CRM, а обсуждение цены и оплаты остаётся менеджеру. Такой процесс достаточен, когда известны и вопросы, и дальнейший маршрут заявки.
Что меняется, если поручить модели только разбор текста?
Во втором проходе модель извлекла из свободных сообщений нужные данные: дату, срок, оборудование, количество и упомянутый номер прошлого заказа. Дальнейший порядок мы сохранили: проверить повтор обращения, выделить особые условия, при необходимости получить состав прошлого заказа, проверить полноту данных и выбрать расчёт либо уточнение.
Для заявки про два проектора и экран модель подготовила тот же набор полей, который уже был в форме. Затем обычный калькулятор снова вернул 8400 рублей. Языковая модель помогла прочитать просьбу, а сумму определила программа по прайсу.
Такую цепочку удобно рассматривать по ответственности. Модель отвечает за понимание сообщения. Правила определяют, какие данные обязательны и какой следующий шаг допустим. Калькулятор выполняет арифметику. Человек подтверждает условия, которые программа пока не проверяет. От добавления модели весь процесс не получает право самостоятельно менять порядок работы.
В учебном проходе модель отдельно разобрала сообщения, а извлечённые данные мы передали обработчику. Отдельный автоматический вызов модели внутри программы не подключали. В рабочем решении такой этап может быть одним вызовом на заявку, но качество этого разбора на других сообщениях наш набор не измеряет.
Отдельной проверки требует смысл извлечённых данных. Наличие числа в поле срока само по себе ещё ничего не гарантирует: важно, чтобы клиент действительно назвал срок. Поэтому для процесса полезно заранее определить, какие сведения можно брать из обращения, какие — из справочника, а какие обязательно нужно уточнить. Иначе технически заполненная заявка может содержать догадку, которую никто не разрешал использовать.
Когда ИИ-агенты для бизнеса получают отдельную задачу?
В описании архитектур Anthropic различие проходит по управлению процессом. В workflow модель и инструменты работают по заранее заданному пути. В агентной системе модель сама выбирает дальнейшие действия и использование инструментов. Подробнее как устроен агентный цикл, мы уже разбирали в отдельной статье.
Для владельца операции это различие можно выразить через конкретное полномочие: кто решает, что делать после полученного ответа? Если для каждой ситуации уже известен следующий шаг, его можно записать в правилах. Если же результат промежуточного действия меняет план, появляется отдельная задача для агентного управления.
В нашем наборе подходящим кандидатом выглядела третья заявка: «Повторите состав моего заказа H-101, но на три дня с 4 декабря 2026». В ней нет перечня оборудования. Чтобы подготовить расчёт, нужно обратиться к истории.
Учебный заказ H-101 содержал две колонки и один микшер. В прошлом их брали на два дня. Новая просьба меняла срок на три дня, поэтому переносить старый заказ целиком было бы ошибкой. Нужно взять из истории состав, а срок — из свежего сообщения. По вымышленным ставкам 900 рублей за колонку и 1200 за микшер калькулятор получил (900 × 2 + 1200) × 3 = 9000 рублей.
Агентный проход выполнил эту последовательность: модель выбрала обращение к истории, после ответа получила цены нужных позиций и вызвала расчёт. Это был реальный интерактивный проход модели с локальными инструментами, а не скрипт с заранее записанными решениями за неё.
Однако тот же маршрут мы предусмотрели в фиксированной цепочке: если в сообщении есть номер заказа, получить его состав и продолжить проверку данных. Она тоже вернула 9000 рублей. Само обращение к истории оказалось недостаточным основанием для агентной архитектуры: необходимый путь уже был известен.
Что показали остальные обращения и где остановилась автоматизация?
Три оставшиеся заявки проверяли границы операции. Они важны для выбора устройства процесса не меньше, чем готовая сумма.
Клиент из четвёртого обращения попросил один проектор с 5 декабря и спросил цену. Срок он не назвал. Обработчик с разбором моделью выбрал уточнение; в агентном проходе модель подготовила вопрос о сроке. Ни один из этих вариантов не выдал расчёт. Дата начала не подсказывает, на сколько дней клиент берёт оборудование, а подставлять удобное значение в учебной задаче не разрешалось.
В пятом обращении были и состав, и срок: один экран на два дня с 6 декабря. Но клиент добавил просьбу о скидке 15% со словами «как договорились». Доступной информации о такой договорённости у обработчика не было. Фиксированная цепочка передала заявку человеку; агентный проход сделал то же самое и не пообещал скидку. Понимание фразы не даёт права подтверждать чужую договорённость.
Шестое обращение полностью повторяло первую заявку с тем же идентификатором. Все три варианта распознали повтор по этому признаку. Второго черновика в агентном проходе не появилось. Здесь проверяли именно одинаковый идентификатор: похожие сообщения с разными номерами и одновременное поступление заявок в прогон не входили.
Результат шести обращений можно свести к трём наблюдениям:
- Исходные правила посчитали заявку из формы, остановили повтор, а свободные сообщения направили оператору.
- Цепочка с моделью дополнительно подготовила расчёты из текста и по прошлому заказу, выделила недостающий срок и условие скидки.
- Агентный проход дал те же полезные исходы, что эта цепочка, самостоятельно выбирая операции там, где цепочка уже имела готовый маршрут.
Каждый расчёт оставался черновиком с условием подтверждения наличия и выдачи человеком. Доставка и другие услуги в сумму не входили. Мы отдельно сверили результаты с учебным прайсом, проверили смену срока с двух на три дня и отсутствие расчётов в неопределённых случаях. Отправки в этой модели вообще нет.
Этого достаточно, чтобы оценить устройство одной операции. Для вывода о скорости, стоимости обработки или точности на потоке данных нет. Результат также не доказывает общее преимущество фиксированных цепочек: мы выбрали небольшой набор обращений с известными ситуациями.
Как выбрать достаточный вариант для своего процесса?
Начать можно с одного результата, который нужен бизнесу. В нашей операции это черновик ответа со стоимостью аренды либо понятная причина, почему расчёт пока готовить нельзя. Подтверждённый заказ потребовал бы другой задачи: с проверкой наличия и согласованием условий.
Дальше полезно разобрать несколько собственных обращений в одном и том же порядке. Сначала отметить, какие данные нужны для результата и где они находятся. Затем записать действия после получения данных. Наконец, обозначить решения, которые требуют человека. Такое описание помогает увидеть, для какой части операции действительно нужна модель.
В учебной аренде получились четыре части:
- Фиксированные действия: проверка повтора, полноты заявки и расчёт по прайсу.
- Понимание текста: извлечение даты, срока, состава и ссылки на прошлый заказ.
- Обращение за дополнительными сведениями: получение состава заказа по названному номеру. В нашем наборе это тоже заранее известный шаг.
- Решения человека: подтверждение скидки, наличия и выдачи; получение недостающего срока у клиента.
Если данные сразу приходят в нужном виде, можно начать с правил. Если маршрут известен, но данные спрятаны в свободном сообщении, имеет смысл проверить цепочку с разбором моделью. Агентное управление заслуживает отдельного рассмотрения, когда при описании реальных обращений обнаруживаются шаги, выбор которых зависит от промежуточных результатов и плохо укладывается в готовый порядок.
Такой выбор нужно подкрепить проверкой результата. Для аренды мало убедиться, что ответ выглядит убедительно. Проверяющий должен видеть, откуда взялись позиции и срок, совпадают ли ставки с прайсом, осталось ли особое условие без подтверждения. Если система подготовила вопрос, нужно проверить, какого именно сведения ей не хватило. Если передала заявку менеджеру — сохранила ли просьбу клиента, из-за которой потребовалось решение.
Перед работой с реальными клиентами останутся проверки, которых в нашем прогоне не было: доступ к данным разных клиентов, работа интеграций, повторы с другими идентификаторами, параллельные обращения и устойчивость к злонамеренному тексту. Их набор зависит от полномочий системы. Чем больше действий она может выполнить без человека, тем существеннее последствия неверного решения.
Владелец может оставить маршрут фиксированным и при этом получить пользу от языковой модели. В нашей операции именно её способность прочитать по-разному оформленные просьбы сняла ограничение исходной формы. Дополнительная свобода выбора действий на этих шести заявках результата не добавила.
Короткие ответы на частые вопросы
Любая автоматизация с языковой моделью — агент?
Модель может выполнять один шаг в заранее заданной цепочке, например извлекать данные из сообщения. Агентное управление начинается там, где она сама выбирает дальнейшие действия и инструменты.
Свободный текст клиента обязательно требует агента?
Для нашего набора хватило разбора текста моделью и фиксированного порядка обработки. На других обращениях качество такого разбора нужно проверять отдельно.
Запрос к истории заказов уже делает систему агентом?
Его можно заранее предусмотреть: клиент назвал номер заказа — программа получает состав. В учебном прогоне этот маршрут дал такой же результат, как выбор действий моделью.
Можно ли поручить модели считать стоимость?
В нашем сравнении суммы считала одна обычная функция по прайсу. Модель извлекала данные или выбирала действия; качество её арифметики мы не проверяли.
Когда оставлять решение менеджеру?
Когда не хватает данных или полномочий для подтверждения условий. В учебном наборе человеку передали просьбу о скидке; наличие и выдача также требовали подтверждения.
Можно ли запускать такую обработку после проверки шести заявок?
Шесть заранее выбранных обращений показывают работу только этих ситуаций. Для реальной эксплуатации нужны проверки на собственных данных, интеграциях и допустимых действиях системы.
Два одинаковых по смыслу запроса в начале разбора различались только формой подачи. После извлечения данных они прошли один порядок обработки и дали одну сумму. Этот переход и помог выбрать достаточную сложность для учебной операции. В AI Practiq мы разбираем внедрение через такие конкретные решения: какой результат нужен бизнесу, что поручить модели и чем проверить её работу.
Если вам близок разбор ИИ через конкретные рабочие задачи, читайте канал AI Practiq.