一句话结论
先用 bindings 把不同渠道、账号或发送者路由到隔离 Agent；只有真的需要顺序执行时，再选择可审计的 Task Flow、Lobster 或插件。
适用场景
- 单 Agent 越改越乱，想分工
- 想让工作、个人或不同渠道使用相互隔离的 Agent
- 确实需要一个可暂停、可恢复、可审计的多步任务
常见现象
- 一个 Agent 同时做太多事，回答质量下滑
- 想加新规则就要改一大段 Prompt
- 无法判断是分类错还是回答错
原因解释
- 多个身份共用同一 workspace、凭据和会话，容易混淆上下文与权限
- bindings 负责入站路由，并不会自动形成接收→分类→处理→回复的顺序 pipeline
- 多步流程若没有显式状态、审批点和失败恢复，很难审计或重试
解决步骤
- 先判断需求是「入站路由」还是「顺序编排」：前者用多个隔离 Agent + bindings，后者另选编排机制
- 用 `openclaw agents add <id>` 为真正需要隔离的角色创建独立 workspace、state 和 session store；不要复用 agentDir
- 通过 onboarding 或配置 bindings，把具体 channel/account/sender 路由到目标 Agent，并用 `openclaw agents list --bindings` 验证
- 顺序、多步骤、需要持久状态的任务用受控插件驱动 Task Flow；单次确定性工具链可评估可选的 Lobster，并设置审批点
- 先跑最小场景，保留失败状态、日志和人工接管；确认隔离与路由正确后再扩大
可复制命令
openclaw agents add work
openclaw agents list --bindings
# bindings 解决“消息交给哪个 Agent”
# Task Flow / Lobster / 插件解决“多个步骤如何依次执行”
# 两者不要混为同一个拖拽式 pipeline 功能
仍然不行怎么办
- 只是回答风格或提示词问题就保留单 Agent，不要为“看起来高级”增加路由与状态复杂度
- 需要 Dify / n8n 式可视化流程时，使用明确的外部编排器或插件，不要假设 OpenClaw 基础 Control UI 能直接拖拽完成
小白先准备什么
- 列出需要隔离的身份、渠道、账号、workspace、模型凭据和数据边界。
- 先确认 bindings 的匹配规则，不让多个 Agent 共享同一个 agentDir。
- 如果是多步任务，再画出步骤、状态、审批点、重试与人工接管，不要先创建一堆 Agent。
- 准备正常、异常和越权样例，测试消息是否路由到正确 Agent、流程是否在敏感动作前停下。
验收标准
- 每个 Agent 都有独立 workspace、状态目录和会话，bindings 能把测试消息送到正确目标。
- 敏感凭据和客户数据不会因共享 agentDir、workspace 或插件存储而意外串到其他 Agent。
- 多步流程能显示当前状态、失败步骤和审批点，并支持安全取消或恢复。
- 日志能区分入站路由与流程步骤，低置信度、资料缺失或敏感动作会转人工。
可复制提示词
请把下面业务拆成多 Agent 流程。
业务目标：___
用户入口：___
可用资料：___
必须转人工的情况：___
请输出：
1. 需要几个 Agent，每个 Agent 的名字和职责。
2. 每个 Agent 的输入字段和输出字段。
3. 正常流程图。
4. 异常和转人工流程。
5. 最小可运行版本先做哪 3 步。
常见误区和不适合场景
- 误区一：一开始就拆很多 Agent。先证明身份或数据确实需要隔离。
- 误区二：bindings 就是顺序工作流。bindings 只决定入站消息交给谁。
- 误区三：复用 agentDir。这样会造成凭据与会话状态冲突，官方明确不建议。
- 误区四：多步自动化不需要审批。发送、删除、发布等副作用必须设置明确审批点。
- 不适合：业务规则还没稳定、连人工流程都说不清的场景。
还卡着？
仅把删除凭证、客户数据和环境变量值后的必要截图、日志片段、需求说明或当前页面链接发到 zhemuy@gmail.com。