企业官网建设流程全解析

本文基于 Dify 官方博客Grounding Dify Agents in Real Data整理改写，原文链接见文末。链接和插件名都以官方为准，我只在"使用者"视角上做解读。

做 AI 应用这事儿，大家基本都走过同一条路：最开始写个聊天机器人，问一句答一句；后来不满足了，想让它去翻真实业务数据——查订单、搜文档、推荐人选。

这时候麻烦就来了。你要自己接数据库、接 embedding 模型、接向量检索、接重排序，再把这一串用代码串起来。对写代码的人来说是体力活，对不想写代码的人（比如我这种爱折腾但不想天天焊胶水代码的）来说，基本就只能等平台把这些集成做出来。

我前两天在 Dify 的市场里翻，发现 MongoDB 和 Dify 合作上架了两个官方插件：MongoDB Atlas和Voyage AI。这俩东西加起来，等于在 Dify 的画布上就能拼出一个"能查真实数据"的 RAG 工作流，不用自己写后端。

名词小抄：RAG（Retrieval-Augmented Generation，检索增强生成）——别被名字吓到，说白了就是：让 AI 回答问题前，先去资料库里把相关的几段内容翻出来，再让它基于这些内容作答。这样比直接问大模型靠谱，因为它答的是"查到的真东西"，而不是"脑子里大概率对的东西"。

下面我把这两个插件能干什么、怎么搭、适合谁用，挨个说清楚。

一、为什么是 Dify + MongoDB 这个组合

Dify 本身是个"编排层"[一句话解释：把大模型、工具、提示词像搭积木一样组织起来的地方，你拖拖拽拽就能拼出 AI 应用]。你在它画布上排好工作流、Agent、提示词，剩下的就是"让这些 AI 真正够得着业务数据"。

而一个能用的 AI 应用，光有大模型不够，还得有两样东西：数据从哪来，以及查得准不准。这正好是 MongoDB Atlas 和 Voyage AI 补上的位置：

• MongoDB Atlas管数据和检索：文档存着、能做聚合查询[一句话解释：MongoDB 里一种多步骤数据处理流水线，类似 SQL 里group by+join的组合]、能做全文搜索、也能做向量检索，一个平台全包了。
• Voyage AI管检索质量：出 embedding（语义向量）用来搜，再出 reranking（重排序）用来把结果排得更准。

打个比方：如果搭 RAG 像做菜，以前你得自己买菜、洗菜、切菜、调味，全流程手搓；现在 Dify 市场给你备好了"净菜包"——Atlas 是冰箱（存料+取料），Voyage AI 是那把能精准切配料的刀。你只要决定先放什么后放什么。

二、两个插件分别能干啥

MongoDB Atlas 插件

装好之后，它在 Dify 里是一组现成可调用的工具节点，直接挂在工作流或 Agent 上就能用。能做的事：

• 查文档（find）
• 跑聚合管道（aggregation）
• 做 Atlas 向量检索（Vector Search）
• 做全文检索（full-text search）
• 插入 / 更新 / 删除文档

注意，它不只是用来"读"。比如你可以做一个项目管理 Agent：让它去翻团队成员表、技能表、历史项目表、在岗状态，然后推荐"这个新项目该派谁上"。权限给得够细的话，它甚至能把一份草稿组队方案写回 MongoDB。

Voyage AI 插件

这个插件往工作流里加了两个关键节点：embedding（向量化）和reranking（重排序）。

• Embedding：把文字变成一串数字（向量）。意思相近的文字，这串数字也相近，于是就能按"意思"搜，而不是按"关键词"搜。[一句话解释：embedding 就是把一段话压缩成一长串带语义的数字坐标，语义越近，坐标越近]
• Reranking：第一轮搜出一堆可能相关的，再让模型拿"用户原问题"和每条候选比一比，按相关度重新排个序，把最对口的那几条顶到最前面。

为什么要"先向量搜、再重排"两步？因为向量检索擅长快速捞出一大把"可能相关"的，重排序擅长从这把里面挑出"最该用"的几条。这就像你先在大库房里按类别抓出一堆零件，再让老师傅挑出真正要用的那几个。在 Dify 里这两步都是画布上能看见、能调的节点，不用切出去改代码。

三、官方给的 MongoDB RAG 模板：5 步一条龙

Dify 市场里顺手给了个 MongoDB RAG 模板，把上面两个插件串成了一条标准流水线。整体长这样：

这套模式其实就是大多数生产级 RAG 系统的底子：与其把用户问题直接甩给大模型赌它"刚好知道"，不如先去 MongoDB 里把相关信息捞出来，再让下游的回答节点基于这些上下文生成更靠谱的回复。

四、工作流每一步怎么拆（新手也能调）

模板刻意把每一步拆成独立节点，好处是你看得懂、调得动、换得掉。我按实际跑一遍讲讲：

1. 用户输入

工作流从一个文本输入开始。可以是提问、搜索词、工单、项目描述，任何形式的自然语言都行。
举例：

What would be a good team to build scalable Rust applications? （谁能组成一个适合做"可扩展 Rust 应用"的团队？）

2. 向量化问题

输入丢给 Voyage AI 的 embedding 工具，变成向量。
重点：搜东西的时候，embedding 要用"query 优化"的模式。意思是告诉模型"这是一句搜索意图"，而不是"一段要被存起来的文档"。模型懂了这层，检索质量会明显好一些。[一句话解释：同类模型通常区分query（搜）和document（存）两种向量模式，搜的时候用 query 模式，索引的时候用 document 模式，两边对齐了才好搜]

