ИИ-агент полезен там, где нужно не только подготовить ответ, но и выбрать следующий шаг: найти сведения, обратиться к инструменту, проверить результат и при необходимости уточнить задачу. Начинать я бы предложил с ограниченного внутреннего процесса, где результат принимает сотрудник. Доступ к деньгам, публикациям и обещаниям клиенту требует отдельного решения.
Вокруг слова «агент» сейчас много интересного. Иногда так называют обычный бот с несколькими кнопками. Иногда — систему, которой хотят выдать доступ почти ко всему бизнесу. Для первой задачи мне достаточно знать, какие действия она выполняет и кто замечает ошибку. Название можно обсудить потом.
Сначала определите, нужна ли свобода действий
Есть простая последовательность: поступила форма, поля записались в таблицу, менеджер получил уведомление. Если шаги заранее известны, такой процесс можно собрать обычной интеграцией.
Теперь другой случай. Пришло свободное описание проблемы с сайтом. Нужно понять, о какой странице речь, найти связанные проверки, выделить недостающие сведения и подготовить человеку сводку. Здесь выбор следующего действия уже зависит от содержания обращения.
Anthropic в разборе агентных систем проводит полезное различие: у рабочего процесса путь заранее задан кодом, а агент выбирает действия динамически. В конкретном продукте оба подхода могут сочетаться. Чем больше свободы, тем внимательнее приходится проверять поведение.
| Задача | С чего разумно начать | Где может понадобиться агент |
|---|---|---|
| Переслать поля заказа | Обычная интеграция | Обычно незачем усложнять |
| Кратко разобрать обращение | Один запрос к модели и проверка | Если нужно искать сведения в разных разрешённых источниках |
| Подготовить статью | Процесс с этапами и редактором | Для исследования внутри заданных границ |
| Изменить цену в магазине | Действующие правила и ответственный | Лишь с отдельно согласованными полномочиями и контролем |
Эта таблица помогает выбрать архитектуру, а не доказывает, что определённый инструмент уже умеет всё перечисленное.
Выберите результат, который можно принять
Для пробного запуска подойдёт конкретный документ или карточка. Например, сводка по проблеме: что произошло, какие сведения найдены, чего не хватает, кому передать. У результата есть проверяемые поля, а не общее требование «сделать поддержку умнее».
В нашей работе есть сайты, контент и собственные инструменты для обращений и мониторинга. Из этого можно собирать сценарии автоматизации. Но наличие чата или истории сообщений само по себе ещё не означает, что там работает автономный ИИ-продавец. Для такого заявления нужны отдельные реализованные функции и их проверка.
Допустим, агент готовит черновик ответа по каталогу. Тогда в задании стоит прямо написать: использовать только переданные характеристики, неизвестное отмечать, цену не придумывать, клиенту не отправлять. Получается небольшая полезная роль, которую можно проверить до расширения.
Ограничьте инструменты и право на запись
Составьте список разрешённых источников и действий. Для первого запуска часто достаточно чтения выбранных документов и создания черновика. Публикация, удаление, изменение заказа и отправка сообщения — другие полномочия.
Отдельно задайте границы выполнения: сколько шагов разрешено, когда надо остановиться и куда передать неясный случай. Если документ не найден, агент должен сообщить об этом, а не продолжать поиск бесконечно и не подменять пробел догадкой.
Внешние страницы и сообщения клиентов рассматривайте как данные. Инструкция внутри чужого текста не должна сама по себе разрешать системе менять настройки или отправлять сведения наружу. Ограничения нужны и в инструментах: один текстовый запрет не заменяет проверку доступа на стороне приложения.
Для владельца это можно оформить коротко: «читает эти папки, создаёт черновики здесь, ничего не отправляет, при сомнении зовёт этого сотрудника». Уже заметно понятнее слова «автономный».
Наличие доступа к чтению не должно автоматически давать право менять данные или писать клиенту. На каждом следующем уровне нужны свои ограничения и способ исправить ошибку.
Проверьте обычные случаи и неудобные исключения
Соберите разрешённые примеры: полный запрос, неполный, противоречивый, повторный и запрос без ответа в базе. Перед запуском запишите ожидаемое поведение. Важен и правильный отказ от действия, если данных недостаточно.
Измеряйте время вместе с проверкой и исправлениями. Быстрая подготовка не помогает, если сотрудник затем заново расследует каждый пункт. Дополнительно считайте неподтверждённые утверждения, неверно выбранные действия и случаи, когда система не остановилась вовремя.
Маленькая пробная выборка показывает явные проблемы, но не гарантирует надёжность на всех будущих обращениях. После изменений повторяйте проверку на сохранённых случаях и добавляйте реальные ошибки в набор.
Добавьте в тесты случай, когда ответа в базе нет. Корректная остановка в таком случае полезнее уверенно составленного ответа из общих знаний.
Расширяйте полномочия по одному действию
Сначала пусть система готовит материал для человека. Когда понятны качество, стоимость и причины ошибок, можно отдельно разрешить конкретную запись: например, создать внутреннюю задачу по утверждённому формату.
Для каждого такого действия нужны журнал, защита от случайного повторения и понятный способ исправить результат. Если ответ инструмента потерялся, сначала выясните, произошла ли запись. Повтор вслепую способен создать вторую задачу или второе сообщение.
Я бы начинал с одной роли, одного принимающего сотрудника и понятной границы остановки. Критерии выбора первой задачи подробнее есть в статье про ИИ для бизнеса. Если у вас есть повторяющийся процесс, можно разобрать его вместе и определить, где агент вообще нужен.