很多团队在把 AI 接入飞书时，第一反应都是：先做一个机器人，把所有事都接进来再说。

这个思路能跑起来，但很快就会遇到几个典型问题：

• 写作、信息收集、技术排障混在一个上下文里，角色越来越“串味”

• 长期记忆互相污染，越用越难管

• 群聊、私聊、不同入口的行为不容易精确控制

• 一旦出问题，很难判断到底是账号问题、路由问题，还是角色本身的问题

如果你的目标不是“先有个机器人能用”，而是想把 OpenClaw 真正落到团队协作场景里，那么更合适的方式往往不是单机器人，而是：一个网关实例，承载多个 agent；多个飞书应用，映射多个角色；再通过 bindings 做精确路由。

这篇文章基于当前 openclaw.json 的实际配置结构，系统说明一套可落地的方案：如何把 OpenClaw 组织成一支可分工、可协作、可持续扩展的 AI 团队。

适合阅读的人包括：

• 想在飞书里部署多个 AI 助手的团队

• 已经接入 OpenClaw，但发现“一个机器人包打天下”越来越难维护的人

• 希望把内容、收集、协调、开发等职责拆开的实施者

• 需要多账号、多入口、多角色并行运行的管理者或技术负责人

一、这套方案解决的，不是“多开几个机器人”

当前方案的核心不是“一个机器人接所有任务”，而是：

• 一个 OpenClaw Gateway 实例

• 多个 Agent

• 多个飞书应用 / 多个飞书机器人账号

• 多组 bindings 路由规则

• 每个 Agent 独立 workspace

也就是说，当前环境采用的是一套标准的“多 agent + 多 Feishu account + 多 bindings”组织方式。

在现有配置思路里，Agent / account 不是平铺罗列，而是按职责拆分为以下几类：

• main：主入口 / 对外交互主助手

• content：内容生成与写作

• collect：信息收集、整理、归档

• social：社媒/外部传播/互动相关工作

• coordinator：协调调度、跨 agent 串联

• dev：开发、调试、工程实施

换句话说，这不是“多机器人部署技巧”，而是一种更接近真实团队协作的组织方式。

二、为什么要这样配：从单机器人，升级到可分工的 AI 团队

这套配置的目标不是“多开几个机器人”，而是把 OpenClaw 真正组织成一支可分工的 AI 团队：

1. 每个职责对应独立 Agent

2. 每个 Agent 绑定独立飞书账号 / 应用

3. 通过 bindings 把消息路由到正确 Agent

4. 通过独立 workspace 保证记忆、人格、上下文隔离

5. 需要时再通过 agent-to-agent 能力协作

这样做的直接收益很明确：

• 写作 agent 只专注内容生产，不被技术对话污染

• 收集 agent 只负责汇总资料，不承担最终表达

• 协调 agent 可以负责串联多个角色，而不是自己亲自做所有事情

• 开发 agent 专门处理配置、部署、排障，不影响业务型对话体验

因此，飞书里看到的是多个机器人；OpenClaw 内部看到的是多个 agent；而真正把二者对应起来的，是 channels.feishu.accounts 和 bindings。

三、先建立一个正确理解：这是三层映射，不是一层配置

在当前配置结构里，可以把系统理解成三层。

1）Agent 层：真正干活的“角色”

Agent 是真正执行任务的“人格/能力体”。当前重点关注这些 agent：

• main

• content

• collect

• social

• coordinator

• dev

每个 agent 都应该有：

• 自己的 id

• 自己的 name

• 自己独立的 workspace

2）Feishu Account 层：飞书里的多个入口

飞书通道下不是只配置一组 App ID / App Secret，而是配置多组 accounts。也就是说，每个飞书应用都作为一个独立 account 接入 OpenClaw。

这正是当前方案区别于单机器人方案的关键点：

• main 对应一个飞书应用

• content 对应一个飞书应用

• collect 对应一个飞书应用

• social 对应一个飞书应用

• coordinator 对应一个飞书应用

• dev 对应一个飞书应用

3）Bindings 层：真正决定“谁来回复”

bindings 决定“某个飞书账号收到的消息，最终交给哪个 agent 处理”。

也就是说，用户在飞书里和哪个机器人说话，取决于 Feishu account；真正回答的人格和工作区，取决于 binding 最终命中的 agentId。

这个结构一旦想清楚，后面很多配置和排障逻辑就会变得很顺。

四、推荐做法：不是 1:N，而是显式的一一映射

在现有结构下，不建议把所有飞书消息都打到 main，再让 main 内部区分角色；当前配置更适合采用显式映射：

这种方式的价值在于：

• 人设稳定，不串味

• 记忆隔离，不互相污染

