10个真实案例：个人助手 / 代码审查 / SEO流水线 / IoT 边缘自动化等

第42章　10个真实案例：个人助手 / 代码审查 / SEO流水线 / IoT边缘自动化等

前言：从配置到生产

前几章讲透了 OpenClaw 的架构原理和配置细节。本章换一个视角：以 10 个真实部署场景为主线，每个场景完整呈现痛点、架构、关键代码和效果数据。这些案例来自 ClawHub 社区的高 Star 项目与 awesome-openclaw-skills 精选列表，经过作者本人复现验证。

案例1　每日简报机器人

1.1 场景描述

痛点：每天早晨需要浏览科技新闻、检查加密货币行情、确认当日日历安排，整个过程耗时 30-40 分钟，且经常遗漏重要信息。

目标：在每天 7:00 AM 自动汇总所有信息，生成一份简报发送到 Telegram，5 分钟内读完当天所有关键信息。

1.2 架构设计

Cron 触发器（07:00 AM）
    │
    ▼
OpenClaw Agent（daily-briefing）
    ├── web_fetch → HackerNews Top 10
    ├── web_fetch → CoinGecko API（BTC/ETH 行情）
    ├── bash → gcalcli（Google Calendar 当日事项）
    └── bash → curl Telegram Bot API（发送消息）

使用组件：Cron Channel、web_fetch 工具、bash 工具、Telegram Bot API

1.3 关键配置

openclaw.json 调度配置：

{
  "agents": [
    {
      "id": "daily-briefing",
      "skillFile": "~/.openclaw/skills/daily-briefing/SKILL.md",
      "model": "claude-haiku-4-5",
      "schedule": {
        "cron": "0 7 * * *",
        "timezone": "Asia/Shanghai"
      },
      "tools": ["web_fetch", "bash"],
      "env": {
        "TELEGRAM_BOT_TOKEN": "${TELEGRAM_BOT_TOKEN}",
        "TELEGRAM_CHAT_ID": "${TELEGRAM_CHAT_ID}"
      }
    }
  ]
}

SKILL.md 核心内容：

# Daily Briefing Bot

## Purpose
每天早晨 7:00 生成并推送简报到 Telegram。

## Steps

### 1. 采集 HackerNews 热榜
使用 web_fetch 访问 https://hacker-news.firebaseio.com/v0/topstories.json，
取前 10 条 ID，再分别获取标题和链接。

### 2. 采集加密货币行情
访问 https://api.coingecko.com/api/v3/simple/price?ids=bitcoin,ethereum&vs_currencies=usd,cny
解析 BTC 和 ETH 的当前价格和 24h 涨跌幅。

### 3. 采集今日日历
运行 bash 命令：gcalcli --cal "我的日历" agenda today today --nocolor

### 4. 生成并发送简报
将以上信息格式化为 Markdown，通过 Telegram Bot API 发送到指定群组：
bash: curl -X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
  -d chat_id=${TELEGRAM_CHAT_ID} \
  -d parse_mode=Markdown \
  -d text="<生成的简报内容>"

## Output Format
📰 *今日科技简报 - {日期}*

🔥 HackerNews 热榜
1. {标题} - {链接}
...

💰 行情速览
BTC: ${价格} ({涨跌}%)
ETH: ${价格} ({涨跌}%)

📅 今日日程
{日历事项列表}

1.4 实现步骤

# 1. 安装依赖
pip install gcalcli
gcalcli init  # 授权 Google Calendar

# 2. 创建 Telegram Bot（通过 @BotFather 获取 token）

# 3. 配置环境变量
echo 'TELEGRAM_BOT_TOKEN=your_token' >> ~/.openclaw/.env
echo 'TELEGRAM_CHAT_ID=your_chat_id' >> ~/.openclaw/.env

# 4. 注册 Skill
openclaw agent --message "初始化 daily-briefing Skill" \
  --skill ~/.openclaw/skills/daily-briefing/SKILL.md

# 5. 测试运行（立即触发，不等 cron）
openclaw agent --id daily-briefing --message "立即生成今日简报" --run-now

# 6. 验证 Cron 注册
openclaw nodes status | grep daily-briefing

1.5 效果数据

1.6 注意事项

• CoinGecko 免费 API 有速率限制（每分钟 10-30 次），Haiku 模型不会产生过多调用
• gcalcli 首次需要交互授权，建议手动运行一次后再交由 Agent 调用
• Telegram 消息长度上限 4096 字符，超长时 SKILL.md 中应指定截断规则

案例2　邮件智能管理

2.1 场景描述

痛点：每天收到 80-150 封邮件，90% 是通知、订阅和垃圾邮件，真正需要处理的只有 10-20 封，但筛选本身就耗费 1 小时。

目标：自动分类邮件，为需要回复的邮件生成草稿，将含日程信息的邮件自动添加到日历。

2.2 架构设计

Gmail Webhook（Push Notification）
    │
    ▼
OpenClaw Agent（email-manager）
    ├── 分类判断（LLM 语义理解）
    │   ├── Category: Newsletter → 自动归档
    │   ├── Category: Action Required → 生成回复草稿
    │   └── Category: Meeting → 提取时间+创建日历事项
    ├── bash → Gmail API（归档/标签/草稿写入）
    └── bash → Google Calendar API（添加事项）

