Старые продуктовые метрики не видят ИИ-агента: как завести журнал запусков
Продуктовая аналитика долго жила вокруг действий человека: визит, клик, сессия, экран, шаг воронки, конверсия. Это удобно, пока пользователь сам нажимает кнопки и оставляет след в интерфейсе.
С ИИ-агентом картина меняется. Агент может за один запуск прочитать письмо, открыть документ, сравнить данные, подготовить ответ, изменить карточку, собрать отчет или предложить правку. Для старого дашборда это может выглядеть как одна сессия, один API-вызов или вообще как технический шум. Для бизнеса это уже действие, которое надо понимать, проверять и иногда останавливать.
Поэтому вопрос не только в том, сколько людей пользуется агентом. Вопрос точнее: видно ли, что именно сделал агент, почему он это сделал, какой артефакт оставил и кто принял итог.
Почему клик, сессия и воронка плохо описывают агента
Клик фиксирует жест. Сессия фиксирует присутствие. Воронка фиксирует путь человека к целевому действию. Но агент не всегда идет по экранному пути. Он может работать через файлы, API, почту, CRM, репозиторий, таблицу, задачу или внутренний инструмент.
Если смотреть только на старые метрики, легко пропустить главное. Агент мог сократить ручную работу, но не создать новый клик. Агент мог подготовить хороший черновик, но человек его не принял. Агент мог выполнить действие быстро, но без достаточного контекста. Агент мог изменить данные, а продуктовый отчет покажет только рост активности.
Старая аналитика отвечает на вопрос: что пользователь сделал в продукте. Для агентного процесса нужен второй слой: что агент сделал от имени процесса и как это было проверено.
Что полезного дает сигнал из очереди @alexkrol
В очереди @alexkrol есть точная боль: аналитика строилась вокруг кликов, сессий и воронок, а теперь появляется агент, для которого предлагают считать запуск новой единицей наблюдения. Это не статистика, которую надо повторять как доказанный факт. Это хороший редакционный сигнал: старые приборы не всегда подходят для нового типа действия.
Для ONFF здесь важен практический вывод. Если агент входит в рабочий процесс, его нельзя оценивать только через обычный продуктовый дашборд. Нужен журнал запусков, где видно не красивую активность, а цепочку ответственности.
Запуск агента должен быть похож не на анонимный технический вызов, а на понятную строку дела: была цель, был вход, было действие, был результат, была проверка, было решение.
Что в этом подтверждает документация Codex
Документация Codex постоянно возвращает к нескольким рабочим принципам. Задаче нужен контекст: цель, важные файлы или данные, ограничения и критерий готовности. Повторяющиеся правила лучше выносить в AGENTS.md, чтобы агент видел стандарты проекта. Результат нужно проверять через tests, review, diff, логи и понятные evidence. Права, sandbox и approval policy задают границу: что агент может делать сам, а где должен остановиться и попросить человека.
Это легко перевести из разработки в продуктовую аналитику агента. Если агенту нужен контекст и критерий готовности, значит запуск должен фиксировать, какой контекст был дан и по какому критерию результат принят. Если есть review, значит в журнале должен быть статус проверки. Если есть approvals, значит в журнале должно быть видно, какие действия были автоматическими, а какие требовали решения человека.
Так появляется не абстрактная метрика "агент активен", а управляемый контур.
Какие события нужно логировать у агента
Минимальный журнал не должен быть сложным. Важно, чтобы по нему можно было восстановить смысл запуска.
| Поле | Что фиксировать |
|---|---|
| run_id | Уникальный номер запуска, чтобы можно было найти следы |
| цель | Какую задачу агент пытался решить |
| вход | Какие данные, документы, сообщения или задачи были переданы |
| действие | Что агент сделал: прочитал, сравнил, изменил, подготовил, отправил |
| объект | Где изменилось состояние: CRM, таблица, файл, пост, задача, письмо |
| evidence | Ссылка на diff, отчет, лог, черновик, скриншот или проверяемый артефакт |
| риск | Что могло пойти не так и насколько это критично |
| review | Кто или что проверило результат |
| решение | Принято, отклонено, нужен ручной разбор, остановлено |
Такой журнал не заменяет продуктовую аналитику. Он добавляет слой, которого раньше не было: наблюдение за работой агента как исполнителя.
Какой артефакт попросить у Codex
Не просите Codex "придумать метрики для агента" в общем виде. Лучше дать конкретный процесс и попросить собрать карту запусков.
Рабочий запрос может звучать так:
Разбери этот агентный сценарий и составь agent run ledger. Для каждого запуска укажи цель, входные данные, разрешенные действия, изменяемый объект, ожидаемый артефакт, evidence, риск, проверку, статус принятия и решение человека. Отдельно отметь действия, которые нельзя выполнять без approval.
На вход стоит дать описание сценария, примеры задач, список доступов, критерий готовности, риски и несколько последних запусков. Если уже есть AGENTS.md, правила процесса, тесты или чек-листы, их тоже нужно приложить.
Хороший результат от Codex здесь не эссе, а таблица, по которой можно принять управленческое решение.
Как проверить журнал без программирования
Проверка простая. Откройте последние 5-10 запусков и попробуйте объяснить каждый запуск обычным языком.
Если видно только "успешно" или "ошибка", журнал слабый. Если неясно, какие данные агент видел, журнал слабый. Если нет ссылки на артефакт, вы не можете проверить результат. Если действие изменило важный объект, но нет review, это риск. Если агент отправил что-то наружу без approval, это уже не аналитическая проблема, а проблема управления.
Хороший журнал отвечает на пять вопросов:
- что агент пытался сделать;
- на каком входе он работал;
- что изменилось после запуска;
- где доказательство результата;
- кто принял или отклонил итог.
Если эти вопросы закрыты, запуск можно обсуждать предметно. Если нет, агент работает внутри тумана, даже если дашборд показывает рост активности.
Практическая карточка agent run ledger
Перед тем как давать агенту больше прав, заведите короткую карточку.
Сценарий: какую повторяющуюся работу агент выполняет.
Run ID: как найти конкретный запуск.
Вход: какие данные, документы или сообщения были переданы.
Правила: какие инструкции, AGENTS.md, чек-листы или ограничения применялись.
Действие: что агент сделал сам, а что только предложил.
Изменение состояния: какой объект был создан, изменен, опубликован, отправлен или удален.
Evidence: где лежит проверяемый результат.
Review: кто проверил и по какому критерию.
Approval: какие действия требовали человека.
Решение: принять, повторить, сузить права, отправить на ручной разбор или остановить сценарий.
Так продуктовая аналитика перестает быть только счетчиком кликов. Она становится системой наблюдения за агентной работой: не просто "агент что-то сделал", а "мы понимаем запуск, видим доказательство и знаем, кто отвечает за решение".