内存里放几份文档，可以很快演示检索。进程重启后数据没了，多个实例又各自保存一份，存储问题就出现了。

走到上线这一步，先保证已有数据能持续使用，再检查页面到工具的整条请求。网页能够打开，只覆盖了其中一部分。

先把存储需求写具体

MemoryVectorStore 适合小样本学习和建立对照。它也可以做过滤，不能因为数据放在内存里就断言它没有过滤能力。需要进一步比较的是持久化、共享、查询执行和更新管理。

如果项目已有 PostgreSQL，可以把 pgvector 放进候选。它支持精确搜索，也提供 HNSW 和 IVFFlat 等近似索引，具体用法见 pgvector 项目文档。是否适合当前任务，还要结合过滤、并发和运维条件验证。

独立向量服务、混合检索和托管方案也各有候选。原教程介绍了 Qdrant、Weaviate、Milvus、Chroma 和 Pinecone 等方向。选择前先检查部署形态、实际版本与所需能力，用自己的文档和查询比较。

固定“多少万条以后必须换库”的门槛，无法覆盖向量维度、并发、更新频率和延迟要求。原型的数据量相同，查询条件不同，表现也可能差很多。

近似检索省下计算，也引入取舍

全量比较会对候选向量逐个计算。ANN 通过索引寻找更有希望的候选，减少一部分计算，也可能漏掉精确搜索能找到的近邻。

HNSW 使用分层图来导航，搜索先在较稀疏层接近目标区域，再在更密集层继续查。索引构建、内存占用与搜索宽度都需要考虑，不能把它理解成对任何数据都有固定复杂度保证。

近邻召回与问答证据召回也要分开。向量近邻找得很好，文档本身却没读完整，问题仍然没有依据。性能测试要和前面准备的问题集一起做。

迁移以后，查询只连接已有索引

把索引任务和查询服务分开。首次编码并写入以后，普通启动应连接已有集合。每次启动都调用会重新编码和写入的方法，可能增加费用，也可能不断产生重复片段。

稳定文档 ID 与片段版本有助于更新。重复导入同一版本，应按设计保持可控；替换资料以后，旧片段需要清理。删除完成后，再查询一次确认它已经消失。

正文、元数据和向量要一起迁移。只有向量而取不回正文，模型就没有资料可用。过滤语法也要逐库验证，统一 VectorStore 接口无法抹平底层差异。

用两个用户的混合资料测试过滤。可信用户范围从服务端认证上下文获得，检索时在正确候选范围内执行。先全库取少量结果，再删掉无权限记录，既可能丢掉有效答案，也可能让不必要的数据进入应用。

页面接入要关心任务状态

原教程给出独立服务、嵌入已有后端，以及通过 Next.js 服务端接口调用 Agent 的几种方式。根据已有项目选择即可。模型密钥和工具凭证留在服务端，通过环境变量配置。

前端发送消息，服务端运行 Agent，再把流式事件交回来。流里可能同时包含文本与工具状态，客户端需要使用匹配的消息协议解析。把整个响应当普通文字拼接，可能无法正确显示工具结果。

页面要处理发送中、接收、结束、错误和取消。后端如果返回 limit_reached，前端应该说明任务尚未完成。连接正常结束，无法单独证明业务目标已经达到。

生产环境还要验证文件路径、存储卷和运行时。开发机上存在的相对目录，部署包里未必包含；容器能重新启动，也不能证明删除重建后数据仍在。按实际重建方式测试一次，才能知道恢复是否可靠。

留一组以后还能重复运行的检查

知识库助手至少可以保留下面这些验收题。

为每道题分别记录检索结果、最终回答与引用，再记录延迟和输入输出量。调了分块、换了数据库或升级框架以后，重新跑同一组题，差异才能比较。

这套系列的第一个可交付版本可以很克制。读取指定项目文档，回答真实问题，保留来源，支持同会话追问，并在失败时如实说明。把这些行为部署后验证一遍，再根据出现的问题增加能力。

延伸阅读

本篇依据冴羽《AI Agent 开发实战》学习整理稿中的向量数据库、部署与实践验收章节重写。原教程见 向量数据库选型、Agent 部署 和 Next.js 与 Mastra 集成。

上一篇 · 系列目录