企业官网建设流程全解析

前段时间我在帮团队做内部知识库问答系统，从最开始只是想把散落在各处的文档丢进系统里、让同事能直接问出答案，到后来慢慢演化成了一套带工作流编排、多成员权限、外部接口对接的 Agent 平台。这中间我一直在用 FastGPT 这条技术路线，从部署、调模型、做知识库，再到工作流编排和二次开发，基本把从“轻量知识库”到“Agent 平台”的这条路完整踩了一遍。这篇笔记不是官方文档的复述，而是我在真实选型、部署、排错和扩展过程中沉淀下来的实操经验，希望对正在做同类技术选型的人有用。

如果你的处境和我类似——业务方提了“智能问答”需求，但你心里清楚这本质上是个检索问题，又不想从零手写一套 RAG 再去处理前端、权限和运维，那么 FastGPT 这套开源方案值得认真看一下。下文我会按自己的实践顺序来讲：先聊为什么选它，再讲架构、部署、模型接入，然后是知识库和 Agent 工作流的落地细节，最后给出一份问题排查速查。

1. 选型背后的真实诉求

1.1 大多数“知识库问答”需求，本质是检索问题

我最初接到需求时，业务方给的描述非常模糊：“做一个像 ChatGPT 一样的问答系统，把我们公司文档都放进去，员工随便问就能得到答案。”但仔细拆解之后会发现，这里面真正难的从来不是“生成回答”，而是“在几百份文档里找到正确的那几段”。如果不解决检索，模型只能靠记忆和猜测输出，结果就是看似流畅、实则胡编。

这个认知直接影响了选型方向。我一开始考虑过基于 LangChain 自己组合链路：文档加载、文本切分、向量化、检索、拼接上下文、调大模型。这条路代码量不大，但问题出在周边配套——前端聊天界面要做、文档管理界面要做、权限体系要做、日志审计要做，这些东西加起来的工作量远超核心链路本身。所以我开始转向现成的开源平台，FastGPT 就是在这个阶段进入视野的。

选型时我列了几个硬性指标：能本地私有化部署，数据不出内网；有可视化知识库管理界面，不用自己写管理后台；支持对接多种大模型 API，不能绑定某一家；最好自带简单的工作流能力，为后续扩展留余地。对比下来，FastGPT 算是唯一一个把这几点都覆盖得比较全的开源方案。

1.2 圈定“轻量知识库”边界，避免一上来就失控

做技术选型最容易犯的错，是想一步到位。我当时也差点直接上全套 Agent 编排，后来冷静下来，把第一阶段目标压缩成了三条：上传文档能自动切分和向量化；用户提问能检索到相关内容并生成带引用的回答；后台能看到问答记录并管理应用。用这三条去卡方案，很多花哨功能自然被过滤掉了。

那时我方团队只有两个人，一个前端一个后端，都没有专门做 NLP 或大模型应用的经验。在这个前提下，自研的维护成本是非常高的：向量库选型、切分策略调优、召回效果评测、多模型兼容，每一块都是持续投入的黑洞。FastGPT 把知识库管理、向量检索、模型接入、对话编排做成了界面化操作，等于把最脏最累的部分封装好了，我们只需要关注数据和效果调优。

这个决策后来被证明是对的。上线第一周，团队就有人开始用自然语言查制度文档，而我们在后台唯一要做的，就是根据问题命中率去调整几个切分参数和检索阈值。

1.3 和自研、商用 SaaS 的直观对比

如果用一个表格来看当时几种路径的差异，会更直观一些：

商用 SaaS 的问题是数据链路不透明，尤其企业内部文档往往涉密，业务方一听“上云”直接摇头。自研的问题是时间表不可控，按当时的人力，光是把管理后台和权限做好就要两个月。FastGPT 属于中间路线：代码开源、社区活跃、部署后离线可用，同时在知识库和模型接入上保留了足够的配置自由度。对我们这种“想要掌控力但不想全造轮子”的团队来说，是非常合适的切入点。

不过这里也要提醒一句：开源平台不是零成本，它只是把“从零开发”降级为“配置和调优”。你依然需要懂 Docker、懂一点向量检索原理、懂 Prompt 设计，否则遇到问题还是无从下手。选型前一定要评估团队有没有这个基础，而不是把开源当成免维护的挡箭牌。

