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

Где агенту нужен поводок
Контроль нужен не везде. Чтение базы знаний, классификация обращения и черновик письма обычно можно автоматизировать. Отправка клиенту, изменение сделки, деньги, удаление записи и юридическое заключение требуют явного подтверждения человеком.
хорошая пробная версия фиксирует эти границы в матрице действий: что агент делает сам, что предлагает, что только объясняет и где обязан остановиться. Да, это скучная таблица. Зато потом никто не ищет, кто сломал процесс.
- только чтение: поиск, анализ, резюме, классификация
- режим черновика: письма, задачи, CRM-комментарии, отчёты
- режим подтверждения: отправка, изменение статусов, финансовые действия
Логи нужны не только разработчикам
Руководителю процесса важно видеть, почему агент предложил действие, какие источники использовал и где оператор его поправил. Это превращает пробную версию в обучаемую систему, а не в чёрный ящик с приятным интерфейсом.
В минимальный журнал действий включите входной запрос, выбранные инструменты, найденные источники, итоговый ответ, уверенность модели или причину отказа и решение человека. Потом это будет ваша карта улучшений.
Хотите проверить это на своих данных? Разберём задачу бесплатно и скажем, стоит ли браться.
Начинайте с карты действий
Перед разработкой агента полезно выписать не функции, а действия процесса. Например: прочитать карточку клиента, найти похожие обращения, подготовить ответ, создать задачу, изменить статус сделки, отправить письмо, приложить документ. Для каждого действия нужно указать риск, владельца, источник данных и режим выполнения.
Так появляется простая матрица: агент может читать, может готовить черновик, может предложить действие, но не может выполнять его без подтверждения. Эта матрица важнее красивого промпта. Она защищает от ситуации, когда агент случайно получает слишком широкий доступ и начинает делать то, что никто не согласовывал.
- чтение: безопасное чтение данных и поиск контекста
- Черновик: подготовка письма, задачи, резюме или CRM-комментария
- commit: действие только после подтверждения человека
Вызов инструментов: где ломается агент
Агентные ошибки часто выглядят не как плохой текст, а как неправильный вызов инструмента. Модель выбрала не ту функцию, передала неполные аргументы, не проверила результат, повторила вызов или не поняла, что инструмент вернул ошибку. Поэтому тестировать нужно не только финальный ответ, но и весь trace.
В пробной версии стоит хранить цепочку: намерение пользователя, выбранный инструмент, аргументы, ответ инструмента, промежуточное рассуждение в безопасной форме, итоговое действие и решение оператора. Тогда команда видит, что исправлять: описание инструмента, валидацию аргументов, права доступа, fallback или сам маршрут.
Проверка человеком не должен быть ручным костылём
Контроль человека часто делают слишком грубо: агент всё равно готовит ответ, а оператор просто перечитывает весь результат с нуля. Это не экономит время. Нормальный проверка человеком показывает оператору, что изменилось, какие источники использованы, где низкая уверенность и какое действие предлагается.
Хороший интерфейс контроля должен сокращать проверку. Оператор видит: «найдены такие документы», «предлагаемый ответ», «риск: нет подтверждения по цене», «нужно выбрать один из вариантов». Если человек каждый раз заново расследует ситуацию, значит агент не встроен в процесс, а просто добавил ещё один экран.
- показывайте источники и причины выбора
- подсвечивайте низкую уверенность и конфликт данных
- собирайте правки оператора как обучающие сигналы
Как измерить агентная пробная версия
Для агента недостаточно метрики «ответ понравился». Нужны показатели маршрута: сколько шагов он выполнил правильно, где запросил подтверждение, сколько раз вызвал инструмент, сколько ошибок инструментов обработал, сколько действий оператор принял без правки и сколько отклонил.
Ещё одна важная метрика - containment без риска. Это доля задач, которые агент довёл до безопасного результата в разрешённом режиме. Например, подготовил карточку заявки и черновик follow-up, но не отправил письмо сам. Такая автоматизация уже может экономить время, даже если критичные действия остаются за человеком.
Порядок внедрения без героизма
Практичный путь: сначала агент читает данные и делает резюме, затем готовит черновики, затем создаёт задачи в безопасном режиме, затем получает ограниченный доступ к действиям с подтверждением человеком. На каждом этапе нужны тесты, логи и понятный откат.
Если процесс критичный, полезно запускать агента в shadow mode: он предлагает действие, но сотрудник работает как обычно. Через неделю можно сравнить, где агент совпал с человеком, где ошибся и какие правила нужны перед реальным запуском.
Что сделать дальше
- Начинайте с узкого маршрута: заявка, документ, тикет, отчёт. Не надо сразу строить цифрового директора.
- Разделяйте чтение данных и действия, которые меняют состояние систем.
- Логируйте инструмент calls, источники, промпты и решения оператора.
Вывод
Резюме: автономность надо добавлять постепенно. Сначала поиск и черновики, потом контролируемые действия, и только после накопления логов - больше самостоятельности.

