AIOps实践:基于 Dify+LangBot 实现飞书智能体对话机器人

AIOps实践:基于 Dify+LangBot 实现飞书智能体对话机器人

文章目录

AIOps实践:Dify接入飞书实现与智能体对话

前言

前端时间把dify的智能体接入到了Prometheus和夜莺上,实现了与智能体的基本对话,并可以调取Prometheus数据进行分析,在那之后就开始深度研究AIOps实现原理于深度赋能运维的可能性,所以正在研究AIOps的核心:MCP Server;现在还并未成型,在研究的过程中,就想到了可否基于dify的agent,连接自建的mcp服务器,对接到飞书的机器人上,这样就可以和智能体进行对话,配合成型的mcp,就可以基本实现AIOps。

这里需要借助一个三方的开源工具LangBot,LangBot是一个生产级多平台 LLM 机器人开发平台。那么就开始实践吧:

在这里插入图片描述

MCP Server开发的当前阶段:

在这里插入图片描述

后续会开源至github。

环境搭建

1、Docker环境搭建

安装Docker和docker compose

# 安装必要的工具包sudoapt-get update sudoapt-getinstall ca-certificates curl gnupg lsb-release # 创建密钥环目录并添加Docker的官方GPG密钥(用于验证软件包)sudoinstall -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg |sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudochmod a+r /etc/apt/keyrings/docker.gpg # 将Docker仓库添加到APT源echo"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"|sudotee /etc/apt/sources.list.d/docker.list > /dev/null sudoapt-get update # 安装Dockersudoapt-getinstall docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 配置国内镜像源,当然也可以不配置,可以配一个Docker代理,让Docker坐上VPN,在此不再展示vim /etc/docker/daemon.json {"registry-mirrors":["https://docker.1ms.run", "https://docker.1panel.live", "https://hub.rat.dev", "https://docker.m.daocloud.io", "https://do.nark.eu.org", "https://dockerpull.com", "https://dockerproxy.cn", "https://docker.awsl9527.cn"], "exec-opts":["native.cgroupdriver=systemd"]} systemctl daemon-reload systemctl start docker# 验证配置docker info 

2、LangBot搭建

# 拉取代码 (该代码在gitcode,如果拉取不下来请在web端登陆下载zip)git clone https://gitcode.com/RockChinQ/LangBot 

启动服务

unzip LangBot-master.zip cd LangBot-master/docker # 启动容器docker compose up -d 

访问 http://ip:5300,首次登录需要初始化。

在这里插入图片描述

注册,登陆即可。

3、编辑流水线

在这里插入图片描述
在这里插入图片描述

点击AI能力,填写相关配置,在dify上查询智能体的URL与密钥,获取参数:

在这里插入图片描述

填写参数:

在这里插入图片描述

保存完成。

4、配置飞书机器人

由于本人使用的是个人账户,所以才可以这样胡作非为哈哈哈哈哈,有企业认证的大佬们就要谨慎了,这个需要管理员审核的。

