Как проверить тип final_output через final_output_as в OpenAI Agents SDK

• result.final_output_as(SomeType) — удобное приведение финального результата к указанному типу.
• По умолчанию это приведение предназначено только для type checker и не выполняет строгую runtime-проверку.
• Для фактической проверки нужно передать raise_if_incorrect_type=True.
• При несовпадении фактического типа SDK поднимает TypeError.
• Метод не преобразует произвольную строку в Pydantic-модель и не чинит невалидный результат.

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

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

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

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

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

1. Опишите бизнес-результат классом Pydantic и задайте этот же класс в Agent(output_type=...).
2. После завершения Runner вызовите final_output_as с тем же классом и обязательным raise_if_incorrect_type=True.
3. Передавайте типизированный объект дальше только после успешного вызова. Не используйте cast() как runtime-валидацию.
4. В unit-тесте создайте корректный RunResult и намеренно подменённый final_output; второй сценарий обязан завершиться TypeError.

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

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

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

from pydantic import BaseModel
from agents import Agent, Runner

class Ticket(BaseModel):
    ticket_id: str
    priority: str

agent = Agent(
    name="triage",
    instructions="Верни ticket_id и priority; не добавляй других полей.",
    output_type=Ticket,
)
result = Runner.run_sync(agent, "Тикет T-781: касса не отвечает")
ticket = result.final_output_as(
    Ticket,
    raise_if_incorrect_type=True,
)
assert isinstance(ticket, Ticket)
assert ticket.ticket_id == "T-781"
print(ticket.model_dump())

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

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

Вход: «Тикет T-781: касса не отвечает». Ожидаемая схема содержит строковые поля ticket_id и priority.

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

Ожидаемый результат успешного теста — объект Ticket, а не JSON-строка. Негативный стаб возвращает обычную строку, и вызов с runtime-флагом поднимает TypeError.

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

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

Повторите вызов без raise_if_incorrect_type=True. Он может удовлетворить type checker, но не докажет фактический тип. Тест должен явно показать эту разницу.

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

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

Проверь участок после Runner: совпадает ли класс в output_type и final_output_as, включён ли raise_if_incorrect_type, обрабатывается ли TypeError и не выдаётся ли статический cast за runtime-валидацию.

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

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

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

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