Гайд · TNWS AI
Как проверить guardrail results в RunResult OpenAI Agents SDK
Разбираем input_guardrail_results и output_guardrail_results, отличаем успешные проверки от tripwire и сохраняем доказательства без чувствительного output_info.
Задача и критерий готовности
Практическая задача — после успешного agent run проверить, какие input и output guardrails действительно выполнялись, и не принимать пустой список за пройденную защиту. Готовность подтверждается программным тестом, а не впечатлением от текста. Для каждого сценария ниже заданы вход, ожидаемый наблюдаемый признак и негативная проверка.
Контракт сверён 12 сентября 2026 года по официальной документации OpenAI Agents SDK. Цены, тарифы, региональная доступность и неподтверждённые лимиты не используются: они не нужны для выполнения задачи.
Подтверждённые факты
input_guardrail_resultsсодержит результаты guardrails для входных сообщений.output_guardrail_resultsсодержит результаты guardrails финального ответа.- Пустой список означает отсутствие записанных результатов, а не автоматически «все проверки пройдены».
- Tool input и tool output guardrails имеют отдельные result-поля и не входят в эти два списка.
- Детали output_info могут содержать чувствительную информацию и требуют отдельной политики хранения.
Эти пункты задают границу решения. Не расширяйте их предположениями: наличие поля не гарантирует истинность содержимого, HTTP 200 не подтверждает бизнес-состояние, а комментарий в коде не заменяет assert.
Подготовка стенда
- Зафиксируйте версию SDK, Ollama и точное имя тестовой модели.
- Используйте fake tool или provider stub для сценариев с побочными эффектами.
- Удалите токены, персональные данные, реальные счета и внутренние пути.
- Добавьте счётчики model calls и tool executions.
- Настройте завершение процесса с ошибкой при несовпадении контракта.
Тестовый ввод должен быть небольшим, но реалистичным. Идентификаторы T-781 и INV-781 в статье вымышлены. Для длинного текста создавайте синтетическую строку без копирования пользовательских документов.
Пошаговые действия
- Назначьте агенту именованные input и output guardrails.
- После run проверьте ожидаемое количество результатов каждого слоя.
- Сохраните название проверки и итоговый boolean, не сериализуя output_info целиком.
- Негативный тест должен активировать tripwire до формирования успешного бизнес-ответа.
После каждого действия сохраняйте минимальное доказательство: класс объекта, длину списка, status code, обязательное поле JSON или порядок событий. Полный prompt и raw payload в журнал не нужны.
Копируемый пример
Сохраните пример как отдельный файл языка python. Значения в угловых скобках — заполнители; их нельзя выдавать за реальные digest или идентификаторы.
from agents import Agent, Runner
# input_checks и output_checks — проверенные guardrail-функции проекта.
agent = Agent(
name="support",
instructions="Ответь по правилам поддержки.",
input_guardrails=input_checks,
output_guardrails=output_checks,
)
result = Runner.run_sync(agent, "Обезличенный запрос T-781")
assert len(result.input_guardrail_results) == len(input_checks)
assert len(result.output_guardrail_results) == len(output_checks)
summary = {
"input_checks": len(result.input_guardrail_results),
"output_checks": len(result.output_guardrail_results),
}
print(summary)
Python запускайте в virtualenv проекта, JavaScript — как .mjs в Node.js с fetch. Не смешивайте глобальную и проектную версии. Если импорт отсутствует, сначала проверьте установленную версию, а не подбирайте похожий API.
Реалистичный вход
Вход A проходит одну input- и одну output-проверку. Вход B специально нарушает детерминированное тестовое правило input guardrail.
Ожидаемый результат
Для A оба списка содержат ожидаемое число записей. Для B run прерывается tripwire, и приложение не публикует обычный финальный ответ.
Ожидание перенесите в assert или throw. Если текст модели недетерминирован, сравнивайте структурный инвариант. Если API возвращает массив, проверяйте число элементов и форму каждого.
Негативная проверка
Удалите guardrails из Agent, но оставьте проверку all([]). Такой тест ошибочно проходит; замените его строгой проверкой ожидаемого количества.
Негативный тест должен ломать ровно одно условие. Сетевая ошибка не равна 404, пустой список не равен PASS, новый запуск не равен resume, а локально созданный UUID не равен response ID провайдера.
Готовый prompt для ревью
Проверь guardrail-аудит: пустые списки не считаются PASS, tool guardrails не смешаны с agent guardrails, output_info не логируется целиком, для tripwire есть отдельный тест.
Верни таблицу: условие, доказательство из кода или очищенного лога, 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, считаем вызовы модели и инструментов, не записываем секреты и проверяем порядок событий агентного запуска.
Комментарии
Пока тихо. Скажите первое слово