【實戰篇】用 OpenClaw 搭建你的"數字打工人"

作者:H先生出品
日期:2026年5月8日 上午1:35
來源:WeChat 原文

整理版優先睇

速讀 5 個重點 高亮

OpenClaw 搭建自動運維助手「數字打工人」,從監控到自動修復一條龍

整理版摘要

呢篇文章係 H先生 OpenClaw 系列嘅實戰篇,承接前面六篇嘅原理、技能、記憶、定時任務同子 Agent 概念,將佢哋串聯成一個真正用得嘅自動運維系統「數字打工人」。作者目標係搭建一個可以主動彙報、監控告警、自動修復、生成日報嘅助手,等用戶只需要睇推送,唔使手動處理。整體結論係:用 OpenClaw 嘅 cron 工具加子 Agent,配合簡單 Shell 腳本,已經可以實現基礎嘅自動化運維,而且可以逐步擴展到更複雜場景。

文章詳細記錄咗從需求分析到落地嘅完整過程:先寫監控腳本檢查服務器存活,再用定時任務每小時執行,然後加入自動修復子 Agent,最後加上晨報同日報。每個步驟都有具體嘅 JSON 配置同 Shell 腳本,仲有踩坑指南同最佳實踐,例如告警分級、靜默時段、失敗重試等。對於想用 OpenClaw 實現自動化工作流程嘅人,呢篇係好實用嘅參考。

  • OpenClaw 可以整合 Shell 腳本、定時任務同子 Agent,搭建一個自動運維系統,實現「只睇推送,佢負責做嘢」。
  • 核心方法係用 curl 寫健康檢查腳本,配合 cron 每小時定時執行,並利用子 Agent 自動嘗試修復。
  • 相比傳統人手運維,呢個方案大幅減少手動操作,將常見問題(如服務器掛咗)自動化處理。
  • 啟發係可以將重複性操作封裝成 Skill 或子 Agent,並通過記憶文件記錄常見問題,令系統越來越聰明。
  • 可行動點:跟住文中步驟,由創建檢查腳本開始,逐步加入修復、日報,再擴展到更多監控維度。
值得記低
工具

服務器存活檢查腳本 (check-server.sh)

用 curl 檢查 HTTP 狀態碼,判斷服務器是否正常。返回 200 就正常,否則異常。附超時 10 秒設定。

工具

自動修復腳本 (fix-server.sh)

通過 SSH 遠程重啓指定服務(例如 nginx),需要預先配置免密登錄同 sudo 免密。

流程

服務器監控+自動修復定時任務

OpenClaw cron job JSON 配置:每小時執行檢查腳本,發現異常時先告警、再執行修復腳本、然後二次檢查、最後彙報結果。正常時靜默。

整理重點

實戰目標:一個完整嘅「數字打工人」

呢篇文章嘅目標係將 OpenClaw 嘅 定時任務、子 Agent 同 Skill 串聯,搭建一個自動運維助手。佢要具備主動彙報、監控告警、自動修復、日報生成同智能分析嘅能力。最終效果係你只負責睇推送,佢負責做嘢。

  • 主動彙報:早上 9 點推送服務器狀態,用定時任務加天氣 Skill。
  • 監控告警:每小時檢查服務器存活,掛咗就告警,用定時任務加 Shell 腳本。
  • 自動修復:檢測到問題後自動嘗試重啓,用子 Agent 加 SSH
  • 日報生成:下班前生成運維日報,用定時任務加文檔 Skill。
  • 智能分析:遇到複雜問題時自動查資料分析,用子 Agent 加聯網搜索。
整理重點

搭建監控基礎同定時任務

第一步係寫監控腳本。作者用 curl -s -o /dev/null -w "%{http_code}" 嚟檢查服務器 /health 端點,超時設為 10 秒。腳本輸出「✅ 服務器正常」或「🚨 服務器異常」,然後用 exit code 區分狀態。記住要加執行權限先。

check-server.sh bash
#!/bin/bash
SERVER="https://your-server.com"
TIMEOUT=10
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" --max-time $TIMEOUT $SERVER/health)
if [ "$RESPONSE" = "200" ]; then
 echo "✅ 服務器正常 (HTTP $RESPONSE)"
 exit 0
else
 echo "🚨 服務器異常 (HTTP $RESPONSE 或無法連接)"
 exit 1
fi

