Как продолжить диалог Pydantic AI через message_history без смешивания пользователей

До сетевого запуска установите pydantic-ai и настройте ключ провайдера предусмотренным им способом. Примеры не содержат действующих секретов. Для воспроизводимого теста зафиксируйте версии Python, пакета и выбранной модели; после обновления снова выполните как удачный, так и отрицательный сценарий. Вызов run_sync использован для наглядного скрипта вне уже работающего асинхронного цикла. Там, где проект асинхронный, применяйте документированный await agent.run(...) и управляйте ресурсами на стороне приложения.

Готовый шаблон для запуска

from pydantic_ai import Agent

agent = Agent("openai:gpt-5.2",
              instructions="Отвечай только по явно заданному расписанию, иначе уточняй.")
first = agent.run_sync("Учебная справка: выдача партии R-7 во вторник. Когда выдача R-7?")
second = agent.run_sync("А в какой день недели это происходит?",
                        message_history=first.all_messages())
print(first.output)
print(second.output)
print(len(second.all_messages()), len(second.new_messages()))

Конкретный вход и ожидаемый результат

Исходный факт в примере: выдача R-7 — вторник. После первого вопроса пользователь спрашивает: «А в какой день недели это происходит?» Если история передана корректно, второй ответ ссылается на вторник. Без истории местоимение «это» не определяет конкретный объект, и правильнее уточнить предмет вопроса. Для независимого пользователя, который раньше говорил о пятнице, передавать историю R-7 запрещено: это одновременно ошибка качества и риск утечки.

Почему этот способ работает

all_messages() возвращает сообщения диалога с учётом переданной предыдущей истории; new_messages() содержит только шаги текущего запуска. Если во второй вызов требуется полная история, передайте именно подходящую историю первой сессии и проверьте её владельца. Не склеивайте несколько полных историй простым сложением, иначе старые сообщения продублируются и модель может дать неожиданный ответ. Для долговременного хранения документация описывает сериализацию с ModelMessagesTypeAdapter; бесконтрольный JSON пользователя нельзя считать доверенным состоянием сервера. Историю следует ограничивать по объёму и очищать от конфиденциальных данных согласно правилам продукта.

Пограничный случай и предметная проверка

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

Проверяйте случай потери контекста отдельно от неверного факта: когда модель пишет «пятница», имея историю с «вторник», причина может быть в ошибочном выборе истории или в неверном пересказе корректной истории. Сохраняйте идентификатор сессии рядом с диагностическим безопасным набором сообщений, но не отправляйте содержимое разговоров другому пользователю для отладки. После восстановления серверного хранилища запустите продолжение с тем же учебным примером и убедитесь, что ответ остался привязан к R-7.