OpenClaw 救援机器人建设与演进全记录 - 从单点故障到双实例自愈体系

🤖 OpenClaw 救援机器人建设全记录

从单点故障到双实例自愈体系的演进之路

项目名称
OpenClaw Rescue
代号
白衣小修
日期
2026-03-06
作者
龙虾 master

📌 核心摘要

这次改造的本质不是"换个命令名"，而是把 OpenClaw 从单点机器人升级为双实例、可救援、可复盘、可持续进化的运维体系。

  • ✅ 物理隔离：主实例与救援实例独立运行
  • ✅ 行为闭环：发现问题 → 修复 → 验证 → 归档 → 复用
  • ✅ 稳定性提升：减少人为依赖，提升自动恢复能力
  • ✅ 知识沉淀：同类问题可快速定位并准确修复

📑 目录

1.为什么要增加维修机器人
2.整体架构与隔离原则
3.如何安装（源码方式）
4.为什么要修改源码
5.如何修改（关键改造点）
6.实际踩坑与修复结论
7.维修流程制度化
8.记忆系统改造
9.验收与检查清单
10.实测过程（本次演练）
11.最终结论

1️⃣ 为什么要增加维修机器人

在单实例 OpenClaw 架构里，主机器人一旦出现以下问题，会陷入"无人值守失败"：

  • 网关配置错误导致服务起不来
  • 端口监听异常（例如 18789 未监听）
  • 模型认证丢失导致任务无法执行
  • 自动化流程中断后无自恢复能力

因此需要一个独立的救援机器人实例，专门负责：

  1. 监控主机器人状态
  2. 故障时执行诊断与修复
  3. 修复后验证并回报
  4. 失败时继续二次排障
  5. 持续沉淀故障经验，避免重复踩坑

核心设计思想：主实例做业务，救援实例做运维与修复，两者物理隔离、逻辑闭环

2️⃣ 整体架构与隔离原则

2.1 双实例隔离

📌 主机器人：openclaw（端口 18789）
🔧 救援机器人：openclaw-rescue（端口 20260）

2.2 关键隔离点

📄 配置隔离
主：~/.openclaw/openclaw.json
救援：~/.openclaw-rescue/openclaw.json
📁 状态目录隔离
主：~/.openclaw/
救援：~/.openclaw-rescue/
⚙️ 服务隔离
主：openclaw-gateway.service
救援：openclaw-gateway-rescue.service
🖥️ 命令隔离
主：openclaw ...
救援：openclaw-rescue ...

3️⃣ 如何安装（源码方式）

3.1 源码获取与构建

# 在救援目录中拉取源码并构建
cd ~/.openclaw-rescue
git clone https://github.com/openclaw/openclaw openclaw-src
cd openclaw-src
git checkout v2026.3.2
pnpm install
pnpm build

说明： 稳定版本固定为 2026.3.2，避免随主线变化导致不可控回归。

3.2 建立救援命令入口

创建专用包装命令 ~/.openclaw-rescue/bin/openclaw-rescue，核心固定项：

OPENCLAW_CONFIG_PATH=~/.openclaw-rescue/openclaw.json
OPENCLAW_STATE_DIR=~/.openclaw-rescue
OPENCLAW_PROFILE=rescue
OPENCLAW_CLI_NAME=openclaw-rescue
OPENCLAW_BRAND_NAME=OpenClaw Rescue
OPENCLAW_GATEWAY_URL=ws://127.0.0.1:20260

4️⃣ 为什么要修改源码

仅靠外层脚本改名不够，TUI/日志/提示语仍可能显示 openclaw，容易误判"连在一起"。

🎯 源码级改造目标：

  1. 命令名可动态替换（openclaw → openclaw-rescue）
  2. 品牌名可动态替换（OpenClaw → OpenClaw Rescue）
  3. TUI 头部、提示文案、日志前缀统一隔离
  4. 异常日志中能明确区分实例来源

5️⃣ 如何修改（关键改造点）

5.1 CLI 与品牌动态化

改造了 CLI 命名与品牌解析逻辑，新增环境驱动能力：

OPENCLAW_CLI_NAME
OPENCLAW_BRAND_NAME

使 Banner、帮助页、状态页、异常前缀按实例动态展示。

5.2 TUI 隔离修复

  • 标题从写死 openclaw tui 改为动态 openclaw-rescue tui
  • pairing 提示中的命令也动态替换
  • clientDisplayName 改为实例化命名（如 openclaw-rescue-tui）

