MaxKB 架构深度拆解RAG 智能体平台如何跑通一次问答请求【免费下载链接】MaxKB MaxKB is an open-source platform for building enterprise-grade agents. 强大易用的开源企业级智能体平台。项目地址: https://gitcode.com/GitHub_Trending/ma/MaxKB在 MaxKB 的聊天页面输入如何重置企业知识库权限并回车后系统并没有直接转发给大模型。它会先命中对应的应用Application把问题改写、检索知识库中的相关段落再把问题 段落拼进提示词最后由模型流式吐回答案。这套先检索、再生成的链路就是 RAG检索增强生成Retrieval-Augmented Generation在 MaxKB 里的完整形态。它解决什么问题MaxKB 的能力全景传统知识库系统有三个绕不开的痛点文档检索只支持关键词问法稍变就搜不到回答没有依据无法溯源到具体段落接入新的模型、新的工具都要改代码。MaxKB 的定位是开源的企业级智能体平台用一套模块化架构把这些事都落到代码里。能力模块说明对应源码位置知识库管理文档解析、分块、向量化、混合检索apps/knowledge/应用与工作流基于 LangGraph 的可视化编排apps/application/flow/聊天管道问题改写、段落检索、模型调用的分步执行apps/application/chat_pipeline/多模型接入统一接入 20 余家模型厂商apps/models_provider/impl/工具与 MCP外部工具、数据库、MCP 协议接入apps/tools/、apps/common/mcp/定时任务Celery django-apscheduler 周期任务apps/ops/celery/整体架构可以概括为三条线交互层Vue 3 管理端 聊天端双入口、服务层Django 5 单体应用按 app 划分业务、能力层LangChain/LangGraph pgvector。一次聊天请求的完整旅程从输入到模型调用以最常用的普通应用 关联知识库场景为例一次请求的链路如下。管道机制本身很薄。pipeline_manage.py 里的PipelineManage只做一件事按顺序执行一组 Step共享一个context字典。四个内置 Step 各司其职generate_human_message_step把原始输入改写成适合检索的查询句reset_problem_step如果命中了预设问题problem 表用预设句替换查询search_dataset_step执行段落检索chat_step调用 LLM 并输出。这种Step 列表 共享上下文的写法让新增一步比如加个敏感词过滤只需实现接口并插入列表不动主流程。技术底座拆解自底向上看三层选型AI 能力层LangChain LangGraph选型见 pyproject.tomllangchain1.3.10、langgraph1.2.6、langchain-openai、langchain-anthropic、langchain-deepseek、langchain-mcp-adapters等。选 LangChain 生态的理由是模型厂商 SDK 覆盖全选 LangGraph 是因为应用工作流需要图结构的节点编排而不是线性调用链。模型接入集中在 apps/models_provider/。impl/目录下有 20 多个厂商目录openai、anthropic、deepseek、zhipu、aliyun_bai_lian、local_model_provider 等每个目录按llm/embedding/tti/tts/stt五类模型能力拆分文件统一继承BaseModelProvider本地模型走 local_model_provider/底层依赖sentence-transformers5.0.0和torch离线环境可用installer/Dockerfile-vector-model单独构建向量模型容器。服务层Django 5 按 app 切业务后端没有上微服务而是 Django 5.2 DRF 3.17 单体业务按 app 目录切分users、knowledge、application、chat、models_provider、system_manage、trigger等每个 app 内部固定api / serializers / views / models / sql五件套。这个结构的好处是边界清晰——apps/maxkb/urls/web.py 里每行include()就是一个 app 的路由入口新人找代码不用翻配置文件。几个关键依赖django-redis缓存、django-db-connection-pool连接池、django-mptt文件夹树、drf-spectacularAPI 文档自动生成挂在/api-doc路径下。视图层用TokenAuth做认证、has_permissions装饰器做细粒度鉴权例如 knowledge 视图 中每个接口都显式声明了所需角色。交互层Vue 3 双入口前端是 ui/src/Vue 3.5 TypeScript Vite 6 Element Plus 2.13 Pinia 3。值得注意的是它构建了两个独立入口admin管理端和chat聊天端package.json里的build与build-chat分别产出两份静态资源Django 在非 DEBUG 模式下通过static.serve各自托管——管理端和聊天端在部署上就是两组静态文件加同一套 API 前缀。工作流编辑器基于logicflow/core实现拖拽编排聊天记录渲染支持 KaTeX、Mermaid、CodeMirror。数据怎么存、怎么查PostgreSQL 一个库通吃MaxKB 没有引入独立的向量数据库向量、分词索引、业务表全部落在 PostgreSQL靠 pgvector 扩展承担相似度计算。这个选型的取舍是少维护一个中间件代价是向量检索与业务查询共享连接池。核心表见 knowledge/models/knowledge.py表职责knowledge知识库关联 embedding 模型外键document文档status字段用 4 位字符串并行记录向量/问题/同步/分词四类任务状态paragraph段落chunks用 PostgresArrayField存分块结果embedding每条段落一行含vector类型向量列和SearchVectorField分词列problem/problem_paragraph_mapping预设问题与段落的映射混合检索的 SQL 在 apps/knowledge/sql/blend_search.sql核心逻辑是把两路分数加权成一个综合分WITH vector_top AS ( SELECT id, paragraph_id, (embedding::vector(%s) %s) AS distance -- 余弦距离 FROM embedding ${embedding_query} ORDER BY (embedding::vector(%s) %s) LIMIT LEAST(%s * 10, 500) ) SELECT paragraph_id, comprehensive_score FROM ( SELECT DISTINCT ON (vc.paragraph_id) vc.paragraph_id, (1 - vc.distance COALESCE(ts_rank_cd(e.search_vector, plainto_tsquery(simple, %s), 32), 0)) AS comprehensive_score FROM vector_top vc JOIN embedding e ON e.id vc.id ... ) sub WHERE comprehensive_score %s ORDER BY comprehensive_score DESC LIMIT %s性能上做了三点向量召回量按Top-K * 10放大后截断到 500 条控制召回-精排比例分词检索走ts_rank_cd全文索引文档解析、向量化等重活全部丢给 Celery 异步执行不阻塞 API 线程。原始文件则压缩后写入 PostgreSQL Large Objectloid字段同一库内自包含不用额外挂对象存储。如何把它跑起来容器化部署与服务扩展installer/ 目录给出完整部署物料Dockerfile应用镜像、Dockerfile-vector-model本地向量模型镜像、start-postgres.sh、start-redis.sh、start-maxkb.sh、init.sql初始化库和 pgvector 扩展。最小化部署即一个应用容器 PostgreSQL带 pgvector Redis三件套前端静态资源已打包进应用镜像由 Gunicorn 直接托管不需要单独起 Nginx 也能跑。服务拆分与扩展能力体现在两个维度异步拆分文档解析、embedding 批量写入由 Celery workerapps/ops/celery/承担重负载场景可以单独横向加 worker不影响 API 进程双入口拆分管理端与聊天端是两组独立 URL 前缀/admin、/chat聊天端可以直接嵌入业务系统管理端限内网访问安全域天然分开。工程化细节清单安全、可观测与性能维度落地方式位置认证自研TokenAuth登录接口带图形验证码captcha依赖apps/common/auth/授权has_permissions装饰器角色 × 资源 × 工作空间三级校验apps/common/constants/permission_constants.py密钥安全RSA 加解密工具、模型 API Key 加密存储apps/common/utils/rsa_util.pyMCP 沙箱代码类工具在独立沙箱进程执行apps/common/mcp/sandbox.py操作日志log装饰器记录接口调用log_management模型持久化apps/common/log/API 文档drf-spectacular 自动产出 OpenAPI 文档/api-doc路由缓存django-redis 缓存 access token、API Key 等热点数据apps/common/cache_data/连接池django-db-connection-pool 管理 Postgres 连接pyproject.toml定时清理聊天记录、临时文件按策略周期清理apps/common/job/统计报表预置 SQL 做 Token 用量、热门问题、客户趋势统计apps/application/sql/小结MaxKB 的架构特色可以概括为一句话Django 单体按 app 切模块LangChain/LangGraph 承载 AI 能力PostgreSQL 一个库同时承担业务表、向量库和文件存储。它没有上微服务、没有独立向量数据库工程复杂度控制得比较克制对想自建 RAG 问答平台、需要可控运维成本的团队是一个值得逐 app 精读的实现样本。后续版本里MCP 协议接入和 deepagents 智能体能力的比重会越来越高这条链路的演进也值得持续跟踪。【免费下载链接】MaxKB MaxKB is an open-source platform for building enterprise-grade agents. 强大易用的开源企业级智能体平台。项目地址: https://gitcode.com/GitHub_Trending/ma/MaxKB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MaxKB 架构深度拆解：RAG 智能体平台如何跑通一次问答请求
MaxKB 架构深度拆解RAG 智能体平台如何跑通一次问答请求【免费下载链接】MaxKB MaxKB is an open-source platform for building enterprise-grade agents. 强大易用的开源企业级智能体平台。项目地址: https://gitcode.com/GitHub_Trending/ma/MaxKB在 MaxKB 的聊天页面输入如何重置企业知识库权限并回车后系统并没有直接转发给大模型。它会先命中对应的应用Application把问题改写、检索知识库中的相关段落再把问题 段落拼进提示词最后由模型流式吐回答案。这套先检索、再生成的链路就是 RAG检索增强生成Retrieval-Augmented Generation在 MaxKB 里的完整形态。它解决什么问题MaxKB 的能力全景传统知识库系统有三个绕不开的痛点文档检索只支持关键词问法稍变就搜不到回答没有依据无法溯源到具体段落接入新的模型、新的工具都要改代码。MaxKB 的定位是开源的企业级智能体平台用一套模块化架构把这些事都落到代码里。能力模块说明对应源码位置知识库管理文档解析、分块、向量化、混合检索apps/knowledge/应用与工作流基于 LangGraph 的可视化编排apps/application/flow/聊天管道问题改写、段落检索、模型调用的分步执行apps/application/chat_pipeline/多模型接入统一接入 20 余家模型厂商apps/models_provider/impl/工具与 MCP外部工具、数据库、MCP 协议接入apps/tools/、apps/common/mcp/定时任务Celery django-apscheduler 周期任务apps/ops/celery/整体架构可以概括为三条线交互层Vue 3 管理端 聊天端双入口、服务层Django 5 单体应用按 app 划分业务、能力层LangChain/LangGraph pgvector。一次聊天请求的完整旅程从输入到模型调用以最常用的普通应用 关联知识库场景为例一次请求的链路如下。管道机制本身很薄。pipeline_manage.py 里的PipelineManage只做一件事按顺序执行一组 Step共享一个context字典。四个内置 Step 各司其职generate_human_message_step把原始输入改写成适合检索的查询句reset_problem_step如果命中了预设问题problem 表用预设句替换查询search_dataset_step执行段落检索chat_step调用 LLM 并输出。这种Step 列表 共享上下文的写法让新增一步比如加个敏感词过滤只需实现接口并插入列表不动主流程。技术底座拆解自底向上看三层选型AI 能力层LangChain LangGraph选型见 pyproject.tomllangchain1.3.10、langgraph1.2.6、langchain-openai、langchain-anthropic、langchain-deepseek、langchain-mcp-adapters等。选 LangChain 生态的理由是模型厂商 SDK 覆盖全选 LangGraph 是因为应用工作流需要图结构的节点编排而不是线性调用链。模型接入集中在 apps/models_provider/。impl/目录下有 20 多个厂商目录openai、anthropic、deepseek、zhipu、aliyun_bai_lian、local_model_provider 等每个目录按llm/embedding/tti/tts/stt五类模型能力拆分文件统一继承BaseModelProvider本地模型走 local_model_provider/底层依赖sentence-transformers5.0.0和torch离线环境可用installer/Dockerfile-vector-model单独构建向量模型容器。服务层Django 5 按 app 切业务后端没有上微服务而是 Django 5.2 DRF 3.17 单体业务按 app 目录切分users、knowledge、application、chat、models_provider、system_manage、trigger等每个 app 内部固定api / serializers / views / models / sql五件套。这个结构的好处是边界清晰——apps/maxkb/urls/web.py 里每行include()就是一个 app 的路由入口新人找代码不用翻配置文件。几个关键依赖django-redis缓存、django-db-connection-pool连接池、django-mptt文件夹树、drf-spectacularAPI 文档自动生成挂在/api-doc路径下。视图层用TokenAuth做认证、has_permissions装饰器做细粒度鉴权例如 knowledge 视图 中每个接口都显式声明了所需角色。交互层Vue 3 双入口前端是 ui/src/Vue 3.5 TypeScript Vite 6 Element Plus 2.13 Pinia 3。值得注意的是它构建了两个独立入口admin管理端和chat聊天端package.json里的build与build-chat分别产出两份静态资源Django 在非 DEBUG 模式下通过static.serve各自托管——管理端和聊天端在部署上就是两组静态文件加同一套 API 前缀。工作流编辑器基于logicflow/core实现拖拽编排聊天记录渲染支持 KaTeX、Mermaid、CodeMirror。数据怎么存、怎么查PostgreSQL 一个库通吃MaxKB 没有引入独立的向量数据库向量、分词索引、业务表全部落在 PostgreSQL靠 pgvector 扩展承担相似度计算。这个选型的取舍是少维护一个中间件代价是向量检索与业务查询共享连接池。核心表见 knowledge/models/knowledge.py表职责knowledge知识库关联 embedding 模型外键document文档status字段用 4 位字符串并行记录向量/问题/同步/分词四类任务状态paragraph段落chunks用 PostgresArrayField存分块结果embedding每条段落一行含vector类型向量列和SearchVectorField分词列problem/problem_paragraph_mapping预设问题与段落的映射混合检索的 SQL 在 apps/knowledge/sql/blend_search.sql核心逻辑是把两路分数加权成一个综合分WITH vector_top AS ( SELECT id, paragraph_id, (embedding::vector(%s) %s) AS distance -- 余弦距离 FROM embedding ${embedding_query} ORDER BY (embedding::vector(%s) %s) LIMIT LEAST(%s * 10, 500) ) SELECT paragraph_id, comprehensive_score FROM ( SELECT DISTINCT ON (vc.paragraph_id) vc.paragraph_id, (1 - vc.distance COALESCE(ts_rank_cd(e.search_vector, plainto_tsquery(simple, %s), 32), 0)) AS comprehensive_score FROM vector_top vc JOIN embedding e ON e.id vc.id ... ) sub WHERE comprehensive_score %s ORDER BY comprehensive_score DESC LIMIT %s性能上做了三点向量召回量按Top-K * 10放大后截断到 500 条控制召回-精排比例分词检索走ts_rank_cd全文索引文档解析、向量化等重活全部丢给 Celery 异步执行不阻塞 API 线程。原始文件则压缩后写入 PostgreSQL Large Objectloid字段同一库内自包含不用额外挂对象存储。如何把它跑起来容器化部署与服务扩展installer/ 目录给出完整部署物料Dockerfile应用镜像、Dockerfile-vector-model本地向量模型镜像、start-postgres.sh、start-redis.sh、start-maxkb.sh、init.sql初始化库和 pgvector 扩展。最小化部署即一个应用容器 PostgreSQL带 pgvector Redis三件套前端静态资源已打包进应用镜像由 Gunicorn 直接托管不需要单独起 Nginx 也能跑。服务拆分与扩展能力体现在两个维度异步拆分文档解析、embedding 批量写入由 Celery workerapps/ops/celery/承担重负载场景可以单独横向加 worker不影响 API 进程双入口拆分管理端与聊天端是两组独立 URL 前缀/admin、/chat聊天端可以直接嵌入业务系统管理端限内网访问安全域天然分开。工程化细节清单安全、可观测与性能维度落地方式位置认证自研TokenAuth登录接口带图形验证码captcha依赖apps/common/auth/授权has_permissions装饰器角色 × 资源 × 工作空间三级校验apps/common/constants/permission_constants.py密钥安全RSA 加解密工具、模型 API Key 加密存储apps/common/utils/rsa_util.pyMCP 沙箱代码类工具在独立沙箱进程执行apps/common/mcp/sandbox.py操作日志log装饰器记录接口调用log_management模型持久化apps/common/log/API 文档drf-spectacular 自动产出 OpenAPI 文档/api-doc路由缓存django-redis 缓存 access token、API Key 等热点数据apps/common/cache_data/连接池django-db-connection-pool 管理 Postgres 连接pyproject.toml定时清理聊天记录、临时文件按策略周期清理apps/common/job/统计报表预置 SQL 做 Token 用量、热门问题、客户趋势统计apps/application/sql/小结MaxKB 的架构特色可以概括为一句话Django 单体按 app 切模块LangChain/LangGraph 承载 AI 能力PostgreSQL 一个库同时承担业务表、向量库和文件存储。它没有上微服务、没有独立向量数据库工程复杂度控制得比较克制对想自建 RAG 问答平台、需要可控运维成本的团队是一个值得逐 app 精读的实现样本。后续版本里MCP 协议接入和 deepagents 智能体能力的比重会越来越高这条链路的演进也值得持续跟踪。【免费下载链接】MaxKB MaxKB is an open-source platform for building enterprise-grade agents. 强大易用的开源企业级智能体平台。项目地址: https://gitcode.com/GitHub_Trending/ma/MaxKB创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考