Агентский ИИ в компании: семь направлений, которые стоит проверить на практике

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

1. Агент становится частью команды процессов

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

2. Интеграции требуют понятных границ

MCP задаёт общий способ подключать ИИ-приложения к данным и инструментам. Это упрощает работу с каталогом, CRM или файлами, но подключение сервера ещё не делает процесс безопасным. Для каждого инструмента заранее определите: какие данные доступны, какие действия разрешены, что агенту запрещено делать и кто видит журнал.

3. Масштабирование начинается с пилота

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

4. Человек остаётся контрольной точкой

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

5. Стоимость тоже проектируют

Сначала фиксируйте объём: сколько запросов, какие документы, сколько минут проверки. Сложное планирование можно поручить сильной модели, а классификацию, извлечение полей и проверку формата — более экономичной. Кэшируйте повторяющийся контекст и просите структурированный результат: это упрощает проверку и последующую автоматизацию.

6. Память процесса должна иметь источник

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

В сводке по лидам это выглядит просто. Каждая карточка содержит идентификатор исходной записи, дату выгрузки и версию классификатора. Менеджер может открыть запись и понять, почему заявка получила свой статус. Пустое поле помечается как неизвестное; догадка получает отдельную метку.

7. Передача человеку входит в сценарий

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

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

От пилота до рабочего контура

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

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

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

Три уровня архитектуры

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

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

Что измерять

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

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

Типичные ошибки

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

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

Промпт для выбора пилота

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

Промпт для проверки агента

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

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

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

Источники

#Автоматизация #Практикум #Роман Ботан