Диагностика ИИ-агента без кода и поиск причины сбоя

Сложный ИИ-менеджер может вести десятки параллельных диалогов, обращаться к базе знаний, менять этап заявки и передавать клиента человеку. Но для собственника этого мало. Когда агент отвечает странно или внезапно замолкает, нужно сразу понимать, что произошло с конкретным обращением.

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

Задача

До доработки отдельные части одного обращения жили в нескольких workflow, CRM и технических логах. У каждого запуска был свой идентификатор. Жалоба бот замолчал после этой фразы еще не отвечала на главные вопросы:

какое обращение нужно открыть;
что агент получил и понял;
какое правило сработало;
ушло ли сообщение менеджеру;
что произошло после;
где искать точное место для исправления.

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

Одна фраза из чата открывает нужное обращение

Поддержка вставляет то, что уже есть у нее на руках - телефон, ссылку на диалог, ВК id, фрагмент сообщения или технический trace.

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

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

Вместо сырого журнала - человеческая причина

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

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

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

Что обнаружили на живом обращении

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

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

Это не демонстрационный сценарий. Причина была найдена на живом trace в рабочей Графане, а публичные изображения обезличены.

Один след через ИИ, CRM и ошибки

Входящее сообщение, контекст, решение ИИ, действия в CRM, отправленный ответ и ошибка получают один общий trace. Поэтому история не распадается на отдельные логи разных систем.

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

Логирование отправляется асинхронно и очищает секреты и тяжелые поля. Если диагностический сервис временно недоступен, это не должно останавливать разговор с клиентом.

Что проверено

поиск обращения по trace, ВК id, телефону, ссылке и части сообщения;
человеческий диагноз, решение системы и то, что произошло после;
единый trace через вход, контекст, ИИ, CRM, ответ и ошибку;
живой Телеграм-маршрут через семь связанных workflow;
рабочая панель Графаны на разных классах поведения агента;
переход от первого экрана к точному workflow и запуску для разработчика;
очистка секретов и тяжелых полей перед записью;
асинхронная отправка логов без блокировки рабочего диалога.

Результат

Сотруднику больше не нужно начинать с кода или пересказывать разработчику, что бот опять сделал что-то не то.

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

Система не исправляет сбои сама и не отменяет разработчика. Она разделяет роли нормально - команда понимает ситуацию на одном рабочем экране, а технический специалист подключается уже к найденной причине.

Граница публичного результата

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

Показанный результат подтвержден рабочим экраном Графаны, живыми traces и приемочными сценариями. Имена, телефоны, внутренние URL, идентификаторы запусков и сырые payload в публичные материалы не включены.