2. FastGPT 的整体架构和组织逻辑

2.1 前端控制台、后端服务、沙盒执行三者的协作

FastGPT 部署起来之后，整个系统大致可以分成三层。第一层是前端控制台，负责知识库管理、应用编排、对话测试、成员权限设置；第二层是后端服务，负责对话调度、模型调用、工作流节点执行、数据持久化；第三层是沙盒环境，专门用来运行代码节点和 HTTP 请求节点，避免普通用户直接接触底层执行环境。

第一次接触这个设计时我有个疑问：为什么代码执行非要放到独立沙盒里？后来才想明白，Agent 工作流里的代码节点往往要拼接变量、发请求、处理响应，这些操作如果直接在主进程里跑，一个死循环就能拖垮整个服务。独立的执行沙盒相当于加了熔断和资源隔离，是平台类产品必须要做的安全设计。

三者协作的流程大致是这样的：用户在聊天窗口提问，前端把请求发给后端；后端解析当前应用绑定的是普通知识库对话还是工作流；如果走工作流，就逐个节点执行，其中涉及代码或 HTTP 调用的节点会交给沙盒；最终把结果汇总成一次回答，再回传前端渲染。这里的关键点是，整个流程是解释执行的，意味着我们可以在不重启服务的情况下随时调整应用配置。

2.2 理解三个核心概念：知识库、应用、工作流

刚开始用 FastGPT 时，我花了一点时间才把它的三个核心概念理清楚，因为这三个词和常见理解稍有出入。

知识库（Knowledge Base）是一组文档的集合，文档导入后经过切分和向量化，变成可检索的索引块。每个知识库可以单独配置所属的分类、向量模型和检索策略。应用（Application）是一个完整的对话服务单元，它决定了大模型用哪个、上下文怎么组织、绑定哪个知识库、走不走工作流。你每建一个应用，就等于多了一个独立 bot 入口。工作流（Workflow）则是应用内部的执行逻辑，它由多个节点组成，节点之间按连线传递数据。

这三者的关系可以用一句话概括：一个应用绑定一个或多个知识库，而应用的具体行为由工作流决定。对应实际场景就是——你可以建十几个知识库分别装不同部门的文档，再建一个统一入口的“公司助手”应用，在里面用条件节点判断用户问的是制度、流程还是 IT 问题，再路由到对应的知识库去检索。这种组织方式天然适合有多个文档场景的中大型团队。

2.3 数据存储和向量检索的底层配套

除了核心服务，FastGPT 的部署还依赖两类数据库。一类负责业务数据，比如应用配置、知识库元信息、对话记录；另一类负责向量索引，也就是文档切块后的 Embedding 向量。实际部署里，业务数据常见用 MongoDB，向量数据常见用 PostgreSQL 加向量插件，比如 Pgvector。向量插件的作用是让数据库能直接执行“相似度检索”，按距离返回最接近的文档块。

这个设计在工程量上是有讲究的。很多自研方案喜欢把向量存到专门的向量数据库里，好处是检索性能强，但坏处是多维护一套系统，还要处理向量库和业务库之间的数据同步。FastGPT 把向量检索收敛到关系型数据库的插件扩展里，部署复杂度低了很多，对知识库规模在中上水平的团队完全够用。如果你的知识库是千万级向量、高并发深度检索，再考虑独立向量库也不迟。

我自己在理解这套架构时，习惯把它类比成一个小型信息管理系统：前端是收银台，后端是后厨，数据库是冷藏库，沙盒是独立的加工间。对使用者只暴露点单入口，对管理员暴露全流程配置，而这样划分边界之后，每一块的诊断和替换都可以独立进行。

3. 部署选型与模型接入的实操过程

3.1 Docker Compose 快速拉起一套环境

FastGPT 提供了完整的 Docker Compose 编排文件，拉下来之后，核心服务一共是几个容器：主服务、沙盒执行端、MongoDB、PostgreSQL，可能还有一个模型网关容器。初次体验我建议按默认编排直接把整套起起来，先把功能跑通，再根据实际情况裁剪。官方推荐的配置是至少 4 GB 内存，但我实测下来，如果同时跑向量模型和对话模型，8 GB 内存体验才够顺，否则首轮对话会明显偏慢。

