组建龙虾团队——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

Flutter 三方库 health_connector_core 的鸿蒙化适配指南 - 实现具备跨平台标准的数据采集与同步架构、支持端侧健康指标建模与设备总线协同实战

Flutter 三方库 health_connector_core 的鸿蒙化适配指南 - 实现具备跨平台标准的数据采集与同步架构、支持端侧健康指标建模与设备总线协同实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 health_connector_core 的鸿蒙化适配指南 - 实现具备跨平台标准的数据采集与同步架构、支持端侧健康指标建模与设备总线协同实战 前言 在进行 Flutter for OpenHarmony 的运动健身、个人健康管理或数字疗法类应用开发时,如何统一管理来自不同传感器(如心率计、血糖仪、计步器)的异构数据?health_connector_core 是一款专注于健康数据标准化处理的底层库。它提供了从指标建模到数据聚合的完整逻辑框架。本文将探讨如何在鸿蒙端构建极致、严谨的健康数据中枢。 一、原直观解析 / 概念介绍 1.1 基础原理 health_connector_core 建立在“标准指标(Standard Metrics)”系统之上。它将杂乱无章的原生生理信号抽象为统一的 Record 模型。

By Ne0inhk
OCI 连接失败、PL/SQL 报错?金仓数据库直击 Oracle 迁移 4 大痛点,一次破解!

OCI 连接失败、PL/SQL 报错?金仓数据库直击 Oracle 迁移 4 大痛点,一次破解!

引言 现在企业都在忙着搞数字化转型,信创改造更是提上了所有企业的日程——说白了,就是把核心系统里的国外数据库换成国产的,实现自主可控。Oracle 作为老牌商业数据库,靠谱了几十年,不少政企的核心系统——像财务核算、业务审批、生产调度这些关键环节——都用了它,稳定得没话说。 可一到迁移环节,各种问题就扎堆冒出来:应用和数据库的“通信线”总断、写好的代码一迁就报错、常用的功能突然用不了、改造期限越来越近,迁移进度却越拖越慢……很多企业本来想借着迁移升级系统,结果反而被这些麻烦拖了后腿,甚至影响到正常业务运转。 作为国产数据库的头部玩家,电科金仓早就盯着这些迁移痛点了。靠着这么多年打磨的 Oracle 兼容能力和实打实的实战经验,金仓数据库能精准解决这些问题,让企业不用“推倒重来”,顺顺利利就把 Oracle 换成国产数据库。 一、Oracle 迁移四大核心痛点,企业直呼“扛不住” 1.1 痛点一:OCI 连接总掉线,数据传输“断联”

By Ne0inhk
从小项目到大型鸿蒙 App 的架构变化

从小项目到大型鸿蒙 App 的架构变化

子玥酱(掘金 / 知乎 / ZEEKLOG / 简书 同名) 大家好,我是子玥酱,一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂,目前在某国企负责前端软件研发相关工作,主要聚焦于业务型系统的工程化建设与长期维护。 我持续输出和沉淀前端领域的实战经验,日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案, 在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。 技术方向:前端 / 跨端 / 小程序 / 移动端工程化 内容平台:掘金、知乎、ZEEKLOG、简书 创作特点:实战导向、源码拆解、少空谈多落地 文章状态:长期稳定更新,大量原创输出 我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”,而是更关注为什么这么设计、在什么场景下容易踩坑、

By Ne0inhk
Flutter 三方库 test_api 的鸿蒙化适配指南 - 实现具备底层测试驱动与自定义匹配器扩展的质量基石架构、支持端侧测试骨架深度定制实战

Flutter 三方库 test_api 的鸿蒙化适配指南 - 实现具备底层测试驱动与自定义匹配器扩展的质量基石架构、支持端侧测试骨架深度定制实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 test_api 的鸿蒙化适配指南 - 实现具备底层测试驱动与自定义匹配器扩展的质量基石架构、支持端侧测试骨架深度定制实战 前言 在进行 Flutter for OpenHarmony 的大规模测试框架开发或构建企业专有的测试 SDK 时,简单的 test 库往往无法满足对测试执行流程、自定义断言逻辑以及测试套件生命周期的精细化控制。test_api 是 Dart 官方测试生态的核心底层库,它定义了所有测试相关的抽象契约。本文将探讨如何在鸿蒙端利用此库构建极致、专业的测试基础设施。 一、原直观解析 / 概念介绍 1.1 基础原理 该库定义了 Dart 测试系统的“语意骨架”。它不负责具体的测试运行(那由 test_core 负责),而是构筑了 test(

By Ne0inhk