然後建立定時任務,用 OpenClaw 內置 cron 工具。關鍵設定包括 everyMs: 3600000(每小時)、sessionTarget: "isolated"</highlight-inline>(獨立會話,唔污染主對話),同埋 message 入面嘅條件判斷,要求「正常時唔輸出」,避免嘈雜。

定時任務 JSON (服務器存活監控) json
{
 "action": "add",
 "job": {
 "name": "服務器存活監控",
 "agentId": "main",
 "schedule": {"kind":"every","everyMs":3600000},
 "sessionTarget": "isolated",
 "payload": {
 "kind": "agentTurn",
 "message": "執行 ~/scripts/check-server.sh。如果輸出包含「異常」,立即告警:服務器可能掛了,請檢查。如果輸出包含「正常」,不輸出任何內容。要求:(1) 不要回復 HEARTBEAT_OK (2) 不要調用 message 工具 (3) 只在異常時輸出 (4) 告警內容控制在 1 句話"
 },
 "delivery": {"mode":"announce"}
 }
}
整理重點

自動修復同智能分析

監控只係發現問題,作者進一步加入自動修復。佢寫咗 fix-server.sh,用 SSH 遠程重啓服務(例如 nginx),前提係要配置好 SSH 免密同 sudo 免密。然後修改定時任務嘅 message,當檢查異常時:先告警,再執行修復腳本,然後再次檢查,最後彙報結果。整個流程由 子 Agent 自動完成。

  • 檢查 → 異常 → 告警 → 執行 fix-server.sh → 再次檢查 → 彙報最終結果。
  • 正常時保持靜默,唔會產生任何輸出。

智能分析方面,作者示範點樣用手動或自動觸發子 Agent 嚟排查問題,例如服務器 CPU 持續 100% 時,可以叫 OpenClaw 搜索「Linux CPU 100% 排查方法」,生成排查清單。呢個可以整合到告警流程,當條件符合時自動啟動。

自動修復嘅關鍵係將修復腳本同定時任務結合,等系統可以自我癒合

整理重點

晨報日報同最佳實踐

作者進一步加入 每日晨報(朝早 9 點)同 每日運維日報(下晝 6 點)。晨報包含服務器狀態、天氣同待辦;日報統計告警次數、自動修復成功次數同需要跟進嘅事項。兩個都用 cron 表達式 設定時間,並要求直接輸出內容,唔調用 message 工具。

  1. 1 P0 緊急:服務器 down → 立即通知 + 自動修復。
  2. 2 P1 嚴重:部分功能異常 → 通知 + 記錄日誌。
  3. 3 P2 一般:性能下降 → 只記錄,下班彙報。

最佳實踐仲包括 靜默時段、失敗重試 設定,同埋將常用操作封裝成 Skill(例如 server-health Skill 包含 check.sh、fix.sh、report.sh),仲可以用 MCP 擴展連接 PrometheusGrafana 等工具。

整理重點

踩坑指南同進階方向