2.3 关键配置

{
  "agents": [
    {
      "id": "email-manager",
      "skillFile": "~/.openclaw/skills/email-manager/SKILL.md",
      "model": "claude-sonnet-4-5",
      "triggers": {
        "webhook": {
          "path": "/hooks/gmail",
          "port": 8765,
          "secret": "${GMAIL_WEBHOOK_SECRET}"
        }
      },
      "tools": ["bash"],
      "permissions": {
        "allowedDomains": ["gmail.googleapis.com", "calendar.googleapis.com"]
      },
      "maxSessionTokens": 8000
    }
  ]
}

SKILL.md 分类规则段落：

## Classification Rules

对于每封新邮件，按以下优先级分类：

1. **垃圾/订阅**：发件人域名在黑名单中，或 Subject 含有 "unsubscribe"/"newsletter" 关键词
   → 操作：bash 调用 Gmail API 归档并打标签 "auto-archived"

2. **会议邀请**：邮件包含时间、地点和参与人信息
   → 操作：提取 {日期}/{时间}/{地点}/{参与人}，调用 Google Calendar API 创建事项

3. **需要行动**：发件人是已知联系人，且邮件包含问题或请求
   → 操作：生成回复草稿（礼貌、简洁、不超过 3 段），通过 Gmail API 保存为草稿

4. **FYI（仅供参考）**：公司内部通知，无需回复
   → 操作：打标签 "fyi"，不归档

## Privacy Note
不要在日志中记录邮件正文内容，只记录 messageId 和分类结果。

2.4 实现步骤

# 1. 启用 Gmail Push Notification（需要 Google Cloud Pub/Sub）
gcloud pubsub topics create gmail-notifications
gcloud pubsub subscriptions create gmail-sub \
  --topic=gmail-notifications \
  --push-endpoint=http://your-server:8765/hooks/gmail

# 2. 授权 Gmail API 和 Calendar API
# 使用 OAuth2，参考 Google Cloud Console

# 3. 启动 Agent（常驻监听）
openclaw gateway start
openclaw agent --id email-manager --message "开始监听 Gmail 通知"

# 4. 测试 Webhook
curl -X POST http://localhost:8765/hooks/gmail \
  -H "Content-Type: application/json" \
  -d '{"message": {"data": "base64_encoded_notification"}}'

2.5 效果数据

2.6 注意事项

• 邮件隐私极为重要：确保 maxSessionTokens 设置合理，避免大量邮件内容堆积在 Context 中
• 草稿必须经人工审核后发送，不要配置自动发送
• Gmail API 每日配额：每个用户每天 1,000,000,000 配额单位，正常使用不会超出

案例3　GitHub PR 自动审查

3.1 场景描述

痛点：团队 PR 数量多，人工审查 backlog 积压严重。初级开发者的 PR 常犯相同类型的问题（命名不规范、缺少错误处理、测试覆盖不足），耗费高级工程师大量时间。

目标：PR 提交后自动进行初审，提供具体的改进意见，人工审查只需关注架构层面的决策。

3.2 架构设计

GitHub Webhook（pull_request 事件）
    │
    ▼
OpenClaw Agent（pr-reviewer）
    ├── bash → GitHub API（获取 PR diff）
    ├── ACP → Claude Code（代码质量分析）
    │   ├── 命名规范检查
    │   ├── 错误处理完整性
    │   ├── 测试覆盖分析
    │   └── 安全漏洞初筛
    └── bash → GitHub API（写入 Review Comment）

3.3 关键配置

