OpenClaw 多 Agent 协作深度指南:架构设计、实操配置与进阶模式
深入拆解 OpenClaw 多 Agent 架构的设计理念与实操配置。从单 Agent 的瓶颈到多 Agent 团队的搭建,涵盖路由绑定、Agent 间通信、四大协作模式及生产环境最佳实践。
1332 Words
2026-02-23 09:00 +0000

你有没有遇到过这样的场景:你的 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 创建专属群组,并获取群会话 ID(oc_ 开头的字符串)。
然后在 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 模式。通过 agentToAgent 和 sessions_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 | 性价比高,响应快 |
| claude-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 复杂,建议:
- 为每个 Agent 配置 HEARTBEAT.md:定期检查 Agent 是否在线、响应是否正常
- 设置日志级别:开发阶段开启详细日志,观察 Agent 间的通信内容
- 建立回退机制:当专家 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 架构不是什么高深莫测的技术,它的核心思想和管理一家公司一模一样:
- 招对人(创建合适的 Agent,选对模型)
- 分好工(编写灵魂文件,定义职责边界)
- 建通路(配置路由绑定和 Agent 间通信)
- 做监督(设置主管 Agent,建立质量控制)
从今天开始,你不再需要一个"全能但经常出错"的 AI 助手。你需要的是一支各司其职、高效协作的 AI 团队。
最后分享一个经验法则:如果你发现自己在跟 AI 说"别管那个,专注这个"的时候,就该拆 Agent 了。