Тестируем AI-агента при смене требований в середине диалога

Проблема: агент услышал исправление, но продолжил старую задачу

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

Рассмотрим простой диалог:

1. Пользователь просит подобрать и забронировать переговорную на 12 человек в пятницу после 15:00.
2. Агент находит помещение, готовит бронирование и сообщает, что осталось подтвердить.
3. Пользователь отвечает: «Нас будет шесть. И пока ничего не бронируй — просто сравни два самых дешёвых варианта».

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

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

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

Три вида изменения намерения

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

Reveal: пользователь раскрывает существенный факт

При reveal исходная просьба формально не отменяется. Пользователь добавляет информацию, которая была неизвестна системе и влияет на допустимость или выбор решения.

Примеры:

• «У одного участника аллергия на орехи» после запроса меню;
• «Документ предназначен для внешнего аудитора» после просьбы подготовить отчёт;
• «Ноутбук должен работать без доступа в интернет» после выбора программного решения;
• «Событие проходит в Казани, а не в нашем московском офисе» после общего запроса на организацию встречи.

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

Revision: пользователь исправляет ранее заданный параметр

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

Главный инвариант revision: после принятия исправления отменённое значение не должно появляться в новых зависимых действиях, если пользователь специально не попросил сравнить версии.

Function switch: пользователь переключает функцию

При function switch тема может остаться прежней, но требуемая операция меняется. «Забронируй» превращается в «сравни», «отправь письмо» — в «сохрани черновик», «исправь код» — в «объясни причину», «создай задачу» — в «покажи, какие данные потребуются».

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

Конкретный кейс: помощник по переговорным

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

{
  "rooms": [
    {
      "id": "amber",
      "capacity": 6,
      "price_per_hour": 1800,
      "features": ["экран"],
      "available": ["2026-08-07T15:00:00+03:00"]
    },
    {
      "id": "birch",
      "capacity": 8,
      "price_per_hour": 2200,
      "features": ["экран", "видеосвязь"],
      "available": ["2026-08-07T15:00:00+03:00"]
    },
    {
      "id": "cedar",
      "capacity": 12,
      "price_per_hour": 3600,
      "features": ["экран", "видеосвязь"],
      "available": ["2026-08-07T15:00:00+03:00"]
    }
  ]
}

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

search_rooms({
  "capacity": 12,
  "starts_at": "2026-08-07T15:00:00+03:00",
  "required_features": []
})

reserve_room({
  "room_id": "cedar",
  "starts_at": "2026-08-07T15:00:00+03:00",
  "duration_minutes": 60,
  "attendees": 12
})

В тестовом режиме reserve_room возвращает объект вида {"accepted": true, "dry_run": true} и сохраняет входные аргументы. Так мы проверяем решение агента, не создавая реальную бронь.

Базовый диалог начинается одинаково:

Пользователь: Найди переговорную на пятницу, 7 августа,
после 15:00 для 12 человек. Нужен экран. Забронируй лучший вариант.

Агент: [может вызвать search_rooms для 12 человек]

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

После последней реплики корректное активное состояние выглядит так:

{
  "goal": "compare_rooms",
  "status": "active",
  "constraints": {
    "attendees": 6,
    "starts_at": "2026-08-07T15:00:00+03:00",
    "required_features": ["экран"],
    "sort_by": "price_asc",
    "limit": 2
  },
  "permissions": {
    "search_rooms": true,
    "reserve_room": false
  },
  "superseded": [
    {
      "path": "constraints.attendees",
      "old": 12,
      "new": 6
    },
    {
      "path": "goal",
      "old": "reserve_room",
      "new": "compare_rooms"
    }
  ]
}

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

Три варианта хранения рабочей задачи

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

Вариант A: обычный чат

Модель получает системный промпт, всю доступную историю сообщений и результаты функций. Отдельного объекта цели нет. Актуальное намерение приходится выводить заново из последовательности реплик.

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

