插件系统

大多数聊天机器人框架的"插件系统"不过是一个 Python 模块的动态导入。LangBot 4.0 选择了一条更难但更正确的路——每个插件运行在独立进程中，通过结构化的 JSON-RPC 风格协议与宿主通信。 这篇文章将从源码出发，完整拆解这套系统的设计。 整体架构：三层进程模型 LangBot 的插件系统由三层进程协作： 三个层次各司其职： LangBot 主进程：运行业务逻辑（消息处理流水线、平台适配、模型调用），通过 PluginRuntimeConnector 连接 Runtime。 Plugin Runtime：插件的"编排层"，负责发现、启动、管理所有插件子进程，接收主进程的指令并分发到对应插件。 插件子进程：每个插件独立运行在自己的 Python 进程中，通过 stdio 管道与 Runtime 通信。 为什么要三层而不是两层？ 直觉的设计是主进程直接管理插件进程。LangBot 选择中间加一层 Runtime 的原因是部署灵活性： 本地开发：主进程通过 stdio 直接启动 Runtime 子进程（零配置） Docker 生产环境：Runtime 作为独立容器运行，主进程通过 WebSocket 连接 Windows 兼容：由于 Windows 的 asyncio 不完整支持 stdio 子进程，Windows 上自动降级为 WebSocket 通信 这意味着同一套代码，不改配置，就能适配从开发到生产的全部场景。 通信协议：JSON-RPC 风格的请求/响应 所有跨进程通信基于一个统一的协议层。核心数据结构非常简洁： # 请求 class ActionRequest(pydantic.BaseModel): seq_id: int # 序列号，用于匹配请求和响应 action: str # 动作名称 data: dict # 载荷 # 响应 class ActionResponse(pydantic.BaseModel): seq_id: int code: int # 0 = 成功 message: str data: dict chunk_status: str # "continue" | "end"（支持流式响应） 通信层 Handler 是整个系统的核心抽象。它同时扮演 RPC 客户端和服务端： ...