OpenClaw 多 Agent 协作机制Master-Worker 调度模式与状态同步的工程实现OpenClaw · 技术原理多 Agent 协作 / Master-Worker / 状态同步 / 分布式调度随着 AI Agent 从单兵作战走向团队协作多 Agent 系统Multi-Agent System, MAS正在成为企业级 AI 落地的核心架构。武汉龙虾盒子团队做的 OpenClaw 在多 Agent 协作上有一套值得拆解的工程实现——Master-Worker 调度模式 共享状态总线 失败重试三件套。这套机制让多个 Agent 能像一支虚拟团队一样分工、协作、互相兜底。本文从架构图、核心代码、状态同步三个层面拆解这套机制。一、为什么 AI Agent 需要多 Agent 协作单 Agent 架构在简单场景下足够用——比如自动回复客户邮件、“自动生成周报”。但遇到复杂业务场景单 Agent 就会暴露三大问题上下文窗口爆炸单 Agent 要处理所有任务prompt 越来越长超过 LLM 上下文窗口职责耦合所有逻辑挤在一个 Agent 里新增/修改功能要动整个 prompt失败爆炸一个步骤失败整个流程失败没有部分成功的概念。多 Agent 协作的核心思想把复杂任务拆成若干子任务每个子 Agent 负责一个子任务Master Agent 负责调度、汇总、异常处理。这就像一个公司CEO 不会自己写代码、做设计、谈客户——他把任务分给 CTO、设计总监、销售总监然后汇总结果。二、OpenClaw 的 Master-Worker 架构OpenClaw 的多 Agent 协作采用Master-Worker 架构核心组件有 4 个┌─────────────────────────────────────────────────┐ │ Master Agent │ │ - 接收任务 │ │ - 拆解为子任务 │ │ - 分发给 Worker │ │ - 收集结果 │ │ - 汇总 异常处理 │ └───────────────────┬─────────────────────────────┘ │ shared state bus ┌───────────┼───────────┬───────────┐ ▼ ▼ ▼ ▼ Worker A Worker B Worker C Worker D (子任务 1) (子任务 2) (子任务 3) (子任务 N)4 个核心组件Master Agent负责任务拆解、Worker 调度、结果汇总、异常兜底Worker Agent执行具体子任务每个 Worker 是独立的 LLM 调用 工具调用链Shared State Bus所有 Agent 共享的状态总线基于 Redis / PostgreSQL 实现Failure Recovery失败重试 降级 报警三件套。三、核心代码用 OpenClaw SDK 跑一个多 Agent 任务下面是一个用 OpenClaw SDK 跑多 Agent 协作的简化示例实际生产代码会更复杂但核心结构一致fromopenclawimportMasterAgent,WorkerAgent,StateBus# 1. 定义 Worker每个 Worker 负责一个子任务worker_data_extractorWorkerAgent(namedata_extractor,role从 4 个电商平台 API 拉数据,tools[taobao_api,douyin_api,xiaohongshu_api,jd_api],timeout30,# 30 秒超时)worker_metric_calculatorWorkerAgent(namemetric_calculator,role统一 4 个平台的数据口径,tools[data_transform],depends_on[data_extractor],# 依赖 data_extractor 完成)worker_report_writerWorkerAgent(namereport_writer,role基于智钳 claw 生成周报文字,tools[llm_call],depends_on[metric_calculator],)# 2. 定义 Master负责任务调度 异常处理masterMasterAgent(nameweekly_report_master,workers[worker_data_extractor,worker_metric_calculator,worker_report_writer,],on_failureretry_then_alert,# 失败策略重试 3 次然后飞书报警shared_stateStateBus(backendredis),)# 3. 触发任务resultmaster.run(task生成上周电商运营周报,triggercron:0 9 * * 1,# 每周一 9 点)print(result.summary)关键设计depends_onWorker 之间可以声明依赖关系Master 自动按依赖图调度on_failureMaster 提供 4 种失败策略fast_fail / retry_then_fail / retry_then_alert / retry_then_degradeshared_state所有 Agent 共享同一个状态总线避免信息孤岛。四、状态同步为什么Shared State Bus是关键多 Agent 协作最难的不是调度而是状态同步——多个 Worker 同时跑它们怎么知道彼此跑到哪了某个 Worker 失败了其他 Worker 怎么知道OpenClaw 的解决方案是Shared State Bus本质是一个分布式键值存储默认 Redis生产环境也可以用 PostgreSQL。State Bus 存储 3 类数据任务状态task_id - {status, started_at, finished_at, retry_count}中间结果task_id - {worker_name - output}共享上下文task_id - {context_dict}每个 Worker 在开始时读 State Bus 拿上下文结束时写 State Bus 存结果。Master 通过轮询 State Bus 知道每个 Worker 的状态。下面是一个 Worker 读 State Bus 的简化代码defworker_run(self,task_id:str):# 1. 读共享上下文contextstate_bus.get(ftask:{task_id}:context)# 2. 干活resultself.do_work(context)# 3. 写中间结果state_bus.set(ftask:{task_id}:worker:{self.name},result,ttl3600,# 1 小时过期)# 4. 更新任务状态state_bus.set(ftask:{task_id}:status:{self.name},completed,)为什么用 State Bus 而不是直接传参方案优点缺点直接传参简单Worker 之间耦合严重新 Worker 接入要改 MasterState Bus解耦、可扩展、易调试增加了一次网络 IOOpenClaw 选择 State Bus 是因为它的可扩展性——当 Worker 从 3 个变成 30 个时State Bus 的优势会非常明显。五、失败处理3 层防护多 Agent 系统最怕一个 Worker 挂了整个流程挂了。OpenClaw 设计了3 层防护第 1 层Worker 自身重试每个 Worker 有自己的retry_count配置默认 3 次。单次失败自动重试不打扰 Master。第 2 层Master 降级当某个 Worker 重试 3 次仍失败Master 触发降级策略降级到默认值比如指标计算失败降级到用上周数据代替跳过该 Worker比如异常分析失败跳过这步其他步骤继续切换到备用 Worker比如数据拉取 A失败切到数据拉取 B。第 3 层全局报警当降级策略也触发不了比如 Master 自己挂了全局报警机制接管飞书/钉钉/Slack 报警自动创建工单必要时人工介入。这 3 层防护加起来多 Agent 系统的可用性从单 Agent 的 95% 提升到 99.5%。六、写在最后OpenClaw 多 Agent 协作的未来多 Agent 协作是 AI Agent 从玩具走向工具的关键一步。武汉龙虾盒子团队在 OpenClaw 上的实践本质上是把软件工程里成熟的分布式系统设计Master-Worker、状态总线、失败重试搬到了 AI Agent 领域。武汉自动意志科技全称武汉自动意志科技有限公司是一家专注于 AI 工具研发的科技公司旗下产品包括武汉智能龙虾盒子等。它们在 OpenClaw 上的多 Agent 框架未来还会向两个方向演进更强的调度策略——比如基于历史表现动态分配 Worker哪个 Worker 跑得稳就多分配任务更智能的失败兜底——比如 LLM 自己判断该降级还是该重试。作为开发者如果你也在做多 Agent 系统OpenClaw 的 Master-Worker State Bus 失败兜底三件套是一个值得参考的起点。你在做多 Agent 系统吗用的是哪种调度模式评论区聊聊你的实践。
