Openaibot：用插件生态把 GPT-4 机器人搬进 Discord、Discord 和 Kook

你有没有想过，在 Discord 群里直接喊一句「@AI Bot，帮我写一段快速排序」，就能立刻得到答案？在 Slack 工作频道里发一条指令，让 AI 自动回复客户问题，而不需要切换到 ChatGPT 网页？这正是 Openaibot 试图解决的事情——把强大的 LLM 能力，无缝嵌入到大家日常泡在里面的即时通讯平台。

这不是一个简单的 ChatGPT 接入工具。作者 sudoskys 在项目中写道，这是一个 MQ（Message Queue）事件驱动 LLM 的实验性项目，经历了四次迭代，已经成为一套完整的、生产级别的机器人框架，支持 Telegram、Discord、Kook、Slack 四大平台，在 GitHub 上收获了接近 2000 颗星。

为什么需要一个 LLM 聊天机器人框架？

单独使用 ChatGPT API 本身并不难，但一旦把它放到多人、多平台的实际场景中，问题就复杂了：消息来自不同平台（Discord/Telegram/Kook/Slack），有群聊有私聊，有指令有闲聊，还要记住对话上下文、执行函数调用、控制插件权限——这些都需要一套完整的事件分发、消息队列和插件生命周期管理机制。

Openaibot 的核心思路是消息队列 + 快照系统：所有进站消息进入 RabbitMQ 队列，经过鉴权、插件权限检查和消息快照后，分发给对应的处理器。整个架构天然支持高并发和消息重试，也天然支持插件的懒加载——即使装了几十个插件，也不会拖慢 Bot 启动速度。

图1：Openaibot 项目封面（来源：LlmKira 官方仓库）

架构：从消息接收器到插件生态

Openaibot 的代码结构分为两层：接收层（Receiver） 和 发送层（Sender），中间由 RabbitMQ 连接。

• app/receiver/：各平台适配器目录，分别有 telegram/、discord/、kook/、slack/ 子目录，继承统一的 Receiver 基类。只需实现 receive_message() 和 send_message() 两个接口，就能接入新平台。
• app/sender/：消息分发和响应处理器，负责把 RabbitMQ 队列中的消息路由到对应插件。
• llmkira/openai/：封装了与 OpenAI API 的交互，包括 request.py（API 调用）、cell.py（消息单元）和 utils.py（工具函数）。
• llmkira/logic/、llmkira/memory/、llmkira/task/：分别处理业务逻辑、对话记忆和任务管理。
• llmkira/sdk/：插件 SDK，提供了插件开发的最小接口。

这种架构的好处是关注点分离：平台适配器只管消息收发，业务逻辑和 AI 能力完全独立。换个平台，不用改一行 AI 相关代码。

图2：链式对话（Chain Chat）功能演示（来源：项目 README）

插件系统：pip 安装即用

Openaibot 最值得称道的部分是其插件生态。项目采用 pip 安装式插件，开发者把插件打包成 Python 包发布到 PyPI，用户只需 pip install xxx 就能安装，无需复制文件、无需修改配置目录。插件可以声明自己的依赖项、环境变量，甚至可以控制自己在新会话中是否显示。

插件还支持函数调用（Function Calling）——这是 GPT-4 在 2023 年带来的核心能力，Openaibot 第一时间接入了。当 Bot 收到一条需要工具辅助的请求时，它会通过 OpenAI Function Calling 接口判断需要哪个插件，然后把控制权交给插件处理。

内置的插件包括：表情包转换器、定时任务、代码解释器、图片生成等。开发者参考 llmkira/extra/ 下的示例（如 voice_hook.py），可以快速编写自己的 Hook 和插件。

图3：表情包转换插件演示（来源：项目 README）

图4：定时任务插件演示（来源：项目 README）

代码解释器：GPT-4 当你的终端

项目还演示了一个代码解释器（Code Interpreter） 功能：用户发一段代码，Bot 自动执行并返回结果。这不是简单调用 exec()，而是通过 OpenAI Function Calling + Docker 容器隔离执行的沙箱模式，安全地运行用户代码。

图5：代码解释器插件演示（来源：项目 README）

部署：一条命令全搞定

部署 Openaibot 完全没有想象中那么复杂。项目提供了两种开箱即用的部署方式：

方式一：docker-compose 一键启动（推荐）

git clone https://github.com/LlmKira/Openaibot.git
cd Openaibot
cp .env.exp .env && nano .env  # 填写 OpenAI API Key 等配置
docker-compose -f docker-compose.yml up -d

docker-compose.yml 已经内置了 Redis、RabbitMQ 和 MongoDB，启动后整个系统就跑起来了。资源限制也已配置好：最多 0.9 核 CPU、4GB 内存，生产级配置。

方式二：单脚本自动安装

curl -sSL https://raw.githubusercontent.com/LLMKira/Openaibot/main/deploy.sh | bash

这个脚本会自动安装 Python 3.9+、RabbitMQ、FFmpeg 和项目依赖，适合全新服务器。

Dockerfile 采用了多阶段构建：第一阶段用 python:3.9-buster + PDM 安装所有依赖；第二阶段用 python:3.9-slim-buster 打包成精简镜像，并安装 npm + PM2 进程管理。镜像已发布到 Docker Hub：sudoskys/llmbot:main。

需要注意的是，Openaibot 没有 Web UI，所有配置和交互都在终端完成。但它提供了完整的斜杠命令（Slash Commands）：/login（登录 API）、/chat（对话）、/task（函数对话）、/tool（列出所有插件）、/auth（授权插件）、/learn（训练指令）。

技术栈：纯 Python + MQ 事件驱动

组件	技术选型
核心语言	Python 3.9+
消息队列	RabbitMQ (aio-pika)
数据库	Redis（会话缓存）、MongoDB（消息快照）
AI 接口	OpenAI API（gpt-4o、gpt-4-vision-preview 等）
插件系统	pip 安装 + Arclet Alconna（指令解析框架）
进程管理	PM2（Node.js 全局安装，用于管理 Python 进程）
日志	Loguru（彩色结构化日志）
错误追踪	Sentry SDK

有趣的是，项目用 Node.js 安装 PM2 来管理 Python 进程——不是用 systemd，而是 PM2。这是因为 PM2 提供了零配置集群模式、负载均衡和日志轮转，比 systemd 更适合容器化环境。

争议与局限

Openaibot 也有它的局限性：

1. 仅支持 OpenAI 格式：项目坚定拥抱 OpenAI Schema，所有模型调用必须符合 OpenAI 的请求/响应格式。这意味着使用自建模型（如 ollama、本地 LLaMA）需要通过 gateway 或 one-api 做一层代理转换。
2. 没有 Web UI：配置全部在 .env 文件和终端完成，对非技术用户有一定门槛。
3. Kook/Slack 平台不完全支持：不支持「回复触发」功能，限制了某些对话场景的使用。
4. 插件安全边界：插件通过 pip 安装，拥有和 Bot 进程同等的权限，需要用户自行审核插件来源。

行业意义：从工具到平台

Openaibot 代表了一个趋势——LLM 应用从单点工具向平台生态演进。它的插件系统借鉴了成熟生态（pip、npm）的安装体验，而 MQ 事件驱动架构让它具备了企业级应用的可扩展性。作者在 Roadmap 中明确写道，项目的下一步方向是让插件环境能够访问 LLM 引用（检索增强），这将进一步提升插件的智能化程度。

截至目前，该项目已迭代至第四代，star 数接近 2000，fork 数超过 220，是多平台 AI Bot 领域的标杆项目之一。如果你正在考虑把 LLM 能力嵌入到即时通讯平台，Openaibot 值得深入研究其架构设计。

---

本文档基于 GitHub 仓库公开信息生成，仅供研究参考。