Мониторинг AI-агента: что записывать, за чем следить и когда останавливать

Мониторинг AI-агента: почему недостаточно проверки «сервер жив»

Обычная программа ломается заметно: упала, вернула ошибку. Агент ломается тихо. Сервер отвечает, интеграции подключены, задачи закрываются, а ответы стали хуже: в 1С поменяли справочник, клиенты заговорили про новую акцию, поставщик обновил модель. Причины мы разбирали в статье почему агент деградирует без сопровождения. Здесь речь о том, как заметить их вовремя.

В англоязычных источниках это называют observability, по-русски говорят «наблюдаемость LLM-приложений»: возможность по записям системы восстановить, что она делала и почему. На практике это три слоя.

Мониторинг не заменяет тесты. Тест-набор показывает, что агент умел на момент запуска (как оценить качество AI-агента), мониторинг — что происходит на живом потоке, который набор не предусмотрел. Без тестов правки делают наугад, без мониторинга о проблеме узнают от клиента.

Что логировать при работе AI-агента: запись, по которой можно разобрать любой случай

Основа — трассировка: запись всей цепочки одной задачи от запроса до итога под сквозным номером. Если нельзя ответить на вопрос «почему агент так сделал», остаются догадки. Минимальный состав записи:

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

Журнал пишет код системы, а не модель: просьба «отчитывайся о своих действиях» не гарантирует полного отчёта. Записи структурные, иначе по ним не построить выборки и графики. Отдельно ведут журнал изменений: правка инструкции, модели, инструментов или базы знаний с датой, автором и результатом прогона тестов. Так видно, после какой правки показатель сдвинулся.

Чего не логировать и как долго хранить журнал

Журнал легко становится каналом утечки: в нём тексты клиентов, телефоны, содержимое документов. Что не писать, решают до запуска.

• Секреты. Ключи, токены и пароли не попадают ни в запрос к модели, ни в журнал: инструмент подставляет их кодом, в записи остаётся метка (безопасность AI-агентов).
• Лишние персональные данные. Телефоны, почту, паспортные и платёжные реквизиты заменяют метками до записи, а не после. Если для разбора хватает номера заказа, полный документ в журнале не нужен, только ссылка на него.
• Всё «на всякий случай». Каждое лишнее поле — риск и расход на хранение. Состав записи согласуют со службой безопасности заранее.

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

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

Алерты для AI-агента: какие сигналы что значат и когда тревожить

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

Чтобы алерты не стали шумом:

• Коридор, а не число. Пока базовой линии нет, ставят защитные лимиты (шаги, время, расход), а «норму» определяют по пилоту.
• Два вида. Немедленные: ошибки инструментов, лимиты, всплеск расхода, жалоба на опасное действие. Трендовые идут в недельную сводку, чтобы не будить инженера.
• У каждого алерта владелец и действие. Алерт, на который никто не обязан реагировать, через месяц отключают, и контроль теряется вместе с ним.
• Одной метрики мало. Если следить только за долей задач без человека, появляется соблазн отвечать уверенно любой ценой. Пара «без человека» и «правки с жалобами» это сдерживает.

Панель мониторинга AI-агента: что видит владелец процесса, а что инженер

Один экран на двоих не получается.

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

Выборочная проверка диалогов: что не видно в метриках

Метрики не замечают уверенных ошибок: агент ответил складно, клиент ушёл, в журнале «решено». Это самый опасный тип ошибки (галлюцинации ИИ в бизнесе), и находит его только человек, который читает. Что читать:

• случайные диалоги из всего потока, в том числе «хорошие»;
• диалоги с жалобами и отметкой «не помогло»;
• случаи, где человек поправил черновик агента;
• задачи, остановленные лимитом;
• обращения на темы, которых нет в базе знаний.

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

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

Разбор сбоя: как неудачный случай превращается в тест

Каждая найденная ошибка идёт одним путём:

1. Найти задачу по номеру и открыть трассу.
2. Воспроизвести на сохранённых входах и ответах инструментов в тестовой среде, чтобы повторное письмо не ушло клиенту. Запускать несколько раз: модель может отвечать по-разному, один прогон ничего не доказывает.
3. Определить причину: данные, инструкция, инструмент или модель. От неё зависит, кто правит.
4. Записать верный итог. Эталон пишет владелец процесса, а не тот, кто чинит.
5. Добавить в тест-набор, исправить и прогнать весь набор, чтобы правка не сломала другое.
6. Выкатить, записать в журнал изменений и понаблюдать за метрикой.

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

Инцидент с AI-агентом: выключатель, откат и разбор

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

1. Остановить. Выключатель (переключатель в интерфейсе, отзыв ключей на вашей стороне) или режим «только черновики»: агент готовит решения, но ничего не исполняет. Ждать звонка подрядчику не нужно; кто вправе нажать, записано, и выключатель проверяли на учениях.
2. Сохранить картину. Журнал и трассы не правят.
3. Откатить. Инструкция, инструменты и база знаний версионируются, возврат должен быть одним действием. С моделью сложнее: где поставщик позволяет, фиксируют версию; если он заменил модель без вас, откатить нельзя, остаётся подстраивать инструкцию или менять модель (как выбрать модель).
4. Исправить последствия: письма, записи, документы. Решить судьбу очереди, чтобы задачи не терялись и не исполнялись «вслепую».
5. Найти причину, оформить тестом, включить и понаблюдать.
6. Разобрать без поиска виноватых: какой алерт должен был сработать и почему не сработал.

Про ответственность — кто отвечает за ошибку AI-агента, про точки согласования — human-in-the-loop, про защиту вокруг модели — безопасность агентов.

Контроль расходов на модель по журналу

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

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

Кто дежурит: роли и стоимость мониторинга

Мониторинг без людей — это письма, которые никто не читает. Нужны три роли.

• Владелец процесса (у вас): читает сводку и диалоги, пишет эталоны, решает, где граница полномочий агента.
• Инженер сопровождения: реагирует на алерты, разбирает сбои, правит инструкцию и инструменты, прогоняет тесты.
• Владелец доступов (у вас): ключи, выключатель, журнал, срок хранения.

Инженерную роль можно закрыть своими силами, если есть человек, который понимает устройство агента и выделяет на это регулярное время; мы передаём документацию и обучаем. Или отдать в сопровождение: от 40 000 ₽/мес, минимальный срок после запуска — 6 месяцев, он фиксируется в договоре; мониторинг и разбор ошибок входят, состав описан в статье про сопровождение агента. Обращения к модели и железо считаются отдельно.

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

Минимальный набор мониторинга к запуску пилота

• Журнал шагов с версиями, стоимостью и итогом; запись ведёт код.
• Согласованы маскирование, срок хранения и круг доступа.
• Защитные лимиты: шаги, время, расход на задачу и на сутки.
• Несколько алертов из таблицы, включая «тишину», у каждого владелец.
• Панель для владельца и недельная сводка.
• Расписание чтения диалогов и анкета.
• Выключатель, проверенный на учениях.
• Путь «ошибка → тест-набор → регрессия» и журнал изменений.

Это закладывается при проектировании и записывается в техническое задание, а не дорабатывается после первой жалобы. Глубина зависит от размера агента: в пилоте панель может быть простым отчётом по журналу, а алертов — всего несколько; что именно входит, фиксируется в смете и техзадании. Для мультиагентных систем то же, плюс сквозной номер и запись передач между агентами. Как строим работу целиком — на странице разработки AI-агентов.

Агент, за которым никто не наблюдает, не автономный, а бесхозный.