两周之内，两个不同行业的朋友先后找我聊同一件事。一家做设备的，想给售后团队配个 AI 客服；一家做咨询的，想让新员工少翻老文档。两家卡的地方一模一样：Demo 半天就能调通，真往公司里推，模型密钥散在三个人的记事本里，文档散在网盘五个文件夹，没人说得清哪份是最新版，更没人说得清线上跑的到底是哪家模型。

AI 落地难的从来不是调通模型，是调通之后没人管得住，密钥、文档、权限，最后全变成嘴上的管理，出了事连该找谁都说不上来，回头翻聊天记录才发现没人接这个活，这种局面我见过不止一回。

今天聊的这套开源企业级 AI 助手平台叫乾坤，做的就是把这摊事收拢：统一接模型、统一管知识库，配置全在后台页面上点，前后端分离，Docker 一键部署。

项目定位也交代得清楚：它不是从零造轮子，底子是一套成熟的企业后台管理框架，AI 那一层用 LangChain 撑起来，给研发团队一个能直接二次开发的起点，把从试用到大上线的周期压短。当起点合适，当终点就不够看。

十几个大模型，怎么在一个后台里全接进来？

先说模型这头。它用 LangChain4j 做统一抽象，DeepSeek、通义千问、文心一言、豆包、智谱、星火、OpenAI、Gemini、Azure、Claude 都能接，连本地跑的 Ollama 也在支持列表里，README 一共点了 11 家，实际以配置为准。

不想把数据送出内网的，Ollama 那条路就是留给你：模型本地起，数据不出门。这条对国企、医院这类数据敏感的单位，往往就是选型的先决条件，过不了数据出门这一关，别的都白谈。

接进来之后怎么管，才是这套平台真正下功夫的地方。管理端是可视化页面，模型名称、参数、API Key 全在界面上配，换供应商不动一行代码，改完配置就生效。做过集成的人都懂这值多少：各家 SDK 接口参差，Key 一轮换全员手忙脚乱，有个统一入口，环境切换的成本直接砍掉。

多接一家供应商就多一条退路：能比价、防单点故障，还能不同任务配不同模型，写代码的接一家，做客服的接另一家，这是企业侧实打实的需求。

网盘里的文档，怎么变成能开口回答的知识？

知识库走的是标准 RAG 路线：文档上传后做向量化，提问时先按 Embedding 检索出相关段落，再交给大模型组织答案。比直接问模型强的地方在于，答案带着依据，能溯源到具体文档，不是凭感觉编。

分组做得比较细：不同知识库可以关联不同模型和不同向量数据库，向量库支持 Milvus 和 PGVector，按需选装，不强制。量不大时 PGVector 就够，别一上来就堆 Milvus。

有句实话得说在前面：平台把链路搭好了，效果的上限却取决于你自己的文档质量。切得稀碎的 PDF 喂进去，神仙检索也救不回来。另外知识库分组可以按部门来，人事一个库、研发一个库，权限隔清楚了，回答也不会串味。

三个场景，拿去就能对号入座

第一个，企业制度与流程问答。人事制度、报销流程、IT 规范导进知识库，员工从统一入口提问，人事不用一遍遍回同样的问题。对那种制度文档几百页、员工从来不看的公司，这一条就值回部署成本。顺带把入职培训的问答也挂上去，新人前两周的高频问题八成能在这里找到答案。

第二个，客服和运营助手。给一线配专属助手和 Prompt，挂上产品手册知识库，客户问什么，回答带着手册出处，新人培训周期肉眼可见地短，夜班排班也不用再靠老员工硬顶。

第三个，研发与实施的知识沉淀。接口文档、部署说明、FAQ 进库，新成员用对话找上下文，比在群里等回话快得多，老员工脑子里那些只有他自己知道的细节，也能沉淀成公共资产。同理适用于运维值班手册、售前打单的问答库，凡是重复回答超过三次的知识，都值得进库。

除了 AI，后台还带多少东西？

它不是个光杆 Demo，底子是完整的企业后台：用户、角色、权限管理，对象存储，定时任务，服务监控，甚至带代码生成器和流程模块。技术栈后端 Java 17 加 Spring Boot 3.4，认证用 Sa-Token，数据访问 MyBatis；前端 Vue 3 配 Vite，组件库 Naive UI，样式 Tailwind；数据层 MySQL 8.0 兼容 5.7，Redis 5 以上。

对有 Java 底子的团队来说，这套底座几乎没学习门槛，Spring 那套分层、权限、定时任务都是老熟人，二次开发是在熟路上走路，不是换轨道，上手成本低得很。

多久能跑起来？

最快的一条路是 Docker。装好 Docker Desktop 或 Docker Engine，按需改根目录 .env 里的端口和密码，一条命令拉起全部服务。默认四个端口：前端 10010，后端 API 10011，MySQL 10012，Redis 10013，内存建议备 8GB 以上。第一次起完服务，先看后端日志确认数据库和缓存都连上了，再去开前端页面，能省掉一半排查时间。

想本地开发也行，环境要求写在明面上：JDK 17 以上、Maven 3.8 以上、Node 22 加 pnpm。先建库导 script/sql/init.sql，再在 application-dev.yml 里配数据源和 Redis，后端进 qiankun-admin 跑 mvn spring-boot:run，前端进 qiankun-ui/langchain-ui 跑 pnpm run dev。开发库建议单独建一个，别跟 Docker 那套共用实例，免得端口打架。

常见坑 README 也提前铺了一排。最有画面感的一条：Docker 引擎报 500、启动无响应，处理办法是执行 wsl --shutdown 再重启 Docker Desktop，必要时清理 docker-desktop 的 WSL 数据。向量检索查不到结果，就挨个排三处：Embedding 模型、向量库连接、文档有没有向量化完成。依赖下载慢，就配上 Maven 和 pnpm 的国内镜像源。

我的判断：谁该上，谁先别急

最适合的，是有研发能力、想把 AI 助手攥在自己手里的团队。模型自己选、知识库自己喂、Prompt 自己调，它省下的是工程化那一段：不用从零搭后台、从零对接各家 SDK、从零写权限和任务调度。这类底座的价值要把时间线拉长看：第一年省的是接各家模型的重复劳动，往后省的是换模型、扩知识库时的迁移成本。

反过来说，想要开箱即用零配置的，它可能不是那杯茶。向量库和对象存储要选装，知识库运营要人来盯，指望导几个文档就出神答复，不现实。

再补一句：RAG 解决的是找得到、说得清，不保证答得对。涉及钱、合同、制度的回答，人工核对这道环节不能省。尤其拿去对外回答客户问题时，一次答错的代价可能比省下的人工贵得多，关键流程必须留复核。

节奏上我建议这么走：先用 Docker 起一遍看界面，再拿真实文档建一个小知识库试问答，效果能接受再谈接业务系统。顺序别反，反过来就是先花一周配环境，然后发现文档根本没整理。环境配好当天就能出第一版问答演示，剩下的时间都应该花在整理文档上。

源代码网址：https://www.gitcc.com/Crosstalk/qiankun-ai-zs