AI Agent连接SQL与向量数据库：企业知识库智能问答架构解析

“Digital Librarian AI Agent”这个名称最早是在IBM的一档技术讲解视频里出现的。直译过来就是“数字图书管理员AI代理”它的定位很明确把大模型从“聊天窗口”升级成“资料管理员”你只需要用自然语言提问它自己决定该去SQL数据库里查结构化记录还是去向量数据库里做语义检索最后把结果整理成答案返回给你。这个消息在中文社区里最初是以中英字幕学习材料的形式传播的很多人一边看字幕一边对照英文术语学习概念。但真正值得关注的不是字幕本身而是IBM提出的这套架构思路用LLM作为调度大脑把SQL数据库和向量数据库同时接入Agent的工具链。这其实就是“混合数据检索 工具调用”的经典工程形态也是企业知识库落地时最现实的需求。这篇文章会把这条思路拆开讲为什么一个Agent需要同时连接SQL和向量数据库LLM怎么决定调用哪个工具Text-to-SQL和RAG在中间各扮演什么角色以及一个最小可运行的Demo该怎么写。如果你正在做企业知识库、内部问答机器人、数据查询助手这类项目或者你只是想知道“LLM除了聊天还能怎么落地”这篇文章可以直接收藏。1. 核心概念速览能力项说明项目来源IBM技术讲解视频“什么是Digital Librarian AI Agent”中文社区以中英字幕形式流传核心思想用LLM作为Agent调度大脑通过工具调用同时接入SQL数据库和向量数据库SQL数据库的作用处理结构化数据查询典型如订单记录、员工信息、库存清单通过Text-to-SQL把自然语言转成SQL语句向量数据库的作用处理非结构化数据语义检索典型如产品文档、技术手册、FAQ通过Embedding实现相似度搜索Agent决策方式依赖LLM的Function Calling / Tool Use能力自动选择调用SQL工具还是向量检索工具适用形态企业知识库问答、内部数据助手、文档业务数据混合查询显存要求如果LLM走API服务本机不需要GPU如果LLM本地部署显存取决于模型规模接口能力可以把Agent封装成HTTP API供前端或下游系统调用批量任务支持知识库批量写入向量索引也支持批量问题队列处理项目性质概念讲解 架构设计不是开箱即用的软件包落地时需要自己拼装组件这里要提前说清楚IBM的视频重在讲清概念和架构不会给你一个可以双击启动的安装包。你要做的是理解这套“SQL 向量数据库 LLM Agent”的组合方式然后用LangChain、LlamaIndex或者原生Function Calling把它实现出来。2. 为什么AI Agent要同时连接SQL和向量数据库很多人在做企业知识库时容易掉进一个误区把所有资料全部塞进向量数据库然后让LLM做RAG检索。这种做法对文本类文档确实有效但一遇到“上季度华东区销售额是多少”“张三目前借了几本书没还”这种问题就失灵了。原因很简单这类问题背后是强结构化数据答案藏在数据库字段里而不是某段文档的语义描述里。你不可能靠余弦相似度把一个数值算出来。正确的做法是让Agent去执行一条SQLSELECT、WHERE、GROUP BY之后再返回结果。反过来如果有人问“什么是Text-to-SQL”你用SQL去查也不合适。这个问题的答案是一种概念解释存在于技术文档中需要去向量数据库里做语义检索再把相关片段交给LLM总结。所以Digital Librarian AI Agent的设计逻辑是用户问题进来之后LLM先判断意图再选择合适的工具。查订单、查库存、查员工信息走SQL路线查概念、查规范、查操作手册走向量检索路线。两条路线共用同一个对话入口对用户完全透明。这种设计的价值在于不用迁移现有数据。结构化数据继续留在SQL数据库文档继续放在知识库Agent层面做工具连接即可。答案是“算”出来的不是“猜”出来的。SQL查询返回的是精确业务数据错误率低。文档检索补足了SQL无法覆盖的语义空间覆盖范围更大。知识库更新与数据库写入互不影响数据治理边界清晰。从实际场景看一个客服机器人如果只接向量数据库它知道“退货政策”在哪一页但不知道“这个用户昨天买过什么”。如果只接SQL它知道用户的订单记录但解释不了“退货政策为什么要这样执行”。Digital Librarian AI Agent要做的就是把这两个能力拼到一起。3. Digital Librarian AI Agent 架构拆解把整个架构拆开可以分成四层。3.1 用户层用户通过Web聊天窗口、企业微信、钉钉或者API接口提出问题。这一层只保留对话记录和上下文管理不做任何数据访问。问题文本统一传给Agent核心。3.2 Agent调度层这一层是整个架构的大脑由一个LLM实例承担。LLM需要具备Function Calling能力也就是在生成回复之前先根据用户问题判断是否需要调用外部工具如果需要则输出一个结构化的工具调用请求。调度逻辑大致如下接收用户问题。LLM结合系统提示词判断问题类型。如果问题涉及结构化业务数据输出SQL查询工具调用。如果问题涉及文档语义内容输出向量检索工具调用。执行工具把结果返回给LLM。LLM基于工具输出生成最终自然语言回答。3.3 工具层工具层至少包含两个核心工具SQL Query Tool接收LLM生成的SQL语句执行查询并返回结果集。Vector Search Tool接收自然语言查询文本完成Embedding编码在向量数据库中执行相似度检索返回最相关的文档片段。工具层还可以扩展比如增加HTTP请求工具、API调用工具、文件读取工具扩展方式完全一致。3.4 数据层数据层包含关系型数据库和向量数据库两类存储。关系型数据库负责存储业务数据字段清晰、关系明确适合精确查询。向量数据库负责存储文档Embedding向量需要在入库前对文档做切片、Embedding和索引构建。下面用一张文字流程来描述这个架构用户问题 ↓ LLM Agent调度器判断意图 ↓ ↓ SQL查询工具 向量检索工具 ↓ ↓ SQL数据库 向量数据库 ↓ ↓ 精确业务结果 相关文档片段 ↓ ↓ LLM汇总生成答案 ↓ 输出给用户这里的关键点在于LLM工具调用不是一次完成就结束的。现实中的Agent经常需要“先查SQL拿用户ID再拿ID去向量库查相关文档”这种多轮工具调用。所以整个循环要支持多步调用直到LLM认为信息足够再输出最终答案。4. 关键技术Text-to-SQL、Embedding与Function CallingDigital Librarian AI Agent能落地依赖三项核心技术的成熟。4.1 Text-to-SQLText-to-SQL指把自然语言问题转换成SQL查询语句。比如用户问“图书管理系统中有多少本计算机类书籍”LLM需要把它转换成SELECT COUNT(*) FROM books WHERE category 计算机;这个转换看起来简单但在真实业务里很考验模型能力。你需要让LLM知道数据库的表结构、字段含义、枚举值范围否则它可能生成一张不存在的表名或者把时间字段的格式搞错。实践中通常有两种方式预置Schema在系统提示词中把表结构和字段说明贴给LLM适合表数量少的项目。动态Schema注入先查询数据库的表结构动态拼进Prompt适合表数量多的项目。无论哪种方式都必须给SQL工具设置安全护栏比如只允许SELECT语句、限制查询行数、设置查询超时时间。4.2 Embedding与向量检索向量数据库解决的是语义检索问题。文档在入库前会被切片切好的文本块通过Embedding模型转换成向量存储在向量数据库中。查询时用户问题同样经过Embedding转换然后通过余弦相似度或内积计算找到最相关的文档片段。这里容易踩坑的是切片策略。切片太大检索结果会混入无关信息切片太小单片段上下文不足LLM无法回答。实际操作时可以按章节、段落、固定长度三种方式混合使用再根据效果调整。向量数据库选型上如果数据量小用Chroma、FAISS就可以如果到了生产环境Milvus、Weaviate、Qdrant这类分布式方案更合适。4.3 Function Calling工具调用Function Calling是OpenAI最早提出的能力现在几乎成为行业标准。它的工作方式是你给LLM定义一批工具每个工具包含名称、描述和参数Schema。LLM在生成回复时如果判定需要调用工具它不会直接输出自然语言而是输出一个结构化的函数调用请求包含函数名和参数。下面是一个标准工具的JSON定义{ type: function, function: { name: query_sql_database, description: 查询图书管理系统中的结构化数据支持按书名、作者、分类、借阅状态查询, parameters: { type: object, properties: { sql: { type: string, description: 要执行的只读SQL查询语句 } }, required: [sql] } } }第二个工具是向量检索{ type: function, function: { name: search_vector_database, description: 在文档知识库中进行语义搜索适合查找概念解释、技术方案、操作手册等非结构化内容, parameters: { type: object, properties: { query: { type: string, description: 自然语言检索问题 }, top_k: { type: integer, description: 返回的相关文档数量默认3, default: 3 } }, required: [query] } } }LLM看到这两个工具定义后会根据用户问题自己决定调用哪一个。这就是整个Agent最核心的机制。链式调用时比如“先查张三的用户ID”模型会先生成SQL工具调用执行后再发起下一轮工具调用。5. 环境准备与最小可运行示例这一节给出一套通用落地流程。以下是Demo设计用来复现Digital Librarian AI Agent的核心行为。5.1 环境准备项目要求操作系统Windows / macOS / Linux均可Python版本Python 3.9及以上LLM访问OpenAI兼容接口推荐使用API方式不需要本机GPU关系数据库SQLite即可生产环境可替换为MySQL、PostgreSQL向量数据库Chroma或FAISS生产环境替换为Milvus、QdrantEmbedding模型使用API服务或本地模型均可如text-embedding-3-small、bge系列整体来看如果LLM走API你的本机不需要独立显卡内存8G以上带一个轻量向量库没有问题。如果坚持全本地部署LLM需要至少12G以上显存Embedding模型可以在CPU上运行。5.2 准备SQL数据先创建一个SQLite数据库插入几条图书数据作为演示数据。import sqlite3 conn sqlite3.connect(library.db) cursor conn.cursor() cursor.execute( CREATE TABLE IF NOT EXISTS books ( id INTEGER PRIMARY KEY, title TEXT NOT NULL, author TEXT, category TEXT, status TEXT, location TEXT ) ) cursor.executemany( INSERT INTO books (title, author, category, status, location) VALUES (?, ?, ?, ?, ?), [ (SQL注入防御实践, 张工, 安全, 可借, A-01), (向量数据库原理, 李工, 数据库, 借出, B-02), (大语言模型工程化, 王工, AI, 可借, C-03), (图数据库实战, 赵工, 数据库, 可借, B-05), ] ) conn.commit() conn.close()5.3 准备向量数据使用Chroma做一个轻量的向量索引用来模拟“文档知识库”。先用任意Embedding服务生成向量再写入集合。import chromadb from chromadb.utils import embedding_functions client chromadb.PersistentClient(path./vector_store) embedding_fn embedding_functions.OpenAIEmbeddingFunction( model_nametext-embedding-3-small ) collection client.get_or_create_collection( namelibrary_docs, embedding_functionembedding_fn ) docs [ Text-to-SQL是一种将自然语言转换为SQL查询语句的技术主要依赖大语言模型理解数据库表结构。, 向量数据库通过Embedding将文本转换为高维向量使用余弦相似度进行语义检索。, Function Calling允许大模型在生成回复时调用外部工具是AI Agent的核心能力之一。, 企业知识库建设中结构化数据适合用SQL查询非结构化文档适合用向量检索。 ] collection.upsert( ids[str(i) for i in range(len(docs))], documentsdocs )5.4 实现Agent核心循环下面用OpenAI兼容接口来演示Agent的决策循环。这个过程是所有Digital Librarian AI Agent的骨架LLM生成工具调用主程序执行工具把结果回传给LLMLLM生成最终答案。import json import sqlite3 import openai client openai.OpenAI() TOOLS [ { type: function, function: { name: query_sql_database, description: 查询图书馆数据库中的图书结构化信息支持按标题、作者、分类、借阅状态查询, parameters: { type: object, properties: { sql: { type: string, description: 要执行的只读SQL查询语句 } }, required: [sql] } } }, { type: function, function: { name: search_vector_database, description: 在图书馆技术文档库中进行语义搜索适合回答概念解释、技术原理解答, parameters: { type: object, properties: { query: { type: string, description: 自然语言检索问题 }, top_k: { type: integer, default: 3 } }, required: [query] } } } ] def run_sql(sql_text: str): conn sqlite3.connect(library.db) cursor conn.cursor() try: cursor.execute(sql_text) rows cursor.fetchall() columns [desc[0] for desc in cursor.description] return {columns: columns, rows: rows} finally: conn.close() def run_vector_search(query_text: str, top_k: int 3): collection client.get_collection( library_docs, embedding_functionembedding_fn ) result collection.query( query_texts[query_text], n_resultstop_k ) return {documents: result[documents]} def librarian_agent(user_question: str): messages [{role: user, content: user_question}] response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolsTOOLS, tool_choiceauto ) msg response.choices[0].message if not msg.tool_calls: return msg.content messages.append(msg) for tool_call in msg.tool_calls: args json.loads(tool_call.function.arguments) if tool_call.function.name query_sql_database: tool_result run_sql(args[sql]) elif tool_call.function.name search_vector_database: tool_result run_vector_search( args[query], args.get(top_k, 3) ) else: tool_result {error: unknown tool} messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(tool_result, ensure_asciiFalse) }) final_response client.chat.completions.create( modelgpt-4o-mini, messagesmessages ) return final_response.choices[0].message.content if __name__ __main__: print(librarian_agent(有没有计算机类的书)) print(----) print(librarian_agent(什么是向量数据库))这个Demo把最重要的Agent决策循环完整跑通了。你拿相同的框架去换真实业务表、真实文档库就是一个生产雏形。6. 功能测试与效果验证代码写完之后不要急着接生产数据先按下面几个维度做一轮验证。6.1 SQL查询类问题测试测试问题预期行为判断标准图书管理系统中总共有多少本书LLM生成COUNT查询返回精确数字张工写了哪些书LLM生成WHERE author张工的查询返回正确记录数现在可借的书有哪些LLM生成WHERE status可借的查询返回列表正确测试时重点观察LLM生成的SQL是否合法、是否用对了字段名、是否受Schema描述影响。如果SQL经常出错就在工具描述里补充更完整的字段说明。6.2 向量检索类问题测试测试问题预期行为判断标准什么是Text-to-SQL触发向量检索工具返回的文档片段与问题语义相关Function Calling的作用是什么触发向量检索工具返回的文档片段覆盖核心要点企业知识库怎么选存储触发向量检索工具检索结果能帮助LLM总结出对比结论向量检索类的判断标准不是“非对即错”而是看返回的文档片段和问题之间是否语义匹配。如果相关性差先检查切片粒度再检查Embedding模型的选型。6.3 多轮工具调用测试在真实场景中Agent可能连续调用多个工具。比如“找出关于向量数据库的书再解释一下向量数据库的核心概念”理想情况下Agent会先查SQL然后调用向量检索最后合并回答。如果多轮工具调用失败常见原因是上下文信息没有被正确回传给LLM。检查messages里每一步的tool_call_id是否对应工具结果是否成功追加。6.4 判断成功的标准一个合格的Digital Librarian AI Agent至少要满足同一类语义的问题连续问10次工具选择正确率不低于90%。SQL工具生成的语句不会出现表名或字段名错误。向量检索工具返回结果与问题相关不会答非所问。工具执行时间控制在可接受范围内SQL查询超过5秒、向量检索超过3秒需要优化。最终答案不是对工具结果的直接搬运而是自然语言组织后的总结。6.5 常见失败原因系统提示词没有说清数据库Schema导致SQL频繁报错。Embedding模型版本不稳定同一个问题两次检索结果差异很大。LLM上下文窗口太小工具结果太长时被截断。缺少工具调用次数上限Agent陷入死循环。7. 接口API与批量任务设计Demo能跑通之后下一件事就是把Agent包成HTTP服务方便其他系统调用。7.1 FastAPI接口封装from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class AskRequest(BaseModel): question: str class AskResponse(BaseModel): answer: str app.post(/ask, response_modelAskResponse) def ask(req: AskRequest): answer librarian_agent(req.question) return AskResponse(answeranswer) app.get(/health) def health(): return {status: ok}启动命令uvicorn main:app --host 127.0.0.1 --port 8000这样外部系统就可以通过HTTP接口访问Agent能力。要注意的是真实生产环境不要直接暴露在公网至少要加鉴权和访问限制。7.2 批量任务设计批量任务主要有两类。一类是知识库批量入库需要把批量文档切片后执行Embedding再写入向量数据库另一类是批量问题处理比如历史工单自动回复、批量数据查询。批量问题处理时建议用一个简单的队列结构不要同步并发调用LLM接口。原因有二一是LLM API有速率限制并发过高会被限流二是SQL查询必须控制并发避免压垮数据库。一个简单的批量处理伪代码import time import json questions [ 计算机类图书有哪些, 什么是函数调用, 张工的书放在哪里, ] for idx, q in enumerate(questions): try: answer librarian_agent(q) with open(f./outputs/result_{idx}.json, w, encodingutf-8) as f: json.dump({question: q, answer: answer}, f, ensure_asciiFalse) except Exception as e: print(f问题 {q} 处理失败: {e}) time.sleep(1) # 留出请求间隔批量任务建议增加三个能力失败重试、结果落盘、进度日志。任何一个环节缺失大批量任务一跑起来你都会后悔。8. 常见问题与排查方法问题现象可能原因排查方式解决方案LLM生成的SQL语句表名错误Schema没有正确注入Prompt打印LLM生成的SQL检查系统提示词里的表结构在工具描述中补充完整表结构和字段说明SQL执行超时查询未限制行数或JOIN过于复杂查看数据库慢查询日志强制增加LIMIT和超时时间控制查询行数向量检索结果不相关文档切片过大或Embedding模型不匹配打印检索到的文档片段检查切片粒度调整切片大小更换Embedding模型Agent选择了错误的工具工具描述不够明确打印LLM的工具调用选择日志优化工具description增加使用场景说明多轮调用死循环缺少工具调用次数上限查看Agent调用日志中的tool_calls数量设置最大调用次数超过则终止并返回提示请求LLM接口报413传入内容长度超过模型限制检查messages总长度对长文档做截断或分段处理API部署后无法访问端口被占用或防火墙未放行使用netstat检查端口curl测试本地接口修改端口或开放防火墙白名单批量任务中途停止某个问题抛出异常且无重试机制查看日志中的异常栈增加单条任务try-except和失败重试这里重点提醒一个容易被忽略的问题LLM工具调用产生的结果务必做格式校验。SQL工具返回的结果集需要确认是否为空、字段是否完整向量检索结果需要确认返回条数是否满足要求。否则LLM面对空结果时很容易自己编造一个不存在的答案这在知识库场景里风险很大。9. 最佳实践与合规边界走到这一步思路已经完整了。最后几条建议直接决定项目能不能从Demo走向生产。9.1 工程化建议第一次联调时只用最小数据集把工具选择的准确性调到一个稳定水平后再接入全量数据。SQL工具必须使用只读账号禁止Agent生成的SQL执行INSERT、UPDATE、DELETE、DROP等操作这是防止SQL注入和数据误删的基本前提。始终对Agent设置最大工具调用次数建议3到5次避免逻辑死循环造成API费用和查询压力失控。模型缓存可以做但结果要带时间戳避免知识库和数据更新后回答还是旧的。接口层一定要加鉴权系统提示词中不要写入数据库账号密码所有敏感信息都放环境变量。9.2 合规边界企业知识库里的文档入库前要确认版权和授权情况不能把未经授权的内部资料或第三方内容随意公开到Agent接口上。涉及用户个人信息、订单数据时必须做脱敏和权限隔离。不同角色只能查询对应权限范围的数据。LLM生成的SQL本身也是代码需要纳入安全审查。上线前建议把所有历史生成的SQL日志做一轮审计。如果用到本地部署的LLM要确认模型授权和部署许可如果走API服务要关注数据传输与存储合规要求。不要为了让Agent更“智能”就把系统提示词写成可以绕过权限控制的内容安全边界一旦被突破工具调用链会变成数据泄露通道。9.3 扩展方向把SQL和向量数据库接好之后这个架构的扩展空间很大。你可以继续接入工单系统、日历日程、外部API查询等工具让Agent从“数字图书管理员”变成“数字助理”。每一步扩展其实都是往TOOLS数组里再增加一个JSON定义再写一个对应的执行函数。架构本身不需要变。总结与下一步Digital Librarian AI Agent最值得尝试的点是把结构化数据查询和语义检索统一到同一个Agent里让用户不再关心“这个问题该查哪个系统”。这个思路对企业知识库场景覆盖得比较完整也是LLM在实际业务里真正能提升效率的落地方式。如果你要动手实践我建议按这个顺序来先用SQLite加一个轻量向量库把最小Demo跑通。重点验证LLM的工具选择是否稳定这是整个Agent的命门。确认工具选择稳定后再替换成真实业务数据库和生产文档库。接入API层、鉴权、日志和批量任务让系统具备上线条件。最容易踩的坑有三个不注入Schema导致SQL乱生成、不设工具循环上限导致Agent死循环、不限制SQL权限导致数据安全风险。这三个坑只要提前堵住项目离生产就更近一步。后面如果你想继续深入可以试着给这个架构增加多轮对话记忆或者在向量检索里加上重排Rerank环节回答质量还会再上一个台阶。这套结构搭好后扩展起来只是时间问题。