Примеры ИИ‑агентов из моей практики: три задачи

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

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

Пример 1: агент принимает вопрос о строительной услуге

В проекте Radomir CRM сообщение с Авито связано с CRM. Помощник подхватывает обращение, уточняет сведения и оставляет менеджеру историю. Он не должен утверждать индивидуальную смету. На экране клиент трижды просит назвать цену. Робот намеренно не называет индивидуальную стоимость до замера и получает контакт. 17 сентября менеджер отправил смету на 80 000 ₽, сделка перешла в заливку. Это завершённый маршрут от вопроса до расчёта.

Для локального испытания сохраните обезличенные сообщения в JSON. Проверяйте тип результата. Точная фраза модели может меняться без изменения правильного действия. Один случай должен вести к ответу, другой к человеку, третий к остановке из‑за отсутствия данных.

[
  {"message":"Как считаете стяжку?","expected":"ask_area"},
  {"message":"Позовите специалиста","expected":"handoff"},
  {"message":"Цена на нестандартную смесь?","expected":"handoff"}
]

python3 -m json.tool cases.json >/dev/null

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

Перед переходом к следующему примеру проверьте первый маршрут руками:

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

Пример 2: агент ищет застрявшие сделки

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

Сделки на момент запуска -> фильтр по просроченным обещаниям
                         -> проверка карточки -> короткая рекомендация
                         -> руководитель подтверждает действие

Здесь модель полезна для краткого объяснения, почему строка важна. Но сам признак просрочки лучше считать по явному правилу и данным CRM. Тогда можно открыть карточку и проверить решение. В кейсе Radomir CRM показана форма экрана, к которой я привязываю рекомендации.

Пример 3: агент помогает разобрать звонок

В проекте AI‑РОП рабочий экран показывает разбор разговора. Путь сложнее: запись звонка превращается в текст, затем система ищет вопросы клиента, обещания менеджера и следующий шаг. Помощник может предложить руководителю фрагмент для проверки. Оценивать сотрудника по одному автоматическому выводу нельзя: расшифровка бывает неточной, а контекст звонка мог остаться в переписке.

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

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

Три примера отличаются тем, что нужно проверять после ответа.

Как выбрать свой первый пример

Оцените три вещи: частоту события, ясность правильного результата и цену ошибки. Заявки приходят часто, а факт создания карточки легко проверить. Разбор звонка может быть очень полезным, но качество вывода оценить труднее. Утреннюю сводку бессмысленно строить, если CRM не хранит обещания и сроки. Выбирайте участок, где у вас уже есть данные и человек, который исправит исключение.

# До изменения проекта проверьте, где сейчас создаётся задача
rg -n 'create_task|handoff|next_action' .
# После изменения посмотрите только затронутые файлы
git diff --stat

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

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

Частые вопросы

Какой из примеров дешевле начать собирать?

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

Нужно ли начинать с автономного агента?

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

Можно ли перенести агента из стройки в клинику?

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

Что считать результатом работы агента?

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

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