3. 去 MongoDB Atlas 里搜

生成的查询向量丢给 Atlas Vector Search，它拿去和集合里存好的文档向量比对，返回最近的语义匹配。
这里有两个关键旋钮：

{"numCandidates":100,// 先粗筛多少候选（越大召回越全，越慢）"limit":10// 最终往前传几条（下游真正用到的）}

numCandidates调大，捞得全但慢；调小，快但可能漏。按你自己的数据量和体感去拧就行。

4. 重排序

第一步搜出来的 top 结果，再丢给 Voyage AI 的 rerank 工具。它拿"用户原问题"和每条候选逐一对打，按相关度重排。
这一步在"第一轮搜出一堆都像那么回事"的时候特别值钱——它能帮你把"真正回答用户问题"的那几条顶上来，别让无关的占了上下文。

5. 格式化输出

最后模板节点把重排后的文档整理成结构化输出。这个输出可以直接返回，也可以当上下文喂给下游的大模型回答节点。
所以这套模板很灵活：单独当搜索管道用也行，塞进更大的聊天机器人 / 工作流 / Agent 里当检索层也行。

五、不用写代码的人，能拼出哪些东西

对非开发同学来说，最大的爽点是"可拼装"。不用从零写 RAG 后端，拖几个工具节点、连上线就行。能做出的东西包括但不限于：

• 知识库助手：基于 MongoDB 里的文档回答问题
• 客服 copilot：搜历史工单，推荐处理方案
• 项目管理 Agent：按技能和履历推荐团队（上面那个例子）
• 文档搜索应用：语义检索 + 全文检索混着用
• CRM / 客户助手：捞出相关客户信息
• 运营 Agent：读 MongoDB，产出结构化建议

同一套积木，既能拼简单工作流，也能拼更自主的 Agent。区别只在于：工作流是"你定好步骤它照跑"；Agent 是"你给它工具，它自己决定什么时候搜、什么时候聚合、什么时候写回"。

六、写代码的人能得到什么

开发者其实也省事。这两个插件把"接 Dify 和 MongoDB / Voyage AI"要手写的胶水代码（请求、解析响应、调 embedding、跑数据库操作）打包成了节点，输入输出都清清楚楚。

架构上也顺手做了清晰的职责分离：

这种拆法调试和扩展都舒服：调向量检索不用动重排序，换 embedding 模型不用改 MongoDB 逻辑，加个回答节点不用碰检索管线。各管各的。

七、一个具体例子：项目管理 Agent

举个能落地的场景。用户问：

What would be a good team to build scalable Rust applications?

Agent 可以用语义检索，去 MongoDB 里翻相关的候选人、历史项目、技能、经验，然后攒出一份推荐，还顺带解释"为什么这人合适"。

在 Dify 里，你可以把 MongoDB 的工具和 RAG 工作流同时挂给 Agent。它既能搜文档、看结构化记录、跑聚合，也能产出一份"扎根在数据库结果上"的推荐。

这个模式之所以实用，是因为业务数据很少只是静态文档——人、工单、客户、项目、任务、产品、事件，都是会变的运营记录。MongoDB 让这些数据保持灵活、可查；Dify 让 AI 工作流够得着它们。

八、上手时几个别踩的坑

从官方给的最佳实践，加上我自己理解，挑几条最实用的：

1. Embedding 模式要对：搜的时候用 query 优化，存的时候用 document 优化（模型支持的话）。两边对齐，检索才灵。
2. 向量检索的召回和延迟自己拧：numCandidates和limit直接影响质量和速度。先用默认，再按数据和体感调。
3. 生成答案前先重排：重排能压掉无关上下文，答案更准、也更让人信得过。
4. 写操作（增删改）权限要收死：MongoDB 的 insert / update / delete 工具很猛。给 Agent 用时，权限、指令、范围都要卡细。很多应用先从只读开始，等流程和边界想清楚了再加写能力。
5. 索引要和数据对上：向量检索的 Atlas 索引，要匹配你用的 embedding 字段和维度；全文检索就索引用户常搜的字段。索引对了，原型才像真产品。

九、为什么我觉得这事值得关注

说到底，这次合作值钱的地方不是"Dify 能调 MongoDB 了"——这本来就能调。值钱的是：一个 AI 应用的"检索 + 数据交互"整套模式，现在整块住在 Dify 一个地方了。

以前你要在"可视化拖拽的快"和"生产级数据基建的稳"之间二选一；现在在同一块画布上两样都给你，还能在每个应用里复用。对不想写代码的人是少卡壳、多试错；对写代码的人是接口更干净、重复活更少。

顺带提一嘴数据：Dify 这个项目开源，截至 2026 年 1 月 GitHub 上已经破了14.2 万 star，算是开源生成式 AI 里最出圈的项目之一。MongoDB 那边是多年老牌开发者数据平台，Atlas 把文档库、聚合、全文检索、多云向量检索都揉在一个架构里，不用你再分别运维好几套数据库。

怎么开始

去 Dify Marketplace 把MongoDB Atlas和Voyage AI两个插件搜出来装上，拖进工作流，几分钟就能跑起一个"能查真实数据"的 Agent。

想直接看成品，官方那个 MongoDB RAG 模板 一键就能导入，改改数据源就能用。

参考原文：Grounding Dify Agents in Real Data: MongoDB Atlas and Voyage AI Are Now Native to Dify RAG Workflows