打开飞书开放平台(https://open.feishu.cn/),点击企业自建应用,点击添加机器人能力:

在这里插入图片描述

配置相关权限:

左侧点击权限管理,右侧点击开通权限,搜索im:message,全部选择:

在这里插入图片描述

再次搜索:cardkit:card:write,开启该权限:

在这里插入图片描述

配置事件回调:

在这里插入图片描述

点击下放的添加事件,配置相关事件:

在这里插入图片描述

当一切都配置完成后发布机器人:

在这里插入图片描述

保存发布即可。

此时,去复制关键信息,LangBot接入飞书的关键凭证:

在这里插入图片描述

复制这两项信息。

到此,飞书配置完成。

5、创建机器人

在这里插入图片描述

配置相关信息:

在这里插入图片描述
在这里插入图片描述

保存即可。

6、进行测试

点击飞书的工作台,选择我们自己创建的机器人:

在这里插入图片描述

进行对话:

在这里插入图片描述

当dify接入了mcp后:

在这里插入图片描述

哈哈哈哈哈,后续会开源这个mcp-server服务器的,敬请期待啦。

附:遇到的问题

如若遇到相关问题,可以查看日志,在LangBot项目的Docker目录下存在log文件夹,查看日志解决问题:

在这里插入图片描述

解决:

访问:

https://open.feishu.cn/app/cli_a9d5778e15389cef/auth?q=cardkit:card:write&op_from=openapi&token_type=tenant 

开通该权限即可。

Read more

Selenium环境搭建完全指南:WebDriver版本匹配与生产级配置实践(Day 21-23)

引言:Web自动化的第一块多米诺骨牌 如果你曾尝试在深夜配置Selenium环境,大概率经历过这样的场景:满怀信心地写下webdriver.Chrome(),回车执行,浏览器窗口一闪而逝——秒退。紧接着是SSL握手失败的红色堆栈,GitHub Issue的彻夜鏖战,以及第二天早晨同事轻描淡写的一句“哦,你Chrome版本没对齐吧”。 环境搭建是Web自动化门槛最低、踩坑密度最高的环节。它不需要复杂的业务逻辑,却对细节有近乎偏执的要求:浏览器版本、驱动版本、系统架构、环境变量、二进制路径——任何一环脱节,整个自动化大厦便无从谈起。 Day 21-23的目标不是让你“跑通一个脚本”,而是建立对Selenium WebDriver底层交互机制的工程级认知。本文将从版本匹配的底层逻辑切入,覆盖跨平台配置、常见陷阱根治方案,并引入2026年主流的最佳实践工具链。读完本文,你将具备诊断并彻底解决环境问题的能力,而不再依赖“重装大法”。 一、Selenium WebDriver的本质:不只是“驱动” 1.1 拆解黑箱:WebDriver协议与浏览器内核 许多初学者将WebDriver误

三种适用于Web版IM(即时通讯)聊天信息的加密算法实现方案

三种适用于Web版IM(即时通讯)聊天信息的加密算法实现方案

文章目录 * **第一部分:引言与核心密码学概念** * **1.1 为什么IM需要端到端加密(E2EE)?** * **1.2 核心密码学概念与工具** * **第二部分:方案一:静态非对称加密(基础方案)** * **2.1 方案概述与流程** * **2.2 前端Vue实现(使用node-forge)** * **1. 安装依赖** * **2. 核心工具类 `crypto.js`** * **3. Vue组件中使用** * **2.3 后端Java实现(Spring Boot)** * **1. 实体类** * **2. Controller层** * **3. WebSocket配置** * **2.4 密钥管理、注册与登录集成** * **1. 用户注册/登录时生成密钥** * **2. 密钥设置页面** * **2.

基于C++11手撸前端Promise

基于C++11手撸前端Promise

文章导航 * 引言 * 前端Promise的应用与优势 * 常见应用场景 * 并发请求 * Promise 解决的问题 * 手写 C++ Promise 实现 * 类结构与成员变量 * 构造函数 * resolve 方法 * reject 方法 * then 方法 * onCatch 方法 * 链式调用 * 使用示例 * `std::promise` 与 `CProimse` 对比 * 1. 基础功能对比 * 2. 实现细节对比 * (1) 状态管理 * (2) 回调注册与执行 * (3) 异步支持 * (4) 链式调用 * 3. 代码示例对比 * (1) `CProimse` 示例 * (2) `std::promise` 示例 * 4.

前端CI/CD流程:自动化部署的正确打开方式

前端CI/CD流程:自动化部署的正确打开方式 毒舌时刻 CI/CD?听起来就像是前端工程师为了显得自己很专业而特意搞的一套复杂流程。你以为配置了CI/CD就能解决所有部署问题?别做梦了!到时候你会发现,CI/CD配置出错的概率比手动部署还高。 你以为随便找个CI/CD工具就能用?别天真了!不同的工具配置方式不同,坑也不同。比如Jenkins的配置文件就像是天书,GitLab CI的YAML语法也能让你崩溃。 为什么你需要这个 1. 自动化部署:CI/CD可以自动完成代码测试、构建和部署,减少手动操作,提高部署效率。 2. 减少人为错误:自动化部署可以避免手动部署时的人为错误,提高部署的可靠性。 3. 快速反馈:CI/CD可以在代码提交后立即进行测试和构建,及时发现问题,提供快速反馈。 4. 持续集成:CI/CD可以确保代码的持续集成,避免代码冲突和集成问题。 5. 环境一致性:CI/CD可以确保不同环境的配置一致,避免环境差异导致的问题。 反面教材