4 Lobster工作流：把多步任务做成可审批流水线

OpenClaw 里有一个很关键的概念叫 Lobster。你可以把它理解成“工作流外壳”：把多步工具调用组织成一个确定性流程，并在关键位置加入人工审批。

Lobster工作流

1. 为什么需要Lobster

很多任务不是一句提示词就能安全完成的。

例如“帮我处理今天的邮件”：

先读取邮件。
再分类。
再判断哪些需要回复。
再起草回复。
再等待用户确认。
最后才发送。

如果把这些步骤全部交给模型自由发挥，风险会很高。Lobster 的价值是把步骤拆清楚，把副作用放到审批之后。

2. Lobster工作流长什么样

官方文档里提到，Lobster 可以运行 YAML/JSON 工作流文件，字段包括 name、args、steps、env、condition 和 approval。

一个简化示例：

name: inbox-triage
steps:
  - id: collect
    command: inbox list --json
  - id: categorize
    command: inbox categorize --json
    stdin: $collect.stdout
  - id: approve
    command: inbox apply --approve
    stdin: $categorize.stdout
    approval: required
  - id: execute
    command: inbox apply --execute
    stdin: $categorize.stdout
    condition: $approve.approved

这段流程的重点不是代码本身，而是两个设计：

approval: required：执行前必须停下来确认。
condition: $approve.approved：只有确认通过才继续。

3. 用图理解审批流程

Lobster审批流水线

把它放到真实任务中，就是：

AI 可以帮你收集和判断。
流程可以保证每步输入输出清楚。
你决定是否允许执行有副作用的动作。

这比“请帮我处理邮件”安全得多。

4. 适合做成Lobster的任务

适合：

邮件分类和回复草稿。
每日新闻收集和摘要。
项目发布前检查。
账单、发票、合同材料整理。
多仓库巡检。
内容发布前的图片、链接、格式检查。

不适合：

一次性闲聊。
没有固定步骤的开放式创意。
需要大量人工判断且无法结构化的任务。
高风险生产操作且没有回滚方案的任务。

5. 一个博客发布检查示例

假设你要发布一门课程，可以设计成：

name: blog-course-release-check
steps:
  - id: scan
    command: blog scan-course --json
  - id: validate
    command: blog validate-frontmatter --json
    stdin: $scan.stdout
  - id: preview
    command: blog build-preview --json
  - id: approve
    command: blog release-plan --preview
    stdin: $preview.stdout
    approval: required
  - id: deploy
    command: blog deploy
    condition: $approve.approved

这个流程把“检查”和“部署”隔开了。检查可以自动跑，部署必须确认。

6. 设计Lobster工作流的三条原则

原则一：先只读，再写入

所有流程都先收集信息、生成预览，不要一上来就执行。

原则二：副作用必须审批

发邮件、删文件、改数据库、重启服务、发布文章，都属于副作用。

原则三：输出要结构化

让每一步输出 JSON，比输出一大段自然语言更适合后续流程判断。

7. 本节小结

Lobster 让 OpenClaw 从“会调用工具”升级成“能按流程办事”。它最适合那些重复、可拆解、需要审批的任务。

下一节我们把安全边界讲透：OpenClaw 能做真实动作，所以必须先设计安全规则。