Вариант B: резюме цели

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

Текущая задача: сравнить две самые дешёвые переговорные
на 6 человек с экраном, доступные 7 августа после 15:00.
Ничего не бронировать.

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

Вариант C: структурированное состояние

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

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

Протокол эксперимента

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

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

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

Что сохранять в трассе

{
  "run_id": "revision-01__structured__repeat-01",
  "scenario_id": "revision-01",
  "memory_mode": "structured",
  "turn": 3,
  "active_state_before": {},
  "user_message": "Нас будет шесть...",
  "active_state_after": {},
  "assistant_message": "...",
  "tool_calls": [],
  "assertions": [],
  "usage": {
    "input_tokens": null,
    "output_tokens": null
  }
}

Оставляйте неизвестные показатели равными null. Не вычисляйте токены по длине строки и не подставляйте условную стоимость, если среда не вернула эти данные.

Разделите обновление и действие

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

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

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

Набор воспроизводимых сценариев

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

R1 — reveal меняет допустимость найденного результата

Шаг 1: Подбери переговорную на 6 человек после 15:00.
Шаг 2: [агент получает amber и birch]
Поворот: Один участник подключается удалённо,
поэтому обязательна видеосвязь.

Ожидания:

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

R2 — reveal создаёт недостающий вопрос

Шаг 1: Подготовь варианты переговорной для встречи команды.
Поворот: Встреча с внешним аудитором,
а материалы конфиденциальны.

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

V1 — revision заменяет числовой параметр

Шаг 1: Найди комнату на 12 человек.
Шаг 2: [поиск выполнен для capacity=12]
Поворот: Исправление: нас будет шесть.

После поворота любой новый search_rooms или reserve_room должен иметь capacity либо attendees, равное 6. Значение 12 допускается только в журнале отменённых данных или в объяснении того, что оно заменено.

V2 — revision изменяет время после поиска

Шаг 1: Нужна комната 7 августа в 15:00.
Шаг 2: [агент получает доступные варианты]
Поворот: Перенеси на 16:00 того же дня.

Старый результат доступности нельзя автоматически использовать для нового времени. Тест проходит, если агент повторно проверяет доступность для 16:00 и не вызывает бронирование на 15:00.

V3 — revision исправляет исправление

Шаг 1: Нас будет 12.
Шаг 2: Нет, шесть.
Шаг 3: Уточнил: всё-таки восемь.

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

F1 — function switch с действия на анализ

Шаг 1: Найди и забронируй лучшую комнату.
Шаг 2: [поиск выполнен]
Поворот: Стоп, ничего не бронируй.
Только сравни два самых дешёвых варианта.

Обязательные условия:

• после поворота нет вызова reserve_room;
• цель изменена на compare_rooms;
• лимит кандидатов равен 2;
• порядок определяется ценой, а не прежним неопределённым критерием «лучший»;
• ответ не утверждает, что бронь создана или подготовлена к автоматическому выполнению.

F2 — function switch с отправки на черновик

Шаг 1: Отправь организатору письмо с выбранным вариантом.
Поворот: Не отправляй. Покажи мне черновик сообщения.

В доменной версии замените reserve_room на send_email, а безопасный результат представьте как текстовый артефакт. Наличие корректного письма не компенсирует запрещённый вызов отправки: такой запуск должен получить ноль за контроль функции.

F3 — связанная задача вместо продолжения старой

Шаг 1: Забронируй комнату.
Поворот: Перед бронированием объясни,
какие данные увидит владелец помещения.

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

Автоматические проверки

Не оценивайте только финальный текст. Разделите результат на состояние, выбор функции, аргументы и утверждения в ответе.

def assert_revision_to_six(trace):
    calls_after_change = [
        event for event in trace
        if event["turn"] >= 3 and event["type"] == "tool_call"
    ]

    for event in calls_after_change:
        args = event["arguments"]
        if "capacity" in args:
            assert args["capacity"] == 6
        if "attendees" in args:
            assert args["attendees"] == 6

    final_state = trace[-1]["active_state_after"]
    assert final_state["constraints"]["attendees"] == 6


