Гайд · TNWS AI
Как разобрать new_items в RunResult OpenAI Agents SDK
Отделяем сообщения, tool calls и tool outputs, строим безопасный журнал новых событий запуска и не смешиваем их с исходным input.
Задача и критерий готовности
Практическая задача — получить только новые элементы, созданные текущим запуском агента, классифицировать их по типу и построить проверяемый аудит без повторного включения исходного input. Готовность подтверждается программным тестом, а не впечатлением от текста. Для каждого сценария ниже заданы вход, ожидаемый наблюдаемый признак и негативная проверка.
Контракт сверён 12 сентября 2026 года по официальной документации OpenAI Agents SDK. Цены, тарифы, региональная доступность и неподтверждённые лимиты не используются: они не нужны для выполнения задачи.
Подтверждённые факты
new_items— список объектов RunItem, созданных во время agent run.- Список включает новые сообщения, вызовы tools, результаты tools и другие элементы текущего запуска.
- Исходный input хранится отдельно и не является синонимом new_items.
- Для продолжения диалога следует использовать
to_input_list, а не самостоятельно сериализовать внутренние RunItem. - Объект item может хранить ссылку на agent, поэтому долгоживущий аудит должен копировать только необходимые безопасные поля.
Эти пункты задают границу решения. Не расширяйте их предположениями: наличие поля не гарантирует истинность содержимого, HTTP 200 не подтверждает бизнес-состояние, а комментарий в коде не заменяет assert.
Подготовка стенда
- Зафиксируйте версию SDK, Ollama и точное имя тестовой модели.
- Используйте fake tool или provider stub для сценариев с побочными эффектами.
- Удалите токены, персональные данные, реальные счета и внутренние пути.
- Добавьте счётчики model calls и tool executions.
- Настройте завершение процесса с ошибкой при несовпадении контракта.
Тестовый ввод должен быть небольшим, но реалистичным. Идентификаторы T-781 и INV-781 в статье вымышлены. Для длинного текста создавайте синтетическую строку без копирования пользовательских документов.
Пошаговые действия
- Запустите агента с fake tool, чтобы получить минимум сообщение, tool call и tool output.
- Пройдите по
result.new_items, сохранитеtype(item).__name__и безопасное текстовое представление без аргументов-секретов. - Сравните число и порядок элементов с журналом fake tool.
- Для хранения скопируйте компактную запись, после чего при необходимости вызовите release_agents.
После каждого действия сохраняйте минимальное доказательство: класс объекта, длину списка, status code, обязательное поле JSON или порядок событий. Полный prompt и raw payload в журнал не нужны.
Копируемый пример
Сохраните пример как отдельный файл языка python. Значения в угловых скобках — заполнители; их нельзя выдавать за реальные digest или идентификаторы.
from agents import Agent, Runner, function_tool
@function_tool
def lookup_ticket(ticket_id: str) -> str:
return '{"ticket_id":"T-781","status":"open"}'
agent = Agent(name="support", instructions="Проверь статус тикета.", tools=[lookup_ticket])
result = Runner.run_sync(agent, "Какой статус T-781?")
audit = []
for index, item in enumerate(result.new_items):
audit.append({"index": index, "kind": type(item).__name__})
assert audit, "агент не создал новых элементов"
print(audit)
Python запускайте в virtualenv проекта, JavaScript — как .mjs в Node.js с fetch. Не смешивайте глобальную и проектную версии. Если импорт отсутствует, сначала проверьте установленную версию, а не подбирайте похожий API.
Реалистичный вход
Вход: вопрос о статусе T-781; fake tool возвращает локальный JSON и не обращается к реальной CRM.
Ожидаемый результат
В new_items появляется упорядоченная последовательность новых событий. Аудит содержит индексы и реальные имена классов, но не исходную пользовательскую строку как отдельный «новый результат».
Ожидание перенесите в assert или throw. Если текст модели недетерминирован, сравнивайте структурный инвариант. Если API возвращает массив, проверяйте число элементов и форму каждого.
Негативная проверка
Подставьте пустой список вместо result.new_items: тест должен упасть. Затем сравните с result.input и убедитесь, что приложение не считает эти поля взаимозаменяемыми.
Негативный тест должен ломать ровно одно условие. Сетевая ошибка не равна 404, пустой список не равен PASS, новый запуск не равен resume, а локально созданный UUID не равен response ID провайдера.
Готовый prompt для ревью
Проверь обработчик new_items: какие типы RunItem учитываются, сохраняется ли порядок, исключены ли секреты и не используется ли ручная сериализация new_items вместо to_input_list для продолжения.
Верни таблицу: условие, доказательство из кода или очищенного лога, 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 — без секретов и полного пользовательского содержимого.
Первоисточник
- Официальная документация OpenAI Agents SDK — проверено 12 сентября 2026 года.
Материал подготовлен самостоятельно; примеры не выдают синтетические данные за результаты реального бенчмарка.
Читайте также
Как проверять агента в терминале через REPL OpenAI Agents SDK
Запускаем run_demo_loop, проверяем многошаговый контекст и streaming, составляем сценарий ручной приёмки и отделяем REPL от автоматических тестов.
Как исправить ошибку reasoning item ID в OpenAI Agents SDK
Разбираем reasoning_item_id_policy=omit: когда удалять ID из переносимой истории, какие входы политика не меняет и как проверить исправление Responses API 400.
Как настроить lifecycle hooks в OpenAI Agents SDK для аудита вызовов
Подключаем RunHooks и AgentHooks, считаем вызовы модели и инструментов, не записываем секреты и проверяем порядок событий агентного запуска.
Комментарии
Пока тихо. Скажите первое слово