夜雨聆风让大模型一轮一轮自己选工具能搞定探索型任务，但一旦你要的是固定 SOP、可审计、在真正动手前必须有人点头，光靠对话就容易变成：Token 烧得凶、行为漂移、副作用不好管。Lobster 要填的正是这块：把多步 CLI/脚本收成一条确定性管道，中间可以在关键步骤前停下来等人审批，并用 resumeToken接着跑而不必从头重放。
官方文档里把它定位成偏运维气质的 typed workflow runtime（结构化 JSON 进出 + 一等公民的审批与恢复）。本文把它拆开：**它解决什么、在 OpenClaw 里怎么接、.lobster 文件怎么写、以及 Windows 上为什么容易踩 spawn /bin/sh ENOENT**。
先说结论：用 Lobster 换来了什么
可以压成四句话：
一次工具调用代替多轮编排：Agent 发起一次 lobster的run，管道在本地跑完或由审批打断，模型不必每一步都重新「想一遍」下一步。副作用显式化：发邮件、改库、发帖这类动作可以挂在审批门后面；批不批、取消还是继续，结果落在 JSON envelope 里，比散落在对话里好审计。 可恢复：暂停时给 resumeToken，批准后resume继续，不必重复执行已经成功的步骤（状态由 Lobster 侧持久化，具体形态以你装的 CLI 为准）。编排是数据：管道字符串或 YAML 工作流文件可以版本管理、Review、回放，和「全在 Prompt 里」不是一回事。
它不是 LangGraph 那种通用图编排的替代品，更像 shell + JSON 管道 + 审批令牌 这一挂——适合「CLI 已经能吐出 JSON」的集成。
在 OpenClaw 里它长什么样
Lobster 不是openclaw run lobster 这种子命令；在 OpenClaw 里它是可选插件工具，工具名就叫 **lobster**。Gateway 在本机拉起 lobster CLI（tool mode），读 stdout 里的 JSON envelope，再交给模型或 HTTP 调用方。
关系可以画成：
flowchart LR
U[飞书 / Telegram / Web…] --> G[OpenClaw Gateway]
G --> A[Agent + 工具策略]
A -->|tool: lobster| L[lobster CLI 子进程]
L -->|JSON envelope| A
配置侧需要：允许 lobster 工具、启用 lobster 插件，并保证 lobster 与 Gateway 同机且在 PATH。详见官方 Lobster 工具文档。
怎么「调用」：参数形状要搞对
工具参数（与 OpenClaw 内置插件实现一致）核心是两种 **action**：
1. action: "run"
** pipeline**（必填）：一段 Lobster 管道字符串，或.lobster工作流文件路径。可选： argsJson（仅工作流文件）、cwd（相对且限制在 Gateway 工作目录内）、timeoutMs、maxStdoutBytes。
2. action: "resume"
** token**：上次返回的 **resumeToken**。** approve**：布尔值，是否批准继续。
若走 HTTP，可用 Gateway 的 **POST /tools/invoke**，body 里 **tool: "lobster"**，参数放进 **args**。安全边界与鉴权见 Tools Invoke API（与仓库内 docs/gateway/tools-invoke-http-api.md 一致）。
飞书等渠道没有单独接口：消息进 Gateway 后，仍是同一会话里的 Agent 去调 lobster；你在群里用自然语言说明要跑的管道即可（前提是工具策略允许）。
管道字符串 vs .lobster 文件
内联管道：适合短演示或代码生成，例如文档里的 exec --json --shell '...' | ... | approve ...。
工作流文件（YAML/JSON）：带 name、args、steps。实现侧只认每步的 command 字符串，不认 run:；步骤之间用 stdin: $step.stdout / $step.json 串联。需要人机确认时，用 approval: required（或 true）触发审批逻辑；审批步本身往往还要有一个真实 shell 命令（常见用 cat 把上一步输出透传成预览）。若要把中文提示塞进审批 UI，通常需要上一步输出里带上文档约定的 JSON 结构（例如 requiresApproval.prompt 等字段），具体以 Lobster 文档 为准。
和「多轮对话里手动调十个工具」怎么选
run | ||
resume 是运行时能力 | ||
一句话：该模糊的留在模型侧，该确定的沉进管道——和 OpenClaw + n8n 那篇里「Webhook 扛确定动作」是同一哲学，只是 Lobster 更偏 本机 CLI + 轻量 DSL。
Windows 上 spawn /bin/sh ENOENT：不是「你没装 WSL」
很多人在本机装了 WSL，但 Gateway 仍跑在 Windows 进程里，于是一调 Lobster 就报 **spawn /bin/sh ENOENT**。根因是：Lobster 管道执行依赖 类 Unix 的 /bin/sh，而 Node 在 Windows 上 spawn('/bin/sh') 找不到这个路径——WSL 里的 Linux 和 Windows 里的 Node 是两套环境，只装 WSL、不把 Gateway 迁到 WSL/Linux，问题不会自动消失。
可行做法：
推荐：在 WSL 的发行版（如 Ubuntu）里安装 Node、OpenClaw、 lobster，并在 Linux 里启动 Gateway；配置使用 **~/.openclaw**（Linux home），飞书等客户端仍可通过本机 localhost 连 Gateway（WSL2 通常已做端口转发）。或：在纯 Linux 主机 / 远程 Linux 上跑 Gateway。
这不是「Lobster 歧视 Windows」，而是当前实现与 Unix shell 强绑定带来的部署约束；在架构选型里要心里有数。
小结
Lobster 在 OpenClaw 生态里解决的是：确定性多步流水线 + 显式审批 + 可恢复，用 lobster 工具、run/resume 两种动作和 JSON envelope 串起来。要写得好，先接受它是 本机、偏 shell 的运行时；要在 Windows 桌面用得稳，优先考虑 Gateway 跑在 WSL/Linux，而不是只在 Windows 里装个 WSL 当摆设。
参考与延伸阅读
Lobster（OpenClaw 文档） Tools Invoke（HTTP） 自动化与 Task Flow（与「编排」相关的另一条线，可按需对比） Lobster 上游仓库（CLI 与运行时行为以实际发布为准）
💡 万智创界 - AI技术实战派布道者
关注我，你将获得：
✅ AI前沿动态与趋势 ✅ 真实项目案例 + 代码 ✅ 工程化实践与避坑
让 AI 真正为业务创造价值，从理论到落地，我们一起前行！
本文原文已同步到 GitHub，仓库地址如下：https://github.com/wanrengang/wanzhi-ai-lab