重新啟動與繼續

每個對話都有自己的 agent，在中繼機器上的背景處理程序中執行。對話本身，包括它的歷史記錄、佇列和草稿，則存在於中繼中。本頁說明兩者如何搭配，讓你知道 Kill session（強制結束 session）、中繼重新啟動或重新開機會讓你付出什麼代價，以及哪些會自行恢復。

簡短來說：你寫下的任何內容都不會遺失。對話的 agent 沒有在執行時，傳給該對話的下一則訊息會再次啟動它，而 agent 會接續供應商自己的 session，而不是從空白的 session 開始。

對話的 agent 處理程序 #

OAR 把這個處理程序稱為 session worker。你不需要啟動它。中繼會在對話需要它時啟動它，通常是在你傳送第一則訊息時，而 worker 會連回中繼，以接收訊息並回報回覆。在安裝了 tmux 的 Linux 和 macOS 上，worker 會在分離的 tmux session 中執行，⋯ 選單中的 Inspect tmux console（檢視 tmux 主控台）可以顯示其中一個。沒有 tmux 時，它們會以一般的背景處理程序執行。

0.9.11 新增 在每個平台上，worker 都以中繼自己的 Node.js 執行，並使用它的完整路徑，所以即使中繼的 PATH 中沒有 node 也能啟動，例如由 Windows 開機任務在任何人登入之前啟動的中繼。COPILOT_WEB_RELAY_NODE 可指定另一個 Node.js（環境變數）。當 worker 的 PATH 中沒有 node 時，該 Node.js 資料夾會加到它的結尾，所以 worker 啟動的 CLI 和指令也找得到一個。

如果無法啟動 worker，對話中會顯示一則註記：

The worker for this conversation could not be started (2 tries). Cause: <reason>. Your message stays queued; the relay tries again every 1 minute until 14:20 UTC.

中繼會每分鐘重試一次，持續 10 分鐘。之後註記會說明它已停止嘗試，並顯示 Retry（重試）按鈕。你的訊息在這段期間一直留在佇列中，worker 一啟動就會送達。在 Windows 上，失敗或一直沒有回應的啟動會立即失敗並指出程式名稱，中繼記錄則會列出指令以及啟動時所用的 PATH。

自行停止 #

Claude 或 DeepSeek 對話，以及 SDK 引擎上的 GitHub Copilot 或 OpenAI 對話，會在沒有任何動靜時釋放記憶體。沒有活動 10 分鐘後，agent 自己的程式會結束，下一則訊息會再次啟動它，並接續同一個供應商 session。worker 處理程序會保留，並維持與中繼的連線。App 中沒有調整這 10 分鐘的設定。

只要有下列任何一種情況，agent 就不會被停止：

• 有回合正在執行，或有回合排在佇列中等它，
• 有提問或權限卡片在等你回答，
• 有背景任務正在執行，或剛結束的背景任務的接續仍待執行。

單靠背景任務，最多只能讓它維持到 Settings → General（設定 → 一般）中的 Background task timeout（背景任務逾時）為止，預設 4 小時；0 表示沒有上限。

0.9.17 新增 DeepSeek 對話在你變更它的模型或 reasoning effort 時，也會重新啟動 agent 的程式，因為 Claude Code 只在啟動時讀取這兩者。重新啟動發生在下一個回合之前、程式中沒有任何東西在執行時，並接續同一個 session。如果程式中仍有背景工作在執行，回合就在現有的程式中執行：新的模型會在其中切換，新的 effort 則要等到重新啟動。

其他供應商沒有這種閒置停止。Claude Cloud、Cursor 或 Grok 的 worker 會持續執行，直到你強制結束 session、封存對話，或機器停止為止。Copilot 擴充功能引擎同樣會讓它的 Copilot CLI 持續執行。已 30 分鐘未使用的 Cursor worker 會關閉它的 agent 控制代碼，並在下一則訊息時重新開啟同一個 Cursor agent。

Kill session #

