OpenClaw安全加固指南：用Tavily API替换Brave Search并建立配置回滚机制

今天完成了对OpenClaw系统的两项关键安全加固，不仅根除了一个潜在的系统死循环风险，还为日常的运维操作建立了一道安全防线。如果你也在运行类似的 Multi-Agent系统，对稳定性的追求或许能从这里找到共鸣。

工作一：告别Brave Search死循环，拥抱可控的Tavily API

问题现象
在OpenClaw的Multi-Agent系统运行过程中，我遇到了一个棘手的稳定性问题。每当系统内置的 web_search 工具调用Brave Search API时，如果遇到网络波动或API限流，它就会陷入反复重试的怪圈。这直接导致Gateway资源被耗尽，最终整个系统进入死循环假死状态。当四个Agent并发触发搜索时，这个问题尤为明显，一次连接失败就能让系统瘫痪。

根因分析
事后分析，问题主要出在三个方面：

问题点	说明
内置工具不可控	web_search 是OpenClaw原生工具，其失败重试逻辑对用户不可配置。
错误处理粗糙	连接失败后没有优雅降级策略，只会持续不断地尝试重连。
资源占用累积	每次重试都会占用Gateway的连接池，累积起来最终拖垮整个系统。

解决方案：用Tavily API + 自定义Skill接管搜索
核心思路很明确：禁用那个不可控的内置搜索，转而使用我们能够完全掌控的Tavily API，并通过自定义Skill来调用。

步骤 1：禁用内置的Brave Search
首先，在配置中彻底关闭内置的搜索功能。

{
  “tools”: {
    “web”: {
      “search”: {
        “enabled”: false  // 彻底关闭内置搜索
      }
    }
  }
}

步骤 2：创建Tavily自定义Skill
接着，创建一个名为tavily的Skill，用于定义新的搜索行为。

---
name: tavily
description: Default web search using Tavily AI API
metadata:
  openclaw:
    os: [“linux”, “darwin”, “win32”]
    requires:
      bins: [“curl”]
    priority: high
---
# Tavily Search (Default Web Search)
**⚠️ IMPORTANT**: Tavily is now the DEFAULT search provider.
Do NOT use `web_search` tool - it has been disabled.

步骤 3：配置API Key
最后，将你的Tavily API Key配置到环境变量中。

# ~/.openclaw/.env
TAVILY_API_KEY=tvly-dev-***

效果对比
完成迁移后，效果立竿见影：

指标	Brave Search (内置)	Tavily (自定义)
失败重试	无限重试，不可控	单次调用，失败即返回
系统稳定性	偶发死循环	稳定运行
结果质量	需二次解析HTML	结构化JSON，直接可用
AI 友好度	低	高（内置 answer 摘要字段）
响应时间	2-5s	平均1-2s

额外收益
除了根治死循环，切换到Tavily还带来了几个惊喜：

1. 更好的AI集成体验：结果是现成的JSON，省去了解析HTML的麻烦。
2. 内置AI摘要：直接提供总结性的 answer 字段，信息获取效率更高。
3. 更快的响应速度：实测平均1.13秒就能返回结果，搜索体验更流畅。

工作二：建立强制性的配置安全回滚机制

问题背景
在一次修改OpenClaw配置后，我习惯性地直接运行了 openclaw gateway restart，结果酿成了半小时的“事故”：

• 配置有误导致Gateway根本无法启动。
• 系统无响应，没有自动恢复能力。
• 手动排查和修复耗时超过30分钟。

对于一个需要7×24小时运行的Multi-Agent系统来说，这种因 配置变更 导致的停机风险是完全不可接受的。

解决方案：构建三层防护机制
为此，我设计并实施了一套强制性的安全回滚机制，确保任何配置更改都不会让系统“猝死”。

第一层：会话检查（强制记忆）
将安全规则写入AGENTS.md，让它在每次会话开始时都提醒我。

## Every Session
Before doing anything else:
5. **Check for config changes**: Run `~/.openclaw/bin/config-check.sh`
   - if “CHANGED”, use `oc-safe-restart`
**Remember**: After modifying `openclaw.json`,
ALWAYS use `~/.openclaw/bin/oc-safe-restart`
NOT `openclaw gateway restart`!

第二层：自动检测（技术实现）
创建一个config-check.sh脚本，用MD5校验和自动判断配置是否被修改过。

#!/bin/bash
CONFIG_FILE=“$HOME/.openclaw/openclaw.json”
CHECKSUM_FILE=“$HOME/.openclaw/.config_checksum”
current_sum=$(md5sum “$CONFIG_FILE” | awk ‘{print $1}’)
previous_sum=$(cat “$CHECKSUM_FILE” 2>/dev/null)
if [ “$current_sum” != “$previous_sum” ]; then
    echo “CHANGED”  # 提醒必须使用安全重启
    echo “$current_sum” > “$CHECKSUM_FILE”
else
    echo “UNCHANGED”
fi

第三层：安全重启脚本（核心防护）
核心是oc-safe-restart脚本，它实现了 备份 → 启动Watchdog → 重启 → 验证 → 回滚/取消 的完整安全流程。

# 核心逻辑
safe_restart() {
    # 1. 备份当前配置
    cp ~/.openclaw/openclaw.json \
       ~/.openclaw/config-backups/openclaw.json.backup-$(date +%s)
    # 2. 启动 60 秒 Watchdog
    config-watchdog.sh start
    # 3. 重启 OpenClaw
    openclaw gateway restart
    # 4. 验证是否正常
    if check_oc; then
        echo “✅ 重启成功！”
        echo “⚠️  运行 ‘oc-safe-restart -c’ 取消 Watchdog”
    fi
    # 5. 如果 60 秒内未取消，Watchdog 自动回滚
}

Watchdog 机制详解
整个防护流程可以通过下面的流程图来清晰理解：

修改配置
    ↓
运行 oc-safe-restart
    ↓
┌─────────────────────┐
│ 备份当前配置          │
│ 启动 60s Watchdog    │
│ 执行重启             │
└─────────────────────┘
    ↓
系统正常? ──Yes──→ 运行 oc-safe-restart -c (取消 Watchdog)
    ↓ No
60 秒后自动回滚到备份配置

强制规则（写入 MEMORY.md）
最后，将这些规则固化为必须遵守的纪律：

### 强制规则
- ❌ **禁止**: `openclaw gateway restart`（直接重启）
- ✅ **强制**: `~/.openclaw/bin/oc-safe-restart`（安全重启）
- ✅ **修改后**: 必须检查 `config-check.sh`，如 “CHANGED” 则必须使用安全重启
- ✅ **重启后**: 验证正常后必须运行 `oc-safe-restart -c` 取消 watchdog
### 违规记录
- 2026-02-22: 修改 Tavily 配置后直接重启（违规）
- 后果: 需强制执行协议防止再犯

成果总结

今日完成清单
两项核心加固工作均已完成，产出了具体可用的脚本和配置。

工作	状态	关键产出
Tavily API 迁移	✅ 完成	~/.openclaw/skills/tavily/SKILL.md
Brave Search 禁用	✅ 完成	tools.web.search.enabled: false
安全回滚系统	✅ 完成	oc-safe-restart + config-watchdog.sh
强制检查机制	✅ 完成	config-check.sh + AGENTS.md 更新

系统稳定性提升
量化对比能更直观地看到价值：

指标	改进前	改进后
搜索死循环风险	高	消除
配置误操作风险	高	可控（自动回滚）
重启安全性	无保障	60 秒 watchdog 保护
恢复时间	30+ 分钟	自动（<60 秒）

经验与反思

关于 Agent 系统稳定性的思考
这次实践让我深刻体会到，Multi-Agent系统的稳定性，其基石在于基础设施的鲁棒性，而不仅仅是单个Agent的能力。

1. 外部依赖要可控：内置工具如同黑盒，出问题难以调试。将其替换为自定义Skill，意味着拥有了完全的掌控权和调试能力。
2. 配置变更是高危操作：对于在线系统，任何配置修改都必须配有自动化的备份和回滚机制，这是保障SLA的底线。
3. 强制规范胜过口头提醒：依赖人的记忆和自觉总会出错。通过脚本将安全流程强制化、自动化，才是可靠的解决方案。

给 OpenClaw 用户的建议
如果你也在运维OpenClaw多Agent系统，不妨参考以下几点：

1. 评估你的搜索方案：如果Brave Search在你的网络环境下表现不稳定，考虑迁移到Tavily或其他更可控的搜索API。
2. 建立配置安全机制：即使不采用我这里的完整脚本，也务必为自己的系统设计备份和快速回滚方案，这是运维的基本素养。
3. 记录规范到 AGENTS.md：充分利用这个文件，让Agent在每次会话时都自动执行安全检查，最大限度降低人为失误的概率。

技术运维的乐趣，往往就在于用自动化和严谨的流程，将那些令人头疼的风险一点点化解掉。希望我在 云栈社区 分享的这次OpenClaw加固实录，能为你解决类似问题带来一些切实的思路。