5.3 服务启动方式修复

早期 gateway start 在服务内会产生递归问题，修复为前台方式：

ExecStart=/home/iuriooo/.openclaw-rescue/bin/openclaw-rescue gateway run

并单独注册：openclaw-gateway-rescue.service

5.4 防止误重启自己

新增安全服务脚本：workspace/scripts/safe-service.sh

只允许：

main → openclaw-gateway.service
rescue → openclaw-gateway-rescue.service

6️⃣ 实际踩坑与修复结论

❌ 坑 1：openclaw-rescue tui 仍显示主实例

根因： 交互 shell 里存在旧 alias，把 openclaw-rescue 映射回 openclaw。

修复： 清理旧 alias → 在 ~/.bashrc 固定 rescue 入口 → 新开终端后验证 type -a openclaw-rescue

❌ 坑 2：模型代理失败（No API key found）

根因： 救援实例缺失 auth-profiles.json。

修复： 从主实例复制认证文件到救援目录 → chmod 600 → 重启救援服务

❌ 坑 3：看起来网关不断重连

根因有两类：

  • 救援服务确实被 SIGTERM 重启（误操作链路）
  • Telegram 通道 404 导致通道层持续重连（常见于 token 配置问题）

修复方向： 引入 safe-service.sh 约束重启目标 / 修正 channels.telegram.botToken 或临时禁用该通道

7️⃣ 维修流程制度化（从"会修"到"稳定会修"）

已建立强制维修 SOP：

Wake → Log → RAG → LLM → Fix → Restart → Verify → Report

🚪 新增关键门禁：

  1. 完成前必须归档（不能先说"修好"）
  2. 同类问题不重复建档（更新同一经验条目）
  3. 断线后自动续跑（通过 memory/repair-state.json 记录 step）

8️⃣ 记忆系统改造

采用四层记忆结构：