實戰一定會遇到問題,作者列出咗幾個常見踩坑位:SSH 免密登錄 未配置會令修復腳本失敗;cron 時區 要留意,最好用 ISO 時間加時區後綴;腳本執行權限 要用 chmod +x;日誌文件</highlight-inline> 唔存在時 grep 會報錯,要先 touch 創建。

  • SSH 免密:用 ssh-keygen + ssh-copy-id 配置。
  • 時區:檢查 date +%z,用正確 ISO 時間。
  • 權限:chmod +x ~/scripts/*.sh。
  • 日誌:touch ~/logs/server.log ~/logs/alerts.log。

進階方面,作者建議加入 記憶能力(在 MEMORY.md 記錄常見問題同解決方案)、自定義 Skill(將檢查、修復、報告封裝成獨立模塊),同埋通過 MCP 協議</highlight-inline> 連接更多工具(例如數據庫監控、雲服務 API)。最後仲可以搭建 Grafana 可視化面板。

前面六篇文章,我哋學識咗 OpenClaw 嘅原理、技能、記憶、定時任務、子 Agent。而家係時候將呢啲能力串埋一齊,砌一個真正做到嘢嘅「數位打工人」。呢篇文章唔講概念,只講實戰——由需求到落地嘅完整過程。


一、實戰目標:一個完整嘅「數位打工人」

我哋要砌一個自動運維助手,佢有以下能力:

能力
具體功能
用到嘅技術
主動匯報
每日朝早 9 點推送伺服器狀態
定時任務 + 天氣 Skill
監控告警
每個鐘檢查伺服器係咪生還,死咗就出警
定時任務 + Shell 腳本
自動修復
偵測到問題之後自動嘗試重啟
子 Agent + SSH
日報生成
每日收工前生成運維日報
定時任務 + 文檔 Skill
智能分析
遇到複雜問題時自動查資料分析
子 Agent + 聯網搜索

最終效果:你淨係負責睇推送,佢負責做嘢。


二、第一步:起監控基礎

2.1 建立監控腳本

需求:檢查伺服器係咪生還

方案:用 Shell 腳本 + curl

#!/bin/bash
# 保存為 ~/scripts/check-server.sh

SERVER="https://your-server.com"
TIMEOUT=10

# 健康檢查
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" --max-time $TIMEOUT $SERVER/health)

if [ "$RESPONSE" = "200" ]; then
  echo "✅ 服務器正常 (HTTP $RESPONSE)"
  exit 0
else
  echo "🚨 服務器異常 (HTTP $RESPONSE 或無法連接)"
  exit 1
fi

說明

  • curl -s 靜默模式,唔輸出進度
  • -o /dev/null 掉咗響應體,淨係留狀態碼
  • -w "%{http_code}" 淨係輸出 HTTP 狀態碼
  • --max-time $TIMEOUT 超時 10 秒

2.2 測試腳本

# 添加執行權限
chmod +x ~/scripts/check-server.sh

# 測試
~/scripts/check-server.sh
# 輸出:✅ 服務器正常 (HTTP 200) 或 🚨 服務器異常

三、第二步:建立定時監控任務

3.1 需求分析

  • 頻率:每個鐘檢查一次
  • 通知:有事先通知,正常嘅時候靜音
  • 渠道:微信

3.2 建立定時任務

用內置 cron 工具:

{
  "action": "add",
  "job": {
    "name": "服務器存活監控",
    "agentId": "main",
    "schedule": {"kind":"every","everyMs":3600000},
    "sessionTarget": "isolated",
    "payload": {
      "kind": "agentTurn",
      "message": "執行 ~/scripts/check-server.sh。如果輸出包含「異常」,立即告警:服務器可能掛了,請檢查。如果輸出包含「正常」,不輸出任何內容。要求:(1) 不要回復 HEARTBEAT_OK (2) 不要調用 message 工具 (3) 只在異常時輸出 (4) 告警內容控制在 1 句話"
    },
    "delivery": {"mode":"announce"}
  }
}

關鍵設計

  • everyMs: 3600000 = 每個鐘(1個鐘 = 3600秒 = 3600000毫秒)
  • sessionTarget: "isolated" = 獨立會話,唔會污染主對話
  • message 入面嘅條件判斷 = 「正常嘅時候唔輸出」

3.3 驗證任務建立

openclaw cron list

輸出例子:

job_xxx  服務器存活監控  every 1h  enabled  next: 10:00

四、第三步:加自動修復能力

4.1 需求分析

監控只係發現問題,真正有用嘅係自動修復

場景:伺服器程序死咗,自動重啟

4.2 建立修復腳本

#!/bin/bash
# 保存為 ~/scripts/fix-server.sh

SERVER="user@your-server.com"
SERVICE="nginx"

echo "嘗試重啓 $SERVER 上的 $SERVICE..."

# SSH 遠程執行(需要提前配置免密登錄)
ssh $SERVER "sudo systemctl restart $SERVICE && echo '重啓成功' || echo '重啓失敗'"

前提條件

  • 本地已經 set 好 SSH 免密登入
  • 伺服器上面 sudo 免密碼(或者喺 sudoers 度 set)

4.3 建立自動修復子 Agent

方案:當監控發現異常,就開動子 Agent 執行修復

喺定時任務度改 message:

{
  "action": "add",
  "job": {
    "name": "服務器存活監控+自動修復",
    "agentId": "main",
    "schedule": {"kind":"every","everyMs":3600000},
    "sessionTarget": "isolated",
    "payload": {
      "kind": "agentTurn",
      "message": "執行 ~/scripts/check-server.sh。如果輸出包含「異常」:(1) 先告警:服務器異常,正在嘗試自動修復 (2) 執行 ~/scripts/fix-server.sh (3) 再次檢查 (4) 彙報最終結果。如果輸出包含「正常」,不輸出任何內容。要求:(1) 不要回復 HEARTBEAT_OK (2) 不要調用 message 工具 (3) 每步操作簡短彙報"
    },
    "delivery": {"mode":"announce"}
  }
}

工作流程

檢查 → 異常 → 告警 → 修復 → 再檢查 → 彙報

五、第四步:每日朝早報告

5.1 需求分析

每日朝早 9 點,自動推送:

  • 尋日伺服器運行情況
  • 今日天氣
  • 今日待辦

5.2 建立朝早報告任務

{
  "action": "add",
  "job": {
    "name": "每日晨報",
    "agentId": "main",
    "schedule": {"kind":"cron","expr":"0 9 * * *"},
    "sessionTarget": "isolated",
    "payload": {
      "kind": "agentTurn",
      "message": "生成今日晨報,包含:(1) 昨日服務器監控結果(查 ~/logs/server.log 最後 20 行)(2) 今日天氣(查北京天氣)(3) 今日待辦(查 ~/notes/todo.md)。格式:簡潔清晰,每項 2-3 句話。要求:(1) 不要回復 HEARTBEAT_OK (2) 不要調用 message 工具 (3) 直接輸出晨報內容"
    },
    "delivery": {"mode":"announce"}
  }
}

cron 表達式說明

  • 0 9 * * * = 每日 9:00
  • 格式:分 時 日 月 星期

5.3 效果例子

📊 今日晨報 (2026-05-08)

🖥️ 服務器狀態:昨日運行正常,無異常記錄

🌤️ 天氣:北京晴,15-25℃,適合户外活動

📝 待辦:
- 完成項目文檔整理
- 下午 3 點代碼評審
- 晚上健身房

六、第五步:每日日報

6.1 需求分析

每日下晝 6 點,自動生成運維日報:

  • 今日告警次數
  • 處理結果統計
  • 需要人工跟進嘅事項

6.2 建立日報任務

{
  "action": "add",
  "job": {
    "name": "每日運維日報",
    "agentId": "main",
    "schedule": {"kind":"cron","expr":"0 18 * * 1-5"},
    "sessionTarget": "isolated",
    "payload": {
      "kind": "agentTurn",
      "message": "生成今日運維日報,包含:(1) 今日告警次數(grep 統計 ~/logs/alerts.log)(2) 自動修復成功次數 (3) 需要人工跟進的事項。格式:表格 + 簡要說明。要求:(1) 不要回復 HEARTBEAT_OK (2) 不要調用 message 工具 (3) 直接輸出日報內容"
    },
    "delivery": {"mode":"announce"}
  }
}

cron 表達式說明

  • 0 18 * * 1-5 = 星期一至五 18:00
  • 1-5 = 星期一至五

七、第六步:智能分析能力

7.1 需求分析

遇到複雜問題嘅時候,自動查資料分析。

場景:伺服器 CPU 持續 100%,要分析原因

7.2 建立分析子 Agent

方案:人手觸發,但可以整合到告警流程度

你:分析服務器 CPU 高的原因
OpenClaw:啓動分析子 Agent...

實際操作:

{
  "task": "服務器 CPU 持續 100%,請:(1) 搜索「Linux CPU 100% 排查方法」(2) 列出常見原因和排查步驟 (3) 生成排查清單。要求:簡潔清晰,控制在 300 字以內",
  "runtime": "subagent",
  "mode": "run",
  "timeoutSeconds": 300
}

自動觸發版本(喺告警 message 度加):

{
  "message": "如果 CPU 持續 100% 超過 10 分鐘:(1) 告警 (2) 啓動子 Agent 分析原因 (3) 推送分析結果"
}

八、完整架構圖

圖片

九、設定檔清單

9.1 腳本檔案

文件
用途
位置
check-server.sh
伺服器生還檢查
~/scripts/check-server.sh
fix-server.sh
自動修復腳本
~/scripts/fix-server.sh

9.2 日誌檔案

文件
用途
位置
server.log
伺服器運行日誌
~/logs/server.log
alerts.log
告警記錄
~/logs/alerts.log

9.3 數據檔案

文件
用途
位置
todo.md
待辦事項
~/notes/todo.md

十、進階:令「數位打工人」更聰明

10.1 加入記憶能力

喺 OpenClaw 嘅記憶檔案度記錄:

  • 常見問題同解決方案
  • 伺服器歷史數據
  • 個人偏好

示例:在 MEMORY.md 度加:

## 服務器運維記錄

### 常見問題
- CPU 100%:通常是 Node.js 死循環,重啓 pm2
- 內存泄漏:檢查日誌中的 "out of memory",重啓服務
- 磁盤滿:清理 /var/log 和 /tmp

### 個人偏好
- 告警時間:工作日 9:00-18:00
- 告警頻率:同類型問題 1 小時內不重複告警

10.2 加入自訂 Skill

將常用操作封裝成 Skill:

示例:創建 server-health Skill

skills/server-health/
├── SKILL.md          # 技能說明
├── scripts/
│   ├── check.sh      # 檢查腳本
│   ├── fix.sh        # 修復腳本
│   └── report.sh     # 報告腳本
└── references/
    └── common-issues.md  # 常見問題庫

10.3 加入 MCP 擴展

通過 MCP 協議連接更多工具:

  • 數據庫監控
  • 雲服務 API
  • 監控平台(Prometheus、Grafana)

十一、踩坑指南

11.1 SSH 免密登入設定

問題:執行遠端腳本嘅時候彈出要入密碼

解決:set 好 SSH 免密登入

# 生成密鑰對
ssh-keygen -t rsa -b 4096

# 複製公鑰到服務器
ssh-copy-id user@your-server.com

# 測試
ssh user@your-server.com "echo 'SSH OK'"

11.2 cron 時區問題

問題:任務比預期早/遲 8 個鐘

解決:檢查時區

# 查看系統時區
date +%z
# 輸出:+0800

# 使用正確的 ISO 時間
# 錯誤:2026-05-08T09:00:00
# 正確:2026-05-08T09:00:00+08:00

11.3 腳本執行權限

問題:彈出「Permission denied」

解決:加執行權限

chmod +x ~/scripts/*.sh

11.4 日誌檔案唔存在

問題:grep 報錯「No such file」

解決:先建立檔案

touch ~/logs/server.log
touch ~/logs/alerts.log

十二、最佳做法

12.1 告警分級

級別
條件
處理方式
P0 緊急
服務完全用唔到
即刻告警 + 自動修復
P1 嚴重
部分功能異常
告警 + 記錄日誌
P2 一般
效能下降
記錄日誌 + 收工匯報

12.2 靜音時段

避免深夜告警騷擾:

{
  "message": "如果是 23:00-08:00,只記錄日誌不告警。其他時間正常告警。"
}

12.3 失敗重試

set 任務失敗嘅重試策略:

{
  "job": {
    ...
    "failureAlert": {
      "mode": "announce",
      "after": 2
    }
  }
}

含義:失敗 2 次先告警,避免誤報。


十三、效果驗證

13.1 模擬伺服器故障

# 臨時停止服務
sudo systemctl stop nginx

# 等待下一次檢查(最多 1 小時)
# 或手動觸發:openclaw cron run <jobId>

預期效果

  1. 收到告警:伺服器異常,正在嘗試自動修復
  2. 收到修復結果:重啟成功/失敗
  3. 收到最終狀態:伺服器已恢復/需要人工介入

13.2 檢查日誌

# 查看監控日誌
tail -f ~/logs/server.log

# 查看告警日誌
tail -f ~/logs/alerts.log

十四、總結

組件
作用
技術實現
監控腳本
偵測伺服器狀態
Shell + curl
定時任務
定期執行監控
cron 工具
自動修復
問題自動處理
子 Agent + SSH
朝早報告/日報
資訊彙總推送
定時任務 + Skill
智能分析
複雜問題診斷
子 Agent + 聯網搜索

由零到一嘅完整路徑

需求分析 → 腳本編寫 → 定時任務配置 → 子 Agent 集成 → 測試驗證 → 持續優化

下一步方向

  • 加更多監控維度(記憶體、磁碟、網絡)
  • 接入雲服務 API(阿里雲、騰訊雲)
  • 起可視化監控面板(Grafana)

系列文章完結

到呢度,OpenClaw 系列文章全部完成:

文章
核心內容
入門篇
安裝設定 + 基本使用 + 安全風險
技能篇
Skill 概念 + 使用 + 自訂
記憶篇
三層架構 + MEMORY.md + 維護技巧
原理篇
Gateway + Agent + Channel + 數據流
進階篇
定時任務 + 子 Agent + 自動化
實戰篇
完整案例:數位打工人

由認識 OpenClaw,到用佢解決實際問題,希望呢個系列對你有幫助。

撳個讚同關注唔怕迷路,之後仲會分享更多 AI 效率工具。

👨‍💻 H先生出品 | 專注 AI 工具與效率提升

前面六篇文章,我們學會了 OpenClaw 的原理、技能、記憶、定時任務、子 Agent。現在,是時候把這些能力串聯起來,搭建一個真正能幹活的"數字打工人"了。這篇文章不講概念,只講實戰——從需求到落地的完整過程。


一、實戰目標:一個完整的"數字打工人"

我們要搭建一個自動運維助手,它具備以下能力:

能力
具體功能
用到的技術
主動彙報
每天早上 9 點推送服務器狀態
定時任務 + 天氣 Skill
監控告警
每小時檢查服務器存活,掛了告警
定時任務 + Shell 腳本
自動修復
檢測到問題後自動嘗試重啓
子 Agent + SSH
日報生成
每天下班前生成運維日報
定時任務 + 文檔 Skill
智能分析
遇到複雜問題時自動查資料分析
子 Agent + 聯網搜索

最終效果:你只負責看推送,它負責幹活。


二、第一步:搭建監控基礎

2.1 創建監控腳本

需求:檢查服務器是否存活

方案:用 Shell 腳本 + curl

#!/bin/bash
# 保存為 ~/scripts/check-server.sh

SERVER="https://your-server.com"
TIMEOUT=10

# 健康檢查
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" --max-time $TIMEOUT $SERVER/health)

if [ "$RESPONSE" = "200" ]; then
  echo "✅ 服務器正常 (HTTP $RESPONSE)"
  exit 0
else
  echo "🚨 服務器異常 (HTTP $RESPONSE 或無法連接)"
  exit 1
fi

說明

  • curl -s 靜默模式,不輸出進度
  • -o /dev/null 丟棄響應體,只保留狀態碼
  • -w "%{http_code}" 只輸出 HTTP 狀態碼
  • --max-time $TIMEOUT 超時 10 秒

2.2 測試腳本

# 添加執行權限
chmod +x ~/scripts/check-server.sh

# 測試
~/scripts/check-server.sh
# 輸出:✅ 服務器正常 (HTTP 200) 或 🚨 服務器異常

三、第二步:創建定時監控任務

3.1 需求分析

  • 頻率:每小時檢查一次
  • 通知:有問題才通知,正常時靜默
  • 渠道:微信

3.2 創建定時任務

使用內置 cron 工具:

{
  "action": "add",
  "job": {
    "name": "服務器存活監控",
    "agentId": "main",
    "schedule": {"kind":"every","everyMs":3600000},
    "sessionTarget": "isolated",
    "payload": {
      "kind": "agentTurn",
      "message": "執行 ~/scripts/check-server.sh。如果輸出包含「異常」,立即告警:服務器可能掛了,請檢查。如果輸出包含「正常」,不輸出任何內容。要求:(1) 不要回復 HEARTBEAT_OK (2) 不要調用 message 工具 (3) 只在異常時輸出 (4) 告警內容控制在 1 句話"
    },
    "delivery": {"mode":"announce"}
  }
}

關鍵設計

  • everyMs: 3600000 = 每小時(1小時 = 3600秒 = 3600000毫秒)
  • sessionTarget: "isolated" = 獨立會話,不污染主對話
  • message 中的條件判斷 = "正常時不輸出"

3.3 驗證任務創建

openclaw cron list

輸出示例:

job_xxx  服務器存活監控  every 1h  enabled  next: 10:00

四、第三步:添加自動修復能力

4.1 需求分析

監控只是發現問題,真正有用的是自動修復

場景:服務器進程掛了,自動重啓

4.2 創建修復腳本

#!/bin/bash
# 保存為 ~/scripts/fix-server.sh

SERVER="user@your-server.com"
SERVICE="nginx"

echo "嘗試重啓 $SERVER 上的 $SERVICE..."

# SSH 遠程執行(需要提前配置免密登錄)
ssh $SERVER "sudo systemctl restart $SERVICE && echo '重啓成功' || echo '重啓失敗'"

前提條件

  • 本地已配置 SSH 免密登錄
  • 服務器上 sudo 免密碼(或在 sudoers 中配置)

4.3 創建自動修復子 Agent

方案:當監控發現異常時,啓動子 Agent 執行修復

在定時任務中修改 message:

{
  "action": "add",
  "job": {
    "name": "服務器存活監控+自動修復",
    "agentId": "main",
    "schedule": {"kind":"every","everyMs":3600000},
    "sessionTarget": "isolated",
    "payload": {
      "kind": "agentTurn",
      "message": "執行 ~/scripts/check-server.sh。如果輸出包含「異常」:(1) 先告警:服務器異常,正在嘗試自動修復 (2) 執行 ~/scripts/fix-server.sh (3) 再次檢查 (4) 彙報最終結果。如果輸出包含「正常」,不輸出任何內容。要求:(1) 不要回復 HEARTBEAT_OK (2) 不要調用 message 工具 (3) 每步操作簡短彙報"
    },
    "delivery": {"mode":"announce"}
  }
}

工作流程

檢查 → 異常 → 告警 → 修復 → 再檢查 → 彙報

五、第四步:每日晨報

5.1 需求分析

每天早上 9 點,自動推送:

  • 昨日服務器運行情況
  • 今日天氣
  • 今日待辦

5.2 創建晨報任務

{
  "action": "add",
  "job": {
    "name": "每日晨報",
    "agentId": "main",
    "schedule": {"kind":"cron","expr":"0 9 * * *"},
    "sessionTarget": "isolated",
    "payload": {
      "kind": "agentTurn",
      "message": "生成今日晨報,包含:(1) 昨日服務器監控結果(查 ~/logs/server.log 最後 20 行)(2) 今日天氣(查北京天氣)(3) 今日待辦(查 ~/notes/todo.md)。格式:簡潔清晰,每項 2-3 句話。要求:(1) 不要回復 HEARTBEAT_OK (2) 不要調用 message 工具 (3) 直接輸出晨報內容"
    },
    "delivery": {"mode":"announce"}
  }
}

cron 表達式說明

  • 0 9 * * * = 每天 9:00
  • 格式:分 時 日 月 星期

5.3 效果示例

📊 今日晨報 (2026-05-08)

🖥️ 服務器狀態:昨日運行正常,無異常記錄

🌤️ 天氣:北京晴,15-25℃,適合户外活動

📝 待辦:
- 完成項目文檔整理
- 下午 3 點代碼評審
- 晚上健身房

六、第五步:每日日報

6.1 需求分析

每天下午 6 點,自動生成運維日報:

  • 今日告警次數
  • 處理結果統計
  • 需要人工跟進的事項

6.2 創建日報任務

{
  "action": "add",
  "job": {
    "name": "每日運維日報",
    "agentId": "main",
    "schedule": {"kind":"cron","expr":"0 18 * * 1-5"},
    "sessionTarget": "isolated",
    "payload": {
      "kind": "agentTurn",
      "message": "生成今日運維日報,包含:(1) 今日告警次數(grep 統計 ~/logs/alerts.log)(2) 自動修復成功次數 (3) 需要人工跟進的事項。格式:表格 + 簡要說明。要求:(1) 不要回復 HEARTBEAT_OK (2) 不要調用 message 工具 (3) 直接輸出日報內容"
    },
    "delivery": {"mode":"announce"}
  }
}

cron 表達式說明

  • 0 18 * * 1-5 = 週一到週五 18:00
  • 1-5 = 週一到週五

七、第六步:智能分析能力

7.1 需求分析

遇到複雜問題時,自動查資料分析。

場景:服務器 CPU 持續 100%,需要分析原因

7.2 創建分析子 Agent

方案:手動觸發,但可以集成到告警流程中

你:分析服務器 CPU 高的原因
OpenClaw:啓動分析子 Agent...

實際操作:

{
  "task": "服務器 CPU 持續 100%,請:(1) 搜索「Linux CPU 100% 排查方法」(2) 列出常見原因和排查步驟 (3) 生成排查清單。要求:簡潔清晰,控制在 300 字以內",
  "runtime": "subagent",
  "mode": "run",
  "timeoutSeconds": 300
}

自動觸發版本(在告警 message 中加入):

{
  "message": "如果 CPU 持續 100% 超過 10 分鐘:(1) 告警 (2) 啓動子 Agent 分析原因 (3) 推送分析結果"
}

八、完整架構圖

圖片

九、配置文件清單

9.1 腳本文件

文件
用途
位置
check-server.sh
服務器存活檢查
~/scripts/check-server.sh
fix-server.sh
自動修復腳本
~/scripts/fix-server.sh

9.2 日誌文件

文件
用途
位置
server.log
服務器運行日誌
~/logs/server.log
alerts.log
告警記錄
~/logs/alerts.log

9.3 數據文件

文件
用途
位置
todo.md
待辦事項
~/notes/todo.md

十、進階:讓"數字打工人"更智能

10.1 加入記憶能力

在 OpenClaw 的記憶文件中記錄:

  • 常見問題和解決方案
  • 服務器歷史數據
  • 個人偏好

示例:在 MEMORY.md 中加入:

## 服務器運維記錄

### 常見問題
- CPU 100%:通常是 Node.js 死循環,重啓 pm2
- 內存泄漏:檢查日誌中的 "out of memory",重啓服務
- 磁盤滿:清理 /var/log 和 /tmp

### 個人偏好
- 告警時間:工作日 9:00-18:00
- 告警頻率:同類型問題 1 小時內不重複告警

10.2 加入自定義 Skill

把常用操作封裝成 Skill:

示例:創建 server-health Skill

skills/server-health/
├── SKILL.md          # 技能說明
├── scripts/
│   ├── check.sh      # 檢查腳本
│   ├── fix.sh        # 修復腳本
│   └── report.sh     # 報告腳本
└── references/
    └── common-issues.md  # 常見問題庫

10.3 加入 MCP 擴展

通過 MCP 協議連接更多工具:

  • 數據庫監控
  • 雲服務 API
  • 監控平台(Prometheus、Grafana)

十一、踩坑指南

11.1 SSH 免密登錄配置

問題:執行遠程腳本時提示輸入密碼

解決:配置 SSH 免密登錄

# 生成密鑰對
ssh-keygen -t rsa -b 4096

# 複製公鑰到服務器
ssh-copy-id user@your-server.com

# 測試
ssh user@your-server.com "echo 'SSH OK'"

11.2 cron 時區問題

問題:任務比預期早/晚 8 小時

解決:檢查時區

# 查看系統時區
date +%z
# 輸出:+0800

# 使用正確的 ISO 時間
# 錯誤:2026-05-08T09:00:00
# 正確:2026-05-08T09:00:00+08:00

11.3 腳本執行權限

問題:提示 "Permission denied"

解決:添加執行權限

chmod +x ~/scripts/*.sh

11.4 日誌文件不存在

問題:grep 報錯 "No such file"

解決:先創建文件

touch ~/logs/server.log
touch ~/logs/alerts.log

十二、最佳實踐

12.1 告警分級

級別
條件
處理方式
P0 緊急
服務完全不可用
立即告警 + 自動修復
P1 嚴重
部分功能異常
告警 + 記錄日誌
P2 一般
性能下降
記錄日誌 + 下班彙報

12.2 靜默時段

避免深夜告警打擾:

{
  "message": "如果是 23:00-08:00,只記錄日誌不告警。其他時間正常告警。"
}

12.3 失敗重試

配置任務失敗時的重試策略:

{
  "job": {
    ...
    "failureAlert": {
      "mode": "announce",
      "after": 2
    }
  }
}

含義:失敗 2 次後才告警,避免誤報。


十三、效果驗證

13.1 模擬服務器故障

# 臨時停止服務
sudo systemctl stop nginx

# 等待下一次檢查(最多 1 小時)
# 或手動觸發:openclaw cron run <jobId>

預期效果

  1. 收到告警:服務器異常,正在嘗試自動修復
  2. 收到修復結果:重啓成功/失敗
  3. 收到最終狀態:服務器已恢復/需要人工介入

13.2 檢查日誌

# 查看監控日誌
tail -f ~/logs/server.log

# 查看告警日誌
tail -f ~/logs/alerts.log

十四、總結

組件
作用
技術實現
監控腳本
檢測服務器狀態
Shell + curl
定時任務
定期執行監控
cron 工具
自動修復
問題自動處理
子 Agent + SSH
晨報/日報
信息彙總推送
定時任務 + Skill
智能分析
複雜問題診斷
子 Agent + 聯網搜索

從零到一的完整路徑

需求分析 → 腳本編寫 → 定時任務配置 → 子 Agent 集成 → 測試驗證 → 持續優化

下一步方向

  • 加入更多監控維度(內存、磁盤、網絡)
  • 接入雲服務 API(阿里雲、騰訊雲)
  • 搭建可視化監控面板(Grafana)

系列文章完結

至此,OpenClaw 系列文章全部完成:

文章
核心內容
入門篇
安裝配置 + 基礎使用 + 安全風險
技能篇
Skill 概念 + 使用 + 自定義
記憶篇
三層架構 + MEMORY.md + 維護技巧
原理篇
Gateway + Agent + Channel + 數據流
進階篇
定時任務 + 子 Agent + 自動化
實戰篇
完整案例:數字打工人

從認識 OpenClaw,到用它解決實際問題,希望這個系列對你有幫助。

點點贊和關注不迷路,後續還會分享更多 AI 效率工具。

👨‍💻 H先生出品 | 專注 AI 工具與效率提升