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

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

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

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

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

SOUL.md：它的性格、表达风格、做事边界
USER.md：它服务谁、用什么沟通方式
AGENTS.md：它的职责和协作规则
问题在这儿：
如果定位太宽，三件套就会非常难调。 你会遇到这些典型问题：

一会儿像技术顾问，一会儿像营销号，风格漂移
同一个需求，今天做得好，明天做歪（不稳定）
提示词越补越多，系统越来越难维护
所以正确做法不是“让一个 Agent 无所不能”，而是“让每个 Agent 各司其职”。

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

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

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

这时候就需要多 Agent 协作。

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

选题规划（写什么）
内容生产（怎么写）
数据运营（发完怎么优化）
这三段能力模型完全不同，强行塞进一个 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 个坑（提前避掉）

Agent 定位重叠

两个 Agent 都在“写内容”，最后谁都不稳定
没有群白名单

机器人被拉进新群后，容易误触发
workspace 复用

多 Agent 共用一个 workspace，会互相污染记忆
先堆功能，后做边界

正确顺序是：先定角色边界，再加能力
七、综上所述
多 Agent 的本质不是“多开几个机器人”，而是把复杂工作拆成多个可调、可控、可复用的角色系统。

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

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

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

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

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

二维码放下面了，直接加我就行。

备注一下【OpenClaw】，我看到会优先通过。