Онбординг AI-агента: чему его учить вручную перед работой

Компании наперегонки внедряют AI-агентов — надстройки над языковыми моделями, которые не просто отвечают на вопросы, а сами вызывают инструменты: пишут в CRM, отправляют письма, деплоят код, создают тикеты. Разница между «умным чатом» и агентом в том, что агент действует, а не советует. И именно поэтому его нельзя просто подключить и уйти пить кофе: модель знает язык, но не знает вашу компанию. Онбординг агента — это набор ручной работы, которую за вас никто не сделает.

Ниже — что придётся настроить самому, в каком порядке и где чаще всего ломается.

Что агент не знает по умолчанию

Базовая модель обучена на публичных данных и остановлена на дате отсечки знаний*. Она не в курсе, что у вас есть регламент возврата средств, что Марину из поддержки нельзя дёргать по ночам, а деплой в пятницу вечером запрещён внутренним правилом. Всё это придётся передать явно — иначе агент будет действовать по «здравому смыслу», а здравый смысл модели вычислен на чужих данных.

Условно онбординг делится на четыре блока: контекст, доступы, границы и обратная связь.

1. Контекст: знания о компании

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

• вычистить устаревшие документы — если в базе лежат два противоречащих регламента, агент процитирует любой;
• разбить длинные документы на осмысленные фрагменты, а не резать по 500 символов посреди предложения;
• добавить глоссарий внутренних сокращений — «СЗ», «БП-12», названия внутренних систем модель не расшифрует сама.

2. Доступы: что агенту можно трогать

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

• отдельная учётная запись для агента, а не рабочий аккаунт живого человека;
• read-only там, где действие не обязательно: пусть агент читает CRM, но создаёт черновик, а не отправляет письмо клиенту сам;
• лог каждого вызова инструмента — вы должны видеть, что именно агент сделал и когда.

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

3. Границы: чего делать нельзя

Самая недооценённая часть онбординга. Модель по умолчанию услужлива и старается выполнить запрос любой ценой. Границы задаются в системном промпте и через ограничения на уровне инструментов:

• операции с деньгами, удаление данных, рассылки клиентам — только с подтверждением человека (паттерн human-in-the-loop);
• явный список запретов: не обещать сроки, не давать юридических гарантий, не обрабатывать персональные данные вне разрешённых систем;
• лимит на количество действий за сессию — чтобы зацикленный агент не создал 400 тикетов за минуту.

4. Обратная связь: как агент становится лучше

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

Как подходят разные платформы

Инструментов для сборки агентов много, и они закрывают разные части онбординга по-разному. Ниже — сравнение подходов на конец 2024 — начало 2025 года; конкретные лимиты и цены проверяйте на официальных страницах, они меняются часто.

Универсального лидера здесь нет: готовые ассистенты экономят недели разработки, но запирают вас в возможностях платформы; фреймворки дают контроль ценой инженерных часов.

Кому это пригодится и кому нет

Пригодится, если:

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

Не стоит начинать с агента, если:

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

Порядок действий на старте

1. Выберите один узкий сценарий, а не «всё сразу».
2. Соберите и вычистите базу знаний по этому сценарию.
3. Дайте агенту минимальные доступы, критичные действия — через подтверждение человека.
4. Пропишите границы и запреты в системном промпте.
5. Запустите в тестовом режиме на реальных, но неопасных задачах.
6. Раз в неделю разбирайте логи и правьте инструкции.

* Дата отсечки знаний (knowledge cutoff) — момент, после которого модель не знает о событиях: всё, что появилось позже, ей неизвестно, если не передать это в контекст.

** RAG (Retrieval-Augmented Generation) — подход, при котором модель перед ответом ищет релевантные фрагменты в вашей базе документов и опирается на них, а не только на обученные знания.

*** Дообучение (fine-tuning) — изменение весов модели на своих данных. Это отдельный процесс, не путать с пополнением базы знаний для RAG: разговоры с агентом веса не меняют.