10.5 流式输出、重试与提前终止
长任务的可靠性不只取决于模型能力，还取决于系统是否能持续输出可观测状态、是否能对失败做有界重试、以及是否能在必要时安全终止执行。本节结合 OpenClaw 的重试策略与模型故障切换文档，说明流式输出的工程意义、重试与降级的边界，以及如何把这些能力纳入验收与排障流程。
10.5.1 流式输出的内部机制：Block Chunker 与 Soft Chunking
在深入工程意义之前，先看看流式输出在内部是怎样工作的。理解切分机制有助于排查“消息在渠道端被截断”或“代码块格式错乱”等问题。OpenClaw 的流式输出并非简单地把 LLM 返回的 token 逐个转发，而是经过一个精心设计的 Block Chunker 做智能切分。
切分偏好与围栏感知
Block Chunker 支持三种切分偏好（breakPreference）：
paragraph（默认）：优先在\n\n（段落分隔）处切分newline：降级为在单个\n处切分sentence：进一步降级为在句号、感叹号、问号处切分
切分器会在 minChars 和 maxChars 之间寻找最佳断点。当到达 maxChars 仍未找到偏好断点时，才会硬切。
关键的安全约束是围栏感知（fence-aware）：切分器会解析 Markdown 代码围栏（```），保证永远不在代码块内部切断。如果 maxChars 恰好落在代码块内，切分器会先关闭围栏（插入匹配的关闭标记），在下一个 chunk 开头重新打开，确保每个独立 chunk 都是合法的 Markdown。
Block Reply Buffer 与刷新时机
流式输出的中间态维护在一个 blockBuffer 中，在两个关键时机触发刷新：
工具调用前：
flushBlockReplyBuffer()确保在执行工具之前把已缓冲的文本块全部发出，让用户看到工具调用前的完整上下文。智能体轮次结束时：强制刷新残余缓冲区，此时
force: true会忽略切分偏好直接发出。
这种“累积到合适断点再批量发出”的策略，既避免了逐 token 发送造成的渠道消息碎片化，又保证了在关键状态转换点（工具调用边界）的及时输出。
10.5.2 流式输出的工程意义：把中间态变成可观测事实
流式输出不仅用于改善交互体验，更重要的是让长链路任务具备可观测中间态，例如：任务是否进入路由、是否发生工具拒绝、是否发生模型切换或重试。对于运维与排障，关键在于能用结构化日志回放一次请求的完整链路。
推荐在排障窗口跟随 JSON 日志，并按事件类型过滤关键事件：
10.5.3 重试策略：有界重试与错误分类
重试的目标是消化瞬时故障，而不是掩盖逻辑错误。官方重试策略文档强调了错误分类与有界重试的重要性：https://docs.openclaw.ai/concepts/retry。
工程上建议遵循三条规则：
区分瞬时故障与不可重试故障：鉴权失败、参数不合法、策略拒绝等属于不可重试，应快速失败并给出可操作指引。
对读操作可自动重试，对写操作必须谨慎：写操作可能产生外部副作用，除非具备明确的幂等机制与结果对账，否则不建议自动重试。
为重试设预算：限制最大次数与最大耗时，避免失败放大为资源占用与队列拥塞。
10.5.4 模型故障切换：用回退链路把不可用变为可用
当上游模型供应商出现短时不可用或限流时，重试可能不足以恢复服务。OpenClaw 支持通过模型回退链路进行故障切换，配置上表现为主模型的 fallbacks 字符串列表。系统会在主模型失败时按顺序尝试备选模型。相关概念与配置见官方文档：https://docs.openclaw.ai/concepts/model-failover。
下面示例展示了一个常见回退链路：当主模型（GPT-5.2）失败时，按顺序回退到备用的小模型或跨供应商模型。
模型回退属于系统层面的降级能力，应与日志与告警联动：当发生回退时，日志中应出现明确事件，便于在成本、质量与可用性之间做权衡。
10.5.5 提前终止与资源预算：让失败可控，让取消可落地
提前终止用于两个目标：
用户主动取消或任务明显偏航时，尽快释放资源。
触发安全边界时，及时阻断高风险动作。
工程上建议把“可终止”写成约束：
工具调用应有超时与失败返回，并在日志里记录原因。
关键写操作应设置确认点，并具备回滚或对账路径。
对于长输出，尽量用结构化中间态而不是一次性堆叠结果，便于在取消时留下可用证据。
验收与排障时，可用 status --deep 与 doctor 先确认系统状态与配置被加载，再结合日志回放定位具体失败点。
最后更新于