截至 2026 年 8 月 19 日，官方 README 仍將 DeepSeek Harness 列為 developer preview，並明確警告可能出現相容性破壞變更。官方 README (github.com)

症狀：你只看到會話檔案已經生成，卻不知道中斷後能否恢復，或把 SQLite 搬到網路掛載盤後才發現鎖定異常。 最快解法：單人單機、短期試用先驗證 JSONL；需要結構化查詢時，才在可靠的本地硬碟評估 SQLite，網路掛載盤則必須先完成鎖定與故障恢復測試。

先按使用場景決定，不要按副檔名決定

這篇適合三類讀者：第一類是長期保留編碼或分析會話、希望逐會話備份的獨立開發者；第二類是在雲端 Mac 管理較多會話、需要查詢與遷移的運維團隊；第三類是正在制定會話審計、恢復與儲存交付標準的平台負責人。

目前官方列出的會話持久化選項包括 JSONL 與 SQLite，但「可設定」不等於「在你的磁碟和工作方式上已經驗證」。你真正要判斷的是：

  • 寫入中的會話在程式異常結束後，能否保留最後一個可辨識事件；
  • 重新啟動後，Harness 能否找到並續跑原會話；
  • 備份副本是否能在另一個乾淨環境中被讀取；
  • 團隊需要的是原始事件保存，還是高頻率的條件查詢；
  • 失敗時由誰保留舊後端、誰負責恢復，以及多久內完成回退。
因此，JSONL 不是天然「簡陋但安全」，SQLite 也不是天然「專業且可靠」。後端是否合格，要由斷進程、重啟、續跑和備份恢復證據決定。

先用這張選擇表縮小範圍

<
決策維度優先評估 JSONL優先評估 SQLite
任務規模單人、單機、短期或少量長期會話團隊管理大量會話，需按事件、時間或狀態篩選
備份方式逐檔複製、人工抽查、以會話為單位交付需要一致性快照、資料庫查詢或集中化工具
寫入型態事件持續追加，但同一時間主要只有一個寫入者需要索引、關聯欄位與較多讀取工作
磁碟位置本地硬碟、可直接讀取的工作目錄可靠的本地硬碟，且能管理 WAL、鎖定與備份
網路掛載只把完成後的檔案當備份交付物不應直接照搬 WAL；必須先驗證檔案系統與鎖定
失敗回退保留舊檔案並重新複製相對直觀需要處理資料庫檔案、-wal、-shm 及一致性
評分建議備份便利性 **5/5**、人工檢查 **5/5**、查詢能力 **2/5**備份便利性 **3/5**、人工檢查 **2/5**、查詢能力 **5/5**
這個評分不是官方效能測試，而是針對運維責任的決策分數。若你的主要問題是「每個會話能不能獨立交付」，JSONL 通常更容易先做出可驗收流程；若主要問題是「如何從大量會話中找出符合條件的事件」，SQLite 才值得增加複雜度。

單人單機先驗證 JSONL 會話存儲

短期試用和單人本地開發，優先選擇容易檢查、容易複製的方案。這裡的「容易」不是指把檔案拖到另一個資料夾，而是你能在沒有原始執行環境的情況下回答：檔案是否完整、編碼是否正確、最後事件是否存在，以及副本能否重新被 Harness 讀取。

你至少要核對四件事：

  1. 會話根目錄：從目前生效的設定確認真正的持久化目錄，不要只看專案工作目錄，也不要根據網路文章猜固定路徑。
  2. 物理編碼：抽查 JSONL 是否為預期的 UTF-8，並確認每一行都是獨立可解析的 JSON 記錄；不要只依賴文字編輯器顯示正常。
  3. 關閉後可讀性：正常退出後，用獨立檢查工具讀取最後幾行，確認沒有只存在於記憶體中的未落盤內容。
  4. 最小恢復任務：複製一個代表會話到乾淨目錄，重新開啟並完成一個短續跑，記錄恢復結果，而不是只確認檔案存在。
JSONL 會話存儲的優點是每個檔案可按會話交付，備份工具也容易採用「新檔案複製、舊檔案唯讀保留」的策略；限制則是查詢通常需要逐行掃描，當會話數量增加後，檢索、去重和事件關聯都可能轉移到額外腳本或派生索引上。