• 群聊/私聊行为可精确控制

• 问题定位简单，知道是哪一路账号、哪一路 agent 出问题

如果你的团队已经开始让 AI 进入日常协作，这种显式映射几乎是从“能用”走向“可维护”的分水岭。

五、现网效果：多个机器人，不再只是多个壳，而是多个真正的角色

一个 OpenClaw 实例 + 多个飞书机器人，本质上就是把多个 AI 角色真正放进同一个协作体系里。

前期在其他通道上做过类似多角色实践，迁移到飞书之后，结构会更清晰，因为飞书应用、权限、发布流程都比较标准化。

针对国内团队协作场景，飞书这套组织方式更适合沉淀为日常工作流，下图是实现的效果。

六、配置怎么写：按当前结构拆成四部分就够了

下面不是空泛示例，而是按当前环境实际组织思路整理出来的推荐结构。实际文件里除了这些字段，通常还会有 models、gateway、auth 等其他配置，修改时不要覆盖无关部分。

1）agents：先定义清楚角色单元

{"agents":{"list":[{"id":"main","default":true,"name":"Main","workspace":"/root/.openclaw/workspace-main"},{"id":"content","name":"Content","workspace":"/root/.openclaw/workspace-content"},{"id":"collect","name":"Collect","workspace":"/root/.openclaw/workspace-collect"},{"id":"social","name":"Social","workspace":"/root/.openclaw/workspace-social"},{"id":"coordinator","name":"Coordinator","workspace":"/root/.openclaw/workspace-coordinator"},{"id":"dev","name":"Dev","workspace":"/root/.openclaw/workspace-dev"}]}}

2）channels.feishu.accounts：每个飞书应用都是一个独立入口

这里要特别注意，当前采用的是多账号方案，不是一组凭证跑所有角色。

{"channels":{"feishu":{"enabled":true,"dmPolicy":"open","groupPolicy":"open","accounts":{"main":{"appId":"cli_a9xxxxx","appSecret":"<main-app-secret>"},"content":{"appId":"<content-app-id>","appSecret":"<content-app-secret>"},"collect":{"appId":"<collect-app-id>","appSecret":"<collect-app-secret>"},"social":{"appId":"<social-app-id>","appSecret":"<social-app-secret>"},"coordinator":{"appId":"<coordinator-app-id>","appSecret":"<coordinator-app-secret>"},"dev":{"appId":"<dev-app-id>","appSecret":"<dev-app-secret>"}}}}}

3）bindings：把入口精确路由到对应 agent

{"bindings":[{"agentId":"main","match":{"channel":"feishu","accountId":"main"}},{"agentId":"content","match":{"channel":"feishu","accountId":"content"}},{"agentId":"collect","match":{"channel":"feishu","accountId":"collect"}},{"agentId":"social","match":{"channel":"feishu","accountId":"social"}},{"agentId":"coordinator","match":{"channel":"feishu","accountId":"coordinator"}},{"agentId":"dev","match":{"channel":"feishu","accountId":"dev"}}]}

4）需要协作时，再打开 agent-to-agent

只有在确实需要跨角色协同的时候，再开放 agent-to-agent 能力。

{"tools":{"agentToAgent":{"enabled":true,"allow":["main","content","collect","social","coordinator","dev"]}}}

七、真正容易被忽略的关键：不是账号数量，而是 workspace 隔离

多 agent 配置里，最容易被忽略、但最关键的不是飞书应用数量，而是 workspace 隔离。

每个 workspace 本质上就是该 agent 的私有工作区，通常会承载：

• SOUL.md：角色设定

• AGENTS.md：团队通讯录 / 协作说明

• USER.md：服务对象信息

• IDENTITY.md：身份卡片（可选）

• memory/：长期记忆

• 该角色专属的临时文件、草稿、输出结果

如果多个 agent 共用一个 workspace，会出现这些典型问题：

1. 人设互相污染

2. 记忆混用

3. 一个角色的中间文件被另一个角色误读

4. 协调 agent 与执行 agent 混成一个上下文

因此，当前这套多 agent / 多账号方案能稳定运行的前提之一，就是为 main、content、collect、social、coordinator、dev 都准备独立目录。

示例：

mkdir -p /root/.openclaw/workspace-mainmkdir -p /root/.openclaw/workspace-contentmkdir -p /root/.openclaw/workspace-collectmkdir -p /root/.openclaw/workspace-socialmkdir -p /root/.openclaw/workspace-coordinatormkdir -p /root/.openclaw/workspace-dev

如果你只记住这篇文章里的一条原则，那应该就是：多角色方案要想稳定，workspace 一定不能共用。

八、角色边界怎么划分，才能真正发挥多 Agent 的价值？

