OpenClaw 6.8 震撼发布：不堆噱头，彻底治愈 Agent 的“宕机失忆症”

OpenClaw 6.8 版把恢复和内存修扎实，聊天输出也更清晰了

让 OpenClaw 在 Telegram 里指挥 Agent 跑任务，消息一条条冒出来时，表格和列表经常挤成一团纯文本。想看引用上下文还得复制出来单独整理。或者任务做到一半，服务器重启或者 Gateway 进程因为更新挂掉，子代理停了、生成的媒体没了着落、上下文也断掉，只能从头再来检查日志。

这些场景对日常把 OpenClaw 当工具用的人并不陌生。这个 2026.6.8 版本没有堆新奇功能，而是针对真实运行里最容易断的恢复流程和输出质量做了针对性处理。 恢复路径覆盖了更多中断类型，内存操作加了边界保护，聊天渠道的结构化支持也让 Agent 的输出终于能在对话里直接读懂。

OpenClaw 本身是个自托管网关。你在自己电脑或服务器上跑一个 Gateway 进程，就能把 Telegram、WhatsApp 等聊天应用桥接到后端 AI 代理。数据和执行全在你本地控制，不用把日程、文件、自动化逻辑交给外部服务。普通用户用起来像多了一个懂上下文的助手，技术用户知道这意味着可以自己管模型、工具和存储。

更新后最直观的是消息格式变了。Telegram 现在能正确渲染表格、列表、可展开的引用块，还保留了故意换行的格式。WhatsApp 那边也开始遵守配置好的 ACP 绑定。以前 Agent 想输出结构化内容，得额外处理转义，现在直接支持，阅读时不用再跳 app 整理。

但真正影响长期使用的，是那些看不见的改动。Agent 系统在真实环境里，最怕的不是模型调用失败，而是中途各种异常导致状态不一致。Gateway 重启、 embedding 批次太大超时、SQLite 在网络存储上出锁，这些以前可能直接让任务失败。现在部分场景有了明确的恢复逻辑。

Telegram 和 WhatsApp 的消息结构优化

以前 Agent 回消息像发没有格式的短信。数字、步骤、引用全挤在一起，用户得自己复制到笔记里重新排版才能看清重点。现在支持表格和列表后，数据直接排好，展开引用也能点开看上下文，不用额外跳转。

这对实际使用的影响很直接。Agent 经常输出数据报告、执行步骤或带引用的决策依据。如果格式乱，用户实际操作时会多花时间整理，或者干脆少用结构化功能，导致整体效率没真正提升。特别是团队里多人看历史记录，清晰的消息能减少误解和重复确认。

技术上，Telegram 这次渲染了 tables、lists、expandable blockquotes，还保留了 intentional line breaks 和 CLI-backed replies。WhatsApp 则 honors configured ACP bindings，让之前配置的绑定规则真正生效。这些改动没有改变用户聊天习惯，却让 Agent 输出更接近专业文档的阅读体验。多个 PR 针对不同渠道做了适配，效果是消息历史直接可用，不再需要二次处理。

结构化支持不是锦上添花，而是让 Agent 输出从“能看”变成“直接能用”。

Gateway 重启后 Agent 状态为什么不容易丢了

想象你设置了一个 cron 定时任务，或者让 Agent 生成媒体后继续下一步流程。结果 Gateway 因为系统更新或者临时网络问题重启了。以前子代理可能直接暂停，生成的媒体交付中断，归档回退也读不到。现在这些环节都有对应的恢复路径。

对把 OpenClaw 当生产工具的用户来说，这类中断的代价是明确的。任务中途失败意味着手动检查日志、重新触发、甚至丢失部分上下文。可靠恢复减少了这种人工干预，让长时间运行的任务更接近“设置后不管”的状态。

具体覆盖了 account-scoped DM sends、generated media completions、auto-reply message-tool final replies、reset archive fallback reads、restart shutdown aborts、yielded subagent pauses 和 session identity prompts。这些场景以前容易在重启后掉链子，现在被明确拉回正确恢复路径。心跳去重和 scoped DM 也同步处理了重复和权限问题。

我一开始以为这些恢复改动只是小修小补，直到看到它覆盖了从 yielded subagent pauses 到 generated media completions 这么多具体环节，才发现对长时间运行的任务来说，这几乎是把常见中断点全堵上了。

内存加固和新模型支持，实际处理了哪些运行边界

Agent 长时间跑，记忆相关的数据会越来越大。embedding 批次太大可能触发超时或者内存问题；跑在 NFS 共享存储上，SQLite 的 WAL 模式又容易出锁。QMD 搜索在某些瞬态情况下也可能不可用。这些都是自托管部署里真实存在的边界条件。

修了这些，Agent 才能在配置各异的服务器上坚持更久，不轻易因为存储或计算细节就中断。尤其是 embedding 操作和索引重建，直接关系到长期记忆是否可靠。

这次加了 GLM-5.2 和 Claude Haiku 4.5 支持，同时把 provider-qualified model IDs 规范化，tool-schema 恢复也更安全。内存部分则做了针对性处理：oversized OpenAI embedding batches 在 431s 前拆分，QMD search 在 transient mode 下保持可用，SQLite 避免在 NFS volumes 上用 WAL，全量 reindex 保留 rollback 和 cache recovery。

起初我认为加新模型主要是为了多样性，但看到内存部分对 embedding batches 和 NFS SQLite 的处理后，我意识到对于自托管部署来说，存储和计算的边界条件处理其实是更基础的可靠性保障。顺便一提，更新日志里特别提到了 431s 这个时间点，可能是 embedding 批次处理超时前的拆分阈值，在大批量向量操作时直接影响是否中断。

更新到这个版本，以及那个默认搜索提供商的改动

更新本身很简单，但有个默认行为变化值得注意。以前没配置 API key 的 web search 提供商（Parallel Free、DuckDuckGo、Ollama、Codex Hosted Search 等）可能会自动选上。现在改成了 explicit opt-in，必须用户主动选择。

把无密钥提供商设为显式开启而不是自动回退，这个改动在不同场景下权衡不同。 对注重成本控制和数据隐私的用户来说，避免了静默使用产生意外开销或隐私问题；对追求最少配置的用户则多了一步选择。文档里专门强调了这一点，建议更新前确认自己的 web search 配置。

执行更新：

# 用稳定频道更新到最新版，并自动确认
openclaw update --channel stable --yes
# 更新后检查版本，确认是否生效
openclaw --version

跑完会看到版本号更新，Gateway 重启后新恢复逻辑和格式支持立即可用。部分 UI 改动如 workspace files 默认折叠、WebChat 流式时 backscroll 保留，也会直接体现在日常操作里。iOS 端 stale Gateway 重连也更顺畅了。

/usage 命令现在有 native full footer、default template、fixed-decimal formatting 和 credential-aware limits， partial usage 数据处理也更清晰。模板坏掉时会给出警告而不是静默输出错误结果。

这些改动加在一起，让日常使用更可预测。恢复和内存的加固是底层，消息格式和 UI 是表层，两者一起作用后，Agent 在真实环境里跑得更稳，输出也更直接可用。

你更新后，有没有试过让 Agent 在 Telegram 里输出带表格的消息，或者遇到 Gateway 重启后任务自动恢复的情况？💬