OpenClaw 多 AI Agent 协作，3 步搞定团队级智能体部署

你好，我是郑工长。

昨天，一个朋友找我吐槽。他说他们团队花了 2 周时间，部署了 5 个 AI Agent，号称要实现"智能体协作"。结果？

5 个 Agent 各说各话，互不搭理。

A Agent 生成的内容，B Agent 收不到；C Agent 在忙，D Agent 在旁边干等。所谓的"协作"，就是 5 个单机版 AI 各玩各的。

他问我："多 Agent 协作是不是就是个噱头？"

我说：不是协作不行，是你配置错了。

今天，我就把这套经过实战验证的 OpenClaw 多 Agent 协作配置方案，毫无保留地分享给你。

配置定律

真正的多 Agent 协作，不是靠"喊口号"实现的，
而是靠清晰的权限边界 + 明确的通信规则 + 统一的会话管理这三层架构撑起来的。

很多人以为，只要部署多个 Agent，它们就能自动协作。这是错的。

Agent 和人一样，没有规则就会乱套。

实战配置：3 步搞定

我用 OpenClaw 这套开源框架，在一个 3 人小团队里跑通了这套方案。下面是完整配置，你可以直接抄作业。

第一步：会话隔离 —— 让 Agent 有"自己的房间"

核心配置：

"session": {
  "dmScope": "per-account-channel-peer"
}

什么意思？

每个 Agent 必须有自己独立的会话空间，就像每个人有自己的办公室。不能让所有 Agent 挤在一个房间里，那样会互相干扰。

per-account-channel-peer 的意思是：按"账号 + 渠道 + 发送者"隔离，确保每个飞书账号的私聊独立存储。

可选的隔离策略：

策略	适用场景	推荐度
`main`	所有私聊共享	⭐
`per-peer`	按发送者隔离	⭐⭐
`per-channel-peer`	按渠道 + 发送者隔离	⭐⭐⭐
`per-account-channel-peer`	按账号 + 渠道 + 发送者隔离	⭐⭐⭐⭐⭐

划重点： 生产环境一定要用最后一个，否则消息会串。

第二步：会话可见 —— 让 Agent 能"看见"彼此

核心配置：

"tools": {
  "sessions": {
    "visibility": "all"
  }
}

什么意思？

Agent 之间要通信，首先得知道对方存在。

visibility: all 表示所有 Agent 都能访问会话列表，这样 A Agent 才能找到 B Agent，才能发消息给它。

如果设为 agent，那就成了信息孤岛，各干各的。

第三步：权限控制 —— 明确"谁能跟谁说话"

这是最核心的一步，也是大多数人踩坑的地方。

核心配置：

"channels": {
  "feishu": {
    "accounts": {
      "agent-a": {
        "dmPolicy": "allowlist",
        "allowFrom": ["user1", "user2"]
      },
      "agent-b": {
        "dmPolicy": "allowlist", 
        "allowFrom": ["user1", "user3"]
      }
    }
  }
}

什么意思？

dmPolicy 是权限策略，有 4 个选项：

策略	说明	适用场景
`pairing`	需要配对码（默认）	个人使用
`allowlist`	白名单制	团队协作
`open`	允许所有人	公开服务
`disabled`	关闭私聊	纯群聊

allowFrom 是白名单列表，里面放的是用户 ID。只有列表里的人，才能给这个 Agent 发消息。

举个例子：

假设你的团队有 3 个人：张三、李四、王五。

Agent A（内容创作）：只允许张三、李四使用
Agent B（代码开发）：只允许张三、王五使用
Agent C（数据分析）：三个人都能用

这样配置，就不会出现"不该用这个 Agent 的人乱发消息"的情况。

完整配置示例

下面是一个 3 人团队跑通的完整配置，你可以直接参考：

{
  "session": {
    "dmScope": "per-account-channel-peer"
  },
  "tools": {
    "sessions": {
      "visibility": "all"
    },
    "agentToAgent": {
      "enabled": true,
      "agents": ["content-agent", "code-agent", "data-agent"]
    }
  },
  "channels": {
    "feishu": {
      "accounts": {
        "content-agent": {
          "dmPolicy": "allowlist",
          "allowFrom": ["user-zhang", "user-li"]
        },
        "code-agent": {
          "dmPolicy": "allowlist",
          "allowFrom": ["user-zhang", "user-wang"]
        },
        "data-agent": {
          "dmPolicy": "allowlist",
          "allowFrom": ["user-zhang", "user-li", "user-wang"]
        }
      }
    }
  }
}

配置完记得重启：

openclaw gateway restart

多 Agent 协作的典型场景

配置完成后，你的团队可以这样协作。下面三个场景，都是我用这套方案跑通的真实案例。

场景一：内容创作流水线（30 分钟出稿）

业务需求：

做内容的朋友都知道，写一篇合格的文章需要经过：找热点 → 写初稿 → 做配图 → 取标题 → 发平台。这 5 个环节，传统模式下一个人要干 4 小时，而且质量不稳定。

团队痛点：

热点不等人，等你写完，热度已经过了
设计师排期慢，文章写好了等图等半天
标题靠感觉，不知道哪个标题点击率高
发多个平台要手动复制粘贴，容易出错

多 Agent 解决方案：

我配置了一个 3-Agent 协作小组：

你只用说一句话：

"今天有什么 AI 热点值得写？写好后配图发我审核。"

接下来 Agent 们自动分工协作：

热点 Agent 收到指令，开始全网搜索：「搜索 AI 领域 48 小时内热点 → 筛选 3 个高潜力选题 → 评估冲突点和传播价值」
热点 Agent 把选题推给 创作 Agent：「选题已确定：《GPT-5 发布，这 3 个变化最值得关注》，开始创作」
创作 Agent 并行执行：「撰写 2000 字深度文章 → 生成 3 个备选标题 → 提取文章关键词」
创作 Agent 通知 设计 Agent：「需要配图，主题：GPT-5 与人工智能发展，暖白色调，科技感」
设计 Agent 生成图片后回传：「配图已完成，尺寸 1664×928，已上传云存储」
创作 Agent 汇总所有产出，推送给用户：「文章已完成，标题 3 选 1，配图已生成，请审核发布」

效果：

原本 4 小时的串行工作，现在 30 分钟并行完成。你只需要在最后审核点个头。

场景二：代码开发协作（2 小时上线）

业务需求：

产品经理提了一个需求："在后台加个数据导出功能，支持 Excel 和 CSV 两种格式。"

传统流程：产品写 PRD → 评审会议 → 前后端开发 → 接口联调 → 测试 → 上线。这一套下来，快则 2 天，慢则一周。

团队痛点：

需求理解不一致，前后端各做各的，联调时发现接口对不上
文档更新慢，开发过程中需求变了，文档还是旧的
测试用例写不完，上线后总是出 bug

多 Agent 解决方案：

配置 4-Agent 开发小组：

产品经理说一句话：

"后台需要数据导出功能，支持 Excel 和 CSV，用户是运营同事。"

Agent 们自动协作：

产品 Agent 解析需求，生成 PRD：「功能名称：数据导出模块 → 用户场景：运营数据备份 → 验收标准：支持 10 万行数据导出 → API 设计：/api/export/data?format=excel|csv」
产品 Agent 同时通知 前端 Agent 和 后端 Agent：「需求已就绪，PRD 已生成，开始并行开发」
前端 Agent 生成代码：「导出按钮组件 → 格式选择弹窗 → 下载进度条 → 错误提示处理」
后端 Agent 生成代码：「导出接口 /api/export/data → Excel 生成逻辑 → CSV 生成逻辑 → 异步任务处理 → 大文件分片」
后端 Agent 主动通知 前端 Agent：「接口地址确认：POST /api/export/data，请求参数：{format, filters, columns}，返回：{downloadUrl, expiresAt}」
前端 Agent 收到接口定义，立即调整：「已对接后端接口 → 更新 API 调用代码 → 联调完成」
代码 Agent（质检角色）介入：「检查前后端接口兼容性 → 检查代码规范 → 生成单元测试 → 发现 2 处潜在问题，已修复」
产品 Agent 汇总上线 checklist：「功能已完成 → 测试通过 → 文档已更新 → 可上线」

