TNWS AI

Гайд · TNWS AI

Как определить last_agent после handoff в OpenAI Agents SDK

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

Проверяем, какой агент сформировал финальный результат после handoff, сохраняем стабильное имя и не определяем маршрут по тексту ответа.

Задача и критерий готовности

Практическая задача — после маршрутизации и handoff точно определить агента, который последним обрабатывал run, вместо угадывания по содержимому финального текста. Готовность подтверждается программным тестом, а не впечатлением от текста. Для каждого сценария ниже заданы вход, ожидаемый наблюдаемый признак и негативная проверка.

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

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

  • last_agent хранит последнего агента, который выполнялся в рамках run.
  • После handoff last_agent может отличаться от исходного top-level агента.
  • Поле содержит объект Agent, а не только строковое имя.
  • После release_agents() last_agent может стать None, если объект собран garbage collector.
  • Имя нужно скопировать до освобождения ссылок, если оно требуется для аудита.

Эти пункты задают границу решения. Не расширяйте их предположениями: наличие поля не гарантирует истинность содержимого, HTTP 200 не подтверждает бизнес-состояние, а комментарий в коде не заменяет assert.

Подготовка стенда

  • Зафиксируйте версию SDK, Ollama и точное имя тестовой модели.
  • Используйте fake tool или provider stub для сценариев с побочными эффектами.
  • Удалите токены, персональные данные, реальные счета и внутренние пути.
  • Добавьте счётчики model calls и tool executions.
  • Настройте завершение процесса с ошибкой при несовпадении контракта.

Тестовый ввод должен быть небольшим, но реалистичным. Идентификаторы T-781 и INV-781 в статье вымышлены. Для длинного текста создавайте синтетическую строку без копирования пользовательских документов.

Пошаговые действия

  1. Создайте triage agent и specialist agent с handoff.
  2. Запустите запрос, однозначно направляемый специалисту.
  3. Проверьте result.last_agent.name и сравните его с ожидаемым стабильным именем.
  4. Скопируйте имя в audit record до release_agents и отдельно протестируйте путь без handoff.

После каждого действия сохраняйте минимальное доказательство: класс объекта, длину списка, status code, обязательное поле JSON или порядок событий. Полный prompt и raw payload в журнал не нужны.

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

Сохраните пример как отдельный файл языка python. Значения в угловых скобках — заполнители; их нельзя выдавать за реальные digest или идентификаторы.

from agents import Agent, Runner

billing = Agent(name="billing", instructions="Решай вопросы оплаты.")
triage = Agent(name="triage", instructions="Передай вопросы оплаты в billing.", handoffs=[billing])
result = Runner.run_sync(triage, "По счёту INV-781 прошло двойное списание")
assert result.last_agent is not None
assert result.last_agent.name == "billing"
audit = {"last_agent": result.last_agent.name}
result.release_agents()
print(audit)

Python запускайте в virtualenv проекта, JavaScript — как .mjs в Node.js с fetch. Не смешивайте глобальную и проектную версии. Если импорт отсутствует, сначала проверьте установленную версию, а не подбирайте похожий API.

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

Вход: однозначный вопрос о двойном списании по INV-781, который должен уйти из triage в billing.

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

last_agent.name равен billing. В контрольном запросе общего характера без handoff ожидается triage; текст ответа не используется для определения маршрута.

Ожидание перенесите в assert или throw. Если текст модели недетерминирован, сравнивайте структурный инвариант. Если API возвращает массив, проверяйте число элементов и форму каждого.

Негативная проверка

Измените instructions так, чтобы handoff не происходил. Тест ожидания billing должен упасть и показать реальное изменение маршрута.

Негативный тест должен ломать ровно одно условие. Сетевая ошибка не равна 404, пустой список не равен PASS, новый запуск не равен resume, а локально созданный UUID не равен response ID провайдера.

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

Проверь тест маршрутизации: last_agent читается из RunResult, ожидаемые имена стабильны, есть сценарий с handoff и без него, значение копируется до release_agents.

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

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

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

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

Для agent run отдельно считайте model responses, tools и RunItem: это разные сущности. Для Ollama проверяйте HTTP и тело. Если операция изменяет модель или индекс, после неё используйте read-only endpoint или схему хранилища как второе доказательство.

В CI сохраняйте exit code, версии и безопасные агрегаты. Не сохраняйте полный raw response, словарь tokenizer, пользовательский prompt или tool arguments без отдельной политики редактирования.

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

Пустой список принимают за успех

Конструкции вроде all([]) истинны. Если ожидается конкретный guardrail или embedding, сначала проверьте количество элементов, затем их свойства.

Логируют всё для удобства

Raw responses, arguments и verbose model_info могут быть большими или чувствительными. Создайте allowlist полей и сохраняйте только агрегаты, нужные для расследования.

Смешивают идентификаторы

Response ID, trace ID, tool call ID, model tag и SHA-256 отвечают на разные вопросы. Храните их в отдельных колонках и не генерируйте подмену для отсутствующего значения.

Не проверяют версию

Поведение после обновления может измениться. Версия и точное имя модели должны быть частью воспроизводимого отчёта, особенно для snapshot-тестов и tokenizer-данных.

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

  • Тема, title и slug уникальны.
  • API и поля сверены по первоисточнику 12 сентября 2026 года.
  • Есть точный вход и программируемый ожидаемый результат.
  • Негативный тест активирует нужную противоположную ветку.
  • Секреты, PII и реальные реквизиты исключены.
  • Счётчики разделяют model, tool и item events.
  • Проверяется форма массива и каждый элемент.
  • Полный raw или verbose payload не уходит в журнал.
  • Повторный запуск не создаёт ложный успех.
  • Ограничения не заменены выдуманными метриками.

Ограничения

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

Approval не заменяет авторизацию, typed output не гарантирует истинность, release ссылок не обещает мгновенное падение RSS, а seed не гарантирует одинаковый ответ после смены модели. Такие границы должны оставаться явными в рабочей документации.

FAQ

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

Потому что они зависят от версии и модели. Используйте фактический ответ вашего стенда и фиксируйте дату измерения.

Достаточно ли HTTP 200?

Нет. Проверяйте контрактный status, обязательные поля и при необходимости независимое состояние.

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

Она полезна для ревью, но PASS выставляет исполняемый тест или проверенный ответ API.

Что сохранять в отчёте?

Версии, безопасные идентификаторы, агрегаты, exit code и результат каждого assert — без секретов и полного пользовательского содержимого.

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

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

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

Гайды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 мин 

Подбор

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

Пройти опрос

Комментарии

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