Создайте первого ИИ-агента для одной реальной задачи

Выберите одну повторяемую задачу, а не универсального помощника

Начните не с названия «ИИ-агент», а с наблюдаемой работы. Хорошая первая задача повторяется, имеет понятный вход и допускает проверку результата. Плохая формулировка — «помогать бизнесу». Рабочая — «по письму клиента подготовить черновик ответа в заданной структуре и отметить, когда нужен человек».

Выбирайте задачу, если для неё можно ответить на четыре вопроса:

• Что приходит на вход?
• Как выглядит приемлемый результат?
• Какие случаи нельзя решать автоматически?
• Кто и как проверит первые результаты?

Не пытайтесь в первой версии объединить почту, продажи, документы, базу знаний и CRM. Чем шире роль, тем сложнее понять причину ошибки: не хватило данных, правило сформулировано расплывчато или задачу вообще стоило передать человеку.

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

Опишите карточку роли до настройки

Карточка роли — короткий рабочий документ. Она нужна не для красивого описания, а чтобы сотрудник мог проверить: агент действует в рамках задачи или начал додумывать. В первой версии карточки достаточно шести разделов.

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

Шаблон карточки роли

Скопируйте шаблон и заполните его на одной странице.

Название роли: [действие + объект]

>

Цель: [какой результат готовит роль]

>

Работает только с: [перечень входных данных и разрешённых материалов]

>

Не делает: [запрещённые действия и темы]

>

Результат выдаёт так: [структура, длина, обязательные поля]

>

Передаёт человеку, если: [список условий]

>

Перед запуском проверяет: [что должно быть во входных данных]

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

Ограничьте инструменты и права минимально необходимым доступом

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

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

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

Для Smokva сценарий создания роли и карточки роли, доступный набор инструментов и модель прав в текущем тенанте в этом материале не подтверждены. До проверки в интерфейсе не стоит приписывать платформе автоматические действия, интеграции или журналирование тестов. Если команда использует Smokva, можно начать с изучения страницы команды в кабинете: https://app.smokva.ai/app/team. База знаний доступна по адресу https://app.smokva.ai/app/knowledge — используйте её только после проверки, какие материалы и права доступны вашей роли.

Подготовьте десять задач до первого запуска

Тестировать роль на одном удобном примере опасно: он может случайно совпасть с инструкцией. Соберите десять реальных, но безопасных задач из недавней работы. Уберите или замените чувствительные сведения, если они не нужны для проверки.

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

Журнал проверки на 10 задач

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

Не меняйте ожидаемый результат задним числом. Иначе тест превращается в поиск оправдания удачному ответу.

Прогоните задачи и фиксируйте ошибку, а не впечатление

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

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

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

Решите, что менять после десяти задач

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

Уточнить роль. Подходит, когда задача остаётся узкой, но не хватает ясного правила, формата или примера допустимого результата.

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

Передавать сложные случаи человеку. Подходит, когда для решения нужны полномочия, оценка риска, недоступные данные или персональная ответственность сотрудника.

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

Не расширяйте роль, пока не подтвердили базовый сценарий

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

Если следующая задача действительно связана с карточкой контакта, можно отдельно проверить рабочий процесс в CRM Smokva: https://app.smokva.ai/app/crm/contacts. Не добавляйте этот шаг только ради интеграции или ссылки: сначала определите, какой факт роль должна читать или записывать, кто отвечает за корректность записи и какое право для этого необходимо.