Как разработать ИИ-агента для бизнеса и проверить его до запуска

1. Начните с одного процесса и измеримого результата

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

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

2. Определите границы агентности

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

Заполните паспорт процесса:

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

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

3. Выберите между автоматизацией, чат-ботом и агентом

Используйте простое разделение.

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

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

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

Граница должна быть практической: агент не должен получать автономность только потому, что задача называется «ИИ». В описании OpenAI Agents SDK агент представлен как модель с инструкциями, инструментами, guardrails и handoffs; среди возможностей также указаны участие человека, сессии и трассировка. Это характеристики фреймворка, а не доказательство того, что конкретная CRM или учётная система уже подключена.

4. Спроектируйте инструменты, роли и контроль человека

Спроектируйте контур до написания кода или настройки платформы.

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

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

Маршрутизация. Задайте условия, при которых запрос остаётся в текущем сценарии, передаётся другому специализированному контуру или уходит сотруднику. В Agents SDK handoffs описаны как передача задачи между агентами; в бизнес-проекте это нужно дополнить конкретными правилами ответственности.

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

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

5. Подготовьте данные, интеграции и доступы

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

Для систем бизнеса составьте карту доступа:

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

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

6. Проведите пилот на контрольной выборке

Для пилота составьте тестовую матрицу до просмотра результатов агента. Включите как минимум:

1. обычный полный вход;
2. отсутствие обязательного поля;
3. неоднозначное совпадение;
4. противоречивые сведения;
5. повторное поступление того же события;
6. отказ в доступе;
7. недоступность внешнего сервиса;
8. потерю ответа после операции записи;
9. запрос вне согласованной области.

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

Разделяйте три проверки: качество итогового результата, корректность вызовов инструментов и фактическое состояние системы. Сообщение «запись создана» не доказывает, что объект действительно появился. Если результат операции неизвестен, сначала проверьте состояние по идентификатору, если это предусмотрено интеграцией; иначе остановите повтор и передайте случай человеку.

7. Зафиксируйте качество и критерии допуска

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

Используйте показатели с понятным знаменателем:

• успешные прогоны / все запланированные прогоны;
• вызовы с допустимым инструментом и параметрами / все вызовы;
• корректные эскалации / случаи, где эскалация предусмотрена;
• критичные ошибки, дубли и неподтверждённые записи;
• время до проверенного результата.

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

8. Решите, масштабировать ли разработку

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

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

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