核心问题

很多同学第一次用 OpenClaw，会把目标定成“脚本能跑、能发消息”。但一旦进入真实场景（长期 cron、多来源抓取、多账号、多人协作），你会发现：真正的成本不在写出第一版，而在第二天还能跑、第三周还能扩展、半年后还能被别人接手。

这一课讲“用例工程化”的最低可行方法：把一次成功变成可复用资产。

案例（真实）

案例 A：Overnight Goal Autopilot（从目标到产物）

夜间无人值守推进长期目标，不只输出“想法”，而是落盘 4 份行动文件并一次性播报。

• 证据1：sessionKey=agent:main:cron:25dc7e01-e375-484c-a331-a326a7f616c2:run:929f80cc-43fd-4995-9b65-b491d874d85d｜2026-03-03T18:00:00.116Z｜quote 摘要："先读取：.../memory/overnight-goals-v1.md ... 每天执行一次：生成今天要推进的 4-5 个高杠杆任务..."
• 证据2：同 sessionKey｜2026-03-03T18:00:27.240Z｜quote 摘要："Successfully wrote .../2026-03-04__nightly-push/01_today_plan.md"

案例 B：长期项目目录重构（让产物可检索、可维护）

当产物散落在不理想层级时，直接影响检索与后续维护；一次迁移把“历史包袱”清掉，并用后续自动产出验证不回归。

• 证据1：sessionKey=agent:main:telegram:group:-1003807921933:topic:4214｜timestamp=1772327040080｜quote 摘要："已把 Overnight Goal Autopilot 的历史产出从根级 outputs/ 迁到项目目录"
• 证据2：同 sessionKey｜timestamp=1772327455215｜quote 摘要："... 全部上移为 projects/overnight-goal-autopilot/<日期目录>/...，并删除 outputs/ 层"

失败点（常见错误尝试）

1. 只追求“当次 OK”：消息发出就算完成，没留下可复用模板；下次只能从聊天记录里翻。
2. 产物不落盘或落盘无规范：今天写在 A 目录，明天写在 B 目录；三周后你自己都找不到。
3. 缺少“回执定义”：到底以什么为成功？是“写了文件”还是“发了消息”？是否需要“仅发送一次汇总”？这些不先约定，后面就会刷屏或误以为成功。

关键转折（工程化思维）

把用例当成“产品功能”，最小可复用单元不是一句 prompt，而是：

• 输入契约：读哪份说明书/规则文件（如 overnight-goals）
• 输出契约：固定目录 + 固定命名 + 固定份数/序号
• 回执契约：最终只发一次总览通知（避免噪音）
• 验证契约：写入成功要有明确 log；Unknown 就标 Unknown

当你做到这四个“契约”，用例才从“能跑”变成“可交接”。

可复用 SOP（用例工程 6 步）

1. 定义目标的“可验证产物”：文件/表/消息/状态机。不要只写“生成报告”。
2. 固化目录与命名：建议 projects/<project>/<YYYY-MM-DD__desc>/NN_xxx.md（案例已验证）。
3. 固化模板与序号：产物数量固定，便于 diff 与回归。
4. 把规则写进文件而不是脑子：如目标说明书、过滤规则、触发门禁。
5. 把成功标准写进回执：至少包含：产物列表、是否发送成功（ok=true/false）、Unknown 的边界。
6. 用“下一次自动产出”做回归验证：迁移/重构后，必须跑一次同类任务验证不回归（案例 B 的经验）。

课后作业

1. 选你手上一个“今天能跑”的小用例（抓取/汇总/提醒都行），把它改造成“可复用资产”，至少补齐：
   • 规则文件（输入契约）
   • 产物目录与命名（输出契约）
   • 成功回执字段（回执契约）
2. 写一段“交接说明”（200 字即可）：别人接手需要知道什么？Unknown 是什么？
3. 自检清单（打勾）：
   • 产物可被 git 跟踪/对比
   • 失败时能定位到是“抓取失败/处理失败/投递失败”哪一层
   • 下一次跑起来，不需要翻聊天记录

核心问题

在真实生产里，“失败”不是异常，而是常态：API 限流、抓取链路被策略拦截、网络环境导致误判、甚至本地命令名都可能不一致。问题不在于是否会失败，而在于：失败后你能否用同一套剧本把任务救回来，并且把救火经验沉淀成 SOP。

案例（真实）

案例 A：Brave 429 + fetch failed + python 命令错误的串联故障

同一条日报链路里同时出现限流、网络失败、工具链缺失，但最终仍完成发送。

• 证据1：sessionKey=agent:main:cron:973684ed-69f4-4938-a6ab-3f99c86aa87d｜2026-03-03T23:15:57.699Z｜quote 摘要："web_search ... 429 ... Request rate limit exceeded"
• 证据2：同 sessionKey｜2026-03-03T23:17:45.227Z｜quote 摘要："command not found: python"
• 证据3（结果回执）：同 sessionKey｜2026-03-03T23:21:02.693Z｜quote 摘要："{ "ok": true, ... }"

案例 B：web_fetch 被私网 IP 策略拦截后切换抓取链路

定时情报任务中 web_fetch 直接被 guardrail 拦截，但通过 browser 抓取继续推进并最终投递成功。

• 证据1：sessionKey=agent:main:cron:b3c9715e-ee3c-4036-8940-f97e48e405c3｜2026-03-04T00:24:52.026Z｜quote 摘要："web_fetch ... Blocked: resolves to private/internal/special-use IP address"
• 证据2：同 sessionKey｜2026-03-04T00:25:38.298Z｜quote 摘要："browser open ... url=https://www.reuters.com/..."
• 证据3（结果回执）：同 sessionKey｜2026-03-04T00:26:10.499Z｜quote 摘要："{ "ok": true, ... }"

失败点（错误尝试/反模式）

