scheduled-report（预定报告）

定时任务编排 Skill

执行模式

• 强模型（Claude Opus/Sonnet, GPT-4o/5）：遵循"原则"段落，自行决定实现细节
• 标准模型（Qwen, DeepSeek, Llama）：严格按"模板"段落执行，使用提供的代码块，不要自行改写

如果你不确定自己属于哪个类别，请按"标准模型"模式执行。

定位

本 Skill 是一个编排层，职责是：

1. 录制：从当前对话中提取用户已完成的分析步骤
2. 打包：将分析步骤组装为自包含的、可独立执行的 prompt
3. 调度：通过 openclaw cron add 创建定时任务

它不负责定义分析逻辑本身。异常检测怎么做、归因怎么跑、阈值怎么设——这些是分析类 Skill（metric-query、metric-attribution 等）的职责。本 Skill 只是忠实地把对话中发生过的分析过程"录"下来。

与分析类 Skill 的关系

用户在对话中完成分析（分析类 Skill 各司其职）
     │
     │  metric-query      → 查指标数据
     │  metric-attribution → 归因分析
     │  dataset-detail-query → 明细查询
     │
     ▼
用户说"帮我做成定时任务"
     │
     ▼
本 Skill 介入（编排层）
     │
     │  Step 1: 提取对话中的分析步骤
     │  Step 2: 整理为配置大纲
     │  Step 3: 用户确认
     │  Step 4: 组装自包含 Prompt
     │  Step 5: openclaw cron add
     │
     ▼
定时任务创建完成，未来按 cron 自动重放

Step 1：提取对话中的分析步骤

回顾当前对话的全部历史，原样提取用户实际执行过的每一个分析步骤。

1.1 需要提取的信息

逐条扫描对话历史，找到所有执行过的分析操作，记录：

指标查询（metric-query）：

• 实际查询的请求参数（metrics、dimensions、timeConstraint、filters 等——这是未来重放的基础）
• metrics 数组中的指标名
• dimensions、filters、resultFilters、timeConstraint
• metricDefinitions（如有）
• 用户对查询结果的解读和关注点

归因分析（metric-attribution）：

• 归因的目标指标和对比基准
• 因子拆解公式
• 下钻维度和路径
• 执行过的全部查询

明细查询（dataset-detail-query）：

• 数据集名称、查询字段、筛选排序条件

用户的分析判断：

• 用户对数据的结论（"这个渠道有问题""这几个品牌表现不错"）
• 用户在对话中设定的阈值或标准（"跌超过 15% 就算异常"）
• 用户要求的输出格式偏好

1.2 提取原则

忠实记录，不添加：只提取对话中实际做过的事，不自行添加用户没要求的分析步骤。

保留精确参数：metricName、dimName、filters 值必须原样保留，不能用展示名替换代码名。

标注时间语义：记录每个 timeConstraint 的业务含义（"上月""近30天"），后续需要将绝对时间转换为 NOW() 相对时间。

Step 2：整理为配置大纲

将提取的步骤整理为结构化的配置，展示给用户确认。

2.1 配置大纲模板

📋 定时任务配置草案

任务名称：[基于分析内容自动命名，如"销售业绩周报"、"渠道异常日巡检"]

📊 分析步骤：
  1. [步骤1描述]（如：查询各渠道销售额及环比变化）
  2. [步骤2描述]（如：对销售额做归因分析，下钻到品牌维度）
  3. [步骤3描述]（如：检查异常品牌的明细数据）
  ...

⏰ 建议执行频率：[频率]
   建议执行时间：[时间]

📄 输出格式：[与对话中的分析输出格式一致]

2.2 执行频率推荐

从对话中的 timeConstraint 推断合理的执行频率：

2.3 时间范围转换

对话中的绝对时间必须转换为 NOW() 相对时间：

• "2025-12-01" → DATEADD(DateTrunc(NOW(), "MONTH"), -1, "MONTH")（上月）
• "2025-12-15" → DATEADD(DateTrunc(NOW(), "DAY"), -1, "DAY")（昨天）
• 如果对话中已经用了 NOW()，直接保留

Step 3：用户确认/调整

将配置草案展示给用户，通过对话确认。

以上是我根据咱们刚才的分析整理出的定时任务配置。

请确认：
1. 分析步骤是否完整？需要增减吗？
2. 执行频率建议为 {频率}，合适吗？
3. 还有其他需要调整的地方吗？

没问题的话我就创建定时任务了。

处理原则：

• 用户说"可以""就按刚才的来" → 全部确认，进入 Step 4
• 用户提出修改 → 调整后重新展示
• 用户要求增加新步骤 → 引导用户先在当前对话中把这个分析做一遍，做完后再提取纳入配置。不要凭空编造分析步骤

Step 4：组装 Prompt

将确认后的配置生成一个完全自包含的 prompt，用于 openclaw cron add --agent-turn。

4.1 核心原则

完全自包含：这个 prompt 将在未来的独立会话中执行，无法访问当前对话。所有信息必须写入 prompt。

忠实重放：prompt 的分析步骤应与用户在对话中做过的步骤一一对应，不添加额外步骤。

使用相对时间：所有 timeConstraint 中的绝对日期必须替换为 NOW() 表达。

委派 metric-query Skill：所有数据查询通过 metric-query Skill 执行，不直接调用 Gateway API，确保查询逻辑的可维护性和一致性。

4.2 Prompt 模板

你是一个数据分析助手，负责执行定期分析任务。请严格按照以下步骤执行。

## 任务信息
- 任务名称：{名称}
- 执行周期：{周报/月报/日报}
- 分析时间范围：{相对时间描述}

## 执行步骤

### 步骤 1：{步骤描述}
{该步骤的完整指令——直接从对话中提取，替换时间为 NOW()}

使用 metric-query Skill 执行以下查询：
{查询意图的自然语言描述}

查询参数参考：
{完整请求体 JSON，timeConstraint 使用 NOW()}

{对查询结果的分析指令——与用户在对话中的分析方式一致}

### 步骤 2：{下一步骤}
{同上格式}

...

## 错误处理
- 如果某个查询返回错误，记录错误信息并继续执行下一步
- 如果数据为空，在输出中标注"本期暂无数据"

## 输出格式
{与用户在对话中看到的分析输出格式一致}

生成报告后保存为 Markdown 文件，文件名格式：{任务名称}_{YYYY-MM-DD}.md

4.3 Prompt 自检清单

组装完成后逐项检查：

1. ✅ 所有 timeConstraint 使用 NOW()，无硬编码日期
2. ✅ 所有 metricName / dimName 使用代码名称，非展示名
3. ✅ metricDefinitions 中每个 key 都在 metrics 数组中
4. ✅ 所有数据查询通过 metric-query Skill 执行，未直接调用 Gateway API
5. ✅ prompt 中无"刚才""上面提到的"等依赖对话上下文的表达
6. ✅ 分析步骤与用户在对话中实际做过的步骤一致，无凭空添加

Step 5：创建定时任务

5.1 命令格式

openclaw cron add --name "<任务名称>" --cron "<Cron表达式>" --agent-turn "<prompt>"

所有定时分析任务都属于复杂任务，必须使用 --agent-turn（触发 Agent 多步执行），不可使用 --system-event（仅适用于简短一次性指令）。

5.2 参数映射

5.3 Prompt 过长时的处理

如果 prompt 过长导致命令行传参困难，先将 prompt 写入临时文件再传入：

# 先写入文件
cat > /tmp/task_prompt.txt << 'PROMPT_EOF'
{完整 prompt 内容}
PROMPT_EOF

# 再创建任务
openclaw cron add --name "销售业绩周报" --cron "0 9 * * 1" --agent-turn "$(cat /tmp/task_prompt.txt)"

5.4 创建后确认

✅ 定时任务已创建！

📋 任务名称：{name}
📝 任务内容：{简要描述，1-2句话}
⏰ 执行频率：{频率描述}
📌 状态：已启用

