重启与恢复

每个对话都有自己的智能体，运行在中继所在机器上的一个后台进程中。对话本身，即它的历史、队列和草稿，保存在中继中。本页说明两者如何配合，让你知道一次 Kill session（强制结束会话）、一次中继重启或一次重新开机会让你付出什么代价，以及哪些会自行恢复。

简而言之：你写下的任何内容都不会丢失。如果对话的智能体没有在运行，发给该对话的下一条消息会重新启动它，并且智能体会接着提供商自己的会话继续，而不是从一个空白会话开始。

对话的智能体进程 #

OAR 把这个进程称为会话 worker。你不需要启动它。中继在对话需要它时启动它，通常是在你发送第一条消息时；worker 会回连中继，以接收消息并报告回复。在装有 tmux 的 Linux 和 macOS 上，worker 运行在分离的 tmux 会话中，⋯ 菜单中的 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 分钟后，智能体自己的程序会退出，下一条消息会重新启动它，并继续同一个提供商会话。worker 进程保留，并保持与中继的连接。应用中没有调整这 10 分钟的设置。

以下任一情况进行期间，智能体都不会被停止：

• 有一轮正在为它运行或排队，
• 一张提问或权限卡片在等待你的回答，
• 有后台任务正在运行，或者刚结束的后台任务的续接仍待进行。

仅靠后台任务，最多只能让它保持到 Settings → General（设置 → 常规）中的 Background task timeout（后台任务超时）（默认 4 小时；0 表示无限制）。

0.9.17 新增 当你更改 DeepSeek 对话的模型或推理强度时，它也会重启其智能体的程序，因为 Claude Code 只在启动时读取这两项。重启发生在下一轮之前、程序中没有任何东西在运行时，并继续同一个会话。如果程序中仍有后台工作在运行，该轮就在程序当前的状态下运行：新模型会在其中切换，新的推理强度则要等到重启。

其他提供商没有这种空闲停止。Claude Cloud、Cursor 或 Grok 的 worker 会一直运行，直到你强制结束会话、归档对话或机器停止运行。Copilot 扩展引擎也会让它的 Copilot CLI 一直运行。闲置 30 分钟的 Cursor worker 会关闭其智能体句柄，并在下一条消息到来时重新打开同一个 Cursor 智能体。

Kill session #

对话的 ⋯ 菜单中，或列表中该对话所在行的菜单中的 Kill session，会停止 worker 及其启动的进程。当对话卡住、智能体对 Stop（停止）没有反应，或者你希望智能体重新开始以便加载新的工具或设置时（例如在你开启了智能体会话之后），就使用它。

会先打开一个确认框：

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 state cleared; no live worker process was found. 如果有进程在尝试后仍然存活，会弹出一条警告 Failed to kill session（终止会话失败），并且不会清除任何内容。

正在运行的一轮会以对话中的一条提示结束：This session was killed from the relay UI before the turn completed. 请再次发送该消息，或写一条新消息。对话、它的历史和排队消息都会保留。下一条消息会启动一个新的 worker，并恢复提供商会话。

归档对话也会停止其 worker。见对话列表。

智能体无法访问时 #

当 10 秒内没有任何 worker 报到时，对话上方会出现一条横幅，侧边栏中的状态行显示 CLI offline（CLI 离线）：

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

这条横幅属于中继，而不属于某个对话；在一个闲置了一段时间的中继上，它可能是正常现象。你发送的消息会被保留。发送一条消息：中继会启动该对话的 worker，一旦它连上，横幅就会消失。如果横幅一直存在，请查看中继日志文件夹中的 worker-<session>.log；该文件夹的位置见文件与文件夹。

丢失连接的 worker（例如在中继重启期间）会不断尝试重新连接，两次尝试之间最多等待 8 秒。0.9.13 新增 它还会放弃 15 秒内没有完成的连接，也不会等待正在关闭的中继断开连接，因此挂起的重启不会再让它失去下一次尝试。每次失败的尝试都会把一行带有原因的 worker ws disconnected 写入它的 worker-<session>.log：前三次都写，之后最多每分钟一行。0.9.11 新增 作为安全保障，当有消息在等待某个 worker、而该 worker 已经 60 秒没有连接时，中继会替换它：停止旧进程并启动一个新进程，由新进程接收该消息。当该会话有一轮或后台工作在运行时，它绝不会这样做；这样做时，它会记录一行 WORKER DETACHED。

重启中继 #

重启中继可以加载新版本、修改过的配置文件或新安装的提供商 CLI。在对话的 ⋯ 菜单中选择 🌄 Restart web relay（重启网页中继），或在中继所在机器上运行 oar restart。oar update 和 Settings → General 中的 Update（更新）按钮会在安装后为你重启它。

重启会等待什么 0.9.13 新增 #

🌄 Restart web relay 会先显示重启会等待什么，以及会让什么继续运行：

• 有一轮正在运行的会话，每个都带有标题；
• 在此之前它会暂缓多少条消息；
• 有后台任务（命令、监视器、子智能体）的会话，每个都标明是继续运行还是 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.