效果：

从需求到上线，2 小时搞定。而且因为 Agent 之间实时同步接口定义，前后端不会出现"对接不上"的情况。

场景三：数据决策支持（日报自动生成）

业务需求：

运营负责人每天早上 9 点要看数据日报，包括：昨日销售额、各渠道转化率、异常指标预警、今日行动建议。

传统方式：运营专员每天早上 8 点到公司，手工导出数据 → Excel 做透视表 → 写分析报告 → 发邮件。这至少要 1 小时，而且容易漏掉异常点。

团队痛点：

数据散落在 5 个平台（抖音、淘宝、京东、小程序、公众号），手工汇总太麻烦
异常指标发现不及时，等发现问题已经损失了不少
分析报告写得慢，老板等着看数据

多 Agent 解决方案：

配置 3-Agent 数据小组，每天早上 8:30 自动运行：

定时任务触发（无需人工指令）：

采集 Agent 自动执行：「连接 5 个平台 API → 拉取昨日数据 → 清洗异常值 → 汇总到数据仓库」
采集 Agent 通知 分析 Agent：「数据采集完成，开始分析」
分析 Agent 深度分析：「计算核心指标 → 对比历史同期 → 识别异常波动（转化率下降 15%）→ 归因分析（抖音渠道流量质量下降）」
分析 Agent 生成结论：「昨日 GMV 12.5 万（-5%），主要受抖音渠道影响；淘宝转化正常；建议今日加大淘宝投放，减少抖音预算」
分析 Agent 推送 运营 Agent：「发现异常，生成应对方案」
运营 Agent 生成行动建议：「今日优化策略：①淘宝直通车加投 20% ②抖音暂停新计划 ③社群促销激活老用户 ④预计挽回 3 万 GMV」
运营 Agent 生成日报推送决策者：「数据日报已生成：昨日 GMV 12.5 万，异常已识别，优化方案已制定，点击查看详情」

决策者收到的是这样一份日报：

📊 昨日数据概览

GMV：12.5 万（环比 -5%）

订单数：320 单（环比 -2%）

客单价：390 元（环比 -3%）

⚠️ 异常预警

抖音渠道转化率下降 15%（需关注）

✅ 今日行动

淘宝投放 +20%

抖音暂停新计划

预计挽回 GMV：3 万

效果：

运营从"看数据写报告"变成"直接看结论做决策"。而且因为 Agent 7×24 小时监控，异常发现时间从 1 天缩短到 10 分钟。

懂我意思吗？

多 Agent 不是把一个人变成多个人，而是让多个专业领域能同时开工。

就像流水线上的工人，每个人都有自己的工位和职责，但产品是流动的、协作是连续的。

关键是：配置好规则，Agent 就能自己协作。你只需要在关键节点做决策。

懂我意思吗？

多 Agent 不是把一个人变成多个人，而是让多个专业领域能同时开工。

就像流水线上的工人，每个人都有自己的工位和职责，但产品是流动的、协作是连续的。

验证配置是否成功

配置完别急着用，先验证一下，直接在终端窗口输入下面的shell代码，可以看到每个agent的会话记录：

# 查看各 Agent 的私聊会话
for agent in content-agent code-agent data-agent; do
  echo "=== $agent ==="
  cat ~/.openclaw/agents/$agent/sessions/sessions.json | \
    jq 'keys[] | select(test("direct:"))'
done

如果看到 direct:ou_xxxxx 格式的会话，说明私聊通信正常。

常见坑：