各位读者朋友大家好。最近不少人在讨论 IBM 的一个概念动画《What is a Digital Librarian AI Agent?》它用一个非常形象的比喻把 AI Agent、SQL 和向量数据库之间的关系讲清楚了。很多朋友看完后留言问我Digital Librarian 到底是做什么的SQL 和向量数据库为什么会同时出现LLM 在这里面扮演什么角色这篇文章我不打算只做字幕翻译而是顺着这个概念把它拆解成一套可落地的技术方案。我们会从概念入手讲清楚 Digital Librarian AI Agent 的定位再分析结构化数据SQL与非结构化知识向量数据库各自的价值最后用一个完整的 Python 实战项目演示如何让 LLM 同时连接 SQL 与向量数据库做一个能查订单、能查文档、能聊历史的“数字图书管理员”。无论你是正在做 RAG检索增强生成、企业知识库还是对 Agent 架构感兴趣的开发者这篇文章都能帮你打通概念与代码之间的断层。1. 什么是 Digital Librarian AI Agent1.1 从“图书管理员”的比喻说起在传统的图书馆里图书管理员是读者与图书之间的桥梁。读者不会直接走进书库翻找而是告诉管理员“我想找一本关于数据库优化的书”管理员会根据分类号、索引目录快速定位甚至能告诉你“这本书的第二章对索引讲得最透”。Digital Librarian AI Agent数字图书管理员智能体就是把这个角色搬到了数字世界。它不是简单的搜索引擎而是能够理解用户意图、主动规划查询路径、跨多个数据源检索信息并把结果整理成回答的智能体。IBM 这个概念动画的核心观点可以总结为未来的企业知识管理不是把所有数据塞进一个存储里而是让 AI Agent 能够同时驾驭结构化数据数据库表与非结构化数据文档、档案、知识片段。1.2 为什么需要同时连接 SQL 与向量数据库这是一个关键问题。很多人刚开始接触时都会想既然向量数据库能做语义搜索为什么还要折腾 SQL二者不是一个替代关系而是互补关系。SQL 数据库擅长存储高精度、强结构、有关系的数据。例如订单记录、用户资料、库存数量、销售金额这些都是“少一个字都不行”的数据。一张订单表的金额字段你不可能用“大概那么多钱”来回答审计问题。向量数据库擅长存储语义化、非结构化、文本向量的数据。例如产品手册、客服聊天记录、技术文档、规章制度。它的检索方式是“找意思相近的内容”而不是“匹配精确字段”。一个真正能落地使用的 AI Agent必须同时具备这两种能力。比如用户问“上个月华东区退货最多的产品是什么”你需要先从 SQL 里聚合分析出结果而用户问“我们的退货政策里关于冲动消费是怎么规定的”你则需要从向量数据库里检索政策文档。这就是 Digital Librarian AI Agent 存在的价值它把这两种能力统一到一个交互入口后面。1.3 它与普通 ChatBot 的区别普通的 ChatBot 只能基于训练数据或单轮 Prompt 回答遇到不在训练数据里的企业内部数据就“一问三不知”。而 Digital Librarian AI Agent 具备以下特征能力维度普通 ChatBotDigital Librarian AI Agent数据范围网络公开知识企业内部数据库 知识库查询方式静态生成动态规划并调用工具结构化数据不支持通过 SQL 精确查询非结构化数据不支持通过向量相似度检索多轮对话较浅结合上下文持续追问可审计性弱查询过程可记录、可追溯从本质上讲Digital Librarian AI Agent 是 Agent 范式在企业数据场景中的具体应用。它不再是一个“聊天模型”而是一个“会使用工具的智能体”。2. 核心概念拆解LLM、Agent、RAG 与向量数据库要深入理解 Digital Librarian AI Agent必须先厘清一组容易混淆的概念。很多读者在交流时会把 LLM、RAG、Agent、向量数据库混为一谈这里我们做一个清晰的拆解。2.1 LLM 是“大脑”不是“数据库”LLMLarge Language Model大语言模型的本质是一个根据上下文预测下一个 token 的模型。因为训练的语料足够多它具备了语言理解、推理和生成能力但它本身并不“记住”你的私有数据。这也是很多企业在落地大模型时踩过的坑以为把 PDF 文档喂给 ChatGPT 就能解决内部知识问答。实际上LLM 的上下文窗口有限且训练时的知识是“过去的快照”无法覆盖企业每天更新的数据。所以LLM 只负责理解和生成不负责存储与检索。2.2 RAG 是“外挂知识包”RAGRetrieval-Augmented Generation检索增强生成解决的是 LLM 知识不足的问题。它的思路非常朴素用户提问之后先从外部检索出与问题最相关的文档片段把这些片段拼进 Prompt 里再交给 LLM 生成回答。这样一来LLM 不需要“记住”你的内部资料只需要在回答时“读取”当前提供的片段。RAG 的检索阶段通常使用向量数据库来完成。流程如下用户提问 - 将问题文本向量化Embedding - 在向量库中查找相似片段 - 拼装 Prompt - LLM 生成回答2.3 Agent 是“会使用工具的机器人”Agent 的出现把 LLM 从“被动回答”升级为“主动执行”。普通的 LLM 调用是“问题进、答案出”而 Agent 允许 LLM 在一轮对话中规划步骤、调用外部工具比如 SQL 查询函数、向量检索函数、HTTP API根据工具的返回结果继续推理直到完成目标。以 Digital Librarian AI Agent 为例一个完整的执行过程可能是用户提问帮我查一下订单号为 10086 的客户邮箱然后读一下这位客户最近反馈的投诉文档。 Agent 规划 1. 调用 query_order_by_id(10086) - 得到 customer_id 2. 调用 query_customer_email(customer_id) - 得到 email 3. 调用 search_vector_docs(customer_name) - 检索投诉文档 4. 汇总所有结果 - 生成最终回答在这个过程中LLM 负责“决策下一步做什么”SQL 工具负责“精确取数”向量检索工具负责“语义找文档”。2.4 SQL 与向量数据库的适用边界维度SQL 数据库向量数据库数据模型表格行列关联向量高维空间查询方式结构化查询SELECT、JOIN、WHERE相似度检索余弦距离、欧氏距离典型数据订单、用户、库存、财务文档、日志、知识片段、图片特征查询精度精确匹配、聚合计算语义相关结果带相似度分数擅长问题“上季度销售额是多少”“客户对退换货政策有哪些抱怨”不适合场景模糊语义搜索精确金额统计在实际系统中这两类数据往往是共存的。Digital Librarian AI Agent 的价值就在于它对用户隐藏底层存储差异统一通过自然语言交互返回结果。用户不需要知道“这个问题该走 SQL 还是走向量库”Agent 自己会判断。3. 系统架构设计一个最小可用的 Digital Librarian 方案在动手写代码之前我们先规划一个最小可用的系统架构。这套架构不依赖特定的云服务本地 Python 环境就能跑通。3.1 整体架构图文字版------------------------------------------- | 用户对话入口 | ------------------------------------------ | v ------------------------------------------- | LLM Agent决策与编排层 | | - 意图识别 | | - 工具调用规划 | | - 答案生成 | ----------------------------------------- | | v v ------------------ -------------------- | SQL 工具模块 | | 向量检索工具模块 | | - 查询订单 | | - 文档Embedding | | - 查询客户 | | - 相似度检索 | | - 聚合统计 | | - 返回TopK片段 | ------------------ -------------------- | | v v ------------------ -------------------- | 关系型数据库 | | 向量数据库 | | SQLite示例 | | Chroma示例 | ------------------- ---------------------3.2 技术选型为了让示例尽量轻量同时保证功能完整我选用以下技术栈组件选型说明关系型数据库SQLite无需安装服务端文件即数据库适合演示生产环境可替换为 MySQL、PostgreSQL向量数据库Chroma纯 Python 实现的嵌入式向量库适合本机运行生产可替换为 Milvus、Weaviate、QdrantEmbedding 模型OpenAI text-embedding-3-small也可以替换为本地模型如 BGE、m3eLLMOpenAI GPT-4o / GPT-4.1-mini也可以用国内大模型 API 替换开发语言Python 3.10目前对 LangChain、Chroma 兼容性最好说明如果你没有 OpenAI 的 API Key可以替换为任何支持 OpenAI 风格接口的大模型服务。本文示例中使用 LangChain 的抽象封装更换模型时只需要修改一处配置。3.3 目录结构规划digital-librarian/ ├── requirements.txt ├── data/ │ ├── orders.db # SQLite 数据库文件 │ └── docs/ # 知识库原始文档 │ ├── return_policy.txt │ └── customer_notes.txt ├── src/ │ ├── database.py # SQL 工具层 │ ├── vector_store.py # 向量检索工具层 │ ├── agent.py # Agent 编排层 │ └── main.py # 命令行入口 └── README.md4. 实战构建一个能查 SQL 又能查向量库的 AI Agent接下来我们进入代码实战环节。为了控制篇幅聚焦在核心逻辑上。4.1 环境准备与依赖安装建议使用虚拟环境。在项目根目录执行python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate创建requirements.txtlangchain0.2.14 langchain-openai0.1.22 chromadb0.5.5 openai1.42.0 pandas2.2.2安装依赖pip install -r requirements.txt4.2 准备 SQLite 示例数据Digital Librarian 首先要能查“精确数据”。我们创建一个销售订单库。创建data/init_db.py# 文件路径data/init_db.py import sqlite3 import os DB_PATH os.path.join(os.path.dirname(__file__), orders.db) def init_db(): # 如果数据库已存在先删除保证示例可重复执行 if os.path.exists(DB_PATH): os.remove(DB_PATH) conn sqlite3.connect(DB_PATH) cur conn.cursor() # 客户表 cur.execute( CREATE TABLE customers ( id INTEGER PRIMARY KEY, name TEXT NOT NULL, email TEXT NOT NULL, region TEXT NOT NULL ) ) # 订单表 cur.execute( CREATE TABLE orders ( id TEXT PRIMARY KEY, customer_id INTEGER NOT NULL, product TEXT NOT NULL, amount REAL NOT NULL, status TEXT NOT NULL, created_at TEXT NOT NULL ) ) customers [ (1, 张伟, zhangweiexample.com, 华东), (2, 李娜, linaexample.com, 华南), (3, 王强, wangqiangexample.com, 华北), ] cur.executemany(INSERT INTO customers VALUES (?, ?, ?, ?), customers) orders [ (SO-1001, 1, 智能手表, 1299.00, 已完成, 2025-05-10), (SO-1002, 2, 蓝牙耳机, 499.00, 已完成, 2025-05-12), (SO-1003, 1, 机械键盘, 899.00, 已发货, 2025-05-14), (SO-1004, 3, 显示器, 2199.00, 待付款, 2025-05-15), (SO-1005, 2, 智能手表, 1299.00, 已发货, 2025-05-16), ] cur.executemany(INSERT INTO orders VALUES (?, ?, ?, ?, ?, ?), orders) conn.commit() conn.close() print(数据库初始化完成, DB_PATH) if __name__ __main__: init_db()运行python data/init_db.py预期输出数据库初始化完成 data/orders.db这批数据模拟了一个微型电商场景3 个客户、5 笔订单。后续 Agent 可以回答“华东区客户有哪些”“金额大于 1000 的订单”等问题。4.3 编写 SQL 工具层Digital Librarian 的 SQL 工具层核心思路是不要让 LLM 随便拼接 SQL 语句而是提供封装好的函数由 Agent 决定调用参数。这样做可以显著降低 SQL 注入和语法错误的风险。创建src/database.py# 文件路径src/database.py import sqlite3 import pandas as pd DATABASE_PATH data/orders.db def get_connection(): conn sqlite3.connect(DATABASE_PATH) conn.row_factory sqlite3.Row return conn def query_customer_by_region(region: str) - str: 按地区查询客户列表 conn get_connection() try: df pd.read_sql_query( SELECT id, name, email, region FROM customers WHERE region ?, conn, params(region,) ) return df.to_markdown(indexFalse) finally: conn.close() def query_order_over_amount(amount: float) - str: 查询金额大于指定值的订单 conn get_connection() try: df pd.read_sql_query( SELECT id, customer_id, product, amount, status FROM orders WHERE amount ? ORDER BY amount DESC, conn, params(amount,) ) return df.to_markdown(indexFalse) finally: conn.close() def query_orders_by_customer(name: str) - str: 根据客户姓名查询订单 conn get_connection() try: df pd.read_sql_query( SELECT o.id, c.name, o.product, o.amount, o.status FROM orders o JOIN customers c ON o.customer_id c.id WHERE c.name ? , conn, params(name,) ) return df.to_markdown(indexFalse) finally: conn.close()这里有几个设计要点使用参数化查询params(region,)是防止 SQL 注入的关键。返回 Markdown 表格把 DataFrame 转成 Markdown方便 LLM 直接把结果放到回答里不用再做一次格式转换。每个函数职责单一Agent 可以清楚地区分“查询客户”和“查询订单”的边界降低误调用概率。4.4 准备知识库文档并写入向量数据库SQL 解决的是“结构化数据精确查询”接下来我们用向量数据库解决“非结构化文档语义检索”。先创建两个示例文档data/docs/return_policy.txt退货政策2025版 自订单签收之日起 7 天内消费者在商品无破损、不影响二次销售的前提下可申请无理由退货。 电子类产品如智能手表、蓝牙耳机激活后不支持七天无理由退货但同样享受 15 天质量问题换新服务。 退货运费由消费者承担但若为商品质量问题运费由商家承担。data/docs/customer_notes.txt客服备注记录 2025-05-08客户张伟反馈智能手表表带过敏已协商换货客户情绪缓和。 2025-05-11客户李娜咨询蓝牙耳机音质问题疑似非正品已经提供官方验真链接。 2025-05-13客户王强在支付显示器订单时遇到页面报错已引导重试。创建src/vector_store.py# 文件路径src/vector_store.py import os from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_core.documents import Document PERSIST_DIR data/chroma_db DOCS_DIR data/docs def load_docs(): docs [] for filename in os.listdir(DOCS_DIR): path os.path.join(DOCS_DIR, filename) with open(path, r, encodingutf-8) as f: content f.read() docs.append(Document(page_contentcontent, metadata{source: filename})) return docs def build_vector_store(): docs load_docs() text_splitter RecursiveCharacterTextSplitter( chunk_size200, chunk_overlap20, separators[\n\n, \n, 。, 。, ], ) chunks text_splitter.split_documents(docs) print(f文档切分为 {len(chunks)} 个片段) embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vector_store Chroma.from_documents( documentschunks, embeddingembeddings, persist_directoryPERSIST_DIR ) print(向量数据库构建完成) return vector_store def get_vector_store(): # 如果持久化目录已存在直接加载 if os.path.exists(PERSIST_DIR): embeddings OpenAIEmbeddings(modeltext-embedding-3-small) return Chroma( persist_directoryPERSIST_DIR, embedding_functionembeddings ) return build_vector_store() def search_docs(query: str, top_k: int 3) - str: 在知识库中检索与问题最相关的文档片段 vector_store get_vector_store() docs vector_store.similarity_search_with_score(query, ktop_k) if not docs: return 未找到相关资料 results [] for i, (doc, score) in enumerate(docs, 1): results.append(f[片段{i}] 来源: {doc.metadata.get(source, 未知)} (相似度: {score:.4f})) results.append(doc.page_content.strip()) return \n\n.join(results)这里需要特别说明一下 Chunk 切割参数chunk_size200表示每个片段最多 200 个字符。对于中文文档200 到 500 是比较常用的范围。chunk_overlap20表示相邻片段有 20 个字符的重叠避免一句话被硬切导致语义断裂。separators列表告诉切割器优先按“段落 - 换行 - 句号”的顺序切割。4.5 编写 Agent 编排层Agent 编排层是整个 Digital Librarian 的中枢。这里使用 LangChain 的create_openai_tools_agent让 LLM 自动决定调用哪个工具。创建src/agent.py# 文件路径src/agent.py from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain.agents import create_openai_tools_agent, AgentExecutor from langchain_core.tools import tool from database import query_customer_by_region, query_order_over_amount, query_orders_by_customer from vector_store import search_docs # 把普通函数包装为 LangChain 工具 tool def search_customer_by_region(region: str) - str: 按地区查询客户列表。参数 region 为地区名称例如华东、华南、华北。 return query_customer_by_region(region) tool def search_orders_over_amount(amount: float) - str: 查询金额大于指定数值的订单。参数 amount 为数字金额例如 1000。 return query_order_over_amount(amount) tool def search_orders_by_customer(name: str) - str: 按客户姓名查询订单列表。参数 name 为客户姓名例如张伟。 return query_orders_by_customer(name) tool def search_knowledge_base(query: str) - str: 在知识库中检索文档片段。适合回答退货政策、客服备注等非结构化问题。 return search_docs(query) # 创建 Agent def create_agent(): llm ChatOpenAI( modelgpt-4o-mini, temperature0.2, ) tools [ search_customer_by_region, search_orders_over_amount, search_orders_by_customer, search_knowledge_base ] prompt ChatPromptTemplate.from_messages([ (system, 你是一名企业数字图书管理员助手。你能够访问两类数据 1. 结构化业务数据订单、客户、销售记录需要使用 SQL 工具查询。 2. 非结构化知识文档退货政策、客服备注需要从向量知识库检索。 规则 - 如果问题需要精确取数例如金额、数量、地区优先使用 SQL 工具。 - 如果问题涉及文档政策、历史备注、语义描述使用向量知识库工具。 - 如果问题需要先查客户再查订单可以连续调用多个工具。 - 回答时把工具返回结果整理成简洁、友好的中文回答。 ), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_openai_tools_agent(llm, tools, prompt) executor AgentExecutor( agentagent, toolstools, verboseTrue, # 打开后可以在控制台看到 Agent 的思考过程 max_iterations5, # 防止 Agent 无限循环 ) return executor4.6 编写命令行入口并测试创建src/main.py# 文件路径src/main.py from agent import create_agent def main(): executor create_agent() example_questions [ 华东地区有哪些客户, 查询金额大于 1000 元的订单, 张伟的订单有哪些, 我们的退货政策里关于 7 天无理由是怎么规定的, 李娜最近反馈了什么商品问题, ] for question in example_questions: print(\n *60) print(用户提问, question) print(*60) response executor.invoke({input: question}) print(\n最终回答) print(response[output]) if __name__ __main__: main()运行cd src python main.py在运行前你需要设置 OpenAI API Key。在命令行临时设置export OPENAI_API_KEYsk-你的密钥 # Windows 使用 set OPENAI_API_KEYsk-你的密钥4.7 预期运行结果由于 LLM 生成内容存在一定随机性实际输出不会逐字相同但执行流程应该是类似的。以第一个问题“华东地区有哪些客户”为例控制台会输出类似信息用户提问 华东地区有哪些客户 Entering new AgentExecutor chain... 我应该使用 SQL 工具来查询这个结构化数据。 调用了 search_customer_by_region参数为 {region:华东} 最终回答 华东地区有以下客户 1. 张伟zhangweiexample.com第二个问题“查询金额大于 1000 元的订单”会触发search_orders_over_amount工具返回大额订单列表。再来看“我们的退货政策里关于 7 天无理由是怎么规定的”这个问题Agent 会判断它属于知识库检索调用search_knowledge_base工具然后从返回的文档片段中提取关键信息进行回答。这正体现了 Digital Librarian 的核心能力同一个对话入口背后自动路由到不同的数据引擎。从执行日志中可以看出Agent 并不是“一上来就生成答案”而是先判断“该用什么工具”再根据工具结果组织语言。这就是它与普通 ChatBot 最本质的区别。5. 常见问题与排查思路在实际运行和二次开发过程中你可能会遇到以下几类问题。5.1 LangChain 版本差异导致 API 不兼容问题现象常见原因解决思路ImportError: cannot import name create_openai_tools_agentlangchain 版本过旧或安装成了旧版 API升级版本并重新安装依赖TypeError: OpenAIEmbeddings.__init__() got an unexpected keyword argument参数名随版本变化查阅当前版本的官方文档确认参数名Chroma 报No module named chromadb.segment安装目录存在残留缓存删除环境重建或者升级 chromadb建议统一按照本文第 4.1 节的依赖版本安装。如果你在更晚的时间阅读本文相关库的版本可能已经更新可以先执行pip list | grep langchain确认版本再按需调整。5.2 Agent 没有调用 SQL 工具反而自己“编造”数据这是使用大模型 Agent 时最常见的问题。LLM 在温度较高或工具描述不清晰的情况下可能跳过工具调用直接凭借训练数据生成看似合理的答案。排查方向检查temperature是否过高建议设置为 0.2 以下。检查工具 docstring 是否清晰。LangChain 的 Agent 是靠函数的 docstring 和参数描述决定调用时机的如果描述含糊模型就会“猜”。在 Prompt 中强调“所有数据必须来自工具返回结果不要编造”。5.3 向量检索返回了无关内容可能原因包括切分粒度不合适chunk_size过大导致片段包含太多无关信息过小导致单个片段缺少上下文。可以尝试 300 或 500同时查看实际切分结果。Embedding 模型与文本语言不匹配中文场景下如果使用面向英文优化的 Embedding 模型效果会明显下降。可尝试替换为中文效果更好的模型如 bge-large-zh。top_k 过大默认检索 3 个片段如果你发现第 3 个片段相关性很差可以调小top_k2。5.4 SQL 查询报错或返回空结果SQL 工具内部使用了pandas.read_sql_query如果 SQL 语法有误会直接抛异常。为了提升健壮性可以在函数外层加上 try-except将错误信息返回给 Agent让 Agent 知道自己“调用失败”从而调整参数重新调用。def safe_sql_query(func, *args, **kwargs): try: return func(*args, **kwargs) except Exception as e: return f调用失败错误信息{e}这样的好处是Agent 不会因为一次工具调用失败就直接放弃而是会尝试换一种查询方式。6. 生产环境落地的最佳实践从 Demo 走向生产Digital Librarian AI Agent 还有很长的路要走。这里分享几条来自真实项目的经验。6.1 不要让 LLM 直接生成 SQL很多初学 Agent 的开发者喜欢写一个“万能 SQL 工具”让 LLM 自己根据自然语言生成 SQL 语句。但在生产环境中这几乎等于打开了潘多拉魔盒。风险包括LLM 生成的 SQL 存在语法错误LLM 可能生成高成本的全表扫描拼接不当时存在 SQL 注入风险无法控制用户只能查询“他有权查看的数据”。更稳的做法是本文演示的**“功能化工具封装”**把可执行的查询场景提前定义成一个个函数LLM 只需要选择函数和填写参数而不是自由编写 SQL。6.2 对 SQL 工具执行只读操作并管控权限Digital Librarian 在企业内部的知识查询场景应该只具备 SELECT 权限绝不能拥有 INSERT、UPDATE、DELETE 权限。在数据库层面单独创建一个只读账号CREATE USER ai_agent% IDENTIFIED BY 强密码; GRANT SELECT ON enterprise_db.* TO ai_agent%;这条限制即使 Agent 被恶意提示词诱导也无法通过 SQL 工具修改数据。6.3 向量数据更新策略企业文档是持续变化的因此知识库不能只建一次。建议建立定时任务例如每天凌晨扫描文档目录识别新增、变更文件后重新 Embedding 并写入向量库。比较实用的策略是按文档来源更新时间差量更新而不是每次全量重建避免产生大量冗余向量。6.4 增加查询审计与反馈机制在生产环境中Agent 的每一次工具调用都应该被记录。建议把以下信息写入日志或审计表用户提问原文命中的工具名称与参数工具返回结果摘要LLM 最终回答耗时与 token 消耗。用户是否对结果点了“有用/无用”。这些日志不仅用于排查问题也是后续评估 Agent 效果、优化 Prompt 和工具描述的宝贵样本。6.5 为检索结果标注来源AI Agent 回答最怕的是“一本正经地胡说八道”。Digital Librarian 的优势在于SQL 返回的数据和向量库返回的文档片段都有来源。因此最终回答中应要求 LLM 标注引用来源。例如“根据《退货政策2025版》第三段……”“订单数据来源于订单表查询时间为 14:32”。这既是产品体验的一部分也是企业合规审计的需要。7. 下一步学习建议如果你已经跟着本文完成了一个简单的 Digital Librarian AI Agent建议按以下路线继续深入。第一阶段打磨工具层把 SQLite 替换成 MySQL 或 PostgreSQL把 Chroma 替换成 Milvus 或 Qdrant体验生产级数据库与向量库的接入差异。这会让你理解为什么生产环境需要考虑连接池、索引优化和向量索引类型选择。第二阶段增强 Agent 能力增加更多工具例如调用企业工单 API 查询售后进度调用日历 API 预约沟通时间调用邮件 API 草拟客户回复邮件。Agent 的价值会随着工具数量增长而放大但也要注意工具之间的冲突和优先级。你可以尝试引入路由判断逻辑先判断问题类别再决定走哪一组工具。第三阶段深入评估与调优可以尝试给 Agent 增加“自我反思”步骤让它拿到工具结果后先检查是否解决了用户问题再生成最终回答而不是“拿到结果就直接输出”。同时建议积累一套评测集包含不同类型的提问精确查询类、语义检索类、多轮问答类、模糊意图类每次修改 Prompt 或代码后都跑一遍评测集确保没有“修好了 A 却弄坏了 B”的回归问题。Digital Librarian AI Agent 这个名字听起来很未来但它的技术本质并不神秘用 LLM 做推理和决策用 SQL 工具做精确查询用向量数据库做语义检索再用 Agent 架构把三者编织在一起。希望这篇文章能帮你把 IBM 概念视频里的想象力变成你自己机器上能跑起来的一段段代码。如果你在实践过程中遇到问题欢迎在评论区留言交流。