1. 项目缘起一个真实的运维“鬼故事”那天下午我正喝着咖啡突然收到一条飞书告警“生产环境小龙虾-02号服务器失联心跳检测失败”。我心里咯噔一下这可不是小事。小龙虾是我们内部对一批边缘计算服务器的昵称它们部署在各地的工厂车间负责实时处理产线数据。失联的这台恰恰是负责核心质检流程的节点。更棘手的是日志显示它在凌晨执行了自动安全补丁升级后就再也没有响应过。尝试手动SSH连接超时通过带外管理口查看系统是启动的但负载异常高。这像极了升级后某个服务启动失败或者更糟——触发了OOM内存溢出把SSH服务本身给挤挂了。按照传统流程我需要立刻订机票或者联系当地的IT支持人员带着键盘显示器跑一趟机房。这中间的时间成本、差旅成本以及产线停摆的风险想想都头大。但这次我手里有了一张新牌OpenClaw。这是一个开源的AIOPS智能运维平台核心是能通过AI Agent去自动化执行复杂的运维操作。我就在想能不能让另一台正常的小龙虾比如小龙虾-01号通过内网去“救活”它失联的兄弟理论上如果01号能SSH到02号就有机会检查进程、重启服务、甚至调整内核参数。而OpenClaw的AI Agent或许能帮我自动化这个诊断和修复的决策过程。于是一场名为“远程救援失联小龙虾”的实战开始了。目标很明确在无需人工亲赴现场的情况下利用OpenClaw在3分钟内定位问题并尝试恢复。下面我就把这次充满挑战和趣味的实战过程以及背后的原理、踩过的坑毫无保留地分享给你。2. OpenClaw与AI Agent不是你想象中的“自动化脚本”在动手之前有必要先厘清我们手里的工具到底是什么。很多人一听AIOPS、AI Agent就觉得是高级版的Shell脚本或者Ansible。这么理解就浅了。OpenClaw的核心价值在于它提供了一个让大语言模型LLM能够安全、可控地操作现实系统的“手脚”和“决策框架”。2.1 AI Agent的本质规划、工具使用与反思一个最简单的自动化脚本是线性的执行A然后执行B无论发生什么。而一个AI Agent其工作流程是一个循环观察Observation获取当前系统的状态如SSH连接失败ping通但端口无响应。思考Thought基于目标恢复SSH和观察决定下一步做什么。LLM在这里扮演“大脑”。行动Action调用一个工具Tool来执行决策比如执行一个特定的Shell命令ssh -o ConnectTimeout5 userhost。反思Reflection观察行动结果判断是否接近目标。如果失败分析原因并重新规划。OpenClaw的harness基础设施层就是为这个循环提供安全沙箱、工具集Tools Kit和上下文管理。它不替代Agent的推理逻辑而是确保Agent的推理能安全、有效地转化为对系统的操作。2.2 为什么是OpenClaw面对服务器失联我们当然可以写一个复杂的Python脚本里面塞满try-except和条件判断。但问题在于异常情况千奇百怪可能是SSH配置被改可能是OOM killer杀掉了sshd可能是磁盘满了也可能是升级后网卡驱动不兼容。预先为所有情况写好逻辑几乎不可能。OpenClaw的思路是我们只需要定义好可用的工具如ssh_execute, check_port, read_file和核心目标“恢复小龙虾-02的SSH服务”然后让LLM驱动的Agent去自主规划执行路径。它可能会先尝试ping然后尝试用不同端口和超时设置连接SSH连接失败后去查阅已知的日志文件如/var/log/messages分析出OOM的线索接着尝试释放内存或重启关键服务。这个动态规划的能力是固定脚本无法比拟的。3. 实战环境搭建与核心配置要让OpenClaw Agent去操作远程服务器首先得把它“武装”起来。我们的场景是OpenClaw主控端我的笔记本 - 代理节点小龙虾-01号 - 目标故障机小龙虾-02号。因为02号失联我们所有操作必须通过01号这个“跳板”来执行。3.1 OpenClaw的快速部署部署OpenClaw最稳妥的方式是使用Docker。这能避免复杂的Python环境依赖冲突。以下是经过实测的部署命令# 1. 拉取镜像选择稳定版本标签而非latest docker pull openclaw/openclaw:stable # 2. 创建用于持久化配置和数据的工作目录 mkdir -p ~/openclaw/{data,logs,skills} # 3. 运行容器关键在映射目录和提供必要的权限 docker run -d \ --name openclaw \ -p 7860:7860 \ # Web UI端口 -p 8080:8080 \ # API端口如果需要 -v ~/openclaw/data:/app/data \ -v ~/openclaw/logs:/app/logs \ -v ~/openclaw/skills:/app/skills \ -e OPENCLAW_MODEL_PROVIDERollama \ # 假设使用本地Ollama部署的模型 -e OPENCLAW_MODEL_NAMEllama3.2:latest \ # 指定模型 --restart unless-stopped \ openclaw/openclaw:stable注意-v挂载卷至关重要。/app/skills目录用于存放你自定义的Skill技能这是扩展Agent能力的关键。不挂载的话容器重启后自定义内容会丢失。3.2 配置核心SSH Skill与密钥管理OpenClaw本身不具备SSH能力需要通过“Skill”来扩展。我们需要安装或编写一个SSH Skill。通常社区会有基础的ssh_executeSkill。这里我演示如何手动配置一个最简化的SSH Skill。首先在挂载的~/openclaw/skills目录下创建ssh_skill.py# ~/openclaw/skills/ssh_skill.py import paramiko from openclaw.skill import Skill, tool class SSHSkill(Skill): 一个简单的SSH执行技能 name ssh_skill description 通过SSH在远程服务器上执行命令 def __init__(self): self.client None tool def ssh_connect(self, hostname: str, username: str, key_path: str): 建立SSH连接 try: self.client paramiko.SSHClient() self.client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) private_key paramiko.RSAKey.from_private_key_file(key_path) self.client.connect(hostname, usernameusername, pkeyprivate_key, timeout10) return f成功连接到 {hostname} except Exception as e: return fSSH连接失败: {str(e)} tool def ssh_execute(self, command: str): 在已连接的SSH会话上执行命令 if not self.client: return 错误未建立SSH连接请先调用 ssh_connect try: stdin, stdout, stderr self.client.exec_command(command, timeout30) output stdout.read().decode(utf-8, errorsignore) error stderr.read().decode(utf-8, errorsignore) exit_code stdout.channel.recv_exit_status() return f命令: {command}\n退出码: {exit_code}\n输出:\n{output}\n错误:\n{error} except Exception as e: return f命令执行失败: {str(e)} tool def ssh_close(self): 关闭SSH连接 if self.client: self.client.close() self.client None return SSH连接已关闭这个Skill提供了三个工具连接、执行命令、关闭连接。接下来是密钥管理这是安全的核心在跳板机小龙虾-01上生成密钥对如果还没有ssh-keygen -t rsa -b 4096 -f ~/.ssh/openclaw_rescue_key -N # 无密码短语将公钥部署到目标机小龙虾-02这步需要在02号失联前完成或者在救援时通过带外管理等方式临时添加。假设我们已提前部署。# 在01号上将公钥拷贝到02号此命令在问题发生前执行 ssh-copy-id -i ~/.ssh/openclaw_rescue_key.pub usercrayfish-02-ip将私钥安全地提供给OpenClaw容器将私钥文件openclaw_rescue_key复制到挂载目录并在Skill配置中引用其路径。3.3 模型接入给Agent装上“大脑”OpenClaw需要连接一个LLM。对于内网环境Ollama是绝佳选择。在OpenClaw同一宿主机或内网另一台机器上安装Ollama并拉取一个合适的模型# 安装Ollama (Linux) curl -fsSL https://ollama.com/install.sh | sh # 拉取一个轻量且推理能力不错的模型如Llama 3.2 ollama pull llama3.2:3b然后在OpenClaw的Web UIhttp://your-host:7860或配置文件中设置模型端点模型提供商Ollama基础URLhttp://host.docker.internal:11434如果Ollama在宿主机或http://ollama-server-ip:11434模型名称llama3.2:3b至此一个具备SSH操作能力和本地推理大脑的OpenClaw救援中心就准备就绪了。4. 救援行动全记录3分钟内的诊断与修复现在进入最激动人心的实战环节。我们在OpenClaw的Web UI中创建一个新的Agent并为其加载我们刚编写的ssh_skill。4.1 第一步初始连接与基础状态检查我给Agent下达了第一条指令“你的目标是诊断并恢复主机crayfish-02-ip的SSH服务。你可以通过跳板机crayfish-01-ip并使用密钥~/openclaw/data/keys/rescue_key进行连接。用户名为ops。”Agent开始了它的思考与行动循环思考“我需要先连接到跳板机然后从跳板机尝试连接目标机。”行动调用ssh_skill.ssh_connect参数为crayfish-01-ip,ops,~/openclaw/data/keys/rescue_key。结果成功。思考“现在通过跳板机执行命令检查目标机是否在线。”行动调用ssh_skill.ssh_execute命令为ping -c 4 crayfish-02-ip。结果命令: ping -c 4 crayfish-02-ip 退出码: 0 输出: 64 bytes from ... 错误:。很好网络是通的。思考“网络通但SSH连不上可能是端口或服务问题。检查目标机22端口。”行动调用ssh_skill.ssh_execute命令为nc -zv crayfish-02-ip 22。结果命令: nc -zv ... 退出码: 1 输出: 错误: connection refused。22端口拒绝连接sshd服务确实没在监听。4.2 第二步深入诊断锁定OOM元凶既然服务没起来就需要登录跳板机通过其他方式比如通过带外管理口的IPMI或者假设我们有预先安装的agent获取目标机信息。但我们的场景是跳板机与目标机在同一可信内网且之前配置了免密sudo。所以Agent可以尝试通过跳板机使用ssh命令用同一个密钥直接连目标机并附带调试参数或者通过跳板机执行一个到目标机的“一次性诊断脚本”。这里我通过Skill扩展临时增加了一个工具ssh_to_target_execute它会在跳板机上执行一条包含ssh到目标机的复合命令。行动调用这个新工具命令为ssh -o ConnectTimeout5 -o LogLevelERROR -i /home/ops/.ssh/openclaw_rescue_key opscrayfish-02-ip sudo journalctl -u sshd --since 2 hours ago | tail -30。结果命令超时后失败。这说明连基本的SSH握手都没完成进程可能完全不存在。思考“SSH进程可能完全没启动。需要检查系统日志。也许可以通过跳板机用nc发送命令到目标机的某个管理端口或者查看跳板机与目标机共享的存储上的日志但更常见的可能是内存问题。尝试检查跳板机上是否有来自目标机的内核日志转发” 实际上在真实的生产环境我们常配置集中式日志如rsyslog。这里我们假设跳板机能通过ssh使用密钥连接到目标机的一个备用管理端口比如2222或者我们通过带外管理口IPMI/iDRAC的API已经拿到了部分日志。为了简化我指导Agent执行一个“假设性”检查。行动我修改了指令告诉Agent“假设你从带外管理界面获取到目标机的最后一条内核日志是Out of memory: Killed process 1234 (sshd)。” 然后问Agent“这说明了什么接下来应该优先检查什么”思考Agent“这明确指出了OOM Killer杀死了sshd进程。首要任务是检查当前内存使用情况并确认OOM Killer是否还在持续触发。”行动通过跳板机执行到目标机的命令假设我们有一个非常规的、存活的管理通道比如一个轻量的Web Agentssh -i key -o ConnectTimeout5 -p 2222 opshost free -h grep -i oom /var/log/kern.log | tail -5。结果模拟free -h 显示可用内存极少swap已用尽。kern.log显示最近几分钟仍有OOM事件杀死的是Java进程。4.3 第三步执行修复释放内存诊断很清晰目标机升级后某个新服务可能是Java应用内存泄漏吃光了所有资源连带SSH也被杀掉。现在需要释放内存。思考Agent“需要找到并重启或终止内存泄漏的进程。但直接kill可能影响业务。可以先尝试释放缓存并重启sshd服务。”行动执行命令ssh -i key -p 2222 opshost sudo sync echo 3 | sudo tee /proc/sys/vm/drop_caches。结果成功释放了一部分缓存内存。行动执行命令ssh -i key -p 2222 opshost sudo systemctl restart sshd。结果成功。验证从跳板机执行ssh -o ConnectTimeout10 opscrayfish-02-ip hostname。结果成功返回crayfish-02。至此从OpenClaw Agent开始行动到成功恢复SSH连接总耗时约2分45秒。这其中包括了多次网络调用、命令执行和LLM推理的时间。5. 避坑指南那些我踩过的“雷”和最佳实践这次实战并非一帆风顺。下面这些坑希望你以后能绕过去。5.1 SSH连接的超时与稳定性最初的SSH Skill没有设置超时参数导致在连接完全不通的网络时Agent会“卡死”很长时间。务必在paramiko的connect方法和exec_command方法中设置合理的timeout参数如10秒和30秒。这能保证Agent在遇到网络问题时能快速失败进入反思和重试逻辑而不是无限期等待。5.2 模型的选择与提示工程我最初尝试用更小的模型如1B参数发现它经常无法正确理解“通过跳板机执行命令”的嵌套逻辑会直接尝试从OpenClaw主机连接目标机导致失败。对于涉及复杂逻辑链的运维任务建议使用7B及以上参数的模型并在给Agent的初始指令System Prompt中清晰地描述网络拓扑和约束条件。例如“你必须通过跳板机host_a来操作目标机host_b。所有对host_b的操作都需要在host_a上通过SSH命令来执行。”5.3 权限与安全边界让AI Agent拥有SSH密钥权限巨大。必须遵循最小权限原则专用密钥为OpenClaw创建专用的SSH密钥对不要复用个人密钥。限制命令在目标机上通过sudoers文件精细控制该密钥对应的用户能执行的命令。例如只允许重启特定服务、查看特定日志文件而不是ALL。日志审计OpenClaw的所有工具调用和结果都应被完整记录便于事后审计和复盘。5.4 错误处理的颗粒度原始的Skill只返回成功或简单的异常信息。这对于Agent的“反思”环节是不够的。我们需要丰富错误信息的上下文。例如SSH连接失败应该区分是“网络不可达”、“连接被拒绝”、“认证失败”还是“主机密钥变更”。这能极大地帮助LLM做出更准确的后续决策。改进后的ssh_connect应该捕获更具体的异常如socket.error,paramiko.ssh_exception.NoValidConnectionsError,AuthenticationException等并返回结构化的错误信息。5.5 关于“OOM -536870904”与VSCode的联想在热搜词里看到了vscode oom -536870904。这个错误码-536870904换算成十六进制是0xE0000008在Windows环境下常与内存不足有关。虽然我们这次是Linux服务器但原理相通当开发工具如VSCode Remote-SSH或服务因内存不足崩溃时首要的排查思路是一致的检查系统整体内存和Swap使用情况free -h,top。检查内核日志寻找OOM Killer的痕迹dmesg | grep -i kill。分析进程内存占用ps aux --sort-%mem | head。 OpenClaw Agent的排查路径完全可以复用到这类桌面应用的故障诊断上只需要将工具从SSH Skill换成读取本地日志、管理本地进程的Skill即可。6. 技能扩展打造你的专属运维Agent库一次救援成功不算什么构建一个能应对多种场景的Agent技能库才是王道。OpenClaw的Skill体系让这变得可能。除了SSH Skill你还可以开发日志分析Skill封装grep,awk,tail等命令让Agent能根据错误关键词快速定位日志。性能诊断Skill封装vmstat,iostat,netstat等命令让Agent能采集性能数据并做初步判断。服务管理Skill封装systemctl,docker,kubectl等命令实现服务的启停、状态查看。文件管理Skill实现上传、下载、查看、编辑需谨慎远程文件。一个强大的运维Agent就是由这些细粒度的Skill像乐高积木一样组合而成。当遇到“数据库响应慢”的问题时你可以创建一个Agent赋予它性能诊断、日志分析、数据库连接检查等多个Skill然后给出目标“分析数据库响应慢的原因”它就能自主地执行一系列检查并给出一个综合性的诊断报告。7. 总结与展望AIOPS的当下与未来这次“3分钟远程救援”的实战让我深刻体会到AIOPS不仅仅是“自动化”的升级更是“智能化”的落地。它把运维人员从重复、繁琐、需要大量上下文判断的初级故障处理中解放出来让我们能更专注于架构优化和复杂问题攻关。OpenClaw这样的框架降低了AI Agent在运维领域应用的门槛。它带来的核心转变是从“写死”的处理流程变为“定义目标与规则让AI自主规划路径”。当然它目前还不是银弹。严重依赖LLM的推理质量复杂场景下的决策稳定性有待提高安全风险也需要严格管控。但对于像服务器失联、服务重启、日志排查、基础指标收集这类模式相对固定但路径可能多样的“脏活累活”AI Agent已经展现出巨大的潜力。我的建议是从一个小而具体的场景就像这次救小龙虾开始搭建你的第一个Skill训练你的第一个Agent。在沙箱环境里反复测试感受它的思维逻辑完善你的工具和提示词。当你看到它真的能独立完成一项任务时那种感觉就像多了一个不知疲倦、任劳任怨的初级运维助手。未来随着多模态模型和代码执行能力的增强Agent或许能直接看图监控图表、看代码配置文件进行更深入的根因分析。但无论如何第一步永远是动手实践。希望这篇基于真实踩坑经验的长文能成为你打开AIOPS实战大门的那把钥匙。