ИИ-агенты: инструменты и навыки

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

Под названием «скилы для ИИ агентов» подрядчики могут предлагать разные вещи: отдельную функцию, подключение к сервису или готовую цепочку действий. Поэтому при заказе полезно описать ожидаемый результат. Например, не просто попросить навык работы с CRM, а указать, какое поле агент должен заполнить и как проверить запись.

Что такое инструмент в контексте ИИ агентов

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

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

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

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

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

Какую роль выполняет инструмент в ИИ агенте

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

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

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

Даже успешный вызов не доказывает, что агент выбрал верное действие. Поиск может вернуть устаревший документ, а CRM — несколько карточек с похожими именами. Поэтому руководителю важно согласовать правила выбора, допустимые источники и действия при неоднозначном результате. Эти правила проверяют на примерах до запуска.

Какие действия может выполнять агент

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

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

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

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

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

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

Как устроен сценарий: от запроса до результата

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

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

Пример: агент звонит и отправляет сообщение

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

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

Пример: агент ищет ответ и записывает его в CRM

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

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

Какие права нужны инструментам

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

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

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

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

Готовые скиллы для ИИ агентов или индивидуальная настройка

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

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

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

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

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

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

Как описать подрядчику нужные инструменты

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

Далее называют систему и источник сведений. Для звонка это телефония и список разрешённых номеров, для поиска — конкретная база знаний, для записи — нужная CRM. Полезно приложить примеры карточки и документа. Подрядчик сможет проверить, доступны ли нужные операции и как система отвечает на запрос.

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

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

Пример требования: после подтверждения заказа агент находит карточку клиента в CRM, добавляет итог звонка в заданное поле и создаёт задачу сотруднику. Если карточка не найдена, агент не создаёт дубликат и передаёт случай сотруднику. Название поля, получателя задачи и способ передачи команда уточняет отдельно.

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

Главное о скиллах и инструментах ИИ-агента

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

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

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