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

Что такое теневой режим

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

Цель такого прогона — не получить красивый общий процент, а ответить на три проверяемых вопроса:

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

Схема теневого контура

1. Рабочая система создаёт событие.
2. Зеркальный потребитель получает разрешённую копию события.
3. Агент использует только инструменты чтения.
4. Структурированное предложение попадает в отдельный журнал.
5. Фактическое действие сотрудника экспортируется из аудита.
6. Компаратор связывает записи и рассчитывает метрики.

Сотрудник не должен видеть предложение агента во время эксперимента. Иначе подсказка изменит его поведение, и независимого сравнения не получится.

Шаг 1. Ограничьте проверку одним решением

Выберите узкую операцию с однозначным результатом: назначить очередь, определить категорию или предложить один из заранее разрешённых статусов. Свободный текст и длинные цепочки действий сложнее сравнивать объективно.

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

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

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

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

{
  "event_id": "example-event-001",
  "observed_at": "2026-01-01T10:00:00Z",
  "decision_type": "route",
  "proposed_value": "billing",
  "confidence": 0.82,
  "reason_codes": ["mentions_invoice"],
  "agent_version": "shadow-v1",
  "policy_version": "routing-v3",
  "input_fingerprint": "sha256:example"
}

Для воспроизводимости нужны версии агента и правил, время наблюдения и отпечаток входа. Развёрнутое объяснение полезно при разборе, но не должно заменять конечное проверяемое значение.

Шаг 3. Запретите запись независимо от модели

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

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

mode: shadow

input:
  source: event_mirror
  consumer_group: agent-shadow-routing
  start_position: latest

tools:
  allow:
    - ticket.read
    - customer.read_summary
  deny:
    - ticket.update
    - message.send
    - refund.create

execution:
  apply_actions: false
  max_tool_calls: 4
  timeout_seconds: 20

output:
  type: append_only_jsonl
  path: ./shadow-data/proposals.jsonl

privacy:
  fields_allowlist:
    - event_id
    - ticket.subject
    - ticket.category
    - customer.service_tier
  redact_unknown_fields: true

Флаг apply_actions: false — дополнительный барьер, а не замена ограничениям API. Ошибка в коде не должна превращать предложение в команду.

Шаг 4. Проверьте конфигурацию до подключения

Следующие команды работают только с локальными файлами: создают закрытый каталог, проверяют синтаксис YAML и ищут явно опасные разрешения.

mkdir -p ./shadow-data
chmod 700 ./shadow-data

python -c "import yaml; yaml.safe_load(open('shadow.yaml')); print('YAML: OK')"

if grep -En \
  'apply_actions:[[:space:]]*true|ticket\.update|message\.send|refund\.create' \
  shadow.yaml
then
  echo "Проверка не пройдена: найдено разрешение на запись"
  exit 1
fi

Команда Python предполагает, что PyYAML уже установлен. Не устанавливайте пакет прямо в рабочую среду без принятой процедуры управления зависимостями.

Пример запуска, где agent-runner — условное имя программы:

agent-runner \
  --config ./shadow.yaml \
  --mode shadow \
  --output ./shadow-data/proposals.jsonl

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

Шаг 5. Докажите невозможность воздействия

До длительного прогона проверьте четыре независимых свойства:

1. учётная запись агента имеет только операции чтения;
2. в реестре процесса отсутствуют функции записи;
3. журнал предложений не подключён к рабочему исполнителю;
4. запрещённая операция отклоняется до обращения к модели.

Если раннер поддерживает отдельную проверку политик, ожидаемый интерфейс может выглядеть так:

agent-runner policy check \
  --config ./shadow.yaml \
  --tool ticket.update

# Ожидаемое поведение:
# DENY: tool is not allowed in shadow mode

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

Шаг 6. Сохраните фактический результат

После завершения рабочей обработки экспортируйте минимальные поля из журнала аудита. Пример записи:

{
  "event_id": "example-event-001",
  "actual_action": "route",
  "actual_value": "billing",
  "acted_at": "2026-01-01T10:04:00Z",
  "actor_type": "human"
}

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

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

Шаг 7. Сопоставьте записи

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

Команда ниже читает два JSONL-файла и выводит сравнение, не изменяя исходные данные:

jq -s '
  (.[0] | map({key: .event_id, value: .}) | from_entries) as $p
  | .[1]
  | map(
      select($p[.event_id] != null)
      | {
          event_id,
          proposed: $p[.event_id].proposed_value,
          actual: .actual_value,
          match: ($p[.event_id].proposed_value == .actual_value)
        }
    )
' ./shadow-data/proposals.jsonl \
  ./shadow-data/actual.jsonl

Для первого отчёта достаточно пяти показателей:

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

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

Теневой прогон технически организован правильно, если выполняются все условия:

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

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

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

Запрет действий записан только в промпте

Уберите инструменты записи и ограничьте права сервисной учётной записи на стороне API.

Теневой потребитель влияет на рабочую очередь

Используйте зеркало событий или независимую группу потребителей.

Сотрудники видят предложения агента

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

Дубли считаются новыми задачами

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

Все несовпадения объявляются ошибками модели

Отправляйте спорную выборку на слепую экспертную проверку по фиксированным критериям.

Общая точность скрывает опасный сегмент

Считайте метрики отдельно для редких, неполных и чувствительных случаев.

В журнал копируется полный вход

Храните разрешённые признаки, коды причин и отпечаток входа, а не ненужные чувствительные данные.

Ограничения

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

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

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

Итог

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

← Все практические руководства · Глоссарий Agent Lab Journal →