Перейти к основному содержанию
По умолчанию SDK записывает стенограммы сеансов в файлы JSONL в папке ~/.claude/projects/ на локальной файловой системе. Адаптер SessionStore позволяет зеркалировать эти стенограммы в собственный бэкенд, такой как S3, Redis или база данных, чтобы сеанс, созданный на одном хосте, можно было возобновить на другом. Основные причины использования хранилища сеансов:
  • Развертывания на нескольких хостах. Бессерверные функции, автомасштабируемые рабочие процессы и CI-раннеры не используют общую файловую систему. Общее хранилище позволяет любой реплике возобновить любой сеанс.
  • Надежность. Локальные контейнеры являются временными. Хранилище, поддерживаемое S3 или базой данных, сохраняется при перезагрузках и переразвертываниях.
  • Соответствие и аудит. Сохраняйте стенограммы в хранилище, которым вы уже управляете, с собственными правилами хранения, шифрованием и контролем доступа.

Интерфейс SessionStore

SessionStore — это объект с двумя обязательными методами, append и load, и тремя необязательными методами. SDK вызывает append для записи записей стенограммы во время запроса и load для их чтения при возобновлении.
SessionKey адресует одну стенограмму. projectKey — это стабильное, безопасное для файловой системы кодирование рабочей директории, sessionId — это UUID сеанса, а subpath устанавливается, когда запись принадлежит стенограмме подагента или файлу сайдкара, а не основному разговору. Рассматривайте subpath как непрозрачный суффикс ключа; он следует макету на диске, например subagents/agent-<id>. Когда subpath не определен, ключ ссылается на основную стенограмму.

Быстрый старт

SDK поставляется с InMemorySessionStore для разработки и тестирования. Пример ниже запускает запрос с подключенным хранилищем, захватывает ID сеанса из результирующего сообщения, а затем возобновляет из хранилища во втором вызове query(). Второй вызов передает тот же экземпляр хранилища плюс resume, поэтому SDK загружает стенограмму из хранилища вместо локальной файловой системы:
Второй запрос выводит сводку файлов из первого запроса, что показывает, что агент возобновил работу с полным контекстом из хранилища.

Напишите собственный адаптер

Реализуйте append и load для вашего бэкенда. Добавьте listSessions, delete и listSubkeys, если вы хотите, чтобы listSessions(), deleteSession() и возобновление подагента работали с хранилищем. Записи, переданные в append, типизированы как SessionStoreEntry (объект { type: string; ... }). Рассматривайте их как непрозрачные значения, безопасные для JSON: сохраняйте их по порядку и возвращайте из load в том же порядке. load должен возвращать записи, которые глубоко равны тому, что было добавлено; сериализация, равная по байтам, не требуется, поэтому бэкенды, такие как Postgres jsonb, которые переупорядочивают ключи объектов, подходят.

Эталонные реализации

Репозиторий TypeScript SDK включает запускаемые эталонные адаптеры для S3, Redis и Postgres в examples/session-stores/. Они не опубликованы в npm; скопируйте нужный файл src/ в ваш проект и установите соответствующий клиент бэкенда. Каждый адаптер принимает предварительно настроенный экземпляр клиента, поэтому вы контролируете учетные данные, TLS, регион и пулинг. Например, с S3:
TypeScript

Проверьте ваш адаптер

Оба SDK поставляются с набором соответствия, который утверждает поведенческий контракт, который должны удовлетворять append, load и необязательные методы. Тесты для необязательных методов автоматически пропускаются, когда эти методы не реализованы. В TypeScript скопируйте shared/conformance.ts из директории примеров в ваш набор тестов. В Python набор поставляется в пакете:
Python

Примечания о поведении

Архитектура двойной записи

Хранилище — это зеркало, а не замена. Подпроцесс Claude Code всегда сначала записывает на локальный диск; затем SDK пересылает каждый пакет в append(). Если вы хотите, чтобы локальная копия была временной, укажите CLAUDE_CONFIG_DIR на временную директорию в options.env. Поскольку зеркало зависит от локальных записей, sessionStore не может быть объединен с persistSession: false; SDK выбрасывает исключение, если вы установите оба. Он также выбрасывает исключение, если объединен с enableFileCheckpointing, поскольку резервные копии истории файлов записываются непосредственно на локальный диск и не зеркалируются в хранилище.

Зеркальные записи — это лучшие усилия

Если append() отклоняет, SDK повторяет попытку пакета еще два раза с коротким отступом, всего максимум три попытки. Вызов, который истекает по времени, не повторяется, поскольку исходный вызов может все еще приземлиться. Если пакет все еще не удается, ошибка регистрируется, сообщение { type: "system", subtype: "mirror_error" } выдается в итератор, пакет отбрасывается и запрос продолжается. Локальная стенограмма уже надежна на диске, поэтому сбой хранилища не прерывает агента и не теряет данные локально. Отслеживайте mirror_error, если вам нужно обнаружить потерю данных хранилища. Поскольку повторный пакет может повторно доставить записи, которые уже приземлились, дедублируйте по entry.uuid в вашей реализации append().

getSessionMessages возвращает цепь после компактирования

getSessionMessages({ sessionStore }) возвращает связанную цепь сообщений, которую агент видел бы при возобновлении. После автоматического компактирования более ранние ходы заменяются резюме, поэтому сеанс, чье хранилище содержит 503 необработанные записи, может возвращать 18 сообщений из getSessionMessages. Для полной необработанной истории, включая ходы до компактирования и записи метаданных, вызовите store.load(key) напрямую.

forkSession — это не побайтовая копия

forkSession({ sessionStore }) читает исходные записи, переписывает каждое поле sessionId и переназначает UUID сообщений, затем добавляет преобразованные записи под новым ключом. Копия на уровне адаптера или ярлык CopyObject создали бы стенограмму, которая все еще ссылается на старый ID сеанса, поэтому SDK не использует один.

Стенограммы подагентов

Стенограммы подагентов зеркалируются под subpath: "subagents/agent-<id>". listSubagents({ sessionStore }) требует, чтобы адаптер реализовал listSubkeys; getSubagentMessages({ sessionStore }) использует его, когда доступно, но возвращается к прямому подпути, когда он не определен. Возобновление также вызывает listSubkeys для восстановления файлов подагентов; без него материализуется только основная стенограмма.

Хранение

SDK никогда не удаляет из вашего хранилища самостоятельно. Хранение — это ответственность адаптера: реализуйте TTL, политики жизненного цикла S3 или запланированную очистку в соответствии с вашими требованиями соответствия. Локальные стенограммы в CLAUDE_CONFIG_DIR очищаются независимо параметром cleanupPeriodDays.

Поддерживается на

Следующие функции SDK принимают опцию sessionStore и работают с хранилищем вместо локальной файловой системы, когда она предоставляется: