OpenClaw多智能体路由实战:飞书多机器人配置指南

文章目录

目前我已经完成了OpenClaw的基本安装,但是在对话框只有一个,机器人也只绑定到主会话,一次只能处理一个消息。很多时候我在聊天窗口,说A任务,然后做了一半,又发了关于B任务的指令。一是每次发完消息,如果OpenClaw还在处理,剩下的消息要么进入队列、要么看不到(实际还在队列)。两个任务切来切去,感觉体验很不好。

要彻底解决这个问题,实现网上演示的那种对各Agent、每个对话机器人对应一个Agent,就需要用到多智能体路由技术。
实现的步骤如下:

  • 在飞书创建一个新的机器人
  • 通过控制台创建新的智能体
  • 按照指引将飞书配置上去
  • 根据需要创建多个Agent和机器人,并对应配置上去(略)

飞书重新安装问题

明明我已经安装好了飞书,系统还是会提示我安装,否则就跳过了添加飞书这步。应该是系统Bug。这次安装的飞书位置在~/.openclaw/extensions/feishu,其实和~/.npm-global/lib/node_modules/openclaw/extensions/feishu/是一样的,安装的方法不同而已。建议把.npm-global的删除。

请添加图片描述

第二次配置的时候,会把第一次飞书Channel给覆盖掉,具体看channels.feishu下面的配置。因为我们要实现每个Agent对应一个机器人,就必须要有多个feishu的机器人配置,而这里只有一个。

请添加图片描述


以下为OpenClaw自己配置的:

请添加图片描述

