本地部署中文OpenClaw 飞书机器人部署指南

本地部署中文OpenClaw 飞书机器人部署指南

适用场景:在 Windows 本地(PowerShell)一键部署 OpenClaw,使用阿里云百炼作为大模型后端,通过飞书长连接模式实现 AI 机器人。


安装skills工具参考:OpenClaw 最新必安装 10 个 Skills-ZEEKLOG博客

自动化发布小红书:OpenClaw 实现小红书自动化发文:操作指南


步骤 1:安装 OpenClaw(openclaw中文社区)
  1. 打开 PowerShell
  2. 执行以下命令一键安装:
# 在 PowerShell 中运行 iwr -useb https://clawd.org.cn/install.ps1 | iex
  • 安装过程会自动下载 Node.js、依赖等,耗时几分钟。
  • 安装完成后会自动进入配置向导,或提示你继续下一步。
步骤 2:运行首次配置向导
  1. 重新打开一个 CMD
  2. 向导启动后:
    • 第一步通常会问是否继续 → 选择 YES
    • 在选择大模型提供商时,选 阿里云百炼(或你想用的其他平台,如 OpenAI、deepseek 等)。
    • 后面会引导你输入 API Key。

输入命令启动配置向导:

openclaw-cn onboard
步骤 3:获取阿里云百炼 API Key
  1. 浏览器访问阿里云百炼控制台
  2. 登录后,进入左侧菜单 密钥管理创建 API Key
  3. 创建完成后,立即复制 Key(通常以 sk- 或 bk- 开头)。
  4. 返回 onboard 向导,在对应位置粘贴这个 Key 并继续。
步骤 4:配置飞书机器人渠道
  1. 在 onboard 向导中,选择配置 Feishu渠道。
  • 访问飞书开放平台
  • 创建企业自建应用 → 选择机器人类型 → 填写基本信息 → 创建。

选择机器人,继续下一步

输入内容(自定义)

2.在权限管理/批量导入/导出权限中清空原有权限,粘贴复制下方内容

{ "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", "contact:contact.base:readonly", "im:chat.access_event.bot_p2p_chat:read" ] } }
  • 在「凭证与基础信息」中复制 App ID 和 App Secret。
  • 进入「事件与回调」:
  • 订阅方式选择 长连接订阅方式(不可选 HTTP 回调)。
  • 添加事件:至少包含 im.message.receive_v1(接收消息)。
  • 保存设置。

注意:事件订阅和回调配置建议在openclaw部署完成后统一在飞书后台设置,避免向导卡住。

3.在指定位置输入刚才复制的飞书机器人App IDApp Secret,继续下一步直到向导完成。

步骤 5:启动网关服务

配置完成后,启动 OpenClaw 的网关(负责 WebSocket 长连接):

openclaw-cn gateway
  • 看到类似 “Listening on http://127.0.0.1:18789” 或 “Gateway ready” 即启动成功。
  • 保持这个窗口运行(或用 nohup / pm2 后台运行)。
