Lobster：给 OpenClaw 的自动化加一道类型安全的闸门

它解决的是代理的健忘症

大语言模型代理的常见毛病是每次调用都重新规划。Lobster 把这种规划固化下来。它是一个工作流外壳，让 OpenClaw 或者其他代理用一条命令调用预定义的管道，而不是一步步重新思考。README 里给出的例子是监控 GitHub PR：代理只需要执行 workflows.run，传入仓库和 PR 编号，返回的是结构化 JSON，包含 changed 字段和变更摘要。这个机制省 token 是次要的，主要价值在于确定性。同样的输入会产生同样的步骤序列，不会因为模型状态不同而跑偏。它面向的是那些已经受够了代理随机性的工程师，尤其是需要审计和重放的自动化任务。

JSON 管道，不是文本管道

传统 shell 管道传的是字节流，Lobster 传的是对象和数组。核心命令 exec、where、pick、head 操作的是结构化数据。README 的快速开始里有一行示例：exec --json --shell 'echo [1,2,3]' | where '0>=0' | json。这里 where 的表达式 0>=0 是对数组元素求值，而不是对文本行做正则。这种设计让后续步骤可以直接引用 $step.json 或 $step.stdout，数据流在定义时就明确。代价是学习曲线，你需要理解 JSON 表达式语法，而不是熟悉的 grep 和 awk。但对自动化而言，类型安全比灵活更重要。

审批门是真正的安全边界

Lobster 的 approval 步骤不是简单的确认对话框。它支持身份约束：required_approver 要求指定审批人，require_different_approver 强制审批人与发起人不同，initiated_by 设置发起人 ID。环境变量 LOBSTER_APPROVAL_INITIATED_BY 和 LOBSTER_APPROVAL_APPROVED_BY 在运行时提供这些身份信息。这意味着审批不只是流程上的停顿，而是职责分离的强制点。工作流示例 jacket-advice 里，在调用 LLM 之前有一个 approval 步骤，只有当确认通过后才执行 llm.invoke。文档明确建议：如果需要在 LLM 调用前插入人工检查点，用 workflow 文件里的 approval 步骤，而不是嵌套在 pipeline 里的 approve 命令。这个区分很关键，它把安全决策放在流程定义层。

LLM 调用被当作一等管道步骤

llm.invoke 是原生 pipeline 步骤，不是外部命令。它支持 --provider 参数，解析顺序是命令行、LOBSTER_LLM_PROVIDER 环境变量、自动检测。内置提供商包括 openclaw（通过 OPENCLAW_URL 和 OPENCLAW_TOKEN）、pi（通过 LOBSTER_PI_LLM_ADAPTER_URL）、http（通过 LOBSTER_LLM_ADAPTER_URL）。这个设计把模型调用纳入同一套数据流模型，llm.invoke 的输出可以像 shell 输出一样被后续步骤引用。但注意，Lobster 自己不持有任何认证，token 全由环境变量提供，这符合它的目标：不新增认证面。缺点是部署时你得自己管理这些凭据，没有集中的密钥管理。

可视化是调试的救命稻草

lobster graph 命令可以把工作流渲染成 mermaid、dot 或 ascii 格式。它展示每个步骤节点，包括 run、pipeline、approval，并画出数据流边（来自 stdin 引用）和条件依赖边（来自 when 或 condition）。审批门在 mermaid 和 dot 输出里是菱形节点。这个功能对复杂工作流尤其重要，因为 JSON 管道嵌套多了之后，肉眼很难追踪数据从哪里来。graph 命令接受 --args-json 参数，可以针对特定参数值渲染，这能暴露参数对流程结构的影响。不过 README 没有说明它如何处理循环或动态步骤，对于高度动态的工作流，静态图可能失真。

恢复机制有隐蔽的约束

Lobster 支持命令级输入请求，通过 ctx.requestInput 暂停命令，等待结构化响应后恢复。CLI 和工具模式的恢复令牌只存状态键，持久化状态会验证挂起的请求元数据。这里有个关键限制：命令在恢复时会重新执行，所以命令必须是幂等的，直到 requestInput 返回。数组背书的输入会被快照并带有边界，而惰性流输入不会被缓冲，需要命令自己提供紧凑的 suspendedState。这意味着如果你写了一个有副作用的命令，恢复时可能重复执行。文档没有给出处理这个问题的完整模式，只要求命令作者自己保证幂等性。对生产环境来说，这是一个需要仔细设计的点。

工作流文件是脚本，不是配置

Lobster 的工作流文件用 YAML 写成，但设计上读起来像脚本。run 和 command 等价，pipeline 共享同一套参数和环境模型，approval 作为硬门。cwd、env、stdin、when、condition 对 shell 和 pipeline 步骤都有效。retry、timeout_ms、on_error 控制失败行为。这种统一模型让迁移成本低，你可以把已有的 shell 步骤逐步替换成 pipeline 步骤。但要注意，run 和 command 的等价性意味着历史文件里两种写法并存，新文件推荐用 run，这会造成风格不统一。文档没有提供自动迁移工具，你需要手动整理。

编辑结论

Lobster 适合已经在使用 OpenClaw、希望减少重复规划并提高自动化确定性的团队。它不适合需要复杂分支逻辑或大量非结构化文本处理的场景，也不适合期望它自带认证体系的用户。采用前应验证：工作流文件中的 approval 步骤是否满足你的职责分离要求，LLM 提供商的适配器是否已配置，以及 resume 机制在长任务中是否符合你的幂等性预期。Lobster 的边界在于它刻意不拥有 OAuth 和 token，这既是安全优势，也意味着你需要自己管理所有外部服务的凭据。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes