一篇讲透：OpenClaw 在飞书里怎么配多 Agent

小龙虾的效果，不取决于“模型多强”，而取决于“定位是否清晰”。所以多 Agent 不是花活，而是把复杂工作拆成可控模块。

一、为什么一定要配多 Agent？

很多人一上来就想要一个“万能小龙虾”： 既能写文章、又能改代码、还能做运营复盘。

听起来很爽，但实际很容易翻车。

因为一个 Agent 的工作效果，本质上是被这套“灵魂三件套”约束的：

• SOUL.md：它的性格、表达风格、做事边界
• USER.md：它服务谁、用什么沟通方式
• AGENTS.md：它的职责和协作规则

问题在这儿：

如果定位太宽，三件套就会非常难调。 你会遇到这些典型问题：

• 一会儿像技术顾问，一会儿像营销号，风格漂移
• 同一个需求，今天做得好，明天做歪（不稳定）
• 提示词越补越多，系统越来越难维护

所以正确做法不是“让一个 Agent 无所不能”，而是“让每个 Agent 各司其职”。

二、定位做细了，能力会不会变窄？

会。

但这不是缺点，这是工程化取舍。

你把单个 Agent 定位越细，它越稳定； 但单个 Agent 能覆盖的任务范围，也会越小。

这时候就需要多 Agent 协作。

比如你做公众号这件事，至少是三段工作链路：

1. 选题规划（写什么）
2. 内容生产（怎么写）
3. 数据运营（发完怎么优化）

这三段能力模型完全不同，强行塞进一个 Agent，后期一定难调。

三、飞书不是“一个应用=一个 Agent”吗？

这是很多人卡住的点。

飞书侧确实是：

• 一个应用，通常对应一个机器人

但 OpenClaw 的架构里，飞书只是最外层消息通道。

所以你可以这样理解：

• 飞书应用：负责“收发消息”
• OpenClaw：负责“把消息路由给哪个 Agent”

核心玩法

一个飞书应用 + 一个机器人 + 多个飞书群 + OpenClaw 绑定规则

也就是：

• 一个机器人进多个群
• 每个群绑定不同 Agent
• 不同群发来的消息，自动路由到不同 Agent

这就是“一个飞书应用跑多 Agent”的关键。

四、配置只看 3 个地方：agents / channels / bindings

1）agents：定义你有多少个小龙虾

这部分就是 Agent 清单。

{
  "agents": {
    "list": [
      {
        "id": "main",
        "default": true,
        "name": "主agent",
        "workspace": "/root/.openclaw/workspace"
      },
      {
        "id": "dev",
        "name": "开发助理",
        "workspace": "/root/.openclaw/workspace-dev"
      },
      {
        "id": "content",
        "name": "内容助理",
        "workspace": "/root/.openclaw/workspace-content"
      },
      {
        "id": "ops",
        "name": "运营增长",
        "workspace": "/root/.openclaw/workspace-ops"
      }
    ]
  }
}

实操建议：

• 每个 Agent 用独立 workspace（方便沉淀各自记忆）
• 每个 Agent 只做一类事（不要混岗）
• 保留一个 main 作为总控

2）channels：定义 OpenClaw 接了哪些消息渠道

{
  "channels": {
    "feishu": {
      "enabled": true,
      "appId": "xxxxxxxxxxxx",
      "appSecret": "XXXXXXXXX",
      "domain": "feishu",
      "groupPolicy": "open",
      "groupAllowFrom": [
        "群1id",
        "群2id",
        "群3id"
      ],
      "requireMention": false
    },
    "wechat-access": {
      "enabled": true,
      "wsUrl": "wss://mmgrcalltoken.3g.qq.com/agentwss"
    }
  }
}

你这个配置里，说明已经接了飞书 + 微信两个渠道。

两个关键参数：

• requireMention: false
  • 在群里不用 @机器人 也能触发
• groupAllowFrom
  • 只接收白名单群消息（强烈建议开）

❝小提醒：你草稿里写了 fasle，发文时记得改成 false。

3）bindings：把“群”和“Agent”绑起来

这部分是整个多 Agent 路由的核心。

{
  "bindings": [
    {
      "agentId": "content",
      "match": {
        "channel": "feishu",
        "peer": {
          "kind": "group",
          "id": "群1id"
        }
      }
    },
    {
      "agentId": "dev",
      "match": {
        "channel": "feishu",
        "peer": {
          "kind": "group",
          "id": "群2id"
        }
      }
    },
    {
      "agentId": "ops",
      "match": {
        "channel": "feishu",
        "peer": {
          "kind": "group",
          "id": "群3id"
        }
      }
    }
  ]
}

一句话解释：

哪个群发消息进来，就按绑定规则，交给对应 Agent 处理。其实就是群和agent的对应关系

五、一套可直接落地的公众号团队分工

如果你要做“内容闭环”，我建议先用这 3 个 Agent：

• planner：选题与发布节奏
• writer：正文写作与改稿
• ops：标题测试、数据复盘、二次分发

对应飞书建 3 个群：

• 选题群 → 绑定 planner
• 写作群 → 绑定 writer
• 运营群 → 绑定 ops

这样做的好处是：

• 讨论上下文不串台
• 每个 Agent 的三件套更容易调
• 后续扩容（比如短视频 Agent）也简单

六、容易踩的 4 个坑（提前避掉）

1. Agent 定位重叠
   • 两个 Agent 都在“写内容”，最后谁都不稳定
2. 没有群白名单
   • 机器人被拉进新群后，容易误触发
3. workspace 复用
   • 多 Agent 共用一个 workspace，会互相污染记忆
4. 先堆功能，后做边界
   • 正确顺序是：先定角色边界，再加能力

七、综上所述

多 Agent 的本质不是“多开几个机器人”，而是把复杂工作拆成多个可调、可控、可复用的角色系统。

你要的是“稳定交付”，不是“万能人设”。

我现在调 Agent 的思路很简单： 先把单点任务做稳定，再谈跨角色协作。

以前我也试过把所有事塞进一个 Agent，短期看省事，长期看就是灾难。 后面拆成角色后，提示词长度下降了，输出稳定性反而上来了。

如果你看到这，说明你是真的在做事，不是只看热闹。

你要是也想把 OpenClaw 多 Agent 这套跑顺，我把我自己正在用的配置和踩坑经验，慢慢分享给你。