TNWS AI

Гайд · TNWS AI

Как получить last_response_id из RunResult OpenAI Agents SDK

WindowsmacOSLinuxWeb#нейросети#API#OpenAI Agents SDK
8 мин—

Извлекаем идентификатор последнего модельного ответа, сопоставляем его с raw_responses и корректно обрабатываем None без выдуманного ID.

Задача и практический результат

Цель этого гайда — связать итог запуска с последним модельным response для диагностики и аудита, не подменяя отсутствующий идентификатор случайной строкой. Результат считается готовым только при наличии машинно проверяемого доказательства: конкретного типа, HTTP-статуса, поля JSON, элемента истории или счётчика вызовов. Красивый ответ модели и отсутствие исключения сами по себе успех не подтверждают.

Названия методов и полей сверены 12 сентября 2026 года по официальной документации OpenAI Agents SDK. В материал не включены неподтверждённые цены, лимиты, региональная доступность и результаты производительности: они не нужны для выполнения описанного контракта. При обновлении пакета или сервера запустите тесты повторно.

Подтверждённый контракт

  • last_response_id — convenience property для ID последнего модельного ответа.
  • Тип свойства — str | None.
  • Значение относится к последнему model response, а не к tool call, trace или пользовательскому сообщению.
  • Список низкоуровневых модельных ответов доступен отдельно в raw_responses.
  • Провайдер или тестовый стаб может не дать ID, поэтому ветка None обязательна.

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

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

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

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

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

  1. После Runner сохраните result.last_response_id в отдельное поле аудита.
  2. Если значение None, пишите явный статус response_id_unavailable, а не генерируйте похожий ID.
  3. Для диагностики сопоставьте свойство с последним элементом raw_responses, но не сериализуйте полный сырой ответ без фильтрации.
  4. Unit-тестируйте две ветки provider-stub: с заданным ID и без него.

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

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

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

from agents import Agent, Runner

agent = Agent(name="analyst", instructions="Кратко классифицируй обращение.")
result = Runner.run_sync(agent, "T-781: ошибка оплаты")

response_id = result.last_response_id
audit = {
    "response_id": response_id,
    "response_id_status": (
        "available" if response_id is not None else "unavailable"
    ),
    "model_response_count": len(result.raw_responses),
}
assert audit["model_response_count"] >= 1
print(audit)

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

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

Вход: обращение T-781; тестовый model provider в первом случае возвращает response ID resp_test_781, во втором — None.

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

В первом случае audit содержит точную строку из provider-а. Во втором поле остаётся None и статус unavailable. Никакой UUID для маскировки отсутствия данных не создаётся.

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

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

Подставьте response_id or uuid4(). Тест должен запретить такую реализацию: сгенерированный UUID нельзя использовать для обращения к provider-логам как настоящий response ID.

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

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

Проверь аудит RunResult: не перепутан ли last_response_id с trace_id или tool_call_id, обработан ли None, фильтруются ли raw_responses и не создаётся ли фиктивный идентификатор.

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

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

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

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

Повторите тест дважды. Второй запуск не должен неожиданно удваивать side effect, использовать старый объект или принимать кешированный результат за новый. Для операций создания выбирайте уникальное тестовое имя и после проверки сверяйте именно его. Для content-addressed blobs сравнивайте полный SHA-256, а не начало строки.

В CI фиксируйте версии и exit code. Не сохраняйте сырой prompt, полный raw response или пути пользователя, если они содержат данные. Для диагностики достаточно response id, типа события, статуса и контрольного digest — при условии, что каждый из них получен из реального ответа, а не создан локально для красоты.

Типичные ошибки

Проверяется только счастливый путь

Такой тест может никогда не войти в нужную ветку. Добавьте управляемое несовпадение типа, отсутствующий digest, отказ approval или изменённую историю. Убедитесь, что тест падает именно по ожидаемой причине.

Разные идентификаторы смешиваются

Response ID, trace ID, tool call ID, SHA-256 digest и имя модели служат разным задачам. Не подменяйте один другим и не генерируйте локальное значение там, где нужен идентификатор сервера.

Успех объявляется слишком рано

Ответ transport-уровня ещё не подтверждает бизнес-состояние. После POST проверьте обязательное поле, после create — каталог моделей, после approval — счётчик tool, после преобразования — runtime-тип.

Ошибка версии маскируется fallback-кодом

Если метода или параметра нет, зафиксируйте несовместимость. Универсальный except, возвращающий «готово», делает документацию недостоверной и скрывает регрессию.

Чек-лист финальной проверки

  • Title, slug и тема не повторяют существующую публикацию.
  • Точные имена API сверены по официальному источнику 12 сентября 2026 года.
  • В коде нет секретов и реальных пользовательских данных.
  • Успешная ветка проверяет точный тип, status, поле или состояние.
  • Негативная ветка действительно активирует противоположный исход.
  • Fake tool или stub считает обращения, если возможен side effect.
  • Не смешиваются response ID, trace ID, call ID и digest.
  • Повторный запуск не создаёт ложный или двойной результат.
  • Ограничения не заменены выдуманными метриками.
  • После обновления версии тест можно запустить повторно.

Ограничения

Руководство проверяет один технический контракт, а не безопасность всей системы, качество модели или экономическую эффективность. Конкретные задержки, расход памяти, размер файла и точность зависят от модели и инфраструктуры; без воспроизводимого измерения их нельзя превращать в обещание.

Учитывайте доверительную границу. Локальный Ollama endpoint при публикации в сеть требует собственной защиты. Approval в SDK не заменяет серверную авторизацию. Освобождение ссылок Python не гарантирует мгновенное уменьшение RSS. Типизированный output не гарантирует истинность извлечённых данных. Эти риски проверяются отдельными слоями.

FAQ

Почему в статье нет цен и универсальных лимитов?

Они не участвуют в данном контракте и меняются независимо. Если стоимость нужна вашему проекту, сверяйте официальный pricing в день расчёта с валютой и единицей тарификации.

Можно ли считать HTTP 200 достаточной проверкой?

Нет. Используйте точный статус из официального контракта и проверяйте обязательные поля или состояние через независимый endpoint.

Зачем сохранять версию?

Имена методов и поведение меняются. Версия позволяет воспроизвести результат и отличить ошибку интеграции от изменения SDK или сервера.

Можно ли доверить финальную проверку нейросети?

Нет. Она может провести ревью структуры, но фактический PASS должен выставлять исполняемый тест или проверенный ответ API.

Первоисточник

Материал написан самостоятельно по контракту первоисточника. Примеры используют тестовые идентификаторы и не являются результатами скрытого бенчмарка.

Читайте также

ГайдыWindowsmacOS12 сентября 2026

Как проверять агента в терминале через REPL OpenAI Agents SDK

Запускаем run_demo_loop, проверяем многошаговый контекст и streaming, составляем сценарий ручной приёмки и отделяем REPL от автоматических тестов.

7 мин 
ГайдыWindowsmacOS12 сентября 2026

Как исправить ошибку reasoning item ID в OpenAI Agents SDK

Разбираем reasoning_item_id_policy=omit: когда удалять ID из переносимой истории, какие входы политика не меняет и как проверить исправление Responses API 400.

7 мин 
ГайдыWindowsmacOS12 сентября 2026

Как настроить lifecycle hooks в OpenAI Agents SDK для аудита вызовов

Подключаем RunHooks и AgentHooks, считаем вызовы модели и инструментов, не записываем секреты и проверяем порядок событий агентного запуска.

7 мин 

Подбор

Какую нейросеть выбрать

Пройти опрос

Комментарии

Пока тихо. Скажите первое слово