Теневой режим AI-агента: проверка на реальном потоке без исполнения

Что именно мы проверяем

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

После завершения задачи предложение агента сопоставляют с фактическим решением процесса. Это помогает ответить на три практических вопроса:

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

Минимальная схема

реальный вход ──┬──> действующий процесс ──> фактическое решение
                │
                └──> копия/событие ──> теневой агент ──> журнал предложений
                                                   
фактическое решение + предложение ──> сопоставление и разбор

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

Шаг 1. Зафиксируйте единицу сравнения

Выберите один ограниченный процесс, где есть наблюдаемый вход и итог. Например, классификация обращения в одну из заранее определённых очередей. Это лишь пример: категории и критерии следует взять из вашего процесса.

До запуска создайте контракт записи:

{
  "case_id": "стабильный_идентификатор",
  "observed_at": "2026-07-29T10:15:00Z",
  "input_version": "версия_снимка",
  "agent_version": "shadow-router-0.1",
  "prompt_version": "router-3",
  "proposed_action": "QUEUE_A",
  "confidence": 0.74,
  "reason_code": "TOPIC_A",
  "actual_action": null,
  "actual_at": null,
  "eligible_for_comparison": true
}

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

Шаг 2. Определите границы и критерии до прогона

Составьте короткий паспорт эксперимента:

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

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

Шаг 3. Технически запретите исполнение

Создайте отдельную учётную запись для теневого контура. Ей нужны только чтение разрешённого источника и добавление записей в журнал результатов. Не передавайте ей ключи рабочего исполнителя даже через переменные окружения.

Ниже — пример безопасной декларативной конфигурации. Названия условные; это не готовая конфигурация конкретной платформы.

mode: shadow

input:
  source: sanitized_event_stream
  permissions:
    - events.read

output:
  sink: shadow_decisions
  permissions:
    - records.append
  production_actions: deny

tools:
  allow:
    - context.read
  deny:
    - message.send
    - ticket.update
    - payment.create
    - command.execute

data:
  store_raw_input: false
  redact_fields:
    - email
    - phone
    - access_token

limits:
  max_cases_per_hour: 100
  timeout_seconds: 20
  max_attempts: 1

Если платформа не умеет гарантированно запрещать инструменты, вынесите агент в отдельный сетевой контур без маршрута к рабочим API. Выходной формат также должен быть данными, а не исполняемой командой.

Шаг 4. Снимайте одинаковый контекст

Предложение агента и фактическое решение могут появиться в разное время. Поэтому сохраняйте версию или хеш снимка, который увидел агент. Не позволяйте ему незаметно читать состояние, изменившееся после решения процесса.

Безопасная проверка локального файла конфигурации может выглядеть так:

python -m json.tool shadow-config.json > /dev/null
sha256sum shadow-config.json

Первая команда только проверяет синтаксис JSON, вторая вычисляет контрольную сумму. Они не запускают агента и не изменяют рабочие системы. Для YAML используйте валидатор, уже утверждённый в вашей среде, а не случайно загруженный скрипт.

Шаг 5. Присоединяйте факт только после решения

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

Различайте три состояния:

1. Совпадение: предложение и факт эквивалентны по заранее заданному правилу.
2. Расхождение: оба решения известны, но различаются.
3. Не сравнимо: факт отсутствует, был отменён или изменился из-за информации, недоступной агенту.

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

Шаг 6. Считайте метрики по сегментам

Для категориального решения начните с простых величин:

match_rate = совпадения / сравнимые_случаи
coverage   = сравнимые_случаи / все_теневые_случаи
abstention = отказы_агента / все_теневые_случаи
latency_p95 = 95-й процентиль времени подготовки предложения

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

• не хватило контекста;
• неоднозначное правило процесса;
• неверное предложение агента;
• ошибка или отклонение фактического процесса;
• невозможность честного сравнения.

Фактическое решение — полезная точка сравнения, но не гарантированная истина. Спорные и высокорисковые расхождения должен разбирать назначенный эксперт по единым правилам.

Проверка результата

Теневой прогон организован корректно, если вы можете подтвердить следующее:

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

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

Пример итоговой таблицы

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

Типовые ошибки

«Теневой» агент использует рабочий токен

Отсутствие вызова сегодня не означает отсутствие риска завтра. Удалите полномочия технически и проверьте политики доступа.

Сравнивают с решением, которое агент уже видел

Так возникает утечка целевой метки. Зафиксируйте время снимка и порядок записи событий.

Смотрят только на среднюю точность

Редкая, но дорогая ошибка теряется в среднем значении. Сегментируйте результаты по риску и типу действия.

Любое отличие считают ошибкой агента

Рабочий процесс тоже бывает непоследовательным. Введите независимый разбор спорных случаев.

Меняют промпт во время прогона без новой версии

После этого результаты разных вариантов смешиваются. Любое изменение должно создавать новую версию.

Сохраняют весь вход «на всякий случай»

Это увеличивает риск утечки и усложняет управление сроками хранения. Записывайте минимальный контекст или безопасную ссылку на контролируемый снимок.

Ограничения теневого режима

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

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

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

Практический итог

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

Для продолжения используйте другие практические руководства, а определения терминов сверяйте с глоссарием Agent Lab Journal.