{
  "agents": [
    {
      "id": "pr-reviewer",
      "skillFile": "~/.openclaw/skills/pr-reviewer/SKILL.md",
      "model": "claude-opus-4-5",
      "thinking": "high",
      "triggers": {
        "webhook": {
          "path": "/hooks/github",
          "port": 8766,
          "secret": "${GITHUB_WEBHOOK_SECRET}"
        }
      },
      "tools": ["bash"],
      "acp": {
        "enabled": true,
        "allowedAgents": ["claude-code"]
      },
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  ]
}

SKILL.md 审查规则：

# PR Auto-Reviewer

## Trigger
收到 GitHub Webhook 时，payload 的 action 字段为 "opened" 或 "synchronize"。

## Steps

### 1. 获取 PR 信息
从 Webhook payload 提取：
- PR 编号、仓库名、作者、目标分支
- 使用 GitHub API 获取完整 diff：
  bash: curl -H "Authorization: token ${GITHUB_TOKEN}" \
    https://api.github.com/repos/{owner}/{repo}/pulls/{pr_number}/files

### 2. 通过 ACP 调用 Claude Code 分析
将 diff 内容传递给 Claude Code，要求检查：
- 函数和变量命名是否遵循项目约定
- 是否存在未处理的异常路径
- 新增代码是否有对应的单元测试
- 是否存在明显的 SQL 注入、XSS 等安全问题
- 复杂逻辑是否有注释说明

### 3. 生成审查评论
将分析结果格式化为 GitHub Review 格式，区分：
- 必须修改（blocking）：安全漏洞、严重逻辑错误
- 建议修改（non-blocking）：代码风格、可读性改进
- 欣赏的实现（positive）：优秀的设计值得表扬

### 4. 提交 Review
bash: curl -X POST \
  -H "Authorization: token ${GITHUB_TOKEN}" \
  https://api.github.com/repos/{owner}/{repo}/pulls/{pr_number}/reviews \
  -d '{"event": "COMMENT", "body": "<审查内容>", "comments": [...]}'

## Review Comment Header
在每次 Review 开头注明：
"🤖 此 Review 由 OpenClaw PR-Reviewer 自动生成，仅供参考。
  人工审查将重点关注架构和业务逻辑层面。"

3.4 实现步骤

# 1. 在 GitHub 仓库设置 Webhook
# URL: http://your-server:8766/hooks/github
# Content type: application/json
# Events: Pull requests

# 2. 生成 GitHub Personal Access Token（需要 repo 权限）

# 3. 启动 Agent
openclaw gateway start
echo "PR Reviewer 已启动，等待 Webhook..."

# 4. 测试（模拟 PR 事件）
curl -X POST http://localhost:8766/hooks/github \
  -H "X-GitHub-Event: pull_request" \
  -H "X-Hub-Signature-256: sha256=..." \
  -d '{"action": "opened", "pull_request": {"number": 42, ...}}'

3.5 效果数据

3.6 注意事项

• 必须在 Review 中明确标注"AI 自动生成"，避免开发者误以为是人工审查
• 对于大型 PR（diff > 500 行），建议设置 maxDiffLines 限制，避免超出 Token 预算
• 安全相关的 PR（密钥、权限变更）应额外触发人工强制审查标记

案例4　大型项目多文件重构

4.1 场景描述

痛点：将一个 8 万行的 Python 2 项目迁移到 Python 3，涉及语法变更、依赖替换、测试更新。人工逐文件修改估计需要 3 个月，且容易遗漏边角情况。

目标：使用 ACP 调度 Claude Code 并行处理多个模块，在 1 周内完成迁移，保持测试覆盖率不下降。

4.2 架构设计

OpenClaw 主 Agent（refactor-coordinator）
    │
    ├── bash → 扫描文件树，生成迁移任务列表
    │
    ├── ACP → Claude Code Session 1（处理 core/ 模块）
    ├── ACP → Claude Code Session 2（处理 api/ 模块）
    ├── ACP → Claude Code Session 3（处理 utils/ 模块）
    │   （sessions_spawn 并行模式）
    │
    ├── bash → pytest 运行测试
    └── bash → git commit（原子性提交每个模块）

4.3 关键配置

{
  "agents": [
    {
      "id": "refactor-coordinator",
      "skillFile": "~/.openclaw/skills/py3-migration/SKILL.md",
      "model": "claude-opus-4-5",
      "thinking": "high",
      "acp": {
        "enabled": true,
        "maxParallelSessions": 3,
        "sessionTimeout": 3600
      },
      "tools": ["bash"],
      "maxSessionTokens": 200000,
      "permissions": {
        "fileSystem": {
          "write": ["./src/**", "./tests/**"],
          "read": ["./src/**", "./tests/**", "./requirements*.txt"]
        }
      }
    }
  ]
}

SKILL.md 重构协调逻辑：

# Python 3 Migration Coordinator

## Phase 1: 扫描和规划（不修改文件）
使用 bash 命令扫描所有 .py 文件：
- 识别 print 语句（非函数调用）
- 识别 unicode/basestring/long 等 Python 2 专用类型
- 识别 import 变化（urllib2 → urllib.request 等）
- 统计每个目录的工作量

输出迁移计划到 migration-plan.json，格式：
{"module": "core/", "files": [...], "complexity": "high", "estimatedTokens": 45000}

## Phase 2: 并行重构（通过 ACP 分发子任务）
对每个 complexity >= medium 的模块，创建独立的 Claude Code Session：
- 传入模块目录路径和迁移规则列表
- 要求子 Agent 逐文件修改后运行 python3 -m py_compile 验证语法
- 子 Agent 完成后返回修改摘要

## Phase 3: 集成测试
等待所有子 Session 完成后：
- 运行 pytest --tb=short 2>&1
- 若测试失败，提取错误信息，重新派发修复任务
- 测试通过后生成迁移报告

## Constraints
- 每个子 Session 只能修改自己负责的目录
- 修改前必须 git stash，失败时可以 git stash pop 回滚
- 禁止修改 requirements.txt（在主 Session 统一处理）

4.4 实现步骤

# 1. 确保项目在 git 版本控制下
git init && git add . && git commit -m "pre-migration snapshot"

# 2. 运行主协调 Agent
openclaw agent \
  --id refactor-coordinator \
  --message "开始 Python 3 迁移，项目路径 $(pwd)" \
  --thinking high

# 3. 监控子 Session 进度
watch -n 10 'openclaw nodes status | grep claude-code'

# 4. 查看迁移进度报告
cat migration-plan.json | jq '.[] | select(.status == "completed")'

4.5 效果数据

4.6 注意事项

• 必须在重构前创建 Git 快照分支，随时可以回滚
• 并行 Session 数量不超过 3 个（避免文件锁冲突）
• 复杂业务逻辑的修改建议降为单 Session 处理，避免并行时逻辑理解不一致

案例5　竞品情报监控系统

5.1 场景描述

痛点：需要跟踪 15 个竞品网站的定价页面、产品更新和博客动态。人工每周查看一次，经常错过及时的价格调整信息，导致在商务谈判中处于被动。

目标：每 4 小时自动采集竞品数据，检测变化，生成结构化情报报告推送到 Slack。

5.2 架构设计

Cron（每 4 小时）
    │
    ▼
OpenClaw Agent（competitor-monitor）
    ├── web_fetch × 15（并发采集竞品页面）
    ├── bash → 与上次快照对比（diff）
    ├── LLM 分析（识别定价变化/新功能/营销动向）
    └── bash → Slack API（推送结构化报告）
         ├── 有变化 → 立即推送
         └── 无变化 → 每日汇总推送

5.3 关键配置

{
  "agents": [
    {
      "id": "competitor-monitor",
      "skillFile": "~/.openclaw/skills/competitor-monitor/SKILL.md",
      "model": "claude-sonnet-4-5",
      "schedule": {
        "cron": "0 */4 * * *",
        "timezone": "UTC"
      },
      "tools": ["web_fetch", "bash"],
      "persistence": {
        "snapshotDir": "~/.openclaw/data/competitor-snapshots",
        "retentionDays": 90
      },
      "env": {
        "SLACK_WEBHOOK_URL": "${SLACK_WEBHOOK_URL}",
        "COMPETITOR_LIST": "competitor-list.json"
      }
    }
  ]
}

竞品列表配置文件（competitor-list.json）：

{
  "competitors": [
    {
      "name": "CompetitorA",
      "urls": {
        "pricing": "https://competitora.com/pricing",
        "changelog": "https://competitora.com/changelog",
        "blog": "https://competitora.com/blog"
      },
      "priority": "high",
      "alertOnChange": ["pricing", "changelog"]
    }
  ]
}

SKILL.md 监控逻辑：

## Monitoring Logic

### 采集阶段
对 competitor-list.json 中的每个竞品：
1. web_fetch 获取 pricing 页面的主要内容区域
2. web_fetch 获取 changelog/blog 最新条目
3. 将内容保存到快照文件：
   bash: cat > ~/.openclaw/data/competitor-snapshots/{name}-{url_type}-{timestamp}.txt

### 对比阶段
读取上次快照内容，与当前内容对比：
bash: diff ~/.openclaw/data/competitor-snapshots/{name}-pricing-latest.txt \
  ~/.openclaw/data/competitor-snapshots/{name}-pricing-current.txt

如有差异，请分析变化的性质：
- 价格数字变化（提取具体金额）
- 套餐结构调整（功能增减）
- 促销活动（折扣码/限时优惠）

### 报告生成
按以下格式生成 Slack 消息：
🚨 *竞品动态提醒* - {时间}

*{竞品名}* 发生以下变化：
• 定价调整：{具体描述}
• 影响评估：{对我方业务的潜在影响}
• 建议行动：{1-2 条具体建议}

5.4 实现步骤

# 1. 创建快照目录
mkdir -p ~/.openclaw/data/competitor-snapshots

# 2. 编写竞品列表配置
vim competitor-list.json

# 3. 测试单次运行
openclaw agent --id competitor-monitor --message "立即运行一次竞品监控" --run-now

# 4. 查看生成的快照
ls -la ~/.openclaw/data/competitor-snapshots/

# 5. 注册定时任务
openclaw config set agents.competitor-monitor.schedule.enabled true

5.5 效果数据

某电商 SaaS 公司的实际案例：

5.6 注意事项

• 确保 web_fetch 的频率不违反目标网站的 robots.txt 和服务条款
• 对于反爬措施严格的网站（Cloudflare 保护），考虑使用官方 RSS/API 替代
• 快照文件会持续增长，retentionDays: 90 确保自动清理

案例6　客户入驻全自动化

6.1 场景描述

痛点：新客户签约后，销售需要手动完成 8 个步骤：发送欢迎邮件、创建项目文件夹、建 Slack 频道、邀请客户到频道、设置日历会议、更新 CRM 记录、通知内部团队、创建 Jira 项目……每次耗时约 2 小时，经常遗漏步骤。

目标：CRM webhook 触发后，2 分钟内完成所有入驻操作，零遗漏。

6.2 架构设计

CRM Webhook（deal_won 事件）
    │
    ▼
OpenClaw Agent（customer-onboarding）
    ├── bash → Gmail API（发送欢迎邮件）
    ├── bash → Google Drive API（创建项目文件夹，复制模板）
    ├── bash → Slack API（创建频道 + 邀请客户 + 内部通知）
    ├── bash → Google Calendar API（创建 Kickoff 会议邀请）
    ├── bash → CRM API（更新客户状态）
    └── bash → Jira API（创建项目 + 初始 Epic）

6.3 关键配置

{
  "agents": [
    {
      "id": "customer-onboarding",
      "skillFile": "~/.openclaw/skills/customer-onboarding/SKILL.md",
      "model": "claude-sonnet-4-5",
      "triggers": {
        "webhook": {
          "path": "/hooks/crm",
          "port": 8767,
          "secret": "${CRM_WEBHOOK_SECRET}"
        }
      },
      "tools": ["bash"],
      "timeout": 300,
      "onError": {
        "action": "notify_slack",
        "channel": "#ops-alerts",
        "message": "客户入驻流程异常，请人工介入：{error}"
      }
    }
  ]
}

SKILL.md 入驻流程：

# Customer Onboarding Automation

## Input
从 CRM Webhook payload 提取：
- customer_name: 客户公司名
- contact_email: 主要联系人邮件
- contact_name: 联系人姓名
- plan: 购买套餐（starter/pro/enterprise）
- sales_rep: 负责销售的员工邮件

## Steps（按顺序执行，任一步骤失败立即记录并继续）

### Step 1: 发送欢迎邮件
使用 Gmail API 发送模板邮件（读取 templates/welcome-{plan}.html）
收件人：{contact_email}
抄送：{sales_rep}

### Step 2: 创建 Google Drive 文件夹
- 在 "Clients" 父目录下创建 "{customer_name}" 文件夹
- 复制模板文件夹 "Client Template" 的内容
- 将 {contact_email} 添加为编辑者

### Step 3: 创建 Slack 频道
频道名：client-{customer_name 小写，空格替换为连字符}
邀请：{sales_rep} 和所有 @customer-success 组成员
发送欢迎消息：
  "🎉 欢迎 {customer_name} 加入！我们为 {plan} 计划的客户提供专属支持。"

### Step 4: 创建 Kickoff 会议
时间：当前时间 +3 个工作日，上午 10:00（UTC+8）
时长：60 分钟
参与人：{contact_email}, {sales_rep}
描述："项目启动会议 - {customer_name}"

### Step 5: 更新 CRM 记录
将 deal 状态更新为 "onboarding"，记录入驻开始时间

### Step 6: 创建 Jira 项目
项目 Key：前4个大写字母（{customer_name}）
模板：Client Onboarding Template
初始 Epic：入驻阶段（含 5 个标准子任务）

### Step 7: 生成入驻摘要
将以上所有操作的结果汇总，发送到 #onboarding-log Slack 频道

6.4 实现步骤

# 1. 准备各 API 的凭证（Gmail OAuth2、Slack App Token、Jira API Token）
cp .env.example .env
vim .env  # 填入各 API 密钥

# 2. 测试 Webhook 接收
openclaw gateway start
curl -X POST http://localhost:8767/hooks/crm \
  -H "Content-Type: application/json" \
  -d '{"event": "deal_won", "customer_name": "测试公司", ...}'

# 3. 验证每个步骤的执行结果
openclaw agent --id customer-onboarding \
  --message "检查上次入驻流程的执行日志" \
  --session-id sess_xxxx

6.5 效果数据

6.6 注意事项

• 每个步骤的错误不应阻断后续步骤，SKILL.md 中明确"失败继续"策略
• 最终汇总消息应列出每个步骤的成功/失败状态，便于人工补救
• 欢迎邮件模板需要法务审核，不要让 AI 随意生成邮件正文

案例7　语音驱动 DevOps 助手

7.1 场景描述

痛点：深夜生产告警，需要在手机上紧急处理。在手机浏览器上翻日志、找配置文件、执行 kubectl 命令，操作体验极差，容易误操作。

目标：通过语音指令完成日志审查→配置修改→重新部署的完整流程，手机端体验接近桌面端。

7.2 架构设计

iOS Shortcuts（语音识别）
    │ HTTP POST（文字）
    ▼
OpenClaw Mobile Node（iOS 客户端）
    │ ACP
    ▼
OpenClaw Gateway（服务器端）
    ├── bash → kubectl（查看 Pod 日志）
    ├── bash → kubectl（修改 ConfigMap）
    ├── bash → kubectl rollout restart
    └── bash → curl 验证服务健康

7.3 关键配置

服务器端 Agent 配置：

{
  "agents": [
    {
      "id": "devops-assistant",
      "skillFile": "~/.openclaw/skills/devops-assistant/SKILL.md",
      "model": "claude-opus-4-5",
      "thinking": "standard",
      "tools": ["bash"],
      "permissions": {
        "shell": {
          "allowedCommands": ["kubectl", "helm", "curl", "jq"],
          "requireConfirmation": ["kubectl delete", "helm uninstall"]
        }
      },
      "nodes": {
        "ios": {
          "enabled": true,
          "requireAuth": true,
          "tokenExpiry": 3600
        }
      }
    }
  ]
}

iOS Shortcuts 调用示例（伪代码）：

Shortcut: "DevOps 助手"
1. 语音识别（Ask Each Time）→ 存储到变量 $voice_input
2. URL: https://your-server:18789/agent/devops-assistant
   Method: POST
   Body: {"message": $voice_input, "node": "ios"}
   Headers: Authorization: Bearer $TOKEN
3. 显示响应内容（大字体）
4. 文字转语音播报关键信息

SKILL.md 安全操作规范：

# DevOps Voice Assistant

## Safety Rules（最高优先级）
- 所有 kubectl apply/delete/scale 命令必须先说明操作内容，等待确认
- 只操作 namespace: production 和 staging，禁止操作 kube-system
- 每次操作前检查 Git 当前分支，禁止在 main 以外的分支做生产变更
- 操作完成后必须验证服务健康状态

## Voice Command Examples
- "查看 api-service 的最近 100 行日志" → kubectl logs -n production deployment/api-service --tail=100
- "api-service 的 Pod 数量是多少" → kubectl get pods -n production -l app=api-service
- "重启 api-service" → [确认] → kubectl rollout restart deployment/api-service -n production
- "查看今天的错误日志" → kubectl logs -n production deployment/api-service --since=8h | grep ERROR

7.4 实现步骤

# 1. 在服务器配置 SSL（HTTPS，iPhone 连接需要）
certbot certonly --standalone -d your-server-domain.com

# 2. 生成 iOS 访问 Token
openclaw devices approve --device ios-iphone \
  --permissions read,exec-readonly \
  --expiry 365d

# 3. 在 iOS 上配置 Shortcuts
# （参考官方文档：docs.openclaw.dev/mobile）

# 4. 测试语音流程
# 说："查看 API 服务的错误日志"
# → 预期：返回最近错误信息的语音播报

7.5 效果数据

7.6 注意事项

• 高危操作（scale down 到 0、删除 PVC）必须通过双重确认（语音+推送通知确认按钮）
• iOS 节点的 Token 应设置合理过期时间，不要永久有效
• 建议只在受信任的网络（家庭 WiFi + VPN）下使用此功能

案例8　SEO 内容工厂

8.1 场景描述

痛点：出海电商网站需要持续产出本地化 SEO 内容（英/日/德语），每篇文章需要关键词研究→内容生成→SEO 优化→发布到 WordPress，人工完成每篇需要约 5 小时，难以规模化。

目标：每 4 小时自动产出 2-3 篇高质量本地化内容，直接发布到 WordPress，每周节省 50 小时以上。

8.2 架构设计

Cron（每 4 小时）
    │
    ▼
OpenClaw Agent（seo-content-factory）
    ├── web_fetch → SEMrush/Ahrefs API（关键词数据）
    ├── web_fetch × N（竞品文章采集与分析）
    ├── LLM（内容生成，根据关键词和竞品写作）
    ├── LLM（SEO 优化：meta title/description/内链建议）
    └── bash → WordPress REST API（发布为草稿）

8.3 关键配置

{
  "agents": [
    {
      "id": "seo-content-factory",
      "skillFile": "~/.openclaw/skills/seo-content-factory/SKILL.md",
      "model": "claude-opus-4-5",
      "schedule": {
        "cron": "0 */4 * * *"
      },
      "tools": ["web_fetch", "bash"],
      "env": {
        "WP_API_URL": "https://your-site.com/wp-json/wp/v2",
        "WP_APP_PASSWORD": "${WP_APP_PASSWORD}",
        "SEMRUSH_API_KEY": "${SEMRUSH_API_KEY}",
        "TARGET_LANGUAGE": "en,ja,de"
      }
    }
  ]
}

SKILL.md SEO 写作标准：

# SEO Content Factory

## Keyword Research
1. 从关键词种子文件（keywords-seed.txt）读取本周目标关键词
2. 使用 SEMrush API 获取每个关键词的：
   - 月均搜索量（过滤 < 500 的关键词）
   - 关键词难度（KD < 40 优先）
   - 相关长尾词列表

## Competitor Analysis
对每个目标关键词，web_fetch 采集 Google 前 5 名文章的：
- 文章结构（H2/H3 标题层级）
- 字数范围
- 关键词密度
- 内容独特角度

## Content Generation Requirements
生成文章时必须遵守：
- 字数：1500-2500 字
- 关键词密度：目标词 1-2%，语义相关词自然分布
- 结构：引言 → 3-5 个 H2 章节 → 总结
- 原创性：不能复制竞品内容，需要提供独特观点或数据
- 语言：如果 TARGET_LANGUAGE 包含 "ja"，生成日语版本

## SEO Metadata
每篇文章同时生成：
- Meta title（< 60 字符，含主关键词）
- Meta description（< 160 字符，含 CTA）
- 推荐内链（从现有文章 URL 列表中选择最相关的 3 条）

## WordPress Publishing
bash: curl -X POST "${WP_API_URL}/posts" \
  -u "admin:${WP_APP_PASSWORD}" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "{文章标题}",
    "content": "{文章内容（HTML格式）}",
    "status": "draft",
    "meta": {
      "_yoast_wpseo_title": "{meta title}",
      "_yoast_wpseo_metadesc": "{meta description}"
    }
  }'