1. 把不同失败当成不同问题：429 就临时加 sleep；fetch failed 就“再试一次”；private IP blocked 就换 URL。结果是每次救火都从 0 开始。
2. 只盯一个工具：web_fetch 失败就死磕 web_fetch；web_search 失败就死磕 Brave。链路缺少“可切换的备胎”。
3. 不做证据化回执：没有“失败发生在何时/哪层/错误文本”，事后无法复盘，只能凭感觉改。

关键转折：把失败“归类”，而不是“逐个击破”

建议把失败按层归类：

• 检索层：429 / fetch failed（来源发现失败）
• 抓取层：private IP blocked（内容获取失败）
• 执行层：command not found（本地处理失败）
• 投递层：message ok=false（通知失败）

一旦归类，你就能写出“统一剧本”：每层都有固定兜底和退出条件。

可复用 SOP：统一失败剧本（建议贴进团队 Runbook）

目标：救回任务 + 留下可复盘证据 + 不刷屏。

1) 先记录证据（必须）

• 记录：tool、error 原文、时间戳、sessionKey。
• 不确定信息标记 Unknown（例如：最终正文不可见就写 Unknown）。

2) 检索层（429 / fetch failed）

• 触发：出现 429 或连续 web_search=fetch failed。
• 动作：进入“退避 + 兜底”。（具体退避节奏在另一案例中被明确为 2s/5s/10s，若你当前实现不一致，标 Unknown 并补齐。）
• 兜底：切换到 DDG 文本结果（案例 A 的处理路径）。

3) 抓取层（private IP blocked）

• 触发：web_fetch 返回 Blocked: resolves to private/internal/special-use IP address。
• 动作：停止死磕 web_fetch，改为 browser 打开并读取页面内容，同时可并行 web_search 补来源。

4) 执行层（command not found）

• 触发：python/其他解释器不存在。
• 动作：先修工具链（python → python3），再继续后续处理；不要把失败“吞掉”。

5) 最终只发送一次结果

• 成功回执：至少包含 ok=true/false（案例均有 ok=true 证据）。
• 失败回执：明确失败层级与下一步动作。

课后作业

1. 把你最常跑的一条 cron/脚本，按四层（检索/抓取/执行/投递）写一张“失败分类表”，每类至少写：触发条件、兜底动作、退出条件。
2. 找一个你曾经遇到的失败，补齐证据字段（sessionKey/时间/错误原文/你当时做的动作）。缺的写 Unknown。
3. 给你的用例加一个“兜底开关”：当主链路失败 N 次后自动切换备胎（N=Unknown 也行，但要写清楚你准备怎么定）。

核心问题

很多团队的自动化最终死在两件事：

1. 没有监控：坏了没人知道；
2. 监控太吵：每小时“我还活着”刷屏，大家很快把通知静音，真正异常也看不到。

这一课讲一套可落地的 cron 告警设计：“任务层有流水、通知层有门控、群里只看关键变化”。

案例（真实）

案例 A：每小时网络探测，但只在异常/提醒窗口才通知

这条 cron 的关键不是“能测速”，而是把“刷屏风险”变成显式规则。

• 证据1：sessionKey=agent:main:cron:c01564b6-bd97-4a17-9e4d-a48f311c0518:run:ad07a702-52d0-44c4-8240-148802406a97｜2026-03-04T00:58:51.203Z｜quote 摘要："仅在出现异常，或到达提醒窗口时才发送通知..."
• 证据2：同 sessionKey｜2026-03-04T00:59:20.851Z｜quote 摘要："{ "ok": true, "messageId": "4675" ... }"

案例 B：新闻监控的“24h 时窗 + 多源兜底 + 单次发送”

同一条监控既要抗 429，也要避免重复消息；用“24h 首发时窗”强制去重，是典型的产品化规则。

• 证据1：sessionKey=agent:main:cron:b3c9715e-ee3c-4036-8940-f97e48e405c3:run:f741429b-206e-4883-82fd-2586bb0e1b38｜2026-03-04T00:23:32.398Z｜quote 摘要："严格时窗规则：仅纳入过去24小时内首次发布内容。"
• 证据2：同 sessionKey｜2026-03-04T00:24:27.730Z｜quote 摘要："web_search error: ... (429)..."
• 证据3（结果回执）：sessionKey=agent:main:cron:b3c9715e-ee3c-4036-8940-f97e48e405c3｜2026-03-04T00:26:10.499Z｜quote 摘要："{ "ok": true, ... }"

失败点（监控/播报常见坑）

1. 把 cron 当“消息生产机”：每次执行都发一条“我跑完了”，最后所有人都 mute。
2. 没有分离“流水”和“播报”：没有本地日志/结构化输出，导致你只能依赖群消息追溯历史。
3. 没有“去重/时窗”：同一新闻/同一异常反复发，信噪比下降。
4. 失败不可见：任务内部失败但依然发“成功”，或者干脆不回执。

关键转折：把通知当成“产品界面”，而不是“日志 dump”

好的告警不是“信息越多越好”，而是：

• 只在需要人介入时打扰
• 一眼能看懂：是什么问题、严重吗、要做什么
• 能回溯：原始流水在本地/文件里

这也是为什么案例 A 要“异常才通知”，案例 B 要“24h 首发时窗”。

可复用 SOP：异常优先的 cron 告警设计（5 步）

1. 任务输出先落盘（机器可读）

   • 例如脚本写 jsonl/markdown 摘要。
   • Unknown：如果你当前没有落盘机制，就先标 Unknown，并把“落盘”列为下一步改造。

2. 定义通知门控（Alert Gating）

   • 规则最少三类：
     • 异常触发（error/阈值超标）
     • 提醒窗口触发（例如每天固定时间一条健康汇总）
     • 静默（其余时间不发）
   • 证据：案例 A 已明确写出“仅异常或提醒窗口才发送”。

