用Dify构建知识库，结合NextChat做RAG知识问答，打造灵活可定制的AI助手

在上一篇文章中，我们分享了如何使用 Dify 搭建个人知识库。这次介绍下如何通过 Dify 的 API，将后端强大的知识库能力“输送”到 NextChat 前端，用各自最擅长的部分，构建自己的AI私人助手。

为什么选择 Dify + NextChat？

从技术角度看，我们希望技术选型的链路上是可插拔、可解耦合的，同时各个技术模块是有专长的。尽管很多开源组件追求大而全，但从技术负责人视角看，这个要有绝对的技术选项和判断力，知道什么业务在什么阶段使用什么样的技术组件，以及保留足够的扩展性！

Dify 负责知识库管理、模型配置、复杂工作流编排。它的 RAG 能力（如混合检索、重排序）目前是开源界的一流水准。（但是如果做企业级的知识库，可能就需要调整了，但这目前不影响我们架构）

NextChat 主要就是做AI助手的前端，可以理解为一个chatgpt类似的对话AI系统，可以方便的通过配置API key就能接受数据呈现出来问答，前台是API是标准的openAI规范，目前大模型绝大部分都遵循的接口规范。

我们上篇文章里在打造个人AI助手的时候，把dify主要当做了管理知识库，使用的内容RAG引擎，后续我们希望有业务用户系统—>来对接前端AI助手–>AI助手前端来访问dify RAG API, 这样各尽其责，又方便替换某个环节，不是一个大杂烩系统。

第一步：解决协议规范

如前面所讲，一切看起来很完美，但是我们在上一次部署完dify的知识库后发现dify api 是自己的规范，他不是按照 openAI的接口格式返回的。

有点想不到吧，仔细分析会发现他是按照dify自己解析后做的，也有直接的大模型对话窗口。

我们目前不想在dify的内部来改对话框UI来自己，这样成本太高，代码改动也大，关键也不符合架构设计，要在dify平台内，我一个定制化的AI助手窗口改UI ？

要解决这个问题就需要让Dify能返回标准的API，让 Dify 兼容 OpenAI 协议

因为我们自己本地部署的dify，可以直接在 Dify 的“插件”市场搜索并安装 OpenAI Compatible Dify App进行安装。

第二步：让 Dify API 兼容 OpenAI 协议

安装插件后，我们要对起设置，目的是要获得这个拆解代理之后的地址。

其中断点名称是可以自定义的，apikey 要注意下，这个是在插件配置里自己定义的，后边要给nextChat访问的时候使用。

配置完成后我们会获得代理的地址类似：http://localhost/e/g6k4yxvwp1u5ckru/chat/completions 这样的地址，通过访问这个地址就可以返回符合openAI接口的数据格式，这样就可以直接在nextchat里显示对话数据了。

第三步：解决跨域 (CORS) 难题

在我们获得这个地址后，如果直接在nextchat的配置里进行填写，这个是不行的，因为这个配置的方式给留给兼容openAI接口的模型使用的。我们这个直接用会有跨域问题和地址找不到。

为什么为这样呢？

先说跨域资源共享问题 (CORS Policy)：

当你在 NextChat 网页的“设置”中填写了自定义 OpenAI URL 时，NextChat 前端会尝试直接向你的 Dify 接口发起请求。由于 NextChat 运行在 localhost:3000，而 Dify 接口在 localhost:80，浏览器发现域名/端口不一致，且 Dify 接口未返回允许跨域的 Access-Control-Allow-Origin 报头，因此封禁了请求。

那我们怎么解决？

如果你参考网上的一些做法，会让你做各种nginx代理方式来解决，其实你会发现很多都是没有经过验证，仅仅通过AI给出的一些不靠谱的方案。而我们希望写出的东西最好是验证过的，这样才技术负责。回到正文，我们说下怎么解决，将 NextChat 网页设置中的“端点 URL”和“API Key”全部清空。

走后端代理：通过配置根目录的 .env 文件（设置 BASE_URL 和 OPENAI_API_KEY），让请求由 NextChat 的 Node.js 后端进行转发。由于服务器与服务器之间的通信不受浏览器 CORS 限制，所以就能轻松解决。

你可能会问这个就能解决？

在进一步来讲，因为app/client/platforms/openai.ts里开头有"use client";当这部分代码运行 fetch() 时，执行者是浏览器（如 Chrome 或 Safari），浏览器是一个受限的“沙箱”环境，它必须严格遵守 CORS 安全准则。

而我们通过在.env 设置浏览器代码也读不到，而且前面当nextchat设置里配置为空的时候会从api/common.ts里读取地址。这样就把这个请求进行了转发在node.js的后端代码里，而不是沙盒的浏览器环境里。

# 模拟用户访问权限）
CODE=code1
# 2. 配置 Dify api 插件代理接口 & 自定义的apikey
BASE_URL=http://localhost/e/g6k4yxvwp1u5ckru
OPENAI_API_KEY=123456qwe
# 3. 启用你的自定义模型
# 使用 + 来添加模型，确保它在模型列表中显示
CUSTOM_MODELS=+dify2OpenAI

第四步：过滤掉接口里多余的V1地址

你可以发现dify提供的地址是http://localhost/e/g6k4yxvwp1u5ckru/chat/completions 我们要做为BASE_URL是要按照openAI的接口协议格式来的。

API 路由前缀（/api/openai/）+ OpenAI 标准后缀（v1/chat/completions）的格式来拼装的，所以我们进行了拆分http://localhost/e/g6k4yxvwp1u5ckru 但是这里面有个V1是多余的。

在实际运行的时候也会发现，如果不处理这个就会报找不到地址，原因就是多了这么一个V1路径。为什么不直接去掉，因为这样修改可以兼容其他第三方大模型使用时不受任何影响。

解决方法：

在common.ts代码里在进行 const fetchUrl = cloudflareAIGatewayUrl(${baseUrl}/${finalPath});的时候对齐进行判断拦截替换掉V1（具体代码也可参考我公众号里关于这篇的代码修改细节，不再阐述）

通过识别 BASE_URL 中的特征字符串（如 /e/），在请求发出前动态地将 v1/ 从路径中剔除。

使用验证：

通过“Dify + NextChat”的组合，我们成功实现了数据管理与用户界面的完美解耦。

当然，你可以把 Dify 部署在家里的大显存机器上，而把 NextChat 这个轻量前端挂在公网上，随时随地调取你的私人文档。

最关键是我们打通了这种分工明确的方式，可以自己去定制，也可以去替换这些组件。在AI下我们要多探索这种实现的方式，选择最优解决方案，打造个人“数字分身”的正确姿势！

本文由 良技漫谈 原创。如果你在对接过程中遇到 CORS 报错或接口无法调通，欢迎在评论区或公众号后台留言，我会为你提供技术支持。