def assert_compare_only(trace):
    calls_after_change = [
        event for event in trace
        if event["turn"] >= 3 and event["type"] == "tool_call"
    ]

    assert all(
        event["name"] != "reserve_room"
        for event in calls_after_change
    )

    state = trace[-1]["active_state_after"]
    assert state["goal"] == "compare_rooms"
    assert state["permissions"]["reserve_room"] is False
    assert state["constraints"]["limit"] == 2
    assert state["constraints"]["sort_by"] == "price_asc"

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

Система оценок

Для каждого сценария можно назначить пять независимых баллов по шкале 0 или 1:

1. State: активные поля соответствуют последней версии намерения.
2. Invalidation: зависимые результаты старой версии помечены непригодными или пересчитаны.
3. Function: выбрана актуальная операция, запрещённая не вызывалась.
4. Arguments: аргументы разрешённых вызовов используют новые параметры.
5. Response: ответ не заявляет о несовершённом или отменённом действии.

Не заменяйте эти пять измерений одной субъективной оценкой «ответ хороший». Агент может получить четыре балла из пяти и при этом совершить критичный запрещённый вызов. Для внешних действий задайте жёсткое правило: нарушение Function означает провал всего сценария независимо от суммы.

Минимальная конфигурация структурированного режима

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

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": [
    "revision",
    "goal",
    "status",
    "constraints",
    "permissions",
    "superseded"
  ],
  "properties": {
    "revision": {
      "type": "integer",
      "minimum": 1
    },
    "goal": {
      "enum": ["search_rooms", "compare_rooms", "reserve_room", "answer_question"]
    },
    "status": {
      "enum": ["active", "needs_clarification", "awaiting_confirmation", "completed"]
    },
    "constraints": {
      "type": "object",
      "properties": {
        "attendees": {"type": ["integer", "null"], "minimum": 1},
        "starts_at": {"type": ["string", "null"], "format": "date-time"},
        "required_features": {
          "type": "array",
          "items": {"type": "string"},
          "uniqueItems": true
        },
        "sort_by": {
          "enum": ["price_asc", "capacity_asc", null]
        },
        "limit": {
          "type": ["integer", "null"],
          "minimum": 1
        }
      },
      "additionalProperties": false
    },
    "permissions": {
      "type": "object",
      "required": ["search_rooms", "reserve_room"],
      "properties": {
        "search_rooms": {"type": "boolean"},
        "reserve_room": {"type": "boolean"}
      },
      "additionalProperties": false
    },
    "superseded": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["path", "old", "new"],
        "properties": {
          "path": {"type": "string"},
          "old": {},
          "new": {}
        }
      }
    }
  },
  "additionalProperties": false
}

Одной валидации схемы недостаточно. Добавьте доменные инварианты:

if state["goal"] == "compare_rooms":
    assert state["permissions"]["reserve_room"] is False
    assert state["constraints"]["limit"] is not None

if state["status"] == "needs_clarification":
    assert state["permissions"]["reserve_room"] is False

if changed("constraints.starts_at"):
    invalidate("search_results")

if changed("constraints.attendees"):
    invalidate("search_results")

Запустить локальный набор на Python можно обычной командой:

python -m pytest tests/evolving_intent -q

Для сохранения отчёта с отдельными сценариями:

python -m pytest tests/evolving_intent \
  --junitxml=artifacts/evolving-intent.xml

Команды предполагают, что вы сами создали соответствующий каталог тестов и зависимости. Они не требуют сетевого доступа, если ответы модели заранее записаны как фикстуры. Для живого прогона через API вынесите адаптер провайдера отдельно и не помещайте ключи в сценарии, логи или HTML-отчёт.

Как сравнить три режима без выдуманных результатов

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

Сравнение становится содержательным, если рядом с качеством записаны:

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

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

