OpenClaw多Agent协作：构建复杂工作流的进阶玩法
OpenClaw多Agent协作：构建复杂工作流的进阶玩法
基础环境搭好了，但遇到内容创作、电商运营这类多环节任务，是不是还得手动切换机器人、复制粘贴、最后自己汇总？这恰恰说明，单打独斗的Agent已经不够用了。要真正解放双手，关键在于构建一个能自动流转、角色清晰、结果可追溯的多Agent协作工作流。具体怎么做？我们一步步来看。
一、物理目录隔离与Agent实体化
协作的第一步，是让每个Agent成为独立的“实体”。这可不是简单的改个名字，而是要通过物理层面的隔离，划清职责边界，从根本上避免记忆混杂和指令冲突。每个Agent只打理自己的“一亩三分地”——专属的工作空间和记忆文件，上下文绝不共享。
具体操作很直观：
1. 在终端执行两条命令，创建两个职能明确的Agent：
openclaw agents add content-boss
openclaw agents add data-scout
2. 系统会自动生成对应的独立目录：~/.openclaw/agents/content-boss/ 和 ~/.openclaw/agents/data-scout/。
3. 接下来是定义角色。进入content-boss目录，编辑agent.md文件，明确其“项目总监”的身份：
“你是一个内容项目总监。用户只向你发送一句话需求。你不得直接生成内容，必须拆解为‘找热点’‘写初稿’‘配图建议’三步，并依次@data-scout、@draft-writer、@media-consultant完成。所有中间结果必须存入本Agent的MEMORY.md。”
4. 同样，进入data-scout目录，编辑其agent.md，将其约束为精准的“侦察员”：
“你是一名实时数据侦察员。仅响应@调用。输入为‘找XX领域今日热榜’，输出格式严格为Markdown表格，含标题、热度值、原始链接三列。禁止解释、禁止额外字段。”
二、模型分层配置与成本感知路由
不同的Agent干不同的活，计算强度和成本也天差地别。让一个负责复杂规划的总监去跑简单的数据查询，无异于“大炮打蚊子”，既浪费资源又拖慢节奏。合理的做法是，根据任务特性匹配模型，实现成本与效率的最优解。
配置起来也不复杂：
1. 打开主配置文件 ~/.openclaw/openclaw.json。
2. 在agents.list数组中，为不同Agent指定合适的模型。比如，负责复杂拆解的总监用能力更强的模型，而高频轻量的侦察员则选用响应更快的小模型：
{"id":"content-boss","model":"gemini-1.5-pro","temperature":0.3}
{"id":"data-scout","model":"groq-llama-3","temperature":0.1}
3. 在bindings节中，指定通讯路由规则，将不同Agent绑定到不同的协作空间（如飞书群），实现逻辑隔离：
{"channel":"feishu","chatId":"content-team-group","agentId":"content-boss"}
{"channel":"feishu","chatId":"data-monitor-room","agentId":"data-scout"}
4. 保存配置后，重启OpenClaw服务使设置生效。
三、跨Agent提及驱动的任务流转机制
整个工作流的核心驱动力，就藏在最自然的“@提及”里。OpenClaw不需要一个笨重的中央调度器，而是通过Agent之间的@调用，像接力赛一样传递任务。每个Agent只关心自己被@时收到的指令，无需了解全局，这种松耦合的设计让流程既灵活又稳定。
来看一个实际流转的例子：
1. 你在飞书群里对content-boss说：“@content-boss 做一期关于AI Agent安全合规的公众号推文”。
2. content-boss收到后，会在自己的MEMORY.md中创建任务记录（如#A20260418001），并立即拆解出第一步：“@data-scout 找近3天AI安全监管类政策原文与解读文章热榜”。
3. data-scout被@后瞬间响应，执行网络检索，并将标准格式的表格结果直接发回群里。
4. content-boss捕获到这个表格回复，自动提取关键信息存入记忆，随即触发下一步：“@draft-writer 基于以下政策要点与链接，撰写1200字公众号推文草稿，要求带小标题与加粗重点句”。
5. 整个过程行云流水，完全无需人工介入。每个Agent都像专业流水线上的工人，只处理自己最擅长的那个环节。
四、飞书群组统一纳管与权限收敛
要让协作可视化、可管理，把所有Agent都接入同一个飞书群是最高效的方式。但这可不是简单拉个群就行，需要通过精细的权限设置，防止无关消息干扰，同时确保所有操作有迹可循。
具体部署步骤如下：
1. 在飞书管理后台创建一个专用群，例如“OpenClaw-Content-Orchestrator”，并设置为“仅群成员可发送消息”。
2. 将content-boss、data-scout、draft-writer、media-consultant这四个Bot全部添加进该群。
3. 在群设置中关闭“新成员查看历史消息”，确保每次新任务开始时，上下文都是干净的。
4. 为每个Bot申请独立的飞书机器人Token，并填入openclaw.json配置文件的channels.feishu.botTokens字段中：
{"content-boss":"btk_xxx1","data-scout":"btk_xxx2","draft-writer":"btk_xxx3","media-consultant":"btk_xxx4"}
5. 最后，确认每个Bot在群内显示的名称与其角色定义一致（例如“内容项目总监”），而不是千篇一律的默认名，这能让协作过程更加直观。
五、Lobster工作流引擎启用与状态回溯
当协作链条超过三层，或者涉及条件判断（比如“如果热点热度大于80，就追加专家访谈环节”），单纯靠@提及可能就有点力不从心了。这时，就需要请出Lobster工作流引擎。它不修改任何Agent的内部逻辑，只作为一个“监工”和“调度员”，监听消息流并根据预设规则注入状态，驱动流程走向。
启用方法如下：
1. 在~/.openclaw/目录下，新建一个lobster.config.yaml文件。
2. 在里面定义简单的状态机逻辑。例如：
initial: wait_for_task
states:
wait_for_task:
on: "@content-boss"
do: "set task_id = A{date}{seq} & set stage = scout_phase"
scout_phase:
on: "table with ≥5 rows"
do: "set stage = draft_phase & emit @draft-writer"
3. 在openclaw.json中打开引擎开关：
"lobster":{"enabled":true,"configPath":"~/.openclaw/lobster.config.yaml"}
4. 重启服务后，Lobster引擎便开始工作。它会自动解析群里的消息，当发现data-scout返回了行数大于等于5的表格时，就自动触发下一个环节，去@draft-writer。**最关键的是，这一切都无需你修改任何一个Agent的原有代码或指令。**
通过以上五个步骤的配置，一个职责清晰、自动流转、状态可控的多Agent协作工作流就搭建完成了。从接收需求到最终产出，整个过程如同有一支无形的专业团队在高效运作，而你，只需在开始时下达一个简单的指令。