OpenClaw 能做什么：先看任务，不看功能列表
OpenClaw 官方展示了整理邮箱、发送邮件、管理日历、处理航班和值守后台任务等案例。真正落地时，问题不是“它理论上能做多少”，而是哪个任务值得交给一个长期运行、拥有工具权限的 Agent。
一个适合先做的场景通常同时满足四个条件：
- 高频： 每周反复发生，节省的时间能够累计。
- 结构化： 输入、步骤和交付物大体稳定。
- 可验证： 人能快速判断结果是否正确。
- 可恢复： 失败后可以停止、重试或回滚，不造成不可逆损失。
只满足“看起来很酷”的场景，不应排在前面。
10 个场景的价值与风险排序
| 场景 | 适合交付的结果 | 初始权限 | 主要风险 | 建议顺序 |
|---|---|---|---|---|
| 1. 每日资料摘要 | 带来源的要点与待办 | 只读 | 摘要遗漏、来源失真 | 1 |
| 2. 会议准备 | 议程、背景、问题清单 | 只读 | 使用过期资料 | 2 |
| 3. 邮箱初筛 | 分类、优先级、回复草稿 | 只读 + 草稿 | 误判紧急程度、泄露邮件内容 | 3 |
| 4. 日历整理 | 冲突清单、时间建议 | 只读 + 建议 | 错改事件、忽略时区 | 4 |
| 5. 周报与复盘 | 从记录生成结构化周报 | 只读 | 把推测写成事实 | 5 |
| 6. 浏览器取数 | 指定页面的数据与证据 | 隔离浏览器 | 登录失效、页面变化、误操作 | 6 |
| 7. 消息转任务 | 待办、负责人、截止时间 | 读取指定渠道 | 把闲聊误识别为承诺 | 7 |
| 8. 固定提醒与追踪 | 到期提醒、状态汇总 | 定时任务 | 重复通知、时区错误、任务失控 | 8 |
| 9. 团队共享流程 | 统一模板、检查和审批 | 受限写入 | 权限混用、责任不清 | 9 |
| 10. 外部执行操作 | 发送、发布、修改系统 | 高权限 | 不可逆变更和凭据风险 | 10 |
排序不是能力上限，而是风险控制顺序。先让 Agent 可靠地“读、整理、给建议”，再逐渐进入“写草稿、等待确认”，最后才考虑自动执行。
第一阶段：只读任务最容易证明价值
场景 1：每日资料摘要
给 OpenClaw 一组固定来源，让它在指定时间收集更新，保留链接，区分事实、判断和待确认信息。成功标准不是字数，而是你能在三分钟内看完并决定下一步。
场景 2：会议准备
会前读取议程、上次纪要和项目资料，输出背景、未决问题和需要确认的三件事。不要让它凭记忆补齐缺失信息；没有来源的内容应明确标记为待确认。
场景 3：周报与复盘
从每日记录、提交或任务状态中整理周报，要求每条成果能回到原始证据。Agent 可以帮助压缩信息，但不应该替你虚构进度。
第二阶段：生成草稿，人来批准
邮箱和日历很高频，也最容易因为权限过大出问题。推荐采用下面的递进方式：
- 只读取指定文件夹或日历。
- 输出分类、冲突和建议，不做修改。
- 生成回复或事件变更草稿。
- 人工确认后才发送或保存。
- 记录执行结果，失败时停止，不自动扩大范围重试。
这种流程看起来比“全自动”慢一步，却更适合建立真实信任。经过一段时间，你还能从审批记录中发现哪些规则稳定、哪些仍需要人判断。
第三阶段：浏览器、渠道与定时任务
OpenClaw 可以使用独立的受控浏览器，也可以在明确选择后连接真实登录会话。优先使用隔离浏览器完成公开网页或测试账号任务；只有必须使用已有登录态时，才接入个人浏览器，并限制站点和操作范围。
定时任务由 Gateway 调度，因此需要考虑：Gateway 是否持续运行、时区是否正确、任务超时后如何停止、重复执行是否会产生副作用。不要把普通提醒写进记忆文件后期待它准时触发，固定时间任务应使用调度能力。
用任务卡定义首个试点
选择一个场景后，先写任务卡，再配置工具：
任务：每个工作日 17:30 生成项目摘要
允许读取：指定项目目录中的 Markdown 和任务导出文件
禁止读取：凭据目录、个人聊天和其他项目
交付物：5 条进展、3 个阻塞、次日 3 个优先事项
事实规则：每条进展必须附文件或任务来源
审批点：只生成草稿，不发送到群聊
失败处理：来源缺失或格式变化时停止并列出缺口
成功指标：人工修改少于 20%，阅读与整理时间减少一半这张卡片比一句“帮我做项目助理”更容易测试，也能直接转化为 Skill、定时任务或团队 Playbook。
两周落地顺序
第 1 至 3 天：建立只读基线
- 选择一个数据范围明确的任务。
- 在测试工作区运行三次，保留原始输入和结果。
- 记录遗漏、幻觉、格式不稳定和耗时。
第 4 至 7 天：固定交付物
- 把有效提示整理成 Skill 或模板。
- 明确来源引用、异常提示和完成检查。
- 仍然不开放外部发送或删除权限。
第 8 至 14 天：加入触发与审批
- 选择一个渠道或定时触发方式。
- 把发送、修改和高风险步骤放在人工确认之后。
- 统计成功率、人工修改率和真正节省的时间。
两周后，如果任务没有稳定节省时间，先修改任务边界，不要靠增加更多工具掩盖问题。
常见失败方式
- 同时接入邮箱、日历、浏览器和多个群聊，出了问题却无法判断是哪一层。
- 用“处理一下”“帮我看看”这类开放指令代替交付物和成功标准。
- 把浏览器登录成功等同于可以自由点击、下载或提交。
- 定时任务失败后无限重试，产生重复消息或重复写入。
- 只计算 Agent 完成了多少动作，不计算核对和返工时间。
完成检查
- 你已经选出两个场景，并能解释它们为何高频、结构化、可验证、可恢复。
- 每个场景都写明了读取范围、禁止范围、交付物、审批点和失败处理。
- 第一个试点从只读或草稿开始，没有直接开放不可逆权限。
- 你准备记录成功率和人工修改率，而不是只凭新鲜感评价效果。
需要进一步实现触发和恢复机制，可以继续阅读 OpenClaw Hooks 与自动化。团队共用前，先看 OpenClaw 团队落地手册，把账号、渠道和审批责任分开。