如果所有 agent 最后都做同样的事，那多账号、多路由的意义会被迅速稀释。更合理的方式，是明确职责边界。

main：主入口和统一对外接口

适合承担：

• 默认入口

• 对外统一答复

• 简单问题直接处理

• 不确定时转交其他 agent

不建议：

• 长时间承担深度内容生产

• 承担全部资料整理

• 承担工程排错细节

content：内容生产中枢

适合承担：

• 文档写作

• 文章改写

• 知识库沉淀

• 标题、小节、结构优化

collect：信息收集与资料归档

适合承担：

• 信息搜集

• 素材汇总

• 资料分类

• 会议纪要/链接/原始材料整理

social：社媒表达与外部传播

适合承担：

• 社交平台表达

• 外部传播语气适配

• 评论回复草案

• 传播节奏建议

coordinator：任务拆解与跨角色协调

适合承担：

• 接任务后拆解成多个子任务

• 指挥 collect 先收集，content 再成稿，social 再改传播版

• 汇总各 agent 结果

dev：技术实现与排障

适合承担：

• OpenClaw 配置修改

• 服务重启

• 排查飞书接入问题

• 代码、脚本、部署和自动化

这种分工方式最适合的场景，不是简单聊天，而是：一个团队真的希望把 AI 纳入日常工作流。

九、飞书端的核心原则：一个角色，通常对应一个独立应用

当前方案不是一个飞书应用生成多个角色，而是：一个角色通常对应一个飞书应用。

因此，每增加一个 Feishu account，都需要在飞书开放平台重复一遍应用创建与发布流程。

这也是为什么多账号方案前期看起来比单机器人更“重”——因为它换来的，是后续的稳定性、可维护性和边界清晰度。

十、飞书开放平台怎么操作：每个应用都要走完整流程

1）创建企业自建应用

首先登录飞书开放平台，创建企业自建应用。

填写应用名称、描述和图标后创建。

2）添加机器人能力

在应用能力里添加“机器人”。

3）先记录 App ID / App Secret

在“凭据与基础信息”中记录 App ID 和 App Secret，后续填入 channels.feishu.accounts。

十一、把飞书通道接到 OpenClaw：重点不是“接上”，而是“形成多 accounts”

如果是腾讯云 Lighthouse 环境，可在应用管理页配置模型和飞书通道。

先确认模型配置可用。

然后把飞书应用凭证接入通道。需要注意的是：当前是多账号方案，因此并不是只配一组，而是要确保最终 openclaw.json 中形成多组 accounts。

很多人会在这里踩坑：界面上看起来已经“接入了飞书”，但实际上只完成了单账号接入，还没有形成真正的多入口结构。

十二、飞书事件与回调怎么配：长连接是关键

1）事件配置：使用长连接

在“事件与回调”中，事件配置选择“长连接接收事件”。

如果提示“应用未建立长连接”，通常先检查：

• App ID / App Secret 是否填错

• Gateway 是否已经启动并加载正确配置

• 该 account 是否确实存在于当前 channels.feishu.accounts 中

必要时可重启 OpenClaw Gateway。

2）至少添加“接收消息”事件

至少要添加“接收消息”事件。

如果需要群聊里使用机器人，还建议补充群相关事件。

确认事件列表里已经生效。

3）回调配置也使用长连接

回调订阅方式选择“使用长连接接收回调”。

十三、多账号最容易卡住的地方，其实是权限

权限不足是多 account 接入时最常见的问题之一，因为你可能以为某一路已通，实际上只是某个应用权限不全。

进入“权限管理”，可以批量导入权限。

推荐导入以下权限集合：

{"scopes":{"tenant":["aily:file:read","aily:file:write","application:application.app_message_stats.overview:readonly","application:application:self_manage","application:bot.menu:write","cardkit:card:write","contact:contact.base:readonly","contact:user.employee_id:readonly","corehr:file:download","docs:document.content:read","event:ip_list","im:chat","im:chat.access_event.bot_p2p_chat:read","im:chat.members:bot_access","im:chat:readonly","im:message","im:message.group_at_msg:readonly","im:message.group_msg","im:message.p2p_msg:readonly","im:message:readonly","im:message:send_as_bot","im:resource","sheets:spreadsheet","wiki:wiki:readonly"],"user":["aily:file:read","aily:file:write","contact:contact.base:readonly","im:chat.access_event.bot_p2p_chat:read"]}}

权限导入完成后，建议逐个应用确认状态。

这一点特别值得强调：多账号环境下，不是“飞书通了就都通了”，而是每个应用都要单独成立。

十四、别忘了发布：没发布，很多时候就只是“看起来配好了”

