1. 项目概述当AI助手学会“自我修复”最近在折腾一个挺有意思的AI智能体项目叫OpenClaw。简单来说它就像一个能帮你处理各种日常任务的数字助手比如查资料、写代码、管理文件甚至控制智能家居。但这次遇到的状况有点特别我的一台运行OpenClaw的设备我们姑且叫它“Claw A”突然宕机了而修复它的是另一台同样运行着OpenClaw的设备“Claw B”。整个过程几乎没有我的手动干预。这听起来有点像科幻电影里的情节一个机器人修好了另一个机器人。但实际上这背后是一套关于AI智能体Agent协同、故障诊断与自动化恢复的实践。对于正在探索AI Agent开发、寻求系统高可用性方案的朋友来说这个“自愈”案例里踩过的坑和总结的经验或许能给你一些直接的参考。这个项目核心围绕“OpenClaw”展开它是一个开源的AI智能体框架。所谓“坏了”在软件层面可能表现为服务进程崩溃、依赖项缺失、配置文件错误或者资源如GPU内存耗尽。而“修好”则意味着另一套OpenClaw系统能够自动或半自动地诊断问题、执行修复命令如重启服务、重新安装依赖、修正配置最终使目标系统恢复服务。这不仅仅是简单的“重启大法”它涉及到智能体间的通信、对远程系统状态的感知、安全的问题诊断逻辑以及一系列精准的操作指令。接下来我就把这个从故障发生到自动恢复的全过程包括背后的设计思路、实操步骤以及我趟过的那些雷详细拆解一遍。2. 核心思路与架构设计2.1 为什么需要“自愈”—— 从单点脆弱到协同韧性最初部署OpenClaw时我只把它当作一个单体应用来对待。它在我的开发服务器上运行得好好的能响应我的各种查询。但问题出在一次系统级更新之后某个底层Python依赖包出现了版本冲突导致OpenClaw的核心服务直接无法启动。当时我正在外出无法立即登录服务器处理导致服务中断了好几个小时。这次经历让我意识到对于期望提供持续服务的AI助手来说单点部署是脆弱的。于是“自愈”系统的构想诞生了。其核心目标不是追求100%的无中断那需要更复杂的分布式架构而是在主节点发生常见软件故障时能有一个备份节点及时介入执行一些预设的、相对安全的修复操作尝试恢复服务为人工深度干预争取时间。这本质上是一种“高可用”的轻量级实践。我选择使用另一台独立的服务器Claw B作为“医生”AgentDoctor Agent它需要具备以下能力状态监控定期检查Claw A的健康状况如API是否可访问、关键进程是否存在。故障诊断当发现异常时能通过SSH等方式连接到Claw A运行诊断命令如查看日志、检查进程状态、验证配置文件初步判断故障原因。修复执行根据诊断结果从预定义的“修复剧本”中选择合适的命令序列执行例如重启Docker容器、重新拉取特定版本的镜像、修改某个配置参数。安全边界所有修复操作必须在一个严格的“安全沙箱”清单内禁止执行rm -rf /、任意文件下载等高风险命令。修复后需再次验证状态。2.2 技术栈选型与工具链搭建要实现上述思路需要组合多个工具。我的选型主要基于“熟悉度”和“轻量级”原则。OpenClaw (ClawPal) 作为智能体基础这是项目的核心。OpenClaw本身是一个框架它允许你定义具有特定技能Skill的Agent。我需要为Claw B上的OpenClaw开发一个特殊的“运维诊断”Skill。这个Skill将封装所有监控、诊断和修复的逻辑。我选择继续使用OpenClaw是为了保持技术栈的统一利用其已有的对话管理、工具调用能力。SSH与Paramiko库实现远程控制Claw B需要安全地连接到Claw A执行命令。我使用了Python的Paramiko库它提供了纯Python的SSHv2协议实现。相比于在系统中配置免密SSH并直接调用ssh命令Paramiko在程序内集成度更高更容易进行错误处理和日志记录。我为其配置了密钥认证并严格限制了Claw B在Claw A上的用户权限一个仅能执行特定sudo命令的专用用户。Docker作为部署与隔离工具我的OpenClaw是使用Docker容器部署的。这带来了巨大便利首先服务的状态运行/停止非常容易检查docker ps其次很多修复操作可以简化为Docker命令docker restart,docker logs,docker exec最后如果需要回滚或重装直接操作镜像和容器即可不会污染宿主机环境。这也是我推荐的生产环境部署方式。健康检查端点与监控策略我为Claw A上的OpenClaw服务添加了一个简单的HTTP健康检查端点例如/health返回服务状态和版本信息。Claw B上的Doctor Agent会定期如每5分钟调用这个端点。如果连续失败则触发诊断流程。同时Doctor Agent也会通过SSH检查Claw A的系统基础指标如CPU/内存使用率、磁盘空间以排除资源不足导致的问题。注意安全是重中之重。Doctor Agent的权限必须被严格限制。我创建了一个名为claw-maintainer的专用用户并配置sudo仅允许其执行systemctl restart docker,docker logs,docker restart等少数几个命令且需要密码密码由Doctor Agent安全存储。绝对禁止赋予其root或无需密码的sudo权限。3. 核心技能Skill开发详解Claw B上的“Doctor Agent”能力核心在于一个自定义的OpenClaw Skill。下面我详细拆解这个Skill的实现。3.1 技能结构与工作流设计这个Skill我命名为system_healer。在OpenClaw框架中一个Skill通常包含触发器Trigger、处理函数Function和工具Tool。我的设计工作流如下定时触发器每5分钟自动运行一次健康检查任务。健康检查函数尝试调用Claw A的/health端点。如果成功且返回状态正常则本次循环结束。故障诊断函数如果健康检查失败则启动诊断流程。通过Paramiko建立SSH连接。依次执行一系列诊断命令并将结果收集回来。决策与修复函数根据诊断结果匹配预定义的修复剧本。修复执行函数执行修复命令并验证修复结果。通知函数无论成功与否都将本次事件通过日志记录并可以集成飞书、钉钉等Webhook发送通知给我。3.2 关键代码模块解析以下是一些核心代码片段和解释。我使用Python作为开发语言。1. 健康检查模块import requests import time def check_health(target_url: str, timeout: int 10) - dict: 检查目标OpenClaw服务的健康状态。 try: response requests.get(f{target_url}/health, timeouttimeout) if response.status_code 200: data response.json() # 假设健康接口返回 {status: healthy, version: 2.7.9} if data.get(status) healthy: return {is_healthy: True, message: 服务运行正常, details: data} else: return {is_healthy: False, message: f服务状态异常: {data.get(status)}, details: data} else: return {is_healthy: False, message: fHTTP状态码异常: {response.status_code}, details: None} except requests.exceptions.ConnectionError: return {is_healthy: False, message: 无法连接到服务可能已宕机, details: None} except requests.exceptions.Timeout: return {is_healthy: False, message: 健康检查请求超时, details: None} except Exception as e: return {is_healthy: False, message: f健康检查过程发生未知错误: {str(e)}, details: None}这个函数是监控的起点。它必须足够健壮能处理网络超时、连接拒绝、JSON解析错误等各种边缘情况。2. SSH诊断模块使用Paramikoimport paramiko from io import StringIO class RemoteDiagnoser: def __init__(self, hostname, username, key_path): self.hostname hostname self.username username self.key paramiko.RSAKey.from_private_key_file(key_path) self.client None def connect(self): 建立SSH连接 self.client paramiko.SSHClient() self.client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) # 注意生产环境应使用更严格策略 self.client.connect(hostnameself.hostname, usernameself.username, pkeyself.key, timeout15) def run_command(self, command: str, use_sudo: bool False, sudo_password: str None) - dict: 在远程主机执行命令并返回结果 if not self.client: raise Exception(SSH未连接) full_cmd fsudo {command} if use_sudo else command stdin, stdout, stderr self.client.exec_command(full_cmd) if use_sudo and sudo_password: stdin.write(sudo_password \n) stdin.flush() exit_code stdout.channel.recv_exit_status() output stdout.read().decode(utf-8).strip() error stderr.read().decode(utf-8).strip() return { command: full_cmd, exit_code: exit_code, output: output, error: error } def diagnose(self) - list: 执行一系列诊断命令 diagnostics [] # 1. 检查Docker服务状态 result self.run_command(systemctl is-active docker, use_sudoTrue) diagnostics.append((Docker服务状态, result)) # 2. 检查OpenClaw容器状态 result self.run_command(docker ps --filter nameopenclaw --format table {{.Names}}\\t{{.Status}}) diagnostics.append((OpenClaw容器状态, result)) # 3. 查看最近100行容器日志寻找错误 result self.run_command(docker logs --tail 100 openclaw_app 21 | tail -50) # 假设容器名为openclaw_app diagnostics.append((容器最近日志, result)) # 4. 检查宿主机资源简化版 result self.run_command(free -h | grep Mem) diagnostics.append((内存使用, result)) result self.run_command(df -h / | tail -1) # 检查根分区磁盘 diagnostics.append((磁盘使用, result)) return diagnostics def close(self): if self.client: self.client.close()这个类封装了所有远程操作。diagnose方法里列出的命令就是根据我以往遇到的常见问题总结出来的“检查清单”。生产环境中你可能需要根据自身情况调整和增加。3. 修复决策与执行模块这是整个系统的“大脑”。我采用了一个简单的规则引擎rule-based来实现因为初期故障模式是可枚举的。我将诊断结果映射到修复动作。class RepairEngine: def __init__(self): self.repair_playbooks { docker_service_inactive: { description: Docker服务未运行, actions: [ {cmd: systemctl start docker, use_sudo: True, expect: 服务启动}, {cmd: systemctl is-active docker, use_sudo: True, expect_stdout_contains: active} ] }, openclaw_container_exited: { description: OpenClaw容器已退出, actions: [ {cmd: docker start openclaw_app, use_sudo: False, expect: 容器启动}, {cmd: docker ps --filter nameopenclaw_app --format {{.Status}}, use_sudo: False, expect_stdout_contains: Up} ] }, openclaw_container_restart_loop: { description: 容器不断重启可能配置错误, actions: [ {cmd: docker logs --tail 20 openclaw_app 21 | grep -i error, use_sudo: False, expect: 分析日志}, # 这里可以更复杂比如识别到特定错误后调用另一个函数来修正配置文件 # 例如{function: fix_config_file, args: {error_line: ...}} ] }, port_conflict: { description: 端口被占用如3000端口, actions: [ {cmd: lsof -i :3000 | grep LISTEN, use_sudo: True, expect: 查看占用进程}, {cmd: kill -9 PID, use_sudo: True, expect: 强制结束进程, note: 需要从上一个命令的输出中提取PID动态生成此命令} ] } } def analyze_and_repair(self, diagnostics: list, ssh_client: RemoteDiagnoser) - dict: 分析诊断结果并执行修复。 返回修复报告。 report {triggered_playbook: None, actions_executed: [], final_status: unknown} # 分析诊断结果匹配故障模式这里简化逻辑 docker_status next((d for d in diagnostics if d[0] Docker服务状态), None) container_status next((d for d in diagnostics if d[0] OpenClaw容器状态), None) if docker_status and docker_status[1][output] ! active: playbook self.repair_playbooks[docker_service_inactive] report[triggered_playbook] playbook[description] # 执行修复动作 for action in playbook[actions]: result ssh_client.run_command(action[cmd], use_sudoaction.get(use_sudo, False)) report[actions_executed].append({ command: action[cmd], result: result }) # 修复后再次进行健康检查 # ... 调用健康检查函数 ... report[final_status] repaired if health_ok else failed elif container_status and Exited in container_status[1][output]: playbook self.repair_playbooks[openclaw_container_exited] # ... 类似地执行修复 ... else: # 未匹配到已知剧本可能需要人工介入 report[triggered_playbook] unknown_issue report[final_status] requires_manual_intervention return report这个规则引擎虽然简单但解决了80%的常见问题。对于更复杂的故障如配置文件语法错误、模型加载失败我目前的策略是记录详细日志并通知我不进行自动修复因为风险太高。3.3 集成到OpenClaw Skill最后需要将上述模块封装成一个OpenClaw Skill并设置定时任务。# 在OpenClaw的技能定义文件中 from openclaw.skill import Skill, tool, trigger import schedule import threading import time class SystemHealerSkill(Skill): def __init__(self): super().__init__() self.diagnoser RemoteDiagnoser(hostnameclaw-a-ip, usernameclaw-maintainer, key_path/path/to/private_key) self.repair_engine RepairEngine() self.target_url http://claw-a-ip:3000 # Claw A的服务地址 # 启动后台监控线程 self.monitor_thread threading.Thread(targetself._monitor_loop, daemonTrue) self.monitor_thread.start() def _monitor_loop(self): 后台监控循环 schedule.every(5).minutes.do(self._health_check_and_heal) while True: schedule.run_pending() time.sleep(1) def _health_check_and_heal(self): 核心监控与修复逻辑 health check_health(self.target_url) if not health[is_healthy]: self.logger.warning(f检测到服务异常: {health[message]}) # 开始诊断 try: self.diagnoser.connect() diagnostics self.diagnoser.diagnose() # 分析与修复 repair_report self.repair_engine.analyze_and_repair(diagnostics, self.diagnoser) self.logger.info(f修复报告: {repair_report}) # 发送通知此处可集成飞书/钉钉Webhook self._send_notification(health[message], repair_report) except Exception as e: self.logger.error(f诊断或修复过程中发生错误: {e}) finally: self.diagnoser.close() else: self.logger.debug(服务健康检查通过。) tool(namemanual_health_check, description手动触发对Claw A的健康检查与修复) def manual_check(self): 提供一个手动调用的工具用于测试或立即触发 self._health_check_and_heal() return 手动健康检查与修复流程已触发。 def _send_notification(self, issue, report): 发送通知的示例函数 # 实现飞书、钉钉或邮件的通知逻辑 pass这样一个具备自愈能力的Doctor Agent技能就开发完成了。它会在后台默默监控并在发现问题时尝试修复。4. 部署与配置实战4.1 环境准备与依赖安装首先你需要在Claw B上部署一个标准的OpenClaw环境。我强烈推荐使用Docker方式这能避免复杂的Python环境冲突。# 在Claw B上 # 1. 安装Docker和Docker Compose (如果尚未安装) # 参考官方文档此处省略 # 2. 克隆OpenClaw项目或使用你自定义的包含healer skill的版本 git clone your-openclaw-fork-repo cd openclaw # 3. 将上面开发的system_healer技能代码放到项目的skills目录下 # 例如: mkdir -p skills/system_healer 将skill文件放入 # 4. 修改Dockerfile或docker-compose.yml确保技能被正确加载 # 通常需要在配置中指定技能路径例如在config.yaml中添加 # skills: # - system_healer4.2 关键配置详解1. SSH密钥配置在Claw B上生成专用的SSH密钥对并将公钥部署到Claw A的claw-maintainer用户下。# 在Claw B上生成密钥 ssh-keygen -t rsa -b 4096 -f /path/to/openclaw_healer_key -N # 无密码短语生产环境建议设置 # 将公钥复制到Claw A ssh-copy-id -i /path/to/openclaw_healer_key.pub claw-maintainerclaw-a-ip然后在Claw A上配置claw-maintainer用户的sudo权限编辑/etc/sudoers.d/claw-maintainer使用visudo -fclaw-maintainer ALL(ALL) NOPASSWD: /usr/bin/systemctl start docker, /usr/bin/systemctl restart docker, /usr/bin/systemctl status docker, /usr/bin/lsof这里只授予了启动/重启docker和查看端口占用的权限没有给stop或rm权限非常关键。2. OpenClaw配置文件在Claw B的OpenClaw配置中需要包含技能和必要的参数。# config.yaml (Claw B) name: Doctor_Agent model: openai:gpt-4 # 或你使用的其他模型Doctor Agent本身也需要LLM来处理更复杂的逻辑判断 skills: - system_healer # 我们开发的技能 # 技能特定配置可以在skill内部通过self.config读取 system_healer: target_host: 192.168.1.100 # Claw A的IP target_health_url: http://192.168.1.100:3000/health ssh_username: claw-maintainer ssh_private_key_path: /app/keys/openclaw_healer_key # Docker容器内的路径 # 通知Webhook lark_webhook: https://open.feishu.cn/...3. Docker Compose配置确保将私钥文件作为卷volume挂载到容器内。# docker-compose.doctor.yaml version: 3.8 services: openclaw-doctor: build: . container_name: openclaw_doctor volumes: - ./skills:/app/skills # 挂载技能目录 - ./config.yaml:/app/config.yaml # 挂载配置文件 - ./keys:/app/keys:ro # 挂载密钥目录只读 environment: - OPENCLAW_CONFIG_PATH/app/config.yaml restart: unless-stopped然后启动服务docker-compose -f docker-compose.doctor.yaml up -d4.3 测试与验证流程部署完成后绝不能直接投入生产。必须进行严格的测试。模拟健康检查手动停止Claw A的OpenClaw服务观察Claw B的日志看是否能检测到并触发诊断。# 在Claw A上 docker stop openclaw_app # 在Claw B上查看日志 docker logs -f openclaw_doctor你应该能看到类似“检测到服务异常”的日志然后进入诊断流程。测试诊断命令在Doctor Skill的日志中检查它执行的SSH命令是否成功返回的结果是否正确解析。测试修复动作这是最需要小心的。先测试最安全的操作比如“重启已停止的容器”。确保Claw A的容器是Exited状态。触发Doctor Agent观察它是否执行了docker start命令。验证Claw A的服务是否恢复。测试安全边界尝试制造一个Doctor Agent剧本中没有定义的故障比如故意损坏配置文件。观察Doctor Agent的行为它应该识别为“未知问题”并发送通知而不是尝试胡乱修复。压力与并发测试短时间内多次触发故障观察Doctor Agent的处理队列和逻辑是否会出现混乱。确保没有竞态条件例如一个修复还没完成另一个监控周期又开始了。5. 常见问题与故障排查实录在实际搭建和运行过程中我遇到了不少问题。这里记录下最典型的几个及其解决方案。5.1 SSH连接失败或权限不足问题现象Doctor Agent日志显示“Authentication failed”或“Permission denied”。排查步骤验证密钥在Claw B宿主机上手动用ssh -i /path/to/key claw-maintainerclaw-a-ip测试连接。如果失败说明密钥或授权有问题。检查权限确保Claw B上的私钥文件权限是600chmod 600 key。Docker容器内挂载的密钥文件同样需要正确权限可以在Dockerfile中COPY时设置或启动脚本中修改。检查用户与sudo确认Claw A上的claw-maintainer用户存在且~/.ssh/authorized_keys中有正确的公钥。使用sudo -l -U claw-maintainer命令验证sudo权限配置是否正确。容器内用户确保Docker容器内运行OpenClaw的用户通常是non-root有读取挂载的私钥文件的权限。5.2 诊断命令执行超时或无输出问题现象SSH命令执行卡住或者stdout/stderr获取不到内容。排查与解决设置超时Paramiko的exec_command本身没有很好的超时控制。我后来改用channel.exec_command配合channel.settimeout()和select模块来实现超时。或者在远程命令中加上timeout包装例如run_command(timeout 30s docker logs ...)。缓冲区问题对于可能输出很长的命令如docker logs要确保读取完整。我使用了stdout.channel.recv_exit_status()等待命令结束然后再读取输出避免死锁。交互式命令像sudo如果需要密码必须像前面代码那样通过stdin写入。确保你的sudoers配置正确如果配置了NOPASSWD则无需交互。5.3 误修复与“修复风暴”问题现象Doctor Agent错误地判断了故障执行了不当的修复操作甚至可能让问题恶化。或者在修复期间监控周期又到了导致重复触发修复形成循环。经验与策略保守的修复剧本只对原因明确、后果可控的问题进行自动修复。例如“容器停止”可以重启“端口占用”可以kill进程需谨慎。但对于“应用内部逻辑错误”、“数据库连接失败”应止步于诊断和告警。状态锁与冷却期在开始修复时设置一个“修复中”的状态锁。在锁定期内跳过后续的健康检查。修复完成后进入一个“冷却期”例如5分钟在此期间即使健康检查再次失败也不立即触发修复防止系统在启动过程中被反复打扰。人工确认机制升级版对于某些中级风险操作可以让Doctor Agent通过通知渠道如飞书向我发送一个包含修复方案的卡片我点击“确认”后它再执行。这实现了“半自动”。5.4 OpenClaw技能加载或执行错误问题现象Claw B的OpenClaw服务启动失败日志提示找不到system_healer技能或技能初始化错误。排查步骤路径检查确认技能目录是否被正确挂载到容器内且在OpenClaw的配置文件中路径拼写正确。依赖检查system_healer技能依赖paramiko,requests等库。需要在Claw B的OpenClaw项目依赖文件如requirements.txt中添加这些依赖并确保Docker镜像重建时安装了它们。初始化日志在技能的__init__方法中加入详细的日志输出查看初始化过程在哪一步出错。5.5 网络与防火墙问题问题现象健康检查的HTTP请求失败但SSH连接成功或反之。解决健康检查端点确保Claw A的OpenClaw服务确实配置了/health端点并且该端点可从Claw B的网络访问检查防火墙规则如云服务器的安全组。SSH端口确保Claw A的SSH端口默认22对Claw B开放。容器网络如果两者都运行在Docker中且不在同一网络需要配置正确的网络连接或使用宿主机IP。6. 进阶思考与优化方向实现了基础的自愈后这个系统还有很大的优化空间。以下是我规划或实验中的一些方向更智能的诊断目前是基于规则的匹配。可以引入一个轻量级的LLM比如通过OpenClaw自身的对话能力将诊断日志错误信息喂给LLM让它分析可能的原因并生成更精准的故障分类。这可以处理一些未预见的、但错误信息清晰的故障。修复动作的灰度执行对于重启容器这类操作可以先尝试“软重启”发送SIGTERM等待优雅退出不行再“硬重启”SIGKILL。对于配置更新可以先备份原文件再修改。多节点与选举可以部署多个Doctor Agent并通过简单的选举机制如基于Redis的分布式锁来避免单点监控的负担和单点故障。一个Agent负责监控其他的作为热备。修复效果评估与回滚修复执行后不仅检查服务是否“存活”还应进行更深入的健康检查例如发送一个测试请求验证核心功能。如果修复后一段时间内如10分钟故障再次发生可以自动回滚到之前的操作如重启前先打标签回滚时使用之前的镜像。与配置管理工具集成将修复剧本抽象成Ansible Playbook或Salt StateDoctor Agent只负责触发由更专业的配置管理工具来执行变更这样更规范也便于版本控制。回过头看“我的OpenClaw坏了另一只OpenClaw把它修好了”这个项目本质上是一次将运维知识监控、诊断、修复编码到AI智能体中的实践。它并不高深但非常实用。最大的收获不是代码本身而是在设计和实现过程中对“自动化边界”、“故障模式”和“系统韧性”的深入思考。开始你的AI Agent自愈之旅时不妨从一个小而具体的故障场景开始比如“容器挂了就重启”先让它跑起来再逐步迭代增加它的“医术”。这个过程本身就像在训练一个专属的、永不疲倦的运维助手。 AI智能体自愈系统实战：基于OpenClaw的自动化故障诊断与恢复
1. 项目概述当AI助手学会“自我修复”最近在折腾一个挺有意思的AI智能体项目叫OpenClaw。简单来说它就像一个能帮你处理各种日常任务的数字助手比如查资料、写代码、管理文件甚至控制智能家居。但这次遇到的状况有点特别我的一台运行OpenClaw的设备我们姑且叫它“Claw A”突然宕机了而修复它的是另一台同样运行着OpenClaw的设备“Claw B”。整个过程几乎没有我的手动干预。这听起来有点像科幻电影里的情节一个机器人修好了另一个机器人。但实际上这背后是一套关于AI智能体Agent协同、故障诊断与自动化恢复的实践。对于正在探索AI Agent开发、寻求系统高可用性方案的朋友来说这个“自愈”案例里踩过的坑和总结的经验或许能给你一些直接的参考。这个项目核心围绕“OpenClaw”展开它是一个开源的AI智能体框架。所谓“坏了”在软件层面可能表现为服务进程崩溃、依赖项缺失、配置文件错误或者资源如GPU内存耗尽。而“修好”则意味着另一套OpenClaw系统能够自动或半自动地诊断问题、执行修复命令如重启服务、重新安装依赖、修正配置最终使目标系统恢复服务。这不仅仅是简单的“重启大法”它涉及到智能体间的通信、对远程系统状态的感知、安全的问题诊断逻辑以及一系列精准的操作指令。接下来我就把这个从故障发生到自动恢复的全过程包括背后的设计思路、实操步骤以及我趟过的那些雷详细拆解一遍。2. 核心思路与架构设计2.1 为什么需要“自愈”—— 从单点脆弱到协同韧性最初部署OpenClaw时我只把它当作一个单体应用来对待。它在我的开发服务器上运行得好好的能响应我的各种查询。但问题出在一次系统级更新之后某个底层Python依赖包出现了版本冲突导致OpenClaw的核心服务直接无法启动。当时我正在外出无法立即登录服务器处理导致服务中断了好几个小时。这次经历让我意识到对于期望提供持续服务的AI助手来说单点部署是脆弱的。于是“自愈”系统的构想诞生了。其核心目标不是追求100%的无中断那需要更复杂的分布式架构而是在主节点发生常见软件故障时能有一个备份节点及时介入执行一些预设的、相对安全的修复操作尝试恢复服务为人工深度干预争取时间。这本质上是一种“高可用”的轻量级实践。我选择使用另一台独立的服务器Claw B作为“医生”AgentDoctor Agent它需要具备以下能力状态监控定期检查Claw A的健康状况如API是否可访问、关键进程是否存在。故障诊断当发现异常时能通过SSH等方式连接到Claw A运行诊断命令如查看日志、检查进程状态、验证配置文件初步判断故障原因。修复执行根据诊断结果从预定义的“修复剧本”中选择合适的命令序列执行例如重启Docker容器、重新拉取特定版本的镜像、修改某个配置参数。安全边界所有修复操作必须在一个严格的“安全沙箱”清单内禁止执行rm -rf /、任意文件下载等高风险命令。修复后需再次验证状态。2.2 技术栈选型与工具链搭建要实现上述思路需要组合多个工具。我的选型主要基于“熟悉度”和“轻量级”原则。OpenClaw (ClawPal) 作为智能体基础这是项目的核心。OpenClaw本身是一个框架它允许你定义具有特定技能Skill的Agent。我需要为Claw B上的OpenClaw开发一个特殊的“运维诊断”Skill。这个Skill将封装所有监控、诊断和修复的逻辑。我选择继续使用OpenClaw是为了保持技术栈的统一利用其已有的对话管理、工具调用能力。SSH与Paramiko库实现远程控制Claw B需要安全地连接到Claw A执行命令。我使用了Python的Paramiko库它提供了纯Python的SSHv2协议实现。相比于在系统中配置免密SSH并直接调用ssh命令Paramiko在程序内集成度更高更容易进行错误处理和日志记录。我为其配置了密钥认证并严格限制了Claw B在Claw A上的用户权限一个仅能执行特定sudo命令的专用用户。Docker作为部署与隔离工具我的OpenClaw是使用Docker容器部署的。这带来了巨大便利首先服务的状态运行/停止非常容易检查docker ps其次很多修复操作可以简化为Docker命令docker restart,docker logs,docker exec最后如果需要回滚或重装直接操作镜像和容器即可不会污染宿主机环境。这也是我推荐的生产环境部署方式。健康检查端点与监控策略我为Claw A上的OpenClaw服务添加了一个简单的HTTP健康检查端点例如/health返回服务状态和版本信息。Claw B上的Doctor Agent会定期如每5分钟调用这个端点。如果连续失败则触发诊断流程。同时Doctor Agent也会通过SSH检查Claw A的系统基础指标如CPU/内存使用率、磁盘空间以排除资源不足导致的问题。注意安全是重中之重。Doctor Agent的权限必须被严格限制。我创建了一个名为claw-maintainer的专用用户并配置sudo仅允许其执行systemctl restart docker,docker logs,docker restart等少数几个命令且需要密码密码由Doctor Agent安全存储。绝对禁止赋予其root或无需密码的sudo权限。3. 核心技能Skill开发详解Claw B上的“Doctor Agent”能力核心在于一个自定义的OpenClaw Skill。下面我详细拆解这个Skill的实现。3.1 技能结构与工作流设计这个Skill我命名为system_healer。在OpenClaw框架中一个Skill通常包含触发器Trigger、处理函数Function和工具Tool。我的设计工作流如下定时触发器每5分钟自动运行一次健康检查任务。健康检查函数尝试调用Claw A的/health端点。如果成功且返回状态正常则本次循环结束。故障诊断函数如果健康检查失败则启动诊断流程。通过Paramiko建立SSH连接。依次执行一系列诊断命令并将结果收集回来。决策与修复函数根据诊断结果匹配预定义的修复剧本。修复执行函数执行修复命令并验证修复结果。通知函数无论成功与否都将本次事件通过日志记录并可以集成飞书、钉钉等Webhook发送通知给我。3.2 关键代码模块解析以下是一些核心代码片段和解释。我使用Python作为开发语言。1. 健康检查模块import requests import time def check_health(target_url: str, timeout: int 10) - dict: 检查目标OpenClaw服务的健康状态。 try: response requests.get(f{target_url}/health, timeouttimeout) if response.status_code 200: data response.json() # 假设健康接口返回 {status: healthy, version: 2.7.9} if data.get(status) healthy: return {is_healthy: True, message: 服务运行正常, details: data} else: return {is_healthy: False, message: f服务状态异常: {data.get(status)}, details: data} else: return {is_healthy: False, message: fHTTP状态码异常: {response.status_code}, details: None} except requests.exceptions.ConnectionError: return {is_healthy: False, message: 无法连接到服务可能已宕机, details: None} except requests.exceptions.Timeout: return {is_healthy: False, message: 健康检查请求超时, details: None} except Exception as e: return {is_healthy: False, message: f健康检查过程发生未知错误: {str(e)}, details: None}这个函数是监控的起点。它必须足够健壮能处理网络超时、连接拒绝、JSON解析错误等各种边缘情况。2. SSH诊断模块使用Paramikoimport paramiko from io import StringIO class RemoteDiagnoser: def __init__(self, hostname, username, key_path): self.hostname hostname self.username username self.key paramiko.RSAKey.from_private_key_file(key_path) self.client None def connect(self): 建立SSH连接 self.client paramiko.SSHClient() self.client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) # 注意生产环境应使用更严格策略 self.client.connect(hostnameself.hostname, usernameself.username, pkeyself.key, timeout15) def run_command(self, command: str, use_sudo: bool False, sudo_password: str None) - dict: 在远程主机执行命令并返回结果 if not self.client: raise Exception(SSH未连接) full_cmd fsudo {command} if use_sudo else command stdin, stdout, stderr self.client.exec_command(full_cmd) if use_sudo and sudo_password: stdin.write(sudo_password \n) stdin.flush() exit_code stdout.channel.recv_exit_status() output stdout.read().decode(utf-8).strip() error stderr.read().decode(utf-8).strip() return { command: full_cmd, exit_code: exit_code, output: output, error: error } def diagnose(self) - list: 执行一系列诊断命令 diagnostics [] # 1. 检查Docker服务状态 result self.run_command(systemctl is-active docker, use_sudoTrue) diagnostics.append((Docker服务状态, result)) # 2. 检查OpenClaw容器状态 result self.run_command(docker ps --filter nameopenclaw --format table {{.Names}}\\t{{.Status}}) diagnostics.append((OpenClaw容器状态, result)) # 3. 查看最近100行容器日志寻找错误 result self.run_command(docker logs --tail 100 openclaw_app 21 | tail -50) # 假设容器名为openclaw_app diagnostics.append((容器最近日志, result)) # 4. 检查宿主机资源简化版 result self.run_command(free -h | grep Mem) diagnostics.append((内存使用, result)) result self.run_command(df -h / | tail -1) # 检查根分区磁盘 diagnostics.append((磁盘使用, result)) return diagnostics def close(self): if self.client: self.client.close()这个类封装了所有远程操作。diagnose方法里列出的命令就是根据我以往遇到的常见问题总结出来的“检查清单”。生产环境中你可能需要根据自身情况调整和增加。3. 修复决策与执行模块这是整个系统的“大脑”。我采用了一个简单的规则引擎rule-based来实现因为初期故障模式是可枚举的。我将诊断结果映射到修复动作。class RepairEngine: def __init__(self): self.repair_playbooks { docker_service_inactive: { description: Docker服务未运行, actions: [ {cmd: systemctl start docker, use_sudo: True, expect: 服务启动}, {cmd: systemctl is-active docker, use_sudo: True, expect_stdout_contains: active} ] }, openclaw_container_exited: { description: OpenClaw容器已退出, actions: [ {cmd: docker start openclaw_app, use_sudo: False, expect: 容器启动}, {cmd: docker ps --filter nameopenclaw_app --format {{.Status}}, use_sudo: False, expect_stdout_contains: Up} ] }, openclaw_container_restart_loop: { description: 容器不断重启可能配置错误, actions: [ {cmd: docker logs --tail 20 openclaw_app 21 | grep -i error, use_sudo: False, expect: 分析日志}, # 这里可以更复杂比如识别到特定错误后调用另一个函数来修正配置文件 # 例如{function: fix_config_file, args: {error_line: ...}} ] }, port_conflict: { description: 端口被占用如3000端口, actions: [ {cmd: lsof -i :3000 | grep LISTEN, use_sudo: True, expect: 查看占用进程}, {cmd: kill -9 PID, use_sudo: True, expect: 强制结束进程, note: 需要从上一个命令的输出中提取PID动态生成此命令} ] } } def analyze_and_repair(self, diagnostics: list, ssh_client: RemoteDiagnoser) - dict: 分析诊断结果并执行修复。 返回修复报告。 report {triggered_playbook: None, actions_executed: [], final_status: unknown} # 分析诊断结果匹配故障模式这里简化逻辑 docker_status next((d for d in diagnostics if d[0] Docker服务状态), None) container_status next((d for d in diagnostics if d[0] OpenClaw容器状态), None) if docker_status and docker_status[1][output] ! active: playbook self.repair_playbooks[docker_service_inactive] report[triggered_playbook] playbook[description] # 执行修复动作 for action in playbook[actions]: result ssh_client.run_command(action[cmd], use_sudoaction.get(use_sudo, False)) report[actions_executed].append({ command: action[cmd], result: result }) # 修复后再次进行健康检查 # ... 调用健康检查函数 ... report[final_status] repaired if health_ok else failed elif container_status and Exited in container_status[1][output]: playbook self.repair_playbooks[openclaw_container_exited] # ... 类似地执行修复 ... else: # 未匹配到已知剧本可能需要人工介入 report[triggered_playbook] unknown_issue report[final_status] requires_manual_intervention return report这个规则引擎虽然简单但解决了80%的常见问题。对于更复杂的故障如配置文件语法错误、模型加载失败我目前的策略是记录详细日志并通知我不进行自动修复因为风险太高。3.3 集成到OpenClaw Skill最后需要将上述模块封装成一个OpenClaw Skill并设置定时任务。# 在OpenClaw的技能定义文件中 from openclaw.skill import Skill, tool, trigger import schedule import threading import time class SystemHealerSkill(Skill): def __init__(self): super().__init__() self.diagnoser RemoteDiagnoser(hostnameclaw-a-ip, usernameclaw-maintainer, key_path/path/to/private_key) self.repair_engine RepairEngine() self.target_url http://claw-a-ip:3000 # Claw A的服务地址 # 启动后台监控线程 self.monitor_thread threading.Thread(targetself._monitor_loop, daemonTrue) self.monitor_thread.start() def _monitor_loop(self): 后台监控循环 schedule.every(5).minutes.do(self._health_check_and_heal) while True: schedule.run_pending() time.sleep(1) def _health_check_and_heal(self): 核心监控与修复逻辑 health check_health(self.target_url) if not health[is_healthy]: self.logger.warning(f检测到服务异常: {health[message]}) # 开始诊断 try: self.diagnoser.connect() diagnostics self.diagnoser.diagnose() # 分析与修复 repair_report self.repair_engine.analyze_and_repair(diagnostics, self.diagnoser) self.logger.info(f修复报告: {repair_report}) # 发送通知此处可集成飞书/钉钉Webhook self._send_notification(health[message], repair_report) except Exception as e: self.logger.error(f诊断或修复过程中发生错误: {e}) finally: self.diagnoser.close() else: self.logger.debug(服务健康检查通过。) tool(namemanual_health_check, description手动触发对Claw A的健康检查与修复) def manual_check(self): 提供一个手动调用的工具用于测试或立即触发 self._health_check_and_heal() return 手动健康检查与修复流程已触发。 def _send_notification(self, issue, report): 发送通知的示例函数 # 实现飞书、钉钉或邮件的通知逻辑 pass这样一个具备自愈能力的Doctor Agent技能就开发完成了。它会在后台默默监控并在发现问题时尝试修复。4. 部署与配置实战4.1 环境准备与依赖安装首先你需要在Claw B上部署一个标准的OpenClaw环境。我强烈推荐使用Docker方式这能避免复杂的Python环境冲突。# 在Claw B上 # 1. 安装Docker和Docker Compose (如果尚未安装) # 参考官方文档此处省略 # 2. 克隆OpenClaw项目或使用你自定义的包含healer skill的版本 git clone your-openclaw-fork-repo cd openclaw # 3. 将上面开发的system_healer技能代码放到项目的skills目录下 # 例如: mkdir -p skills/system_healer 将skill文件放入 # 4. 修改Dockerfile或docker-compose.yml确保技能被正确加载 # 通常需要在配置中指定技能路径例如在config.yaml中添加 # skills: # - system_healer4.2 关键配置详解1. SSH密钥配置在Claw B上生成专用的SSH密钥对并将公钥部署到Claw A的claw-maintainer用户下。# 在Claw B上生成密钥 ssh-keygen -t rsa -b 4096 -f /path/to/openclaw_healer_key -N # 无密码短语生产环境建议设置 # 将公钥复制到Claw A ssh-copy-id -i /path/to/openclaw_healer_key.pub claw-maintainerclaw-a-ip然后在Claw A上配置claw-maintainer用户的sudo权限编辑/etc/sudoers.d/claw-maintainer使用visudo -fclaw-maintainer ALL(ALL) NOPASSWD: /usr/bin/systemctl start docker, /usr/bin/systemctl restart docker, /usr/bin/systemctl status docker, /usr/bin/lsof这里只授予了启动/重启docker和查看端口占用的权限没有给stop或rm权限非常关键。2. OpenClaw配置文件在Claw B的OpenClaw配置中需要包含技能和必要的参数。# config.yaml (Claw B) name: Doctor_Agent model: openai:gpt-4 # 或你使用的其他模型Doctor Agent本身也需要LLM来处理更复杂的逻辑判断 skills: - system_healer # 我们开发的技能 # 技能特定配置可以在skill内部通过self.config读取 system_healer: target_host: 192.168.1.100 # Claw A的IP target_health_url: http://192.168.1.100:3000/health ssh_username: claw-maintainer ssh_private_key_path: /app/keys/openclaw_healer_key # Docker容器内的路径 # 通知Webhook lark_webhook: https://open.feishu.cn/...3. Docker Compose配置确保将私钥文件作为卷volume挂载到容器内。# docker-compose.doctor.yaml version: 3.8 services: openclaw-doctor: build: . container_name: openclaw_doctor volumes: - ./skills:/app/skills # 挂载技能目录 - ./config.yaml:/app/config.yaml # 挂载配置文件 - ./keys:/app/keys:ro # 挂载密钥目录只读 environment: - OPENCLAW_CONFIG_PATH/app/config.yaml restart: unless-stopped然后启动服务docker-compose -f docker-compose.doctor.yaml up -d4.3 测试与验证流程部署完成后绝不能直接投入生产。必须进行严格的测试。模拟健康检查手动停止Claw A的OpenClaw服务观察Claw B的日志看是否能检测到并触发诊断。# 在Claw A上 docker stop openclaw_app # 在Claw B上查看日志 docker logs -f openclaw_doctor你应该能看到类似“检测到服务异常”的日志然后进入诊断流程。测试诊断命令在Doctor Skill的日志中检查它执行的SSH命令是否成功返回的结果是否正确解析。测试修复动作这是最需要小心的。先测试最安全的操作比如“重启已停止的容器”。确保Claw A的容器是Exited状态。触发Doctor Agent观察它是否执行了docker start命令。验证Claw A的服务是否恢复。测试安全边界尝试制造一个Doctor Agent剧本中没有定义的故障比如故意损坏配置文件。观察Doctor Agent的行为它应该识别为“未知问题”并发送通知而不是尝试胡乱修复。压力与并发测试短时间内多次触发故障观察Doctor Agent的处理队列和逻辑是否会出现混乱。确保没有竞态条件例如一个修复还没完成另一个监控周期又开始了。5. 常见问题与故障排查实录在实际搭建和运行过程中我遇到了不少问题。这里记录下最典型的几个及其解决方案。5.1 SSH连接失败或权限不足问题现象Doctor Agent日志显示“Authentication failed”或“Permission denied”。排查步骤验证密钥在Claw B宿主机上手动用ssh -i /path/to/key claw-maintainerclaw-a-ip测试连接。如果失败说明密钥或授权有问题。检查权限确保Claw B上的私钥文件权限是600chmod 600 key。Docker容器内挂载的密钥文件同样需要正确权限可以在Dockerfile中COPY时设置或启动脚本中修改。检查用户与sudo确认Claw A上的claw-maintainer用户存在且~/.ssh/authorized_keys中有正确的公钥。使用sudo -l -U claw-maintainer命令验证sudo权限配置是否正确。容器内用户确保Docker容器内运行OpenClaw的用户通常是non-root有读取挂载的私钥文件的权限。5.2 诊断命令执行超时或无输出问题现象SSH命令执行卡住或者stdout/stderr获取不到内容。排查与解决设置超时Paramiko的exec_command本身没有很好的超时控制。我后来改用channel.exec_command配合channel.settimeout()和select模块来实现超时。或者在远程命令中加上timeout包装例如run_command(timeout 30s docker logs ...)。缓冲区问题对于可能输出很长的命令如docker logs要确保读取完整。我使用了stdout.channel.recv_exit_status()等待命令结束然后再读取输出避免死锁。交互式命令像sudo如果需要密码必须像前面代码那样通过stdin写入。确保你的sudoers配置正确如果配置了NOPASSWD则无需交互。5.3 误修复与“修复风暴”问题现象Doctor Agent错误地判断了故障执行了不当的修复操作甚至可能让问题恶化。或者在修复期间监控周期又到了导致重复触发修复形成循环。经验与策略保守的修复剧本只对原因明确、后果可控的问题进行自动修复。例如“容器停止”可以重启“端口占用”可以kill进程需谨慎。但对于“应用内部逻辑错误”、“数据库连接失败”应止步于诊断和告警。状态锁与冷却期在开始修复时设置一个“修复中”的状态锁。在锁定期内跳过后续的健康检查。修复完成后进入一个“冷却期”例如5分钟在此期间即使健康检查再次失败也不立即触发修复防止系统在启动过程中被反复打扰。人工确认机制升级版对于某些中级风险操作可以让Doctor Agent通过通知渠道如飞书向我发送一个包含修复方案的卡片我点击“确认”后它再执行。这实现了“半自动”。5.4 OpenClaw技能加载或执行错误问题现象Claw B的OpenClaw服务启动失败日志提示找不到system_healer技能或技能初始化错误。排查步骤路径检查确认技能目录是否被正确挂载到容器内且在OpenClaw的配置文件中路径拼写正确。依赖检查system_healer技能依赖paramiko,requests等库。需要在Claw B的OpenClaw项目依赖文件如requirements.txt中添加这些依赖并确保Docker镜像重建时安装了它们。初始化日志在技能的__init__方法中加入详细的日志输出查看初始化过程在哪一步出错。5.5 网络与防火墙问题问题现象健康检查的HTTP请求失败但SSH连接成功或反之。解决健康检查端点确保Claw A的OpenClaw服务确实配置了/health端点并且该端点可从Claw B的网络访问检查防火墙规则如云服务器的安全组。SSH端口确保Claw A的SSH端口默认22对Claw B开放。容器网络如果两者都运行在Docker中且不在同一网络需要配置正确的网络连接或使用宿主机IP。6. 进阶思考与优化方向实现了基础的自愈后这个系统还有很大的优化空间。以下是我规划或实验中的一些方向更智能的诊断目前是基于规则的匹配。可以引入一个轻量级的LLM比如通过OpenClaw自身的对话能力将诊断日志错误信息喂给LLM让它分析可能的原因并生成更精准的故障分类。这可以处理一些未预见的、但错误信息清晰的故障。修复动作的灰度执行对于重启容器这类操作可以先尝试“软重启”发送SIGTERM等待优雅退出不行再“硬重启”SIGKILL。对于配置更新可以先备份原文件再修改。多节点与选举可以部署多个Doctor Agent并通过简单的选举机制如基于Redis的分布式锁来避免单点监控的负担和单点故障。一个Agent负责监控其他的作为热备。修复效果评估与回滚修复执行后不仅检查服务是否“存活”还应进行更深入的健康检查例如发送一个测试请求验证核心功能。如果修复后一段时间内如10分钟故障再次发生可以自动回滚到之前的操作如重启前先打标签回滚时使用之前的镜像。与配置管理工具集成将修复剧本抽象成Ansible Playbook或Salt StateDoctor Agent只负责触发由更专业的配置管理工具来执行变更这样更规范也便于版本控制。回过头看“我的OpenClaw坏了另一只OpenClaw把它修好了”这个项目本质上是一次将运维知识监控、诊断、修复编码到AI智能体中的实践。它并不高深但非常实用。最大的收获不是代码本身而是在设计和实现过程中对“自动化边界”、“故障模式”和“系统韧性”的深入思考。开始你的AI Agent自愈之旅时不妨从一个小而具体的故障场景开始比如“容器挂了就重启”先让它跑起来再逐步迭代增加它的“医术”。这个过程本身就像在训练一个专属的、永不疲倦的运维助手。