Как продолжить диалог через RunResult.to_input_list в OpenAI Agents SDK

• to_input_list() создаёт представление текущего запуска в виде списка input items.
• Режим по умолчанию preserve_all сохраняет историческое поведение и превращает new_items в полную plain-item историю.
• Режим normalized предпочитает канонический continuation input, если история модели была переписана handoff-фильтрацией.
• Для обычных запусков без переписывания истории результаты режимов совпадают.
• Метод возвращает список элементов, а не готовый текстовый prompt.

Каждый пункт выше превращается в отдельную проверку. Не объединяйте их в одну расплывчатую проверку вроде «запрос прошёл». Например, HTTP 200 не заменяет проверку status в теле, а подсказка type checker не заменяет runtime-валидацию. Такой подход особенно важен в агентных системах, где модельный ответ, tool call и локальная бизнес-логика имеют разные жизненные циклы.

Что подготовить

• отдельное тестовое окружение и зафиксированную версию зависимости или сервера;
• обезличенный вход без API-ключей, cookie, реальных реквизитов и персональных данных;
• fake tool или model stub, если сценарий способен вызвать внешний side effect;
• лог событий с точными полями, но без полного пользовательского диалога;
• автоматическую проверку, завершающую процесс ошибкой при несовпадении контракта.

До запуска определите, какой эффект допустим. Проверка чтения может обращаться к тестовому endpoint, но публикацию, оплату, удаление и отправку сообщений следует заменить счётчиком или sandbox-реализацией. Retry и resume нельзя тестировать на реальной операции, которую опасно выполнить дважды.

Пошаговая настройка

1. Выполните первый запуск и сохраните объект RunResult.
2. Получите continuation = first.to_input_list(mode="normalized"). Выбирайте этот режим, если используете mapper или фильтрацию handoff.
3. Добавьте новый пользовательский элемент в конец списка, сохраняя role и content.
4. Передайте полученный список второму запуску и отдельно протестируйте, что отфильтрованные элементы не появились снова.

После каждого шага фиксируйте наблюдаемый результат. Если проверяется порядок, храните массив событий. Если тип — используйте isinstance или строгий runtime-флаг. Если HTTP API — проверяйте и status code, и обязательные поля тела. Если состояние сервера — подтверждайте его отдельным read-only endpoint.

Готовый минимальный пример

Сохраните код в отдельный файл. Заполнители в угловых скобках нельзя отправлять как реальные digest или идентификаторы. Пример намеренно останавливается при несовпадении: тихое продолжение превратило бы ошибку в ложный успех.

from agents import Agent, Runner

agent = Agent(name="support", instructions="Работай только с переданной историей.")
first = Runner.run_sync(agent, "Мой номер обращения T-781")

continuation = first.to_input_list(mode="normalized")
continuation.append({
    "role": "user",
    "content": "Добавь уточнение: ошибка возникает после оплаты",
})
second = Runner.run_sync(agent, continuation)
assert len(continuation) >= 2
print(second.final_output)

Для Python запускайте файл в virtualenv проекта. JavaScript-пример сохраните как .mjs и используйте Node.js с глобальным fetch. Не смешивайте глобальную и проектную версии SDK. Перед первым интеграционным запросом выведите только безопасные параметры: endpoint, имя тестовой модели и версию, но никогда токен.

Реалистичный вход

Первый запуск получает номер T-781, второй — уточнение об ошибке после оплаты. В тесте с handoff mapper служебный шум удаляется из канонической истории.

Ожидаемый результат

Второй агент видит номер обращения и новое уточнение один раз. В режиме normalized удалённый mapper-ом элемент не возвращается; для обычного запуска оба режима дают одинаковый список.

Запишите это ожидание в assert или явный throw. Естественно-языковой текст может меняться, поэтому тестируйте стабильный инвариант. Для типов это класс объекта, для approval — число interruptions и executions, для blob — точный status, для create — финальное поле success и независимое присутствие новой записи.

Обязательный негативный тест

Используйте preserve_all после искусственного handoff-переписывания и сравните список с normalized. Тест обязан обнаружить лишний элемент, иначе сценарий не покрывает различие режимов.

Негативный сценарий запускайте в том же окружении. Он должен сломать ровно проверяемое условие, а не весь стенд. Сетевая недоступность не равна 404, TypeError не равен отказу модели, новый Runner не равен resume, а старое имя в каталоге не доказывает успешную пересборку. Эти различия следует выразить кодом.

Копируемый prompt для ревью

Сравни preserve_all и normalized для приложенного RunResult. Покажи индексы элементов, восстановленных только preserve_all, и проверь, не возвращает ли это данные, которые handoff mapper намеренно удалил.

Ответ верни таблицей: проверяемое условие, доказательство из кода или лога, PASS/FAIL, минимальное исправление. Не додумывай версии, статусы и результаты. Если доказательства нет, ставь FAIL.

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

Как проверить результат независимо

Сделайте таблицу минимум из трёх строк: штатный ввод, намеренно ошибочный ввод и пограничное значение. Для каждой укажите ожидаемую ветку, наблюдаемый признак и фактический результат. Если используется provider stub, считайте модельные обращения. Если tool fake — считайте исполнения. Если API — сохраните status и минимальный JSON без чувствительных данных.