为什么我的 OpenClaw 多 Agent 协作失败?从小说写作团队案例谈架构设计

节省时间版本

今天的文章主要是工作群里有个同事问“有人玩 openclaw 多 Agent 吗？”然后我就抽空和我的“座山雕🦅”一起搞了这个文章，核心是介绍 OpenClaw 的多 Agent 架构（Multi-Agent Architecture）。文章比较长，建议点赞收藏，后续再看。另外，可以直接关注本公众号，然后回复“openclaw”获取一份提示词，直接丢给 OpenClaw 就可以帮你自动配置一个多 Agent 架构。大致如下：

OpenClaw 的多 Agent 架构（Multi-Agent Architecture）

OpenClaw 的设计本质上是：一个 Gateway + 多个 Agent Runtime + Tool 系统

核心组件包括：Geteway、Agent Runtime、Session、Tool System、Agent-to-Agent Communication，在搞多 Agent 之前，这些概念还是要理一下。

Gateway

Gateway 是 OpenClaw 的运行入口。职责：

• 接收消息（来自钉钉、飞书、Telegram、OpenClaw Dashboard 等）
• 根据 routing rules 分发到 Agent
• 管理 session 生命周期

典型流程：

User message
     ↓
Gateway
     ↓
bindings routing
     ↓
Agent session

因此 Gateway 的核心能力其实是：

message routing （消息路由）
session creation （会话创建）
agent dispatch （代理分发）

Agent Runtime

每个 Agent 本质是一个独立的运行环境。一个 Agent 包含：

workspace
memory
tools
prompt configuration
session history

结构通常是：

workspace/
  AGENTS.md
  SOUL.md
  TOOLS.md
  MEMORY.md
  ...

比如我的工作空间

这些文件会在运行时被组合进 system prompt。

这里埋一个伏笔，关注这个公众号的朋友肯定知道，我最近在学习脑科学和记忆相关的生物知识，我发现 OpenClaw 的 Prompt 组装就和人脑记忆中的一个逻辑很像，通俗讲叫
“U 型遗忘曲线”，专业一点叫做“序列位置效应”。扯远了，这个下次更新。

Session

Session 是 Agent 的运行上下文。可以立即为你和 ChatGPT 聊久了之后点击了一个新建会话，然后就生成一个新的 session。

保存内容：

用户消息
Agent回复
工具调用
执行轨迹

路径通常在：

~/.openclaw/agents/<agentId>/sessions

重要特性：

session 是 agent 私有

不同 agent 默认无法直接访问对方 session，但其实物理上是不隔离的，都在一个宿主机上，还是可以通过bash命令访问的，简单的方式就是你直接对 Agent1说，让它去阅读Agent2的 sessions 目录，你会发现能够阅读到。

这也是很多 Multi-Agent 协同问题的来源。

Tool System

Agent 的执行能力来自 Tools，例如：

web_search
web_fetch
file_write
file_read
sessions_send
shell
browser

Agent 的执行循环：

receive message （收到消息）
build prompt （构建 prompt）
LLM reasoning （模型推理）
tool call （工具调用）
tool execution （工具执行）
update memory （更新记忆（可选））
return result （返回结果）

Agent-to-Agent Communication

OpenClaw 提供两个理论上的通信方式：

1. sessions_send

AgentA → message → AgentB session

2. spawn sub-agent

AgentA
   │
spawn
   │
AgentB

但这两种方式在实践中都存在一些问题比如：权限控制、session lifecycle、routing 冲突等。我遇到的问题就是这个层面的典型案例。下面会讲。

Single Agent 与 Multi-Agent 协同的差异

在 AI Agent 系统设计中，通常存在两种架构模式：Single Agent Architecture 和 Multi-Agent Architecture。简单做个对比

	Single Agent Architecture	Multi-Agent Architecture
架构	`plain User ↓ Agent ↓ Tools`	`plain User ↓ Manager Agent ↓ Worker Agents 比如一个小说创作架构 Manager ├ Writer ├ Researcher └ Editor`
特点	1. 单决策中心，系统简单 2. 统一上下文，状态统一 3. 工具驱动执行 4. 调试简单 5. token 消耗低	1. 角色专业化 2. 任务可拆分 3. 可并行执行
缺点	1. 角色分工弱，同时承担多角色的时候上下文切换混乱 2. 任务结构复杂时 prompt 会变大	1. 协调成本高 2. 状态同步困难 3. 调试复杂

实际工程中最常见的问题是：

Agent coordination failure

也就是：

任务分配成功
但执行失败

原因通常是：

communication mechanism 不稳定

下面用一个小说写作案例分析举例讲解一下

小说写作系统案例分析

我的系统结构大致是：

