作者：周弘懿（锦琛）

背景与挑战

在构建面向特定技术领域（如一个框架、一个平台或一个软件库）的问答机器人时，我们通常会面临以下核心挑战：

问题一：知识滞后性

技术文档，尤其是在活跃的开源项目中，更新非常频繁。新的 API、功能变更、Bug 修复说明、版本兼容性问题等信息层出不穷。依赖于通用大模型（其知识有截止日期）或手动更新的知识库，很快就会过时，导致提供的答案不准确甚至是有害的。

问题二：信息幻觉与事实不准确

当通用大模型（LLM）被问及它不确定的问题时，它可能会“编造”答案，即产生幻觉。在技术问答中，一个虚构的函数名、一个错误的配置参数，可能会浪费开发者数小时的调试时间。

问题三：领域术语与上下文理解不足

每个技术领域都有其独特的术语、缩写和上下文（例如，在数据库领域 "partition" 和在磁盘管理中的 "partition" 含义不同）。通用 LLM 可能无法准确理解这些细微差别。

问题四：知识库维护成本高昂

手动跟踪文档变更、处理、然后更新知识库是一项繁琐、易错且耗时的工作，难以规模化。

本文将聚焦于业界领先的Milvus，并借助低代码工作流编排平台n8n，向您展示如何将二者无缝结合，结合GitHub的API快速搭建一个企业级的垂直领域智能问答应用。同时会介绍一下如何构建一个生产可用的n8n，聚焦在可观测和安全上。

通过与Milvus的结合使用，重点解决了以下智能问答中常见的问题：

一、非结构化数据处理的碎片化与高延迟

传统 RAG 数据管道依赖手动脚本处理文档分块、向量化、存储等流程，各环节割裂且难以实时更新，导致 Milvus 中的向量数据与源数据存在严重延迟。
Milvus 的突破性价值：

通过高性能批量写入接口，支持 n8n 工作流中实时生成的向量数据高速入库（如每秒数万条），确保数据时效性；
提供动态 Schema 管理，允许 n8n 灵活处理多模态数据（如文本+图像混合分块），避免因数据结构变更导致的流程中断。

二、复杂系统的运维成本高

自建向量检索系统需独立维护数据分片、索引构建、负载均衡等模块，运维复杂度极高。
Milvus 的突破性价值：

以全托管服务提供自动扩缩容、滚动升级、全链路监控告警能力，使 n8n 工作流无需关注底层运维，专注业务逻辑编排；
通过混合查询（标量+向量）能力，允许 n8n 在数据预处理阶段嵌入业务标签（如文档分类），提升后续检索精准度。

阿里云Milvus基本原理介绍

基本原理与架构概述

Milvus 是专为向量相似性搜索设计的分布式数据库，其核心基于以下关键技术：

近似最近邻搜索（ANN）：通过HNSW、IVF、PQ等算法实现高效向量检索，平衡精度与速度。
向量索引与查询分离：支持动态构建多种索引类型（如FLAT、IVF_FLAT、IVF_PQ、HNSW），适配不同场景需求。
向量数据分片与分布式计算：数据水平切分（Sharding）并行处理，实现高吞吐与低延迟。
采用云原生和存算分离的微服务架构。该架构分为接入、协调、执行和存储四层。各组件可独立扩展，确保了系统的高性能、高可用性和弹性。它依赖成熟的第三方组件（如etcd、对象存储）进行数据和元数据管理，稳定可靠。

阿里云Milvus系统架构图

使用场景

阿里云 Milvus 适用于任何需要进行“相似性”匹配的场景。其核心应用包括：

图像视频搜索：如电商平台的以图搜图、安防领域的人脸识别和视频轨迹追踪。
文本语义搜索：构建智能客服、企业内部文档知识库和代码搜索引擎，能精准理解用户意图，而非简单的关键词匹配。
个性化推荐系统：根据用户的行为和偏好向量，实时推荐最相似的商品、音乐、新闻或视频。
前沿科学与安全：在生物信息学中加速药物分子筛选，或在网络安全领域进行异常流量和欺诈行为检测。
智能驾驶数据准备与挖掘：对点云图像、车载传感器收集的音视频等多模态数据进行向量数据的实时查询。

n8n平台介绍

n8n，全称NodeNation，意寓“节点连接”，是一个开源的、可视化的工作流自动化平台，被誉为“程序员的Zapier”或可自部署的Make。它允许用户通过连接不同的“节点”（Node）来构建强大的自动化任务。每个节点代表一个具体的操作，例如读取数据库、调用API、发送邮件、处理文件或执行AI模型。用户可以在一个可视化的画布上，通过拖拽和连接这些节点，将复杂的业务流程、数据同步、定时任务等轻松实现自动化，而无需编写大量代码。其核心特点在于高度的灵活性和可扩展性，支持数百种应用和服务的即用型集成。

基础概念：

