先给判断
OpenClaw 已经公布了 extended-stable 渠道、成熟度评分和新的治理安排；这些是值得审查的维护机制，不是「项目已经稳定」的证据。对计划把它接入真实工作流的人，正确问题不是「有没有 extended-stable」，而是：我运行的具体版本线支持到何时、哪些修复会回移、覆盖了哪些端到端路径，出错时如何退出。
本文的观察窗口是官方记录与文档快照所覆盖的 2026-05-05 至 2026-08-09；复查日期为 2026-08-09。本文没有取得按版本的升级成功率、事故恢复时间或独立可复现的可靠性数据，因此不把任何项目方目标改写成实际成效。
已确认：一次事故之后，项目方宣布了什么
在 2026-05-05 的复盘中，OpenClaw 作者把 2026.4.24 与 2026.4.29 附近的发布描述为一次严重的使用体验退化：网关变慢、部分安装卡在插件依赖修复循环，多个消息渠道表现变差，部分用户降级。文中将其归因于启动和更新路径中的插件依赖修复、尚未完全拆开的 bundled/external plugin、ClawHub 制品元数据仍在调整，以及网关冷路径执行了过多工作的组合，而不是一个单独的 bug。
2026-07-30，项目方宣布 extended-stable 渠道。首条 2026.6.33 以 2026.6.11 为基础，已经加入从后续版本回移的安全性与可靠性修复；计划每月从 YYYY.M.33 开始一条 extended-stable 线。若安全性或可靠性修复被回移，该线路的 patch 版本递增一位；每条 extended-stable 线路至少支持到下一条 extended-stable 切出、最短一个月。原文把这称为「迈向正式 LTS」的一步，不能把它写成已经宣布了正式 LTS，更不能推断所有未来修复都会回移。
2026-08-08，2026.6.34 已作为 extended-stable 的维护 patch 制品发布。官方将它描述为定向安全性与可靠性修复，不增加发布线的新功能；Release verification 还称 npm 与 amd64/arm64 容器的 extended-stable 别名当前解析到 2026.6.34。这只确认一个标为定向安全性与可靠性维护 patch 的制品已经发布，不能据此观察到持续的维护周期，更不能证明可靠性结果已经改善。
openclaw update --channel extended-stable 的渠道切换流程是 package-only、foreground-only；这不是对所有发布物的概括。v2026.6.34 发布物另有 npm 与 amd64/arm64 容器 extended-stable 别名。保存后的渠道选择只有在启用 update.checkOnStart 时才会给出只读更新提示，且不会自动应用更新。精确目标解析或精确 package 验证失败会终止，不会回退到 latest、beta 或 dev。git 安装不支持该渠道，原 checkout 会保持不变。
Maturity scorecard 把 maturity 表述为 quality 与 completeness 的组合；两项均参考未解决 issue、与同类服务的比较和人工判断。7 月 30 日的公告称，mature 功能的 issue 将获得标签与维护优先级，相关功能将配置生产端到端测试；同一公告的目标是所有 stable 功能的端到端覆盖率超过 90%。当前 Scorecard 的表述则是让 mature Stable-or-better 功能的端到端覆盖率随时间超过 90%。两种措辞并不相同，且都只是项目方的测试承诺，不是已达成的覆盖率、外部认证或逐项验收结果。
R35B 于 2026-08-09 访问并复查 Scorecard；页面标注 Last updated: 2026-08-02，底层 QA evidence 时间为 2026-08-02T16:03:38.894Z。快照显示 overall maturity 为 68%（Alpha），deterministic coverage 为 6%（Experimental）；完整 taxonomy 验证列出 279 项检查：218 通过、5 失败、49 阻塞、7 跳过；确定性 QA 覆盖为 2,002 个功能/覆盖标识中的 133 个（6.6%），页面顶部将其显示为 6%。68%、6% 与超过 90% 分别对应综合成熟度、当前确定性 QA 覆盖和特定子集的长期 E2E 覆盖目标，不能直接相互比较。
2026-07-08 的基金会文章还称 OpenClaw 已成为美国 501(c)(3) 非营利组织，并开始建设全职团队。它支持的事实是项目方正在把治理、资金与维护者支持写入组织安排；它不能单独证明维护能力、资金持续性或审查质量已经覆盖了插件和集成生态。
这套机制可能解决什么
一个面向 Agent 的版本升级往往同时触碰模型调用、凭据、外部服务、消息渠道、插件依赖和长任务状态。把快速更新渠道与需要回移修复的 extended-stable 渠道并行维护，理论上能让使用者围绕选定渠道组织变更评审、回归检查和内部文档。评分卡则能把「可安装」与「项目方认为已成熟」分开，并把功能状态、issue 和测试承诺放到同一讨论面上。
这只是机制层面的推断。它成立的前提是项目持续按规则切线、回移修复、说明例外，并把测试覆盖到用户确实依赖的升级和恢复路径。任何一个前提落空，渠道名称和评分标签都不足以降低实际风险。
仍不能下的结论
六条来源都来自 OpenClaw。文章中的关键工作负载、企业采用、合作规模、基金会影响与未来目标属于当事方叙述；本文不使用它们来证明活跃用户、留存、故障率或商业结果。评分里包含人工判断，不能当作第三方认证；基金会的成立也不等于单点依赖已消失。
同样，本文核查的六条材料没有给出：按版本的升级失败率、回归率、平均修复时间、完整跨版本/插件兼容性矩阵、测试环境组合、用户环境覆盖数据、跨环境升级成功率，或独立的事故数据。extended-stable 的最短支持期是项目方声明的下一条线出现前、至少一个月；它不等于对任何任务连续性的保证。
反例：extended-stable 与评分卡机制也会制造新的维护面
同时维护快速更新渠道与需要回移修复的 extended-stable 渠道，仍意味着更多回移、兼容性测试、发布说明和安全响应。资源不足时，这可能延迟关键修复，或让渠道之间的行为逐渐分叉。
评分卡已经公开了确定性 QA 汇总、判断输入和测试承诺，但其说明没有把端到端覆盖率列为成熟度评分的输入。外部使用者仍需要独立测试、生产 E2E 的环境与场景映射、长期 coverage 与失败趋势、测试环境组合与用户环境覆盖数据，以及实际升级与恢复结果，才能理解一个标签对自己的工作流意味着什么。
生产端到端测试只能代表被选中的操作系统、账户、渠道和任务组合。它不会穷尽自建插件、权限配置错误、外部平台规则变化或不可逆操作。涉及资金、医疗、法律、隐私或外部发送的工作流，即使使用了 extended-stable 渠道，仍需要最小权限、人工批准、日志和可执行的回退计划。
下一次复查应寻找什么
要把本文的判断从「机制值得观察」升级为「可靠性得到改善」，下一次应追踪公开 Scorecard 中的 coverage、failed/blocked QA evidence，生产 E2E 的环境与场景范围，以及实际升级与恢复结果是否持续改善；同时观察下一月线路是否按规则切出、后续安全性与可靠性修复是否持续回移。2026.6.34 只证明维护 patch 制品出现过一次；缺少后续节奏和结果证据时，最稳妥的用法仍是把 extended-stable 当作待验证的变更管理选项，而不是稳定性的证明。
来源与口径
本文只使用六条 OpenClaw 官方公开记录：事故复盘、Foundation 公告、extended-stable 与评分卡公告、2026.6.34 Release、Maturity scorecard 和 Release channels。Scorecard 的首次发布日期未知，但页面显示最后更新于 2026-08-02；Release channels 未显示可靠发布日期或更新时间，两者均按无日期来源记录。它们足以确认项目方公开的事故描述、版本机制、Scorecard 快照、目标和一次维护 patch；不用于独立确认采用规模、可靠性成绩或任何商业数字。