對話 ⋯ 選單中的 Kill session，或清單中該對話那一列的選單中的同一個項目，會停止 worker 以及它啟動的處理程序。當對話卡住、agent 對 Stop（停止）沒有反應，或你想讓 agent 重新開始以取得新的工具或設定時，就使用它，例如在你開啟 agent session 之後。

會先開啟確認畫面：

Kill the session for <title>?
This stops the current worker and any active turn will need a manual retry or a new message.

之後會有一則簡短通知：Session killed.（Session 已強制結束。）如果沒有找到執行中的處理程序，則改為顯示 Session state cleared; no live worker process was found. 如果有處理程序在嘗試後仍存活，會出現警示 Failed to kill session（強制結束 session 失敗），且不會清除任何東西。

正在執行的回合會以對話中的一則註記結束：This session was killed from the relay UI before the turn completed. 請再次傳送訊息，或寫一則新的。對話、它的歷史記錄和排入佇列的訊息都會保留。下一則訊息會啟動新的 worker，並繼續供應商 session。

封存對話也會停止它的 worker。見對話清單。

無法連到 agent 時 #

當沒有任何 worker 回報達 10 秒時，對話上方會出現橫幅，側邊欄中的狀態列會顯示 CLI offline（CLI 離線）：

⚠️ CLI is offline — messages will queue until it reconnects

這個橫幅屬於中繼，而不屬於某一個對話；在閒置了一段時間的中繼上，出現它可能是正常的。你傳送的訊息會被保留。傳送一則訊息：中繼會啟動對話的 worker，橫幅會在 worker 連線後消失。如果橫幅一直存在，請查看中繼記錄資料夾中的 worker-<session>.log；它的位置見檔案與資料夾。

失去連線的 worker（例如在中繼重新啟動期間）會持續嘗試重新連線，每次嘗試之間最多等待 8 秒。0.9.13 新增 它也會放棄 15 秒內未完成的連線，而且不會等待正在關閉的中繼關閉連線，所以卡住的重新啟動不會再讓它沒有下一次嘗試。每次嘗試失敗都會在它的 worker-<session>.log 中寫入一行附有原因的 worker ws disconnected：前三次都會寫，之後最多每分鐘一次。0.9.11 新增 作為安全網，當有訊息在等待某個 worker、而該 worker 已 60 秒沒有連線時，中繼會取代它：停止舊的處理程序並啟動新的處理程序，由新的處理程序接手該訊息。該 session 有回合或背景工作在執行時，中繼絕不會這麼做；這麼做時，它會記錄一行 WORKER DETACHED。

重新啟動中繼 #

重新啟動中繼，以載入新版本、變更過的設定檔，或新安裝的供應商 CLI。在對話的 ⋯ 選單中選擇 🌄 Restart web relay（重新啟動網頁中繼），或在中繼機器上執行 oar restart。oar update 和 Settings → General 中的 Update（更新）按鈕會在安裝後為你重新啟動它。

重新啟動會等待什麼 0.9.13 新增 #

🌄 Restart web relay 會先顯示重新啟動要等待什麼，以及會讓什麼繼續執行：

• 有回合正在執行的 session，各附上標題；
• 在那之前它會暫緩多少則訊息；
• 有背景任務（指令、監控、subagent）的 session，各標示為會繼續執行或 may stop（可能停止）。中繼從先前的重新啟動保留下來、但其 worker 尚未確認的任務，會列為尚未確認。

有回合在執行時，視窗會提供 🌄 Restart when idle（閒置時重新啟動），將重新啟動排入佇列，以及 Restart now（立即重新啟動），不等待。沒有任何東西在執行時，按鈕是 🌄 Restart web relay，中繼會立即重新啟動。

重新啟動會等待執行中的回合 #

重新啟動不會中斷回合。Restart when idle 會將它排入佇列，而每個已連線裝置上的每個頁面都會顯示橫幅：

