Как задать rejection_message при отклонении tool approval

• RunConfig.tool_error_formatter задаёт run-wide текст для approval rejection.
• state.reject(interruption, rejection_message=...) задаёт per-call override.
• Per-call rejection_message имеет приоритет над run-wide formatter.
• Formatter проверяет args.kind == "approval_rejected".
• Текст не должен раскрывать запрещённые аргументы или внутренние правила.

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

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

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

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

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

1. Создайте run-wide formatter только для kind approval_rejected.
2. При отклонении конкретного interruption передайте короткий per-call текст.
3. Возобновите state с тем же RunConfig.
4. Проверьте, что модели передан per-call вариант и tool fake не исполнился.

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

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

from agents import RunConfig, ToolErrorFormatterArgs

def format_rejection(args: ToolErrorFormatterArgs[None]):
    if args.kind != "approval_rejected":
        return None
    return "Операция отменена: approval не получен."

config=RunConfig(tool_error_formatter=format_rejection)
state=paused.to_state()
state.reject(paused.interruptions[0],rejection_message="Публикация INV-781 отменена проверяющим.")
resumed=Runner.run_sync(original_agent,state,run_config=config)

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

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

Оператор отклоняет публикацию тестового счёта INV-781.

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

В model-visible результате используется per-call сообщение; execution counter равен нулю.

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

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

Удалите per-call override: должен примениться run-wide fallback, что подтверждает порядок приоритетов.

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

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

Проверь конфигурацию сценария «Как задать rejection_message при отклонении tool approval». Для каждого факта найди исполняемое доказательство. Проверь 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, который проверяет закрытие даже после исключения.