ZeroClaw 从不恢复中断的流。它是否会再次发送该回合，取决于你的 profile 中有多少候选模型；而在唯一的当前发布版本中，实际行为并不完全符合文档承诺。 ZeroClaw 针对 v0.8.5（发布于 2026 年 9 月 5 日）的文档称，在任何输出之前失败的流会以非流式方式重试，而在输出之后失败的流永远不会重放。2026 年 10 月 1 日，针对一个在回复中途切断流的端点运行时，v0.8.5 的终端客户端做了更简单的处理：只有一个候选模型时，无论文本出现前还是出现后都完全不重试；有第二个候选模型时，则会将该回合以非流式方式重新发送给第二个模型——即使答案已经显示了一部分。部分输出后的引导式恢复仍是一个尚未获得设计批准的开放功能请求。因此，有用的问题不是如何让 ZeroClaw 重试，而是你重新发送该回合是否安全，以及那次失败的尝试已经产生了什么成本。
在任何内容可付诸行动之前，先说明两点范围。实际运行的范围很窄：v0.8.5 发布二进制文件的交互式终端模式、一个 OpenAI 兼容端点，以及一个故意关闭流的本地测试服务器——结果如下。通道、网关 WebSocket、RPC、ACP、Anthropic 插槽及真实提供商故障均未经过运行测试。其他所有声明均来自 v0.8.5 发布标签中的代码仓库、版本固定的文档 docs.zeroclaw.com/v0.8.5/，或带日期的上游问题报告，查阅日期均为 2026 年 9 月 21 日。还请自行固定该 URL：README 将读者引向 /master/ 路径，其 HEAD 比该发布版本领先十六天，并且恰恰在这个主题上与发布版本矛盾，而 /latest/ 返回 404。本文中的 ZeroClaw 指 zeroclaw-labs/zeroclaw 运行时；如果你不确定自己运行的是否正是它，ZeroClaw 与 OpenClaw 对比可将它与那些共享该名称的项目和分支区分开来。
v0.8.5 中的四个标记，其中只有一个与网络有关
在做任何决定之前，先查看你实际收到的是哪个标记。ZeroClaw 在 v0.8.5 的英文语言环境文件中，将这些标记定义为不同的 Fluent 键；文件头部注释说明，当一轮对话被提前截断时，它们会附加到或持久化为助手输出，并在所有传输方式中展示给最终用户——包括 Channels、WS、RPC、ACP 和 CLI。
| 标记 | Fluent 键 | 它告诉你的信息 |
|---|---|---|
[stream interrupted] | turn-stream-interrupted | 传输流在一轮对话中途中断。没有人按下停止键。 |
[interrupted by user] | turn-interrupted-by-user | 人为中断。 |
[turn cancelled via client] | turn-cancelled-client-rpc | 是通道，而不是执行者。其代码注释明确说明，人为中断和程序化客户端取消都会通过此路径到达，因此措辞指明的是通道。 |
[interrupted by user before this tool produced a result] | turn-tool-interrupted-before-result | 某个工具在返回结果前被截断。 |
同一文件的 master 分支中还存在第五个键 turn-failed = [turn failed]，但 v0.8.5 的语言环境文件中没有它，因此发布版本不会发出该标记。有一个行为值得了解，因为它会改变你之后能够读取的内容：轮次引擎仅当部分文本非空时才会持久化附加了该标记的部分文本。如果某一轮产生了推理或提供商侧预执行的工具事件，却没有可见文本，则完全不会持久化任何内容——代码注释将持久化描述为提交消费者已经看到的内容。其他语言环境包含相同的键及其翻译值，因此非英语安装显示的并不是字面上的英文方括号字符串。
重试边界实际位于何处
整个决策归结为一个问题：是否已经有任何内容到达不可变事件接收器？
| 发生了什么 | v0.8.5 中记录的行为 | 注意事项 |
|---|---|---|
| 流在任何可见输出之前失败 | 运行时会通过非流式路径重试整个调用，重新进入完整的可靠性处理流程 | 有文档记录，但不是单候选配置在发布版本上观察到的结果——见下文 |
| 流结束时没有最终文本，也没有工具调用 | 这是语义上的空响应，而不是答案。当结果被标记为可安全重放且 provider_retries 非零时，会向完全相同的提供商和模型发起一次非流式恢复调用，并仅消费一次 | 通过拉取请求 #10602 在 v0.8.5 中发布，于 2026 年 9 月 4 日合并。适用于空流，不适用于在输出中途中断的流 |
| 文本、推理或预执行的工具事件已经到达不可变事件接收器 | StreamInterruptedAfterOutput。运行时不会重放请求，已经转发给消费者的文本就是会被持久化的部分助手文本 | 在 master 分支上这是有意为之且行为相同。回归测试已锁定这一点：在已有可见输出后发生流错误时，必须使该轮失败，不得进行备用重试 |
| 上述任一情况 | 流只打开一次，开始后不会切换条目 | 恢复始终是新请求。包括自定义插槽在内的任何提供商系列都没有恢复路径 |
确实存在的控制项是全局的，而不是按端点配置的。[reliability]包含 provider_retries（文档默认值为 2）和 provider_backoff_ms（默认值为 500），生命周期文档说明每个已实例化条目最多尝试 provider_retries + 1 次。v0.8.5 配置参考没有记录与它们并列的按提供商或按别名重试覆盖设置。也不要指望密钥池：v0.8.5 文档说明，reliability.api_keys目前不是可用的故障转移机制，因为包装器会在可重试的限流后选择并记录备用密钥，却无法将其应用到已构造的提供商，因此重试仍使用原始凭据。你添加第二个密钥所期待的救援并不会发生。
指向单个端点的配置最容易受到影响
对于使用 ZeroClaw 对接单一网关或单一供应商端点的人来说，这是最明确的边界，因为单个端点按定义就是单候选可靠性配置。问题 #10736报告称，在发布版本中，这种配置下发生输出前流失败时，日志会记录回退到非流式聊天，但随后从未发送该请求，最终以 All model providers/models failed after 0 failure event(s) 终止该轮。该问题于 2026 年 9 月 18 日关闭——在 v0.8.5 发布之后——因此修复仅存在于 master。2026 年 10 月 1 日运行时，发布版 v0.8.5 的行为与该问题描述完全一致：先发出一个请求，然后出现该错误，无论流是在文本出现之前还是之后中断。
这里有两个相互矛盾的官方说法，二者都值得保留。v0.8.5 架构文档承诺进行非流式重试；该问题则证明发布版本没有执行它，其预期行为部分要求只有在确实会尝试回退时，日志才能声称发生了回退。之后，master 增加了发布版本没有的单候选恢复许可——而问题 #10787称，无论 provider_retries 如何，该许可都通过 RetryDecision::Admit(0) 授予，且没有退避，因此请求会在同一个负载丢弃时段内立即重新发送给已经过载的上游。该问题于 2026 年 9 月 26 日标记为完成并关闭——相关修复位于 master 上，晚于 v0.8.5，因此也未包含在任何发布版本中。Master 的行为仍在变化；不要据此制定计划。
文档所述的缓解方式是配置，而不是某个设置：为配置档提供第二个候选项，让可靠性处理流程有其他去处。2026 年 10 月 1 日，这在终端中的 v0.8.5 上有效——但在依赖它之前需要了解一个注意事项：恢复请求发送给了第二个模型，而不是第一个，因此中断后的答案来自你的备用模型。ZeroClaw API 成本与设置指南介绍了这些条目应采用的配置形式。
流被截断时 v0.8.5 的行为
2026 年 10 月 1 日，依据发布版本的 SHA256SUMS 完成校验和验证的 v0.8.5 发布二进制文件，在一次性容器中以交互式终端模式运行——这是会进行流式传输的模式；单消息 -m 模式发送一个非流式请求，永远不会进入此路径。一个 OpenAI 兼容的自定义插槽配置档 provider_retries = 2 指向本地测试服务器；该服务器先正常响应流，然后在未发送 [DONE] 的情况下关闭连接，关闭位置分别为首个事件之前或一个文本块之后。
| 配置档 | 流中断的位置 | 发送的请求数 | 终端显示的内容 |
|---|---|---|---|
| 单个候选项 | 任何文本之前 | 一次流式请求，无重试 | 错误：所选模型提供商失败。请检查提供商配置或选择其他提供商。日志：所有模型提供商/模型均在 0 个失败事件后失败 |
| 单个候选项 | 文本已打印之后 | 一次流式请求，无重试 | 先显示部分文本，然后出现相同的错误。没有打印 [stream interrupted] 标记 |
使用第二个模型时还会有 fallback_models | 任何文本之前 | 先发送流式请求，然后向第二个模型发送一次非流式请求 | 第二个模型的回复 |
使用第二个模型时还会有 fallback_models | 文本已打印之后 | 相同的两次请求 | 先显示部分文本，然后显示第二个模型的完整回复——因此答案出现了两次 |
对于在 v0.8.5 上从终端运行 ZeroClaw 的人来说，可以得出三点结论。单候选失败就是已复现的 #10736；provider_retries并未改变这一点。文档所述的“可见输出后不重放”边界在这里并未生效：终端中已经打印的文本并没有阻止重新发送，因此你眼看着只到达一半的轮次仍可能被再次发送给另一个模型。此外，该轮日志将第一个模型记录为该轮使用的模型，但文本却来自第二个模型，这正是 v0.8.5 自身文档警告的归属差距。本次运行未涵盖：Telegram 或 Slack 等 Channels、网关 WebSocket、RPC 和 ACP 客户端——不重放规则正是针对这些传输方式的事件接收器编写的——Anthropic 插槽、真实提供商中断，以及任何通过 Kunavo 发出的请求。
重新发送之前：哪些操作已经运行，哪些费用已经产生
ZeroClaw 自身的工具循环会将流读取至结束，流结束后恢复工具调用并执行它们，然后为下一轮助手对话打开新的流式调用。因此，发生中断的那次迭代所请求的工具并未运行——但这比听起来更有限。提供商侧预执行的工具调用属于另一类事件，它们已经在上游产生了影响，这正是它们会阻止重放的原因。而较长的轮次可能会在后期中断：#10736 指出，失败前的工具调用已成功完成；#10787 的日志显示中断发生在第 2 次迭代，此时请求中已有 126 条消息。重新发送原始提示会重放模型将再次执行的所有早期副作用。
看起来干净的记录也不能证明一切正常。问题 #9421同时针对 Anthropic 和 OpenAI 兼容提供商系列以 p1 优先级开放，标题指出不完整的终端响应可能被报告为成功。在 Code/ACP 层面，另外两个开放的 p1 报告描述了：失败的轮次会从持久历史中丢弃已接受的提示和已完成的工具交互（#10788），以及超出预算的轮次在会话恢复后丢失可见进度（#10659）；用于持久化中断轮次进度的拉取请求仍未合并。所有问题在 2026 年 9 月 21 日都处于开放状态，其中数个标记为进行中，因此请重新检查，不要直接引用这一快照。
在费用方面，v0.8.5 与 master 确实存在分歧，你应阅读与你使用的构建版本相匹配的文档。该发布版本的文档将最终记录称为成功通知，而非记录每次尝试的权威账本，并说明不应据此推断每次尝试的费用准确性；master 则将该段替换为逐次尝试的 usage_by_provider 账本，这一变更来自于 2026 年 9 月 18 日合并的拉取请求 #8966。任何发布版本都尚未包含这一变更，而且 master 本身也将其适用范围限定为已添加事件监测的轮次执行路径。与此同时，流中断时的用量快照是一个可选字段，可能不存在，而 ZeroClaw 会要求兼容 OpenAI 的端点在最后一个 SSE 数据块中提供用量信息——被截断的流可能永远不会发送这个数据块。请将最后这一点视为需要在你自己的费用输出中核查的机制，而非实测结果。请改为依据端点自身的用量记录进行核对；在 Kunavo 上，这就是用量日志。
为什么模型前的网关会产生这个标记
最可能的第三方原因是完成信号从未到达。ZeroClaw 的 v0.8.5 流式文档说明，传输不会依赖连接关闭作为成功信号：OpenAI 兼容流在 [DONE] 上结束，OpenAI Responses 流在其终止响应事件上结束，而 Anthropic 流在 message_stop 上结束；服务器在这些事件之后仍可能保持 HTTP 连接打开。没有该信号就关闭的流会被作为错误——SSE stream closed before {completion_signal}: response truncated——而不是短成功响应呈现出来。这是端点缺陷，而不是 ZeroClaw 缺陷。文档记录了一个例外：Anthropic 解析器目前还会将非空 message_delta.stop_reason 后的 EOF 视为完成，即使没有 message_stop；要求必须有该信号的拉取请求在这两个引用版本上都尚未合并。
第二个原因是开放套接字上的静默。ZeroClaw 使用字节空闲超时，而不是整个请求的截止时间；文档记录的超时为：OpenAI Responses 和 OpenAI 兼容提供商 300 秒，Anthropic 90 秒，并且每次读取正文都会重置计时器。如果端点缓冲上游响应，并持续 1 分 30 秒不转发任何内容，就会触发 Anthropic 系列插槽的超时，却不会触发 OpenAI 兼容插槽的超时——这一点值得了解，因为 Anthropic Messages 端点应放在带有 uri 覆盖设置的 anthropic 插槽中，而不是放在 custom 中。请参阅Messages 基础 URL 文档和OpenAI 兼容 API，了解这两种通信协议。
一次失败轮次的成本：示例计算
把两笔费用分开。ZeroClaw 运行时成本为 $0——zeroclaw.com说明它是开源软件，采用 MIT 或 Apache-2.0 双许可证，没有订阅，也没有托管席位；你只需支付自己的 LLM 提供商成本，或者在使用 Ollama 运行本地模型时完全无需支付任何费用。没有任何层级会解锁恢复、更大的重试预算或引导式恢复，因为根本没有层级。
中断会影响的是模型账单。以下数字是基于假设的令牌算术，不是测得的任务成本，也不是账单上限。假设某一轮发送 110,000 个未缓存输入令牌——这是单次有日期记录的过载事件 #10787 中记录的提示大小；上游接受了请求并完成预填充后才将其丢弃——并在流中断前接收 2,000 个输出令牌。三次尝试这一列是 provider_retries + 1，采用文档默认值 2。费率是实时的，每百万令牌的价格来自Kunavo 目录。
| 模型 | 每 1M 个令牌的输入 / 输出 | 一次失败的尝试 | 三次尝试 |
|---|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $0.084 | $0.252 |
| GPT-5.6 Terra | $0.70 / $4.20 | $0.085 | $0.256 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $0.252 | $0.756 |
| Claude Opus 5 | $3.50 / $17.50 | $0.420 | $1.260 |
某个端点是否对其拒绝处理的请求收费，取决于该端点自身的计费政策，ZeroClaw 的源代码和文档均未对此作出说明——本页面也未针对任何提供商实测这一点。此处的计算是为了估算这一问题涉及的金额，而非回答它。Kunavo 的目录价格是计费下限，而非上限：当上游报告其收费金额时，账单金额取目录价格与上游费用乘以适用加价系数两者中的较大值。最低充值金额为$10 的预付余额，这是最低资金充值要求，而非任务费用或订阅费——请参阅计费详情。
哪种路径最能抵御此类故障
| 方式 | 流中途断开时的行为 | 你放弃的内容 |
|---|---|---|
| 单一端点、直接供应商 | 单候选可靠性配置，因此在 v0.8.5 上属于 #10736 报告的范围 | 是否为第一方供应商不会改变处理流程；一个候选项就是一个候选项 |
| 单一端点、网关 | 完全相同的单候选结构。网关在这里带来的是在一个密钥和一个余额上切换模型的能力，而不是流式传输韧性 | 额外的一跳本身也可能在没有完成信号的情况下关闭，而 ZeroClaw 只有在你自行填写其 [cost.rates] 条目后才会为它计价 |
| 配置档中的两个或更多候选项 | 可靠性处理流程有了去处。在 2026 年 10 月 1 日的终端运行中，它在早期中断和回复中途断开后都通过第二个模型完成了恢复 | 需要维护第二个模型或别名，而且恢复后的答案来自你的备用选项，而不是首选项 |
| 通过 Ollama 使用本地模型 | 重新发送消耗的是时间和硬件，而不是金钱，因此保守地进行重试成本很低 | 相对于托管前沿模型的能力差距，以及运行其中一个模型所需的机器 |
| 固定费率订阅代理 | 完全不是 ZeroClaw 路径——该项目没有订阅，也没有托管席位 | 你改变的是客户端，而不是 ZeroClaw 的恢复行为 |
无论你选择哪一种，操作规则都是 ZeroClaw 已经编码的规则：在 [stream interrupted] 之后，读取已持久化的部分内容，确认哪些操作已经生效，然后重新发送比原始内容更窄的请求。Kunavo 针对 OpenAI 兼容端点和 Messages 风格端点的配置参考是设置文档，而不是兼容性测试——上文 10 月 1 日的运行使用的是本地测试服务器，不是 Kunavo。从错误参考开始，解读你的端点返回了什么；准备为密钥充值时，再创建 Kunavo 账户。上文单候选与多候选决策最接近的比较是OpenRouter 与 LiteLLM 对比。
常见问题
ZeroClaw 会重试被中断的流吗？
这完全取决于你是否已经看到输出。ZeroClaw 针对已发布 v0.8.5 的提供商路由文档称，流只建立一次，开始后不会切换条目，因此不会恢复任何内容——存在恢复时，也是发起全新的请求。如果流在任何不可变事件输出可见之前失败，文档记录的行为是通过非流式路径重试整个调用。一旦文本、推理或预执行的工具事件到达不可变事件接收端，中断就会变为 StreamInterruptedAfterOutput，运行时不会重放请求。第二条规则在 master 分支上也相同。但在 2026 年 10 月 1 日运行 v0.8.5 的交互式终端客户端时，实际情况并未按文字呈现：使用一个候选模型时，无论文本出现前还是出现后都没有重试；使用 fallback_models 中的第二个候选模型时，两种情况下都会将该轮以非流式方式重新发送给第二个模型，包括答案已经打印了一部分之后。未运行 Channels 和网关 WebSocket。文档核查于 2026 年 9 月 21 日。
ZeroClaw 中的 [stream interrupted] 是什么意思？
这是传输流在一轮对话中途终止时面向用户显示的标记，在 ZeroClaw 的英文语言文件中定义为 Fluent 键 turn-stream-interrupted，并在所有传输方式中显示——Channels、WS、RPC、ACP 和 CLI。它与 [interrupted by user] 和 [turn cancelled via client] 是有意区分的标记，因此看到这个标记说明没有人按下停止按钮。当流在已有可见输出后终止时，部分文本会作为助手消息持久化，并追加该标记，但仅当部分文本非空时才会如此：只产生推理或只产生预执行工具事件的回合不会持久化任何内容。非英语安装使用相同的键和翻译后的文本，因此不要在非英语安装中搜索英文方括号字符串。读取发布标签 v0.8.5，时间为 2026 年 9 月 21 日。在 2026 年 10 月 1 日的 v0.8.5 交互式终端客户端中，流在回复中途断开时没有打印此标记；终端显示的是提供商失败错误。
ZeroClaw 流中断后，可以直接重新发送提示词吗？
不能自动这样做，ZeroClaw 自己的维护者也以这种方式处理。运行时会将流读取至完成，流结束后恢复工具调用，然后执行这些调用——因此发生故障的那次迭代中的工具尚未运行。但长回合也可能在后续迭代中断：一份上游报告指出，前一个工具调用已成功完成后才发生故障；另一份日志显示故障发生在第 2 次迭代，而请求中已有 126 条消息。更早迭代已经执行的任何操作——写入文件、运行命令、发送消息——如果你盲目重新发送相同提示词，都会再次发生。针对引导式恢复的开放功能请求，其明确列出的非目标包括盲目重放包含工具或审批的回合，以及将每个提供商错误都视为临时错误。先阅读持久化的部分文本，检查哪些操作已经生效，然后重新发送范围更窄的提示词，而不是原始提示词。
可以配置 ZeroClaw 来恢复中断的流吗？
不可以。任何已发布版本中都没有相关设置，也没有通过付费档位解锁该功能的方式——ZeroClaw 免费且开源，采用 MIT OR Apache-2.0 双许可证，没有订阅，也没有托管席位，因此这一限制属于工程边界，而不是套餐边界。出现可见输出后不重放的规则位于源代码中，并由回归测试锁定；该测试自身的失败消息称，出现可见输出后的流错误必须使回合失败且不得进行回退重试——不过在 2026 年 10 月 1 日的 v0.8.5 交互式终端客户端中，配置第二个候选模型的 profile 在文本打印后确实重新发送了请求，因此该规则并非适用于每种传输方式的保证。中断回合后的引导式恢复对应 issue #10634——截至 2026 年 9 月 21 日，该 issue 仍处于 open 状态，标记为 status:accepted 和 priority:p2，并被安排先进行设计或 RFC 讨论。Accepted 表示分诊已接受问题陈述，并不表示代码已经编写或合并。
我的日志显示它正在回退到非流式聊天，然后回合就终止了。为什么？
在已发布的 v0.8.5 中，该日志行可能并不真实。上游 issue #10736 的标题指出，输出前的流失败会跳过所宣称的非流式回退；该 issue 报告称，运行时记录自己正在回退到非流式聊天，却没有发送非流式请求，随后回合立即以 All model providers/models failed after 0 failure event(s) 终止。其影响说明将受影响人群列为只有一个提供商候选模型的用户，尤其是配置了零次重试的用户。零次重试并非唯一情况：复现配置将 provider_retries 设置为 0，但后续 issue #10787 在 provider_retries 保持文档默认值 2 时，也复现了相同的立即失败。该 issue 于 2026 年 9 月 18 日关闭，而 v0.8.5 于 2026 年 9 月 5 日发布，因此没有任何已发布版本包含修复。在 2026 年 10 月 1 日的 v0.8.5 上复现了这一问题：一次流式请求，没有非流式后续请求，并出现该错误——provider_retries = 2，且无论流是在文本出现前还是出现后中断，结果都相同。在 fallback_models 下添加第二个模型即可让回合恢复。针对 v0.8.5 从日志调试此问题，意味着要识别一个并未发生的回退。
中断的回合会收费吗？如何检查？
请检查端点自身的用量记录，而不是 ZeroClaw 的记录，因为 v0.8.5 的文档告诉你不要信任其每次尝试的数字：文档将最终回退通知描述为成功通知，而不是记录每次尝试的权威账本，并称不要据此推断每次尝试的成本准确性。能够解决这一问题的按每次尝试记录的 usage_by_provider 账本通过拉取请求 #8966 在 master 分支上加入，并于 2026 年 9 月 18 日合并，时间晚于 v0.8.5 发布，因此任何发布版本都没有该功能——而且 master 分支将其限定在经过事件插桩的回合路径中。ZeroClaw 会在流中断时捕获用量快照，但该字段是可选的，可能不存在；它还会向 OpenAI 兼容端点请求最终 SSE 块中的用量，而被截断的流可能根本不会发送该块。后一事实来自源代码读取，而非运行时观察。此外，ZeroClaw 自身的成本数字来自你配置中的操作员编写的 [cost.rates] 费率表，因此未在其中定价的端点，ZeroClaw 也不会为其定价。
2026 年 10 月 1 日运行：v0.8.5 发布二进制文件以交互式终端模式连接本地测试服务器，测试服务器截断了流——结果表中的四行；没有运行其他内容，也没有请求发送到 Kunavo。问题状态于同日重新核查（#10787 此后已关闭；#10634 仍处于开放状态）。源代码读取自 v0.8.5 发布标签，文档读取自版本固定的 /v0.8.5/ 路径，问题和拉取请求状态读取于 2026 年 9 月 21 日；其中数个问题当时标记为进行中，状态可能变化。Kunavo 令牌费率来自实时目录，本文每个美元数字均为示例性的令牌算术，而不是测得的任务成本。