В 2026 ГОДУ DEEPSEEK HARNESS
сохранять сессии в JSONL или SQLite?

Сессия DeepSeek Harness после сбоя открывается, но часть последних событий не находится или поиск по десяткам диалогов становится ручной работой.

Быстрое решение: для личного запуска и простого резервного копирования сначала проверяйте JSONL; SQLite выбирайте только при реальной потребности в структурированных запросах и работе на надёжном локальном диске. На сетевом диске не переносите настройки WAL без отдельной проверки блокировок и восстановления.

Эта статья рассчитана на независимых разработчиков, которые долго хранят кодовые или аналитические сессии, на команды эксплуатации, управляющие несколькими сессиями на облачном Mac, и на владельцев платформ, которым нужно формализовать аудит, резервное копирование и восстановление. По состоянию на 19 августа 2026 года DeepSeek Harness остаётся Developer Preview, а официальный репозиторий прямо предупреждает о возможных несовместимых изменениях. (github.com)

Сначала отделите три разных слоя хранения

Главная ошибка — считать, что выбор JSONL или SQLite автоматически решает все задачи хранения. В DeepSeek Harness нужно разделять:

1. Персистентный журнал сессии — первичные события диалога, вызовы инструментов, результаты и состояние, необходимое для продолжения.
2. Проекцию или производное состояние — заголовки, статистику, отображаемые значения и другие данные, которые можно восстановить из журнала.
3. Индекс запросов — отдельный механизм поиска и фильтрации, который не обязательно заменяет первичное хранилище.

