实战案例与完整工作流

适用版本： OpenClaw v2026.4.11（stable） 验证日期： 2026-04-13 目标读者： 前 10 篇学完，想用 OpenClaw 解决真实问题 难度： ⭐⭐⭐ 中高（因案例而异） 适合首次阅读： 是——挑一个案例做就行

目标

把前十篇学到的能力串成可复制的生产案例。每个案例都是完整配置，改几个字段就能跑。

💡 第一次只选 1 个案例做。 不要 8 个一起上——每个案例都需要调试和磨合，一次只跑通一个才扎实。

前置条件

• 已完成第 1-10 篇
• workspace + 记忆系统 + 安全基线已就位
• 至少一个消息渠道接好

案例总览

先看完这张表再决定做哪个：

风险说明： 低 = 只读/只推送；中 = 会修改文件或标记邮件；高 = 涉及服务器操作，配错可能影响生产。

第一部分：8 个实战案例

每个案例遵循统一结构：适合谁 → 前置依赖 → 风险提示 → 完整配置 → 验证方式 → 常见坑。

案例 1：每日早报

适合谁： 需要高效开始一天的知识工作者。

前置依赖： 第 3 篇《消息渠道（Channels）与交互体验优化》的渠道接入 + 第 8 篇《自动化、多 Agent 与高级执行》的 cron 配置。

风险提示： 低——只读取数据并推送，不修改任何内容。

完整配置：

json5
{
  cron: {
    jobs: [
      {
        name: "daily-briefing",
        schedule: "55 8 * * 1-5",       // 工作日 8:55
        timezone: "Asia/Shanghai",       // ⚠️ 请替换：你的时区
        agent: "researcher",
        profile: "lean",
        prompt: "生成今日早报（不超过 20 行）：天气、3 条行业新闻摘要、今日日程、未读邮件 Top 5、今日重点 1-2 件事。",
        delivery: {
          channel: "feishu",             // ⚠️ 请替换：你的渠道
          chatId: "ou_your_open_id",     // ⚠️ 请替换：你的 open_id
          format: "markdown",
        },
        timeout_seconds: 180,
      },
    ],
  },
}

验证方式：

bash
openclaw cron trigger daily-briefing
# 检查渠道是否收到早报消息

常见坑：

• 首次部署用 every: "5m" 测试格式，确认后再改回 cron
• 早报要短，超过 20 行没人看
• 新闻用 RSS 源而不是实时搜索，后者每次多烧 3-5K tokens

案例 2：邮件智能分流（Gmail / 企微邮箱 / 163 / QQ）

适合谁： 每天 50+ 封邮件的人。

前置依赖： 第 8 篇《自动化、多 Agent 与高级执行》的 cron + 第 9 篇《安全最佳实践（重磅章节）》的凭证管理。

风险提示： 中——会标记邮件已读和移动到文件夹。建议先只做分类推送，确认分类准确后再开启自动归档。绝不自动回复。

国内邮箱 IMAP 参数：

完整配置：

json5
{
  cron: {
    jobs: [
      {
        name: "mail-triage",
        every: "15m",
        agent: "executor",
        profile: "lean",
        // ⚠️ 请替换：prompt 中的分类规则按你的实际需求调整
        prompt: "扫描未读邮件（最多 20 条），分类为：紧急/重要/一般/可忽略。紧急邮件立即推送，一般和可忽略标记已读。每批报告统计。",
        delivery: {
          channel: "telegram",           // ⚠️ 请替换：你的渠道
          chatId: "me",
        },
        timeout_seconds: 120,
      },
    ],
  },
}

验证方式： openclaw cron trigger mail-triage，检查分类结果是否合理。

常见坑：

• 企微/163/QQ 必须在邮箱设置里手动开启 IMAP 并设授权码
• Gmail 用户如需高级操作（label、thread），升级到 mcp-server-gmail

案例 3：GitHub Issue → PR Draft

适合谁： 开源维护者 / 开发团队。

前置依赖： 第 5 篇《写你的第一个自定义技能》+ 第 8 篇多 Agent。

风险提示： 中——会创建 PR，但不会自动合并。建议 reviewer Agent 审查后才推送。

完整配置： 用 webhook 监听 Issue 事件 → researcher 分析 → executor 写代码 → reviewer 审查 → 创建 Draft PR。

json5
{
  // ⚠️ 请替换：GitHub token 放环境变量
  // export GITHUB_TOKEN="ghp_xxx"
  agents: {
    list: [
      { id: "researcher", skills: ["github", "summarize"], sandbox: { mode: "all" } },
      { id: "executor", skills: ["github", "bash-runner"], sandbox: { mode: "non-main" } },
      { id: "reviewer", skills: ["code-review"], sandbox: { mode: "all" } },
    ],
  },
}

验证方式： 手动创建一个测试 Issue，确认 Draft PR 被创建。

常见坑： executor 的 sandbox 不要设为 off——写代码的 Agent 必须受限。

案例 4：竞品动态周报

适合谁： 产品经理 / 运营。

前置依赖： 第 8 篇 cron。

风险提示： 低——只读取公开网页信息。

完整配置：

json5
{
  cron: {
    jobs: [
      {
        name: "competitor-weekly",
        schedule: "0 9 * * 1",          // 每周一 9:00
        timezone: "Asia/Shanghai",       // ⚠️ 请替换
        agent: "researcher",
        profile: "lean",
        // ⚠️ 请替换：竞品名称和关注维度按你的实际需求填写
        prompt: "搜索过去一周关于 [竞品A] [竞品B] [竞品C] 的公开信息（产品更新、融资、人事变动），生成竞品周报，每家 3-5 条要点。",
        delivery: { channel: "feishu", chatId: "ou_xxx" },  // ⚠️ 请替换
      },
    ],
  },
}

验证方式： openclaw cron trigger competitor-weekly。

常见坑： 网页抓取可能被反爬，出现空结果时检查 web_browse 工具是否正常。

案例 5：机票价格监控

适合谁： 差旅频繁、想抄底的人。

前置依赖： 第 8 篇 heartbeat。

风险提示： 低——只读取价格并通知。

完整配置：

json5
{
  cron: {
    jobs: [
      {
        name: "flight-monitor",
        every: "2h",
        agent: "researcher",
        profile: "lean",
        // ⚠️ 请替换：出发地、目的地、日期换成你的实际值
        prompt: "查询 上海→东京 2026-05-01 的机票价格（携程/去哪儿/飞猪任选），如果有低于 ¥2000 的直飞，立即通知我。否则只记录到 daily log。",
        delivery: { channel: "telegram", chatId: "me", only_on_anomaly: true },
      },
    ],
  },
}

验证方式： openclaw cron trigger flight-monitor。

常见坑： 网页抓取价格不一定准确，重要决策前人工复核。

案例 6：IM 群管理（飞书/企微/钉钉）

适合谁： 管理多个工作群的团队负责人。

前置依赖： 第 3 篇《消息渠道（Channels）与交互体验优化》+ 第 8 篇 cron。

风险提示： 中——会发送群消息。配置 requireMention 避免误触发。

常见场景： 每日群总结、@未回复提醒、新人欢迎。

验证方式： 在测试群中手动触发，确认消息格式正确。

案例 7：文件整理

适合谁： 下载目录常年混乱的人。

前置依赖： 第 5 篇《写你的第一个自定义技能》。

风险提示： 中——会移动文件。务必用 Plan-then-Execute 模式：先生成整理方案，人工确认后再执行。

验证方式： 先对一个小目录跑 dry-run，检查方案合理后再 apply。

案例 8：云服务器监控与自愈

适合谁： 运维工程师。

前置依赖： 第 8 篇《自动化、多 Agent 与高级执行》多 Agent + 第 9 篇《安全最佳实践（重磅章节）》安全加固。

风险提示： 高——涉及服务器操作。executor Agent 必须严格限制 allowed_commands，禁止 rm/dd/reboot 等破坏性命令。自愈动作先生成方案等人确认。

需要的凭证： 云 API Key（阿里云 AccessKey / 腾讯云 SecretId）+ SSH Key。

验证方式： 用只读命令测试（df -h、free -m），确认权限边界后再启用自愈。

text
帮我配置一个实战案例。按步骤来：

[第 1 步]
问我想做哪个案例（早报/邮件/GitHub/竞品/机票/群管理/文件整理/云监控），
或者描述一个自定义场景。

[第 2 步]
确认前置依赖是否满足：渠道、凭证、Agent 配置。
缺什么告诉我怎么补。

[第 3 步]
生成完整的 cron/agent/mcp 配置，用 diff 展示。
所有占位符明确标注需要我替换什么。

[第 4 步]
先用临时频率（every 5m）测试 2-3 次。
展示输出给我确认格式和内容。

[第 5 步]
确认后改回正式 schedule，写入配置。

每步等我确认。涉及副作用的操作先说明风险。

第二部分：4 个通用工作流模板

上面 8 个案例抽象出 4 种模式。新场景大部分能从这里套用：

选型口诀： 有时间点用 A，有外部事件用 B，持续监控用 C，涉及副作用用 D。不确定时选更保守的。

验证清单

bash
# 1. 你配置的案例 cron 已注册
openclaw cron list

# 2. 手动触发成功
openclaw cron trigger <你的任务名>

# 3. 消息正确投递到目标渠道
# 在渠道中确认收到消息，格式符合预期

# 4. 查看日志无报错
openclaw logs --follow

常见问题

Q: 第一个案例选哪个？

如果你有飞书或企微，选案例 1（每日早报）——最简单、风险最低、效果最直观。如果没有 IM 但有邮件需求，选案例 2。

Q: 案例之间有依赖关系吗？

没有。每个案例独立，选任何一个开始都行。但案例 8（云监控自愈）风险最高，建议最后做。

Q: prompt 里的格式模板必须照抄吗？

不必。示例中的 prompt 是参考，按你的实际需求调整。核心是写清楚「输入什么 → 怎么处理 → 输出什么格式」。

Q: 案例里的 {chatId}、{ou_xxx} 等变量怎么填？

这些都是占位符。飞书的 open_id 在飞书开放平台「通讯录 → 成员管理」查；企微的 userid 在企业微信管理后台查；Telegram 的 chatId 用 "me" 表示发给自己。

下一步

跑通了第一个案例，你已经体验到 OpenClaw 作为「主动同事」的真实价值了。

最后一篇：第 12 篇《系统体检：跑一次 doctor.sh 就知道你到底配没配好》，给你的整套系统做一次全面体检。