会话名称是链接，点击即可打开对应对话。当会话有后台工作时，后面会跟一行 Background tasks:（后台任务：），标明每个任务是否继续运行。横幅有两个按钮：

• Restart now 会先询问，列出它不等待的会话，然后重启。这些会话的 worker 会继续运行，并向重启后的中继报告；在中继离开期间，它们各轮的实时输出会暂停，回复没有送达的一轮需要重新发送。在 Linux 服务下，worker 可能会随中继一起停止，窗口会说明这一点。
• Cancel restart（取消重启）会撤回重启。被暂缓的消息会立即发出。

只有正在运行的轮次会拖住重启。在重启排队期间，你发送的消息会在队列中等待，不会交给智能体，因此一个繁忙的中继无法一再推迟重启。这些消息会在重启之后运行。智能体已经沉默的一轮，会在中继的不活动窗口（默认 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 新增 任何已登录的浏览器都可以将重启排队或取消重启；它只需要访问令牌，别无其他。如果中继拒绝，页面会显示其原因。在主机的终端上，oar restart 始终可用。

0.9.13 新增 你让智能体重启中继时，它会以同样的方式将重启排队，并被告知重启在等待什么、暂缓了哪些消息、哪些后台任务会继续运行，以便它转告你。智能体被告知绝不能跳过等待：不等待就重启即是 Restart now，那应由你决定。

重启保留什么、丢失什么 #

保留：

• 对话及其历史
• 排队的消息，包括等待重启的那些消息
• 输入区草稿和附件
• 0.9.11 新增 预览，启动时会再次检查
• 0.9.11 新增 继续运行的 worker 的后台任务
• 0.9.13 新增 任务控制台：已结束的行保留到其一小时期满，以及正在运行的命令的输出
• 智能体为监视其他会话而设置的订阅
• 智能体获得的启动会话的批准
• 用量上限暂停
• 各对话的提供商会话

丢失：

• 排队中的 Suspend host（让主机休眠）（Windows），中继会放弃它并给出说明
• 被重启停止的 worker 的后台任务（在 Linux 服务下，见下文）

当中继由 oar start 或在终端中启动时，它退出时不会停止 worker。worker 会注意到连接已断开，然后重新连接到新的中继。oar service install 的服务则不同：systemd 会停止该服务启动的所有东西，包括 worker，因为该服务没有提出其他要求。之后，发往每个对话的下一条消息会启动一个新的 worker，对话按下文所述继续。

出问题时正在运行的一轮 #

计划内的重启会等待轮次，因此这里涉及的是 Restart now、崩溃、强制结束进程、断电或重新开机。

中继会把一轮标记为运行中，直到它的 worker 报告。如果 worker 停止报告，中继会等待其不活动窗口（默认 10 分钟，processingTimeoutMs；完全没有 worker 连接时最多 45 秒），然后把消息放回队列。消息会再次送达一个新的 worker，后者会恢复提供商会话，因此智能体拥有它先前的对话内容。智能体已经修改的文件保持修改后的状态。

• 一条消息最多被放回 maxRequeueRetries 次（默认 5 次）。之后它会以 Relay recovery limit reached … Send it again to retry. 失败。
• 智能体在后台任务之后自行开始的一轮（即续接）不会被放回。它会被丢弃，因为再次运行它会把智能体自己的通知当作你的提示词交给它。
• SDK 引擎上的 Copilot 会保留中继在重启期间无法接收的已完成回复，并在最多五分钟内再次提供它，因此答案不会丢失，提示词也不会运行两次。

在重启期间一直运行的 worker 会保留它的那一轮：它会向新的中继报告，该轮继续进行。

让被中断的会话继续 0.9.13 新增 #

有少数轮次无法再次运行，因为智能体已经接收了消息：你在它工作时发送的消息、续接，或者一轮已经开始、而其 worker 回来时却没有带着它。这样的一轮会直接停止，智能体永远不会知道自己被打断了。

在 Settings → General 中开启 After a relay restart, tell interrupted sessions to carry on（中继重启后，让被中断的会话继续）（默认关闭，是中继的一项设置），这样的会话在中继恢复后就会收到来自中继的一条留言。它在对话中显示为一个紧凑的 relay（中继）行，智能体读到的是：

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.

• 你的消息绝不会被再次发送，并且每次重启时每个会话最多收到一条留言。
• 以下情况不会发送任何内容：空闲会话、会自行再次运行的轮次、已归档的对话，以及用量上限暂停正拖住该会话时（它自己的后续消息会让该轮继续）。
• 你在此期间排队的消息先发送；留言排在它后面。
• 留言会像任何消息一样启动会话的智能体。被打断时距中继启动不超过 30 分钟的轮次计入其中。

没有这项设置时，请自己发送一条简短的消息，例如“继续”。

按提供商 #

对每个提供商，对话和队列都由中继保存。提供商保存的内容不同，因此恢复后的对话从哪里继续也不同。OpenAI Image 对话没有 worker：中继自己调用 Images API，因此本页内容都不适用于它们。