组建龙虾团队——OpenClaw多机器人构建

组建龙虾团队——OpenClaw多机器人构建

成功搭建了OpenClaw,也成功建立的自己的每日服务,这时候发现,似乎不太敢在当前的机器人中让他做别的事情,生怕会话太多会让他出现遗忘。(尽管我们配置了QMD记忆增强,但毋庸置疑任何技术都是有上限的)。

换做同样的情况,比如在DeepSeek或者豆包之类的对话窗口,我们会习惯性地新建一个对话。那么我们是否可以新建一个机器人,或者多个机器人,让他们各司其职,各尽所能,形成一个相互配合的团队呢~开干吧,没什么不可能的!!

🦞新建一个机器人

来到飞书开发者后台,新创建一个应用,在这里我们以短视频剪辑脚本应用为例。

创建之后,由于我们的openclaw绑定的是之前的飞书渠道,并没有链接到这个应用的APP ID,所以暂时不做其他操作,只需要记录一下他的APP ID和APP Secret。

🦞配置OpenClaw

如果还是按照claw的命令行安装,每一步都有些让人担心害怕,毕竟我们先前已经配置过一次了,接下来的操作,需要小心是否会把以前的配置给覆盖掉。

为了避免这样的不确定性,我们直接去操作他的配置文件

在WSL2终端中进入openclaw目录

cd .openclaw/ 

别着急,首先我们先备份一份配置文件,避免一次失误导致全局崩盘

cp openclaw.json openclaw.json.backup

以任何你喜欢的方式打开openclaw.json,在这里以nano为例。

nano openclaw.json

找到关于Channels的版块

在这里,你的json构造和图中的构造多半是不一样的,因为再在此之前我已经创建了两个机器人,一个名为“claw_deepseek”,一个名为“咨询获取”(已经无所畏惧了直接上中文吧)

接下来我将完整的配置粘贴到下方,大家只需要根据自己应用的APP ID 和Secret进行填写就好。

"channels": { "feishu": { "enabled": true, "domain": "feishu", "groupPolicy": "allowlist", "accounts": { "main": { "appId": "【cli_ID1】", "appSecret": "【Secret1】", "botname": "【机器人名1】", }, "feishu-work":{ "appId": "【cli_ID2】", "appSecret": "【Secret2】", "botName": "【机器人名2】", } }, "dmPolicy": "pairing" } }, "bindings": [ { "agentId": "main", "match": { "channel": "feishu", "accountId": "main" } }, { "agentId": "work", "match": { "channel": "feishu", "accountId": "feishu-work【这个可以自己命名一下】" } } ],

保存之后回到终端,执行以下最简单的检查命令

openclaw-cn gateway

如果你的json有问题的话,就会出现报错,像这样

按照指引去看看哪里写错了。

如果没有问题的话,就会像这样,告诉我们网关已经在跑了。

🦞启动新员工

回到飞书后台,开启订阅方式为长连接

如果没有去配置openclaw就试图开启长连接的话,之类会提示【没有会话对象】之类的

接下来就比较熟悉, 订阅一个消息接收的事件,im.message.receive_v1

在这里我加了一个消息已读,没什么关系,后续我们都可以修改。根据引导开启机器人功能就好。

下一步就是要给他授予权限,除了下面批量导入的权限外,也可以把关于文档的权限尽可能给它开通,避免生成文档出现问题。

{ "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: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", "im:chat.access_event.bot_p2p_chat:read"] } }

接下来就让我们发布一个版本,正式上线吧~

发布成功后,我们去飞书的消息栏看一下,【打开应用】

我们向新建的应用发送一句“你好”,有时候飞书回复会很慢,这个时候我们可以去claw的后台去看,访问你本机地址的18789端口(默认)。根据消息在命令行执行配对命令

当再次打招呼时,就会发现它可以正常的跟我们对话了。

🦞做个测试

首先我对他的身份进行了定义,他是专门用于输出短视频剪辑脚本的,我将另一个机器人生成的每日资讯作为输入,让其生成脚本文件,结果是比较惊讶的。

其不仅建立了独立的工作空间,而且创建了完整版和快速版两种,十分高效。

🦞总结

到现在为止我们成功创建了多个龙虾员工,下一步我们将探索如何将他们的工作关联起来,形成一个整体~加油~

Read more

机器人重力补偿技术:从理论到实践的MuJoCo实现解析