最强大脑：任务管理
丸子：写小说
座山雕：收集素材

目标流程：

我提出需求
 ↓
最强大脑拆分任务
 ↓
座山雕收集资料
 ↓
丸子写作
 ↓
最强大脑整合

这是一个非常典型的：Manager + Workers的多 Agent 架构，大脑 1:N 和丸子还有座山雕沟通，座山雕收集的素材存放到指定的目录之后，丸子只读取素材，不会和座山雕沟通，所以还相对简单，但是这个简单的架构也是问题很多。

sessions_send 失败的问题

我选择的是使用sessions_send方法在 Agent 之间进行通信，老是遇到这个报错，Wroker Agent 没有收到指令。

目前看会有几个问题：

1. Session 不存在，如果 AgentB 没有 active session，那sessions_send会失败，因为系统无法找到：target session，等于这个协作是要不间断的协作，如果一个 Agent 静默了就会失败。
2. Agent routing 冲突，如果多个 Agent 在同一 channel：比如我拉的钉钉群，Gateway routing 会：创建新的 session,而不是使用 existing session
3. 权限问题

比如这个 issue 中提到的问题：https://github.com/openclaw/openclaw/issues/23187

agentToAgent.enabled

配置错误会导致sub-agent / spawn和sessions_send异常。

沟通机制缺失

Multi-Agent 需要有效的沟通机制，如果没有沟通机制，那运行到后面就会越来越乱，即使事无巨细的都写到本地文件了，那也无济于事，就像开卷考试你都不知道答案在哪一页。

没有制定有效的沟通机制是一个场景的问题，尤其第一次搞 Multi-Agent

我的协作系统其实是：

Manager （最强大脑）
 ↓
command （发送指令）
 ↓
Worker （驱动 Wroker 干活）

但没有做状态同步，没有预定任务看板在哪，这样方便 Agent 下次激活的时候知道自己要干啥，以及整体项目进度怎么样了。（写到这里，我真想要那些觉得自己项目管理能力强的人去试试配置个 Multi-Agent，秀一秀他的瓜你哲学，是不是一摊💩）

重要的同步信息例如：任务状态、任务结果、任务依赖都需要有一个良好的机制。数据库、文本都可以，在 openclaw 下我还没有找到稳定的方案，有了分享，记得关注。

分享我的架构方案

我现在会有一个公共的共享文件：

tasks.md

结构：

# 小说任务板

## 当前任务

任务ID: 001
任务类型: 收集资料
负责人: 座山雕
状态: pending

任务ID: 002
任务类型: 写第一章
负责人: 丸子
依赖: 001
状态: waiting

运行流程：

## 开始

最强大脑
 ↓
写入任务板
 ↓
worker agent 设置定时任务读取 task.md
 ↓
完成任务后更新状态

## 下一个定时任务
最强大脑
 ↓
读取任务板 （进行新的规划）
 ↓
写入任务板 （写入新计划）
 ↓
worker agent 设置定时任务读取 task.md
 ↓
完成任务后更新状态

这样，从send_sessions到了定时任务+任务状态管理，稳定性会提高不少，就是很“异步”。

后面我应该还是会调整为Single Agent，上面的Multi-Agent 只是为了体验一下。最终会收敛到：

Writer Agent
  ├ research tool
  ├ plot planning tool
  ├ writing tool

直接用一个 Agent 的 Wrokflw 完成。

research
↓
plan
↓
write

其实吧，向上收敛，你会发现我那个是伪分工，构思、协作、素材收集不都是一个小说创作者角色吗？现实中大量 Agent 设计是这样的，在我看来也是伪分工：

Coder Agent
Python Agent
Backend Agent
API Agent
Database Agent

但这些其实都是：软件工程，属于同一领域。多 agent 只是在人为拆分协作，这反而增加了处理 Agent 之间沟通的成本。记得之前看过几篇文章讨论是 Signle Agent 还是 Multi-Agent 的，各有千秋吧，今天写得有点多了，下次输出。但从大模型本质出发，它更适合统一 reasoning，而不是分布式协同。

总结

OpenClaw 的 Multi-Agent 架构为 AI 协作提供了强大的可能性，但在实践中也带来了新的工程挑战，本质还是在处理多 Agent 之间如何共享上下文的协议问题，定义清楚了，按照协议执行，应该会极大的减少这种不确定性。我自己有个想法是结合AGUI的思路事件驱动，有一套事件机制来控制和协调任务。

另外，我看现在也有Agent Team和Git Wrok Tree的方案，更有人在推Agent 管理学，有时间我也学习学习给大家分享一下。

欢迎与我一起虚度时光，可关注华东野老，了解更多 Agent 相关资讯。