
整体架构:三层进程模型
LangBot 的插件系统由三层进程协作:
- LangBot 主进程:运行业务逻辑(消息处理流水线、平台适配、模型调用),通过
PluginRuntimeConnector连接 Runtime。 - Plugin Runtime:插件的”编排层”,负责发现、启动、管理所有插件子进程,接收主进程的指令并分发到对应插件。
- 插件子进程:每个插件独立运行在自己的 Python 进程中,通过 stdio 管道与 Runtime 通信。
为什么要三层而不是两层?
直觉的设计是主进程直接管理插件进程。LangBot 选择中间加一层 Runtime 的原因是部署灵活性:- 本地开发:主进程通过 stdio 直接启动 Runtime 子进程(零配置)
- Docker 生产环境:Runtime 作为独立容器运行,主进程通过 WebSocket 连接
- Windows 兼容:由于 Windows 的 asyncio 不完整支持 stdio 子进程,Windows 上自动降级为 WebSocket 通信
通信协议:JSON-RPC 风格的请求/响应
所有跨进程通信基于一个统一的协议层。核心数据结构非常简洁:Handler 是整个系统的核心抽象。它同时扮演 RPC 客户端和服务端:
- 基于
seq_id的请求/响应匹配,支持全双工并发调用 - 支持流式响应(
chunk_status),用于命令执行等长时间操作 - 大消息自动分块传输(stdio 16KB / WebSocket 64KB 分块)
- 文件传输通过 base64 分块机制实现,不走消息通道
Action 枚举:清晰的 API 契约
系统通过四组枚举严格定义了所有跨进程调用:插件生命周期
一个插件从安装到运行,经历以下阶段:1. 发现(Discovery)
Runtime 启动时扫描data/plugins/ 目录:
{author}__{name},每个目录包含 manifest.yaml 和插件代码。
2. 启动(Launch)
Runtime 为每个插件启动独立子进程:3. 注册(Register)
插件进程启动后,主动向 Runtime 注册自己:4. 运行(Running)
插件进入INITIALIZED 状态后,即可接收事件、工具调用、命令执行等请求。
5. 卸载(Shutdown)
组件系统:四种扩展类型
LangBot 的插件不是一个单一的 hook 函数,而是一个组件容器。一个插件可以同时提供多种类型的组件:EventListener(事件监听器)
最基础的扩展方式——监听流水线中的事件:
事件传播支持两种中断:
prevent_default():阻止默认行为(如跳过 LLM 调用)prevent_postorder():阻止后续插件执行
Tool(工具)
供 LLM 的 Function Calling 调用的工具:Command(命令)
用户通过!command 触发的命令,支持子命令注册:
AsyncGenerator 返回,天然支持流式输出。
KnowledgeRetriever(知识检索器)
多实例组件,用于接入外部知识库:SDK API:插件能做什么
插件通过BasePlugin 基类继承的 LangBotAPIProxy 获得丰富的能力:
plugin_storage(插件私有)和 workspace_storage(全局共享),数据以 bytes 形式存储(base64 序列化传输),简单但足够灵活。
事件分发机制
事件从主进程到插件的完整路径:
include_plugins 参数实现了流水线级别的插件绑定——不同的消息处理流水线可以使用不同的插件子集。
安装与分发
插件支持三种安装来源:- 本地上传:
.lbpkg文件(实际上是 zip 包,包含 manifest.yaml 和代码) - 插件市场:从 LangBot Space 在线安装
- GitHub Release:从 GitHub 仓库的 Release 资产下载
AsyncGenerator 流式报告进度,前端可以实时显示安装状态。
调试体验
SDK 提供了完善的开发者工具链:与其他系统的对比
vs Dify 插件
Dify 的插件系统(dify-plugin-daemon)与 LangBot 有相似的进程隔离理念,但侧重点不同:
- Dify:插件扩展的是工作流节点类型(Tool、Model、Extension),面向 AI 应用编排
- LangBot:插件扩展的是消息处理流水线(Event、Tool、Command、KnowledgeRetriever),面向即时通讯场景
EventListener 组件提供了 Dify 没有的能力——在消息处理的任意阶段插入逻辑。
vs MCP(Model Context Protocol)
MCP 是一个标准化的 AI 工具调用协议。LangBot 的 Tool 组件和 MCP 服务功能上有重叠,但定位不同:- MCP:通用的”AI 调用外部能力”协议,任何 LLM 应用都能用
- LangBot Tool:深度集成在消息处理上下文中,能访问会话信息、用户身份等
设计决策背后的思考
为什么选择进程隔离而非线程/协程?- 插件代码质量不可控,一个 segfault 不应该崩掉整个服务
- 依赖隔离:不同插件可能依赖同一个库的不同版本
- 资源可控:可以对单个插件进程设置资源限制
- 调试友好:开发者可以直接阅读通信日志
- Python 生态原生支持,无需额外依赖
- 性能瓶颈不在序列化(插件调用频率远低于数据库查询)
- stdio 无需网络栈,延迟更低
- 进程生命周期管理更简单(父进程退出时子进程自动清理)
- WebSocket 只在不支持 stdio 的场景(Docker、Windows)使用
总结
LangBot 的插件系统是一个为生产环境设计的、进程隔离的、事件驱动的组件化扩展框架。 它的核心设计原则:- 安全第一:进程隔离确保插件不会影响主服务稳定性
- 部署灵活:stdio/WebSocket 双模式适配所有环境
- 开发者友好:完善的 SDK、CLI 和调试支持
- 组件化:四种组件类型覆盖主要扩展需求
