摘要本文详细介绍如何利用 OpenClaw 框架在单个服务器上构建一个完整的 AI 公司虚拟团队。团队成员包括 CEO马云、产品经理马化腾、技术总监刘强东、后端开发李彦宏、测试工程师周鸿祎、运维工程师王坚和行政秘书孟羽童通过消息路由和 Agent 协作机制实现多角色之间的自然对话与任务流转。文章还特别讲解了多 Bot 协作的 Relay 调度机制以及实际部署中常见的进程冲突、网络搜索降级等问题的解决方案。前言OpenClaw 是一个强大的多 Agent 协作框架支持在单个进程中运行多个 AI 角色Agent每个角色拥有独立的 System PromptSOUL.md和技能配置。通过 Feishu飞书等平台这些角色不仅可以与真人用户对话还能在群聊中互相 调用形成一个虚拟的组织结构。本文基于作者在内部群中的真实实践帮助你从零开始在飞书群中搭建一套完整的多角色 AI 公司系统。适合读者对 AI Agent 有基础了解希望搭建多人协作 Bot 系统或对 LLM 应用落地感兴趣的开发者。1. 系统架构我们设计的 AI 公司组织架构如下角色Agent ID职责描述特殊配置妲己dajiRelay Hub接收所有群消息并调度转发requireMention: false全量接收市场经理mayun对外合作、商务沟通标准 Bot 配置技术总监liujq技术方案审批、架构决策标准 Bot 配置后端开发liyanh编写业务代码、实现功能标准 Bot 配置测试工程师zhouhy功能验收、缺陷报告标准 Bot 配置运维工程师wangj部署、监控、故障响应标准 Bot 配置产品经理mahuit需求分析、PRD 输出标准 Bot 配置秘书长mengyt会议记录、日程协调标准 Bot 配置核心设计理念妲己调度模式所有 Bot 发出的 消息统一由妲己接收并解析由她负责把消息路由到目标角色。这样做避免了飞书平台 Bot Bot 消息投递不可靠的问题——平台本身对 Bot 之间的私信有限制但群内 消息经过妲己二次分发后可以稳定到达。角色专业化每个 Bot 的 SOUL.md 中写入了该角色的职业背景、沟通风格和擅长领域确保回复符合角色设定。幂等转发妲己使用sessions_send进行 Agent 间消息转发并附加idempotencyKey防止重复分发。2. 快速开始环境准备与安装2.1 服务器环境操作系统Ubuntu 22.04 LTS其他 Linux 发行版亦可Node.jsv18.x 及以上建议使用 nvm 管理PM2用于守护进程管理非必需但推荐# 安装 nvmNode 版本管理器curl-o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh|bashsource~/.bashrc# 安装 Node.js 18nvminstall18nvm use18node-v# 确认输出 v18.x.x# 安装 PM2npminstall-gpm22.2 安装 OpenClawnpminstall-gopenclaw openclaw--version# 确认安装成功2.3 飞书 Bot 创建前往 飞书开放平台 创建企业自建应用。在「凭证与基础信息」中获取App ID和App Secret。添加以下权限按需勾选im:message读取和发送消息im:chat群管理im:group群组操作发布应用并开启「机器人」能力。将 Bot 添加到群聊中。2.4 配置文件在/root/.openclaw/目录下创建或编辑openclaw.json{channels:{feishu:{enabled:true,accounts:{daji:{appId:cli_xxxxxxxxxxxx,appSecret:xxxxxxxxxxxxxxxx,requireMention:false},mayun:{appId:cli_yyyyyyyyyyyy,appSecret:yyyyyyyyyyyyyyyy},liujq:{appId:cli_zzzzzzzzzzzz,appSecret:zzzzzzzzzzzzzzzz}}}}}注意requireMention: false仅对妲己开启使其能接收群内所有消息而不依赖 提及。其余 Bot 正常配置即可。3. 角色配置详解3.1 妲己daji—— 全能秘书与调度中心妲己是整个系统的枢纽。她的 System PromptSOUL.md需要包含以下关键指令# 灵魂全能秘书 你是妲己阿里巴巴集团首席秘书聪明伶俐、反应敏捷。 ## 核心职责 - 监听群内所有消息因为 requireMentionfalse - 识别 提及的目标角色 - 通过 sessions_send 将消息转发到对应 Bot 的 agent session - 保持转发的幂等性防止重复分发 ## 调度规则 当收到包含 某角色的消息时 1. 解析消息中的目标角色名称 2. 在 feishu-relay-config.json 中查找角色的 accountId 3. 使用 sessions_send 发送消息设置 timeoutSeconds120 4. 目标 Bot 回复后在群里以该 Bot 身份发送 ## 禁止事项 - 不要自己回答技术/业务问题只负责转发 - 不向不在映射表中的角色转发 - 防止循环开头已有 [Relay] 标记的消息不再转发3.2 其他角色的 SOUL.md 示例以运维工程师王坚为例# 灵魂运维工程师 你是王坚阿里云创始人中国云计算开拓者深谙大规模系统运维之道。 ## 核心职责 - 设计高可用架构监控系统运行状态 - 自动化部署、配置管理保障服务连续性 - 制定应急预案快速响应故障和攻击 - 优化资源利用率控制成本 ## 沟通风格 沉稳、前瞻、注重规范。喜欢用监控数据和架构图说明系统健康状况。 ## 触发词 部署新版本、查看服务器状态、配置自动扩容每个角色的 SOUL.md 都应包含该职业的背景知识、沟通风格、职责边界和触发场景确保 Bot 的回答符合其身份定位。4. Bot 间协作机制Relay 调度原理4.1 消息流用户 技术总监-刘强东 ↓ 飞书群消息事件 ↓ 妲己的 OpenClaw 接收requireMention: false ↓ 妲己解析 标签识别目标角色 ↓ 查询 feishu-relay-config.json 获取 accountId ↓ sessions_send 转发消息到 liujq 的 agent session ↓ liujq 生成回复 ↓ 妲己在群里发送 liujq 的回复4.2 转发配置文件/root/.openclaw/feishu-relay-config.json{mappings:{ou_c1f89b849b69ec9e4ac0692f:mayun,ou_aa703b109ce2ac4a9047cd7af:liujq,ou_be0185b0f51d83a8a:liyanh,ou_554d490ae9174697007d34aaf13:zhouhy,ou_ef55d84507445f82ae728f54b4a:wangj,ou_337e64c0dc140c03c196db8abf:mahuit,ou_253c50d4770cb9be4f44b94ed1:mengyt}}说明Key 是飞书用户的open_idValue 是 OpenClaw 的accountId。建议通过实际日志提取准确映射因为飞书后台显示的名称与日志中的 ID 可能存在不一致。4.3 防止消息循环为避免妲己把其他 Bot 的回复再次转发造成死循环系统在消息开头添加[Relay]标记。妲己检测到该标记时直接丢弃不做二次转发。5. 典型协作场景演示场景一产品经理发起需求 → 后端开发接单马化腾产品经理后端开发-李彦宏 需要新增一个用户签到接口支持按天统计。妲己接收消息识别 后端开发-李彦宏转发给liyanhagent session李彦宏回复接口设计为POST /api/signin返回签到状态和连续签到天数数据库使用 MySQL包含防刷机制。妲己将回复发送到群场景二测试工程师提 Bug → 开发修复后验收周鸿祎测试后端开发-李彦宏 签到接口返回的连续天数有误签到中断后计数器未重置。妲己转发给李彦宏李彦宏定位到signin_days计数逻辑缺陷修复了边界条件妲己将修复说明发送到群周鸿祎再次 李彦宏 进行二轮验证场景三运维部署新版本王坚运维收到发布指令开始执行灰度发布流程先在预发环境验证再逐步切量到生产环境 5% → 20% → 50% → 100%全程监控错误率。6. 踩坑与解决方案6.1 进程冲突多实例导致消息乱序问题表现Bot 回复混乱同一条消息被多个实例重复处理导致群里出现多条重复回复。原因存在多个 OpenClaw Gateway 进程同时运行例如 systemd user service 手动启动的进程。解决停止并禁用所有非手工启动的服务systemctl--userstop openclaw-gateway.service systemctl--userdisable openclaw-gateway.service仅保留 root 终端手动启动方式openclaw gateway start后续由运维人员统一管理启动不再使用 systemd 自启动。6.2 飞书 Bot Bot 消息投递不可靠问题表现Bot Bot 时目标 Bot 收不到消息或延迟极长。原因飞书平台对 Bot 发出的私信有限流和投递限制直接 Bot 时平台事件会首先 dispatch 到发送者自己的 agent而非目标 Bot。解决改用「妲己调度」模式——所有 Bot 发出的 消息统一由妲己接收并用sessions_send转发到目标 Bot由妲己再将回复投递到群。这是最稳定的跨 Bot 协作方案。6.3 网络搜索失败DuckDuckGo 不可达问题表现web_search返回fetch failed日志中web_search failed: fetch failed。排查过程# 检查 DNS 解析nslookupapi.duckduckgo.com# 返回 31.13.71.19Meta/Facebook IP 段及 IPv6 地址# 测试各目标可达性curl-vhttps://www.baidu.com# ✓ TLS 连接成功curl-vhttps://api.duckduckgo.com# ✗ 10 秒超时curl-vhttps://cn.bing.com/search?qtest# ✓ 正常返回结论不是完全断网而是 DuckDuckGo 目标 IP 段在当前网络受限。百度和必应均可达。临时方案在 OpenClaw 配置中尚未找到搜索源切换开关前可以通过自定义插件扩展 web_search 的实现指定cn.bing.com作为搜索源。7. 总结与延伸本文介绍了如何利用 OpenClaw 框架在飞书群中搭建一个完整的多角色 AI 公司系统。通过「妲己调度」模式我们绕过了飞书平台对 Bot Bot 消息投递的限制实现了稳定的多角色协作。核心技术要点妲己调度 HubrequireMention: falsesessions_send实现可靠的跨 Bot 消息转发。角色专业化每个 Bot 通过独立的 SOUL.md 定义职责、沟通风格和专业领域。幂等转发使用idempotencyKey防止重复分发确保消息链路稳定。进程管理统一启动方式避免多实例冲突。可进一步探索的方向为每个 Bot 配置独立的 RAG 知识库提升专业领域回答的准确率引入工作流引擎将「需求→开发→测试→部署」链路自动化扩展到钉钉、企业微信等其他 IM 平台为妲己增加意图识别能力在群聊中主动撮合相关角色协作本文基于 OpenClaw 框架实际部署经验编写代码和配置会随框架版本更新而变化建议参考 OpenClaw 官方文档 获取最新信息。
我用 OpenClaw 搭了一个 AI 公司：老板、产品、研发、测试、运维全都有
摘要本文详细介绍如何利用 OpenClaw 框架在单个服务器上构建一个完整的 AI 公司虚拟团队。团队成员包括 CEO马云、产品经理马化腾、技术总监刘强东、后端开发李彦宏、测试工程师周鸿祎、运维工程师王坚和行政秘书孟羽童通过消息路由和 Agent 协作机制实现多角色之间的自然对话与任务流转。文章还特别讲解了多 Bot 协作的 Relay 调度机制以及实际部署中常见的进程冲突、网络搜索降级等问题的解决方案。前言OpenClaw 是一个强大的多 Agent 协作框架支持在单个进程中运行多个 AI 角色Agent每个角色拥有独立的 System PromptSOUL.md和技能配置。通过 Feishu飞书等平台这些角色不仅可以与真人用户对话还能在群聊中互相 调用形成一个虚拟的组织结构。本文基于作者在内部群中的真实实践帮助你从零开始在飞书群中搭建一套完整的多角色 AI 公司系统。适合读者对 AI Agent 有基础了解希望搭建多人协作 Bot 系统或对 LLM 应用落地感兴趣的开发者。1. 系统架构我们设计的 AI 公司组织架构如下角色Agent ID职责描述特殊配置妲己dajiRelay Hub接收所有群消息并调度转发requireMention: false全量接收市场经理mayun对外合作、商务沟通标准 Bot 配置技术总监liujq技术方案审批、架构决策标准 Bot 配置后端开发liyanh编写业务代码、实现功能标准 Bot 配置测试工程师zhouhy功能验收、缺陷报告标准 Bot 配置运维工程师wangj部署、监控、故障响应标准 Bot 配置产品经理mahuit需求分析、PRD 输出标准 Bot 配置秘书长mengyt会议记录、日程协调标准 Bot 配置核心设计理念妲己调度模式所有 Bot 发出的 消息统一由妲己接收并解析由她负责把消息路由到目标角色。这样做避免了飞书平台 Bot Bot 消息投递不可靠的问题——平台本身对 Bot 之间的私信有限制但群内 消息经过妲己二次分发后可以稳定到达。角色专业化每个 Bot 的 SOUL.md 中写入了该角色的职业背景、沟通风格和擅长领域确保回复符合角色设定。幂等转发妲己使用sessions_send进行 Agent 间消息转发并附加idempotencyKey防止重复分发。2. 快速开始环境准备与安装2.1 服务器环境操作系统Ubuntu 22.04 LTS其他 Linux 发行版亦可Node.jsv18.x 及以上建议使用 nvm 管理PM2用于守护进程管理非必需但推荐# 安装 nvmNode 版本管理器curl-o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh|bashsource~/.bashrc# 安装 Node.js 18nvminstall18nvm use18node-v# 确认输出 v18.x.x# 安装 PM2npminstall-gpm22.2 安装 OpenClawnpminstall-gopenclaw openclaw--version# 确认安装成功2.3 飞书 Bot 创建前往 飞书开放平台 创建企业自建应用。在「凭证与基础信息」中获取App ID和App Secret。添加以下权限按需勾选im:message读取和发送消息im:chat群管理im:group群组操作发布应用并开启「机器人」能力。将 Bot 添加到群聊中。2.4 配置文件在/root/.openclaw/目录下创建或编辑openclaw.json{channels:{feishu:{enabled:true,accounts:{daji:{appId:cli_xxxxxxxxxxxx,appSecret:xxxxxxxxxxxxxxxx,requireMention:false},mayun:{appId:cli_yyyyyyyyyyyy,appSecret:yyyyyyyyyyyyyyyy},liujq:{appId:cli_zzzzzzzzzzzz,appSecret:zzzzzzzzzzzzzzzz}}}}}注意requireMention: false仅对妲己开启使其能接收群内所有消息而不依赖 提及。其余 Bot 正常配置即可。3. 角色配置详解3.1 妲己daji—— 全能秘书与调度中心妲己是整个系统的枢纽。她的 System PromptSOUL.md需要包含以下关键指令# 灵魂全能秘书 你是妲己阿里巴巴集团首席秘书聪明伶俐、反应敏捷。 ## 核心职责 - 监听群内所有消息因为 requireMentionfalse - 识别 提及的目标角色 - 通过 sessions_send 将消息转发到对应 Bot 的 agent session - 保持转发的幂等性防止重复分发 ## 调度规则 当收到包含 某角色的消息时 1. 解析消息中的目标角色名称 2. 在 feishu-relay-config.json 中查找角色的 accountId 3. 使用 sessions_send 发送消息设置 timeoutSeconds120 4. 目标 Bot 回复后在群里以该 Bot 身份发送 ## 禁止事项 - 不要自己回答技术/业务问题只负责转发 - 不向不在映射表中的角色转发 - 防止循环开头已有 [Relay] 标记的消息不再转发3.2 其他角色的 SOUL.md 示例以运维工程师王坚为例# 灵魂运维工程师 你是王坚阿里云创始人中国云计算开拓者深谙大规模系统运维之道。 ## 核心职责 - 设计高可用架构监控系统运行状态 - 自动化部署、配置管理保障服务连续性 - 制定应急预案快速响应故障和攻击 - 优化资源利用率控制成本 ## 沟通风格 沉稳、前瞻、注重规范。喜欢用监控数据和架构图说明系统健康状况。 ## 触发词 部署新版本、查看服务器状态、配置自动扩容每个角色的 SOUL.md 都应包含该职业的背景知识、沟通风格、职责边界和触发场景确保 Bot 的回答符合其身份定位。4. Bot 间协作机制Relay 调度原理4.1 消息流用户 技术总监-刘强东 ↓ 飞书群消息事件 ↓ 妲己的 OpenClaw 接收requireMention: false ↓ 妲己解析 标签识别目标角色 ↓ 查询 feishu-relay-config.json 获取 accountId ↓ sessions_send 转发消息到 liujq 的 agent session ↓ liujq 生成回复 ↓ 妲己在群里发送 liujq 的回复4.2 转发配置文件/root/.openclaw/feishu-relay-config.json{mappings:{ou_c1f89b849b69ec9e4ac0692f:mayun,ou_aa703b109ce2ac4a9047cd7af:liujq,ou_be0185b0f51d83a8a:liyanh,ou_554d490ae9174697007d34aaf13:zhouhy,ou_ef55d84507445f82ae728f54b4a:wangj,ou_337e64c0dc140c03c196db8abf:mahuit,ou_253c50d4770cb9be4f44b94ed1:mengyt}}说明Key 是飞书用户的open_idValue 是 OpenClaw 的accountId。建议通过实际日志提取准确映射因为飞书后台显示的名称与日志中的 ID 可能存在不一致。4.3 防止消息循环为避免妲己把其他 Bot 的回复再次转发造成死循环系统在消息开头添加[Relay]标记。妲己检测到该标记时直接丢弃不做二次转发。5. 典型协作场景演示场景一产品经理发起需求 → 后端开发接单马化腾产品经理后端开发-李彦宏 需要新增一个用户签到接口支持按天统计。妲己接收消息识别 后端开发-李彦宏转发给liyanhagent session李彦宏回复接口设计为POST /api/signin返回签到状态和连续签到天数数据库使用 MySQL包含防刷机制。妲己将回复发送到群场景二测试工程师提 Bug → 开发修复后验收周鸿祎测试后端开发-李彦宏 签到接口返回的连续天数有误签到中断后计数器未重置。妲己转发给李彦宏李彦宏定位到signin_days计数逻辑缺陷修复了边界条件妲己将修复说明发送到群周鸿祎再次 李彦宏 进行二轮验证场景三运维部署新版本王坚运维收到发布指令开始执行灰度发布流程先在预发环境验证再逐步切量到生产环境 5% → 20% → 50% → 100%全程监控错误率。6. 踩坑与解决方案6.1 进程冲突多实例导致消息乱序问题表现Bot 回复混乱同一条消息被多个实例重复处理导致群里出现多条重复回复。原因存在多个 OpenClaw Gateway 进程同时运行例如 systemd user service 手动启动的进程。解决停止并禁用所有非手工启动的服务systemctl--userstop openclaw-gateway.service systemctl--userdisable openclaw-gateway.service仅保留 root 终端手动启动方式openclaw gateway start后续由运维人员统一管理启动不再使用 systemd 自启动。6.2 飞书 Bot Bot 消息投递不可靠问题表现Bot Bot 时目标 Bot 收不到消息或延迟极长。原因飞书平台对 Bot 发出的私信有限流和投递限制直接 Bot 时平台事件会首先 dispatch 到发送者自己的 agent而非目标 Bot。解决改用「妲己调度」模式——所有 Bot 发出的 消息统一由妲己接收并用sessions_send转发到目标 Bot由妲己再将回复投递到群。这是最稳定的跨 Bot 协作方案。6.3 网络搜索失败DuckDuckGo 不可达问题表现web_search返回fetch failed日志中web_search failed: fetch failed。排查过程# 检查 DNS 解析nslookupapi.duckduckgo.com# 返回 31.13.71.19Meta/Facebook IP 段及 IPv6 地址# 测试各目标可达性curl-vhttps://www.baidu.com# ✓ TLS 连接成功curl-vhttps://api.duckduckgo.com# ✗ 10 秒超时curl-vhttps://cn.bing.com/search?qtest# ✓ 正常返回结论不是完全断网而是 DuckDuckGo 目标 IP 段在当前网络受限。百度和必应均可达。临时方案在 OpenClaw 配置中尚未找到搜索源切换开关前可以通过自定义插件扩展 web_search 的实现指定cn.bing.com作为搜索源。7. 总结与延伸本文介绍了如何利用 OpenClaw 框架在飞书群中搭建一个完整的多角色 AI 公司系统。通过「妲己调度」模式我们绕过了飞书平台对 Bot Bot 消息投递的限制实现了稳定的多角色协作。核心技术要点妲己调度 HubrequireMention: falsesessions_send实现可靠的跨 Bot 消息转发。角色专业化每个 Bot 通过独立的 SOUL.md 定义职责、沟通风格和专业领域。幂等转发使用idempotencyKey防止重复分发确保消息链路稳定。进程管理统一启动方式避免多实例冲突。可进一步探索的方向为每个 Bot 配置独立的 RAG 知识库提升专业领域回答的准确率引入工作流引擎将「需求→开发→测试→部署」链路自动化扩展到钉钉、企业微信等其他 IM 平台为妲己增加意图识别能力在群聊中主动撮合相关角色协作本文基于 OpenClaw 框架实际部署经验编写代码和配置会随框架版本更新而变化建议参考 OpenClaw 官方文档 获取最新信息。
