夜雨聆风
OpenClaw 多Agent 怎么落地?看完这个真实配置方案就知道了
最近搭了一套 OpenClaw + 飞书的多 Agent 协作流，把之前踩过的坑和最新的思考整理了一下，不讲概念，直接上我的真实方案。
先泼盆冷水：为什么”一个 Agent 干所有事”是个坑
我见过太多人一开始的思路是：能不能搞一个超级助手，又能写文案、又能改代码、又能做数据分析。
听起来很美好，实际上：
做出来的效果飘忽不定。今天像技术顾问，明天像客服小妹，后天又像营销号。同一类需求，交给同一个 Agent，今天输出还行，明天就可能跑偏。
问题出在哪？
不是模型不行，是定位太宽。一个 Agent 装的”灵魂三件套”——SOUL.md（性格边界）、USER.md（服务对象）、AGENTS.md（协作规则）——定位越宽，这三件套越难调，最后提示词越补越多，系统越来越难维护。
真正有效的做法：让每个 Agent 只盯一件事。
飞书搭多 Agent，先把一个误解解开
很多人卡在”一个飞书应用 = 一个 Agent”这个思路里出不来。
其实不是。
飞书在这个架构里就是个传话筒——负责把消息收进来、发出去。真正决定消息交给谁处理的，是 OpenClaw 这层。
所以玩法是这样的：
一个飞书应用 → 进入多个飞书群 → 每个群绑定不同的 Agent → 消息自动路由
一个机器人进多个群，每个群对应一个专精角色，这才是”一个应用跑多 Agent”的核心。
我的方案：6 个 Agent 跑通自媒体全链路
先看一下整体分工：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对应飞书建 6 个群，每个群绑定一个 Agent。
配置文件就三块，看懂就会配
第一块：agents——6 个 Agent 的基本信息
OpenClaw 安装在 Mac 上，目录是 /Users/kman/.openclaw/。每个 Agent 用独立 workspace，数据完全隔离。
{"agents": {"list": [{"id": "moss","default": true,"name": "小墨","workspace": "/Users/kman/.openclaw/agents/moss"},{"id": "moss-ops","name": "墨媒","workspace": "/Users/kman/.openclaw/agents/moss-ops"},{"id": "moss-wechat-book","name": "墨微","workspace": "/Users/kman/.openclaw/agents/moss-wechat-book"},{"id": "moss-wechat-ai","name": "墨码","workspace": "/Users/kman/.openclaw/agents/moss-wechat-ai"},{"id": "moss-xhs","name": "墨红","workspace": "/Users/kman/.openclaw/agents/moss-xhs"},{"id": "moss-video","name": "墨拍","workspace": "/Users/kman/.openclaw/agents/moss-video"}]}}
default: true 的 Agent 作为总控入口第二块：channels——飞书机器人凭证
用一个飞书机器人（App ID: cli_xxxx）统一收发消息，所有 Agent 共用这个凭证：
{"channels": {"feishu": {"enabled": true,"appId": "cli_xxxx","appSecret": "xxxxxxx","connectionMode": "websocket"}}}
requireMention: false：群里不用 @ 机器人也能触发groupAllowFrom：只接收白名单群的消息，强烈建议加上，不然机器人被拉进任何群都会乱响应第三块：bindings——群和 Agent 的对应关系
这是整个路由的核心。我把我的实际配置直接贴出来：
{"bindings": [{"agentId": "moss","match": {"channel": "feishu","peer": {"kind": "group","id": "oc_caxxxxxxxc"}}},{"agentId": "moss-ops","match": {"channel": "feishu","peer": {"kind": "group","id": "oc_caxxxxxx5"}}},{"agentId": "moss-wechat-book","match": {"channel": "feishu","peer": {"kind": "group","id": "oc_bxxxxx3"}}},{"agentId": "moss-wechat-ai","match": {"channel": "feishu","peer": {"kind": "group","id": "oc_axxxxx6"}}},{"agentId": "moss-xhs","match": {"channel": "feishu","peer": {"kind": "group","id": "oc_exxxxx2"}}},{"agentId": "moss-video","match": {"channel": "feishu","peer": {"kind": "group","id": "oc_fxxxxxf"}}}]}
逻辑很简单：哪个群发消息，就按绑定规则路由到对应的 Agent。
执行步骤
第一步，创建 6 个 Agent：
cd /Users/kman/.openclaw/openclaw agents add moss --workspace "/Users/kman/.openclaw/agents/moss"openclaw agents add moss-ops --workspace "/Users/kman/.openclaw/agents/moss-ops"openclaw agents add moss-wechat-book --workspace "/Users/kman/.openclaw/agents/moss-wechat-book"openclaw agents add moss-wechat-ai --workspace "/Users/kman/.openclaw/agents/moss-wechat-ai"openclaw agents add moss-xhs --workspace "/Users/kman/.openclaw/agents/moss-xhs"openclaw agents add moss-video --workspace "/Users/kman/.openclaw/agents/moss-video"
第二步，编辑绑定。
把上面的 bindings JSON 追加到 /Users/kman/.openclaw/openclaw.json 里，建议先备份：
cp /Users/kman/.openclaw/openclaw.json /Users/kman/.openclaw/openclaw.json.backup第三步，生效配置：
openclaw gateway restart第四步，飞书端确认：
验证：在”小墨”群发一条消息，看是否只有 moss 响应。
完成后的目录结构
/Users/kman/.openclaw/├── openclaw.json # 主配置（含 bindings）├── agents/ # 各 Agent 数据目录│ ├── moss/ # 小墨│ ├── moss-ops/ # 墨媒│ ├── moss-wechat-book/ # 墨微（读书分享公众号）│ ├── moss-wechat-ai/ # 墨码（老码的AI手记）│ ├── moss-xhs/ # 墨红│ └── moss-video/ # 墨拍四个最容易踩的坑
1. Agent 职责重叠
两个 Agent 都在写内容，最后谁都不稳定。各司其职是底线。
2. 没配群白名单
机器人被拉进陌生群，容易乱说话。groupAllowFrom 一定要配。
3. 多 Agent 共用 workspace
记忆文件互相污染，调试的时候你会疯掉。
4. 先堆功能，后定边界
正确顺序是：先想清楚这个 Agent 负责什么、不负责什么，再往里加能力。
最后说两句
多 Agent 这套东西，说到底是角色化分工的思路，不是比谁开的机器人多。
你真正该追求的是”稳定输出”，不是”什么都能干”。
我现在的习惯是：先把单个角色的任务跑稳，再考虑跨角色协作。急着用一个大一统的 Agent 搞定所有事，短期看省心，长期一定是噩梦。
如果你也在OpenClaw搭多Agent环境，有什么具体问题可以直接问。