机器人重力补偿技术:从理论到实践的MuJoCo实现解析 【免费下载链接】mujocoMulti-Joint dynamics with Contact. A general purpose physics simulator. 项目地址: https://gitcode.com/GitHub_Trending/mu/mujoco 技术挑战引入:重力场中的机器人控制困境 在精密制造领域,当六轴机械臂以0.1mm精度装配半导体元件时,未补偿的重力会导致末端执行器产生2.3mm的静态偏移,直接超出工艺允许误差范围。医疗手术机器人在进行脑组织穿刺时,重力引起的臂端下垂可能造成0.5mm的定位误差,这在神经外科手术中可能导致严重后果。这两个典型场景揭示了同一个核心问题:重力作为一种持续存在的外力场,如何精确量化并实时补偿其对机器人系统的影响,是实现高精度控制的关键挑战。 MuJoCo物理引擎通过其独特的动力学计算架构,为解决这一挑战提供了完整的技术方案。在拟人机器人模型中(model/humanoid/humanoid.xml),23个自由度的复杂结构使得重力影响呈现高度非线性特征,髋

【ROS 2】运行 ROS 2 机器人 ( ROS 2 机器人示例 - 海龟仿真器 | ROS 节点分析工具 - rqt | ros2 run 命令解析 | ros2 run 基础格式和完整格式 )

【ROS 2】运行 ROS 2 机器人 ( ROS 2 机器人示例 - 海龟仿真器 | ROS 节点分析工具 - rqt | ros2 run 命令解析 | ros2 run 基础格式和完整格式 )

文章目录 * 一、ROS 2 机器人示例 - 海龟仿真器 * 1、启动海龟仿真器节点 * 2、启动控制节点 * 3、ROS 节点分析工具 - rqt * 二、ros2 run 命令解析 * 1、设计理念 * 2、ros2 run 基础格式 * 3、ros2 run 完整格式 * 4、启动海龟仿真器命令分析 在上一篇博客 【ROS 2】ROS 2 Humble 完整环境配置 ( VirtualBox 7.2.4 + Ubuntu 22.04.5 LTS + ROS 2

中小型火电厂如何经济高效地部署机器人巡检系统

中小型火电厂部署机器人巡检系统,关键在于“经济”与“高效”。核心思路是:先算清账,再选对场景,用对技术,最后分阶段投入。 🧮 第一步:算清经济账,明确投入产出 在采购前,务必进行成本效益分析,回答以下三个问题: 1. 替代了什么?明确机器人将替代哪些高频、高危、高强度的人工巡检任务。例如,输煤廊道、升压站、主变区、电缆夹层等区域,人工巡检环境恶劣、强度大,是机器人替代的重点。 2. 规避了哪些损失?机器人能更早发现设备过热、跑冒滴漏等隐患,有效减少“非停”和设备损坏。例如,有电厂通过智能巡检使“非停”次数减少约20%,每年减少故障损失超百万元。您可以估算近几年的相关损失,作为项目收益的参考。 节省了多少人力?根据行业实践,一台多场景机器人可替代约3名人工,每年节省人力成本约30万元。您可以根据本地工资水平进行测算: 年节省人力成本 ≈ 替代人数

从黑盒到白盒:基于GB28181/RTSP全栈源码交付的AI视频平台OEM与低代码集成实战

引言:掌握核心代码,重塑交付价值链 对于系统集成商(SI)和独立软件开发商(ISV)而言,依赖厂商的“黑盒”产品无异于将命运交予他人。功能定制周期长、接口开放受限、Logo无法替换、私有协议无法打通……这些痛点往往导致项目交付延期,利润微薄。据统计,在传统模式下,企业需投入大量人力重复开发基础视频能力,约95%的成本并未转化为业务价值。 如何破局?全源码交付是关键。今天,我将深度解析一款支持OEM贴牌、纯自研代码的企业级AI视频管理平台。它不仅提供了丰富的RESTful API,更开放了从流媒体内核到算法商城的完整工程代码,让开发者能像搭积木一样构建专属的安防应用。 一、源码交付的核心价值:从“使用者”到“拥有者” 该平台坚持“纯自研代码,任意形式合作”的理念,为合作伙伴提供极致的定制化能力。 * OEM贴牌自由:支持一键替换系统Logo、名称、版权信息,甚至深度修改UI风格,帮助ISV快速打造自有品牌产品,无需等待厂商排期。 * 算法自主可控: