LangBot v4.9.0 的版本代号是“Knowledge Without Borders”，意思很直接：整个知识库能力已经从内置实现重构为插件驱动架构。这不是一次小修小补，而是重新定义了 LangBot 里“知识”的含义。

旧方案为什么难用

打开网易新闻 查看精彩图片

在 v4.9.0 之前，LangBot 的知识库被拆成两套独立系统。内置知识库使用 Chroma 作为向量数据库，嵌入模型由 LangBot 直接管理，文档解析、分块和索引全部硬编码。外部知识库则通过 KnowledgeRetriever 插件组件桥接 Dify、RAGFlow、FastGPT 等服务，只做检索，不做文档导入。

这两套系统放在不同的界面标签页下，数据模型和管理流程完全不同。带来的问题也很明显：扩展性差，想换向量数据库或自定义分块策略都不行；维护成本高，每次 RAG 改进都要改 LangBot 核心代码并发布新版本；用户体验割裂，两套知识库管理流程让学习曲线变陡。

统一模型与 KnowledgeEngine 组件

v4.9.0 的解法是把 RAG 能力从 LangBot 核心中抽出来，交给插件。内部和外部的区分被取消，所有知识库都通过单一界面管理，只靠 rag_engine_plugin_id 区分。一个列表、一个创建流程，选择引擎即可。

最核心的新增是 KnowledgeEngine 组件。它取代了旧的 KnowledgeRetriever，接管知识库完整生命周期：文档导入，从文件解析到向量索引的完整流水线；知识检索，在查询时返回相关分块；文档删除，清理文档及其关联向量数据；生命周期钩子，在知识库创建或删除时触发回调。也就是说，KnowledgeEngine 插件对索引和检索策略拥有完整控制权，而不只是检索。

Parser 组件与数据流

文档解析被抽成独立的插件组件类型。Parser 把 PDF、Word、Markdown 等二进制文件转换成结构化文本，再交给 RAG 引擎做分块和索引。如果某个 RAG 引擎声明了 DOC_PARSING 能力，它可以在内部处理解析，跳过外部 Parser。

Host RAG API 提供基础设施

LangBot 核心不再直接执行 RAG 操作，但仍通过 RAGRuntimeService 提供必要的基础设施，插件可以通过 RPC 访问。具体包括：嵌入调用 invoke_embedding()，插件不需要管理模型连接；向量数据库操作 vector_upsert()、vector_search()、vector_delete()；文件访问 get_knowledge_file_stream()，从存储中读取原始文件。

这样一来，插件可以专注于 RAG 策略本身，比如分块算法、检索逻辑和重排序，而不用操心底层连接和存储细节。