需要审批的自动化流程应该怎么设计

很多团队刚开始做 OpenClaw 自动化时，会把“能自动跑”和“应该自动跑”混在一起。

但从最近官方文档的方向看，产品已经越来越明确地区分三层：

• 分析和准备
• 审批
• 有副作用的执行

这条边界如果一开始不设计清楚，后面越自动化越危险。

第一原则：把副作用当成独立阶段

最稳的自动化，不是从收集一路直接跑到执行，而是至少拆成：

1. 收集
2. 分类 / 生成候选动作
3. 审批
4. 执行

官方 Lobster 文档之所以强调 approval gate 和 resumeToken，本质上就是在鼓励这种分层。

第二原则：分析过程尽量确定性，审批点尽量显式

如果一个流程前半段只是：

• 拉取数据
• 分类
• 生成候选

那它更适合写成可重复、可审计的管道。

而真正需要人的地方通常是：

• 要不要发出消息
• 要不要写入外部系统
• 要不要修改生产状态

这些节点应该显式停下来，而不是隐含在 prompt 里。

第三原则：审批要落在“最小副作用单元”上

审批太早会让人看不懂要批准什么，审批太晚又可能已经做了不该做的动作。

更稳的方式通常是：

• 让前面步骤先产出预览
• 再对即将发生的副作用做批准

官方 Lobster 的 approve --preview-from-stdin 思路，正是在支持这种做法。

第四原则：批准逻辑不要只靠聊天记忆

官方最近把 Exec approvals、chat approvals 和 Lobster 的 resume 流程都做得更明确，本质上是在告诉你：

• 审批应该是运行时对象
• 而不是某句“你可以继续了”的自然语言默契

如果你把批准建立在聊天上下文里，后面最容易遇到：

• 批准对象对不上
• 会话换了以后状态丢失
• 很难审计是谁批准了什么

第五原则：高风险动作和低风险动作不要共用同一节奏

不是所有自动化都应该同样严格，但也不应该一刀切。

更适合快速自动通过的通常是：

• 只读收集
• 摘要整理
• 内部草稿生成

更适合显式审批的通常是：

• 发消息
• 发邮件
• 评论 / 提单 / 改状态
• 宿主机高权限执行

第六原则：宿主机执行边界要和业务审批边界分开看

官方 Exec approvals 文档强调的是：

• 命令能不能在真实 host 上执行

而 Lobster 的 approval gate 更接近：

• 某个流程副作用要不要继续

这两层不要混成一层理解。

更稳的做法是：

• 宿主机执行用 host approvals / allowlist 控制
• 业务动作用 workflow approval gate 控制

这样才能同时守住：

• 机器安全
• 业务操作安全

第七原则：Prose 负责组织，Lobster 负责落地

官方最近对 OpenProse 和 Lobster 的搭配方向已经很清楚：

• Prose 适合多智能体准备工作
• Lobster 适合最终的确定性管道和审批恢复

所以如果你在做更复杂的团队流程，更稳的结构往往是：

• 前面用 Prose 做调研、分工、草拟
• 最后用 Lobster 执行固定流程

第八原则：把取消也当成正式结果

自动化里最常见的误区之一是：

• 只设计“批准后怎么办”

但官方 Lobster 输出状态里明确把 cancelled 作为正式结果，这很值得学。

因为在真实团队里，更常见的情况往往是：

• 审批没过
• 操作者改变主意
• 条件已失效

如果你的流程不能优雅处理取消，它就不算真正可运营。

一条更稳的设计顺序

建议按这条顺序搭自动化：

1. 先确认哪些步骤只是分析，哪些步骤有副作用
2. 先把分析段做成确定性管道
3. 对外部写入和消息发送加显式审批
4. 用 resumeToken 而不是重跑全流程
5. 再把高频流程抽成工作流文件

特别适合这么做的场景

这套方法特别适合：

• 邮件 / 消息分流
• 工单整理和执行
• 内容发布流水线
• 团队值班和运维辅助

这些流程的共同点都是：

• 前半段需要智能判断
• 后半段不能无审批地直接动外部系统

下一步推荐

• Lobster 的调用、审批和 resume token
• Exec 工具、apply_patch 与执行审批
• Heartbeat 和 Cron 的组合编排