🤖 救援机器人设计文档 - OpenClaw 双网关隔离架构

🤖 救援机器人设计文档

OpenClaw 双网关隔离架构

🎯 项目目标

创建一个独立的救援机器人，监控主 OpenClaw 网关的健康状态，并在检测到故障时自动修复或发送告警。

🏗️ 架构设计

双网关隔离架构

┌─────────────────────────────────────────────────┐
│ 主机器人 (Gateway 18789) │
│ - 大模型：ollama/qwen3.5:397b-cloud │
│ - 嵌入模型：all-minilm │
│ - LanceDB: ~/.openclaw/workspace/memory_db/ │
│ - Telegram: 主 Bot Token │
│ - Session Scope: main │
│ - 用途：日常对话、任务执行 │
└─────────────────┬───────────────────────────────┘
│ HTTP 健康检查 (每 5 分钟)
▼
┌─────────────────────────────────────────────────┐
│ 救援机器人 (Gateway 18790) │
│ - 大模型：ollama/qwen3.5:397b-cloud │
│ - 嵌入模型：all-minilm │
│ - LanceDB: ~/.openclaw-rescue/workspace/... │
│ - Telegram: 救援 Bot Token (独立) │
│ - Session Scope: rescue │
│ - 用途：监控、修复、告警 │
│ │
│ 核心技能： │
│ - health-monitor/ (健康监控) │
│ - auto-repair/ (自动修复) │
│ - alert-notifier/ (告警通知) │
└─────────────────────────────────────────────────┘

资源隔离对照表

资源 主机器人 救援机器人 隔离方式
网关端口 18789 18790 ✅ 端口隔离
工作区 ~/.openclaw/ ~/.openclaw-rescue/ ✅ 目录隔离
LanceDB memory_db/ rescue_memory_db/ ✅ 数据库隔离
Session Scope main rescue ✅ Scope 隔离
Telegram Bot 主 Bot Token 救援 Bot Token ✅ Token 隔离
大语言模型 qwen3.5:397b-cloud qwen3.5:397b-cloud ✅ 模型共享

📊 监控指标

1. 网关健康

  • HTTP 状态码 - GET /api/health 或根路径
  • 响应时间 - >5 秒视为异常
  • Token 验证 - API 调用是否成功
  • 检查间隔 - 从配置文件读取 (默认 30 分钟)

2. 系统资源

  • CPU 使用率 - >90% 告警
  • 内存使用率 - >95% 告警
  • 磁盘使用率 - >90% 告警

3. Session 状态

  • 活跃 Session 数 - 异常增长告警
  • Session 大小 - >180k 预警

🔧 自动修复策略

故障类型 修复动作 重试 失败后动作
网关无响应 systemctl restart openclaw-gateway 3 Telegram 告警
Session 超限 清理空闲 >2h 的 session 1 发送报告
磁盘空间不足 清理旧日志 (>7 天) 1 紧急告警
配置错误 回滚到上一个配置 1 手动干预

📢 告警分级

级别 状态 行动
🟢 正常 所有指标正常，无需行动
🟡 警告 单个指标异常，自动修复成功，记录日志
🟠 严重 多个指标异常，自动修复失败，Telegram 通知
🔴 紧急 网关完全无响应，系统资源耗尽，Telegram + 邮件通知

🛠️ 技能开发计划

技能 1: health-monitor

  • 从配置文件读取健康检查间隔 (默认 30 分钟)
  • 定期检查主网关健康 (HTTP 请求)
  • 收集系统资源指标 (CPU/RAM/磁盘)
  • 分析日志错误模式
  • 将检查结果写入 LanceDB 记忆

技能 2: auto-repair

  • 执行自动修复动作
  • 重启网关服务
  • 清理 session/日志

技能 3: alert-notifier

  • 发送 Telegram 告警
  • 发送邮件告警
  • 告警历史记录

📅 开发计划

阶段 任务 时间 状态
1 基础搭建 (目录 + 配置) 2h ✅ 完成
2 health-monitor 技能 8h ⬜ 待开始
3 auto-repair 技能 8h ⬜ 待开始
4 alert-notifier 技能 4h ⬜ 待开始
5 测试验证 4h ⬜ 待开始
总计 26h

🔑 配置项

主机器人信息

  • URL: http://localhost:18789
  • 健康检查间隔: 30 分钟
  • 工作区: ~/.openclaw/workspace/
  • Session Scope: main

救援机器人配置

  • 端口: 18790
  • 工作区: ~/.openclaw-rescue/workspace/
  • Session Scope: rescue
  • 大语言模型: ollama/qwen3.5:397b-cloud
  • 嵌入模型: all-minilm

告警配置

  • Telegram Chat ID: 1927389589
  • 邮件: techworld.empoli@gmail.com

📝 测试场景

场景 1: 网关无响应

  1. 手动停止主网关 (systemctl stop openclaw-gateway)
  2. 救援机器人检测到故障 (HTTP 请求失败)
  3. 尝试自动重启 (systemctl start openclaw-gateway)
  4. 发送告警通知到 Telegram

场景 2: Session 超限

  1. 模拟大量 session (手动创建或等待自然增长)
  2. 救援机器人检测到 Session >180k
  3. 清理空闲 >2h 的 session
  4. 发送清理报告到 Telegram

场景 3: 磁盘空间不足

  1. 填满磁盘到 95%
  2. 救援机器人检测到空间不足
  3. 清理旧日志 (>7 天)
  4. 发送告警到 Telegram + 邮件

场景 4: 消息隔离验证

  1. 同时向主机器人和救援机器人发送消息
  2. 验证主机器人只响应主 Bot 的消息
  3. 验证救援机器人只响应救援 Bot 的消息
  4. 确认两个机器人的记忆数据不混合

场景 5: Ollama 并发验证

  1. 同时触发两个机器人的 LLM 调用
  2. 验证 Ollama 服务正常响应
  3. 确认没有冲突或错误
  4. 检查响应时间是否正常

文档版本: V1.1

创建日期: 2026-03-05

状态: 🟢 设计完成

评论

发表评论

此博客中的热门博文

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

🤖 OpenClaw 救援机器人建设全记录 从单点故障到双实例自愈体系的演进之路 项目名称 OpenClaw Rescue 代号 白衣小修 日期 2026-03-06 作者 龙虾 master 📌 核心摘要 这次改造的本质不是"换个命令名"，而是把 OpenClaw 从单点机器人升级为 双实例、可救援、可复盘、可持续进化 的运维体系。 ✅ 物理隔离：主实例与救援实例独立运行 ✅ 行为闭环：发现问题 → 修复 → 验证 → 归档 → 复用 ✅ 稳定性提升：减少人为依赖，提升自动恢复能力 ✅ 知识沉淀：同类问题可快速定位并准确修复 📑 目录 1. 为什么要增加维修机器人 2. 整体架构与隔离原则 3. 如何安装（源码方式） 4. 为什么要修改源码 5. 如何修改（关键改造点） 6. 实际踩坑与修复结论 7. 维修流程制度化 8. 记忆系统改造 9. 验收与检查清单 ...
阅读全文

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 智能体的本质定义 作者给出的定义简洁而精准： ...
阅读全文