8.4 实现步骤

# 1. 准备关键词种子文件
echo "best ergonomic chair\nstanding desk benefits\nhome office setup" > keywords-seed.txt

# 2. 获取现有文章 URL 列表（用于内链推荐）
curl "${WP_API_URL}/posts?per_page=100" | jq '.[].link' > existing-posts.txt

# 3. 测试单次内容生成
openclaw agent --id seo-content-factory \
  --message "生成一篇关于'ergonomic chair'的 SEO 文章（英语）" \
  --run-now

# 4. 在 WordPress 后台审核草稿后发布

8.5 效果数据

某出海家具品牌的实际数据：

8.6 注意事项

• 所有文章必须经过人工审核后再发布（status: draft），不要配置自动发布
• 关键词研究 API 成本较高，建议每次只处理 5-10 个关键词
• 多语言内容生成时，本地化质量需要母语者抽查，AI 在文化细节上可能有偏差

案例9　树莓派家庭安全守卫

9.1 场景描述

痛点：家里安装了摄像头，但传统监控软件只会录像，不会智能分析。想在检测到异常（陌生人、包裹遗留、门未关）时立即通知，但误报率高（宠物、树影）让人疲倦。

目标：部署在树莓派上的 OpenClaw Headless Node，每 5 分钟抓取摄像头图像，用 AI 判断是否异常，误报率 < 5%。