部署前要准备几个关键配置项：MongoDB 连接串、PostgreSQL 连接串、主服务密钥、沙盒地址。这些通常写在 .env 文件里。初次部署最容易踩的坑是容器启动顺序，数据库还没就绪时主服务就启动了，会导致初始化失败。我自己的习惯是在 docker-compose 里加上健康检查，让主服务依赖数据库健康状态之后再启动。用默认编排其实也带了这种依赖，但如果你自己改过编排文件，一定要保留这部分逻辑。

下面是一个简化后的编排示例，展示出最核心的几块：

version: "3" services: mongo: image: mongo:6.0 volumes: - mongo_data:/data/db pg: image: pgvector/pgvector:pg16 environment: POSTGRES_PASSWORD: ${PG_PASSWORD} volumes: - pg_data:/var/lib/postgresql/data sandbox: image: fastgpt-sandbox:latest app: image: fastgpt:latest depends_on: mongo: condition: service_healthy pg: condition: service_healthy ports: - "3000:3000" env_file: .env volumes: mongo_data: pg_data:

这套起完之后，浏览器打开主服务的 3000 端口，先初始化管理员账号，再接入模型，就可以开始建知识库了。整个过程如果顺，半小时内能完成，但如果你是第一次接触 Docker 和数据库，建议留出半天时间，因为中间总会有一些小配置要反复确认。

3.2 大模型 API 接入的关键配置项

FastGPT 本身不生产模型，它通过“模型供应商”概念来接入外部大模型。这里我强烈建议先部署一个统一模型网关，把所有上游模型 API 的 Key 和地址都收敛到网关里，FastGPT 只管对接网关即可。这个做法的好处是，后续更换模型供应商时，只需要改网关里的配置，不需要动 FastGPT 的应用设置。

在 FastGPT 管理后台配置模型时，需要关注三个字段：模型名称、模型别名、接口地址。模型名称是对上游 API 的实际调用名，模型别名是在控制台里展示的友好名，接口地址指向网关的统一入口。实际上还有一个重要配置是请求方式，大部分情况用兼容 OpenAI 格式的接口即可。国内能正常访问的云上模型服务基本都支持这种格式，填进去就能用。

我刚接入时犯过一个低级错误：只配置了对话模型，没配置向量模型，结果建第一个知识库时发现文档一直导入失败。后来才意识到，知识库的向量化必须由专门的 Embedding 模型完成，和负责对话的大模型是两个独立的配置项。一个应用里可以同时使用两个不同来源的模型，这在配置上没有任何冲突，但前提是两者都要提前填好。

3.3 Embedding 模型选型和向量库调参

知识库问答的效果上限，很大程度由 Embedding 模型决定。如果对话模型负责“说”，那 Embedding 模型就负责“听”——它决定了两段语义相近的文本能否被正确识别为相似。中文场景下，我推荐优先考虑开源中文向量模型，比如 BGE 系列这一类，它们对中文语义的理解和通用英文模型有明显差异。选模型时还要关注一个核心参数：输出向量维度。常见的有 512、768、1024 等，维度越高容量越大，但内存消耗也会上涨。

向量库层面，FastGPT 默认使用 PostgreSQL 的向量插件来做检索，表结构里每一行是一条文档分块，字段包含原文内容、向量、来源文件、分类标签。向量检索性能取决于索引类型和参数，默认 HNSW 索引对中小规模知识库表现很好，支持毫秒级召回。初次使用不用调索引参数，只需要关注检索时命中的相似度阈值，也就是“低于多少分就不算命中”。

我曾经为了一批专有名词特别多的制度文档换了另一个向量模型，重建完索引后检索质量提升明显，但代价是历史语音记录关联的引用会失效，需要重新导入一遍文档。这里给一句实在的提醒：向量模型在项目早期就要选好，后续更换的迁移成本远高于一开始多做几次测试对比。

4. 知识库从导入到可靠回答的三步实操

4.1 文档切分：这步直接决定检索质量

FastGPT 的知识库支持 Markdown、TXT、PDF、DOCX 等常见格式。导入环节看起来很自动化，但其实最影响效果的参数是“切分策略”。系统把文档切分成向量检索的最小单元，这个单元太大，召回的内容包含大量无关上下文；太小，单个单元信息量不足，模型无法完整理解。

