用 OpenClaw 搭建 AIOps 智能巡检系统:从人肉值班到 Agent 自动化的落地实战

凌晨三点，你还在盯告警吗？

每个运维团队都有这样的夜晚：Prometheus 告警群炸了，order-service 报 5xx，你一边翻 Grafana 看指标，一边 grep 日志找堆栈，一边在 SkyWalking 里追链路。折腾一小时，发现是上游 payment-service 的一次发版引入了慢查询。

这种"指标 → 日志 → 链路"的人肉三件套，每次故障都要重复一遍。更痛苦的是日常巡检——每天早上手动检查几十个服务的健康状态、Pod 是否重启、CPU/内存是否飙升、业务指标是否异常。纯体力活，但不干又不行。

AIOps 不是银弹，但把重复性巡检交给 AI Agent 是完全可落地的第一步。

本文介绍我们团队如何基于 OpenClaw（一个开源 AI Agent ）构建智能巡检系统，实现每日自动巡检、异常自动分析、报告自动生成。不讲概念，只讲怎么干。

一、整体架构：三层能力模型

AI 巡检不是装个工具就完事的。Trace、Log、Metric 三大可观测性支柱散落在不同系统里，要让 AI 看懂问题，需要在三个层次上建能力：

┌──────────────────────────────────────────────────────┐│                    决策层                              ││  Agent 编排 · 根因推理 · 自动修复 · 专家库反馈          │├──────────────────────────────────────────────────────┤│                    分析层                              ││  向量检索 · 知识图谱 · RAG · 历史案例匹配              │├──────────────────────────────────────────────────────┤│                    数据层                              ││  OpenTelemetry 统一采集 · Exemplars 关联                ││  Prometheus · SkyWalking · ES/Loki                    │└──────────────────────────────────────────────────────┘

数据层：把三个孤岛的语言统一

现状是三个系统各说各话：

落地动作：

1. OpenTelemetry 统一 SDK：一个 SDK 搞定 Trace/Log/Metric 三种信号，TraceID 自动注入日志字段
2. Prometheus Exemplars：在指标数据中关联 TraceID，实现从 Metric 直接跳转到 Trace，不用猜时间窗口和服务名

# Prometheus exemplar 配置示例# 在应用的 metrics handler 中添加 exemplarhttp_request_duration_seconds_bucket{le="0.5"}1000# {trace_id="abc123"}

数据层的核心目标：让 AI Agent 用一个 TraceID 就能串起指标异常、错误日志和调用链路。

分析层：让 AI 理解数据关系

数据统一了，但 AI 还需要理解 "CPU 飙升" 和 "数据库慢查询" 之间的因果关系。这需要两个能力：

• 知识图谱：把服务依赖、Trace、Log、Metric 组织成可查询的关系网。例如："order-service → 依赖 → payment-service → 使用 → MySQL"
• RAG（检索增强生成）：当 AI 分析一个异常时，先检索历史相似案例，再结合上下文生成诊断结论

阶段一不需要知识图谱和 RAG。 先把基础巡检跑通，积累数据和案例后再建设分析层。不要一步到位。

决策层：从告警到修复

分析出根因后，AI 给出决策甚至自动执行修复。这是最终形态，但需要逐步开放权限——先只读巡检，再只读分析，最后才是写操作（扩容、重启、回滚）。

二、为什么选 OpenClaw

OpenClaw 是 2025 年底开源的 AI Agent 平台（GitHub 300K+ Stars），支持本地部署、多模型接入（Claude/GPT/DeepSeek）、Skill 扩展、定时任务、多 Agent 编排。它对 AIOps 巡检场景特别合适的几个原因：

三、前置能力建设

在写巡检逻辑之前，先把三件事做好。

3.1 上下文获取能力

AI 巡检的前提是 Agent 能拿到数据。需要为每种数据源开发对应的 Skill：

3.2 Skill 开发

以 k8s-inspector Skill 为例，文件结构：

~/.openclaw/skills/k8s-inspector/└── SKILL.md

---name: k8s-inspectordescription: 查询 Kubernetes 集群中 Pod 状态、资源使用率和异常事件metadata:  openclaw:    requires:      bins: ["kubectl"]---# K8s Inspector你是一个 Kubernetes 集群检查工具。## 能力1. **Pod 状态检查**：执行 `kubectl get pods -n <namespace> -o json`，分析 Pod 的 status.phase 和 containerStatuses2. **资源使用率**：执行 `kubectl top pods -n <namespace> --no-headers`，获取 CPU 和内存实际使用量3. **异常事件**：执行 `kubectl get events -n <namespace> --sort-by='.lastTimestamp' --field-selector type!=Normal`，获取最近的异常事件## 输出要求对每个命名空间输出：- 异常 Pod 列表（非 Running/Completed 状态）- 资源使用率 Top5 的 Pod- 最近 1 小时的异常事件## 注意事项- 只执行只读命令，不做任何修改操作- 如果某个命名空间无权访问，跳过并记录

Prometheus 查询 Skill 示例：

---name: prometheus-querydescription: 通过 PromQL 查询 Prometheus 指标数据，支持即时查询和范围查询metadata:  openclaw:    requires:      bins: ["curl"]    env: ["PROMETHEUS_URL"]---# Prometheus Query你是一个 Prometheus 指标查询工具。## 能力1. **即时查询**：```bash   curl -s "${PROMETHEUS_URL}/api/v1/query?query=<promql>"

1. 范围查询（最近 1 小时）：

   curl -s "${PROMETHEUS_URL}/api/v1/query_range?query=<promql>&start=$(date -d '1 hour ago' +%s)&end=$(date +%s)&step=60"

常用查询模板

• CPU 使用率：rate(container_cpu_usage_seconds_total{namespace="<ns>"}[5m])
• 内存使用率：container_memory_working_set_bytes{namespace="<ns>"} / container_spec_memory_limit_bytes * 100
• 错误率：rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) * 100
• Pod 重启次数：increase(kube_pod_container_status_restarts_total{namespace="<ns>"}[24h])

输出要求

• 将查询结果转为可读格式（表格或列表）
• 标注异常值（CPU > 80%、内存 > 85%、错误率 > 1%、24h重启 > 0）

### 3.3 Skill 验证与管理每个 Skill 开发完后，独立验证其原子能力：```bash# 验证 k8s-inspectoropenclaw skills list        # 确认 Skill 已加载# 在 OpenClaw 会话中测试> 使用 k8s-inspector 检查 production 命名空间的 Pod 状态# 验证 prometheus-query  > 使用 prometheus-query 查询 production 命名空间最近 1 小时的 CPU 使用率 Top5

建立 Skill 维护责任制：每个 Skill 指定一个维护人，负责更新查询模板、修复兼容性问题。Skill 就是团队的 SOP 沉淀——每次成功的巡检经验都应该回流到 Skill 中。

四、任务编排：Spec + Template 驱动巡检

Skill 是原子能力，巡检需要把多个 Skill 按顺序编排起来。OpenClaw 通过 Spec 文件和 Template 文件实现这一点。

4.1 Spec 文件：定义巡检任务流

创建 daily-inspection-spec.md，定义巡检的执行顺序和验收标准：

# 每日巡检 Spec你是一个智能巡检 Agent。按照以下顺序执行每日巡检任务，每个步骤必须完成后再进行下一步。## 巡检范围命名空间列表：production, staging服务列表：order-service, payment-service, user-service, gateway## 执行步骤### Step 1: K8s 基础巡检使用 k8s-inspector 对每个命名空间执行：- Pod 状态检查（是否有 CrashLoopBackOff、Pending、Evicted）- 资源使用率排查（CPU > 80% 或 内存 > 85% 标记为异常）- 异常事件汇总**验收标准**：输出每个命名空间的健康摘要### Step 2: 指标巡检使用 prometheus-query 对每个服务执行：- 基础指标：CPU、内存、网络 IO- 业务指标：QPS、错误率、P99延迟- 对比昨日同期数据，标注波动超过 30% 的指标**验收标准**：输出指标对比表，异常项标红### Step 3: 日志巡检使用 log-searcher 对最近 24 小时的日志执行：- 按 ERROR/WARN 级别聚合统计- 对 ERROR 日志进行去重和分类- 识别新增的错误模式（昨天没有、今天出现的）**验收标准**：输出错误分类列表和新增错误告警### Step 4: 链路巡检（可选）如果 Step 2 或 Step 3 发现异常，使用 skywalking-trace：- 查询异常服务最近 1 小时的慢链路（> 3s）- 分析链路瓶颈节点**验收标准**：输出慢链路 Top5 和瓶颈分析### Step 5: 生成巡检报告综合以上所有步骤的结果，按照 @daily-inspection-template.md 的格式生成巡检报告。- 整体健康评分（绿/黄/红）- 关键发现摘要- 建议行动项

4.2 Template 文件：统一报告格式

创建 daily-inspection-template.md，确保每次巡检报告结构一致：

