Как сериализовать RunState для позднего возобновления агента

• RunState рассчитан на durable storage.
• Доступны to_json()/from_json() и to_string()/from_string().
• Serialized state включает app context и runtime metadata: approvals, usage, tool_input, trace data и настройки conversation.
• Sticky approval decisions переживают сериализацию.
• Context с секретами попадёт в payload, если приложение само его туда положило.

Каждый пункт проверяется отдельно. Не объединяйте доступность backend, корректность истории и качество ответа в один флаг success: это независимые слои.

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

• отдельную тестовую базу, Redis database или временный файл;
• уникальный session_id, не совпадающий с ID реального пользователя;
• fake tool и provider stub для контроля вызовов;
• переменные окружения для ключей и строк подключения;
• журнал безопасных агрегатов и версий без содержимого переписки.

Прежде чем запускать код, определите владельца соединения и cleanup. Для hosted storage проверьте, где фактически лежат данные. Для durable state считайте payload чувствительным: он включает app context и runtime metadata.

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

1. Получите real paused RunResult и вызовите to_state.
2. Перед сериализацией удалите секреты из app context либо задайте serializer.
3. Сохраните state string зашифрованно и с access control.
4. Восстановите RunState, примените решение к interruption и передайте исходному top-level agent.

После каждого шага записывайте наблюдаемый признак: число items, конкретный exception, наличие interruption, счётчик tool или факт завершения async iterator. Комментарий в коде не является проверкой.

Копируемый пример

from agents import RunState, Runner

# paused получен из RunResult с interruptions.
state=paused.to_state()
serialized=state.to_string()
assert serialized
# Сохраните serialized как чувствительные данные.
restored=RunState.from_string(serialized)
restored.approve(restored.interruptions[0])
resumed=Runner.run_sync(original_agent,restored)
print(resumed.final_output)

Запускайте пример в отдельном virtualenv. Все ключи и URL берите из окружения; тестовые localhost-адреса не превращайте в production-конфигурацию автоматически. Заполнители paused, original_agent и fake counters должны быть определены вашим воспроизводимым fixture.

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

Run остановлен на approval публикации тестового счёта INV-781.

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

После восстановления interruption сохраняется, approve применяется к нему, tool fake выполняется один раз.

Перенесите ожидание в assert. Для недетерминированного текста проверяйте сохранённый факт через model stub либо напрямую session items. Для approval проверяйте и interruptions, и execution counter.

Негативный тест

Перезапустите исходный prompt вместо state: тест должен считать это новым run, а не resume.

Негативная проверка меняет одно условие. Ошибка подключения не равна пустой истории, новый run не равен resume, другой session_id не является потерей данных, а отсутствие второй паузы допустимо только при подтверждённом sticky decision.

Готовый prompt для ревью

Проверь конфигурацию сценария «Как сериализовать RunState для позднего возобновления агента». Для каждого факта найди исполняемое доказательство. Проверь ownership соединений, cleanup, секреты, session_id, число model/tool вызовов и негативный тест. Верни таблицу PASS/FAIL; если доказательства нет, ставь FAIL.

Prompt используйте после приложения кода и очищенного лога. Он не заменяет исполнение: языковая модель может назвать комментарий гарантией или пропустить неверный cleanup.

Независимая проверка

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

Считайте отдельно model calls, tool executions, session writes и approval interruptions. Один счётчик не описывает весь run. Для async cleanup добавьте fixture, который проверяет закрытие даже после исключения.