Официальная структура проекта выделяет два бэкенда именно для постоянного хранения сессий: JSONL и SQLite. При этом пакет запросов к сессиям вынесен отдельно и включает SQLite-поиск по тексту. Следовательно, включение поиска не означает, что весь исходный журнал обязательно нужно переводить в SQLite. ([github.com](https://github.com/deepseek-ai/deepseek-harness/tree/master/packages/session))

Это различие влияет на резервное копирование. Копия JSONL-файлов — это копия первичного журнала. Копия SQLite-файла — это копия базы данных, но не всегда безопасный снимок активной базы, если процесс продолжает запись. Отдельный индекс можно пересоздать, а потерю первичных событий — уже нет.

Где DeepSeek Harness сохраняет сессии по умолчанию? Официальное руководство указывает, что процесс использует каталог, из которого он был запущен, как базовое расположение файловой системы. В Web UI рабочее пространство сначала нужно выбрать отдельно, поэтому наличие созданного файла ещё не доказывает, что вы нашли корень сессий. (github.com)

Перед выбором бэкенда зафиксируйте:

• каталог запуска и выбранное рабочее пространство;
• фактический путь к журналу или базе;
• кодировку файлов;
• права пользователя, от имени которого работает процесс;
• способ остановки и запуска;
• место, куда будет доставляться резервная копия.

На облачном Mac эта проверка особенно важна: каталог может находиться внутри временного рабочего окружения, а резервное копирование домашней директории не обязательно включает выбранный рабочий путь.

Первый сценарий: один разработчик и короткий срок хранения

Если вы тестируете Harness самостоятельно, работаете с одной машиной и сохраняете сессии поштучно, JSONL обычно проще проверить и передать. Каждая запись остаётся текстовой строкой, поэтому вы можете быстро проверить:

find "$SESSION_ROOT" -type f -name '*.jsonl' -print
file "$SESSION_FILE"
sed -n '1,5p' "$SESSION_FILE"
tail -n 5 "$SESSION_FILE"

Команды здесь являются примером проверки, а не утверждением о конкретном имени переменной или каталога в вашей конфигурации. Подставьте фактический путь, который вы получили из конфигурации и журнала запуска.

Преимущество такого подхода не в том, что расширение .jsonl гарантирует надёжность. Оно не гарантирует. Преимущество — в низкой стоимости диагностики:

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

Но у JSONL есть ограничения. При большом количестве событий ручной поиск становится медленным, параллельная запись требует аккуратной координации, а автоматическая фильтрация по времени, инструменту или типу события обычно требует отдельного скрипта или индекса.

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

Подходит ли JSONL для длительного запуска? Да, если вы оцениваете его не по расширению, а по четырём доказательствам: дописывание событий, поведение после обрыва процесса, повторное открытие сессии и восстановление из холодной копии. Для длительного Agent JSONL может быть рабочим вариантом, но это должно подтверждаться вашим сценарием остановки и версией Harness.

Второй сценарий: длительный Agent и постоянная запись

В длительной сессии важна не только возможность прочитать старые сообщения. Вам нужно понимать, на каком событии система остановилась и может ли она безопасно продолжить работу после:

• принудительного завершения процесса;
• перезагрузки Mac;
• разрыва удалённой оболочки;
• кратковременной ошибки записи;
• повторного запуска с тем же рабочим каталогом.

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

SQLite предлагает транзакционную модель и удобнее для согласованных изменений, но это не отменяет необходимости тестирования. Нужно проверить, как конкретная реализация Harness открывает соединение, когда фиксирует транзакцию, какие файлы создаются рядом с основной базой и что происходит при восстановлении после незавершённой записи.

Официальный пакет сессий подтверждает наличие отдельного SQLite-бэкенда, но сам факт его наличия не является обещанием одинакового поведения между версиями. Для Developer Preview это особенно важно: конфигурация и формат могут измениться вместе с несовместимыми изменениями в проекте. (github.com)

Тест, который стоит выполнить до длительной работы

1. Создайте новую тестовую сессию с заранее известным идентификатором или легко узнаваемым первым сообщением.
2. Выполните несколько действий, включая запись результата инструмента.
3. Убедитесь, что новые события появились в фактическом хранилище.
4. Завершите процесс принудительно, а не через обычную кнопку выхода.
5. Перезапустите Harness с тем же каталогом и теми же параметрами.
6. Откройте исходную сессию и проверьте последний подтверждённый результат.
7. Сравните восстановленную историю с исходным журналом или контрольным экспортом.
8. Повторите запуск уже после перезагрузки Mac.

Считать бэкенд пригодным для постоянного Agent можно только после прохождения этой последовательности. Если после сбоя сессия открывается, но теряет последнее действие, это нужно зафиксировать как ограничение восстановления, а не скрывать за формулировкой «база не повреждена».

Третий сценарий: много сессий, поиск и аудит

Когда у вас появляются десятки или сотни сессий, решение меняется. Вам может понадобиться быстро найти:

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

В такой ситуации SQLite получает преимущество благодаря структурированным запросам и индексации. Официальный пакет session-query отдельно описывает логические записи, ограниченные чтения, связи между событиями, фильтрацию и SQLite full-text search. Это делает SQLite особенно интересным для командного аудита и внутренней панели поиска. ([github.com](https://github.com/deepseek-ai/deepseek-harness/tree/master/packages/session-query))

Но не смешивайте две задачи. Если вы добавили поисковый индекс, это ещё не означает, что индекс стал источником истины. Надёжная схема выглядит так:

• первичный журнал хранит события;
• индекс ускоряет поиск;
• резервная копия сохраняет первичный журнал и необходимые метаданные;
• индекс при необходимости пересоздаётся после восстановления.

Для JSONL можно построить производный индекс отдельно, не меняя формат исходных сессий. Это часто разумный компромисс для команды, которая хочет сохранить простое архивирование, но добавить быстрый поиск. В таком варианте вы не обязаны мигрировать все исторические файлы только ради фильтрации.

Оценка по этому сценарию:

• JSONL как первичное хранилище — 5/5 за прозрачность копирования, 3/5 за массовый поиск.
• SQLite как первичное хранилище — 4/5 за структурированные запросы, 3/5 за переносимость при изменении версии.
• JSONL плюс отдельный индекс — 4/5 за баланс, но 2/5 за операционную сложность, потому что нужно контролировать актуальность индекса.

Четвёртый сценарий: локальный диск против сетевого каталога

На локальном диске SQLite и JSONL нужно оценивать по обычным требованиям: стабильные блокировки, корректная синхронизация, предсказуемое завершение записи и возможность восстановить файлы после сбоя.

Сетевой каталог добавляет другой класс рисков. SQLite WAL использует дополнительные файлы и рассчитывает на согласованное поведение блокировок и общей памяти. Документация SQLite отдельно предупреждает, что WAL рассчитан на процессы, находящиеся на одном компьютере, и не является универсальным режимом для сетевой файловой системы. (github.com)

Можно ли размещать SQLite WAL на сетевом диске? Нельзя считать это безопасным по умолчанию. Сначала проверьте конкретный протокол, клиент Mac, режим монтирования и реализацию файлового сервера. Если хотя бы один из тестов ниже не проходит, базу нужно оставить на локальном диске, а на сетевой ресурс отправлять только остановленную копию или экспорт:

1. Запишите события при активном процессе.
2. Проверьте наличие основной базы и сопутствующих файлов.
3. Остановите процесс во время записи.
4. Убедитесь, что после повторного запуска сессия открывается.
5. Проверьте, исчезают ли временные файлы после корректного завершения.
6. Выполните копирование на другой каталог и проверку целостности.
7. Повторите тест после краткого отключения сетевого ресурса.

JSONL на сетевом каталоге тоже не становится автоматически надёжным: задержка, кэширование и разрыв соединения могут оставить неполный хвост или создать ошибочное представление о завершении записи. Поэтому для облачного Mac практическое правило такое: рабочее хранилище — локальный диск, сетевой каталог — место доставки резервных копий, если это подтверждено тестом восстановления.

**Важно:** не используйте расширение файла как замену проверке. Файл с правильным именем может быть неполным, а база, которая открывается после сбоя, может не содержать последнюю подтверждённую операцию.

Пятый сценарий: миграция между бэкендами и возврат

До миграции не удаляйте старое хранилище и не заменяйте его символической ссылкой на новый каталог. Сначала создайте независимую точку возврата.

Рабочая последовательность:

1. Запишите версию DeepSeek Harness, дату проверки, конфигурационные ключи и путь к хранилищу.
2. Остановите процесс и сохраните старый бэкенд в режиме «только чтение».
3. Зафиксируйте контрольный набор сессий: короткую, длинную, аварийно завершённую и содержащую вызов инструмента.
4. Включите новый бэкенд только для небольшой тестовой группы.
5. Выполните штатное продолжение, аварийный перезапуск и поиск по контрольным сессиям.
6. Сравните число событий, последний подтверждённый результат и доступность старых записей.
7. Только после этого расширяйте миграцию.
8. При расхождении вернитесь к старому бэкенду, не перезаписывая исходную копию.

**Как проверить старые записи после замены бэкенда?** Не ограничивайтесь тем, что список сессий отображается. Для каждой контрольной записи проверьте идентификатор, первое сообщение, последнее подтверждённое событие, наличие результатов инструментов и возможность продолжить работу. Если старое хранилище читается только экспортом, это нужно указать в эксплуатационной документации.

Поскольку DeepSeek Harness находится в предварительной стадии, нельзя обещать прямую совместимость между версиями. Официальный репозиторий прямо предупреждает о compatibility-breaking changes, поэтому при каждом обновлении сохраняйте не только файлы, но и конфигурацию, версию и результат восстановления. (github.com)

Как принять решение перед запуском на облачном Mac

Сначала ответьте на три вопроса:

• Вам нужно копировать отдельные сессии вручную или искать по большому архиву?
• Процесс работает на локальном диске или пишет прямо в сетевой каталог?
• Вы готовы самостоятельно обслуживать индексы, WAL-файлы и процедуру миграции?

Используйте эту оценку как операционный фильтр, а не как обещание производительности: <

Критерий	JSONL	SQLite	Решение
Один пользователь, короткий тест	5/5	3/5	Начните с JSONL
Резервное копирование отдельных сессий	5/5	3/5	JSONL проще проверять и доставлять
Большой архив и структурированный поиск	3/5	5/5	Оцените SQLite или отдельный индекс
Длительная запись	4/5 после теста	4/5 после теста	Выбирайте по результатам сбоя и восстановления
Локальный диск	4/5	5/5	SQLite получает преимущество при запросах
Сетевой каталог	3/5 после проверки	1/5 без отдельной проверки WAL	Не переносите SQLite автоматически
Миграция в Developer Preview	4/5	3/5	Храните старый бэкенд и контрольный экспорт
Человеческая проверка	5/5	2/5	JSONL удобнее для первичной диагностики

Если ваша главная цель — не потерять отдельные сессии и упростить резервное копирование на облачном Mac, выбирайте JSONL и добавляйте производный индекс только при появлении реальной потребности в поиске. Если команда регулярно фильтрует события, строит аудит и работает на локальном диске, SQLite заслуживает отдельного пилотного запуска.

Для подготовки самого Mac сначала проверьте рабочий каталог и удалённый доступ по руководству по M4 и удалённой работе, а требования к окружению сопоставьте с доступными вариантами аренды Mac. Эти шаги не заменяют тест Harness, но уменьшают риск, что сессии окажутся в неучтённом временном каталоге.

Ваша текущая схема может быть дешевле или привычнее, но у неё часто есть три слабых места: сетевой диск скрывает ошибки блокировок, ручные JSONL-архивы плохо ищутся, а локальная машина не всегда готова к длительному процессу и повторной проверке после сбоя. Если вам нужно временное окружение для сравнения JSONL и SQLite, миграционного пилота или контрольного восстановления, аренда Mac через MACGPU позволяет отделить эксперимент от вашей основной рабочей станции. Для постоянной тяжёлой нагрузки, физических интерфейсов или долгосрочного хранения без собственной процедуры резервного копирования аренда не заменяет полноценную инфраструктуру — в этих случаях сначала зафиксируйте требования к владению диском и ответственности за восстановление.