Мониторинг AI-агентов: как ловить тихие сбои

Почему AI-агенты могут «молча» ошибаться

Представьте: ваш LangChain-агент работает без ошибок, логи чистые, трейсы в LangSmith выглядят идеально. Но клиент звонит и говорит, что цифры «какие-то странные». Две недели тихих сбоев, $2400 потраченных впустую на LLM — и вы узнаёте об этом только от заказчика. Знакомая ситуация? В этой статье разберём, почему стандартные инструменты мониторинга не видят семантических ошибок, и как построить систему, которая их ловит.

Проблема: трейсинг не равен корректности

Мы потратили много времени, чтобы сформулировать разницу: observability на уровне трейсов показывает, что сделал агент, но не правильно ли он это сделал. Наш агент вызывал верные инструменты, получал HTTP 200, никаких эксепшенов. Проблема была в том, что он начал извлекать неверный контекст для данных одного клиента и на его основе генерировал правдоподобные, но неверные ответы. На уровне трейса успешный и неуспешный запуски выглядели идентично: те же вызовы, те же коды ответов, та же задержка. Разница была только семантической — а её трейс не показывает.

Большинство инструментов в этой области (LangSmith, Langfuse, Helicone — все хороши) заточены под вопрос разработчика: сколько стоило, сколько времени заняло, была ли ошибка. Это правильный вопрос для отладки интеграций. Но он бесполезен для сценария, когда агент работает безупречно, но делает не то.

Что мы изменили: три ключевых решения

Мы построили внутренний инструмент (позже ставший AgentWatch), который подходит к мониторингу иначе. Вот три главных изменения.

1. Outcome как явное поле

Вместо того чтобы выводить «успех» из отсутствия ошибки, мы сделали outcome полем, которое вы устанавливаете вручную для каждого сеанса: success, error или unknown. Это звучит тривиально, но на практике заставляет вас на этапе записи решить, что значит «корректно» для данной задачи. Раньше это ручная разметка, позже — автоматизация, но поле существует и заполняется всегда.

import agentwatch

aw = agentwatch.init(
    api_url="https://agentwatch-api.up.railway.app",
    api_key="your-api-key"
)

# Оборачиваем агента
chain = aw.wrap(your_langchain_agent)
# SDK автоматически захватывает LLM-вызовы, вызовы инструментов, задержку и стоимость
# Outcome устанавливается вашей логикой оценки или вручную

2. Количество ретраев как сигнал, а не шум

Агент, который четыре раза молча повторяет вызов инструмента перед успехом, говорит вам нечто важное. В большинстве трейсеров эта информация зарыта глубоко в дереве. Мы сделали retry_count первоклассным полем для каждого события, чтобы по нему можно было фильтровать и строить алерты. «Сеансы, где любое событие ретраилось больше двух раз» — это однострочный фильтр, а не ручной просмотр трейсов.

3. Распределение стоимости по клиентам с самого начала

Если вы запускаете агентов для нескольких B2B-клиентов на общей инфраструктуре (типичная ситуация для агентств), вопрос «сколько это стоило» бессмыслен без уточнения «для какого клиента». Добавлять это постфактум — значит восстанавливать атрибуцию по неполным данным. Мы тегируем workspace_id на уровне API-ключа, так что каждый сеанс и событие привязаны к клиенту с момента создания.

Что удивило: клиентам не нужен дашборд

Мы дали одному клиенту доступ к сырым трейсам сеансов. Они ни разу их не открыли. Вместо этого им понадобилось нечто вроде ежемесячного отчёта: сколько сеансов выполнено, сколько это стоило, сработало ли, и — это был конкретный запрос — что-то, что можно показать собственному начальнику, не вдаваясь в понятие «трейс». Это принципиально другой артефакт, нежели дашборд. Это отчёт.

Существующие инструменты (LangSmith, Langfuse) созданы для команды, которая запускает агента, а не для клиентов этой команды. Там нет white-label PDF, потому что это не их use case. Если вы агентство, которое поставляет агентов другим компаниям, вопрос «что показать клиенту» оказывается одним из первых, и готового ответа на него не было.

Что ещё не решено

Несколько вещей, которые мы пока не осилили:

• Автоматическая оценка outcome. Ручная разметка не масштабируется. Использовать другую модель для оценки — значит доверять модели-судье, что та поймает то, что пропустила исходная модель. Это та же проблема в другом обличье.
• Мониторинг качества данных. Мусор на входе даёт уверенный мусор на выходе, который выглядит как здоровый запуск. Мы считаем, что это заслуживает такого же первоклассного внимания, как отслеживание outcome, но пока не внедрили.
• Атрибуция сэкономленных средств. Мы интегрировались с FiGuard для контроля бюджета на уровне вызова инструмента. Когда запрос отклонён из-за превышения лимита, мы показываем это как «сэкономлено» в отчёте клиента. Но корректный учёт через две системы, которые не проектировались совместно, — это отдельное приключение с верификацией вебхуков и общим словарём.

Что делать прямо сейчас

Если вы запускаете LangChain- или LangGraph-агентов в продакшене для клиентов и сталкивались с подобными проблемами, попробуйте начать с малого: добавьте явное поле outcome в свои логи, настройте алерт на количество ретраев и подумайте, как вы будете показывать отчёты клиентам. Мы сделали бесплатный тариф (500 сеансов/месяц) для тех, кто хочет протестировать наш подход: agentwatch-two.vercel.app. Будем рады обменяться опытом.