Сложный тикет редко начинается с самой ошибки.
Сначала надо понять, чей это бот. Потом какой агент. Через какой канал он работает. Найти актуальный конфиг. Понять, что происходило в диалоге. Выгрузить аналитику. Если ответа всё ещё нет, идти в логи и пытаться восстановить цепочку событий.
При следующем похожем тикете часть этого пути проходится заново.
Я решил собрать этот контекст в одном месте.
Получился внутренний support kit, который можно открыть как рабочую папку в Claude Code и начать разбор с одного файла: INSTRUCTION.md.
Не агент вместо саппорта
Мне не хотелось делать ещё одного бота, которому кидаешь тикет и надеешься, что он что-нибудь придумает.
Задача была другой: дать агенту тот же рабочий контекст, который постепенно появляется у опытного сотрудника поддержки.
Поэтому внутри кита есть несколько слоёв.
Первый — карта платформы. Она связывает клиента, проект, агента, канал и рабочий контур. По тикету можно довольно быстро перейти от названия клиента к конкретному боту, с которым придётся разбираться.
Второй — папки проектов. У каждого проекта есть собственные заметки, конфиги и результаты предыдущих исследований. Новый тикет не начинается с чистого листа.
Третий — аналитика. Агент может сам запросить нужную выгрузку, дождаться её формирования и положить рядом с проектом.
Четвёртый — логи. Для типовых проблем есть runbook: где искать недоставленное сообщение, ошибку внешнего запроса, проблему с LLM, переводом на оператора или подключением бота.
Получается довольно простой маршрут:
тикет → бот → конфиг → аналитика → логиА не:
тикет → открыть восемь вкладок → вспомнить, как мы это делали месяц назадСначала сценарий, потом инфраструктура
Одна из вещей, которую я специально зафиксировал в процессе: не надо начинать каждый странный кейс с Kibana.
Сначала конфиг и аналитика.
Если бот пошёл не по той ветке, дважды выполнил слот или получил неожиданное состояние, проблема часто уже видна там. Логи нужны, когда становится понятно, что сценарий отработал правильно, а дальше что-то случилось с каналом, внешним запросом или платформой.
Это кажется мелочью, но меняет сам способ расследования.
Вместо поиска ошибки во всей системе мы постепенно сужаем пространство: что произошло → что должен был сделать сценарий → сделал ли → если сделал, куда событие ушло дальше.
Память важнее промпта
Самая интересная часть получилась случайно.
После каждого разобранного кейса в проекте остаются заметки, конфиги, найденные особенности и рабочие способы диагностики.
То есть следующий разбор начинается уже не с общей документации ChatMe. Он начинается с того, что команда действительно узнала об этом конкретном проекте.
Чем больше через систему проходит реальной работы, тем полезнее становится её контекст.
По сути, я перестал пытаться написать агенту идеальную инструкцию и начал собирать для него рабочую память.
И немного паранойи
В саппорте эта схема быстро упирается в неприятную деталь: реальные данные.
В диалогах могут быть имена, телефоны и другие чувствительные данные. В конфигах бывают секреты интеграций.
Поэтому маскирование я сделал частью самого процесса, а не просьбой «не забудьте перед отправкой». Перед чтением определённых файлов агентом срабатывает хук и подменяет файл его маскированной копией. Если маскирование ломается, исходник не должен просто тихо улететь модели.
Внешние действия тоже отделены от исследования: прочитать тикет и исследовать проблему можно автоматически, а ответ клиенту или изменение состояния требуют явного подтверждения.
Мне кажется, для рабочих агентов это важнее очередной демонстрации того, насколько автономно они умеют нажимать кнопки.
Что получилось
Сейчас это всё ещё первая рабочая версия. Там остаются шероховатости, часть интеграций ещё не закончена, а какие-то знания наверняка придётся переписывать после первых недель использования.
Но принцип уже работает:
Не давать модели больше интеллекта. Дать ей нормальную среду для работы.
И, кажется, именно этого мне всё время не хватало в разговорах про AI-агентов.