9.2 架构设计

Raspberry Pi 4（Headless Node）
    │
    ├── Cron（每 5 分钟）
    │       │
    │       ▼
    │   bash → camera.snap（抓取图像）
    │       │
    │       ▼
    │   OpenClaw Agent（home-guard）
    │       ├── LLM 视觉分析（Claude 多模态）
    │       │   ├── 识别：人/宠物/车辆/包裹
    │       │   ├── 判断：是否异常（基于规则）
    │       │   └── 生成：异常描述
    │       └── bash → Telegram API（发送图片+描述）
    │
    └── OpenClaw Gateway（树莓派本地运行）

9.3 关键配置

树莓派端 openclaw.json：

{
  "gateway": {
    "port": 18789,
    "host": "127.0.0.1",
    "lowMemoryMode": true
  },
  "agents": [
    {
      "id": "home-guard",
      "skillFile": "/home/pi/.openclaw/skills/home-guard/SKILL.md",
      "model": "claude-haiku-4-5",
      "schedule": {
        "cron": "*/5 * * * *"
      },
      "tools": ["bash"],
      "env": {
        "CAMERA_DEVICE": "/dev/video0",
        "TELEGRAM_BOT_TOKEN": "${TELEGRAM_BOT_TOKEN}",
        "TELEGRAM_CHAT_ID": "${TELEGRAM_CHAT_ID}",
        "OWNER_HOME_HOURS": "07:00-23:00"
      },
      "resources": {
        "maxMemoryMB": 512,
        "cpuPriority": "low"
      }
    }
  ]
}