**提醒：**持續追加檔案仍然可能在異常終止時留下最後一行未完成記錄。驗收標準應該是「重開後能否辨識並恢復」，不是「檔案看起來像完整 JSON」。

長期 Agent 要用中斷證據判斷持久化

長期 Agent 的風險不在於每天多寫幾行，而在於寫入、工具事件、上下文壓縮和重新啟動之間的時間差。你應該準備一個代表任務，讓它至少產生使用者輸入、模型回應、工具呼叫、工具結果和下一輪續跑所需的事件，再執行以下測試：

  1. 啟動會話並記錄目前會話識別資訊。
  2. 在持續寫入期間，直接終止進程，不先執行正常退出。
  3. 重新啟動 Harness，確認會話仍出現在清單或指定的恢復入口。
  4. 重新開啟會話，核對最後一個完整事件和續跑上下文。
  5. 再完成一輪工具操作，確認恢復後不是只能讀取歷史，而是能繼續寫入。
  6. 重新啟動一次，確認第二次恢復沒有因第一次修復而產生重複或遺失。
如果 JSONL 通過這組測試，便可以用於長期單機 Agent；如果 SQLite 通過，才有理由把它納入長期運維標準。任何一種後端只完成「正常關閉後重新開啟」都不夠，因為真正的事故通常發生在進程被中斷、遠端工作階段斷線或主機重啟時。

團隊查詢時分離原始後端與查詢索引

團隊常見的錯誤，是把「需要搜尋」直接等同於「必須把所有會話改存 SQLite」。其實應先區分三層：

  • 會話持久化後端：保存原始事件與恢復所需內容，JSONL 或 SQLite 都可能承擔這個角色。
  • 派生查詢索引：從原始會話抽取時間、工作區、工具名稱、錯誤類型或任務狀態，供團隊快速篩選。
  • 普通檔案備份：把完成的會話、索引和設定快照交付到另一個位置，目標是恢復，不是提供即時查詢。
如果團隊只需要每週查一次會話，可以保留 JSONL 作為來源，再建立一個可重建的索引。這樣更換索引工具不會同時破壞原始會話。只有當查詢已成為日常操作，例如需要按工作區、事件類型和時間範圍反覆追蹤，才值得評估 SQLite 作為本地查詢層。

SQLite 的優勢在於結構化條件、索引和關聯查詢；代價是備份責任更高，不能把一個正在寫入的資料庫當成普通文字檔隨手複製。SQLite 官方提供 Online Backup API，用來在來源仍運作時建立一致性快照，並說明直接複製活躍資料庫可能受鎖定和中斷影響。SQLite Online Backup API (sqlite.org)

本地硬碟與網路掛載要分開驗收

SQLite 的 WAL 模式會使用與資料庫同目錄的 -wal 和 -shm 檔案；其中 -shm 用於協調 WAL 索引，並不是可忽略的普通暫存檔。SQLite 官方文件明確指出，WAL 需要同一主機上的程序共享記憶體，因此不能把跨主機網路檔案系統視為一般本地硬碟使用。SQLite WAL 文件 (sqlite.org)

在雲端 Mac 上，你應該採用以下邊界：

  • 把正在寫入的 SQLite 資料庫放在雲端 Mac 的本地硬碟；
  • 將完成的備份或快照交付到共享目錄，而不是讓多台主機同時開啟同一個 WAL 資料庫；
  • 若必須使用網路掛載，先測試單一主機、單一程序和多程序三種情況；
  • 執行鎖定測試、異常中斷測試、重開測試，再做完整性檢查；
  • 確認備份流程是否同時處理主資料庫、WAL 和設定，而不是只複製副檔名為 .db 的檔案。
