网关自愈方案设计（起搏器）

讨论时间：2026-03-02 状态：方案讨论，暂不实现

---

🎯 目标

防止 OpenClaw 网关"紫砂"（自杀/挂掉）后无人修复

---

💡 方案设计

核心思路

专门的修复 Session + 外部监控触发

┌─────────────────┐
│  Cron 监控脚本   │ (5分钟检查一次)
└────────┬────────┘
         │ 检测到网关挂了
         ↓
┌─────────────────┐
│ sessions_send   │ 发送修复指令
└────────┬────────┘
         │
         ↓
┌─────────────────┐
│ 修复 Session    │ (独立 session，自动批准)
│ - 检查日志      │
│ - 重启网关      │
│ - 通知用户      │
└─────────────────┘

---

🔧 实现细节

1. 修复 Session

创建专门 CLAUDE.md：

# 网关修复专家

## 自动批准的命令（白名单）
- `openclaw gateway status`
- `openclaw gateway restart`
- `openclaw gateway start`
- `openclaw gateway stop`
- `cat ~/.openclaw/logs/*.log`
- `tail -n 100 ~/.openclaw/logs/*.log`

## 永不批准的命令
- `rm -rf`
- 任何修改配置文件的命令
- 任何删除操作的命令

## 修复流程
1. 检查网关状态
2. 查看最近日志
3. 分析崩溃原因
4. 重启网关
5. 验证恢复
6. 发送飞书通知

关键：严格限制白名单，防止权限滥用

---

2. 监控脚本

位置：~/.openclaw/scripts/gateway-watchdog.sh

#!/bin/bash

# 检查网关是否存活
if ! curl -s http:/localhost:3777/health > /dev/null 2>&1; then
  # 网关挂了，记录日志
  echo "$(date): 网关挂了，触发修复" >> ~/.openclaw/logs/gateway.log
  
  # 调用修复 session
  # 通过 sessions_send 发送修复指令
  # (需要具体实现)
fi

Cron 配置：

*/5 * * * * ~/.openclaw/scripts/gateway-watchdog.sh

---

3. 触发机制

关键问题：网关断联了，谁来触发？

方案A：外部 Cron 监控（推荐）

• ✅ 独立于 OpenClaw
• ✅ 可靠性高
• ⚠️ 需要额外配置

方案B：OpenClaw 内置 heartbeat

• ⚠️ 网关挂了，heartbeat 也挂了
• ❌ 不可靠

结论：必须使用外部监控

---

🎭 三层防护体系

第1层：进程守护（秒级恢复）

工具：macOS launchd / Linux systemd 作用：进程挂了自动重启 优势：最快、最可靠

macOS 配置：

<!-- ~/Library/LaunchAgents/com.openclaw.gateway.plist -->
<key>KeepAlive</key>
<true/>  <!-- 进程挂了自动重启 -->

第2层：修复 Session（智能修复）

作用：

• 检测异常
• 分析日志
• 智能修复
• 通知用户

优势：不只是重启，还能分析原因

第3层：人工介入（最后保障）

作用：

• 自动修复失败
• 发送飞书告警
• 等待人工处理

---

⚠️ 关键挑战

1. 监控进程本身挂了怎么办？

解决：launchd 守护监控进程

2. 修复 Session 也挂了怎么办？

解决：飞书告警 + 人工介入

3. 权限控制

解决：严格白名单 + 永不批准列表

---

📝 实现步骤（待执行）

等准备好了再实现：

1. 创建修复 Session

   • 写专门的 CLAUDE.md
   • 配置自动批准规则
   • 测试修复流程

2. 创建监控脚本

   • 检测网关状态
   • 调用修复 session
   • 记录日志

3. 配置 Cron

   • 每 5 分钟检查一次
   • 异常时自动触发

4. 配置 launchd

   • 进程守护
   • 秒级恢复

---

💡 优化方向

根本原因分析

• 为什么网关会挂？
  • 配置错误？
  • 内存溢出？
  • 端口冲突？
  • 依赖问题？

预防措施

• 配置保护（修改前备份）
• 日志监控（崩溃前预警）
• 资源限制（防止溢出）

---

🔗 相关资源

• Anthropic 渐进式披露：memory/workflows/daily-distill.md
• Obsidian 安全规范：memory/safety/obsidian-safety-rules.md
• 会话管理：sessions_send 工具

---

状态：方案讨论完成，待实现 下一步：等用户决定何时实施