SKILL.md 异常检测规则：

# Home Security Guard

## Image Capture
bash: fswebcam -d ${CAMERA_DEVICE} -r 1280x720 --no-banner /tmp/snapshot.jpg

## Visual Analysis
将图片转为 base64 后通过多模态 API 分析：
bash: base64 /tmp/snapshot.jpg

分析内容（返回 JSON）：
- detected_objects: 检测到的物体列表（人/宠物/车辆/包裹/门/窗）
- anomalies: 异常列表（参见规则表）
- confidence: 置信度（0-1）
- description: 一句话描述

## Anomaly Rules（判断是否发送告警）
以下情况视为异常，发送 Telegram 通知：

| 条件 | 时间范围 | 置信度阈值 |
|------|----------|------------|
| 检测到陌生人（无法识别为家庭成员） | 任何时间 | > 0.85 |
| 玄关门长时间未关（> 10 分钟） | 任何时间 | > 0.80 |
| 包裹被遗留在门口（> 30 分钟） | 08:00-20:00 | > 0.75 |
| 检测到车辆停在私家车道 | 00:00-06:00 | > 0.90 |

## False Positive Reduction
- 宠物（猫/狗）单独出现 → 不告警
- 同一异常在 30 分钟内只发送一次告警
- 风/树影引起的画面变化 → 依赖物体检测，不做像素级 diff

