OpenClaw 多 Agent 协作深度指南:架构设计、实操配置与进阶模式

深入拆解 OpenClaw 多 Agent 架构的设计理念与实操配置。从单 Agent 的瓶颈到多 Agent 团队的搭建,涵盖路由绑定、Agent 间通信、四大协作模式及生产环境最佳实践。

Bruce

OpenClawMulti-AgentAI 协作AI 架构

AI实战

1332 Words

2026-02-23 09:00 +0000


OpenClaw 多 Agent 协作架构指南封面

你有没有遇到过这样的场景:你的 AI 助手聊着聊着就"精神分裂"了——你让它写公众号,它突然蹦出一段代码逻辑;你让它帮你调研竞品,它却开始纠正你上周的错别字?

这不是 AI 变笨了,是你让一个"大脑"干了太多活。就好比让公司前台同时干行政、财务、研发的事,最后谁的活都干不好。

解决方案是什么?组建一支 AI 团队——让不同的 Agent 各司其职,就像一家真正的公司一样运转。

本文将深入拆解如何用 OpenClaw 搭建一套多 Agent 协作系统。不只是告诉你"怎么配",更要讲清楚"为什么这样配",以及业界主流的多 Agent 架构模式如何在实践中落地。

一、为什么单 Agent 不够用?

1.1 单 Agent 的三大瓶颈

大多数人使用 AI 助手的方式都是"一号通吃":写文案、改代码、生图、调研全在一个 Agent 里搞定。这种方式看似方便,实际上随着使用时间的增长,三个问题会越来越严重:

问题表现原因
记忆膨胀Agent 响应越来越慢记忆文件(USER.md、memory/ 等)不断累积,每次对话都要读取大量历史
上下文污染回答"串味",逻辑混乱不同领域的知识互相干扰,写文章时联想到代码逻辑
成本失控Token 消耗远超预期每次对话都携带所有无关的背景资料,输入 Token 暴涨

用一个形象的比喻:单 Agent 就像一个打工人同时开着 50 个浏览器标签页——看起来什么都在做,实际上哪个都没做好。

1.2 多 Agent 的核心理念

多 Agent 架构的核心理念很简单:专业的事交给专业的人

这不是什么新概念。早在软件工程领域,“单一职责原则"就告诉我们:一个模块只应该有一个改变的理由。放到 AI Agent 的世界里,就是:

  • 写作 Agent 只关心文字表达,它的记忆里全是写作技巧和风格模板
  • 编码 Agent 只关心代码逻辑,它的工作区里全是项目代码和技术文档
  • 调研 Agent 只关心信息收集,它配备了搜索工具和资料整理能力

每个 Agent 都有独立的"大脑”(记忆)、“办公室”(工作区)和"工作日志"(会话记录),互不干扰。

一个人就是一支军队——前提是你要会"排兵布阵"。

二、OpenClaw 多 Agent 架构全景

2.1 架构核心:三层隔离

在 OpenClaw 中,每个 Agent 不只是一个名字,而是一个完全独立的虚拟员工。理解这一点非常关键:

~/.openclaw/agents/<agentId>/
├── agent/                    # 身份证件
│   ├── auth-profiles.json    # 认证配置(用哪个 API Key)
│   └── models.json           # 模型配置(用哪个模型)
└── sessions/                 # 私人日记
    ├── <session-id>.jsonl    # 独立的聊天记录
    └── sessions.json         # 会话索引

~/.openclaw/workspace-<agentId>/
├── SOUL.md                   # 灵魂/人格定义
├── AGENTS.md                 # Agent 行为规范
├── USER.md                   # 用户信息
├── PROMPT.md                 # 提示词模板
├── IDENTITY.md               # 身份定义
└── memory/                   # 记忆存储

这三层隔离对应的正是:

层级目录作用类比
身份层agents/<id>/agent/决定用什么模型、什么凭证员工工牌
状态层agents/<id>/sessions/独立的聊天记录和路由状态工作日志
工作层workspace-<id>/独立的文件、提示词、记忆个人办公室

这种隔离设计的好处是物理级别的上下文分离。你的写作 Agent 永远不会看到编码 Agent 的代码文件,编码 Agent 也不会被写作 Agent 的风格指南干扰。

2.2 路由绑定:Bindings 机制

有了独立的 Agent,下一个问题就是:当一条消息进来时,系统怎么知道该交给哪个 Agent 处理?

答案是 Bindings(绑定)机制。这是一套确定性的路由规则,OpenClaw 会按照优先级从高到低匹配:

优先级 1:精确 peer 匹配(DM/群组 ID)
优先级 2:父 peer 匹配(线程继承)
优先级 3:guildId + 角色(Discord 特有)
优先级 4:guildId 单独匹配
优先级 5:teamId(Slack 特有)
优先级 6:accountId 匹配
优先级 7:频道级别匹配
优先级 8:默认 Agent 回退

简单说就是:越具体的规则优先级越高。如果你给某个飞书群配了专属 Agent,那这个群的消息一定会被路由到这个 Agent,不会跑偏。

多条件绑定采用 AND 逻辑——所有条件都满足才会匹配。如果同一优先级有多条规则匹配,按配置文件中的顺序,第一个赢

2.3 两种流派:分身术 vs 独立团

OpenClaw 支持两种多 Agent 部署方式,各有适用场景:

维度分身术(单 Bot 路由)独立团(多 Bot 独立)
实现方式一个飞书 Bot,通过 Bindings 路由到不同 Agent每个 Agent 对应一个独立的飞书 Bot
用户体验群里看到的是同一个机器人,但"换脑"工作每个机器人有自己的头像和名字
管理成本低,配置简单高,需要管理多个 Bot
适合场景个人使用,追求效率团队协作,需要角色感
参考 PR默认支持feishu 多 Bot PR #137

对于个人用户,强烈推荐分身术——用最少的配置获得最大的灵活性。本文也以此为重点讲解。

三、实操配置:从零搭建多 Agent 团队

3.1 创建新 Agent

使用命令行创建一个隔离的 Agent 非常简单:

# 创建一个名为 writer 的写作 Agent,使用 deepseek 模型
openclaw agents add writer \
  --model deepseek/deepseek-chat \
  --workspace ~/.openclaw/workspace-writer

# 创建一个名为 brainstorm 的头脑风暴 Agent,使用 glm-4.7
openclaw agents add brainstorm \
  --model zai/glm-4.7 \
  --workspace ~/.openclaw/workspace-brainstorm

# 创建一个名为 coder 的编码 Agent,使用 claude
openclaw agents add coder \
  --model anthropic/claude-sonnet-4-6 \
  --workspace ~/.openclaw/workspace-coder

这里有个巧妙的设计:不同 Agent 可以使用不同的模型。你可以根据任务特性选择最合适的"大脑":

Agent推荐模型理由
头脑风暴glm-4.7中文创意能力强
写作deepseek性价比高,逻辑输出稳定
编码claude-sonnet代码能力强,理解深
调研gpt-4o多模态理解好,适合信息整合

3.2 赋予灵魂:编写"入职材料"

创建了 Agent 只是给了它一个"身体"。真正让它变得有用的,是它的"灵魂文件"。

在每个 Agent 的 Workspace 目录下,需要配置三个核心文件:

SOUL.md —— Agent 的人格定义:

# Writer Agent

## 角色
你是一位资深的公众号写作专家,擅长用犀利、真实的视角剖析技术话题。

## 风格
- 开头必须用一个引人入胜的场景或反直觉的观点
- 段落短小精悍,移动端阅读友好
- 善用类比,让小学生也能听懂复杂概念
- 结尾必须有行动号召(CTA)

## 禁忌
- 不使用"众所周知""不言而喻"等空洞词汇
- 不堆砌术语,每个专业名词第一次出现时必须解释

AGENTS.md —— Agent 的行为规范:

# 工作规范

## 输出格式
- 所有文章使用 Markdown 格式
- 标题层级不超过三级(H2 > H3 > H4)
- 代码块必须标注语言类型

## 工作流程
1. 先列大纲,确认后再展开
2. 每个段落不超过 150 字
3. 完成后自检 SEO 要素

USER.md —— 用户信息:

# 用户信息

## 身份
博主,技术自媒体作者,专注 AI 工具和效率提升。

## 偏好
- 语言风格:专业但不学术,有温度
- 目标读者:对 AI 感兴趣的技术人和产品经理
- 发布平台:微信公众号 + 个人博客

给 AI 写"入职材料"听起来很魔幻,但这正是让 Agent 输出稳定、可控的关键。你越认真地定义它,它就越认真地工作。

3.3 设置身份标识

让每个 Agent 在飞书群里有辨识度:

# 给 Agent 设置显示名和 emoji
openclaw agents set-identity --agent writer --name "写作助手" --emoji "✍️"
openclaw agents set-identity --agent brainstorm --name "脑暴搭子" --emoji "💡"
openclaw agents set-identity --agent coder --name "代码工匠" --emoji "⚡"

