Как создать ИИ-агента: от одной задачи до проверяемого пилота

1. Выберите работу, которую можно проверить

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

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

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

2. Решите, нужен ли именно агент

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

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

Определите разрешённый уровень действий. На старте разумно дать системе право читать данные и готовить черновик. Изменение записи, отправка письма или запуск оплаты — отдельные решения с отдельной проверкой.

3. Приведите знания в состояние, пригодное для поиска

Частый запрос: «Пусть агент отвечает по нашим документам». Покажите эти документы: у них есть владелец, дата обновления, версия, права доступа? Если условия доставки различаются в PDF, таблице и переписке, модель не угадает, чему верить.

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

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

4. Соберите короткую схему и минимальные инструменты

Для первого рабочего прототипа обычно достаточно модели, инструкции, одного источника знаний и одного результата. Например: письмо клиента на входе; поиск по утверждённым условиям; черновик ответа с ссылками; статус «нужна проверка». Только после этого имеет смысл подключать CRM и дополнительные сервисы.

Инструмент для агента — не абстрактное «доступ к интернету», а строго определённая операция: получить карточку заказа по номеру, найти статью в базе, создать черновик задачи. В Yandex AI Studio для агентов описаны инструменты, память и поиск по файлам; похожие возможности встречаются и на других платформах. Выбирают их по требованиям к данным, качеству на ваших примерах, стоимости и поддержке, а не по числу пунктов в меню.

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

5. Сделайте набор тестов раньше красивого интерфейса

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

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

Не используйте один и тот же десяток примеров и для настройки, и для окончательной оценки. Оставьте часть случаев как контрольные, неизвестные разработчику во время доработки. Для небольшого пилота это доступнее и честнее, чем универсальная цифра «точность 99 %».

• Типовой случай: ответ есть в действующем документе.
• Пробел: источника нет или он устарел.
• Конфликт: два документа дают разные условия.
• Атака: текст письма пытается заставить агента игнорировать инструкции.
• Критическое действие: требуется согласие человека до отправки или изменения данных.

6. Посчитайте цену одного завершённого действия

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

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

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

7. Проверьте безопасность и полномочия

Чужой текст — письмо, страница сайта, документ — может содержать команду для модели. Нельзя считать его инструкцией владельца системы. OWASP отдельно описывает риск внедрения инструкций и раскрытия чувствительной информации. Минимальные меры: ограничение прав, разделение доверенных и внешних данных, журнал действий, подтверждение рискованных операций и проверка негативных сценариев.

Отдельный вопрос — кто сможет исправить поведение после запуска. Меняется регламент, появляется новый товар, переименовывается поле в CRM. Без ответственного за знания и тесты качество будет медленно дрейфовать, даже если первый день прошёл отлично.

8. Встройте в работу, а не оставляйте в тестовом окне

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

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

Мы помогаем пройти этот путь от процесса и измерений до технического задания и пилота. Обсудить создание ИИ-агента можно с одной конкретной задачей: покажите несколько обезличенных примеров, а мы начнём с проверки, подходит ли для неё агент.