Как хранить историю агента в MongoDBSession

from_uri создаёт AsyncMongoClient и передаёт владение сессии. Поэтому close завершает клиент и делает эту session terminal; подключение, жизненным циклом которого управляет приложение, передают через client=. Готовность означает не «код не упал», а наблюдаемый итог из поля ожидаемого результата. Сохраните идентификатор сессии как ключ предметной области: например, номер тикета или идентификатор диалога. Не используйте один и тот же session_id для разных пользователей.

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

Пошаговая настройка

1. Создайте отдельное виртуальное окружение и установите пакет командой pip install openai-agents. Для Dapr, MongoDB и шифрования используйте extra, указанный в официальном разделе соответствующего backend.
2. Скопируйте пример ниже в отдельный файл. Значения session_id, адреса и имена коллекций вынесите в конфигурацию приложения; секреты берите из менеджера секретов или переменных окружения.
3. Запустите пример на тестовом хранилище. Сначала добейтесь прохождения встроенных assert. Они проверяют состояние, а не качество текста модели.
4. Повторите запуск с тем же session_id. Заранее запишите ожидаемое поведение: история должна сохраниться для постоянного backend или начаться заново для памяти процесса.
5. Выполните негативный сценарий из отдельного раздела. Ошибка соединения, пустая история и истёкший TTL — разные состояния; не объединяйте их в один catch с сообщением «памяти нет».
6. Добавьте метрики уровня приложения: название операции, длительность, количество элементов до и после, тип исключения. Содержимое сообщений в метрики не отправляйте.
7. Перед выпуском прогоните два параллельных обращения к разным session_id. Их результаты не должны смешиваться. Для общего backend дополнительно проверьте два процесса или два worker.

Готовый код

import asyncio
from agents import Agent, Runner
from agents.extensions.memory import MongoDBSession

async def main():
    session = MongoDBSession.from_uri(
        "customer-318", uri="mongodb://localhost:27017", database="agents"
    )
    try:
        await session.ping()
        agent = Agent(name="Assistant", instructions="Отвечай кратко")
        await Runner.run(agent, "Мой проект называется Север", session=session)
        result = await Runner.run(agent, "Как называется проект?", session=session)
        print(result.final_output)
        assert len(await session.get_items()) > 0
    finally:
        await session.close()

asyncio.run(main())

Код намеренно использует явные проверки. Заменять assert обычным print в CI не стоит: печать позволяет сборке пройти при неверном состоянии. В production обработайте ожидаемые исключения на границе сервиса, но не скрывайте их внутри адаптера хранения.

Реалистичный пример входа и результата

Вход: Первый запрос сообщает название проекта «Север», второй спрашивает название.

Ожидаемый результат: ping проходит, второй ответ содержит «Север», история читается до close().

Запишите результат в автотесте структурно. Для списка сравнивайте количество, порядок, роли и ключевое содержимое. Для сетевого хранилища выполняйте повторное чтение новым объектом сессии: так тест не пройдёт случайно из-за локального кэша. Если пример запускает модель, отдельно проверяйте состояние session через get_items — формулировка ответа модели может немного меняться.

Негативный тест

После close() вызовите get_items в отдельном контрактном тесте. Для owned-клиента ожидается RuntimeError, что выявляет повторное использование закрытого объекта.

Негативный тест запускайте в отдельном session_id и очищайте его после проверки. Не проверяйте отказ на рабочем диалоге. В отчёте CI сохраняйте тип ошибки и этап — connect, write, read, pop или clear. Это быстро отличает проблему инфраструктуры от нарушения контракта Session.

Как встроить в сервис

Создавайте session на границе запроса или диалога, но не смешивайте идентификатор пользователя с секретом. Передавайте объект в Runner там, где SDK должен автоматически читать прежние элементы и записывать новые. Прямые операции памяти оставьте административному endpoint или сервисному слою с авторизацией. Так пользовательский handler не сможет случайно очистить чужую историю.