SQLite 的鎖定文件也提醒，某些網路檔案系統的 advisory lock 可能不可靠，官方甚至建議最穩妥的防線是不要把 SQLite 檔案放在網路檔案系統上。[SQLite 鎖定與並行文件](https://www.sqlite.org/lockingv3.html) ([sqlite.org](https://www.sqlite.org/lockingv3.html?utm_source=openai))

依照五個步驟完成一次可回退的選型

不要先改正式環境。你可以按下面順序建立小批量驗收：

  1. 記錄版本與設定：保存 Harness 版本、目前啟用的後端、會話根目錄、日誌模式、磁碟類型和主機位置。開發者預覽期間，這些欄位就是日後重現問題的最低條件。
  2. 建立代表任務：不要只用空白會話，應包含文字輸入、工具操作、錯誤事件和一次續跑，讓測試覆蓋真正的事件流。
  3. 執行四種生命週期測試：正常關閉、直接終止、主機重啟後重新開啟，以及恢復後再寫入。每次都保存會話清單、最後事件與恢復結果。
  4. 測試備份交付：JSONL 以逐檔副本測試；SQLite 則用一致性備份方式建立快照，再於另一個乾淨目錄檢查。不要把「複製成功」當成「可恢復」。
  5. 設定失敗回退：舊後端只讀保留，新後端只匯入小批量；只要會話數量、最後事件、續跑或查詢結果有一項不一致，就停止遷移並回到舊副本。
  6. 建立驗收紀錄：把測試日期、版本、磁碟、掛載方式、退出方式、恢復結果和負責人寫入交付紀錄。下一次升級時重跑代表任務，不要沿用上一版本的口頭結論。
更換後端時，不能承諾跨版本直接複用。官方目前已確認仍在 developer preview，並警告會出現 compatibility-breaking changes；因此舊後端唯讀保留不是多餘工作，而是你在版本變動期間的回退保險。[DeepSeek Harness 官方儲存庫](https://github.com/deepseek-ai/deepseek-harness) ([github.com](https://github.com/deepseek-ai/deepseek-harness))

FAQ：把長尾問題放進恢復責任裡

會話根目錄不能只靠預設值

如果你不知道 DeepSeek Harness 預設會把會話保存在哪裡，就先不要安排備份工作。以目前啟用的設定為準，建立測試會話後再用檔案時間、內容和權限反向確認根目錄。雲端 Mac 還要記錄該目錄位於本地硬碟還是網路掛載，因為同一個設定鍵在不同檔案系統上的恢復風險不同。

JSONL 適合長期運行，但不等於免驗收

JSONL 會話存儲適合需要逐會話備份、人工抽查和簡單交付的場景。長期 Agent 使用時，必須確認追加寫入在異常終止後能被重新解析，並且恢復後可以繼續寫入。若你需要大量跨會話查詢，可以保留 JSONL 為原始來源，再建立可重建的派生索引。

SQLite WAL 與網路掛載不是同一個問題

「SQLite 能不能用」和「SQLite WAL 能不能放在網路掛載盤」是兩個問題。可靠本地硬碟上的 SQLite 可以有清楚的單機鎖定假設；跨主機網路掛載則涉及共享記憶體、檔案鎖定、快取和中斷後恢復。未完成實測前，不應把本地成功結果外推到共享目錄。

後端遷移要先保留可讀舊副本

更換會話後端後，舊記錄的驗證不應只看匯入命令是否回傳成功。你要比較代表會話的事件數、最後事件、重新開啟結果、續跑結果和查詢結果；其中任何一項失敗，就保留新後端供分析，但讓正式流程回退到舊後端。

最後的選擇：先判斷你的當前方案，再決定是否用雲端 Mac

如果你現在把會話放在一般文字檔、同步資料夾或未驗證的網路掛載盤，常見缺點是：備份可能抓到未完成寫入、多人同時修改時缺少明確鎖定、恢復時沒有版本與設定紀錄，而且資料夾看似同步完成，實際上不代表 Harness 能重新開啟會話。

相較之下，雲端 Mac 可以把正在寫入的後端放在本地硬碟，將備份和交付流程獨立出去，並用固定環境重做中斷、重啟和續跑驗收。若你需要臨時測試遠端持久化、交付一套可重現的 Mac 環境，或不想先承擔長期硬體維護，MACGPU 會比未驗證的共享目錄更容易建立責任邊界。你可以先查看 MACGPU 雲端 Mac 方案，再依任務持續時間、查詢需求和磁碟類型填完選擇表；若要進一步部署遠端環境，請從 MACGPU 官方入口 了解適合你的交付方式。