## Alert Format
bash: curl -X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendPhoto" \
  -F chat_id="${TELEGRAM_CHAT_ID}" \
  -F photo=@/tmp/snapshot.jpg \
  -F caption="⚠️ 安全告警 {时间}: {description}"

9.4 实现步骤

# 树莓派上执行：

# 1. 安装 OpenClaw（ARM 版本）
curl -fsSL https://install.openclaw.dev/arm64 | bash

# 2. 安装摄像头工具
sudo apt-get install fswebcam

# 3. 测试摄像头
fswebcam -d /dev/video0 -r 1280x720 /tmp/test.jpg
ls -la /tmp/test.jpg

# 4. 配置低内存模式（树莓派 4 建议至少 4GB）
openclaw config set gateway.lowMemoryMode true
openclaw config set gateway.maxMemoryMB 512

# 5. 启动 Gateway（开机自启）
sudo systemctl enable openclaw-gateway
sudo systemctl start openclaw-gateway

# 6. 测试告警流程
openclaw agent --id home-guard --message "立即拍摄并分析" --run-now

9.5 效果数据

9.6 注意事项

• 图片会发送到 Anthropic API（Claude 多模态），确保遵守隐私相关法规
• 树莓派内存有限，lowMemoryMode: true 会禁用部分日志功能
• 定期检查 /tmp 目录，快照文件需要定期清理（tmpwatch 或 systemd-tmpfiles）

案例10　Slack 工程运营机器人

10.1 场景描述

痛点：工程团队在 Slack 上的告警频道每天收到数百条告警，On-Call 工程师需要手动查看日志、关联事件、判断根因，往往从收到告警到定位问题需要 20-30 分钟。