步骤 6:访问管理后台并验证
  1. 浏览器打开命令中提示的网址(通常是 http://127.0.0.1:18789http://localhost:18789,可能带 token 参数)。
  2. 登录 OpenClaw 管理后台。
  3. 确认飞书渠道已连接:
    • 检查事件订阅是否为 长连接模式
    • 确认已添加的事件列表完整。
步骤 7:测试部署是否成功
  • 将机器人拉入飞书群或私聊。
  • 发送消息(如 @机器人 你好)。
  • 如果机器人正常回复(可能简单问候或调用百炼模型生成回答),则部署成功!

快速排错提示

  • onboard 卡住或报错 → 检查网络,重新运行 openclaw-cn onboard。
  • gateway 启动失败 → 检查端口 18789 是否被占用,可加参数 --port 其他端口。
  • 飞书不回复 → 确认选了“长连接”、事件已订阅、App ID/Secret/Key 无误。
  • 模型无响应 → 确认百炼 API Key 有效、配额充足。

Read more

攻击模式日志库搭建:反哺Qwen3Guard-Gen-WEB训练数据

攻击模式日志库搭建:反哺Qwen3Guard-Gen-WEB训练数据 在AI内容安全防线持续升级的今天,一个常被忽视却至关重要的现实正浮出水面:再强大的审核模型,也会在真实对抗中逐渐钝化。当攻击者熟练使用谐音替代、符号拆分、语义绕过、多语言混写等手法试探边界时,模型的误判率悄然上升;当“炸dan”变成“乄単”、“暴*力”演变为“b40li”、“违法”隐匿于“违-法”或“wéi fǎ”中时,静态规则和固定分类器的漏检窗口正在扩大。更严峻的是,这些新型对抗样本若未被系统性捕获、归档与分析,就永远无法成为模型进化的养料。 Qwen3Guard-Gen-WEB 作为阿里开源的安全审核模型,其核心价值不仅在于开箱即用的三级风险判定能力,更在于它为持续进化提供了可落地的技术接口——它不只是一道门禁,更是一个可反馈、可学习、可生长的智能守门人。而支撑这一进化闭环的关键基础设施,正是本文要深入探讨的:攻击模式日志库。 这不是一份简单的错误日志汇总,而是一套面向模型迭代的数据生产流水线。它将线上拦截失败、人工复核修正、用户反馈质疑等“活”的对抗行为,结构化沉淀为高质量训练信号,

3大核心功能深度解析:jQuery DateTimePicker 如何解决前端日期时间选择难题

3大核心功能深度解析:jQuery DateTimePicker 如何解决前端日期时间选择难题 【免费下载链接】datetimepickerjQuery Plugin Date and Time Picker 项目地址: https://gitcode.com/gh_mirrors/da/datetimepicker 在Web开发中,日期和时间选择是每个开发者都会遇到的常见需求,但传统的解决方案往往存在界面不统一、功能不完整、兼容性差等问题。jQuery DateTimePicker作为一款专业的日期时间选择器插件,通过三合一的设计理念,为开发者提供了完整的解决方案。 🎯 问题分析:传统日期时间选择面临的挑战 理论说明 传统的日期时间选择方案通常存在以下几个核心问题: * 日期和时间选择界面分离,用户体验不连贯 * 不同浏览器对原生日期控件的支持程度不一 * 缺乏灵活的自定义选项和事件处理机制 * 移动设备适配困难,响应式设计支持不足 实践示例 假设我们需要为一个会议系统添加时间选择功能: // 错误的传统做法 $('#meetingDate').date

前端计算机基础

前端计算机基础

进程和线程的区别 简单记:进程是 “独立的容器”,线程是 “容器里干活的人”,多人共享容器资源,效率更高但也更容易互相影响。 进程:独立可运行的程序,比如微信,留言及,VSCODE 进程是操作系统资源分配的最小单位(资源包括内存、CPU 时间片、文件句柄等),每个进程都有自己独立的内存空间,进程之间互不干扰。 线程:是进程的执行单位,一个进程可以包含多个县城,比如微信进程中,有接收消息线程,渲染界面线程 线程是调度执行的最小单位 ,同一进程内的线程共享进程的内存和资源。 类比:进程像一家 “独立的公司”,有自己的办公场地(内存)、资金(系统资源);线程像公司里的 “员工”,共享公司的场地和资金,各自做不同的工作,协作完成公司整体任务。 维度进程线程资源分配系统资源分配的最小单位资源调度 / 执行的最小单位内存空间每个进程有独立的内存空间共享所属进程的内存空间通信方式复杂(需 IPC:管道、套接字、共享内存等)简单(直接读写进程内共享变量)创建

微信 H5 缓存控制:后端重定向 & 前端强制刷新

在 Web 开发中,缓存是一把双刃剑。对于静态资源,它能极大提升加载速度;但对于业务逻辑频繁变动的 H5 页面(如支付、订单页),缓存往往会导致用户看到过期的数据或界面。最近在维护一个 uni-app 项目时,遇到了一段关于 H5 缓存控制的逻辑,引发了我对于“后端重定向加时间戳”和“前端 JS 加时间戳”这两种方案的思考。虽然两者的最终目的一致,但在 Hash 模式下,它们的实现原理和效果有着本质的区别。 一、 问题背景 在应用启动的生命周期中,通常会有这样一段逻辑:当用户访问特定的关键页面(如支付、订单页)时,如果当前 URL 中缺少时间戳参数,前端会自动解析 URL,追加当前时间戳,并强制页面刷新。 这就引出了一个问题:为什么不直接在后端重定向时加时间戳?这两种方式有什么区别? 二、 核心区别: