n8n Agentic RAG 智能体模板深度解析：融合向量检索与 SQL 查询的多工具知识库方案

n8n Agentic RAG 智能体模板深度解析融合向量检索与 SQL 查询的多工具知识库方案【免费下载链接】ottomator-agentsAll the open source AI Agents hosted on the oTTomator Live Agent Studio platform!项目地址: https://gitcode.com/GitHub_Trending/ot/ottomator-agents本文基于 oTTomator Agents 仓库中的 n8n 智能体 RAG 工作流模板n8n-agentic-rag-agent/Ultimate_Agentic_RAG_AI_Agent_Template.json与其配套说明n8n-agentic-rag-agent/README.md完整拆解一套可直接导入 n8n 的 Agentic RAG 系统它不止做向量检索而是让 LLM Agent 自主决策——何时走 RAG、何时查 SQL、何时读整篇文档并借助 Google Drive 触发器实现文档自动入库。读完本文你将掌握该模板的架构脉络、三张数据表与匹配函数的建表 SQL、四类 Agent 工具的调用逻辑以及部署与自定义的完整路径。为什么需要 Agentic RAG标准 RAG 的四大短板该模板的设计出发点源自标准 RAGRetrieval Augmented Generation在真实业务场景中的明显局限。README 中将其归纳为四点数值与表格数据分析能力差简单向量检索对某季度总营收最大值这类需要精确计算的提问无能为力分块导致上下文缺失文档被切块后答案所需的上下文可能横跨多个 chunk检索结果天然残缺无法跨文档串联信息结论分散在多篇文档时标准 RAG 难以把片段组合成完整答案不会根据问题类型动态选工具无论问什么都走同一条嵌入→检索→拼接的固定流水线。Agentic RAG 的解法是把检索本身交给 Agent 决策。模板的 Agent 系统提示词明确要求除非问题需要针对表格数据执行 SQL 查询求和、求最大值等 RAG 查找不可靠的操作否则始终先执行 RAG如果 RAG 无效就查看可用文档清单挑选几篇可能包含答案的文档并深入分析——这正是能推理、能自我改进检索、能动态切换工具的具象实现。模板全景42 个节点、34 条连线的两大子系统从 JSON 模板Ultimate_Agentic_RAG_AI_Agent_Template.json的节点清单看该工作流共包含42 个节点、34 组连接逻辑上可划分为两条相互独立的子系统文档摄取流水线Ingestion Pipeline以 Google Drive 触发器为起点将新文件/更新文件自动处理入库问答运行时Agent Runtime以 Chat Trigger 或 Webhook 为入口驱动 LLM Agent 调用各类工具回答用户问题。两条子系统的纽带是同一套 Supabase/Postgres 数据库——向量检索表、文档元数据表与表格数据行表。摄取流水线负责写库Agent 运行时负责按需读库。整体链路如下Google Drive 触发器(新建/更新) │ 每 1 分钟轮询指定文件夹 ▼ Set File IDfile_id / file_type / file_title / file_url ▼ Download FileGoogle 文档转 text/plain ▼ Switch 按 mimeType 分流 ├─ PDF → Extract PDF Text → 文本分块 → 向量化 → 插入 Supabase Vectorstore(documents 表) ├─ 文本类(文档/Docs) → Extract Document Text → 同上 └─ Excel/CSV/Google 表格 → 抽取行数据 → 删除旧行 → 以 JSONB 写入 document_rows 表 │ ▼ 更新 document_metadata标题、URL、表格 schema数据层设计三张表 一个匹配函数模板用三个 Postgres 节点完成建表全部以executeQuery直连 Supabase 的 Postgres 实例执行部署时须先运行这三个建表节点。1. documents 表向量检索主表含 pgvector 扩展与 match_documents 函数-- Enable the pgvector extension to work with embedding vectors create extension vector; -- Create a table to store your documents create table documents ( id bigserial primary key, content text, -- corresponds to Document.pageContent metadata jsonb, -- corresponds to Document.metadata embedding vector(1536) -- 1536 works for OpenAI embeddings, change if needed ); -- Create a function to search for documents create function match_documents ( query_embedding vector(1536), match_count int default null, filter jsonb DEFAULT {} ) returns table ( id bigint, content text, metadata jsonb, similarity float ) language plpgsql as $$ #variable_conflict use_column begin return query select id, content, metadata, 1 - (documents.embedding query_embedding) as similarity from documents where metadata filter order by documents.embedding query_embedding limit match_count; end; $$;要点说明与模板内节点 Create Documents Table and Match Function 完全一致embedding vector(1536)与模板默认嵌入模型text-embedding-3-small对齐若更换嵌入模型需同步调整向量维度相似度使用余弦距离相似度 1 - 距离filter jsonb通过metadata filter实现元数据过滤摄取时写入的file_id、file_title元数据即可在此作为检索过滤条件match_count缺省为null由调用方Supabase Vectorstore 节点决定返回条数。2. document_metadata 表文档目录CREATE TABLE document_metadata ( id TEXT PRIMARY KEY, title TEXT, url TEXT, created_at TIMESTAMP DEFAULT NOW(), schema TEXT );id即 Google Drive 文件 IDschema字段用于记录 CSV/Excel 文件的表头结构Agent 查询表格数据时先读 schema 再构造 SQL。摄取完成后由 Insert Document Metadata 节点以upsert匹配列id写入标题与 URL随后由 Update Schema for Document Metadata 节点回填schema。3. document_rows 表表格数据的 JSONB 存储CREATE TABLE document_rows ( id SERIAL PRIMARY KEY, dataset_id TEXT REFERENCES document_metadata(id), row_data JSONB -- Store the actual row data );这是模板用 JSONB 存储表格数据、无需为每个 CSV 建新表的关键设计每个 Excel/CSV 文件的每一行作为一条document_rows记录整行内容以 JSONB 存入row_datadataset_id关联到文档元数据。INSERT 时模板用表达式{{ $json.toJsonString().replaceAll(//g, ) }}对单引号做转义避免破坏 SQL 语法。重复文件处理入库前的幂等清理两个 Supabase 节点负责删除旧数据Delete Old Doc Rowsdelete操作过滤条件metadata-file_id like *{{ $json.file_id }}*删除该文件的旧向量块防止重新摄取时产生重复 chunkDelete Old Data Rows按dataset_id {{ $(Set File ID).item.json.file_id }}删除document_rows中该文件的历史行。也就是说同一文件每次更新都会被整体重建天然支持文档迭代。摄取流水线Google Drive 文件自动入库触发器与多文件循环File Created 与 File Updated 两个 Google Drive 触发器均设置为每分钟轮询指定文件夹模板中默认监听名为 n8n Documents 的目录上传多个文件时触发器会输出多个 itemLoop Over ItemssplitInBatches节点以循环逐个处理实现单次工作流循环处理多个文件Set File ID 从触发数据提取四个关键字段贯穿后续流程file_id$json.idDrive 文件 ID充当数据库主键与检索过滤键file_type$json.mimeType驱动分流判断file_title$json.namefile_url$json.webViewLink按文件类型分流的 Switch 节点Switch 依据file_typemimeType走三条分支mimeType 匹配处理分支application/pdfExtract PDF TextextractFromFile的pdf操作抽取全文application/vnd.openxmlformats-officedocument.spreadsheetml.sheetExcel 表格分支xlsx抽取 → 表格入库application/vnd.google-apps.spreadsheetGoogle 表格分支先经 Download File 下载并转换docsToFormat: text/plain再按 CSV/Excel 路径处理文本类文件分块 → 嵌入 → 写入向量库文本分支的链路为Extract Document Text或 PDF 抽取→AggregateaggregateAllItemData汇总全部内容→Character Text Splitter字符级切块 →Embeddings OpenAI默认text-embedding-3-small→ Insert into Supabase Vectorstoremode: insert表documents查询函数match_documents。写入时模板通过 Default Data Loader 的 metadata 选项为每个 chunk 附加file_id与file_title元数据取值自$(Set File ID).first().json使向量库可以按文件维度过滤与追溯。表格类文件抽取 → 汇总 → JSONB 入库表格分支的关键节点是 Set Schema它生成两个关键字段schema{{ $(Extract from Excel).isExecuted ? $(Extract from Excel).first().json.keys().toJsonString() : $(Extract from CSV).first().json.keys().toJsonString() }}即动态取表头字段列表供 Agent 构造 SQL 时参考data汇总后的行数据供 Summarize 以concatenate聚合。随后 Insert Table Rows 将每一行以{dataset_id, row_data}写入document_rows最后更新document_metadata中的schema。整个过程中表格数据完全不进向量库从而规避了向量检索对数值计算不可靠的根本问题。Agent 运行时四个工具与系统提示词入口与记忆When chat message received公开 Chat Trigger提供交互式聊天入口WebhookPOST、headerAuth 鉴权、responseNode 响应模式 Edit Fields 提供外部 API 调用入口兼容$json.chatInput || $json.body.chatInput与sessionId两种入参形态最后经 Respond to Webhook 返回结果Postgres Chat MemorymemoryPostgresChat把多轮会话历史持久化到 Postgres支撑连续追问。Agent 系统提示词模板原文RAG AI Agent 节点使用n8n/n8n-nodes-langchain.agenttypeVersion 1.6其系统提示词定义了完整的工具使用策略You are a personal assistant who helps answer questions from a corpus of documents. The documents are either text based (Txt, docs, extracted PDFs, etc.) or tabular data (CSVs or Excel documents). You are given tools to perform RAG in the documents table, look up the documents available in your knowledge base in the document_metadata table, extract all the text from a given document, and query the tabular files with SQL in the document_rows table. Always start by performing RAG unless the question requires a SQL query for tabular data (fetching a sum, finding a max, something a RAG lookup would be unreliable for). If RAG doesnt help, then look at the documents that are available to you, find a few that you think would contain the answer, and then analyze those. Always tell the user if you didnt find the answer. Dont make something up just to please them.这份提示词对应了模板对外暴露的四个 Agent 工具全部以ai_tool类型接入 AgentSupabase Vector Store1RAG 工具retrieve-as-tool模式工具名documents工具描述 Use RAG to look up information in the knowledgebase.查询函数match_documents——用于常规语义检索也是提示词中始终先执行 RAG的首选路径List DocumentspostgresToolselect全表读取document_metadata描述为获取所有可用文档若文件是 CSV/Excel 则一并返回其表结构 schema——帮助 Agent 了解知识库中有哪些文档、哪些是表格数据Get File ContentspostgresTool执行 SQL 把某个文件的全部chunk 拼接成完整文本SELECT string_agg(content, ) as document_text FROM documents WHERE metadata-file_id $1 GROUP BY metadata-file_id;参数$1由表达式{{ $fromAI(file_id) }}动态填充——这正是需要完整文档上下文时直接取全文而不是只给片段的实现机制弥补了分块丢失上下文的缺陷Query Document RowspostgresTool执行{{ $fromAI(sql_query) }}生成的任意 SQL用于对document_rows做精确计算。工具描述中内置了两条示范查询-- 例 1求某文件的平均 revenue SELECT AVG((row_data-revenue)::numeric) FROM document_rows WHERE dataset_id 123; -- 例 2按 category 分组求和 SELECT row_data-category as category, SUM((row_data-sales)::numeric) as total_sales FROM dataset_rows WHERE dataset_id 123 GROUP BY row_data-category;其中dataset_id即文件的file_idrow_data为 JSONB 字段通过-提取键值并::numeric转型后参与聚合运算。Agent 的决策闭环因此非常清晰先 RAG 语义检索 → 不满足则查文档目录 → 锁定文件后取全文精读或对表格文件执行 SQL 精确计算 → 找不到答案就如实告知用户。跨文档串联、数值精准分析、动态选工具三大能力均由这套提示词 四个工具的组合直接产出。部署与使用步骤按 README 的 Getting Started落地该模板只需四步建表导入模板后先手动运行三个建表节点Create Documents Table and Match Function、Create Document Metadata Table、Create Document Rows Table确保 Supabase 中已存在documents、document_metadata、document_rows三张表及match_documents函数上传文档将文件放入 Google Drive 中触发器监听的文件夹默认 n8n Documents如需更换存储方案也可将触发器替换为其他文件存储需要为 Google Drive、OpenAI、Supabase/Postgres 各凭据完成授权模板中 OpenAI 凭据以openAiApi引用自动处理Agent 会自动完成文本分块入库、表格数据 JSONB 入库与元数据登记全程无需人工干预提问验证通过 Chat Trigger 或 Webhook 发起问题观察 Agent 是否按RAG → 目录 → SQL/全文的次序决策。自定义扩展方向README 明确指出模板是一个可扩展的坚实基础建议从以下维度定制调优系统提示词替换 RAG AI Agent 节点的 systemMessage适配具体业务如限定回答语言、补充领域规则、调整工具调用顺序偏好补充文档元数据如在document_metadata增加 summary 字段可让 Agent 在 List Documents 阶段更快判断文档相关性引入更高级 RAG 技术如重排序Reranking、查询改写Query Expansion、多查询检索等可替换/叠加在向量检索工具之上面向更大知识库优化调整 Character Text Splitter 的分块参数、索引策略或引入混合检索。运行前提与注意事项该模板依赖 n8n 的n8n/n8n-nodes-langchain 系列节点Agent、Supabase Vectorstore、Postgres Chat Memory、Embeddings 等需在支持 LangChain 节点的 n8n 版本中导入运行嵌入维度硬编码为1536对应 OpenAItext-embedding-3-small更换嵌入模型必须同步修改documents.embedding向量维度与match_documents函数签名数据库需启用pgvector扩展建表脚本中已包含create extension vector;Google Drive 触发器采用每分钟轮询模式文件处理存在分钟级延迟若需近实时处理可调整pollTimes模板内嵌了作者示例的 Drive 文件夹 ID 与 Webhook 路径使用前应替换为自有资源。总的来说这套模板的参考价值在于它示范了一种向量检索 结构化查询 全文精读三路并存的 Agentic RAG 范式把存储结构三表 JSONB、摄取自动化Drive 触发 循环 类型分流与决策智能系统提示词 四个 Postgres/Vectorstore 工具完整串联。无论是直接导入改造还是借鉴其表结构与工具编排思路都能为构建更可靠的企业级 RAG 提供一份可运行、可验证的起点。【免费下载链接】ottomator-agentsAll the open source AI Agents hosted on the oTTomator Live Agent Studio platform!项目地址: https://gitcode.com/GitHub_Trending/ot/ottomator-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考