目标：告警触发后，Agent 自动分析日志、定位根因、给出修复建议，将响应时间缩短到 3 分钟以内。

10.2 架构设计

Slack Events API（告警消息）
    │
    ▼
OpenClaw Agent（slack-ops-bot）
    ├── bash → 云日志平台 API（采集相关日志）
    ├── LLM → 日志模式分析（错误聚类/时间关联）
    ├── bash → 监控 API（Datadog/Prometheus，获取指标）
    ├── LLM → 根因推断（基于日志+指标）
    └── bash → Slack API（回复线程，@相关人员）
         ├── 自动修复方案（可执行命令）
         └── 升级路径建议

10.3 关键配置

{
  "agents": [
    {
      "id": "slack-ops-bot",
      "skillFile": "~/.openclaw/skills/slack-ops-bot/SKILL.md",
      "model": "claude-opus-4-5",
      "thinking": "high",
      "triggers": {
        "webhook": {
          "path": "/hooks/slack",
          "port": 8768,
          "secret": "${SLACK_SIGNING_SECRET}"
        }
      },
      "tools": ["bash", "web_fetch"],
      "env": {
        "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}",
        "DATADOG_API_KEY": "${DATADOG_API_KEY}",
        "LOG_PLATFORM": "datadog",
        "MAX_LOG_LINES": "500"
      }
    }
  ]
}

SKILL.md 事件响应逻辑：

# Slack Engineering Operations Bot

## Trigger Conditions
监听 Slack 事件，当满足以下条件时响应：
- 消息来自 #alerts 或 #incidents 频道
- 消息包含关键词：ERROR / CRITICAL / DOWN / timeout / OOM / 5xx

## Response Workflow

### Step 1: 确认告警上下文（30秒内）
立即在消息线程中回复：
"🔍 正在分析此告警，预计 2 分钟内提供根因分析..."

解析告警消息，提取：
- 服务名称
- 错误类型
- 发生时间
- 受影响范围

### Step 2: 采集诊断数据（60秒内）
并行执行：
- 查询 Datadog 日志（最近 500 行，过滤 ERROR 级别）
- 查询 Datadog 指标（CPU/内存/错误率，最近 30 分钟）
- 查询相关服务的健康检查端点

### Step 3: 根因分析
基于采集的数据，分析：
1. 错误首次出现的时间点
2. 是否与某次部署/配置变更关联
3. 是否有已知的故障模式匹配
4. 相关联的上下游服务状态

### Step 4: 回复 Slack 线程
格式：
🚨 *告警分析报告*

*根本原因（置信度: {%}）*
{根因描述，1-2句}

*证据*
• {关键日志行1}
• {指标异常: 错误率从 0.2% 升至 12.4%}

*建议修复步骤*
1. `kubectl rollout undo deployment/api-service`（若为近期部署导致）
2. `kubectl scale deployment/api-service --replicas=5`（若为流量峰值）

*需要升级？*
若 5 分钟内未恢复，请联系 @on-call-lead

*相关 Runbook*: <https://wiki.company.com/runbooks/api-service|API Service Runbook>

10.4 实现步骤

# 1. 创建 Slack App（Slack API 控制台）
# 权限：channels:history, chat:write, reactions:write
# 开启 Event Subscriptions，URL: https://your-server:8768/hooks/slack

# 2. 配置 Slack Signing Secret
echo "SLACK_SIGNING_SECRET=xxx" >> ~/.openclaw/.env

# 3. 测试事件接收
openclaw gateway start

# 模拟告警消息
curl -X POST http://localhost:8768/hooks/slack \
  -H "Content-Type: application/json" \
  -d '{"event": {"type": "message", "channel": "C_ALERTS", "text": "CRITICAL: API service 5xx rate 45%"}}'

# 4. 验证 Bot 回复
# 检查 #alerts 频道是否出现分析消息

10.5 效果数据

某 100 人工程团队（6个月数据）：

10.6 注意事项

• Bot 提供的修复命令必须由 On-Call 工程师手动执行，不要配置自动执行
• 高置信度（> 90%）的根因分析也只是参考，复杂系统中 AI 可能误判
• 日志可能包含敏感信息（用户 ID、IP），确保 Datadog → OpenClaw 的数据传输路径合规
• Bot 回复频繁时（告警风暴），设置冷却时间避免 Slack API 限速

本章小结

10 个案例覆盖了个人生产力、团队协作、代码工程、IoT 边缘计算和企业运营五个维度。关键规律如下：

1. 模型选择决定成本：简单定时任务（每日简报、邮件分类）用 Haiku，复杂推理（PR 审查、根因分析）用 Opus
2. Webhook 是企业自动化的核心入口：几乎所有企业场景都从外部事件触发，而非纯定时轮询
3. 人工审核环节不可省略：内容发布、邮件发送、生产操作都应保留人工确认步骤
4. 错误处理的设计优先于功能本身：在 SKILL.md 中明确"失败如何处理"比实现功能本身更重要
5. 成本可控：大多数案例的月运行成本在 $10-$100 区间，ROI 显著

下一章将探讨 OpenClaw 项目的生态走向，包括基金会模式、ACP 标准化与开源社区现状。