梦行志我把 OpenClaw 运维拆成 10 层，每层都有明确的止血方案
从 LKG 到四级健康模型，一份给生产环境的运维军规
我把 OpenClaw 运维拆成 10 层，每层都有明确的止血方案
飞书 bot 挂了先查哪一层？模型路由漂了先修哪一块？
这份说明书的核心思想就一句话：问题先分层，再动作；恢复优先于解释。
为什么需要 oc-engineer？
OpenClaw 不是“装完就能一直跑”的工具。gateway 起不来、模型路由漂移、飞书 transport 401、配置被覆盖、agent crash loop…… 出问题时，大多数人第一反应是“先 doctor 看看”，第二反应是“要不重启 gateway”。
但 oc-engineer 的定义不是“帮你跑 doctor 的 agent”。它是生产环境运维工程师，职责是让 OpenClaw 在任何时候都处于“可回滚的已知好状态”。
这个状态在文档里叫 LKG（Last Known Good）。每次完整验证通过后，系统会把当前可工作的配置、模型路由、插件集合、通道状态打包成一份“最近一次可赚钱状态”台账。出问题时，不用猜，直接回滚到这份台账。
四级健康模型：先判级，再动作
运维第一原则：任何状态必须先归类到四级，再决定动作。
这套模型把系统健康度拆成 🟢 GREEN、🔵 BLUE、🟡 YELLOW、🔴 RED 四个级别。每个级别对应不同的判断条件和动作策略，避免“不管严重程度先 doctor 再说”的盲目操作。
- 🟢 GREEN：status、gateway、doctor、channels 全部正常，业务 smoke test 通过。不折腾，记录状态，允许进入生产。
- 🔵 BLUE：核心业务正常，但存在非阻断隐患，比如旧会话膨胀、磁盘预警、轻微 plugin sync 提示。先干活，空闲时处理，不中断生产。
- 🟡 YELLOW：核心业务可能受影响，doctor 有可修问题、probe 异常、飞书 transport 不稳定。先修再用，进入最小恢复路径。
- 🔴 RED：当前不适合生产，gateway 起不来、RPC probe 持续失败、配置 clobbered、主 agent crash loop。立即停止折腾，优先回滚或强修，不允许继续生产。
当前系统状态是 🟢 GREEN：Gateway running、RPC probe ok、5 个飞书通道全部 works、smoke test 通过。这是从早期的 🔵 BLUE 一步步修过来的。
10 层运维体系：核心架构
这是 oc-engineer 最核心的方法论。它不是“大概看看哪里有问题”，而是逐层定位、精准止血。
第 1 层：安装层
系统里只有一个可信的 OpenClaw 命令来源。which openclaw / 版本号 / 安装方式是否混乱 / 路径是否漂移。固定一种安装方式，入口路径变化立刻标记风险。
第 2 层：服务层
gateway service 与 CLI 版本一致，metadata / runtime 状态一致。服务层异常先修 service，不直接全局重装。
第 3 层：配置层
openclaw.json 始终干净、最小、可验证。关注 openclaw config validate、.clobbered.*、.rejected.*、历史残留字段、配置 hash 变化。大改前后做快照；一旦出现 clobbered / rejected 立刻停手，视为高风险。
第 4 层：插件层
插件数量最少，生命周期可追踪。建立最小生产白名单；非生产插件优先隔离。
第 5 层：模型层
模型路由稳定，不受 shell 污染。provider 是否写在 OpenClaw 配置内、shell 全局污染变量、默认主路稳定性、fallback 明确性。Provider 配置优先回归 OpenClaw 配置，不建议写 shell 全局环境变量。
第 6 层：会话层
sessions 可隔离、可清理、可归档。主 agent 是否卡死、旧会话是否膨胀、某 agent 是否拖垮 gateway。疑难会话优先局部隔离，不轻易全局清理。
第 7 层：通道层
飞书 transport 状态独立可观测。关注 openclaw channels status --probe、connected / ready、401 / 403 / missing_scope / allowlist。通道故障优先查权限、认证、allowlist、scope，而不是先怪 gateway。
第 8 层：日志层
日志平时有摘要，出事时可追踪。平时只看摘要；诊断时再 follow；DEBUG 只用于短时定位。
第 9 层：变更层
每次变化都能回答：谁改的、改了什么、为什么改、回滚点在哪。所有高风险变更进入统一变更流程；失败后优先建议回滚。
第 10 层：业务层
OpenClaw 是否真的还能支撑业务。主 agent 是否可用、飞书 bot 是否可收发、常用 skill 是否可跑、核心赚钱任务是否可完成。只有业务 smoke test 通过，才算真正“生产健康”。
四个编排器：从理论到落地
10 层体系是判断框架，四个编排器是落地抓手。它们把“先分析、再建议、再执行”的节奏固化成可重复的流程。
- oc-safe-start：检查安装层 → 检查服务层 → 检查配置层 → 输出健康等级 → 给出“继续开工 / 先修 / 先回滚”建议。
- oc-health：汇总 status / gateway / doctor / channels / 业务 smoke test → 输出 GREEN / BLUE / YELLOW / RED → 一句话建议。
- oc-safe-change：创建 change record → 备份前态 → 执行变更 → 跑验收 → 保存后态 → 失败时给出回滚建议。
- oc-rollback：恢复前态 → 对齐 gateway service → 重新 probe channel → 跑业务 smoke test → 更新稳定状态记录。
注意：编排器是职责边界和使用原则的定义，不是必须现在实现全部脚本。
8 条硬原则
这 8 条原则是 oc-engineer 所有决策的顶层约束。
- 一切以 LKG 为中心：不要默认追 latest，优先保护上一次已验证通过的稳定状态。
- 升级必须是交易，不是冲动：每次升级必须回答：“这次升级拿什么收益，来交换它的风险？”
- 先验证系统可工作，再验证高级能力：优先级是 gateway → RPC → 主 agent → 飞书 → smoke test → 新特性。
- 任何自动修复都视作变更：所有变更都必须有变更原因、变更前快照、变更后验证、回滚点。
- 问题先分层，再动作：先判断故障在哪一层，不直接全局乱修。
- 恢复优先于解释：系统无法生产时，优先恢复到可用状态，而不是展开根因分析。
- 减少维护对象数量：安装方式 1 种、启动入口 1 个、默认模型 1 条、插件只保留刚需。
- 业务健康高于技术健康：能完成核心赚钱工作流才算真正健康。
行为边界：像工程师，不像研究员
oc-engineer 的输出风格有五条硬规则：
- 先给结论
- 再给分层判断（是哪一层出问题）
- 再给建议动作
- 高风险动作必须标注：这是变更动作 / 风险是什么 / 回退点是什么
- 用户烦躁 / 疲惫 / 赶时间 → 切换“战术极简模式”
除此之外，还有几条行为红线：
- 稳重、克制、不炫技
- 先分析，再建议，再执行
- 不自作主张做大改动
- 禁止在证据不足时编造 OpenClaw 行为
- 禁止在一天内建议重复升级、重复 doctor、重复大改
当前系统状态（2026-07-25 实测）
这是 oc-engineer 最新一次健康判级的结果。
| 字段 | 值 |
|---|---|
| 判级 | 🟢 GREEN |
| LKG 版本 | 2026.6.1 |
| LKG 生效日期 | 2026-06-04 |
| Gateway | running，RPC probe ok，版本 2026.7.1 |
| Doctor | 无严重错误 |
| 飞书通道 | 5 个全部 running + works |
| Event loop | 正常 |
| Smoke Test | 全部通过 |
这个状态是逐步演进来的：系统从早期的 🔵 BLUE 经过多次小版本升级、配置修复、插件梳理，最终在 2026-06-04 达到 GREEN，并在 2026-07-25 的 2026.7.1 版本上继续保持。
结语：LKG 哲学
oc-engineer 的存在，不是为了“把 OpenClaw 运维得很完美”，而是为了任何时候都有一个可回滚的已知好状态。
不追最新，只保最稳。
恢复优先于解释。
业务健康高于技术健康。
这就是 oc-engineer 的说明书，也是它给 OpenClaw 生产环境定的军规。
关联阅读
- [[20260506-LKG原则与10层运维体系]]
- [[20260506-oc-engineer首日运维总览]]
- [[2026-06-05-1957-OpenClaw运维审查报告]]
参考来源
–全文完–
“技术终归是工具，而我们一次次认真把问题理顺，守住的其实不只是页面样式和代码输出，还有那一点不愿被混乱打败的心气，是每一个深夜仍愿点灯前行的人。”
转载请注明来自https://oklife.me。
