Агентная система поддержки

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

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

Мы собрали общий рабочий контур. Сотрудник формулирует задачу обычным языком — «разбери такое-то обращение». Дальше агент сам решает, какие источники нужны, и собирает минимально необходимый набор доказательств.

Не «все данные на всякий случай». Для правки текста хватает свежей конфигурации; для спорного диалога нужны факты о самом обращении; логи открываются последними — когда сценарий и аналитика проблему не объяснили.

Система различает подтверждённое и предполагаемое — это её главная настройка.

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

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

Отсюда следующий слой. Разница между черновиком и отправленным текстом — это и есть материал: система может учитывать редактуру конкретного человека вместо общей просьбы «сделай текст человечнее». Этот слой пока не сделан.

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

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

В одном из разборов клиент жаловался, что бот здоровается заново и отвечает то, чего не должен. Сценарий большой: 2674 слота в конфигурации.

Агент нашёл конкретный путь — восемь узлов от интента до перехода на LLM-агента, — а на входе условие, которое требует значения 1, тогда как в сценарии записан 0. Ветка, о которой спрашивал клиент, при такой конфигурации не выполняется.

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

2674 слота

агент нашёл нужную ветку и объяснил переход между агентами

0 вместо 1

условие входа в ветку не выполняется — это видно в самой конфигурации

54 слота разошлись

два экспорта подряд отличаются; расхождение показано, причина не выдумана

Четыре разных вида доказательств. Работа агента — не смешать их.

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

• конфигурация

  записанная логика: что сценарий делает по своему тексту

• данные

  наблюдаемое: что происходило в диалогах

• логи

  runtime: что делали сервисы в момент события

• документация

  ожидаемая семантика: как функция должна работать по правилам платформы

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

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

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

Неполнота видна

ограниченный обход возвращает признак неполноты, а не молча урезанный список

Выборка не транзакционная

обращения меняются во время чтения; спорный случай перечитывается

Только чтение

статусы, назначения и ответ клиенту этим путём не меняются — по устройству

Дальше разрешается цепочка: обращение → клиент → компания → проект → агент → канал.

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

После связывания читается накопленное по этому клиенту: заметки, прошлые разборы, сохранённые версии конфигураций.

Конфигурация выгружается комплектом: сама логика и карта соответствий между тем, как элемент записан в конфигурации, и тем, как он опознаётся в данных. Каждый снимок ложится в свой каталог со временем, автором, задачей и хешами. Старый снимок не перезаписывается никогда.

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

Текущая — не историческая

конфигурацию прошлого периода заменяет только сохранённый тогда снимок

Выгружено, правка, публикация

три разных состояния, и ни одно не доказывает другое

Расхождение не прячется

в одном разборе два экспорта подряд разошлись в 54 элементах из 2674 — это осталось в статусе карты

Пять продуктовых выгрузок. Агент заказывает не все пять, а те, что отвечают на вопрос.

• сводка выполнения

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

  агрегат не объясняет причину перехода конкретного диалога

• история сообщений

  что писали, какой смысл распознан, текст после предобработки

  нераспознанный смысл — признак, а не диагноз

• состояние переменных

  флаги и счётчики диалога

  снимок на момент выгрузки, а не журнал событий за период

• точки остановки

  на каких элементах диалоги заканчиваются

  остановка сама по себе не ошибка

• матрица диалогов

  какие элементы выполнялись в каждом диалоге

  точный порядок переходов из матрицы не восстанавливается

Сутки режутся по UTC

для клиентских суток сдвиг задаётся явно, иначе окно поедет

Условия сохраняются рядом

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

Когда агрегата мало, агент спускается к SQL — через API источников данных Grafana.

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

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

Это и есть разница между разговором о поведении бота и доказательством: наблюдаемое production-поведение связывается с конкретным местом конкретной версии исполняемого сценария.

Сообщения — не журнал

наличие сообщений не означает полного журнала прохождения сценария

Время не задаёт порядок

совпадающие отметки времени не выстраивают последовательность

Чат — не диалог

чат без подтверждённого идентификатора сессии не гарантирует одну беседу

Покрытие проверяется

история доступна не за любой период; отсутствие периода записывается как ограничение

Глубже — пока задача

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

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

Логи — не первый шаг и не универсальный ответ. Они подключаются, когда конфигурация выглядит корректной, отчёты не объяснили наблюдение, SQL не дал достаточного ответа — или когда проблема очевидно runtime: коннектор, внешний запрос, модель, доставка.

Поиск узкий: известный период, конкретный идентификатор, конкретный компонент и сформулированная гипотеза. Глубина хранения ограничена и проверяется фактически: рабочее окно измеряется десятками часов, а не месяцами. Для более старых дат остаются отчёты и SQL — и это часть маршрута, а не досадное ограничение.

Confluence и Slack легко записать в «ещё два источника». Они отвечают на разные вопросы, и смешивать их нельзя.

И отдельно: тишина в канале не доказывает, что всё работает. Непрочитанный канал не доказывает, что обсуждения не было.

Confluence

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

Slack

обсуждалось ли это, был ли известный инцидент или договорённость. Контекст, а не источник истины о поведении production

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

Перед записью состояние перечитывается, устаревшее предложение отклоняется. Уникальный идентификатор записи не даёт списать одно и то же дважды. Если после записи подтверждение не пришло — это неопределённый результат, а не разрешение повторить.

Тем же образцом позже строится отправка ответа клиенту: черновик, проверка, применение, сверка. Возможность писать не превращается в право писать.

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

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

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

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

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

Знание живёт вне чата

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

Версии не перезаписываются

старые снимки и заметки остаются на месте

Система уже работает в настоящих обращениях, и её результат дошёл до клиента.

Процентов экономии времени здесь не будет: их никто не измерял. Перечисленное — то, что можно проверить.

Ей пользуются

сотрудники разбирают в ней реальные обращения

Разбор из многих источников

тикет, структура клиента, конфигурация, аналитика, логи — в одной задаче

Ответ дошёл до клиента

и клиент отдельно отметил качество объяснения

Разбор чинит инструмент

по ходу работы нашлись и исправлены две ошибки чтения данных, 25 локальных проверок

Знание остаётся

каждый разбор пополняет папку клиента

Мы автоматизируем не отдельное действие, а работу вокруг человека.

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

Как это собиралось — запись «Собрал поддержку в папку» на nikeshin.space.