场景演示

你每天上班，打开电脑，第一件事是什么？

大概率是：打开邮箱看看有没有紧急邮件、打开飞书看看有没有人 @ 你、打开钉钉看看有没有客户消息、打开日历看看今天有什么安排……

这一套「检查动作」，每天至少消耗 15-30 分钟。而且往往是：并没有紧急的事，但你不放心，必须看。

真正的痛点不是「没有信息」，而是「你不知道哪些信息需要你立即处理」。

今天介绍一个完全不同的思路：让 AI 不是等你来问，而是主动预判你接下来要做什么，并在最佳时机提醒你或直接帮你处理。

这个场景，OpenClaw 可以做到。

Step by Step：搭建 AI 任务预判流

整体架构


数据源（邮件/飞书/日历/文件）
    ↓
上下文采集 Agent（定时）
    ↓
意图预判 Agent（分析 + 打标签）
    ↓
行动决策 Agent（决定：推送给谁 / 直接处理 / 静默归档）
    ↓
执行（飞书通知 / 日历创建 / 草稿生成 / 自动回复）

三个 Agent 形成一个闭环，不需要你介入每个环节，只需要最后确认或调整。

Step 1：定义你的「预判上下文」

任务预判的前提是定义哪些信号值得关注。你可以维护一张「任务预判配置表」：

信号类型	数据来源	预判动作
客户邮件含「紧急」「求助」关键词	Gmail / 飞书邮箱	立即飞书通知 + 生成草稿
飞书被 @ 且含「请确认」「待审批」	飞书消息	创建待办 + 推送给你
日历显示「30分钟后有会议」	Google Calendar / 飞书日历	自动准备会议议程草稿
文件被共享到云盘（特定目录）	飞书云盘 / Google Drive	读取摘要 + 判断是否需要行动
股票/业务数据触发阈值	API / Bitable	推送摘要报告

关键是：让 OpenClaw 知道「什么信号对应什么动作」，而不是让你自己去判断。

Step 2：构建上下文采集 Agent

这个 Agent 的职责是定时抓取各数据源，汇总成统一上下文格式，不用 AI 判断，只管采集：


采集脚本（Python，每15分钟跑一次）：
  - 读取飞书未读消息（关键词过滤）
  - 读取日历接下来的2个事件
  - 读取 Gmail 收件箱（只看未读 + 重要标记）
  - 读取指定飞书云盘目录的新文件列表
  ↓
输出：统一 JSON 格式的「上下文快照」

OpenClaw 的 subagents 功能可以让这个采集 Agent 在后台静默运行，不打扰你。

Step 3：构建意图预判 Agent

这个是核心大脑。把上下文快照丢给它，让它判断：

「基于以上上下文，用户今天最可能需要处理哪三件事？」

提示词参考（可直接复制）：


## 角色
你是一个任务预判助手。你的任务是根据用户当前的上下文快照，
判断用户今天最需要优先处理的事项。

## 输入
{context_snapshot}  # 包含：飞书未读消息、日历事件、邮件摘要、云盘新文件

## 判断标准
1. 紧急性：哪些事项含有时间压力（deadline临近、对方在等回复）
2. 重要性：哪些事项与用户核心目标强相关
3. 可执行性：哪些事项现在就可以开始做

## 输出要求
按「紧急-重要」矩阵分类，给出：
- 🔴 立即处理（2小时内必须响应）
- 🟡 今天处理（可排入日程）
- 🟢 静默归档（暂不需要行动）

对每个事项，给出：
- 事项描述
- 触发信号来源
- 建议的下一步动作（具体，不模糊）

Step 4：构建行动决策 Agent

预判结果出来之后，这个 Agent 负责匹配动作：

事项类型	自动动作
需要你确认	飞书卡片推送，等待你点「确认」或「推迟」
需要你回复	生成回复草稿，飞书发给你，你修改后发送
需要你准备	自动生成议程/摘要，飞书通知你「已就绪」
静默归档	记录到 Bitable，不打扰你

关键设计：人永远是最后确认者，AI 做预判和草稿，不做不可逆的动作。

Step 5：用定时任务串联整个流程

使用 OpenClaw 的 cron 能力，把整个流水线串联起来：


# 每小时运行一次预判流
cron: "0 * * * *"  →  触发上下文采集 → 预判 Agent → 行动决策 → 推送

# 每天早上8:30推送「今日预判摘要」
cron: "30 8 * * *" →  基于最新上下文生成「今日行动建议」→ 飞书卡片推送

这样你每天早上打开手机，看到的不是一堆未读消息，而是AI 已经帮你整理好的「今日行动清单」。

可复制提示词

每日预判摘要提示词


你是用户的「任务预判助手」。以下是该用户当前的上下文快照：

{context}

请根据以上信息，生成一份「今日行动建议」，格式如下：

## 🔴 立即处理（2小时内）
1. [事项] | 来源：[飞书/邮件/日历] | 下一步：[具体动作]
2. ...

## 🟡 今日处理
1. [事项] | 来源：[...] | 下一步：[...]
2. ...

## 🟢 已静默归档
- [事项] → 归档原因：...

请确保「立即处理」不超过3条，「今日处理」不超过5条。
只输出真正的行动项，不要输出废话。

新文件预判提示词


一个文件刚被共享到 {directory_path}：
- 文件名：{filename}
- 共享时间：{timestamp}
- 共享者：{sharer}

请判断：
1. 这个文件是否需要用户立即查看？（是/否）
2. 如果是，预计用户需要花多少时间处理？
3. 用户可能的下一步动作是什么？

回答尽量简洁，1-3句话。

使用的 Skills

Skill	用途
`tavily-search` / `multi-search-engine`	搜索背景知识，持续优化预判规则
`subagents`	并行运行采集、预判、决策三个 Agent
`feishu-bitable`	记录预判日志，评估预判准确率
`feishu_chat`	推送预判结果和行动卡片
`halo-backend-publisher`	将预判流程文档化并发布
飞书日历 API / Gmail API	数据源采集
`browser-automation`	定时抓取需要登录的数据源

价值与注意事项

核心价值

节省「检查成本」：不再需要手动逐个 app 检查，AI 帮你过滤噪音
减少遗漏：人在疲劳时容易漏掉重要信息，AI 不会
从被动到主动：你的工作流从「被消息推着走」变成「你决定先做什么」

注意事项

预判准确率需要磨合：前两周可能会推送一些你根本不关心的内容。每次修正时，告诉 AI 「这条不需要」或「这条优先级不对」，让它学习你的偏好。

数据源接入是关键：如果数据源接口不稳定，整个预判流就会断。建议先从 1-2 个数据源起步，等稳定后再扩展。

不要让预判变成新的焦虑源：如果推送太频繁，反而增加了干扰。建议「立即处理」类最多 3 条，且只在真正有需要时才推送。

隐私边界：预判流会读取你的邮件、飞书消息、日历，确保这个流程只在你的个人设备或可信环境中运行，不要开放给第三方。

定期复盘预判效果：每周看一次预判日志，统计「推送了 → 你实际处理了」的比例，持续优化判断标准。

总结：任务预判流的核心思路是——让 AI 替你做「今天有哪些事需要处理」的判断，而不是让你自己去翻邮件、翻消息、翻日历找出来。

当这套流程跑顺之后，你会发现每天的「 inbox zero 」不再是一个苦苦追求的目标，而是一个自然的结果。