节点（Node）：负责集成外部服务和实现功能的核心载体。工作流的最小功能单元，代表一个独立操作步骤（如发送HTTP请求、解析JSON、写入数据库）。通过输入/输出端口传递数据（JSON格式），支持本地执行或分布式执行。
工作流（Workflow）：由多个节点按逻辑顺序连接而成的自动化流程，支持分支、循环、错误处理。支持事件驱动（Webhook）与定时调度两种触发模式，是执行引擎的输入。
执行引擎（Engine）：n8n的运行时核心，负责解析工作流定义和拓扑、调度节点执行、管理任务队列与错误重试。
卷（Volume）：在容器化部署（如Docker）中，用于持久化存储n8n配置、工作流数据与日志的存储空间。通过绑定宿主机目录到容器路径（如/home/n8n/.n8n），避免数据丢失。

方案概述

为了达到快速搭建一个企业级的垂直领域智能问答应用的效果，我们将在n8n中创建两个工作流。其中第一个工作流用来定时拉取GitHub上Milvus产品的文档数据，写入Milvus向量库中。第二个工作流使用AI Agent，结合大模型的能力判断客户的提问，当问及的问题与Milvus产品相关就从Milvus向量库中召回问题对应的答案，将答案整合到大模型的输出中返回客户；否则就直接通过大模型进行一个通用的回答。

流程图大致如下所示：

操作步骤

前提条件

已创建阿里云Milvus实例。具体操作，请参见快速创建Milvus实例。
已开通服务并获得API-KEY。具体操作，请参见开通DashScope并创建API-KEY。
github创建openapi key，请参见 GitHub认证。
已安装本地docker，请参见 Docker&Docker Compose安装(离线+在线) 。

1、n8n 安装与配置

输入以下命令，创建一个名字为n8n_data的数据卷，并创建n8n运行容器

docker volume create n8n_data
docker run --name n8n -d \
    -e N8N_SECURE_COOKIE=false \
    -p 5678:5678 \
    -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

安装成功验证

启动后访问部署的n8n服务IP地址http://127.0.0.1:5678/ 进入n8n的登陆页面，设置管理员账号密码，并登陆进管控台。

阿里云Milvus接入配置

创建Milvus账号，输入Base URL、Username 和 Password，顶部连接验证通过即可。

注意

将Base URL替换为您的阿里云Milvus公网地址，并在后面需要加端口19530。
将Username替换为您的阿里云Milvus用户。
将Password替换为您的阿里云Milvus密码。

GitHub接入配置

创建GitHub账号，开通方式参考文档，输入User和Access Token，顶部连接验证通过即可。

2、工作流配置：拉取GitHub数据创建知识库

在n8n平台上添加工作节点，选择 GitHub 的 List files 节点

选择GitHub接入的Credential，填写仓库Owner、仓库Name以及需要创建向量的Path，如下图所示，然后执行Execute step查看输出。

在Split Out 输出节点配置参数中，选择download_url字段，配置一个Split Out Node做字段提取。

为避免执行后可能会出现null 或者.png结尾的文档，进一步可能影响后续Http获取的正确性，所以我们还需要配置一个If Node，过滤掉null和非.md的链接，If Node节点具体配置如下图所示。

接下来配置一个Http Request节点，URL为之前的download_url参数，测试输入输出，如下图所示。

自此，milvus官网的文档内容我们已经成功提取了，这部分完整工作流如下图所示。

接下来就需要对解析的网页内容，向量化后输入milvus数据库，我们在上述工作流的基础上添加一个后继节点Milvus Vector Store，选择Milvus接入的Credential，选择一个collection，这里使用了n8n_test，为了便于测试，选择Clear Collection开关打开，这样每次插入时会自动清除数据。

在Milvus Vector Store节点配置的左下角添加embedding模型，我们这里选择 text-embedding-v1模型，dataloader使用Default Data Loader，并选择之前参数中的data字段。

最后，因为考虑到github上文档的实时性，我们需要定时同步所有文档，因此添加一个Schedule Trigger节点，定时执行，放在最前面进行工作流的触发，具体配置如下，我们这里选择定期同步的周期为每天。

github上提取文档内容以及录入milvus向量库的工作流已经配置完成，如下图所示。

执行该工作流，查看下面交互式日志。

验证阶段登录阿里云Milvus控制台，选择您配置的Milvus实例，单击右上角Attu Manager进入Attu页面，可以看到对应的n8n_test collection 数据已存在，点击加载collection，左侧collection处显示绿灯，且有加载entity即可。

现在，我们已经可以实现成功将GitHub拉取数据创建知识库。

3、工作流配置：大模型结合Milvus检索增强

为了实现智能化的问答，接下来我们重新创建一个工作流，选择When chat message received节点，当收到输入框内容回车后触发。

接下来创建一个AI Agent节点，通过接受Chat输入，当客户搜索Milvus相关信息时，我们希望从之前创建的知识库进行内容召回，除此之外，采用大模型的默认输出返回。在本例中，输入以下内容作为System Prompt

你是主控 AI，负责统筹不同的专业子代理，以执行复杂的用户任务。
你有以下的Agent/Tool
1. MilvusDocumentAgent  
Agent负责搜索所有Milvus相关的文档，当涉及到Milvus相关搜索，运行这个Agent
其他情况下，直接在该节点执行