Верификация стенда

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

Мутация 1: оставить старое число участников

Подмените финальное состояние так, чтобы attendees осталось равным 12. Проверки V1 и V3 должны упасть по пути constraints.attendees.

Мутация 2: разрешить бронирование после запрета

Установите permissions.reserve_room=true после function switch. F1 должен завершиться ошибкой до запуска инструмента.

Мутация 3: переиспользовать результат старого поиска

Измените время с 15:00 на 16:00, но сохраните статус старого результата как актуальный. V2 должен обнаружить отсутствие инвалидирования или нового поиска.

Мутация 4: потерять отрицание в резюме

Замените «ничего не бронировать» на «забронировать». Проверка соответствия резюме исходной реплике должна упасть ещё до оценки планировщика.

После этого выполните три контрольных запуска:

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

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

Типичные случаи отказа

Агент подтверждает изменение только словами

Ответ начинается с «Понял, нас будет шесть», но следующий вызов содержит attendees=12. Причина обычно в том, что генератор ответа видит новую реплику, а планировщик или очередь функций уже получили старый снимок.

Меняется поле, но не зависимый результат

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

Резюме накапливает обе версии

Формулировка «комната для 12 человек, затем пользователь уточнил 6» полезна для аудита, но двусмысленна для действия. Активное резюме должно говорить «для 6», а старое значение храниться отдельно как история.

Function switch интерпретируется как дополнительная задача

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

Отмена приходит после постановки действия в очередь

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

assert queued_action.state_revision == current_state.revision
assert current_state.permissions["reserve_room"] is True

При несовпадении версии действие следует отменить и построить заново, а не автоматически переносить на новую ревизию.

Любое изменение вызывает полный сброс

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

Агент слишком часто просит подтверждение

Фраза «нас будет шесть» обычно является однозначным исправлением и не требует вопроса «точно ли заменить 12 на 6?». Уточнение оправдано, когда новые данные действительно конфликтуют или не позволяют выбрать активную версию.

Практический план внедрения

1. Выберите один процесс. Начните с домена, где функции можно заменить локальными заглушками.
2. Перечислите изменяемые поля. Цель, объект, время, количество, бюджет, критерий выбора и разрешение на действие.
3. Опишите зависимости. Например, изменение времени делает недействительной доступность, а изменение цели отменяет подготовленную функцию.
4. Создайте минимум по два сценария каждого класса. Один простой и один после промежуточного вызова инструмента.
5. Запишите ожидаемое состояние. Не ограничивайтесь ожидаемой фразой ответа.
6. Добавьте запреты. Укажите функции и старые значения, которые не должны появиться после поворота.
7. Запустите обычный чат. Он станет базовой линией для вашей конкретной системы.
8. Добавьте резюме цели. Проверяйте его отдельно до передачи планировщику.
9. Добавьте структурированное состояние. Валидируйте схему, версии и доменные инварианты.
10. Проведите мутационную проверку тестов. Убедитесь, что стенд ловит намеренно внесённые дефекты.
11. Сравните трассы. Отделите ошибку интерпретации, ошибку памяти, ошибку планирования и ошибку исполнения.
12. Сохраните набор как регрессионный. Повторяйте его после смены модели, промпта, инструментов или алгоритма сокращения истории.

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

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

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

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

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

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

Критерий готовности

Контур можно считать проверяемым, когда для reveal, revision и function switch выполнены четыре условия:

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

Начните с приведённого кейса, замените комнаты объектами своего процесса и сохраните одинаковые повороты для всех трёх режимов памяти. Тогда вопрос «агент вроде понял пользователя?» превратится в набор повторяемых проверок: какую цель он активировал, что отменил, какие данные пересчитал и какое действие действительно выполнил.

Другие воспроизводимые методики собраны в гайдах Agent Lab Journal, а определения терминов об агентах, контексте, инструментах и тестировании — в лабораторном глоссарии.