Трейсинг AI-агентов: где теряется контроль над сессией
Агент отвечает клиенту неверно — и узнают об этом только по жалобе. В интерфейсе виден финальный текст, в журнале приложения — успешный ответ сервиса, а между ними пусто: не записано, какие шаги выполнил агент, какие инструменты вызвал и на каком промежуточном решении свернул не туда. Разбор инцидента начинается с нуля и часто заканчивается фразой «воспроизвести не удалось».
Без трейсинга AI-агентов цепочка вызовов агента не сохраняется как единое целое. Запрос к поиску ушёл с одной формулировкой, в контекст попал устаревший документ, модель дважды переспросила саму себя — каждый шаг живёт в своём журнале или не живёт нигде. Сопоставить их по времени можно только вручную, и то если совпадают идентификаторы запроса, которых обычно нет.
Отсюда два следствия. Необъяснимый отказ невозможно отличить от сбоя внешнего сервиса: виноват поиск, промпт или сама постановка задачи — непонятно. И воспроизводимость сессии равна нулю: при повторе агент отвечает иначе, потому что не зафиксированы ни версия промпта, ни состав переданных документов, ни порядок вызовов.
Пока эти данные не пишутся, любая правка поведения агента — угадывание: стало лучше или просто повезло на другом наборе примеров. Дальше разбираем, как это закрывается — что именно попадает в трассу сессии, как по ней восстанавливается цепочка и как отличить деградацию модели от ошибки в инструменте.
Что даёт наблюдаемость цепочек вызовов инструментов
Без трейсинга агентная система ведёт себя как чёрный ящик: пользователь получил неверный ответ, внутри — десяток вызовов внешних сервисов, и какой из них дал сбой, непонятно. Воспроизвести ситуацию тоже не выходит: на том же запросе агент может повести себя иначе.
Наблюдаемость агентных цепочек фиксирует каждый шаг: какой инструмент вызван, с какими аргументами, что вернулось, сколько шаг занял и где цепочка оборвалась. Разбор инцидента превращается в чтение одной трассы вместо перебора гипотез по логам разных сервисов — время разбора сокращается с часов до минут.
Доля объяснённых отказов — вторая измеримая величина. Вместо «модель ошиблась» появляется причина: недоступность внешнего сервиса, обрезанный контекст, выбор не того инструмента, исчерпанный лимит шагов. Пока эта доля растёт, команда закрывает классы сбоев, а не отдельные случаи.
Повторяемость запусков делает результаты сравнимыми. Один и тот же набор запросов прогоняется на неизменной конфигурации, поэтому расхождения объясняются правками в системе, а не случайностью — версии до и после изменения сравниваются на одном срезе.
Отсюда вырастает контроль качества ответов: регрессионный набор запросов с ожидаемыми результатами, доля корректных ответов, число шагов на запрос. Правка системной инструкции или подключение нового инструмента проверяется на наборе до выката — деградация видна заранее.
Трейсинг AI-агентов: сравнение режимов сбора данных
Режим сбора данных определяет, что вообще попадёт в трассу, и его выбирают до внедрения, а не после первого разбора инцидента. Ниже — варианты, между которыми реально выбирают инженерные команды, с их применимостью и ограничениями.
| Режим | Когда подходит | Ограничения подхода |
|---|---|---|
| Перехват вызовов в коде агента | Свой код: есть доступ к обёрткам вокруг моделей, инструментов и обращений к памяти | Видит только инструментированные участки; при рефакторинге обёртки нужно поддерживать, иначе шаги выпадают из трассы |
| Пограничный слой на периметре | Закрытые и сторонние сервисы: нужен независимый след без правок их кода | Фиксирует лишь сетевой обмен — внутренние шаги, состояние памяти и промежуточные решения остаются вне журнала |
| Разбор журналов приложений | Наследие и сервисы без доступа к коду, где другого источника нет | Задержка между действием и записью; связи между шагами восстанавливаются по догадкам, а правила разбора ломаются при смене формата |
По разборам крупных сбоев Google SRE больше половины инцидентов связано с изменениями и неполной наблюдаемостью — поэтому на практике перехват вызовов и пограничный слой совмещают: первый даёт шаги агента изнутри, второй — независимую проверку того, что ушло за периметр.
Разбор журналов оставляют как страховку для сервисов, куда иначе не заглянуть, и как второй источник при сверке. Главное ограничение любого режима — неполнота: если шаг не записан, восстановить его постфактум нельзя, поэтому состав данных фиксируют на этапе проектирования трассы.
Этапы внедрения: от аудита сессий до передачи регламентов
Трейсинг AI-агентов не включается одним переключателем: события рождаются в разных местах — в вызовах модели, обращениях к инструментам, пользовательских сессиях. Поэтому внедрение идёт этапами, и каждый заканчивается артефактом, который можно проверить.
- Обследование систем. Инвентаризируем сервисы, очереди и внешние вызовы, находим места, где теряется идентификатор сессии. На выходе — карта потоков и перечень точек, которые нужно инструментировать.
- Схема сбора. Согласуем структуру события: обязательные поля, корреляция по идентификатору сессии, что семплируем и что храним целиком. Отдельно решаем, где обезличиваются персональные данные — до записи, а не после.
- Настройка. Поднимаем приёмник событий, подключаем агентов и инструменты, задаём срок хранения и разграничение доступа. Проверяем, что запись не удлиняет ответ агента.
- Проверка на реальных сценариях. Прогоняем типовые и аварийные цепочки: отказ инструмента, таймаут, повторный вызов, петля в рассуждении. Каждый сбой должен читаться в трейсе целиком, а не фрагментом.
- Разбор инцидента вместе с командой. Показываем, как от аномалии в метриках дойти до конкретного шага агента за минуты. Это и есть проверка, что данные пригодны для работы.
- Передача регламентов. Отдаём описание полей, правила именования, политику хранения и порядок разбора инцидентов. Дальше команда ведёт систему сама, а мы подключаемся при изменении схемы.
Конфигурация и артефакты, которые остаются у заказчика
Передаём не отчёт, а рабочую конфигурацию: трейсинг живёт в вашем репозитории и разворачивается вашими же средствами доставки. Иначе через полгода ни инцидент не разобрать, ни детализацию записи изменить без внешней команды.
- Конфигурации сбора. Что агент пишет в трейс — вызовы инструментов, аргументы, ответы, ветвления, ошибки; уровень детализации и правила сэмплирования: часть обращений хранится целиком, остальные только метаданными.
- Схема потоков данных. От вызова агента до хранилища: где события пишутся, где агрегируются, сколько живут, что уходит во внешний контур, а что не покидает ваш.
- Правила доступа. Кто видит сырые трейсы целиком, кто только агрегаты и метрики; учётные записи берутся из вашего каталога пользователей, отдельный список не заводится.
- Маскирование полей. Персональные и чувствительные данные вырезаются на этапе сбора, до записи, а не чистятся постфактум: что не попало в трейс, то невозможно утечь.
- Инструкции для команды. Как прочитать трейс и найти корень сбоя, как добавить новый шаг агента в трассировку, как разобрать инцидент по шагам.
- Регламенты и оповещения. Пороговые значения по доле ошибок и времени ответа, панели мониторинга и правила оповещения хранятся как конфигурация, а не как ручные настройки в интерфейсе.
Всё перечисленное остаётся в вашем контуре, под вашим контролем доступа и с документацией на русском: развивать трейсинг сможет любой ваш инженер, а не только тот, кто его внедрял.
Кейс: разбор инцидента за часы вместо недель
Заказчик — продуктовая команда с диалоговым агентом, который обрабатывает обращения клиентов и сам вызывает внутренние сервисы: биллинг, доставку, проверку остатков. Восемь диалогов из десяти проходили штатно, но разбор оставшихся превращался в ручной перебор логов и переписку между поддержкой и разработкой.
Симптомы приходили в виде «агент ответил не то» или «заказ завис». Воспроизвести сбой удавалось примерно в каждом пятом случае: не сохранялось ни входных данных, ни последовательности вызовов, ни ответов внешних сервисов. Локализация причины занимала рабочие дни, а поддержка каждое обращение превращала в ручную реконструкцию диалога.
Что изменили
Мы связали каждый шаг агента — план, вызов инструмента, ответ модели — в единую трассу и привязали её к идентификатору обращения. Хранилище трасс развернули на Langfuse: поиск по диалогу, входным параметрам и коду ошибки появился сразу, без собственного интерфейса разбора. Вокруг трасс построили воспроизведение — инцидент прокручивается с теми же входами на изолированном контуре, включая записанные ответы внешних сервисов.
Метрики до и после
- Доля воспроизводимых сбоев: 20% → 85%.
- Время локализации причины: 2-4 рабочих дня → 2-4 часа.
- Ручная работа поддержки сократилась втрое: типовые обращения закрываются по трассе, без разработчика.
- Эскалаций к инженерам стало меньше вчетверо — остаются только те, где нужна правка кода или промпта.
Отдельно оставили запись неудачных прогонов: новый дефект теперь проверяется на накопленных трассах как на регрессионном наборе, поэтому повторное появление того же класса сбоя видно на этапе выката.
Что делать, если система уже работает без контроля?
Работающую систему не переписывают ради наблюдаемости. Первый шаг — поставить съём на границах: на входе запроса и на выходе ответа, там, где сервисы уже общаются по сети. Такой посредник фиксирует идентификатор запроса, вход, результат и время обработки, не вмешиваясь в сам обработчик, — поведение системы для пользователя остаётся прежним.
Дальше выбираем критичные сценарии, а не покрываем всё сразу. Это пути, где сбой дороже всего: оформление заказа, списание, выдача документа, обращение в поддержку. Их подключаем первыми, остальное — по мере того как стабилизируется поток данных и настраиваются правила хранения.
Включение идёт в две ступени. Сначала теневой режим: события только пишутся и ни на что не влияют — так проверяем, что контекст размечается полностью, а цепочка вызовов между сервисами не рвётся на нештатных ветках. Затем в сбор уходит часть трафика, метрики сверяются с логами приложения, и доля растёт только тогда, когда расхождение в пределах нормы.
Миграция без остановки: узлы подключаются по одному, переключатель включения живёт в конфигурации, а не в коде. Откат — это выключение сбора, а не развёртывание предыдущей сборки; если приёмник данных недоступен, запросы продолжают идти обычным путём. Порядок действий такой: опись вызовов, отбор критичных путей, съём на границах, сверка в теневом режиме, расширение охвата на остальные сценарии.
Технические сомнения: хранение, нагрузка, доступ
Сбор трассировки не должен становиться узким местом в диалоге с агентом: мы разводим горячий путь ответа и запись телеметрии. События уходят в локальный буфер и отправляются отдельным каналом, не блокируя генерацию; если приёмник недоступен, буфер переживает перезапуск и догоняет запись позже, а диалог продолжается в штатном режиме.
Хранение истории, обезличивание и доступ описываются политиками, а не правками в коде агента — правила меняются без пересборки. Ниже — ответы на то, что инженерные команды чаще всего уточняют перед стартом.
Сбор данных замедлит ответы агента?
Запись асинхронная: событие кладётся в неблокирующий буфер, отправитель шлёт их пакетами вне пути ответа. Отдельно замеряем вклад в отклик на профиле нагрузки заказчика до промышленного запуска — если он заметен, правим конфигурацию, а не миримся.
Как обезличиваются персональные данные?
Маскирование идёт на стороне агента, до записи: имена, контакты и документы заменяются идентификаторами по словарю соответствий. Словарь хранится отдельно, со своими правами и сроком жизни. В трассе остаётся структура диалога и решения агента, но не чувствительный контент.
Сколько хранится история и можно ли менять сроки?
Сроки задаются политиками по классам данных: полные трассы с содержимым живут ограниченное окно, агрегаты и метрики качества — дольше. Политику меняют без пересборки агента, а по истечении срока данные удаляются автоматически.
Как разграничивается доступ к трассам?
Роли определяют глубину выдачи: инженер разбирает полную трассу, аналитик работает с агрегатами, руководитель — со сводной панелью. Любое чтение трассы попадает в журнал доступа, чувствительные поля скрываются на уровне выдачи.
Что если сбор нужно приостановить или откатить политику?
Трейсинг включается флагом конфигурации: сбор отключается без выпуска новой версии агента, агент работает как обычно, история просто не пишется. Откат — возврат предыдущего профиля, уже записанные данные остаются доступными по тем же правилам.
Обсудим задачу: схема сбора и план внедрения
Чтобы посчитать объём работ, нам нужны исходные данные по вашему агенту: какие вызовы моделей и внешних инструментов он делает, где сейчас оседают логи и как они связаны между собой. Без этого схема сбора трейсинга получится умозрительной, а оценка — прикидочной. На первой встрече мы разбираем поток событий, отмечаем точки, которые нужно инструментировать, и договариваемся, что считаем успешным прогоном.
Со своей стороны приносим черновик схемы сбора: какие события фиксируем, что кладём в контекст шага, как связываем вызовы по идентификатору сессии, где храним и как отдаём в аудит. К нему — план внедрения по этапам, чтобы было видно порядок и зависимости.
Что полезно подготовить до разговора:
- перечень сценариев агента и его внешних вызовов — по ним строится карта трассировки;
- образцы текущих логов или выгрузок, даже неполных: по ним видно формат и пробелы;
- требования к сроку и глубине хранения: что нужно для разбора инцидента, а что для отчётности;
- роли и права доступа — кто читает трейсы, кто может выгружать, кто администрирует;
- ограничения контура: закрытый периметр, свои хранилища, запрет на вынос данных;
- точки интеграции: очереди, уведомления, системы инцидентов и дежурств;
- критерии приёмки — как вы поймёте, что прозрачность действительно появилась.
Следующий шаг — встреча на 40–60 минут: разбираем ваши вводные, показываем черновик схемы и возвращаемся с оценкой объёма работ и планом внедрения по этапам. Опишите задачу в двух-трёх абзацах — этого хватит, чтобы прийти подготовленными.