管理命令：
- 查看任务：openclaw cron list
- 暂停任务：openclaw cron disable --name "{name}"
- 删除任务：openclaw cron remove --name "{name}"

边界场景处理

对话中没有分析历史（重要——高频场景）

用户在没有前置分析的情况下直接下达定时任务需求，如"帮我每周监控一下库存的健康状况""帮我做个销售周报"。

处理原则：主动引导用户完成一轮分析，分析完成后自动衔接定时任务创建，整个过程是连贯的，不需要用户再说一遍"帮我做成定时任务"。

流程如下：

用户："帮我每周监控一下库存的健康状况"
  │
  ▼
本 Skill 触发 → Step 1 扫描对话 → 无分析历史
  │
  ▼
进入"引导分析"模式：
  │
  ├→ 1. 先记住用户的定时任务意图（"每周""监控""库存健康"）
  │
  ├→ 2. 引导用户明确分析内容：
  │     "我来帮您搭建这个定时巡检任务。
  │      我们先一起确定要监控哪些指标、怎么算异常，
  │      我帮您跑一遍看看效果，然后直接创建定时任务。"
  │
  ├→ 3. 通过 Gateway 搜索相关指标，展示给用户选择
  │     （调用 metric-query 等分析 Skill 的能力）
  │
  ├→ 4. 用户选定后，实际执行一轮完整分析
  │     - 查数据、看结果
  │     - 和用户讨论什么算异常、关注哪些维度
  │     - 按用户要求调整分析逻辑
  │
  ├→ 5. 分析完成后，对话中已有完整的分析记录
  │
  ▼
自动衔接 Step 1-5（不需要用户再说一遍）：
  "好的，刚才的分析流程我已经整理好了。确认一下配置，
   我就帮您创建每周自动执行的任务。"

关键细节：

• 在引导分析的过程中，始终记住用户的最终目的是创建定时任务，不要做完分析就结束了
• 引导分析时调用的是其他分析 Skill（metric-query、metric-attribution 等）的能力，本 Skill 不自行实现分析逻辑
• 分析完成后，自动进入 Step 1 提取流程，不要等用户再次触发
• 从用户原始需求中提取的信息（频率"每周"、领域"库存健康"）在后续 Step 2 中直接使用，不需要重复询问

对话中有多个不相关的分析

1. 列出检测到的分析主题
2. 让用户选择：全部放入一个任务？还是拆成多个任务？

时间范围不统一

1. 标注每个步骤的时间范围
2. 让用户确认是否统一调整

用户想增加对话中没做过的步骤

用户在 Step 3 确认时说"再加一个XX分析"：

1. 不要凭空编造分析步骤
2. 引导用户先在当前对话中把这个分析做一遍
3. 做完后更新配置，重新走 Step 2-3

常见错误模式

❌ Prompt 中使用了绝对日期："2026-03-01" 这样的硬编码日期必须替换为 NOW() 相对时间。

❌ Prompt 引用了当前对话上下文：写了"如上所述""刚才分析的"。未来执行时没有当前对话，prompt 必须自包含。

❌ 未委派 metric-query Skill 查数，而是直接在 prompt 中写了 API 调用：所有 Gateway API 调用都应通过 metric-query Skill 执行，prompt 中应该是查询意图和参数说明，而不是 curl 命令。

❌ 没让用户确认就创建：跳过 Step 3 直接创建任务。

❌ 指标名/维度名不精确：使用展示名而非 metricName / dimName。

❌ 临时指标未注册：metricDefinitions 的 key 未出现在 metrics 数组中。

❌ 使用 --system-event 而非 --agent-turn：分析任务是多步复杂任务，必须用 --agent-turn。

❌ 凭空添加分析步骤：用户只在对话中做了查询和环比分析，prompt 里却额外加了归因分析、趋势预测等用户没做过的步骤。本 Skill 的职责是"录制重放"，不是"自作主张扩展"。

❌ Prompt 转义错误：--agent-turn 的 prompt 含双引号等特殊字符未正确转义。建议将 prompt 先写入文件再用 $(cat file) 传入。