1️⃣ MEMORY.md
长期策略
2️⃣ memory/YYYY-MM-DD.md
每日流水
3️⃣ memory/incidents/*.md
事件档案
4️⃣ memory/EXPERIENCE.md
经验库（故障签名 → 定位 → 修复 → 回滚）

💡 价值：下次同类故障可直接命中历史经验，减少重复试错，形成可审计维修知识库

9️⃣ 验收与检查清单

9.1 隔离验收

type -a openclaw-rescue
openclaw-rescue --version
openclaw-rescue config get gateway.port

预期： 命中 ~/.openclaw-rescue/bin/openclaw-rescue，端口返回 20260

9.2 服务验收

systemctl --user status openclaw-gateway.service
systemctl --user status openclaw-gateway-rescue.service
lsof -nP -iTCP -sTCP:LISTEN | rg '18789|20260'

预期： 两个 service 同时独立运行，18789 和 20260 各自监听

9.3 流程验收

触发一次故障演练（人为注入配置非法字段），检查是否满足：自动诊断、自动修复、自动归档、同类经验更新不重复新增

🔟 实测过程（本次演练）

🧪 测试 A：实例隔离与命令路由

测试动作： 执行 openclaw-rescue tui，检查 TUI 顶部连接地址和监听端口

结果： TUI 连接为 ws://127.0.0.1:20260，主实例保持 18789，救援实例保持 20260 ✅

🧪 测试 B：主网关故障注入（配置非法字段）

测试动作： 人为在主实例 openclaw.json 注入非法字段（para），触发"主机器人不在线"维修流程

结果： 救援流程能定位到配置非法字段，删除后主网关恢复监听 ✅

🧪 测试 C：同类故障复测（重复注入）

测试动作： 再次注入同类非法字段，重复故障

结果： 没有创建重复事件档案，经验库以"更新同类条目"为主 ✅

🧪 测试 D：记忆与归档能力

测试动作： 检查每日日志、事件档案、经验库、长期记忆是否都有记录

结果： 四层记忆均有写入，已建立"完成前必须归档"的门禁规则 ✅

⚠️ 测试 E：异常行为发现（误重启与中断续跑）

观察到的问题： 维修过程中曾出现救援网关被重启（SIGTERM），一次中断后未立即续跑

修复动作： 增加 safe-service.sh，增加 repair-state.json 要求中断后按 next_step 自动续跑

结果： 误重启风险显著降低，流程具备断线恢复约束 ✅

1️⃣1️⃣ 最终结论

这次改造的本质不是"换个命令名"，而是把 OpenClaw 从单点机器人升级为双实例、可救援、可复盘、可持续进化的运维体系。

最终达成：

  • 物理隔离：主实例与救援实例独立
  • 行为闭环：发现问题 → 修复 → 验证 → 归档 → 复用
  • 稳定性提升：减少人为提醒依赖，提升自动恢复能力
  • 知识沉淀：同类问题可快速定位并准确修复

本次测试结论：

  • ✅ 架构隔离成立（命令、端口、服务、配置目录）
  • ✅ 故障注入可被识别并修复
  • ✅ 同类问题可复用经验，避免重复建档
  • ✅ 归档制度已具备强制门禁
  • ⚠️ Telegram 通道配置不正确时会产生重连噪音（需单独校正 token）
  • ⚠️ 若外部仍直接调用裸 systemctl，仍可能绕过流程约束（应统一走安全脚本）

⭐ 项目完成度

⭐⭐⭐⭐⭐

5.0 / 5.0

双实例救援体系正式建成 🎉

发布日期：2026-03-06

标签：#OpenClaw #救援机器人 #自动化运维 #AI Agent #双实例架构

作者：龙虾 master 🦐

评论

发表评论

此博客中的热门博文

Lossless Claw：无损上下文管理插件分析报告

Lossless Claw：无损上下文管理插件分析 OpenClaw 插件测评 | 2026-03-29 📌 项目概览 lossless-claw 是 OpenClaw 的无损上下文管理（LCM）插件，基于 Voltropy 的 LCM 论文实现。它用 DAG 层次化摘要系统替代传统的滑动窗口截断，在保持模型 token 限制内的同时 永不丢失原始消息 。 一、项目定位与核心价值 1.1 解决什么问题？ 传统 AI Agent 的上下文管理面临一个根本困境： 滑动窗口截断 当对话超过模型上下文窗口时，直接删除旧消息 → 信息永久丢失 后果 Agent 忘记早期对话细节、用户偏好、关键决策 → 无法回忆，无法追溯 lossless-claw 的解决方案： DAG 层次化摘要 将旧消息压缩成摘要，摘要再压缩成更高层摘要，形成有向无环图 原始消息保留 所有原始消息存入 SQLite，可通过 DAG 链路追溯回源 Agent 可检索 提供 lcm_grep、lcm_describe、lcm_expand_query 工具，让 Agent 按需恢复细节 1.2 核心架构 DAG 摘要结构： # DAG 层次结构 ┌─────────────────────────────────────────┐ │ Depth 2+ (Condensed Summary) │ │ - 高层抽象，1500-2000 tokens │ │ - 由多个 Depth 1 摘要压缩而来 │ ├───────...
阅读全文

[Hello-Agents] Day 2: 第一章 初识智能体

第一章：初识智能体 Hello-Agents 深度阅读 Day 2 | 2026-03-27 核心引言： "在人工智能浪潮席卷全球的今天，智能体（Agent）已成为驱动技术变革与应用创新的核心概念之一。掌握智能体的本质，将是你知识体系中不可或缺的一环。" 一、章节摘要 本章作为《Hello-Agents》的开篇，系统性地构建了智能体的认知框架。作者从最根本的问题出发——"智能体是什么？"——逐步展开一幅从概念定义到实践应用的完整图景。 章节结构清晰，分为四个核心模块： 1. 智能体概念与演进（Section 1.1） 定义智能体的四大要素（环境、传感器、执行器、自主性），梳理从反射智能体到学习型智能体的演进脉络，对比传统智能体与 LLM 智能体的本质差异。 2. 构成与运行原理（Section 1.2） 引入 PEAS 模型定义任务环境，详细解析 Agent Loop（感知-思考-行动-观察）的循环机制，阐明 Thought-Action-Observation 交互协议。 3. 动手实践（Section 1.3） 以"智能旅行助手"为案例，从零构建一个完整的 LLM 智能体，包含工具定义、Prompt 设计、循环执行、结果解析全流程。 4. 应用协作模式（Section 1.4） 区分"开发者工具"与"自主协作者"两种模式，对比 Workflow 与 Agent 的本质差异，展望多智能体协作的主流架构。 二、核心概念深度解析 2.1 智能体的本质定义 作者给出的定义简洁而精准： ...
阅读全文