左下角的Chat Model我们选用qwen-plus模型。

中间Memory选用Simple Memory，最多保持5条上下文

右下角Tool位置，添加Milvus Vector Store，模式采用作为Tool方式，Collection选取之前创建知识库对应的n8n_test，召回限制设置4，可以选择Metadata，以便当chunk数据中包含metadata可以有更好的精确度。其中Rerank简单来说，核心作用是“精加工”和“优化”，它在粗糙的向量检索结果之上，进行一次更精确、更智能的排序，从而把最相关的结果顶到最前面，弥补了召回率高精准度低的情况。 Rerank可以视情况选取，在本例子中不选。

再后接一个Set节点，将文本输出的内容提取出来

大模型结合Milvus检索增强的工作流已经配置完成，如下图所示。

验证效果

执行Chat工作流，输入一个Milvus相关的技术问题，比如 “Milvus的Data Classification 策略有哪些？”

可以看到AI Agent通过将Milvus知识库召回的内容，结合大模型润色总结，输出了一个可读性较强的内容。

查看n8n的执行监控日志，可以清晰的看到每个步骤的输入输出，如图Milvus向量召回可以看到原始的与内容相关的文档，同时左侧可以看到整个问答的链路以及内部一些细节，体验非常好。

n8n可观测

工作流编排平台如n8n、Dify等，通过连接不同服务（如API、数据库、AI模型）来自动化复杂任务。随着工作流节点增多、逻辑变复杂，一个任务的执行路径如同一个微服务调用链，可观测性变得至关重要。

其中，Trace（链路追踪）是可观测的核心。它能将单次工作流执行所经过的所有节点串联成一条完整的、可视化的调用链。这使得开发者可以：

快速定位错误：清晰看到流程在哪一步中断及其上下文。
分析性能瓶颈：直观了解每个节点的耗时，找出拖慢整体流程的环节。
理解数据流转：追踪数据在各个节点间的传递与变换过程。

没有Trace，诊断复杂工作流的故障就像大海捞针，因此它是确保平台稳定与高效的关键。

目前比较尴尬的是，n8n并没有提供原生的可观测平台的接入支持，比如langfuse的Trace能力集成，暂时还没实现，参考文档。在社区也有大量Trace方面的讨论，参考文档，官方暂时没有实现。

本例子参考了一些民间的解决方案，实现了n8n与opentelemetry的集成。

集成了opentelemetry后，可以对接任何可观测平台，比如skywalking、Jaeger等开源可观测平台，这里以阿里云SLS为例子。

操作步骤

首先通过git命令下载项目，镜像打包

git clone https://github.com/pbrissaud/n8n-opentelemetry
cd n8n-opentelemetry
docker build -t n8n-otel:latest .

启动镜像，输入trace相关的环境变量，这部分请参考阿里云官方文档。

docker run --name n8n -d \
    -e N8N_SECURE_COOKIE=false \
    -e OTEL_SDK_DISABLED="false" \
    -e OTEL_SERVICE_NAME="n8n" \
    -e OTEL_LOG_LEVEL="info" \
    -e OTEL_EXPORTER_OTLP_ENDPOINT="https://taihao-server-cn-hongkong-prod.cn-hongkong-intranet.log.aliyuncs.com:10010" \
    -e OTEL_EXPORTER_OTLP_HEADERS="x-sls-otel-project=taihao-server-cn-hongkong-prod,x-sls-otel-instance-id=taihao-cn-hongkong,x-sls-otel-ak-id=xxx,x-sls-otel-ak-secret=xxx" \
    -p 5678:5678 \
    -v n8n_data:/home/node/.n8n n8n-otel:latest

启动后，重新运行一下之前的case，重新问一个问题。

查看docker logs可以看到trace已经打印出来。

查看Trace平台可以看到数据已上报。

n8n安全

“我的密码足够复杂，不可能被攻破！” ——这是无数系统管理员在遭遇安全事件前，最常持有的信念。

然而，现实往往比想象更加残酷。对于像 n8n 这类功能强大且高度可扩展的自动化工作流平台而言，潜在的安全风险远不止于账户泄露本身。

n8n 的一大优势在于其开放性：支持用户自由安装第三方 npm 节点，极大地提升了功能的灵活性和可拓展性。但正因如此，这种开放性也带来了不容忽视的安全隐患。一旦攻击者获取了账户权限，他们不仅能随意查看、修改甚至删除您精心设计的工作流（Workflow），更可利用节点安装机制，植入恶意代码模块。更为严峻的是，这些第三方节点通常以与 n8n 主进程相同的权限运行。这意味着，一个恶意节点可能直接获得服务器的执行权限，进而实现远程命令执行、横向渗透、数据窃取，甚至完全掌控整个服务器系统。到那时，数据被删除或许只是最轻微的后果——更严重的情况可能是敏感信息被长期窃取、系统被用作跳板发起进一步攻击，或是服务器沦为僵尸网络的一部分。

因此，我们必须清醒地认识到：强大的工具，必须配以同等严谨的安全策略。

本例子将使用动态密码(2FA)技术，保障n8n的登陆安全。