OpenClaw 多 Agent + 飞书多 Bot 路由配置实战复盘
<blockquote><p>说明：本文由 OpenClaw 助手根据一次真实配置与排障过程辅助整理，内容经过人工确认。</p>
</blockquote>
<p>最近在 OpenClaw 里做了一次多 Agent、多飞书 Bot 的配置：新建一个独立的 agent profile <code><agent-b-id></code>，并让一个新的飞书机器人专门路由到这个 agent，同时保留原来的默认机器人继续服务主 agent。</p>
<p>这篇记录一下完整过程、踩坑点和最终结论。</p>
<h2 id="目标">目标</h2>
<p>原始状态：</p>
<ul>
<li>一个 OpenClaw Gateway</li>
<li>一个默认 agent：<code>main</code></li>
<li>一个默认飞书 bot：<code>default</code></li>
</ul>
<p>目标状态：</p>
<ul>
<li>保留 <code>default</code> bot → <code>main</code> agent</li>
<li>新增第二个 agent</li>
<li>新增第二个飞书 bot</li>
<li>新 bot 收到的消息自动路由到 第二个 agent</li>
</ul>
<p>最终路由关系：</p>
<pre><code class="language-text">Feishu default bot -> agent: main
Feishu bot B -> agent: <agent-b-id>
</code></pre>
<h2 id="1-创建新的-agent-profile">1. 创建新的 Agent Profile</h2>
<p>先新增 agent：</p>
<pre><code class="language-bash">openclaw agents add <agent-b-id> --workspace <agent-b-workspace>
</code></pre>
<p>如果不走交互式，也可以直接在配置里添加：</p>
<pre><code class="language-json5">{
agents: {
list: [
{ id: "main", workspace: "<main-workspace>", default: true },
{ id: "<agent-b-id>", workspace: "<agent-b-workspace>" }
]
}
}
</code></pre>
<p>同时给新 workspace 准备基础身份文件，例如：</p>
<pre><code class="language-text"><agent-b-workspace>/IDENTITY.md
<agent-b-workspace>/SOUL.md
<agent-b-workspace>/AGENTS.md
</code></pre>
<h2 id="2-配置飞书多账号">2. 配置飞书多账号</h2>
<p>飞书插件支持 multi-account，但这里有一个关键点：</p>
<p><strong>default bot 的 appId/appSecret 需要继续保留在 <code>channels.feishu</code> 顶层。</strong></p>
<p>也就是说，不应该把 default bot 完全迁移到 <code>accounts.default</code>。正确结构类似：</p>
<pre><code class="language-json5">{
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"
}
}
}
}
}
</code></pre>
<p>一开始我把旧 bot 放进了 <code>accounts.default</code>，结果 default bot 在 runtime 里显示 <code>not configured</code>。修正后，两个 bot 都恢复正常。</p>
<h2 id="3-添加路由绑定">3. 添加路由绑定</h2>
<p>在 <code>bindings</code> 里把不同 Feishu account 绑定到不同 agent：</p>
<pre><code class="language-json5">{
bindings: [
{
agentId: "main",
match: {
channel: "feishu",
accountId: "default"
}
},
{
agentId: "<agent-b-id>",
match: {
channel: "feishu",
accountId: "<account-b>"
}
}
]
}
</code></pre>
<p>验证：</p>
<pre><code class="language-bash">openclaw agents list --bindings
openclaw channels status --probe
</code></pre>
<p>期望看到：</p>
<pre><code class="language-text">Feishu default: enabled, configured, running, works
Feishu account B: enabled, configured, running, works
</code></pre>
<h2 id="4-新飞书应用权限配置">4. 新飞书应用权限配置</h2>
<p>飞书开放平台里，新 bot 至少要完成：</p>
<ol>
<li>创建企业自建应用</li>
<li>开启机器人能力</li>
<li>事件订阅使用长连接 / WebSocket</li>
<li>添加消息接收事件：<code>im.message.receive_v1</code></li>
<li>开通发送消息权限</li>
<li>发布版本并安装/升级到企业</li>
</ol>
<p>这次最主要的权限坑是：新 bot 能收到消息，但不能回复。</p>
<p>Feishu API 返回：</p>
<pre><code class="language-text">code: 99991672
Access denied. One of the following scopes is required:
im:message:send, im:message, im:message:send_as_bot
</code></pre>
<p>也就是说，除了接收消息事件，必须开通发送消息权限。实际开通 <code>im:message:send_as_bot</code> 后，发送验证通过。</p>
<h2 id="5-pairing-模式下的首条消息">5. Pairing 模式下的首条消息</h2>
<p>当前 Feishu DM policy 是 pairing 模式。新 bot 第一次收到陌生用户 DM 时，不会直接进入 agent，而是生成 pairing request。</p>
<p>需要执行：</p>
<pre><code class="language-bash">openclaw pairing list --channel feishu --account <account-b>
openclaw pairing approve feishu <CODE> --account <account-b>
</code></pre>
<p>否则用户侧看起来就是“发了消息但没反应”。</p>
<h2 id="6-最终验证">6. 最终验证</h2>
<p>最终验证链路：</p>
<ol>
<li>用户给 bot B 发消息</li>
<li>OpenClaw 日志显示：</li>
</ol>
<pre><code class="language-text">feishu: received message ...
feishu: dispatching to agent
session=agent:<agent-b-id>:feishu:direct:...
</code></pre>
<ol start="3">
<li>agent 生成回复</li>
<li>bot B 成功发送回复</li>
<li>用户在飞书客户端收到消息</li>
</ol>
<p>最终状态：</p>
<pre><code class="language-text">Gateway: running / probe ok
Feishu default: running / works
Feishu account B: running / works
Routing:
default -> main
account B -> agent B
</code></pre>
<h2 id="经验总结">经验总结</h2>
<p>这次配置里最重要的几个经验：</p>
<ol>
<li>
<p><strong>Feishu multi-account 下，default bot 不要完全迁移到 <code>accounts.default</code>。</strong><br>
default bot 的凭据要保留在 <code>channels.feishu.appId/appSecret</code> 顶层。</p>
</li>
<li>
<p><strong>新飞书 bot 能收消息不代表能回消息。</strong><br>
发送消息需要额外开通 <code>im:message:send_as_bot</code> 等权限，并发布/升级应用。</p>
</li>
<li>
<p><strong>Pairing 模式会让首条 DM 看起来像“没反应”。</strong><br>
实际是消息被拦截等待批准，需要 <code>pairing approve</code>。</p>
</li>
<li>
<p><strong>调试时要分层验证。</strong></p>
<ul>
<li>bot 是否 websocket 在线</li>
<li>是否收到 inbound message</li>
<li>是否通过 pairing / allowlist</li>
<li>是否 dispatch 到正确 agent</li>
<li>agent 是否生成回复</li>
<li>Feishu send API 是否成功</li>
</ul>
</li>
<li>
<p><strong>日志比直觉可靠。</strong><br>
这次几个问题都不是“模型没回”，而分别是 routing config、pairing、Feishu scope 权限问题。</p>
</li>
</ol>
<p>整体来看，OpenClaw 的多 Agent + 多 Bot 路由机制是可行的，但飞书插件的 default account 兼容细节和飞书开放平台权限发布流程需要特别注意。</p><br><br>
来源：https://www.cnblogs.com/LexLuc/p/19969852/openclaw-multi-agent-feishu-bots 看到这么详细的复盘贴，必须来支持下！
之前我也折腾过OpenClaw的多Bot配置，不过没搞这么复杂，看了你的帖子才发现原来还有这么多坑。
飞书 multi-account 下，default bot 不要完全迁移到 accounts.default
这个坑估计很多人都会踩，包括我之前也是把default bot移到了accounts下面，结果一直显示not configured，还以为是版本bug...
另外那个权限问题也很典型，之前帮朋友配置飞书机器人，也是只开了接收消息事件，结果用户说能发消息但收不到回复，查半天发现是发送权限没开。
code: 99991672
Access denied. One of the following scopes is required: im:message:send, im:message, im:message:send_as_bot
这个错误信息确实不够直观，飞书开放平台的权限体系确实比较复杂。
总结得很到位，特别是最后那条"日志比直觉可靠"，做系统集成真的就是这样的——大多数时候出问题都不是模型的问题，而是各种配置、权限、路由的细节。
感谢分享！这种实战复盘对社区很有价值，期待更多这样的帖子～
[*]已收藏
[*]给楼主加个分
这篇实战复盘太刚需了！我最近刚好在做类似的多bot分流配置，试了好几次新bot的消息都还是会跑到默认agent那里，卡了快两天都没找到问题出在哪，蹲一个后续的踩坑点和完整配置示例！顺便想问下同时接多个飞书bot的话，要不要提前给Gateway做什么额外的性能配置呀？ 楼主分享的这个主题确实很实用！多bot路由配置在实操中容易卡在消息分流上，常见原因是路由规则里bot ID或agent映射没设准。建议一步步核对Gateway配置，确保新bot的入口和agent绑定是独立的，别和默认混了。
关于性能配置，同时接多个飞书bot时，如果Gateway资源充足（比如内存和CPU留有余量），一般不用提前大调，但最好监控一下连接数和响应时间，必要时可以调整线程池大小。等原帖的完整示例出来，咱们再对照看看细节。
加油，期待更多讨论！ 多bot路由配置确实容易踩坑，你遇到的问题很典型！新bot消息跑到默认agent，通常是因为网关的路由映射没设对，得确保新bot的ID在配置里明确绑定到新建的agent profile，而不是走默认路由。
踩坑点方面，除了路由绑定，还要注意飞书bot的webhook地址和网关接收端点是否匹配，以及agent profile里的权限设置是否完整。配置示例建议按步骤来：先创建新agent profile并测试基础功能，再部署新bot并网关里添加路由规则，最后用新bot发消息验证分流是否生效。
性能配置上，网关默认能处理多bot连接，一般不用额外调优。但如果消息并发量很高，可以留意网关的日志和资源监控，必要时调整线程池或缓存设置。
祝你顺利搞定！如果还有具体配置卡住，欢迎贴出细节，大伙儿一起帮你看看。
頁:
[1]