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

马钞预约大攻略

马钞预约大攻略

各位朋友大家好!最近纪念钞市场的热度持续走高,作为收藏爱好者和“手速党”,大家肯定不想错过这次马钞的预约机会。每年到了预约季,官网服务器的高并发拥堵总是让很多人铩羽而归。 为了帮助大家提高预约成功率,本文将从预约准备、渠道选择、实战操作、以及常见报错处理四个维度,对整个预约流程进行深度拆解。无论是纯手动党还是想了解机制的朋友,这篇攻略都能让你少走弯路。 一、 预约前的“初始化”准备(至关重要) 在预约正式开始前,做好以下准备能帮你节省关键的几秒钟: 信息预填写(核心提速项) 身份证信息:提前准备好自己的身份证号码,如果是帮家人预约,请提前将家人的身份证号存在手机的备忘录里。 联系方式:确保预留的手机号畅通,用于接收验证码。 归属地:明确你要预约的网点。建议提前在银行官网查询好库存较多的网点,不要等到预约开始时才去选地址。 网络环境优化 Wi-Fi vs 5G:建议使用 5G/4G 网络。Wi-Fi 在高并发时容易发生丢包,而移动网络通常更稳定。 关闭后台应用:清理手机后台运行程序,确保手机运行流畅,避免卡顿。

亲测Qwen3Guard-Gen-WEB,内容风险识别真实体验分享

亲测Qwen3Guard-Gen-WEB,内容风险识别真实体验分享 最近在做AI应用安全加固时,偶然接触到阿里开源的 Qwen3Guard-Gen-WEB 镜像。它不像常规大模型那样生成文案或画图,而是专为“看住内容”而生——不输出创意,只输出判断;不追求惊艳,只专注可靠。部署后我连续测试了三天,输入了200+条涵盖中文、英文、粤语、网络黑话、隐喻表达、对抗提问的真实文本,从“怎么修手机”到“如何绕过实名制”,从学生作业提问到营销话术草稿,全程记录响应逻辑、速度和边界表现。这篇不是参数罗列,也不是复述文档,而是一份带着键盘温度、留有思考痕迹、甚至包含翻车现场的真实体验手记。 1. 它到底是什么?一个会“说人话”的安全守门员 Qwen3Guard-Gen-WEB 是 Qwen3Guard-Gen-8B 模型的轻量级Web封装版本,由阿里开源,核心目标非常明确:对任意文本做三级安全判定,并用自然语言解释为什么。 它不是传统意义上的“审核API”,没有返回一堆JSON字段和概率值;

Youtu-VL-4B-Instruct源码实战:基于Gradio自定义组件扩展WebUI的图片批处理功能

Youtu-VL-4B-Instruct源码实战:基于Gradio自定义组件扩展WebUI的图片批处理功能 1. 引言:从单张到批量,解放生产力的新思路 如果你用过Youtu-VL-4B-Instruct的WebUI,肯定体验过它的强大——上传一张图片,问几个问题,模型就能给出精准的回答。无论是识别图片里的文字,还是描述复杂的场景,这个40亿参数的多模态模型都表现得相当不错。 但不知道你有没有遇到过这样的场景:手头有几十张产品图片需要批量添加描述,或者有一堆文档截图需要统一提取文字。这时候,一张一张上传、等待、再上传,效率实在太低了。每次操作都要重复“上传-等待-复制结果”的流程,不仅耗时,还容易出错。 这就是我们今天要解决的问题。原生的WebUI界面虽然友好,但在批量处理方面存在明显短板。它就像一家只接受堂食的餐厅,味道很好,但没法做外卖。而我们需要的是能同时处理多份订单的中央厨房。 好消息是,Gradio框架给了我们足够的灵活性。通过深入源码,我们可以自己动手,为这个WebUI增加一个“图片批处理”功能。想象一下,一次性上传几十张图片,设置好统一的提问模板,然后去喝杯咖

Python 四大 Web 框架对比解析:FastAPI、Django、Flask 与 Tornado

目录 一、框架概述及设计目标 二、核心差异详解 三、详细应用场景与角色定位 1. Django — 企业级全栈Web开发的首选 2. Flask — 灵活、轻量的微框架 3. FastAPI — 现代、高性能异步API框架 4. Tornado — 异步网络编程与实时通信 四、总结对比与选择建议 五、框架选择示意图 结语 Python 在 Web 开发领域有众多框架,功能和定位各有不同。本文重点对比四个主流框架:FastAPI、Django、Flask、Tornado,帮你了解它们的差异、应用场景和各自擅长解决的问题。 一、框架概述及设计目标 框架设计初衷特点概览代表适用场景Django全功能、高度集成的全栈框架“开箱即用” ,集成ORM、模板、后台管理、安全认证复杂业务系统、内容管理、企业级应用Flask轻量级微框架,灵活自由核心简单,