我的经验是，普通制度文档和产品手册，切成 200 到 500 字左右的块比较合适，同时保留一个 20 到 50 字的相邻重叠，防止语义被切断。表格类数据按行切分效果更好，否则模型很难把表头和单元格对应起来。FastGPT 提供了可视化预览，每次调整切分参数后，可以立刻看到切片结果，这个功能非常实用，一定要用起来。

我踩过的坑是 PDF 扫描件。导入后看不出异常，但向量化之后检索命中率极低，排查发现系统根本没有做 OCR，扫描图里的文字半点没有提取。后来我的处理方式是在导入前先把扫描件统一跑一遍 OCR 转成可复制文本，再导入 FastGPT。这步不是平台的问题，而是格式本身的限制，但很多人会忽略。

4.2 检索策略：混合召回和 TopK 参数

当用户提问后，系统会先做两件事：把问题转换成向量，去知识库里做相似度检索；同时用关键词做文本检索，补上向量召回可能在专有名词上失手的情况。FastGPT 支持把这两种结果合并，这种混合召回策略在中文场景下非常有效，因为中文同义词多，单纯向量匹配容易漏掉精确术语。

TopK 是每次检索返回的候选块数量。设得太小容易漏内容，设得太大又浪费模型上下文。我的调参习惯是从 TopK = 5 起步，观察回答效果，如果模型说“找不到相关资料”，先调大 TopK 到 8 试试；如果回答里混入了不相关内容，再下调或者提高相似度阈值。这里的底层逻辑其实很简单，就是做召回率和精确率之间的平衡。

命中的内容块会作为上下文传给大模型，FastGPT 会保留每个块的来源文件信息。这条链路是我个人最喜欢 FastGPT 的地方——引用是可解释的，用户能看到回答来自哪份文档的哪一段，而不是像纯生成式对话那样“凭空回答”。这种可解释性在企业内部推广时几乎是一个刚需。

4.3 减少幻觉的三个实战手段

知识库问答最被诟病的就是幻觉，模型一本正经地编答案。我实践下来有三个手段组合使用效果最好。

第一个是限定数据范围。在对话系统提示词里明确告诉模型：只能基于对话历史和引用内容回答，当引用内容不足以支撑答案时，直接回复“资料库中没有找到相关信息”，不要自行推断。第二个是加强引用校验。FastGPT 可以把引用块作为固定格式输出，回答完附加“参考资料”列表，如果某个答案没有任何引用来源，基本可以判断是模型自由发挥。第三个是控制上下文长度，不要把所有检索结果一股脑塞给模型，凭经验只保留最相关的几块，减少干扰信息。

团队刚开始上线时，总有同事质疑答案不准确，后来我查后台日志发现大部分“幻觉”其实是两个原因：文档里压根没写那条信息，或者同名字段在企业内有两套说法，向量检索命中了另一套。前者靠提示词兜底，后者靠完善知识库别名和同义词解决。这里分享的经验是：幻觉不能完全消灭，但能在架构上做到“有据可查”，对内部用户来说，有引用比没引用可信度高得多。

5. 从轻量知识库升级到 Agent 平台的关键一步

5.1 为什么单靠知识库问答走不到“平台”

知识库问答做到一定阶段，业务方一定会提新需求：不只是“问文档”，还要能“办事”。比如员工问“申请流程是什么”，单纯检索能回答出流程说明，但业务方真正想要的是：问完直接识别出这是请假申请，然后自动生成一个带标题和描述的工单，提交到 OA 系统。这就不是知识库能解决的了，而是需要应用具备“理解意图—查询资料—调用接口—执行动作”的完整闭环。

这个阶段，系统的角色从“电子文档管理员”变成了“业务执行助理”。我把它理解成 Agent 化：让大模型成为流程的决策中枢，决定每一步应该走哪个分支、调用哪个工具、生成什么输出。FastGPT 的工作流模块恰好承担了这件事。它把流程里最常用的能力封装成节点，比如 AI 对话、知识库搜索、HTTP 请求、条件判断、代码执行，然后通过可视化连线自由组合。

在实际评估时，我发现自研一套工作流引擎的复杂度远高于知识库问答。要处理节点状态传递、并行执行、失败重试、日志追踪，一套完整轮子做下来又是几个月。使用现成工作流意味着我可以把精力集中在上层业务逻辑，也就是“员工问出这句话，系统该依次做什么”，这才是业务真正关心的事。

5.2 工作流编排的核心节点用法

FastGPT 工作流的入口是可视化画布，把一个应用从“直接对话”切换成“工作流”模式，就会出现一行节点面板。每个节点有输入和输出，节点之间用连线传递数据。我常用的节点组合是：开始节点接收用户提问 → AI 对话节点负责理解意图 → 知识库搜索节点去指定库检索 → HTTP 请求节点调用内部系统接口 → 条件分支节点决定走哪个回复模板 → 最终回答节点输出。

这里值得专门说的是“变量传递”。工作流节点之间不是黑盒，每个节点输出的字段可以在后续节点里引用。比如 AI 节点识别出的分类结果会赋值给一个变量，条件分支节点拿这个变量和预设值做比较，再走向不同分支。这个机制类似普通后端开发里的状态机加管线，只不过抽象成了可视化操作，维护成本比硬编码逻辑低很多。

我有一次把 HTTP 请求节点直接用来触发一个写操作接口，测试时没受影响，但后来想想很后怕。Agent 自动触发的写操作一旦逻辑有漏洞，可能造成脏数据。所以我的建议是：写操作不要放在全自动链路里，而是用“待确认节点”让人类确认后再执行。既保住了效率，又留了安全兜底。

5.3 案例：工单自动分类加知识库辅助回复

为了讲清楚“Agent 平台”到底长什么样，这里分享一个我实际搭过的场景。某公司的售后客服入口收到用户消息：“我上个月买的设备坏了，想申请售后。”以前人工客服要查产品信息、查售后政策、填工单。我设计的工作流是这样的：

开始节点接收消息 → 知识库搜索节点同时去两个库检索，一个是售后退换标准文档，一个是产品常见故障文档 → AI 对话节点把检索结果和原始问题一起送给模型，让模型输出分类结果，包括售后类型、涉及产品型号、紧急程度 → 条件分支节点按售后类型走不同处理路径 → HTTP 请求节点调用工单系统接口，把结构化字段写进新建工单 → 最终回答节点生成一段面向用户的回复，引用售后政策原文，提示已登记工单号。

这套流程上线后，工单分类准确率大概稳定在 85% 到 90%，剩余的人工二次复核兜底。效果是一线客服不再需要反复翻手册，也不用手动填分类字段，整个处理时长明显缩短。这个案例里，知识库还是核心——Http 请求调接口、条件分支判断，这些都是建立在对场景理解之上的锦上添花，没有好的文档支撑，回答链路本身是没有价值的。

6. 常见问题与排查速查表

6.1 检索不到内容：问题大多出在切分和阈值上

最容易遇到的现象是，文档明明在知识库里，但问它却回答“资料库中没有相关信息”。常见原因有三种：文档切分后的块太碎，导致语义不完整；相似度阈值设得过高，把本来该命中的内容过滤掉了；向量模型对领域词汇理解不到位，把同义词当成了不同概念。

排查顺序我一般是这样：先在知识库后台直接搜索一个和文档内容高度相关的关键词，看索引里能不能命中；然后调低相似度阈值，或者切分调成大块后重建索引。如果还不行，换领域更匹配的向量模型再试。很多初级使用者上来就怀疑大模型，实际上大模型很无辜，绝大部分检索失败要回溯到数据预处理环节。

6.2 回答乱编和重复：先检查提示词与上下文

第二大常见问题是模型输出毫无逻辑，甚至一句话重复多次。多数情况是大模型拿到的上下文太杂，或者提示词里没有明确输出格式约束。FastGPT 里每个 AI 对话节点都有独立的提示词，很多工作流里套了多个 AI 节点，如果上游节点把一堆无关的历史对话也传给下游，输出质量就会明显下降。

我可以给一个快速自查路径：先不做任何知识库检索，只让模型直接回答，看输出是否正常；然后加上知识库检索，看是否变差；再逐步增加上下文，每一步的变化都能定位到具体诱因。这种“剥洋葱式”排查在调试 Agent 平台时非常高效，也推荐给遇到类似问题的人。

6.3 引用来源异常和响应变慢排查方法

引用来源异常也很常见，比如回答正确但引用了完全无关的文档。这通常是检索结果里存在高分的语义相似段落，但实际上下文无关，这时可以压低 TopK，或者提升相似度阈值，尽量只保留更可靠的匹配。至于响应变慢，核心要分清楚瓶颈在模型调用还是向量检索。最简单的方法是在网络层打开耗时观察，如果模型调用占大头，考虑换成更快的模型或者给用户感知更强的流式输出体验；如果向量检索占大头，检查知识库索引是否失效、是否需要重新构建索引。

