夜雨聆风
OpenClaw 企业微信与飞书多机器人配置详解
一、引言：为什么需要多机器人、多 Agent 架构？
当一个 AI 助手同时承担”写代码”、”做评审”、”搜索调研”、”架构设计”等多项职责时，上下文互相污染、角色定位模糊等问题会迅速浮现。更现实的诉求是——不同场景由不同的 AI 角色来服务，每个角色拥有独立的知识空间和对话历史。
OpenClaw 的多机器人架构正是为此设计：
-
• 飞书侧：创建多个飞书应用（每个对应一个 Bot），通过 WebSocket 长连接接收消息，由 bindings路由到对应 Agent。 -
• 企业微信侧：创建多个企微机器人，共享同一个回调入口，通过 botId区分身份。 -
• Agent 层：8 个独立 Agent 各自拥有 workspace、角色设定和模型配置，互不干扰。
这套架构让一个 OpenClaw 实例同时服务于多个 IM 平台、多个 Bot、多个 Agent，一个进程搞定所有场景。
下面我们逐层拆解配置细节。
二、飞书多机器人配置
2.1 channels.feishu 整体结构
{ "channels": { "feishu": { "enabled":true, "defaultAccount": "main", "accounts": { "main": { ... }, "oscar": { ... }, "scout": { ... }, "turing": { ... }, "judge": { ... } } } }}核心字段说明：
|
|
|
|---|---|
enabled |
|
defaultAccount |
|
accounts |
|
2.2 单个飞书 Account 配置
{ "main": { "appId": "cli_aa87f79ebe7b5bc2”, "appSecret": "xE***zkCOKiwONq9y***", "connectionMode": "websocket", "dmPolicy": "pairing", "domain": "feishu", "enabled": true, "groupPolicy": "open", "agentId": "main" }}关键字段解析：
-
• connectionMode: "websocket"— 使用飞书 WebSocket 长连接模式，无需公网回调地址，本地开发也能直接接收消息，这是部署最简的方式。 -
• dmPolicy: "pairing"— 私聊策略为”配对”，即消息发送者与 Bot 自动建立一对一会话。 -
• groupPolicy: "open"— 群聊策略为开放，允许 Bot 被拉入任意群并响应 @ 消息。 -
• domain: "feishu"— 标识为国内飞书环境（海外用lark）。 -
• agentId: "main"— 该飞书应用绑定的 Agent ID，消息进来后路由给该 Agent 处理。
2.3 飞书多 Bot 路由：bindings 配置
飞书的每个 Account 自带 agentId 字段做了一层绑定，但 OpenClaw 还提供了更灵活的 bindings 路由机制：
{ "bindings": [ { "type": "route", "agentId": "judge", "match": { "channel": "feishu", "accountId": "judge" } }, { "type": "route", "agentId": "scout", "match": { "channel": "feishu", "accountId": "scout" } }, { "type": "route", "agentId": "oscar", "match": { "channel": "feishu", "accountId": "oscar" } }, { "type": "route", "agentId": "turing", "match": { "channel": "feishu", "accountId": "turing" } } ]}路由逻辑：当飞书通道收到消息时，先根据 appId 定位到 account（如 judge），然后查找 bindings 中 match.channel === "feishu" && match.accountId === "judge" 的条目，将消息分发给 agentId 对应的 Agent。
为什么不直接依赖 account 里的 agentId？ 因为 bindings 支持更复杂的匹配条件（如按群 ID、按用户、按消息类型路由），是更通用的路由层。
三、企业微信多机器人配置
3.1 channels.wecom 整体结构
{ "channels": { "wecom": { "enabled":true, "defaultAccount": "main", "accounts": { "main": { ... }, "judge": { ... }, "scout": { ... }, "turing": { ... }, "default": { "dmPolicy": "open", "groupPolicy": "open", "allowFrom": ["*"], "groupAllowFrom": ["*"] } } } }}企微侧注册了 多 个机器人（main / judge / scout / turing），另外还有一个特殊的 default 账号——它不是机器人，而是全局默认策略配置。
3.2 单个企微 Account 配置
{ "main": { "botId": "aibL98A8MiOlUnxo18LXNtNZ0mSjsibHE5H", "secret": "xxx8j44ICOxJAtY6t2Wxb7jQgMj6Xv0m***" }}企微的配置比飞书简洁得多：
-
• botId— 企业微信机器人的唯一标识，在企微管理后台创建 Bot 时获取。 -
• secret— 机器人的通信密钥，用于消息加解密和鉴权。
3.3 企微全局策略：default 账号
{ "default": { "dmPolicy": "open", "groupPolicy": "open", "allowFrom": ["*"], "groupAllowFrom": ["*"] }}这个 default 节点定义了企微通道的兜底安全策略：
-
• dmPolicy: "open"— 私聊开放，任何企微用户都能与 Bot 对话。 -
• groupPolicy: "open"— 群聊开放。 -
• allowFrom: ["*"]— 白名单为通配符，表示不限制发送者。
3.4 飞书 vs 企业微信配置差异
|
|
|
|
|---|---|---|
|
|
|
|
|
|
appId
appSecret |
botId
secret |
|
|
agentId + bindings 双层路由 |
|
|
|
|
default
|
四、Agent 列表与多角色设计
4.1 Agent 定位
{ "agents": { "defaults": { "workspace": "~/.openclaw/workspace", "model": { "primary": "zai/glm-5-turbo", "fallbacks": ["zai/glm-5", "zai/glm-5v-turbo", ...] } }, "list": [ ... ] }}Agent 的定位如下：
|
|
|
|
|
|---|---|---|---|
main |
|
|
|
coach |
|
|
|
judge |
|
|
|
scout |
|
|
|
4.2 独立 Workspace 隔离
每个 Agent 拥有独立的 workspace 目录：
{ "id": "coach", "name": "Coach", "workspace": "~/.openclaw/workspace-coach"}{ "id": "judge", "name": "Judge", "workspace": "~/.openclaw/workspace-judge"}这意味着不同 Agent 的会话历史、记忆文件、工作产物完全隔离。Scout 调研产生的中间文件不会出现在 Judge 的 workspace 里，Chief 的对话上下文也不会干扰 Arch 的架构思考。
4.3 模型 Fallback 链
所有 Agent 共享一份默认的模型 fallback 配置：
{ "model": { "primary": "zai/glm-5-turbo", "fallbacks": [ "zai/glm-5", "zai/glm-5-turbo", "zai/glm-5v-turbo", "zai/glm-4.7", "zai/glm-4.7-flash" ] }}设计思路：
-
1. 首选 glm-5-turbo— 最快的模型，优先使用。 -
2. 同代兜底 glm-5/glm-5v-turbo— 主模型不可用时切换到同代替代。 -
3. 跨代逐级降级 — 从 4.7 → 4.6 → 4.5 逐级降级，确保任何情况下都能返回结果。 -
4. 兼顾多模态 — 包含 glm-5v-turbo、glm-4.6v、glm-4.5v等视觉模型，当需要处理图片时自动选择。
这条多级 fallback 链在实际运行中提供了极强的可用性保障。
五、配置要点与最佳实践
5.1 跨平台统一 Agent，差异化管理入口
本配置的核心设计模式是：同一个 OpenClaw 实例、同一组 Agent，通过不同的 Channel 接入不同的 IM 平台。
飞书用户 ──→ 飞书 Bot (appId) ──→ feishu channel ──→ bindings ──→ Agent企微用户 ──→ 企微 Bot (botId) ──→ wecom channel ──→ account 映射 ──→ Agent这意味着你只需维护一份 Agent 配置，就能同时在飞书和企微上提供一致的 AI 服务。
5.2 安全白名单：最小权限原则
{ "tools": { "elevated": { "enabled":true, "allowFrom": { "feishu": ["ou_b70769771de784416786f9fb519cxxx"] } } }}elevated 权限（高危操作）只对特定用户开放。只有 allowFrom 列表中的飞书用户（通过 open_id 标识）才能触发需要提权的操作。
5.3 Session 隔离策略
{ "session": { "dmScope": "per-account-channel-peer", "reset": { "mode": "idle", "idleMinutes": 43200 }, "agentToAgent": { "maxPingPongTurns": 5 } }}-
• dmScope: "per-account-channel-peer"— 每个会话按”账号 × 通道 × 对话者”三维隔离，确保不同 Bot、不同平台、不同用户的会话互不干扰。 -
• idleMinutes: 43200— 30 天无活动自动重置会话，防止上下文无限膨胀。 -
• maxPingPongTurns: 5— Agent 间协作对话最多 5 轮，防止无限循环。
5.4 Gateway 网关配置
{ "gateway": { "mode": "local", "auth": { "allowTailscale":true, "mode": "none" }, "port": 18789, "bind": "loopback" }}-
• bind: "loopback"— 只监听本地回环地址，不暴露到公网。 -
• allowTailscale: true— 通过 Tailscale 组网实现安全远程访问，无需开放端口。
这套配置适合本地部署 + Tailscale 内网穿透的场景，兼顾安全与便利。
六、总结
OpenClaw 的多机器人架构可以归纳为三个层次：
1. Channel 层（接入层） — 飞书通过 WebSocket 接入多个 Bot，企微通过 WebSocket接入多个 Bot，各自独立配置认证信息。
2. Binding 层（路由层） — 通过 bindings 规则将”通道 + 账号”的组合映射到具体 Agent，支持灵活的匹配条件和多平台统一路由。
3. Agent 层（业务层） — 多个Agent 各自拥有独立的 workspace、角色设定和身份标识，共享模型 fallback 链保障可用性。
配置时需要注意的关键点：
-
• 飞书用 appId+appSecret，企微用botId+secret，认证方式不同。 -
• 连接推荐 WebSocket 模式（免公网）。 -
• 安全策略要分层设置：通道级白名单（ allowFrom）+ 命令级权限（ownerAllowFrom）+ 提权控制（elevated）。 -
• Session 隔离粒度选 per-account-channel-peer，避免跨 Bot、跨平台的上下文串扰。
这套架构让我们用一个 OpenClaw 实例就能同时服务飞书和企业微信两大平台上的十多个机器人，每个机器人背后是独立的 AI Agent，互不干扰又统一管理。对于需要多角色、多平台 AI 助理服务的一人团队来说，是一个非常实用的参考方案。
对于如何配置多Agent的人设和工作区，大家有兴趣的话，可以下次介绍，不知道是否有帮助，可以评论区留言，发表你的看法～