Гайд · TNWS AI
Как хранить контекст диалога в OpenAI Responses API без дублирования сообщений
Практическая работа с previous_response_id и conversation: продолжение диалога, смена инструкций и контроль истории.
Задача и результат
Этот гайд нужен, чтобы продолжать диалог между запросами, не отправляя вручную всю историю и не смешивая разговоры разных пользователей. На выходе должен быть воспроизводимый сценарий с сохранёнными настройками, контрольным примером и понятным состоянием ошибки. Если процесс нельзя повторить на том же входе, его рано подключать к рабочему продукту.
Сразу разделите три понятия: запрос принят, запрос выполнен и результат верен. Успешный HTTP-статус обычно подтверждает только первый или второй пункт. Истинность ответа проверяется отдельно по данным, документу или результату доверенной функции.
Что подготовить
Понадобятся серверную таблицу разговоров, внутренний user ID и тест из трёх последовательных сообщений. Начинайте с тестовой копии. Удалите персональные данные, ключи, пароли и коммерческие секреты, если обработка не согласована. Для внешних действий используйте учётную запись с минимальными правами.
Создайте таблицу тестов: case_id, вход, ожидаемый статус, ожидаемый результат, фактический результат, время, комментарий. Минимальный набор — нормальный запрос, пустой ввод, отсутствие факта, противоречие и временная ошибка сервиса.
Пошаговая настройка
Выберите один механизм состояния. Для простой цепочки можно передавать previous_response_id; для управляемого разговора — использовать conversation, если он подходит архитектуре. Не применяйте их одновременно, когда документация это запрещает.
Сохраняйте связь «пользователь → разговор/последний response ID» только на сервере. Перед каждым запросом проверяйте владельца записи. Учтите, что instructions из предыдущего response могут не переноситься при использовании previous_response_id, поэтому критичные правила задавайте заново согласно документации. Добавьте действие «начать новый диалог», которое создаёт чистую ветку, а не просто очищает интерфейс. Тестируйте параллельные вкладки: ответ одной не должен менять контекст другой.
После настройки сохраните точную версию кода, имя модели, параметры и дату проверки. Идентификаторы внешних ресурсов связывайте с внутренним case_id. Это позволяет безопасно продолжить процесс после перезапуска и не создавать дубликаты.
Копируемый промпт или шаблон
Ты помощник по заказу. В каждом ходе используй только данные текущего диалога и результата функций. Не переноси сведения из других клиентов. Если пользователь начинает новый заказ, попроси новый order_id.
Замените значения в квадратных скобках. Не добавляйте просьбы «додумать» отсутствующие факты. Для автоматизации заранее определите допустимый JSON и валидируйте его программно до любого действия.
Реалистичный пример
Вход
Ход 1: «Заказ 5842». Ход 2: «Какой у него статус?» Ход 3 в другой вкладке: «Заказ 9001».
Ожидаемый результат
Первая цепочка связывает местоимение с 5842; вторая вкладка работает с отдельной веткой 9001 и не перезаписывает первый контекст.
Теперь измените один элемент: уберите обязательное значение или добавьте конфликт. Система должна показать понятный статус и не продолжить опасную ветку. Если она выдаёт правдоподобный ответ, усилите схему и добавьте серверную проверку.
Проверка результата
Техническая проверка: формат разбирается, ID сохранён, секреты отсутствуют, ошибка имеет отдельное состояние. Смысловая проверка: минимум три утверждения сверены с исходником, включая число, дату и отрицание. Процессная проверка: повтор после таймаута не создаёт второе письмо, платёж, запись или публикацию.
Меняйте один параметр за раз. Если одновременно заменить модель, инструкцию и данные, нельзя понять, что повлияло на качество. Старую рабочую конфигурацию сохраняйте до окончания регрессионной проверки.
Чек-лист перед запуском
- есть измеримый критерий готовности;
- определены состояния успеха, ожидания и ошибки;
- тестовые данные не содержат лишних персональных сведений;
- ключи хранятся вне кода и промпта;
- параметры сверены с официальной документацией;
- обычный, пустой и противоречивый кейсы проверены;
- отсутствующие данные не заменяются догадкой;
- повторная обработка защищена от дублей;
- важные числа и ссылки сверены вручную;
- есть владелец процесса и журнал изменений.
Как вести журнал качества
Для каждого запуска достаточно хранить case_id, версию инструкции, технический статус, найденный дефект и решение проверяющего. Полный чувствительный текст в обычный журнал не копируйте. После обновления SDK или модели прогоните старый набор целиком.
Разбирайте ошибки по классам: неверный вход, авторизация, ограничение сервиса, временная сеть, неверный формат и смысловая ошибка. Для каждого класса заранее решите: повторить, запросить уточнение, передать человеку или окончательно остановить. Универсальный автоматический retry опасен для операций записи.
Приёмка и безопасный откат
Перед включением для реальных пользователей проведите короткую приёмку вдвоём: исполнитель запускает сценарий по инструкции, а проверяющий видит только журнал и результат. Если проверяющий не может установить, откуда взялось ключевое значение, процесс считается непрозрачным и возвращается на доработку.
Подготовьте откат заранее. Для изменения конфигурации это предыдущая версия файла или промпта; для внешней записи — компенсирующее действие, согласованное владельцем системы. Откат нельзя поручать модели без проверки, потому что он сам может быть необратимым. Зафиксируйте условие выключения: рост ошибок определённого класса, нарушение формата, недоступность источника или подозрение на утечку данных. После выключения сохраните пример сбоя и не включайте процесс снова, пока он не проходит исходный набор тестов.
Отдельно проверьте документацию для выбранного языка программирования: названия объектов SDK могут отличаться, хотя HTTP-схема остаётся той же. Не смешивайте примеры разных версий библиотеки в одном проекте.
Ограничения
Контекст увеличивает объём обрабатываемых данных и может сохраняться по правилам API. Не используйте историю как замену базе фактов или авторизации. Любые изменяемые сведения — модели, форматы, тарифы, квоты и доступность — перепроверяйте на официальной странице непосредственно перед использованием.
FAQ
Можно ли сразу использовать рабочие данные?
Сначала нужен тест на обезличенной копии, проверка прав и согласованный режим хранения. Факт технической доступности API не является разрешением передавать ему любые данные.
Нужно ли сохранять ID запросов?
Да. Они связывают внутреннюю задачу с внешней операцией, помогают продолжать после сбоя и защищают от повторного выполнения.
Как поступать при таймауте?
Не повторяйте опасное действие вслепую. Сначала запросите фактический статус предыдущей операции либо проверьте целевую систему.
Как понять, что обновление ничего не сломало?
Повторите одинаковый набор тестов и сравните статусы и содержательные поля. Один удачный новый пример не является регрессионной проверкой.
Первоисточник и дата проверки
Названия функций и общий процесс сверены 12 сентября 2026 года: официальная документация OpenAI по conversation state. Цены и численные лимиты не приводятся, поскольку их нужно проверять в момент работы.
Частые вопросы
Можно ли сразу использовать рабочие данные?
Нет, сначала нужен тест на обезличенной копии и проверка правил доступа.
Нужно ли сохранять ID операций?
Да, это помогает продолжать после сбоя и не выполнять действие повторно.
Что делать при таймауте?
Сначала проверить фактический статус предыдущей операции, затем решать о повторе.
Как проверить обновление?
Повторить прежний набор обычных, пустых и ошибочных сценариев.
Читайте также
Как сохранять контекст диалога в OpenAI Responses API без повторной отправки истории
Диалог через previous_response_id: хранение цепочки, инструкции, ветвление, контроль владельца и тест на смешивание пользователей.
Как настроить streaming в OpenAI Responses API и правильно собрать ответ
Потоковая выдача OpenAI: stream:true, типы SSE-событий, text delta, завершение, tool calls и восстановление после обрыва.
Как подключить удалённый MCP-сервер к OpenAI API и проверить его инструменты
Remote MCP в Responses API: адрес сервера, список инструментов, approvals, проверка аргументов и защита от prompt injection.
Комментарии
Пока тихо. Скажите первое слово