# 每日巡检报告模板请严格按照以下格式输出巡检报告：---## 📊 巡检报告 - {{date}}### 整体健康度: {{绿色✅ / 黄色⚠️ / 红色🔴}}### 一、摘要- 巡检范围：{{命名空间数量}} 个命名空间，{{服务数量}} 个核心服务- 发现问题：{{问题总数}} 个（严重 {{critical_count}}，警告 {{warning_count}}）- 需要关注：{{需要人工介入的事项}}### 二、K8s 状态| 命名空间 | Pod 总数 | 正常 | 异常 | 异常详情 ||----------|---------|------|------|---------|| {{ns}}   | {{total}} | {{healthy}} | {{unhealthy}} | {{detail}} |### 三、指标概览| 服务 | CPU | 内存 | QPS | 错误率 | P99延迟 | 状态 ||------|-----|------|-----|--------|---------|------|| {{service}} | {{cpu}}% | {{mem}}% | {{qps}} | {{err_rate}}% | {{p99}}ms | {{status}} |> ⚠️ 较昨日波动超过 30% 的指标已标注### 四、日志分析**错误统计：**| 错误类型 | 出现次数 | 影响服务 | 是否新增 ||---------|---------|---------|---------|| {{type}} | {{count}} | {{service}} | {{is_new}} |**新增错误（需重点关注）：**{{new_errors_detail}}### 五、链路分析（如有异常触发）| 链路 | 总耗时 | 瓶颈节点 | 瓶颈原因 ||------|--------|---------|---------|| {{trace}} | {{duration}} | {{bottleneck}} | {{reason}} |### 六、行动建议| 优先级 | 问题 | 建议操作 | 负责人 ||--------|------|---------|--------|| P0 | {{issue}} | {{action}} | 待指定 |---

4.3 Cron 定时执行

配置 OpenClaw 每天早上 8:00 自动执行巡检：

# 添加定时巡检任务openclaw cron add \  --name "daily-inspection" \  --schedule "0 8 * * *" \  --prompt "请按照 @daily-inspection-spec.md 执行每日巡检，使用 @daily-inspection-template.md 格式输出报告" \  --delivery announce \  --channel "ops-inspection"

# 查看已配置的定时任务openclaw cron list# 手动触发一次（调试用）openclaw cron run daily-inspection

配置持久化在 ~/.openclaw/cron/jobs.json，Gateway 重启后自动恢复。巡检报告通过 --delivery announce 推送到指定的消息频道（飞书/Slack/钉钉/企微）。

五、分阶段落地计划

阶段一：基础巡检能力（4-6 周）

目标：跑通"定时巡检 → 自动报告"的完整链路

阶段一关键原则：

• 只读不写：Agent 只查询数据，不执行任何修改操作
• 先跑通再优化：报告格式、Skill 查询模板可以迭代
• 每次成功经验回流：手动排障成功后，把诊断路径沉淀为 Skill

阶段一成果： 替代每日 30-60 分钟的人肉巡检，异常发现时间从"等人看"缩短到"8点推送"。

阶段二：关联分析与根因定位（8-12 周）

目标：从"发现异常"升级到"分析根因"

根因定位工作流：

告警/巡检发现异常      │      ▼主 Agent: 获取异常上下文  ├── 查指标（prometheus-query）  ├── 查日志（log-searcher）  ├── 查链路（skywalking-trace）  └── 查变更记录（deploy-history skill）      │      ▼主 Agent: 生成 3-5 个根因假设      │      ▼派发子 Agent 并行验证  ├── Agent-A: 验证假设 1（查数据库慢查询）  ├── Agent-B: 验证假设 2（查上游服务状态）  └── Agent-C: 验证假设 3（查最近发版变更）      │      ▼主 Agent: 综合打分，输出根因报告      │      ▼人工确认 → 记录到专家库（反馈闭环）

六、日志巡检深入：降噪是关键

日志巡检是最容易"做了等于没做"的环节——如果直接把 10 万条 ERROR 日志丢给 AI，Token 炸了，结果也没用。

6.1 日志预处理流水线

原始日志（10万条/天）      │      ▼  Level 过滤：只保留 ERROR + WARN      │ (降到 ~5000 条)      ▼  去重 & 聚合：相同堆栈合并，保留首次/末次时间和出现次数      │ (降到 ~200 类)      ▼  分类：已知错误（有对应 SOP）vs 未知错误（需要分析）      │      ├── 已知错误 → 直接关联 SOP，标记在报告中      └── 未知错误 → 投递到"待定位队列"，触发根因分析

6.2 Log Searcher Skill 设计要点

---name: log-searcherdescription: 日志查询、过滤、聚合和异常分析---## 查询策略1. **范围查询**：最近 24 小时，按命名空间/服务名过滤2. **聚合降噪**：   - 按错误消息的前 100 字符 hash 分组   - 相同 hash 只保留一条样本 + 出现次数3. **新增检测**：   - 对比前 7 天的错误 hash 集合   - 本次出现但历史未出现的 = 新增错误（重点关注）## 输出格式每条错误输出：- 错误分类（hash）- 出现次数- 首次/末次出现时间- 影响服务- 样本日志（最多 5 行）- 是否为新增错误

七、指标巡检深入：业务指标是重点

基础指标（CPU/内存）只能发现资源问题，业务指标才能发现业务问题。

7.1 指标分层

7.2 业务指标的额外信息

Prometheus 返回的指标只有数值，但业务指标通常需要额外的上下文。在 Prometheus Query Skill 中处理：

## 业务指标增强查询业务指标时，在返回结果中补充以下信息：1. **同比数据**：查询昨日同一时段的值，计算波动百分比2. **环比数据**：查询上一个小时的值，判断趋势3. **阈值标注**：根据预定义阈值标注状态   - 下单成功率 < 99% → 红色- 支付转化率下降 > 5% → 黄色   - P99 延迟 > 1000ms → 红色4. **关联提示**：如果某个业务指标异常，提示检查关联的基础指标   - 下单成功率下降 → 提示检查 order-service 的 CPU 和数据库连接数

八、Agent 监控：看住你的 AI

AI Agent 本身也需要被监控。否则你不知道它是在正常巡检，还是在"胡说八道"。

8.1 关键监控指标

8.2 反馈闭环

巡检报告 → 人工 Review      │      ├── 发现漏报 → 补充 Skill 查询条件 / 调整阈值      ├── 发现误报 → 优化 Skill 过滤逻辑 / 更新已知错误库      └── 发现新模式 → 沉淀为新 Skill 或更新现有 Skill

核心原则：系统定位的问题越多，准确率越高。 每次人工介入都是训练数据，通过持续迭代 Skill 和 Template，巡检质量会不断提升。

九、踩坑与建议

不要一步到位

最常见的失败模式是：第一天就想建知识图谱 + RAG + 自动修复。结果三个月什么都没上线。

正确路径：先跑通最简单的巡检（阶段一），积累数据和信心，再逐步加能力。

Skill 比 Prompt 重要

很多团队花大量时间优化 Prompt，但巡检质量的决定因素是 Skill 的数据获取能力。如果 Skill 查不到正确的数据，再好的 Prompt 也没用。优先投入在 Skill 开发和验证上。

Token 成本可控

一次完整巡检（5 个服务，4 个 Skill）的 Token 消耗大约在 20K-40K tokens。按 Claude Sonnet 的价格，每天不到 1 块钱。但要注意：

• 日志类 Skill 必须先做聚合降噪，不要把原始日志全丢给 AI
• Spec 文件中明确"验收标准"，避免 Agent 无限制地深入分析
• 设置 Token 上限，超出自动终止

Template 决定报告质量

没有 Template 的巡检报告，每次格式都不一样，没人愿意看。**Template 是给 AI 的"表格"**——你画好格子，AI 填内容。格式一致了，团队才会养成看报告的习惯。

Skill 需要持续维护

Prometheus 查询模板过时了、K8s 版本升级导致 API 变了、新服务上线但没加到巡检范围——这些都需要有人持续维护 Skill。给每个 Skill 指定一个 Owner。

十、总结：一张落地路线图

现在  │  ▼  Week 1-2  搭建 OpenClaw + 开发基础 Skill（K8s、Prometheus）  │  ▼  Week 3-4  开发日志 Skill + 编写 Spec/Template + 端到端联调  │  ▼  Week 5-6  配置 Cron 定时执行 + 消息推送 + 试运行  │  ▼  ✅ 阶段一完成：每日自动巡检上线  │  ▼  Week 7-12  OTel 接入 + 链路关联 + 历史案例库  │  ▼  Week 13-18  根因分析 Agent + 多 Agent 编排 + 专家库反馈  │  ▼  ✅ 阶段二完成：智能根因定位上线  │  ▼  未来  自动修复（扩容/重启/回滚）← 需要严格的权限管控

AIOps 不是一个工具的事，是一个体系的事。但只要迈出第一步——让 AI Agent 替你做每天的巡检——你就会发现，后面的路越走越快。

因为每一次巡检，都在帮你积累数据、沉淀 Skill、训练系统。这才是 AI 运维的飞轮效应。