3.4 绑定飞书群组

在飞书中为每个 Agent 创建专属群组,并获取群会话 IDoc_ 开头的字符串)。

然后在 openclaw.json 中配置 Bindings 路由:

{
  "bindings": [
    {
      "agentId": "writer",
      "match": {
        "channel": "feishu",
        "peer": {
          "kind": "group",
          "id": "oc_abc123..."
        }
      }
    },
    {
      "agentId": "brainstorm",
      "match": {
        "channel": "feishu",
        "peer": {
          "kind": "group",
          "id": "oc_def456..."
        }
      }
    },
    {
      "agentId": "coder",
      "match": {
        "channel": "feishu",
        "peer": {
          "kind": "group",
          "id": "oc_ghi789..."
        }
      }
    }
  ]
}

核心原理:同一个飞书 Bot,被拉进三个不同的群。当消息从不同群进来时,Bindings 机制会根据群 ID 精确路由到对应的 Agent。对用户来说,看起来是同一个机器人,但底层连接的是完全不同的"大脑"。

3.5 开启免@模式

默认情况下,群里必须 @机器人才会触发回复。如果你想让某个群变成和 Agent 的"私人办公室",可以关掉这个限制:

{
  "channels": {
    "feishu": {
      "enabled": true,
      "appId": "cli_a9f21xxxxx89bcd",
      "appSecret": "w6cPunaxxxxBl1HHtdF",
      "groups": {
        "oc_abc123...": { "requireMention": false },
        "oc_def456...": { "requireMention": false }
      }
    }
  }
}

同时需要在飞书后台开启 im:message.group_msg 权限,两者配合才有效。

四、Agent 间通信:从单打独斗到团队协作

搭好了多个 Agent 只是第一步。真正的价值在于让它们协作起来——就像一家公司不能只有员工没有沟通。

4.1 核心机制:sessions_send

Agent 之间的通信依靠 OpenClaw 内置的 sessions_send 工具。你可以把它理解为 Agent 之间的"内线电话":

用户发指令 → 主管 Agent (main) 接收
         判断任务类型
        ↙    ↓     ↘
  brainstorm  writer  coder
   (脑暴)    (写作)   (编码)
        ↘    ↓     ↙
         汇总结果
         主管 Agent 返回给用户

4.2 配置 Agent-to-Agent 通信

要让"内线电话"打得通,必须在配置文件中显式开启权限:

{
  "tools": {
    "agentToAgent": {
      "enabled": true,
      "allow": ["main", "brainstorm", "writer", "coder"]
    }
  }
}

关键要点:

  • 默认关闭:Agent 间通信必须显式启用,这是安全设计
  • 白名单机制allow 列表明确规定哪些 Agent 可以互相通信
  • 最小权限原则:不是所有 Agent 都需要相互通信,只给必要的 Agent 开通

4.3 主管 Agent 的角色设计

在我的实践中,最有效的模式是设置一个主管 Agent(通常叫 main),它的职责不是自己干活,而是"接单"和"派单":

# Main Agent - SOUL.md

## 角色
你是团队的首席协调官。你的核心职责:

1. **接住需求**:理解用户的原始指令
2. **精准调度**:判断任务类型,分配给对应的专家 Agent
3. **质量把控**:审查专家 Agent 的输出,必要时要求修改
4. **串联全场**:确保多步骤任务不掉链子

## 调度规则
- 头脑风暴、创意发散 → @brainstorm
- 文章撰写、文案优化 → @writer
- 代码编写、技术实现 → @coder
- 简单问答、日常闲聊 → 自己回答

这种设计的核心意义不仅是分工,更是监督和容错:当某个 Agent 卡住或出错时,主管 Agent 能介入修复,确保流程不中断。

五、四大协作模式深度解析

了解了基础配置后,让我们上升到架构层面。根据 LangChain 的多 Agent 架构研究Google 的八大设计模式,主流的多 Agent 协作模式可以归纳为四种:

5.1 Supervisor(监督者模式)

         ┌─────────┐
         │ 用户指令 │
         └────┬────┘
      ┌───────────────┐
      │ Supervisor     │
      │ (主管 Agent)   │
      └──┬─────┬───┬──┘
         ↓     ↓   ↓
      ┌───┐ ┌───┐ ┌───┐
      │ A │ │ B │ │ C │
      └───┘ └───┘ └───┘
         ↓     ↓   ↓
      ┌───────────────┐
      │  汇总 & 输出   │
      └───────────────┘

工作方式:一个中央 Supervisor 接收所有请求,拆解成子任务,分配给专家 Agent,收集结果后汇总输出。

OpenClaw 实现:这正是前面配置的 main Agent 模式。通过 agentToAgentsessions_send,main 可以向任何专家 Agent 发送指令并获取结果。

适用场景

  • 需要统一入口的个人助手
  • 任务需要跨领域协作(先调研、再写作、最后排版)
  • 需要质量监督和结果审查

在 OpenClaw 中的实践

{
  "agents": {
    "list": [
      { "id": "main", "workspace": "~/.openclaw/workspace-main" },
      { "id": "writer", "workspace": "~/.openclaw/workspace-writer" },
      { "id": "coder", "workspace": "~/.openclaw/workspace-coder" }
    ]
  },
  "tools": {
    "agentToAgent": {
      "enabled": true,
      "allow": ["main", "writer", "coder"]
    }
  }
}

5.2 Router(路由模式)

         ┌─────────┐
         │ 用户指令 │
         └────┬────┘
      ┌───────────────┐
      │   Router       │
      │ (路由分发)     │
      └──┬─────┬───┬──┘
         ↓     ↓   ↓      ← 并行执行
      ┌───┐ ┌───┐ ┌───┐
      │ A │ │ B │ │ C │
      └───┘ └───┘ └───┘
         ↓     ↓   ↓
      ┌───────────────┐
      │  综合 & 输出   │
      └───────────────┘

工作方式:Router 分类输入,将请求并行分发给多个专家 Agent,综合结果后输出。Router 通常是无状态的。

与 Supervisor 的区别:Supervisor 是串行协调(先做 A 再做 B),Router 是并行分发(A 和 B 同时做)。

OpenClaw 实现:利用 Bindings 的确定性路由规则,根据消息来源(群组/频道/用户)自动分发到对应 Agent,天然就是 Router 模式。

适用场景

  • 不同渠道需要不同风格(飞书用中文,Telegram 用英文)
  • 不同用户群需要不同专业度
  • 需要快速响应,不需要跨 Agent 协作

5.3 Pipeline(流水线模式)

      ┌─────────┐
      │ 用户指令 │
      └────┬────┘
      ┌─────────┐     ┌─────────┐     ┌─────────┐
      │ 调研员  │ ──→ │  写手   │ ──→ │ 校审官  │
      └─────────┘     └─────────┘     └─────────┘
                                     ┌──────────┐
                                     │ 最终输出  │
                                     └──────────┘

工作方式:任务像流水线一样在 Agent 之间传递。前一个 Agent 的输出是下一个 Agent 的输入。

OpenClaw 实现:通过 sessions_send,主管 Agent 可以编排一条执行链:先让调研 Agent 收集资料,把结果传给写作 Agent 出初稿,最后交给校审 Agent 润色。

适用场景

  • 内容创作流水线:调研 → 初稿 → 审核 → 排版
  • 代码开发流水线:设计 → 编码 → 测试 → 部署
  • 数据处理流水线:采集 → 清洗 → 分析 → 可视化

实操示例——一篇公众号文章的生产流水线:

Step 1: @brainstorm "围绕 AI 编程效率展开头脑风暴,给出 5 个选题方向"
Step 2: 用户选定方向后 → @writer "基于以下素材撰写文章:{brainstorm 输出}"
Step 3: 写作完成后 → @coder "检查文章中的代码示例是否正确可运行"
Step 4: main Agent 汇总所有反馈,输出最终版本

5.4 Parallel(并行模式)

            ┌─────────┐
            │ 用户指令 │
            └────┬────┘
         ┌──────────────┐
         │  任务拆解器   │
         └──┬────┬────┬─┘
            ↓    ↓    ↓      ← 同时执行
         ┌───┐ ┌───┐ ┌───┐
         │ A │ │ B │ │ C │
         └─┬─┘ └─┬─┘ └─┬─┘
           ↓     ↓     ↓
         ┌──────────────┐
         │ 结果聚合器    │
         └──────────────┘

工作方式:同一个任务被拆成多个独立子任务,由多个 Agent 同时处理,最后聚合结果。

适用场景

  • 竞品分析:多个 Agent 同时调研不同竞品
  • 多角度评审:同一份代码让安全 Agent、性能 Agent、可维护性 Agent 分别审查
  • 多语言翻译:同一内容同时翻译成多种语言

5.5 如何选择合适的模式?

不需要一上来就设计复杂的架构。根据 LangChain 的建议,最佳路径是渐进式升级

单 Agent + 工具
    ↓ (上下文开始污染)
单 Agent + Skills
    ↓ (记忆膨胀、成本失控)
Supervisor + 2-3 专家 Agent
    ↓ (需要更复杂的协作)
Pipeline / Parallel 混合模式

核心原则:添加工具优于添加 Agent,仅在遇到清晰限制时才升级到多 Agent 模式。

六、生产环境最佳实践

6.1 安全沙箱配置

不同 Agent 的权限应该不同。一个写作 Agent 不需要执行代码的能力,一个调研 Agent 不需要写文件的权限:

{
  "agents": {
    "list": [
      {
        "id": "writer",
        "sandbox": { "mode": "all", "scope": "agent" },
        "tools": {
          "allow": ["read", "browser"],
          "deny": ["exec", "write"]
        }
      },
      {
        "id": "coder",
        "tools": {
          "allow": ["exec", "read", "write"],
          "deny": ["browser"]
        }
      }
    ]
  }
}

6.2 模型与渠道的灵活搭配

OpenClaw 支持在不同渠道使用不同模型,甚至同一 Agent 在不同场景下切换模型:

渠道推荐模型理由
飞书(日常)deepseek性价比高,响应快
WhatsAppclaude-sonnet快速、准确,适合移动端
Telegram(深度任务)claude-opus深度思考,适合复杂问题

6.3 Skills 共享机制

多个 Agent 之间可以共享通用技能,同时保留各自的专属技能:

~/.openclaw/skills/           # 全局共享技能
├── web-search/               # 搜索能力(所有 Agent 共用)
├── file-tools/               # 文件操作(所有 Agent 共用)
└── image-gen/                # 图片生成(所有 Agent 共用)

~/.openclaw/workspace-writer/skills/   # Writer 专属技能
├── seo-checker/              # SEO 检查
└── article-template/         # 文章模板

~/.openclaw/workspace-coder/skills/    # Coder 专属技能
├── code-review/              # 代码审查
└── test-runner/              # 测试运行

6.4 监控与调试

多 Agent 系统的调试比单 Agent 复杂,建议:

  1. 为每个 Agent 配置 HEARTBEAT.md:定期检查 Agent 是否在线、响应是否正常
  2. 设置日志级别:开发阶段开启详细日志,观察 Agent 间的通信内容
  3. 建立回退机制:当专家 Agent 无响应时,主管 Agent 应该能自行处理或通知用户

七、常见问题与避坑指南

Q1:Agent 数量越多越好吗?

不是。 每增加一个 Agent 就增加了通信开销和管理成本。我的建议:

  • 个人使用:3-5 个 Agent 足够(主管 + 2-4 专家)
  • 团队使用:根据业务线划分,每条线 2-3 个 Agent
  • 关键指标:如果两个 Agent 的对话超过 80% 是同一类任务,考虑合并

Q2:Agent 之间通信会消耗额外 Token 吗?

会的。 每次 sessions_send 都是一次 API 调用。减少不必要通信的方法:

  • 主管 Agent 在派单前先判断任务复杂度,简单任务自己处理
  • 使用 Token 优化策略减少每次通信的上下文长度
  • 给子 Agent 设置更轻量的模型

Q3:如何处理 Agent 之间的"理解偏差"?

Agent A 的输出交给 Agent B 时,可能出现理解不一致。解决方案:

  • 结构化通信:Agent 间传递 JSON 格式的结构化数据,而非自由文本
  • 模板化指令:主管 Agent 使用标准化的指令模板调度子 Agent
  • 校验环节:在关键节点增加审查步骤

Q4:可以跨平台协作吗?

完全可以。 OpenClaw 不限于飞书,支持 Telegram、Discord、WhatsApp 等多个渠道。你甚至可以让飞书群的 Agent 和 Telegram 的 Agent 通过 sessions_send 协作。

总结

多 Agent 架构不是什么高深莫测的技术,它的核心思想和管理一家公司一模一样:

  1. 招对人(创建合适的 Agent,选对模型)
  2. 分好工(编写灵魂文件,定义职责边界)
  3. 建通路(配置路由绑定和 Agent 间通信)
  4. 做监督(设置主管 Agent,建立质量控制)

从今天开始,你不再需要一个"全能但经常出错"的 AI 助手。你需要的是一支各司其职、高效协作的 AI 团队

最后分享一个经验法则:如果你发现自己在跟 AI 说"别管那个,专注这个"的时候,就该拆 Agent 了

相关阅读