3. 定义去重与时窗

   • 新闻/情报类：用“24h 首发”或 hash 去重（证据见案例 B）。
   • 指标类：用“跨阈值变化”去重（例如从正常→异常、异常→恢复才通知）。

4. 通知内容结构化（面向人）

   • 标题：任务名 + 状态（ok/error）
   • 关键指标：2~5 个
   • 下一步：要不要人处理？处理什么？

5. 最终只发一次（汇总式）

   • 不在中间过程刷屏；中间细节留给本地日志。

课后作业

1. 选一个你团队最想做的 cron（网络、新闻、额度、备份都行），写出你的“通知门控规则”：
   • 异常阈值是什么？
   • 提醒窗口是什么？
   • 去重键是什么？
2. 设计一条“恢复通知”：当异常恢复时才发（从 error→ok）。
3. 用一句话写清楚这条 cron 的价值：如果所有人都 mute 了它，这条系统还有意义吗？如果没有，说明你还没把“异常优先”做到位。

核心问题

当 OpenClaw 进入“长期运行 + 多 cron + 多来源抓取”的阶段，系统问题会从“功能不对”转变为“稳定性不够”：

• 网关偶发 timeout，导致排障命令也跑不动；
• 诊断日志无限增长，悄悄把磁盘打满；
• 修完问题但没回归验证，过两天又复现。

这一课讲稳定性工程的三件套：止损、抗抖、回归。

案例（真实）

案例 A：30G 诊断日志膨胀的止损修复（清理 + 关开关 + 验证）

这次事故的亮点不是“删了文件”，而是有完整闭环：量化→清理→关闭增量→验证网关运行与配置生效。

• 证据1：sessionKey=agent:main:telegram:group:-1003807921933:topic:524｜2026-03-03T12:59:28.210Z｜quote 摘要："~/.openclaw/logs/cache-trace.jsonl 达到 30G"
• 证据2：同 sessionKey｜2026-03-03T13:22:16.003Z｜quote 摘要："cacheTrace.enabled = False ..."
• 证据3：同 sessionKey｜2026-03-03T13:22:20.899Z｜quote 摘要："Gateway 在运行：running ... 配置已生效..."

案例 B：Gateway 超时抖动下，用“可用读操作”维持诊断闭环

同一排障窗口里多次出现 gateway timeout，但通过交替收集可返回的 status/list 输出，避免诊断完全阻塞。

• 证据1：sessionKey=agent:main:telegram:group:-1003807921933:topic:2319｜2026-03-02T00:29:36.229Z｜quote 摘要："Error: gateway timeout after 30000ms ..."
• 证据2：同 sessionKey｜2026-03-02T00:32:02.306Z｜quote 摘要："Error: gateway timeout after 120000ms ..."
• 证据3：同 sessionKey｜2026-03-02T00:32:09.675Z｜quote 摘要："... cron 列表里多个任务 status ok ..."

失败点（稳定性上最容易踩的坑）

1. 没有止损意识：日志膨胀是“慢性事故”，等磁盘满了才处理就晚了。
2. 把 timeout 当“再试一次”：单点命令重试会浪费窗口期；更糟的是你会误以为“系统全挂了”。
3. 修完不验证：关了开关但没确认生效；删了文件但网关没起来；最后变成“感觉修好了”。

关键转折：从“修问题”升级到“做机制”

稳定性工程的本质是机制：

• 让事故发生时可止损（磁盘/刷屏/资源占用）
• 让抖动时可继续推进（多探针、读操作兜底）
• 让修复可被证明（回归验证 + 可回滚点）

案例 A 给了一个很标准的机制闭环；案例 B 提醒我们：排障工具也会失效，所以诊断策略必须容错。

可复用 SOP：稳定性三件套（止损/抗抖/回归）

1) 止损（Damage Control）

• 量化：先确认体积/频率（例如“30G”这种量化证据）。
• 清理存量：删除/归档大文件（注意生产环境要可回滚，Unknown 的部分就标 Unknown）。
• 关闭增量源头：找到开关并关闭（证据：cacheTrace.enabled=false）。

2) 抗抖（Resilience under Jitter）

• 不依赖单一命令：当某条命令 timeout 时，换“读操作探针”继续收集状态（status/list）。
• 记录每次 timeout 的参数与时间（30s/120s 是重要线索）。
• Unknown：根因可能是资源占用/网络层/进程状态，但在证据片段里未给出结论，因此这里标 Unknown，不做推断。

3) 回归验证（Verification）

• 修复后必须做两类验证：
  1. 配置态验证：开关值是否如预期（证据：enabled=false）。
  2. 运行态验证：Gateway 是否 running、关键任务是否仍 ok（证据已给出）。
• 最好再补一条“后续巡检”来防回归（本案例 unknowns 里提到未见自动巡检证据，所以这里也是 Unknown）。

课后作业

1. 画出你当前系统的“稳定性三件套清单”：
   • 止损点：有哪些日志/缓存/输出可能无限增长？
   • 抗抖点：哪些关键命令可能 timeout？有什么替代读操作？
   • 回归点：你如何证明修复已生效？
2. 把一个你团队最近遇到的“慢性事故”（例如磁盘、重复通知、缓存膨胀）写成 10 行 Runbook：触发信号、止损动作、验证动作。
3. 加一条“Unknown 边界”训练：当你没有证据时，必须写 Unknown，并列出你要补的观测点（例如：资源占用、网关进程状态、日志增长速率）。

核心问题

当你把 OpenClaw 真正用到“每天都在跑”的强度时，瓶颈很快就不是“会不会写 prompt”，而是账号/额度/鉴权的治理：

• 多个模型账号并行使用，谁先用、谁兜底、谁已经过期？
• 一旦某个账号 401/额度耗尽，任务会不会整条链路崩掉？
• 你怎么保证“每天早上看到的结果”是可信的，而不是昨晚 cron 失败的残影？

真实案例（带证据）

案例 A：Codex 多账号额度巡检 + auth order 自动重排

• 做法：先读取 auth-profiles，预检 token；再拉 usage（wham/usage）；按规则排序；写回 openclaw models auth order set；最后发简报。
• 证据1：明确了执行逻辑与排序规则（“日剩余% + 5h剩余%”）。
  • sessionKey: agent:main:cron:d2cf6089-a0cb-4c97-a1d1-530986396d37:run:c7b058f0-0806-4776-bb3d-19baf8792a66
  • time: 2026-03-04T00:46:39.424Z
  • quote: “每天凌晨 3 点…读取…auth-profiles…调用…wham/usage…按‘日剩余% desc, 5h剩余% desc’排序…”
• 证据2：排序结果被写入并可读回（Order override 列表）。
  • sessionKey: agent:main:cron:d2cf6089-a0cb-4c97-a1d1-530986396d37:run:c7b058f0-0806-4776-bb3d-19baf8792a66
  • time: 2026-03-04T00:48:03.661Z
  • quote: “Order override: openai-codex:…@outlook.com, …”

案例 B：cron 自动调度失败后的补跑闭环

• 结论：“自动失败 ≠ 任务逻辑失效”。要把失败说清楚（时间 + 原因），然后手动补跑拿到真实结果。
• 证据1：指出“昨天凌晨自动调度失败”，状态 error，原因 fetch failed。
  • sessionKey: agent:main:telegram:group:-1003807921933:topic:4375
  • time: 1772415862224
  • quote: “昨天凌晨那次自动调度是失败的… 状态 error… 原因 fetch failed”
• 证据2：随后“重跑好了，已成功”。
  • sessionKey: agent:main:telegram:group:-1003807921933:topic:4375
  • time: 1772416092486
  • quote: “重跑好了，已成功 ✅… 任务状态 ok”

错误尝试 / 失败点（你很可能也会踩）

1. 只做“拉额度”不做“健康检查”：token 过期/401 时，usage 请求本身就会失败。
2. 只在出事后手工改顺序：这会让“调度系统”退化成“人肉值班”。
3. 改完顺序不复核：写回失败或没生效，你以为兜底在，实际下一次照样崩。
4. 混淆自动失败与逻辑失败：cron error 可能是网络抖动/超时，不代表流程不可跑。

关键转折（从“能跑”到“可治理”）

把“额度/账号”当作一等公民：

• 先做健康检查（鉴权），再做额度采样（usage），最后做策略决策（排序）。
• 每次策略更新都要有读回验证与可视化简报。
• 遇到 error 先把“失败发生在哪里”说清楚，再决定“加参数抗抖”还是“补跑出结果”。

可复用 SOP（建议直接抄到你们的团队脚本里）

目标：每日自动给出“可用账号优先级”，并在失败时可快速补跑。

1. 读取配置：auth profiles 列表（来源 Unknown，取决于你们部署路径）。
2. Token 预检：对每个 profile 做一次轻量验证（401/过期标红）。
3. 额度采样：对通过预检的账号拉 usage（短窗 + 日窗）。
4. 排序策略：
   • 主排序：日剩余% desc
   • 次排序：5h 剩余% desc
   • 账号不可用（401/采样失败）直接排到末尾或剔除
5. 写回 order：openclaw models auth order set ...
6. 立即读回：openclaw models auth order get（或等价接口）确认生效。
7. 简报输出：
   • 当前排序
   • 不可用账号清单（原因：401/采样失败/Unknown）
   • “本次是否为自动补救/手动补跑”标识
8. cron 失败处理：
   • 先从日志提取：失败时间 + 错误字符串
   • 区分：自动调度失败 vs 逻辑失败
   • 需要时手动补跑并回传“核心指标”（排序 + 需要修复账号）

课后作业

1. 把你们当前的模型调用账号列出来，做一个最小版“健康检查 + 额度采样”脚本（先不排序也行）。
2. 写下你们的排序规则（别用“凭感觉”）：至少包含一个主排序字段和一个次排序字段。
3. 设计一条简报消息模板：包含“排序 + 不可用账号 + 失败原因（若有）”。
4. 思考题：当所有账号都不可用时，你的系统应该输出什么？（建议写 Unknown 也要写清楚 Unknown 的边界）

核心问题

很多团队做自动化，最后都停在“定时跑一下，发个消息”。但真正有价值的是：每次跑完都留下可复用产物，让第二天的人/机器人能接着干。 这节课要解决的问题是：

• 如何把“目标”变成“每天夜间无人值守的行动包”？
• 如何让产物结构稳定、可迭代，而不是一次性草稿？
• 如何保证投递不刷屏、但又能让人快速读懂成果？

真实案例（带证据）

案例：Overnight Goal Autopilot（读目标说明书 → 自动产出多份行动文件 → 一次性通知）

• 证据1：任务先读取统一目标说明书（作为单一真源），再生成 4–5 个高杠杆任务。
  • sessionKey: agent:main:cron:25dc7e01-e375-484c-a331-a326a7f616c2:run:929f80cc-43fd-4995-9b65-b491d874d85d
  • time: 2026-03-03T18:00:00.116Z
  • quote: “先读取：…/memory/overnight-goals-v1.md …每天执行一次：生成今天要推进的 4-5 个高杠杆任务…”
• 证据2：产物按固定序号文件落盘（例如 01_today_plan、04_kanban 模板）。
  • sessionKey: agent:main:cron:25dc7e01-e375-484c-a331-a326a7f616c2:run:929f80cc-43fd-4995-9b65-b491d874d85d
  • time: 2026-03-03T18:00:27.240Z
  • quote: “Successfully wrote …/01_today_plan.md”
• 证据3：同一轮中写入了跟踪看板模板，说明不是只“写计划”，而是把执行载体也生成出来。
  • sessionKey: agent:main:cron:25dc7e01-e375-484c-a331-a326a7f616c2:run:929f80cc-43fd-4995-9b65-b491d874d85d
  • time: 2026-03-03T18:01:08.298Z
  • quote: “Successfully wrote …/04_job_tracking_kanban_template.md”

错误尝试 / 失败点

1. 只有“目标描述”，没有“行动颗粒度”：自动化跑完你还是不知道下一步怎么做。
2. 产物不落盘：只在消息里给你一段文字，第二天无法追溯、无法迭代。
3. 目录结构不稳定：今天写 A 路径，明天写 B 路径，后续任何工具链（备份/检索/汇总）都会崩。
4. 每个步骤都发消息：群里被刷屏，最终大家把通知关了。

关键转折

把任务从“通知型 cron”升级成“产线型 cron”，关键在两句话：

• 输入有单一真源（目标说明书）：它决定今天要产什么。
• 输出是结构化资产（文件集合）：它决定明天从哪里继续。

可复用 SOP（从 0 到 1 建一条夜间产线）

1. 定义输入文件：overnight-goals-v1.md（名称可不同，但必须唯一真源）。
2. 定义产物目录：projects/<project>/YYYY-MM-DD__nightly-push/（示例；实际路径可按团队约定）。
3. 规定文件序号与职责（建议至少 4 份）：
   • 01_today_plan.md：今日推进清单（带优先级与可交付定义）
   • 02_context.md：背景与约束（不确定写 Unknown）
   • 03_execution_notes.md：执行提示/命令/链接
   • 04_job_tracking_kanban_template.md：跟踪模板（让人能接手）
4. 生成逻辑：
   • 先把目标拆成 4–5 个高杠杆任务
   • 每个任务写清“产出物是什么”（文件/PR/报告/Unknown）
5. 写入落盘：每份文件都必须写成功后再进入下一步。
6. 通知策略：只发送一次总览消息，内容包括：
   • 本次生成了哪些文件（路径 + 一句话摘要）
   • 今日 Top 3 优先事项
   • Unknown 清单（哪些信息缺失导致无法推进）

课后作业

1. 选一个你们团队“最想推进但总推进不动”的长期目标，写成一份 1 页目标说明书（包含：为什么、范围、非目标、里程碑）。
2. 仿照 SOP 设计 4 个固定产物文件名，并写明各自的读者是谁（自己/同事/机器人）。
3. 给你的产线加一个“只发一次消息”的门控规则：什么情况下发？什么情况下沉默？
4. 思考题：如果夜间产线需要依赖外部数据源（新闻/接口），失败时你希望产物里留下什么“可继续排查”的痕迹？（答案 Unknown 也可以，但要写出 Unknown 的原因）

核心问题

团队里最常见的“能力建设”陷阱是：

• 复盘时人人都说“以后要更稳、更自动化”，但下次还是同样的坑；
• gap 清单靠主观印象维护，最后变成“谁嗓门大写谁的需求”。

这节课要建立一个可执行机制：从真实会话/执行日志里，证据化地挖出能力缺口（skill gaps），并持续写入长期库。

真实案例（带证据）

案例：会话驱动自进化（24h 信号采集 → 更新 skill-gaps.md）

• 证据1：明确扫描范围与方法：sessions_list(activeMinutes=1440) + sessions_history(limit=50)。
  • sessionKey: agent:main:cron:72b13206-d958-428d-bcd1-e32a8dd44c84
  • time: 2026-03-03T10:01:38.840Z
  • quote: “已用 sessions_list(activeMinutes=1440) 拉取过去24h活跃 session，并逐个用 sessions_history(limit=50) 扫描”
• 证据2：gap 库被真实落盘更新（不是停在口头）。
  • sessionKey: agent:main:cron:72b13206-d958-428d-bcd1-e32a8dd44c84
  • time: 2026-03-03T10:01:18.636Z
  • quote: “Successfully replaced text in …/memory/skill-gaps.md.”
• 证据3：存在“信号分类规则”文件，说明不是随便抓关键词，而是先定义口径。
  • sessionKey: agent:main:cron:72b13206-d958-428d-bcd1-e32a8dd44c84
  • time: 2026-03-03T10:00:58.715Z
  • quote: “# 信号分类规则 Agent 自进化系统通过扫描对话记录来识别能力缺口。”

错误尝试 / 失败点

1. 只在出事故时复盘：平时的小摩擦（429、fetch failed、timeout、命令不存在）没被记录，最后变成“事故突然发生”。
2. 没有信号分类规则：今天说“需要更稳定”，明天说“需要更自动化”，无法聚类、无法排序。
3. 只生成一次清单：一次性的 gap 清单很快过期；你需要“每天/每周增量更新”的节奏。
4. gap 不落盘：只在聊天里说，下一轮又从 0 开始。

关键转折

从“复盘会”转为“采集系统”，关键是两点：

• 定义信号口径：什么算 gap？什么不算？（例如：重复出现的错误字符串、手动补跑、频繁求助等）
• 用会话数据作为唯一证据来源：减少主观争论，让改进更像工程问题。

可复用 SOP（建议每周一次，或者每天轻量跑）

1. 准备规则文件 signal-rules（文件名 Unknown，可按团队习惯）：
   • 信号类型：报错类（429/fetch failed/timeout）、流程卡点类（需要人点一下）、质量类（输出被退回）等
   • 每类信号的“判定条件”与“记录字段”（至少含：sessionKey、时间、quote 摘要）
2. 拉取样本：
   • sessions_list(activeMinutes=1440) 取过去 24h 活跃会话
   • 对每个会话 sessions_history(limit=50) 扫描最近记录
3. 抽取：命中规则就写入候选 gap（含证据三元组）。
4. 去重与聚类：
   • 按“错误模式/工具/链路”聚类
   • 同类 gap 合并证据，保留最新一次 + 最典型一次
5. 写入长期库：memory/skill-gaps.md（或团队知识库），并标记：
   • 新增/已存在/已解决（Unknown：如何判定“已解决”取决于你们的回归验证机制）
6. 产出行动项：每个 gap 至少对应一个“下一步动作”（写脚本/补 SOP/加监控/加兜底）。

课后作业

1. 用你们最近一周的聊天/日志（哪怕是手工复制）做一次“信号分类”：把出现频率最高的 3 类问题列出来。
2. 给每类问题定义一个可机读的判定条件（例如包含某个错误字符串、某个工具返回 error）。
3. 做一个最小版 gap 库（markdown 就够），每条 gap 至少带 2 条证据（时间+原句摘要）。
4. 思考题：如果某类问题的证据不足（例如只出现一次），你是把它标成“待观察”，还是立即行动？写出你的规则；不确定就写 Unknown。

核心问题

工具在你自己电脑上跑通，不等于能在团队里落地。组织落地最难的不是写代码，而是：

• 协作边界：谁触发、谁停止、失败怎么兜底，避免“机器人自己聊嗨了/失控刷屏”。
• 接入验收：第三方能力（token/登录态）如果没走完验收，就会变成“装了但不能用”。
• SOP 的可执行性：规则如果写成口号（例如“注意稳定性”），对团队没有增益。

真实案例（带证据）

案例 A：多 Bot 协作稳定性规则化（trigger gate + HOLD/TIMEOUT/STOP）

• 证据1：触发门禁：只有 #task/#sync/“继续”才进入协作；否则最多回一次 HOLD。
  • sessionKey: agent:main:telegram:group:-1003894421455
  • time: 2026-02-25T10:16:47.135Z
  • quote: “只有人类发了 #task / #sync / ‘继续’，才进入任务协作…其他情况最多回一次：HOLD。”
• 证据2：超时与失败刹车：90 秒无响应 TIMEOUT；连续 3 次技术错误强制 STOP。
  • sessionKey: agent:main:telegram:group:-1003894421455
  • time: 2026-02-25T10:19:15.987Z
  • quote: “90 秒无响应 -> TIMEOUT…连续 3 次技术错误 -> 强制 STOP 并记录错误。”

案例 B：第三方技能接入的“密钥落地 + 联调验收”

• 证据1：明确卡点在 token，需要去指定页面拿 token 才能真正跑起来。
  • sessionKey: agent:main:telegram:group:-1003807921933:topic:3739
  • time: 1772212174714
  • quote: “还需要去 https://6551.io/mcp 拿两个 token 才能真正跑起来”
• 证据2：完成安全落盘与接口级验收（env 文件、权限 600、HTTP200 success=true）。
  • sessionKey: agent:main:telegram:group:-1003807921933:topic:3739
  • time: 1772295555350
  • quote: “token 写入 ~/.config/openclaw/6551.env（权限600），接口 HTTP 200、success=true”

错误尝试 / 失败点

1. 没有触发门禁：机器人会在“无任务”的聊天里继续输出，导致干扰与信任崩塌。
2. 没有刹车机制：连续报错时不停止，会形成错误循环，把群刷爆。
3. 只写‘安装成功’不做‘验收成功’：第三方技能最常见失败不是安装，而是 token/登录态没配置。
4. SOP 不可执行：写一堆原则，没人知道“下一步具体按什么命令/按什么顺序做”。

关键转折

组织落地的转折点是：

• 把“协作”抽象成状态机（触发 → 执行 → 结束/暂停），而不是聊天式自由发挥；
• 把“接入”抽象成交付物：配置文件落地 + API 级联调证据，而不是“我感觉可以”。

可复用 SOP（团队推广模板）

目标：任何人都能用同一套规则把一个自动化能力推广到团队。

SOP-1：协作协议（防失控）

1. Trigger Gate：仅当消息包含 #task / #sync / 继续 才启动流程。
2. 非触发场景：最多回复一次 HOLD，然后停止。
3. TIMEOUT：90 秒无响应则暂停（标记为 TIMEOUT）。
4. FAIL-STOP：连续 3 次技术错误，强制 STOP，并记录最后一次错误摘要。
5. 交付即停：交付后一次确认就结束（Stop），避免链路拉长。

SOP-2：第三方能力接入（从“可安装”到“可用”）

1. 安装：能自动化就自动化（但不要把“安装成功”当终点）。
2. 缺口定位：如果不可用，优先检查 token/登录态。
3. 凭据落地：写入 ~/.config/openclaw/<service>.env，权限 600。
4. API 级验收：必须有“HTTP 200 + success=true”（或等价成功信号）。
5. 业务级验收：用 1 个真实场景跑通（场景 Unknown 也要写清为什么 Unknown）。
6. 文档化：把“拿 token 的入口 + env 文件名 + 验收信号”写进团队 SOP。

课后作业

1. 选一个你们团队正在用的机器人/脚本，给它补上 4 个状态：触发门禁、HOLD、TIMEOUT、FAIL-STOP，并写成一页 SOP。
2. 选一个需要 token 的第三方服务，按“落盘 + API 验收 + 业务验收”跑一遍，把证据（成功信号）贴进文档。
3. 讨论题：你们团队更适合“默认沉默，只有异常才通知”，还是“固定窗口播报”？写出理由；不确定就写 Unknown。

写作规则：所有案例与结论必须来自 source_usecases.json 的证据；正文课件里会进一步补齐 sessionKey / 时间 / quote 锚点。

你将学到什么（课程总纲）

这套课不是教“怎么用一个工具”，而是教你把 OpenClaw 当成一套可生产化的自动化系统来落地：

• 遇到失败（429 / fetch failed / private IP blocked / 网关超时）时不崩盘：有分级、有退避、有兜底。
• 定时任务（cron）不是“每小时发一条”，而是“异常优先，不刷屏”的播报体系。
• 运维与稳定性不是玄学：用止损步骤 + 回归验证把风险关住。
• 从单点脚本到可持续产线：多账号额度重排、夜间无人值守推进、会话驱动自进化。

课程结构（cat-cafe 风格：Part 0~4）

Part 0｜从“能跑”到“可复用”：用例工程方法

• Lesson 0.1：什么叫“可复用用例”？从一次成功到一套模板
• Lesson 0.2：证据驱动：如何用 sessionKey/time/quote 给结论上“钢印”

Part 1｜失败是主线：把常见故障变成可自动降级的 SOP

• Lesson 1.1：检索链路三连击：429 + fetch failed + 本地命令错误
• Lesson 1.2：web_fetch 被私网 IP 策略拦截：如何无痛切换抓取链路
• Lesson 1.3：FakeIP 环境下的诊断纠偏：别再被 dig/nslookup 带沟里

Part 2｜监控与播报：做“异常优先、不刷屏”的 cron 体系

• Lesson 2.1：每小时巡检不等于每小时刷屏：通知门禁怎么做
• Lesson 2.2：cron 失败后的快速复盘 + 手动补跑闭环
• Lesson 2.3：双目录 Git 自动备份：失败可见化、结果可追踪

Part 3｜生产化与稳定性工程：事故、可观测、回归验证

• Lesson 3.1：30G 诊断日志膨胀：止损三步法（量化→清理→关增量）
• Lesson 3.2：Gateway timeout 抖动：用“多命令探针”维持诊断闭环
• Lesson 3.3：第三方技能上线：密钥落地 + 联调验收的标准流程

Part 4｜进阶：上下文工程、资源治理、组织落地

• Lesson 4.1：多账号额度巡检与 auth order 自动重排：把资源治理产品化
• Lesson 4.2：Overnight Goal Autopilot：夜间无人值守也能产出“行动包”
• Lesson 4.3：会话驱动自进化：24h 信号采集并更新 skill-gaps
• Lesson 4.4：多 Bot 协作稳定性：HOLD/TIMEOUT/STOP 防失控
• Lesson 4.5：争议信息如何定性：实测 + 官方规则页的双证据策略

学习方式建议

• 每节课只解决一个核心问题，并给出可复用 SOP。
• 建议按 Part 顺序推进；但如果你正在救火，可以直接跳到对应 Lesson。

素材来源（唯一真源）

• materials/source_usecases.json

目的：这是“总纲 + 目录 + 证据来源映射”。不写长正文；正文里会把每条映射展开为：真实场景 → 失败点 → 关键转折 → SOP → 作业，并附 sessionKey/time/quote。

Part 0｜从“能跑”到“可复用”：用例工程方法

Lesson 0.1｜什么叫“可复用用例”？从一次成功到一套模板

• 核心问题：为什么“跑通一次”不等于“可复用”？怎样把成功沉淀为模板（reuse_template）？
• 你会产出的东西：一份用例卡（Problem / Workflow / Outcome / Reuse template / Unknowns / Tags）。
• 证据来源映射（用例标题）：
  1. Codex 多账号额度巡检与 auth order 自动重排
  2. 每小时 Stash 网络探测 + 异常才通知
  3. 30G 诊断日志膨胀的止损修复：删文件 + 关 cacheTrace + 回归验证

Lesson 0.2｜证据驱动：如何用 sessionKey/time/quote 给结论上“钢印”

• 核心问题：团队分享里，如何避免“我感觉/应该是”？怎样把结论锚定到可回放的证据？
• 你会产出的东西：一份“证据锚点”写作规范（每个关键结论 ≥1 个 quote）。
• 证据来源映射：
  1. 会话驱动自进化：24h 信号采集并更新 skill-gaps
  2. 争议信息用‘实测 + 官方规则页’双证据定性

Part 1｜失败是主线：把常见故障变成可自动降级的 SOP

Lesson 1.1｜检索链路三连击：429 + fetch failed + 本地命令错误

• 核心问题：当检索层（429/抓取失败）和执行层（python 不存在）同时炸时，如何让任务仍能“按时交付”？
• 你会产出的东西：一份“分级故障处置表”（检索失败→DDG 兜底；命令失败→解释器修正）。
• 证据来源映射：
  1. Brave 429 + fetch failed + python 命令错误的多故障串联修复
  2. AI 公司动态监控：检索退避 + 多源兜底 + 24h 时窗

Lesson 1.2｜web_fetch 被私网 IP 策略拦截：如何无痛切换抓取链路

• 核心问题：当 web_fetch 报 “Blocked: resolves to private/internal/special-use IP address” 时，怎样保持任务不断线，并且让降级路径可复用？
• 你会产出的东西：一份“抓取链路路由器”SOP（web_fetch → browser 抓取 → web_search 补证 → 原投递链路不变）。
• 证据来源映射：
  1. web_fetch 被私网 IP 策略拦截后，切换抓取链路完成定时播报
  2. 同类私网拦截在另一条 cron 复现，验证 fallback 可复用
  3. AI 公司动态监控：检索退避 + 多源兜底 + 24h 时窗

Lesson 1.3｜FakeIP 环境下的诊断纠偏：别再被 dig/nslookup 带沟里

• 核心问题：为什么在代理 FakeIP 环境下，DNS 结果可能是“假象”？如何建立“真实访问链路优先”的排障规则？
• 你会产出的东西：一份团队级排障 SOP（禁止单看 DNS；必须用浏览器实测/代理内链路复测）。
• 证据来源映射：
  1. FakeIP 网络环境下的诊断纠偏流程

Part 2｜监控与播报：做“异常优先、不刷屏”的 cron 体系