🌄 Relay restart queued — waiting for 2 sessions · waited 4 min of 30 min
Waiting for: Review: server/, Build docs (2 turns)
New messages are held until the restart: 3 messages waiting.

session 名稱是連結，可開啟該對話。session 有背景工作時，後面會接著一行 Background tasks:（背景任務：），說明每個任務是否會繼續執行。橫幅有兩個按鈕：

• Restart now 會先詢問，列出它不等待的 session，然後重新啟動。這些 session 的 worker 會繼續執行，並向重新啟動後的中繼回報；中繼不在的期間，它們回合的即時輸出會暫停，而沒有收到回覆的回合必須重新傳送。在 Linux 服務下，worker 可能會隨中繼一起停止，視窗會說明這一點。
• Cancel restart（取消重新啟動）會撤回重新啟動。被暫緩的訊息會立即送出。

只有執行中的回合會讓重新啟動等待。重新啟動排入佇列期間，你傳送的訊息會在佇列中等待，不會交給 agent，所以忙碌的中繼無法一再延後重新啟動。這些訊息會在重新啟動後執行。agent 已沒有動靜的回合，會在中繼的閒置時間窗過後被放棄，預設為 10 分鐘（processingTimeoutMs），之後就不再讓重新啟動等待。

等待很久時 0.9.13 新增 #

排入佇列的重新啟動最多等待 Settings → General 中 Ask after a queued relay restart has waited（排入佇列的中繼重新啟動等待多久後詢問）所設定的時間：預設 30 分鐘；可選 5、10、15 或 30 分鐘，1、2 或 4 小時，或 No limit（無上限）。之後橫幅會變成一個問題：

🌄 The relay restart has waited 30 min for 2 sessions — restart now, keep waiting or cancel?

它提供 Restart now、Keep waiting (30 min)（繼續等待，30 分鐘）和 Cancel restart。Keep waiting 會從那時起再等待一整個期間，然後再次詢問。開啟通知的裝置也會收到一則通知，標題為 Relay restart waiting（中繼重新啟動等待中）。

不論有沒有詢問，回合執行期間中繼絕不會自行重新啟動，而最後一個回合一結束，它仍會立即重新啟動。使用 No limit 時，排入佇列的重新啟動以及它暫緩的訊息，會一直等到執行中的回合結束或你做出決定。變更後的設定也會套用到已經排入佇列的重新啟動。

沒有任何東西在執行時，橫幅會顯示 Relay restarting now…，中繼很快就會回來。開著的裝置可能會短暫斷線，並在第一個 worker 回報之前顯示 CLI is offline 橫幅。

中繼由 oar start 或在終端機中啟動時，oar restart 的行為相同：它會將重新啟動排入佇列，所以橫幅以及達到最長等待時間後的詢問也適用於它。它最多等待一分鐘，然後說明中繼仍在忙碌，會在回合結束時自行重新啟動。oar stop 也以相同方式最多等待 30 秒。中繼以 systemd 服務（oar service install）執行時，oar restart 和 oar stop 會透過 systemd 立即生效，不等待回合。此時正在執行的回合會結束，並依下文所述處理。

0.9.11 新增 任何已登入的瀏覽器都可以將重新啟動排入佇列或取消它；只需要存取 token，其他都不需要。如果中繼拒絕，頁面會顯示它的原因。在主機的終端機中，oar restart 一律有效。

0.9.13 新增 你要求重新啟動中繼的 agent，也會以相同方式將重新啟動排入佇列，並得知重新啟動要等待什麼、暫緩了哪些訊息，以及哪些背景任務會繼續執行，以便告訴你。agent 被告知絕不可跳過等待：不等待就重新啟動是 Restart now，那是你的決定。

重新啟動會保留什麼、會失去什麼 #

保留：