我自己写过一个最简单的排查表，贴在这里供参考：

这些小问题不会同时出现，但会随着使用规模扩大轮番找上门。维护这套系统半年后我的体会是：调试知识库问答和调试普通后端服务是两套方法论。普通后端靠堆日志能定位，这里还要理解语义处理和召回机制，需要建立新的直觉。

7. 多人协作、权限管理和平台化改造

7.1 多成员权限体系的实用配置

当知识库问答从一个内部工具变成团队级平台，权限管理就是绕不开的课题。不同的部门往往只希望自己成员看到特定知识库和特定应用，FastGPT 内置了成员、团队和应用三个层级的权限模型。我把团队内的人分成管理员、编辑者、使用者三类：管理员能配置一切，编辑者能维护知识库内容，使用者只能访问被授权的应用。

这个设计其实很像 Word 文档的协作模式：不是所有人都需要编辑权限，大多数人只要能查看和提问就行。权限收敛后，误操作概率大幅度下降，尤其是知识库内容被误删这种事故，权限越细越不容易发生。在配置引用权限时，还有一点要注意：应用绑定的知识库如果没有给使用者授权，对方虽然在聊天窗口能对话，但可能无法查看引用来源的文档详情，这类细节在权限配置时要一并检查。

7.2 成本控制与用量统计

平台化之后，成本控制会被提上日程。大模型按 Token 计费，知识库检索按调用次数计费，如果用户把系统当闲聊工具，成本会涨得很快。我的做法是：给不同应用配置不同的模型档位，核心业务问题用高质量模型，简单查询和入门体验用便宜模型；同时限制单应用并发数，避免某些高频场景把整体预算吃光。

FastGPT 的用量统计能看到每次对话的模型消耗和 Token 数，我每周会扫一眼这张报表，发现异常突增就去查是不是有人把应用接口写成了外部调用的免费午餐。排查这类问题需要明确的应用层审计，比如在某些关键接口加上调用方身份信息。这套成本治理逻辑做下来之后，月度成本基本能够稳定在预算线内。

7.3 开放接口与前端定制

真正的平台还要能对外开放能力和定制界面。FastGPT 的所有对话能力都通过 OpenAPI 对外暴露，可以方便地嵌入到企业微信、自己的 Portal 站点或移动端应用里。我的实际做法是写一层薄薄的中转服务，负责把业务系统的用户信息和 FastGPT 的会话 ID 关联，再转发消息，这样业务侧只看到统一接口，底层是 FastGPT 还是别的引擎对上层无感知。

前端定制则更依赖二次开发能力。FastGPT 控制台本身界面已经覆盖大部分管理需求，但如果要嵌入企业统一风格，就需要定制前端。我因为团队前端资源有限，选择保留原始控制台，只对聊天窗口入口做定制嵌入。事实证明这不是偷懒，而是把精力花在业务价值更高的地方——毕竟对使用者来说，一个稳定的问答响应比一个华丽的管理后台重要得多。

8. 最后分享几点带团队过程中的经验

走到这一步，再回头看，我觉得选型 FastGPT 最大的收益不是省掉了写代码的时间，而是帮我建立了一个可以渐进演进的 AI 应用底座。知识库问答和工作流其实是顺承关系——如果你有了一堆结构化的知识切片，把它们接入外部操作节点只是时间问题。如果一开始没有一个平台托底，从知识库到 Agent 的跃迁不会这么平滑。

我也想说一句掏心窝的话：任何“平台”都是被需求逼出来的，不要一开始就冲着 Agent 平台去。我们都是先认真做好了知识库问答，发现不够用了才开始加工作流；先满足了单团队的使用，发现需要权限隔离才开始做多人协作。这种从轻到重的演进路径，相比一开始铺一个大而全的平台，踩坑率会低很多。

工具在不断迭代，但数据准备、效果评测、权限治理这些基本功永远不会过时。每次产品升级之前，我先问自己一个问题：检索准不准、引用能不能追溯、用户信不信。这三件事做扎实了，用什么框架都只是换一种实现方式而已。希望这篇实践笔记能给正在做类似选型的人一些参考。