说明：本文由 OpenClaw 助手根据一次真实配置与排障过程辅助整理，内容经过人工确认。
最近在 OpenClaw 里做了一次多 Agent、多飞书 Bot 的配置：新建一个独立的 agent profile <agent-b-id>，并让一个新的飞书机器人专门路由到这个 agent，同时保留原来的默认机器人继续服务主 agent。
这篇记录一下完整过程、踩坑点和最终结论。
目标
原始状态：
- 一个 OpenClaw Gateway
- 一个默认 agent：
main
- 一个默认飞书 bot：
default
目标状态：
- 保留
default bot → main agent
- 新增第二个 agent
- 新增第二个飞书 bot
- 新 bot 收到的消息自动路由到 第二个 agent
最终路由关系：
Feishu default bot -> agent: main
Feishu bot B -> agent: <agent-b-id>
1. 创建新的 Agent Profile
先新增 agent：
openclaw agents add <agent-b-id> --workspace <agent-b-workspace>
如果不走交互式，也可以直接在配置里添加：
{
agents: {
list: [
{ id: "main", workspace: "<main-workspace>", default: true },
{ id: "<agent-b-id>", workspace: "<agent-b-workspace>" }
]
}
}
同时给新 workspace 准备基础身份文件，例如：
<agent-b-workspace>/IDENTITY.md
<agent-b-workspace>/SOUL.md
<agent-b-workspace>/AGENTS.md
2. 配置飞书多账号
飞书插件支持 multi-account，但这里有一个关键点：
default bot 的 appId/appSecret 需要继续保留在 channels.feishu 顶层。
也就是说，不应该把 default bot 完全迁移到 accounts.default。正确结构类似：
{
channels: {
feishu: {
enabled: true,
domain: "feishu",
connectionMode: "websocket",
// default bot 仍然放顶层
appId: "cli_default_xxx",
appSecret: "***",
defaultAccount: "default",
accounts: {
"<account-b>": {
appId: "cli_bot_b_xxx",
appSecret: "***",
name: "Bot B"
}
}
}
}
}
一开始我把旧 bot 放进了 accounts.default，结果 default bot 在 runtime 里显示 not configured。修正后，两个 bot 都恢复正常。
3. 添加路由绑定
在 bindings 里把不同 Feishu account 绑定到不同 agent：
{
bindings: [
{
agentId: "main",
match: {
channel: "feishu",
accountId: "default"
}
},
{
agentId: "<agent-b-id>",
match: {
channel: "feishu",
accountId: "<account-b>"
}
}
]
}
验证：
openclaw agents list --bindings
openclaw channels status --probe
期望看到：
Feishu default: enabled, configured, running, works
Feishu account B: enabled, configured, running, works
4. 新飞书应用权限配置
飞书开放平台里，新 bot 至少要完成：
- 创建企业自建应用
- 开启机器人能力
- 事件订阅使用长连接 / WebSocket
- 添加消息接收事件：
im.message.receive_v1
- 开通发送消息权限
- 发布版本并安装/升级到企业
这次最主要的权限坑是：新 bot 能收到消息，但不能回复。
Feishu API 返回：
code: 99991672
Access denied. One of the following scopes is required:
im:message:send, im:message, im:message:send_as_bot
也就是说，除了接收消息事件，必须开通发送消息权限。实际开通 im:message:send_as_bot 后，发送验证通过。
5. Pairing 模式下的首条消息
当前 Feishu DM policy 是 pairing 模式。新 bot 第一次收到陌生用户 DM 时，不会直接进入 agent，而是生成 pairing request。
需要执行：
openclaw pairing list --channel feishu --account <account-b>
openclaw pairing approve feishu <CODE> --account <account-b>
否则用户侧看起来就是“发了消息但没反应”。
6. 最终验证
最终验证链路：
- 用户给 bot B 发消息
- OpenClaw 日志显示：
feishu[account-b]: received message ...
feishu[account-b]: dispatching to agent
session=agent:<agent-b-id>:feishu:direct:...
- agent 生成回复
- bot B 成功发送回复
- 用户在飞书客户端收到消息
最终状态：
Gateway: running / probe ok
Feishu default: running / works
Feishu account B: running / works
Routing:
default -> main
account B -> agent B
经验总结
这次配置里最重要的几个经验：
-
Feishu multi-account 下，default bot 不要完全迁移到 accounts.default。
default bot 的凭据要保留在 channels.feishu.appId/appSecret 顶层。
-
新飞书 bot 能收消息不代表能回消息。
发送消息需要额外开通 im:message:send_as_bot 等权限，并发布/升级应用。
-
Pairing 模式会让首条 DM 看起来像“没反应”。
实际是消息被拦截等待批准，需要 pairing approve。
-
调试时要分层验证。
- bot 是否 websocket 在线
- 是否收到 inbound message
- 是否通过 pairing / allowlist
- 是否 dispatch 到正确 agent
- agent 是否生成回复
- Feishu send API 是否成功
-
日志比直觉可靠。
这次几个问题都不是“模型没回”，而分别是 routing config、pairing、Feishu scope 权限问题。
整体来看，OpenClaw 的多 Agent + 多 Bot 路由机制是可行的，但飞书插件的 default account 兼容细节和飞书开放平台权限发布流程需要特别注意。
来源：https://www.cnblogs.com/LexLuc/p/19969852/openclaw-multi-agent-feishu-bots |
發表於 2026-5-4 00:42:00