Lesson 2.1｜每小时巡检不等于每小时刷屏：通知门禁怎么做

• 核心问题：如何在“持续监控”和“群里不被刷屏”之间做工程化平衡？
• 你会产出的东西：一份“通知门禁”设计（异常才发 + 提醒窗口 + threadId 归档）。
• 证据来源映射：
  1. 每小时 Stash 网络探测 + 异常才通知
  2. AI 公司动态监控：检索退避 + 多源兜底 + 24h 时窗

Lesson 2.2｜cron 失败后的快速复盘 + 手动补跑闭环

• 核心问题：cron 失败时，怎样快速回答三个问题：失败发生在何时？为什么失败？现在如何立刻恢复可信结果？
• 你会产出的东西：一份“失败复盘模板”（时间窗口 + 错误原因 + 抗抖参数建议 + 立刻补跑回执）。
• 证据来源映射：
  1. Cron任务异常后快速复盘 + 手动补跑闭环
  2. Gateway 超时抖动场景下，用可用读操作维持诊断闭环

Lesson 2.3｜双目录 Git 自动备份：失败可见化、结果可追踪

• 核心问题：当要备份两个关键目录时，如何保证“谁成功谁失败一眼可见”，并且保留可追踪的 commit 证据？
• 你会产出的东西：一份“多目标任务统一汇总格式”（成功/失败/无变更 + 原因 + hash）。
• 证据来源映射：
  1. 双目录 Git 自动备份 + 失败可见化播报

Part 3｜生产化与稳定性工程：事故、可观测、回归验证

Lesson 3.1｜30G 诊断日志膨胀：止损三步法（量化→清理→关增量）

• 核心问题：当诊断日志膨胀到几十 GB，如何“立刻止血 + 避免复发 + 不引入新事故”？
• 你会产出的东西：事故止损 Runbook（确认体积→停/不停网关策略→清理→关闭开关→回归验证）。
• 证据来源映射：
  1. 30G 诊断日志膨胀的止损修复：删文件 + 关 cacheTrace + 回归验证

Lesson 3.2｜Gateway timeout 抖动：用“多命令探针”维持诊断闭环

• 核心问题：当网关超时导致部分命令不可用时，怎样用“可返回的读操作”拼出最小可行诊断？
• 你会产出的东西：一份“多命令探针”策略清单（status/list 等替代单点命令依赖）。
• 证据来源映射：
  1. Gateway 超时抖动场景下，用可用读操作维持诊断闭环
  2. Cron任务异常后快速复盘 + 手动补跑闭环

Lesson 3.3｜第三方技能上线：密钥落地 + 联调验收的标准流程

• 核心问题：为什么“装上了”不等于“能用”？如何把 token/登录态这个最大不确定性，变成可审计、可验证的上线流程？
• 你会产出的东西：一份技能上线 SOP（安装→缺口定位→安全写 env→API 级验收→业务级实测）。
• 证据来源映射：
  1. 第三方技能接入的‘密钥落地 + 联调验收’标准流程

Part 4｜进阶：上下文工程、资源治理、组织落地

Lesson 4.1｜多账号额度巡检与 auth order 自动重排：把资源治理产品化

• 核心问题：多账号并行时，如何每天自动检查健康度与额度，并把排序规则“显式化 + 可复核”？
• 你会产出的东西：一份资源治理 SOP（健康检查→额度采集→排序→set→get 复核→简报）。
• 证据来源映射：
  1. Codex 多账号额度巡检与 auth order 自动重排
  2. Cron任务异常后快速复盘 + 手动补跑闭环

Lesson 4.2｜Overnight Goal Autopilot：夜间无人值守也能产出“行动包”

• 核心问题：怎么让“长期目标”不再停留在口号，而是每天自动产出可执行文档，并形成连续迭代节奏？
• 你会产出的东西：一份“目标说明书驱动”的产线结构（固定输入→固定输出目录→一次性通知）。
• 证据来源映射：
  1. Overnight Goal Autopilot：读目标文档后自动产出行动包
  2. 长期项目产物目录重构（根目录减负）

Lesson 4.3｜会话驱动自进化：24h 信号采集并更新 skill-gaps

• 核心问题：如何不靠主观印象，而是从真实会话里持续抽取能力缺口，并形成长期改进库？
• 你会产出的东西：一套“信号规则 + 扫描范围 + 去重写入”的自进化管道。
• 证据来源映射：
  1. 会话驱动自进化：24h 信号采集并更新 skill-gaps

Lesson 4.4｜多 Bot 协作稳定性：HOLD/TIMEOUT/STOP 防失控

• 核心问题：多 Agent/多 Bot 协作时，如何防止上下文漂移、无触发继续、错误循环与刷屏？
• 你会产出的东西：一份可执行协作协议（trigger gate + hold-once + timeout + fail-stop）。
• 证据来源映射：
  1. 多 Bot 协作稳定性规则化：HOLD/TIMEOUT/STOP 防失控

Lesson 4.5｜争议信息如何定性：实测 + 官方规则页的双证据策略

• 核心问题：当外部说法冲突时，怎样用“站点实测 + 官方规则文本”把结论做实，并明确不确定性边界？
• 你会产出的东西：一份信息核验 SOP（入口实测→规则页抓取→冲突处理→输出可信口径）。
• 证据来源映射：
  1. 争议信息用‘实测 + 官方规则页’双证据定性

附：可选加餐（如果需要扩展课程）

这些用例可以作为“课后拓展/实操挑战”，不一定进主线。

1. AI 公司动态监控：检索退避 + 多源兜底 + 24h 时窗（偏完整产线）
2. 面向育儿场景的日报模板化输出（偏内容模板工程）
3. web_fetch 被私网 IP 策略拦截后，切换抓取链路完成定时播报（偏抓取兜底）