Как возобновить OpenAI Agent после approval через RunResult.to_state

• Pending approvals доступны в result.interruptions.
• result.to_state() создаёт RunState, пригодный для возобновления исполнения.
• Решение применяется через state.approve(item) или state.reject(item).
• Продолжение выполняется Runner.run(original_agent, state) либо синхронным эквивалентом с исходным top-level агентом.
• Не обязательно разрешать все interruptions за один проход; нерешённые элементы могут снова остановить run.

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

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

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

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

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

1. Настройте tool с требованием approval и вызовите Runner на тестовом вводе.
2. Если interruptions пуст, не имитируйте одобрение: значит, чувствительный вызов не был запрошен.
3. Создайте state, покажите оператору имя tool, call id и очищенные аргументы, затем одобрите только выбранный interruption.
4. Передайте state исходному агенту. Убедитесь, что модельный диалог не стартовал с нуля и tool выполнился один раз.

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

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

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

from agents import Agent, Runner

# publish_invoice — tool, настроенный с requires_approval.
agent = Agent(
    name="billing",
    instructions="Публикуй счёт только после approval.",
    tools=[publish_invoice],
)
paused = Runner.run_sync(agent, "Опубликуй счёт INV-781")
assert paused.interruptions, "approval pause не возник"

state = paused.to_state()
item = paused.interruptions[0]
state.approve(item)
resumed = Runner.run_sync(agent, state)
assert not resumed.interruptions
print(resumed.final_output)

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

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

Вход: запрос публикации счёта INV-781. Fake tool считает исполнения, но не обращается к реальной биллинговой системе.

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

Первый запуск возвращает interruption и ноль выполнений tool. После approve и возобновления исходного state fake tool вызывается ровно один раз, затем run завершается.

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

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

Запустите Runner повторно с исходной строкой вместо state. Считайте это ошибкой теста: это новый run, который не доказывает корректное возобновление и может повторить предыдущие шаги.

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

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

Проверь HITL-код: решение привязано к конкретному interruption, сохраняется RunState, используется исходный top-level agent, tool до approval не выполняется, а после resume исполняется ровно один раз.

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

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

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

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