多Agent实战：用LocalClaw搭一套多Agent协作系统（附完整代码）

什么时候需要多Agent？

单Agent能搞定大多数任务。但当你有以下需求时，多Agent就开始有意义了：

• 多平台运营：每个平台有专人负责，信息不串台
• 任务类型差异大：写代码的Agent和写文案的Agent需要不同的上下文
• 团队协作：多个Agent需要消息传递、任务派发、结果汇总

判断标准：

如果你发现自己在一个Agent里来回切换上下文，多Agent可能更适合你。

LocalClaw 多Agent架构的核心组件

LocalClaw 的多Agent系统有三个核心组件：

1. workspace 隔离

每个Agent有独立的工作空间（workspace），数据完全隔离：

~/.openclaw/
├── workspace微微安/     # 微微安的独立工作空间
│   ├── SOUL.md          # 角色定义
│   ├── IDENTITY.md       # 身份配置
│   └── memory/           # 工作日志
│       └── 2026-04-09.md
├── workspace云拓/       # 云拓的独立工作空间
│   ├── SOUL.md
│   ├── IDENTITY.md
│   └── memory/
│       └── 2026-04-09.md
└── _share/             # 共享知识库（所有Agent可见）
    ├── 产品知识手册.md
    └── 微微安经验笔记.md

workspace 隔离的好处：

• 每个Agent的memory不会互相污染
• 一个Agent崩溃不影响其他Agent
• 可以给不同Agent配置不同的模型（简单任务用4B，复杂任务用9B）

2. sessions_send：Agent间消息传递

sessions_send 是LocalClaw提供的Agent间通信工具：

// 派发任务
sessions_send({
  sessionKey: "agent:csdn:main",  // 目标Agent
  message: "弈清，CSDN文章《多Agent实战》初稿完成，请审核。"
})

// 接收任务（在目标Agent端）
// 消息会出现在目标Agent的对话里，等待处理

关键参数：

• sessionKey：格式为 agent:{name}:main
• message：支持结构化文本
• timeoutSeconds：超时设置

3. 共享知识库（_share/）

_share/ 目录是团队的信息中枢：

_share/
├── 产品知识手册.md       # 最新产品信息
├── 微微安经验笔记.md     # 内容写作心法
└── 团队协作规范.md       # 任务格式、周报要求

更新产品信息时，只需要更新一个文件，所有Agent立即可见。

实战：搭建一个4Agent协作系统

假设我们搭建一个内容运营团队：

• 运营总监（弈清）：任务派发、结果审核
• 微微安：情绪拉力文、热点内容
• 云拓：技术教程、深度测评
• 知妙言：知乎问答、观点输出

Step 1：创建运营总监Agent

运营总监是最重要的角色，负责统一调度：

// 在运营总监的 SOUL.md 中定义角色：
const COORDINATOR_SOUL = {
  name: "弈清",
  role: "运营总监",
  responsibilities: [
    "接收外部任务需求",
    "分解任务并派发给对应Agent",
    "审核各Agent输出",
    "最终交付给客户"
  ],
  rules: [
    "每个任务必须记录到 memory/YYYY-MM-DD.md",
    "任务完成后必须汇报",
    "审核不通过时要给出明确修改意见"
  ]
}

Step 2：创建内容Agent（以微微安为例）

//微微安的 SOUL.md
const WEIWETAN_SOUL = {
  name: "微微安",
  role: "情绪拉力文专家",
  platform: "微信公众号",
  expertise: ["情感共鸣", "热点搭车", "标题党"],
  style: "有温度、有共鸣、让人想转发"
}

//微微安的 IDENTITY.md
const WEIWETAN_IDENTITY = {
  workspace: "workspace微微安",
  models: {
    default: "qwen3.5-9b",     // 默认用9B，写情感文够用
    quick: "qwen3.5-4b"          // 快速回复用4B，省Token
  },
  sharedKnowledge: "_share/微微安经验笔记.md",
  dailyLog: "memory/YYYY-MM-DD.md"
}

Step 3：实现任务派发

// 运营总监（弈清）派发任务给微微安
async function dispatchTask(task, targetAgent) {
  // 1. 记录到运营总监的memory
  await logToMemory({
    agent: "弈清",
    action: "派发任务",
    task: task,
    target: targetAgent,
    time: new Date().toISOString()
  })

  // 2. 通过sessions_send发送任务
  await sessions_send({
    sessionKey: `agent:${targetAgent}:main`,
    message: buildTaskMessage(task)
  })

  // 3. 等待确认
  return { status: "dispatched", target: targetAgent }
}

// 任务消息格式化
function buildTaskMessage(task) {
  return `
【任务】${task.title}
【角度】：${task.angle}
【截止】：${task.deadline}
【注意事项】：${task.notes || "无"}
`
}

Step 4：接收任务并执行

// 在微微安的Agent里，接收任务并执行
async function handleTaskReceived(message) {
  const task = parseTaskMessage(message)

  // 1. 记录到自己的memory
  await logToMemory({
    agent: "微微安",
    action: "接收任务",
    task: task.title,
    time: new Date().toISOString()
  })

  // 2. 开始执行
  const content = await writeEmotionalArticle(task)

  // 3. 记录完成
  await logToMemory({
    agent: "微微安",
    action: "完成任务",
    output: content.summary,
    time: new Date().toISOString()
  })

  // 4. 汇报给运营总监
  await sessions_send({
    sessionKey: "agent:coo:main",
    message: `微微安，任务"${task.title}"已完成。摘要：${content.summary}`
  })

  return { status: "completed", content }
}

Step 5：结果汇总与交付

// 运营总监汇总各Agent结果
async function aggregateResults(articleOutputs) {
  const aggregated = {
    emotional: articleOutputs.find(o => o.agent === "微微安"),
    technical: articleOutputs.find(o => o.agent === "云拓"),
    qa: articleOutputs.find(o => o.agent === "知妙言"),
    summary: generateSummary(articleOutputs)
  }

  // 更新共享知识库
  await updateSharedKnowledge({
    date: getToday(),
    outputs: aggregated,
    notes: "今天的协作效率有所提升，微微安的标题写得特别好"
  })

  return aggregated
}

完整工作流示例

早上9:00
    ↓
外部需求："需要一篇关于LocalClaw的推广文"
    ↓
弈清（运营总监）接收需求
    ↓
任务分解：
  - 微微安：写情绪拉力文（2小时内交稿）
  - 云拓：写技术教程（3小时内交稿）
    ↓
sessions_send → agent:微微安:main
sessions_send → agent:云拓:main
    ↓
微微安和云拓并行执行
    ↓
微微安完成任务 → sessions_send → agent:coo:main
云拓完成任务 → sessions_send → agent:coo:main
    ↓
弈清审核：
  - 微微安 ✓ 直接通过
  - 云拓 ✗ 需要补充一个代码示例
    ↓
云拓补充代码 → sessions_send → agent:coo:main
    ↓
弈清最终交付

多Agent协作的坑与解法

坑1：Agent之间消息丢失

解法：

• 每次发送消息都要有超时和确认机制
• 在自己的memory里记录"已发送，等待确认"

async function sendWithConfirmation(sessionKey, message) {
  const msgId = generateUUID()

  await sessions_send({
    sessionKey,
    message: message + `\n[msgId:${msgId}]`
  })

  // 等待确认（通过轮询或回调）
  const confirmed = await waitForConfirmation(msgId, timeoutMs = 60000)
  if (!confirmed) {
    // 重试或上报
    await notifyFailure({ msgId, sessionKey, message })
  }
}

坑2：workspace空间混乱

解法：

• 每个Agent的memory要定期清理
• 用日期命名，方便追溯

memory/
├── 2026-04-01.md   # 4月1日的工作记录
├── 2026-04-09.md   # 4月9日的工作记录
└── 周报-2026-W15.md  # 本周总结

坑3：模型选择不当

简单任务用大模型 = 浪费Token。
复杂任务用小模型 = 效果差。

解法： 根据任务类型选模型：

总结

LocalClaw 多Agent系统的核心价值：

1. workspace隔离：每个Agent独立运行，互不干扰
2. sessions_send：标准化的Agent间通信
3. 共享知识库：信息同步不需要每次都传

什么时候用多Agent：

• 多平台运营（3个以上平台）
• 任务类型差异大（文案 vs 技术 vs 客服）
• 需要团队协作流程（派发→执行→审核→交付）

什么时候用单Agent：

• 单一平台、单一任务类型
• 任务简单、上下文不多
• 协作需求低

AI review 不能替代人工 review，多Agent也不能替代单Agent——选择合适的架构，才能效率最大化。

相关资源：

• LocalClaw 官网
• 技能市场 ClawHub