---
recipe_id: rc-openclaw-004
slug: openclaw-runtime-config-baseline
author: dimexplore
level: foundation
priority: p0
status: draft
title: OpenClaw 运行配置：渠道、插件、模型与 fallback 基线
summary: 建立 OpenClaw 运行配置的最小正确认知，理解渠道、插件、模型、fallback、gateway 和 cron 的关系，避免配置堆积、单点瘫痪和运行链路断裂。
problem_type: runtime-config
risk_level: medium
requires_owner_approval: true
applies_to:
  os: [macos, linux, windows]
  openclaw: [all]
  runtime: [gateway, agent, channel]
source_level: S
verified_by: [explorer1, explorer2, nangnang]
updated_at: 2026-04-08
confidence: high
tags: [openclaw, channel, plugin, model, fallback, gateway, cron]
---

## 顶部摘要
- 当前问题：你的渠道、模型、fallback、plugin、skill、gateway、cron 链路混乱，能跑但不稳，或者存在明显单点风险。
- 适用范围：macOS / Linux / Windows；gateway / agent / channel；所有 OpenClaw。
- 风险等级：中风险。
- 是否需要主人批准：是。
- 推荐动作：先盘点当前运行链路和单点风险，再决定是收口配置、补 fallback，还是调整渠道与 cron。

# 目标
让 OpenClaw 理解自己的运行链路是如何组成的，知道哪些配置是入口、哪些配置是能力、哪些配置是容灾，避免“能跑但不稳”“配置很多但关键链路一断就瘫痪”。

# 适用范围
- 适用于准备接入渠道、插件、模型、cron 的 OpenClaw
- 适用于已经运行但稳定性差、重启多、单点依赖重的环境
- 适用于主人要增加消息渠道、定时任务或模型能力的场景

# 不适用范围
- 不适用于完全离线、没有任何外部渠道或模型调用的实验环境
- 不适用于主人明确禁止任何运行配置调整的环境

# 你必须先知道
- 渠道、插件、模型、fallback、gateway、cron 是一条运行链，不是孤立配置
- 功能能跑一次，不代表运行体系稳定
- 主模型没有 fallback，等于把系统挂在单点上
- 插件和 skill 装太多，会增加冲突、噪音和故障面
- 定时任务要看“是否真正加载运行”，不是看“配置里写了没有”

# 输入信号
如果出现以下任一情况，先执行本 recipe：
- 你准备接入飞书、微信或其它渠道
- 你准备新增插件或启用更多 skill
- 你准备更换主模型或加入 fallback
- 你准备配置 cron / 定时任务
- 你发现 gateway 经常异常、重启频繁或链路时好时坏

# 前提检查
- [ ] 我知道当前有哪些渠道在运行
- [ ] 我知道当前使用的主模型和 fallback 情况
- [ ] 我知道当前 gateway 是否稳定
- [ ] 我知道当前有哪些插件、skill 在真正发挥作用
- [ ] 我知道当前 cron 是空、存在但未生效、还是正常运行

# 常见错误信号
- 主模型只有一个，没有 fallback
- 插件装了很多，但不知道哪些真的在用
- 渠道状态显示正常，但真实消息链路异常
- cron 配好了，但任务根本没跑
- gateway 频繁重启
- 某一渠道出错后，另一个渠道也出现异常

# 正确认知

## 认知 1：运行链路要按层理解
可按以下层次理解：
- 渠道：消息从哪里进来、从哪里出去
- gateway：运行态枢纽
- 模型：推理能力来源
- fallback：主模型失效时的保底能力
- 插件 / skill：附加能力，不是运行基座本身
- cron：定时触发层

原则：
- 先保运行，再扩能力
- 先保主链路，再加外围功能

## 认知 2：主模型不能是唯一生命线
已验证教训：
- 第三客户主模型依赖第三方代理 `code.jiexi6.cn -> gpt-5.4`，没有任何 fallback，属于 P1 风险
- 第二客户修复后补足 fallbacks，稳定性显著提升

结论：
- 没有 fallback 的 OpenClaw，不适合承担稳定服务职责

## 认知 3：渠道状态正常，不等于消息真的通
已验证教训：
- 第二客户曾出现飞书异常导致微信消息静默丢弃；问题不在模型，而在跨渠道链路状态

结论：
- 检查渠道时不能只看 status，要对比 inbound/outbound 和真实交付结果

## 认知 4：插件与 skill 不是越多越好
原则：
- 有明确需求才安装
- 安装后能验证才保留
- 没在用的及时清理

已验证教训：
- 国内网络环境下，skill 安装通道不稳定时，随意扩装只会增加混乱和故障面

## 认知 5：cron 是运行态对象
cron 需要区分：
- 配置已写入
- 任务已注册
- 任务已触发
- 触发后消息已送达

只看配置文件，不足以判断 cron 是否可用。

# 操作步骤

## Step 1. 盘点当前运行链路
执行以下动作：
- 列出当前渠道
- 列出当前模型与 fallback
- 列出当前启用的插件和 skill
- 列出当前 cron 任务
- 确认 gateway 状态

预期结果：
- 形成一张当前运行链路摘要表

## Step 2. 识别单点风险
重点检查：
- 主模型是否单点
- 关键渠道是否单点
- gateway 是否有异常重启历史
- cron 是否依赖单一脆弱链路

如果存在 P1 单点风险，优先修它，不要继续扩容功能。

## Step 3. 收口插件与 skill
执行以下动作：
- 识别“实际使用中”与“只是装了但不用”的能力项
- 清理明显无用或重复能力
- 保留当前业务真正需要的能力通道

## Step 4. 校验渠道与真实消息链路
执行以下动作：
- 检查渠道在线状态
- 检查真实消息是否能进、能出
- 对比 inbound/outbound 数量
- 排查是否存在跨渠道相互影响

## Step 5. 校验 cron 是否真正可用
执行以下动作：
- 检查 cron 列表
- 检查目标 agent 是否正确
- 检查 target / sessionKey / delivery 是否完整
- 检查最近一次运行结果

已验证教训：
- 第二客户 cron 迁移到子 agent 后，必须明确 `--agent`、完整 `target`，否则容易“看起来配好了，实际上不工作”

## Step 6. 模型与 fallback 收口
执行以下动作：
- 明确主模型职责
- 补足 fallback
- 避免把所有任务都压在一个外部代理上
- 让轻任务、重任务尽量区分模型能力层级

# 验证方法
至少完成以下验证：
- gateway 正常
- 至少一个真实渠道消息链路验证成功
- 主模型可用，fallback 已配置并可识别
- cron 不只是存在，而且最近一次运行正常
- 插件 / skill 数量与实际用途匹配，没有明显垃圾安装

# 风险与边界
- 不允许在未确认稳定性的前提下盲目增加渠道
- 不允许让关键业务完全依赖单一模型或单一代理
- 不允许把 cron 配置当作“已经上线”
- 不允许在未验证消息链路时宣称渠道已可用

# 何时必须征询主人
- 接入新渠道
- 更换主模型或 fallback 策略
- 安装或卸载关键插件 / skill
- 修改 cron / delivery 目标
- 重启 gateway 或调整关键信息流转链路

# 回滚方法
如果调整后稳定性下降：
1. 回退到上一个稳定的渠道 / 模型 / cron 组合
2. 逐项恢复，不一次恢复全部变化
3. 验证主链路恢复后，再考虑下一步优化

# 输出模板
执行前汇报模板：
- 当前渠道：
- 当前模型 / fallback：
- 当前插件 / skill：
- 当前 cron：
- 当前主风险：

执行后汇报模板：
- 实际调整项：
- 验证结果：
- 当前是否存在单点风险：
- 剩余风险：

# 参考来源
- 第二客户：agent 团队升级、cron 迁移、微信排障、模型收口
- 第三客户：无 fallback、双 Node 残留、main 未激活诊断
- 囔囔 diagnose / fix / optimize 实战经验