• 對話及其歷史記錄
• 排入佇列的訊息，包括等待重新啟動的訊息
• 輸入區草稿和附件
• 0.9.11 新增 預覽，啟動時會再次檢查
• 0.9.11 新增 繼續執行的 worker 的背景任務
• 0.9.13 新增 任務主控台：已完成的列會保留到它們那一小時結束，以及執行中指令的輸出
• agent 為了監看其他 session 而設定的訂閱
• agent 獲得的啟動 session 核准
• 用量上限暫停
• 各對話的供應商 session

失去：

• 排入佇列的 Suspend host（讓主機休眠），僅限 Windows；中繼會捨棄它並加以說明
• 被重新啟動停止的 worker 的背景任務（在 Linux 服務下，見下文）

中繼由 oar start 或在終端機中啟動時，它結束時不會停止 worker。worker 會發現連線已中斷，並重新連線到新的中繼。oar service install 的服務則不同：systemd 會停止服務啟動的所有東西，包括 worker，因為服務沒有要求其他行為。之後傳給每個對話的下一則訊息會啟動新的 worker，對話會依下文所述繼續。

出狀況時正在執行的回合 #

有計畫的重新啟動會等待回合，所以這裡指的是 Restart now、當機、強制終止、斷電或重新開機。

中繼會將回合標記為執行中，直到它的 worker 回報為止。如果 worker 停止回報，中繼會等待它的閒置時間窗（預設 10 分鐘，processingTimeoutMs；完全沒有 worker 連線時最多 45 秒），然後把訊息放回佇列。訊息會再次傳給新的 worker，新的 worker 會繼續供應商 session，所以 agent 保有先前的對話。agent 已經變更的檔案會維持變更後的狀態。

• 一則訊息最多會被放回 maxRequeueRetries 次（預設 5 次）。之後它會失敗，並顯示 Relay recovery limit reached … Send it again to retry.
• agent 在背景任務之後自行開始的回合，也就是接續，不會被放回。它會被捨棄，因為再次執行它會把 agent 自己的通知當成你的提示交給它。
• SDK 引擎上的 Copilot 會保留中繼在重新啟動期間無法接收的已完成回覆，並在最多五分鐘內再次提供，所以答案不會遺失，提示也不會執行兩次。

在重新啟動期間持續執行的 worker 會保留它的回合：它會向新的中繼回報，回合繼續進行。

告訴中斷的 session 繼續 0.9.13 新增 #

有少數回合無法再次執行，因為 agent 已經接收了該訊息：在它工作時你傳送的訊息、接續，或已經開始、但 worker 回來時沒有帶著它的回合。這樣的回合就這樣停止，agent 也永遠不知道自己被打斷了。

在 Settings → General 中開啟 After a relay restart, tell interrupted sessions to carry on（中繼重新啟動後，讓中斷的 session 繼續），這是中繼的設定，預設關閉；之後這類 session 會在中繼恢復後收到一則來自中繼的註記。它在對話中顯示為精簡的 relay（中繼）列，而 agent 讀到的是：

Automatic message from OAR, not from the user: the relay restarted at 2026-10-20 14:05 UTC, and the turn you were working on was interrupted before it finished. Check where you were (the files you changed, the commands and background tasks you started) and carry on from there. Do not repeat steps that already completed; if the work was already done, say so briefly.

• 你的訊息絕不會再次傳送，每個 session 每次重新啟動最多收到一則註記。
• 不會傳送給閒置的 session、會自行再次執行的回合、已封存的對話，也不會在用量上限暫停擋住該 session 時傳送（暫停自己的後續訊息會讓回合繼續）。
• 你在這段期間排入佇列的訊息會先送出；註記排在它後面。
• 註記會像任何訊息一樣啟動 session 的 agent。只有在中繼啟動後 30 分鐘內被中斷的回合才算數。

沒有這個設定時，請自己傳送一則簡短訊息，例如「繼續」。

依供應商 #

中繼會為每個供應商保留對話和佇列。供應商保留的內容不同，因此繼續後的對話從哪裡接續也不同。OpenAI Image 對話沒有 worker：中繼自己呼叫 Images API，所以本頁的內容都不適用於它們。