> ## Documentation Index > Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt > Use this file to discover all available pages before exploring further. # 重新啟動復原 重新啟動閘道不會遺失代理程式狀態。對話、逐字記錄、 排程工作、背景工作記錄及佇列中的外送訊息全都儲存在 磁碟上；閘道重新啟動後，系統會偵測在回合途中中斷的工作並 自動繼續。不需要手動介入，也沒有任何項目需要設定： 復原功能永遠啟用。 本頁說明重新啟動後會保留哪些內容、如何偵測中斷的工作， 以及自動繼續的運作方式。 ## 重新啟動後會保留哪些內容 | 狀態 | 儲存位置 | 重新啟動時的行為 | | ----------- | -------------------------- | ----------------------- | | 對話記錄 | 各代理程式的 SQLite 資料庫 | 不受影響；工作階段會從儲存的逐字記錄繼續 | | 中斷的主要工作階段回合 | 各代理程式的 SQLite 工作階段資料列與逐字記錄 | 啟動數秒後自動繼續 | | 子代理程式執行 | SQLite（共用狀態資料庫） | 開機時還原登錄；中斷的執行會繼續 | | 背景工作 | SQLite（共用狀態資料庫） | 開機時進行調整；復原孤立的執行或將其標示為遺失 | | 佇列中的外送項目 | SQLite 傳送佇列 | 重新啟動後清空佇列；未傳送的回覆會重試 | | 排程（cron）工作 | SQLite cron 儲存區 | 排程會保留；排程器在開機時重新啟用 | | 重新啟動後續作業 | SQLite 重新啟動哨兵 | 將一次性後續作業分派至要求重新啟動的工作階段 | ## 正常重新啟動會先等待工作完成 要求重新啟動（`openclaw gateway restart`、需要 重新啟動的設定變更，或閘道更新）不會立即終止進行中的工作。 閘道會停止接受新工作，接著等待作用中的代理程式回合與 背景工作完成，最多等到排空時間上限（預設為 5 分鐘）。因此，大多數 重新啟動根本不會中斷任何工作。 只有無法在排空時間上限內完成的工作（或遭強制重新啟動或當機 中斷的任何執行）才會中止，而在此之前，每個 受影響的工作階段都會標記為待復原。 ## 如何偵測中斷的工作 三種互補機制會標記回合尚未完成的工作階段： * \*\*控制介面受理時：\*\*對現有主要工作階段的一般文字回合， 閘道會附加使用者訊息、將工作階段標記為執行中，並在 傳回 `started` 確認前，透過單一 SQLite 交易 記錄其僅限逐字記錄的傳送認領。 命令、附件、單回合覆寫、待處理傳送、先前的中止 提示、外掛擁有的工作階段，以及含有執行掛鉤的回合，仍會使用其 專用受理路徑。 * \*\*關機時：\*\*在重新啟動排空期間，所有具有作用中執行的工作階段 都會在執行中止前，於工作階段儲存區中寫入 復原標記。 * \*\*啟動時：\*\*閘道會掃描工作階段儲存區，尋找仍 宣告為執行中、但在新處理程序中沒有存活擁有者的工作階段。這可捕捉 未執行任何關機程式碼的嚴重當機與程序終止。同時也會清除過期的逐字記錄鎖定 檔案。 ## 自動繼續 啟動數秒後，閘道會重新分派每個已標記的工作階段， 並附上合成系統訊息，告知代理程式先前的回合因 重新啟動而中斷，並要求從現有逐字記錄繼續。如果 最終回覆已產生但尚未傳送，其文字會包含在內， 讓代理程式能直接傳送，而不必重新執行工作。復原最多重試 3 次，並採用指數退避。每次重試都會重複使用同一個持久性分派 識別碼，因此模稜兩可的連線失敗不會讓同一項復原 啟動兩次。已完成及無法繼續的控制介面回合也會保留有界的持久性 冪等性墓碑，讓重新連線的寄件匣能移除這些項目，而不會 重新執行要求。 繼續之前，閘道會檢查逐字記錄尾端是否能安全地 接續。如果不能（例如，回合結束於過期的待處理 核准），便不會盲目地重新執行工作階段；代理程式會改為發布簡短 通知，要求使用者重新傳送上一個要求。對 WebChat 而言，該通知會 直接寫入工作階段記錄，因此重新連線後仍然可見。 OpenClaw 也能重建中斷的唯讀[程式碼模式](/zh-TW/reference/code-mode) 工作。程式碼模式會將這些執行標記為可安全重新啟動，並在具有副作用的 目錄工具或外掛命名空間執行前拒絕它們。如果重新啟動發生在 `wait` 控制項上，新閘道會根據逐字記錄重建回合， 並強制重建後的執行維持可安全重新啟動，即使 模型省略或清除該旗標也一樣。主機會將整個重建後的 回合篩選為經稽核的唯讀核心工具及明確可安全重播的外掛工具， 包括重新啟動後停用程式碼模式的情況。具有副作用的工作 仍會由重新傳送通知保護，以免發生重複寫入。 ### 子代理程式 子代理程式執行會持久儲存在共用 SQLite 狀態資料庫中，因此 子代理程式登錄能跨處理程序保留。開機時會還原登錄，並使用原始工作情境 繼續中斷的子代理程式工作階段。 有兩項安全機制： * 超過 2 小時前中斷的執行會直接結束，而不會繼續，因此 關閉一整夜的閘道不會復活過期工作。 * 持續復原失敗的工作階段會標記為卡死墓碑，避免 復原無限循環。 ### 背景工作 [背景工作登錄](/zh-TW/automation/tasks)以 SQLite 為後端， 會在開機時及定期進行調整：已完成執行所記錄的持久性結果 會被復原，而擁有者處理程序已消失的執行則會在 寬限期後標記為遺失，而不是永遠停滯。 ### 代理程式要求的重新啟動 當代理程式本身觸發重新啟動（套用設定變更、更新 閘道，或明確要求重新啟動）時，處理程序結束前會將重新啟動哨兵寫入 SQLite。開機後，閘道會將結果發布回 原始聊天，並分派一次性後續回合，讓 代理程式從中斷處精確接續，且使用相同頻道與討論串。 ## 安全機制與可觀測性 * \*\*當機循環斷路器：\*\*5 分鐘內發生 3 次非正常開機會觸發斷路器， 在下次開機時抑制自動啟動的周邊服務，避免當機的閘道 擴大問題。非正常開機時間窗排空後即會恢復。 * \*\*指標：\*\*復原活動會透過 [Prometheus](/zh-TW/gateway/prometheus)匯出為 `openclaw_session_recovery_total` 與 `openclaw_session_recovery_age_seconds`。 * \*\*日誌：\*\*復原決策會記錄在 `main-session-restart-recovery` 與 `subagent-interrupted-resume` 子系統下。 ## 不會繼續的內容 * 由於已有其他擁有者負責處理，因此排除於主要工作階段復原之外的 工作階段：子代理程式工作階段（子代理程式復原）、cron 工作階段（ 排程器會依排程重新執行），以及由 ACP 管理的工作階段（由連線的 IDE 或用戶端負責繼續）。 * 無法從逐字記錄尾端安全接續的工作階段；這些工作階段會收到 上述重新傳送通知，而不會無聲地重新執行。 * 從未受理的工作：在排空時間窗內送達的訊息 會收到明確的重新啟動錯誤而遭拒絕，不會無聲地排入即將終止的 處理程序。