每个飞书应用都要发布，未发布时通常无法正常搜索和使用。

填写版本号并提交。

等待审批通过后确认状态。

十五、怎么验证有没有真的跑通：先私聊，再群聊

1）私聊验证

在飞书中搜索对应机器人名称。

输入应用名进行搜索。

进入机器人对话窗口。

如果首次对话需要配对，按提示执行命令。

在服务器登录后执行配对命令。

成功后应该能正常得到 AI 回复。

2）群聊验证

创建群组。

打开群设置。

添加群机器人。

搜索应用名称。

添加后即可在群里使用。

配置完成后，移动端和桌面端都可使用。

注意：机器人只能被添加到同一企业下的群聊，外部群通常不可用。

十六、OpenClaw 侧如何让配置生效

修改完 ~/.openclaw/openclaw.json 后，重启 Gateway 让配置生效：

openclaw gateway restart

建议随后检查通道状态：

openclaw channels status --probe

如果是当前这种多 account 方式，理想状态下应该能看到各个 Feishu account 都处于可用状态，例如：

Feishu main: enabled, configured, running, worksFeishu content: enabled, configured, running, worksFeishu collect: enabled, configured, running, worksFeishu social: enabled, configured, running, worksFeishu coordinator: enabled, configured, running, worksFeishu dev: enabled, configured, running, works

只有当这些 account 分别都处于正常状态时，整套多角色体系才算真的搭起来了。

十七、实施过程中最常见的几个坑

1）不要混淆 accountId、agentId、workspace

当前配置里，最容易出错的是把这三者混成一件事：

• accountId：飞书账号入口标识

• agentId：OpenClaw 内部 agent 标识

• workspace：该 agent 的文件与记忆空间

推荐保持一一对应，排障最省心。

2）不要让多个 agent 共用同一个 workspace

这会直接破坏角色隔离，是多 agent 失效的常见根因。

3）bindings 漏配时，机器人可能“在线但不工作”

表现通常是：

• 飞书应用能收到消息

• 但没有正确回复

• 或消息被路由到默认 agent

因此新增 account 后，一定同步新增 binding。

4）多账号场景里，经常不是整体坏，而是某一路单独坏

多账号场景里，不是“整体坏掉”，而经常是某一个应用单独没发布、没权限或没建长连接。排查时要逐个 account 看。

5）dmPolicy / groupPolicy 要和实际使用方式一致

如果当前团队需要私聊和群聊都直接可用，保持：

{"dmPolicy":"open","groupPolicy":"open"}

否则可能出现：

• 私聊可以，群聊不回

• 群里 @ 了机器人却没有反应

• 回复行为和预期不一致

6）修改配置时，不要覆盖其他顶层配置

openclaw.json 通常不只有多 agent 配置，还包含模型、网关、鉴权等内容。建议用增量方式修改，而不是整文件覆盖。

十八、推荐的目录结构

结合当前多 agent 组织方式，目录建议如下：

~/.openclaw/├── openclaw.json├── workspace-main/│   ├── SOUL.md│   ├── AGENTS.md│   ├── USER.md│   └── memory/├── workspace-content/│   ├── SOUL.md│   ├── AGENTS.md│   ├── USER.md│   └── memory/├── workspace-collect/│   ├── SOUL.md│   ├── AGENTS.md│   ├── USER.md│   └── memory/├── workspace-social/│   ├── SOUL.md│   ├── AGENTS.md│   ├── USER.md│   └── memory/├── workspace-coordinator/│   ├── SOUL.md│   ├── AGENTS.md│   ├── USER.md│   └── memory/└── workspace-dev/    ├── SOUL.md    ├── AGENTS.md    ├── USER.md    └── memory/

如果后续继续扩充角色，也建议沿用这套命名方式，保持 accountId、agentId、workspace 后缀一致。

结语：真正值得守住的，是这四条原则

按当前 openclaw.json 的真实组织思路，这不是一个普通的“飞书机器人接入教程”，而是一套已经进入团队协作形态的配置模式：

• OpenClaw 作为统一网关与执行底座

• 多个 Feishu account 作为多个独立入口

• 多个 agent 按职责拆分

• 通过 bindings 完成精确路由

• 通过 workspace 完成记忆与人格隔离

• 通过 coordinator / main 等角色实现协同调度

如果后续要长期维护这套系统，最重要的是守住四条原则：

1. 一个职责一个 agent

2. 一个 agent 一个独立 workspace

3. 一个飞书应用一个 account

4. 每新增 account 必补 binding

做到这几点，这套多 agent 飞书团队方案就能长期稳定扩展。

从效果上看，你得到的也不再只是“几个机器人”，而是一支开始具备分工、边界和协作能力的 AI 团队。