正确的如下,将多个机器人配置放在了channels.feishu.accounts下面,没办法只能手工改:

 "channels": { "feishu": { "enabled": true, "domain": "feishu", "groupPolicy": "allowlist", "accounts": { "main": { "appId": "cli_1", "appSecret": "appSecret1", "botName": "主助手", "groupAllowFrom": [ "ou_id1" ] }, "feishu-work": { "appId": "cli_2", "appSecret": "appSecret2", "botName": "工作助手", "groupAllowFrom": [ "ou_id2" ] }, }, "dmPolicy": "pairing" } }, "bindings": [ { "agentId": "main", "match": { "channel": "feishu", "accountId": "main" } }, { "agentId": "work", "match": { "channel": "feishu", "accountId": "feishu-work" #要与前面配置对应 } } ], 

注意事项:

  • 名称一定要对应,agentId对应,accountId也要对应
  • ou_id可以是相同(同一个人名下建立多个机器人),也可以不同(我就是这么干的)
请添加图片描述

效果就是这样。

请添加图片描述

回到Gateway的聊天窗口,就可以切换聊天的对象,我这有2个。(应该也有相关的配置的,找到之后更新)

请添加图片描述

批量增加机器人

一次性申请了6个机器人,确定好Agent的名称,让OpenClaw帮我完成配置。

  • BandBusiness,业务Agent
  • BandProjectMgr,项目经理Agent
  • BandProductMgr,产品经理Agent
  • BandSysDesign,系统设计Agent
  • BandCoder,系统开发Agent,严格来说,还可以继续拆分为前端、后端、安卓、iOS、鸿蒙等

BandTester,系统测试Agent
检查了一下,配置是对的,Agent的职责还做了扩展。重启openclaw gateway restart没问题。接下来需要给每个机器人添加事件,添加配对。

请添加图片描述


请添加图片描述

提示应用未建立长链接。原因是手工修改openclaw.json增加飞书渠道,并没有通过openclaw channels add增加。
发现在~/.openclaw/feishu/dedup少了些内容,但这并没有什么影响。
实测的总结是:必须在控制台完成对飞书机器人添加,才能起作用。而OpenClaw生成的openclaw.json还是对的,能让我的新机器人与Agent对应上。加上之后,还需要调整一下openclaw.json,删除错误的配置。
于是放心把其他的机器人都通过控制台添加上去,任务完美完成。

接下来我就可以创建一批智能体和机器人,并且让他们协同起来了。

缺点

飞书创建机器人的过程比较复杂,流程繁琐。好在我操作一遍之后,就可以按照之前的路径一直这样做下去。

多个飞书机器人名称包含大小写的问题

多个飞书账号时,名称中如果包含大小写,会遇到无法找到的问题。原因时飞书在处理的时候都改成了小写。为了避免类似问题,我将所有飞书的accountId改为小写。

多个Agent名称包含大小写的问题

当多个Agent相互调用的时候,我发现第一个Agent调用第二个Agent失败,仔细看聊天记录,发现OpenClaw把Agent的id全改为了小写。同样,为了规避此类问题,建议所有的Agent名称都时小写。
还可以在Agent的workspace名称发现一些端倪。
比如我的Agent名称为BandBusiness,系统自动分配的workspace名称为~/.openclaw/bandbusiness,全改为小写了。

关键词:OpenClaw 多智能体路由,飞书多机器人配置,OpenClaw bindings 绑定

Read more

Flutter 组件 native_shuttle 的适配 鸿蒙Harmony 实战 - 驾驭极致原生通讯性能、实现鸿蒙端 Dart 与 ArkTS 之间的高频底层穿梭方案

Flutter 组件 native_shuttle 的适配 鸿蒙Harmony 实战 - 驾驭极致原生通讯性能、实现鸿蒙端 Dart 与 ArkTS 之间的高频底层穿梭方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 native_shuttle 的适配 鸿蒙Harmony 实战 - 驾驭极致原生通讯性能、实现鸿蒙端 Dart 与 ArkTS 之间的高频底层穿梭方案 前言 在鸿蒙(OpenHarmony)生态的极速动态图形交互、需要频繁调用系统底层多媒体能力以及对跨引擎数据同步有“毫秒级延时门禁”的各类专业级应用开发中,“宿主语言(ArkTS)与业务语言(Dart)之间的交互效率”是决定应用能否在大规模、高并发工况下保持流畅的终极技术壁垒。面对需要每秒传递 60 帧以上的高精度传感器数据流、复杂的 0307 批次资产二进制 Blob 同步或者是在鸿蒙平板与折叠屏之间执行频繁的逻辑状态投影。如果仅仅依靠传统的 MethodChannel 这种基于 JSON 或序列化编码的慢速异步通道。不仅会导致在数据转换(Serialization)过程中产生巨大的 CPU

By Ne0inhk
Flutter 组件 cron_parser 的适配 鸿蒙Harmony 实战 - 驾驭 Cron 表达式解析、实现鸿蒙端高精度定时任务调度与触发逻辑预判方案

Flutter 组件 cron_parser 的适配 鸿蒙Harmony 实战 - 驾驭 Cron 表达式解析、实现鸿蒙端高精度定时任务调度与触发逻辑预判方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 cron_parser 的适配 鸿蒙Harmony 实战 - 驾驭 Cron 表达式解析、实现鸿蒙端高精度定时任务调度与触发逻辑预判方案 前言 在构建具备高度自动化能力的鸿蒙(OpenHarmony)应用时,“定时触发”是一个绕不开的核心需求。无论是每天凌晨三点的数据库自动化维护,还是每隔五分钟的环境温湿度同步录入,一套稳定、标准的定时规则描述符(Cron Expression)是支撑这些后台逻辑的核心心脏。 虽然简单的 Timer 能够处理定时的延时,但对于诸如“每个月最后一个周五的 14:00 运行”这种复杂的业务逻辑,手动编写判断代码将是维护者的噩梦。 cron_parser 是一款专为 Dart 设计的高性能 Cron 表达式解析器。它不仅支持标准的五段式、六段式语法,更提供了极低延迟的“

By Ne0inhk

Linux下安装OpenClaw并实现外部访问

1. 安装OpenClaw 这里使用官网的一键安装脚本比较省事,它会自动安装最新版的Node.js,不用自己手动安装。 curl -fsSL https://openClaw.ai/install.sh | bash 但如果系统已存在旧版Nodejs,可能会报错 报错是由于系统已安装的旧版Node.js(v10.24.0)与OpenClaw安装脚本尝试安装的Node.js 22+版本冲突导致的。系统包管理器(dnf)检测到两个nodejs包以及依赖包npm存在版本互斥,因此阻止了安装。 要解决这个问题,最根本的方法是移除冲突的旧版Node.js,然后重新安装。 1. 清理旧版Node.js及其依赖 sudo dnf remove nodejs npm -y 2. 重新运行openClaw安装脚本 curl -fsSL https://openClaw.ai/install.

By Ne0inhk
Flutter 组件 http_retry 的适配 鸿蒙Harmony 实战 - 驾驭智能请求重试机制、实现鸿蒙端弱网环境下的协议层自愈方案

Flutter 组件 http_retry 的适配 鸿蒙Harmony 实战 - 驾驭智能请求重试机制、实现鸿蒙端弱网环境下的协议层自愈方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 http_retry 的适配 鸿蒙Harmony 实战 - 驾驭智能请求重试机制、实现鸿蒙端弱网环境下的协议层自愈方案 前言 在鸿蒙(OpenHarmony)生态的全场景移动办公、复杂工业现场巡检以及对数据传输可靠性有“零容忍”要求的各类政务应用开发中,“网络的不确定性”是架构师必须直面的头号天敌。面对在电梯间切换 Wi-Fi、在地下车库偶发的 5G 信号掉包或者是服务器短暂的 503 报错。如果仅仅依靠单次请求判定。那么不仅会导致用户在业务操作过程中频繁看到“连接超时”的生硬弹窗,更会严重损耗鸿蒙应用在极端环境下的可用性口碑。 我们需要一种“策略先行、自动回旋”的网络治理艺术。 http_retry 是一套专为标准化 HTTP 客户端设计的重试中间件插件。它通过引入科学的指数退避(Exponential Backoff)与极其灵活的条件过滤算子(Filter)

By Ne0inhk