1. 为什么是“知识库 数据库”的组合出发点与基础场景1.1 知识库与数据库解决的是两种完全不同的问题这两年“AI Agent”这个概念已经快被玩坏了。很多人一上来就搭 Agent第一反应是给模型接一个向量数据库做一套 RAG 知识库觉得能把企业内部文档检索出来就等于“智能”了。但真正跑到生产环境就会发现知识库解决的是“非结构化信息”的查找问题而企业里还有大量高价值数据躺在关系型数据库里——订单、库存、用户画像、财务流水、设备状态这些东西用 RAG 是检索不出来的。你不可能让大模型去“向量化”一张订单表也不应该把客户的资金流水直接丢进 Embedding 模型里切割成块。数据库里的数据是强结构、强约束、强权限的和知识库里的 PDF、Word、内部 Wiki 完全是两套玩法。所以真正企业级的数据智能 Agent必须具备两条腿走路的能力一条腿检索知识库里的文档规则、产品说明、历史案例另一条腿直接查数据库里的实时业务数据。两条腿缺一条这个 Agent 都只能停在“演示阶段”。1.2 哪些业务场景真正需要这类 Agent结合我实际接触过的落地项目下面这几类场景是最典型的“知识库 数据库”双打场景工单智能助手客服提问“这个订单为什么还没发货”Agent 需要从知识库检索发货规则和异常处理 SOP同时去订单系统数据库查询该订单当前的物流状态、是否拆单、是否命中拦截策略。运维诊断助手用户反馈“昨晚大促之后接口变慢了”Agent 需要查数据库里的慢查询记录、链路追踪表、机器负载指标再结合知识库中的历史故障复盘文档给出诊断建议。企业内部门户问答“今年 Q3 华东区的回款率是多少”“跟去年同期比怎么样”这类问题基本 100% 需要实时查库附带的知识库只是用来补充统计口径和业务术语解释。数据报表自助化业务人员不懂 SQL但想知道“上个月新增的 VIP 用户里哪个行业的转化率最高”Agent 直接改写为多条 SQL 去数据仓库取数再结合报表使用规范文档生成结论。这些场景有一个共同特征答案必须是“当前时刻”的真实数据不能靠模型幻觉编造也不能靠文档快照。这也决定了架构上必须把数据库作为一等公民接入而不是把表格导出成 PDF 丢进知识库敷衍了事。2. PolarDB Agent Express 的核心拆解它到底封装了什么2.1 开箱即用不等于黑盒我第一次看到“PolarDB Agent Express”这个产品名的时候第一反应是警惕市面上叫 Agent 的壳子太多了很多其实就是套了个提示词模板跑通一个 ChatPDF 就说自己是企业级智能体。但仔细拆开来看这类方案的价值不在于“模型有多大”而在于它把几个非常难做的工程问题以服务化的方式解决了。PolarDB 本身就是云原生数据库而 Agent Express 在其上提供的核心能力可以理解为“长在数据库旁边的 AI 代理层”。它不是一个独立的通用 Agent 平台而是围绕数据库访问、自然语言转 SQL、权限隔离、执行审计这一串链路做了深度封装。用的时候你不需要自己维护一套向量库、不需要自己写 Function Calling 的解析逻辑、不需要从零搭建“模型调用 → 工具调用 → 结果返回”的 Agent 循环。这些环节在平台内部已经形成了一个相对稳定的运行框架。2.2 自然语言转 SQL 的执行链路自然语言转 SQL这个方向学术界做了很多年以前效果一直不太理想原因是模型对数据库 schema 的感知能力太弱稍微复杂一点的表关系就晕。Agent Express 这类产品解决这个问题的方式是把“schema 感知”和“样本增强”整合进了执行链路。一条中文问题进来之后大致会走这样一条链路意图识别与问题改写判断用户是想查数据、写数据还是想基于文档回答问题。Schema 召回根据问题语义先从元数据里召回相关的表、字段、索引、外键关系而不是把整个库几百张表全部塞给模型。SQL 生成基于召回的表结构、字段注释、枚举值、历史查询样本生成候选 SQL。语义校验对生成的 SQL 做合法性检查比如字段是否存在、表是否被权限策略禁止访问、是否包含明显的全表扫描。执行与解释通过受控数据库账号执行查询拿到结果集之后再做一次自然语言总结。链路本身其实就是标准 Text-to-SQL 架构但工程难点在第二步和第四步。Schema 召回如果做不好模型会在浩瀚的表结构里迷失语义校验如果做不好一条“误伤”的 SQL 可能直接把生产库拖垮。Agent Express 的优势是这些规则已经内置在数据库引擎的周边可以和数据库的会话管理、资源组、执行计划分析直接打通。提示使用这类方案时不要一上来就问特别复杂的关联查询。先把单表查询、聚合查询跑通再逐步挑战多表 Join。这个顺序能帮你快速判断产品内置的 Schema 理解能力到底在哪一层。2.3 知识库检索和数据库查询的协同方式这个是我认为最有价值的部分。单纯做 RAG 的 Agent 很多单纯做 Text-to-SQL 的 Agent 也不少但真正难的是让两者在同一次问答中协作。举个例子用户问“帮我查一下华东区销售额 TOP10 的客户并告诉我他们对账周期一般是怎么约定的。”这个问题分成两半“华东区销售额 TOP10 客户”需要查订单表、客户表是实时的结构化查询。“对账周期一般怎么约定”这是一种业务规则通常写在销售管理制度文档里属于知识库检索。如果这两半是分开的两个工具Agent 必须先判断先调哪个、后调哪个再把两部分结果拼装成最终答案。如果协同不好就会出现“查了数据但解释规则是错的”或者“搬来文档但数据对不上”的割裂感。好的方案会在内部把知识库和数据库查询当成同一套的“工具路由”先通过知识库检索确定业务口径再用业务口径去约束 SQL 生成最后把查询结果结合文档依据一起返回。这个“以知识定口径、以数据库出数据、以模型做解读”的串行逻辑是落地效果的关键。3. 一次完整的落地过程从配置到跑通一次问答3.1 前置环境与开通既然是云数据库方案第一步自然是开通 PolarDB 实例并且确认你使用的版本支持 Agent Express 服务。这里我不展开具体的控制台点击路径因为控制台 UI 迭代很快重点讲清楚开通时容易被忽略的几个前置条件数据库账号的权限规划给 Agent 专用的账号不要直接用管理员账号。这个账号应该只拥有查询权限以及能够访问 Agent 所需元数据的权限。如果后续要让 Agent 做写操作也需要单独立一条审批策略而不是放开 UPDATE 和 DELETE。知识库的数据源格式Agent Express 对接知识库时通常需要准备好文档存储位置支持常见的 PDF、Word、Markdown、TXT。建议文档里不要堆大段无关的页眉页脚解析效果会好很多。网络访问链路如果你还要把 Agent 接入企业微信、钉钉、飞书或者内部 OA确认这些入口和 PolarDB 服务之间的网络策略是通的。很多项目最后卡在“Agent 问答没问题但接不到 IM 机器人回调”这种环节。3.2 给 Agent 配“数据库权限”和“知识库来源”实际配置的时候最重要的是“最小权限 命名空间隔离”。我的习惯是给每个业务线建一个独立的 Agent 配置对应一个只读账号和一组专用的知识库目录。比如销售助手对应agent_sales_read账号知识库路径指向/knowledge/sales_policy供应链助手对应agent_scm_read账号知识库路径指向/knowledge/scm_sop。这样配置有几个好处业务线之间的数据不会互相串味。出了问题排查范围小审计日志也干净。每个 Agent 的提示词和工具描述可以差异化不会越权。配置知识库来源时需要给每个文档集打一个“业务标签”比如“财务口径”“供应链术语”“产品 FAQ”。这些标签会被 Agent 用来判断一个问题到底该查文档还是查库以及查文档时优先命中哪一块内容。标签如果乱起后面 Agent 的召回准确率会肉眼可见地下降。3.3 写出第一条企业级问答并查看执行计划配好之后先在调试面板里试一条最简单的查询问题“上个月华东区销售额排名前五的产品分别是什么”预期行为Agent 从元数据里召回销售明细表、产品维度表。生成类似下面的 SQLSELECT p.product_name, SUM(o.amount) AS total_sales FROM sales_order o JOIN dim_product p ON o.product_id p.product_id WHERE o.region 华东区 AND o.order_date DATE_TRUNC(month, CURRENT_DATE - INTERVAL 1 month) AND o.order_date DATE_TRUNC(month, CURRENT_DATE) GROUP BY p.product_name ORDER BY total_sales DESC LIMIT 5;重点是第二步之后一定要看“执行计划预览”。这是一个容易被新手跳过的环节但恰恰是评估 Agent 是否靠谱的关键。如果执行计划显示这个查询走了全表扫描而销售订单表又是个上亿行的大表那就算 SQL 语法正确实际跑起来也会很慢。好的 Agent 方案会在这个环节给你提示甚至自动改写 SQL 去利用分区裁剪或物化视图。看完执行计划再让 Agent 返回最终自然语言答案“上个月华东区销售额排名前五的产品分别是 A、B、C、D、E其中 A 的销售额为 1.2 亿元占比 18.6%。”注意这里得到的结果是否附带“数据来源说明”也很关键。如果 Agent 只告诉你数字不告诉你统计口径那这个结果在业务会上是没法被采信的。好的产品会在回复中附带类似“数据来源于 sales_order 表按 order_date 统计统计周期为 2025 年 5 月 1 日至 5 月 31 日”的说明。4. 实测中的经验准确率、性能与常见坑4.1 SQL 生成不准的根因大多不在模型很多人把 Text-to-SQL 效果不好归咎于“模型不够聪明”。我实测下来真正的原因往往在数据资产治理上。表和字段注释缺失一张表叫t_order_info_2024字段叫c1、c2、amount模型再强也没法知道c1是客户 ID 还是订单状态。同义不同名业务叫“回款”表里叫“receipt_amount”知识库里叫“到账金额”三套叫法模型如果没关联住生成 SQL 就会漏条件。枚举值无文档比如status字段只有 0、1、2没人告诉模型 1 代表“已发货”模型很容易生成错误的过滤条件。所以我在每一个 Agent 项目里都会先做一轮“元数据补全”。把核心表的字段注释、枚举值说明、常用查询样例整理好挂到 Agent 能够读取的元数据目录里。这个动作带来的准确率提升比换一个更大的模型明显得多。注意不要想着跳过这一步。谁跳过谁上线之后就会在业务方连环追问“为什么这个数不对”的时候补课而且补课的代价是信任流失比技术返工更麻烦。4.2 权限范围设计比接口调用更重要企业级 Agent 和 Demo 级 Agent 的一个本质区别是对“越权查询”的防御力度。在 Demo 阶段你通常只有一个数据库账号Agent 可以查询任何表。但在企业环境里财务同事通过 Agent 问“上个月所有员工的薪资合计”如果这个 Agent 背后挂着全库只读权限那这就是一起数据安全事故。我的建议是权限策略必须落在两个层面第一层数据库账号层。用视图或者行级安全策略把 Agent 可访问的数据范围物理缩小。比如普通业务 Agent 只能访问过滤掉敏感字段的视图工资表、身份证号、手机号字段干脆不授权。第二层Agent 语义层。在提示词和工具描述里明确告知 Agent“你不能查询任何包含薪酬、身份证、发票明细字段的表。”虽然这不是硬隔离但能减少绝大部分误触发。不要指望大模型有“道德感”要默认它就是一个能力很强但没有边界感的实习员工。你给它什么权限它就会用什么权限。4.3 复杂查询的性能兜底怎么做即使 SQL 生成正确性能问题仍然是企业落地的一道坎。尤其是“允许业务人员自由提问”之后你根本猜不到他会问出什么变态问题。有一次我做压测业务人员问“2020 年到现在每一笔退款订单的客户地址都在哪个城市”看起来挺正常生成的 SQL 也没问题但一执行就是一个多小时——因为退款表和地址表都没有按时间做分区实际扫描行数达到了 20 亿。后来我们在代码排查链路里加了两条硬性规则超时熔断任何 SQL 执行超过 30 秒直接终止并返回提示“该问题涉及数据量过大请缩小时间范围或增加筛选条件”。扫描行数告警执行计划预估扫描行数超过 1 亿时自动转人工提示而不是闷头硬跑。这两条规则不是 Agent 产品自动帮你做到的需要在配置层主动打开。如果你的方案没有提供这些开关那就要在 SQL 生成提示词里强制加一句“你必须预估查询代价如果代价过高请主动建议用户缩小范围而不是直接执行。”5. 和自建 RAG 开源编排工具的对比5.1 自研方案的工作量与隐性成本搜索热词里很多人关心“dify 知识库搭建”“n8n 使用 ai agent”“开源知识库”这类方案。这些工具我基本都摸过确实能快速搭出一个 Agent demo。但真要把“知识库 数据库”变成企业级服务自研链路的工作量远超大部分团队的预期。我列一张对比表大家感受一下环节自研/开源拼装方案PolarDB Agent Express 类方案环境搭建需要准备向量库、应用服务、模型 API、任务队列开通即可用数据库侧能力内置Schema 感知自己写元数据同步、表结构定期拉取数据库引擎侧直接读取自然语言转 SQL 调优需要大量 prompt 工程和 SQL 样本积累内置调优链路可用执行计划反馈权限管控自己设计账号体系、数据脱敏逻辑可基于数据库账号和策略做隔离审计追踪自己埋点记录用户提问和 SQL 对应关系通常有原生审计能力运维成本需要持续维护多个开源组件的版本兼容托管形态职责边界更清晰不是说自研不行而是自研有一个经常被低估的问题你不仅要写功能代码还要持续维护一套大模型应用框架的稳定性。模型升级、向量库扩容、召回参数调优、接口超时治理每一项都在消耗研发资源。5.2 什么时候建议直接用 PolarDB Agent Express我的判断标准非常简单满足下面任意两条就该认真考虑这种开箱即用的企业级方案你的数据已经有一部分在云数据库里而且规模不小不太可能为了做 Agent 再重新迁移一套存储。公司对数据安全、权限管控有明确审计要求不能接受“开发人员写死一个万能只读账号”这种粗放做法。团队的核心能力在业务本身而不是在大模型中间件研发上。你们想快速看到业务价值而不是花三个月造一个轮子。需要对接企业微信、钉钉等内部入口希望有更成熟的应用链路支撑。反过来如果你只是为了学习 Agent 原理、做课程设计、跑个人实验那确实没必要上企业级方案自己在本地搭一个开源知识库 SQL Agent 更能练手。6. 企业落地要注意的安全与治理细节6.1 敏感字段与脱敏策略数据库接入 Agent 之后最需要提前想清楚的不是“能查什么”而是“哪些不该被查到”。我见过一个案例某公司给内部员工做了个数据问答助手上线第二天就有人问“去年年终奖最高的部门是哪个”Agent 还真就回答了。技术上没任何毛病SQL 生成正确数据也准确但这件事本身就不该发生。这里有几个经验敏感字段用脱敏视图不要直接在 Agent 后面挂裸表。手机号、身份证号、银行账号这些字段在视图层就做掩码处理。Agent 就算查到了也只能拿到138****1234这种结果。聚合结果也要注意有时候原始字段脱敏了但聚合之后仍然能反推出敏感信息。比如“薪酬最高的员工月薪是多少”这种问题即使不展示员工姓名单个月薪数字也等于点名了。这种情况需要靠语义层的规则去拦截。黑白名单机制对核心业务表设置“允许被 Agent 访问”的白名单白名单之外的表一律拒绝。不要走黑名单因为你列不完所有不该访问的表。6.2 审计与反馈闭环最后想聊聊审计。企业级 AI Agent 和普通 API 接口不一样它的输出是“自然语言结论”但来源却可能是数据库里的敏感数据。一旦业务方看到某个数字提出质疑你必须能回溯到“用户问的是什么 → Agent 生成了哪条 SQL → 数据来源于哪张表 → 最终如何拼装成回答”。所以上线前一定要检查审计日志是否包含以下几部分完整的问题记录。实际执行的 SQL 语句、执行时间、影响行数。调用了哪些知识库文档片段。大模型最终生成的回答原文。用户对回答的反馈点赞/点踩/纠错。这不仅仅是合规要求更是持续优化 Agent 的燃料。我每次排查 Agent 回答不准的 case都是先看审计日志里的 SQL 和知识库召回片段找出是哪个环节断了。没有审计就只能盲猜效果优化根本无从下手。最后再分享一个实际经验别在项目一开始就追求 Agent 全自动完成所有任务。即便 PolarDB Agent Express 这类方案已经封装了很多能力我仍然建议上线初期保留“人审”环节业务结果由 Agent 生成、由数据负责人确认后才推送。跑一两个月积累了足够的正反案例再逐步放开自动化。这样既不会让业务方失去信任也能给 Agent 留出成长空间。数据智能的价值在于稳定复用不在于单次惊艳。 企业级AI Agent实战：PolarDB知识库与数据库融合方案
1. 为什么是“知识库 数据库”的组合出发点与基础场景1.1 知识库与数据库解决的是两种完全不同的问题这两年“AI Agent”这个概念已经快被玩坏了。很多人一上来就搭 Agent第一反应是给模型接一个向量数据库做一套 RAG 知识库觉得能把企业内部文档检索出来就等于“智能”了。但真正跑到生产环境就会发现知识库解决的是“非结构化信息”的查找问题而企业里还有大量高价值数据躺在关系型数据库里——订单、库存、用户画像、财务流水、设备状态这些东西用 RAG 是检索不出来的。你不可能让大模型去“向量化”一张订单表也不应该把客户的资金流水直接丢进 Embedding 模型里切割成块。数据库里的数据是强结构、强约束、强权限的和知识库里的 PDF、Word、内部 Wiki 完全是两套玩法。所以真正企业级的数据智能 Agent必须具备两条腿走路的能力一条腿检索知识库里的文档规则、产品说明、历史案例另一条腿直接查数据库里的实时业务数据。两条腿缺一条这个 Agent 都只能停在“演示阶段”。1.2 哪些业务场景真正需要这类 Agent结合我实际接触过的落地项目下面这几类场景是最典型的“知识库 数据库”双打场景工单智能助手客服提问“这个订单为什么还没发货”Agent 需要从知识库检索发货规则和异常处理 SOP同时去订单系统数据库查询该订单当前的物流状态、是否拆单、是否命中拦截策略。运维诊断助手用户反馈“昨晚大促之后接口变慢了”Agent 需要查数据库里的慢查询记录、链路追踪表、机器负载指标再结合知识库中的历史故障复盘文档给出诊断建议。企业内部门户问答“今年 Q3 华东区的回款率是多少”“跟去年同期比怎么样”这类问题基本 100% 需要实时查库附带的知识库只是用来补充统计口径和业务术语解释。数据报表自助化业务人员不懂 SQL但想知道“上个月新增的 VIP 用户里哪个行业的转化率最高”Agent 直接改写为多条 SQL 去数据仓库取数再结合报表使用规范文档生成结论。这些场景有一个共同特征答案必须是“当前时刻”的真实数据不能靠模型幻觉编造也不能靠文档快照。这也决定了架构上必须把数据库作为一等公民接入而不是把表格导出成 PDF 丢进知识库敷衍了事。2. PolarDB Agent Express 的核心拆解它到底封装了什么2.1 开箱即用不等于黑盒我第一次看到“PolarDB Agent Express”这个产品名的时候第一反应是警惕市面上叫 Agent 的壳子太多了很多其实就是套了个提示词模板跑通一个 ChatPDF 就说自己是企业级智能体。但仔细拆开来看这类方案的价值不在于“模型有多大”而在于它把几个非常难做的工程问题以服务化的方式解决了。PolarDB 本身就是云原生数据库而 Agent Express 在其上提供的核心能力可以理解为“长在数据库旁边的 AI 代理层”。它不是一个独立的通用 Agent 平台而是围绕数据库访问、自然语言转 SQL、权限隔离、执行审计这一串链路做了深度封装。用的时候你不需要自己维护一套向量库、不需要自己写 Function Calling 的解析逻辑、不需要从零搭建“模型调用 → 工具调用 → 结果返回”的 Agent 循环。这些环节在平台内部已经形成了一个相对稳定的运行框架。2.2 自然语言转 SQL 的执行链路自然语言转 SQL这个方向学术界做了很多年以前效果一直不太理想原因是模型对数据库 schema 的感知能力太弱稍微复杂一点的表关系就晕。Agent Express 这类产品解决这个问题的方式是把“schema 感知”和“样本增强”整合进了执行链路。一条中文问题进来之后大致会走这样一条链路意图识别与问题改写判断用户是想查数据、写数据还是想基于文档回答问题。Schema 召回根据问题语义先从元数据里召回相关的表、字段、索引、外键关系而不是把整个库几百张表全部塞给模型。SQL 生成基于召回的表结构、字段注释、枚举值、历史查询样本生成候选 SQL。语义校验对生成的 SQL 做合法性检查比如字段是否存在、表是否被权限策略禁止访问、是否包含明显的全表扫描。执行与解释通过受控数据库账号执行查询拿到结果集之后再做一次自然语言总结。链路本身其实就是标准 Text-to-SQL 架构但工程难点在第二步和第四步。Schema 召回如果做不好模型会在浩瀚的表结构里迷失语义校验如果做不好一条“误伤”的 SQL 可能直接把生产库拖垮。Agent Express 的优势是这些规则已经内置在数据库引擎的周边可以和数据库的会话管理、资源组、执行计划分析直接打通。提示使用这类方案时不要一上来就问特别复杂的关联查询。先把单表查询、聚合查询跑通再逐步挑战多表 Join。这个顺序能帮你快速判断产品内置的 Schema 理解能力到底在哪一层。2.3 知识库检索和数据库查询的协同方式这个是我认为最有价值的部分。单纯做 RAG 的 Agent 很多单纯做 Text-to-SQL 的 Agent 也不少但真正难的是让两者在同一次问答中协作。举个例子用户问“帮我查一下华东区销售额 TOP10 的客户并告诉我他们对账周期一般是怎么约定的。”这个问题分成两半“华东区销售额 TOP10 客户”需要查订单表、客户表是实时的结构化查询。“对账周期一般怎么约定”这是一种业务规则通常写在销售管理制度文档里属于知识库检索。如果这两半是分开的两个工具Agent 必须先判断先调哪个、后调哪个再把两部分结果拼装成最终答案。如果协同不好就会出现“查了数据但解释规则是错的”或者“搬来文档但数据对不上”的割裂感。好的方案会在内部把知识库和数据库查询当成同一套的“工具路由”先通过知识库检索确定业务口径再用业务口径去约束 SQL 生成最后把查询结果结合文档依据一起返回。这个“以知识定口径、以数据库出数据、以模型做解读”的串行逻辑是落地效果的关键。3. 一次完整的落地过程从配置到跑通一次问答3.1 前置环境与开通既然是云数据库方案第一步自然是开通 PolarDB 实例并且确认你使用的版本支持 Agent Express 服务。这里我不展开具体的控制台点击路径因为控制台 UI 迭代很快重点讲清楚开通时容易被忽略的几个前置条件数据库账号的权限规划给 Agent 专用的账号不要直接用管理员账号。这个账号应该只拥有查询权限以及能够访问 Agent 所需元数据的权限。如果后续要让 Agent 做写操作也需要单独立一条审批策略而不是放开 UPDATE 和 DELETE。知识库的数据源格式Agent Express 对接知识库时通常需要准备好文档存储位置支持常见的 PDF、Word、Markdown、TXT。建议文档里不要堆大段无关的页眉页脚解析效果会好很多。网络访问链路如果你还要把 Agent 接入企业微信、钉钉、飞书或者内部 OA确认这些入口和 PolarDB 服务之间的网络策略是通的。很多项目最后卡在“Agent 问答没问题但接不到 IM 机器人回调”这种环节。3.2 给 Agent 配“数据库权限”和“知识库来源”实际配置的时候最重要的是“最小权限 命名空间隔离”。我的习惯是给每个业务线建一个独立的 Agent 配置对应一个只读账号和一组专用的知识库目录。比如销售助手对应agent_sales_read账号知识库路径指向/knowledge/sales_policy供应链助手对应agent_scm_read账号知识库路径指向/knowledge/scm_sop。这样配置有几个好处业务线之间的数据不会互相串味。出了问题排查范围小审计日志也干净。每个 Agent 的提示词和工具描述可以差异化不会越权。配置知识库来源时需要给每个文档集打一个“业务标签”比如“财务口径”“供应链术语”“产品 FAQ”。这些标签会被 Agent 用来判断一个问题到底该查文档还是查库以及查文档时优先命中哪一块内容。标签如果乱起后面 Agent 的召回准确率会肉眼可见地下降。3.3 写出第一条企业级问答并查看执行计划配好之后先在调试面板里试一条最简单的查询问题“上个月华东区销售额排名前五的产品分别是什么”预期行为Agent 从元数据里召回销售明细表、产品维度表。生成类似下面的 SQLSELECT p.product_name, SUM(o.amount) AS total_sales FROM sales_order o JOIN dim_product p ON o.product_id p.product_id WHERE o.region 华东区 AND o.order_date DATE_TRUNC(month, CURRENT_DATE - INTERVAL 1 month) AND o.order_date DATE_TRUNC(month, CURRENT_DATE) GROUP BY p.product_name ORDER BY total_sales DESC LIMIT 5;重点是第二步之后一定要看“执行计划预览”。这是一个容易被新手跳过的环节但恰恰是评估 Agent 是否靠谱的关键。如果执行计划显示这个查询走了全表扫描而销售订单表又是个上亿行的大表那就算 SQL 语法正确实际跑起来也会很慢。好的 Agent 方案会在这个环节给你提示甚至自动改写 SQL 去利用分区裁剪或物化视图。看完执行计划再让 Agent 返回最终自然语言答案“上个月华东区销售额排名前五的产品分别是 A、B、C、D、E其中 A 的销售额为 1.2 亿元占比 18.6%。”注意这里得到的结果是否附带“数据来源说明”也很关键。如果 Agent 只告诉你数字不告诉你统计口径那这个结果在业务会上是没法被采信的。好的产品会在回复中附带类似“数据来源于 sales_order 表按 order_date 统计统计周期为 2025 年 5 月 1 日至 5 月 31 日”的说明。4. 实测中的经验准确率、性能与常见坑4.1 SQL 生成不准的根因大多不在模型很多人把 Text-to-SQL 效果不好归咎于“模型不够聪明”。我实测下来真正的原因往往在数据资产治理上。表和字段注释缺失一张表叫t_order_info_2024字段叫c1、c2、amount模型再强也没法知道c1是客户 ID 还是订单状态。同义不同名业务叫“回款”表里叫“receipt_amount”知识库里叫“到账金额”三套叫法模型如果没关联住生成 SQL 就会漏条件。枚举值无文档比如status字段只有 0、1、2没人告诉模型 1 代表“已发货”模型很容易生成错误的过滤条件。所以我在每一个 Agent 项目里都会先做一轮“元数据补全”。把核心表的字段注释、枚举值说明、常用查询样例整理好挂到 Agent 能够读取的元数据目录里。这个动作带来的准确率提升比换一个更大的模型明显得多。注意不要想着跳过这一步。谁跳过谁上线之后就会在业务方连环追问“为什么这个数不对”的时候补课而且补课的代价是信任流失比技术返工更麻烦。4.2 权限范围设计比接口调用更重要企业级 Agent 和 Demo 级 Agent 的一个本质区别是对“越权查询”的防御力度。在 Demo 阶段你通常只有一个数据库账号Agent 可以查询任何表。但在企业环境里财务同事通过 Agent 问“上个月所有员工的薪资合计”如果这个 Agent 背后挂着全库只读权限那这就是一起数据安全事故。我的建议是权限策略必须落在两个层面第一层数据库账号层。用视图或者行级安全策略把 Agent 可访问的数据范围物理缩小。比如普通业务 Agent 只能访问过滤掉敏感字段的视图工资表、身份证号、手机号字段干脆不授权。第二层Agent 语义层。在提示词和工具描述里明确告知 Agent“你不能查询任何包含薪酬、身份证、发票明细字段的表。”虽然这不是硬隔离但能减少绝大部分误触发。不要指望大模型有“道德感”要默认它就是一个能力很强但没有边界感的实习员工。你给它什么权限它就会用什么权限。4.3 复杂查询的性能兜底怎么做即使 SQL 生成正确性能问题仍然是企业落地的一道坎。尤其是“允许业务人员自由提问”之后你根本猜不到他会问出什么变态问题。有一次我做压测业务人员问“2020 年到现在每一笔退款订单的客户地址都在哪个城市”看起来挺正常生成的 SQL 也没问题但一执行就是一个多小时——因为退款表和地址表都没有按时间做分区实际扫描行数达到了 20 亿。后来我们在代码排查链路里加了两条硬性规则超时熔断任何 SQL 执行超过 30 秒直接终止并返回提示“该问题涉及数据量过大请缩小时间范围或增加筛选条件”。扫描行数告警执行计划预估扫描行数超过 1 亿时自动转人工提示而不是闷头硬跑。这两条规则不是 Agent 产品自动帮你做到的需要在配置层主动打开。如果你的方案没有提供这些开关那就要在 SQL 生成提示词里强制加一句“你必须预估查询代价如果代价过高请主动建议用户缩小范围而不是直接执行。”5. 和自建 RAG 开源编排工具的对比5.1 自研方案的工作量与隐性成本搜索热词里很多人关心“dify 知识库搭建”“n8n 使用 ai agent”“开源知识库”这类方案。这些工具我基本都摸过确实能快速搭出一个 Agent demo。但真要把“知识库 数据库”变成企业级服务自研链路的工作量远超大部分团队的预期。我列一张对比表大家感受一下环节自研/开源拼装方案PolarDB Agent Express 类方案环境搭建需要准备向量库、应用服务、模型 API、任务队列开通即可用数据库侧能力内置Schema 感知自己写元数据同步、表结构定期拉取数据库引擎侧直接读取自然语言转 SQL 调优需要大量 prompt 工程和 SQL 样本积累内置调优链路可用执行计划反馈权限管控自己设计账号体系、数据脱敏逻辑可基于数据库账号和策略做隔离审计追踪自己埋点记录用户提问和 SQL 对应关系通常有原生审计能力运维成本需要持续维护多个开源组件的版本兼容托管形态职责边界更清晰不是说自研不行而是自研有一个经常被低估的问题你不仅要写功能代码还要持续维护一套大模型应用框架的稳定性。模型升级、向量库扩容、召回参数调优、接口超时治理每一项都在消耗研发资源。5.2 什么时候建议直接用 PolarDB Agent Express我的判断标准非常简单满足下面任意两条就该认真考虑这种开箱即用的企业级方案你的数据已经有一部分在云数据库里而且规模不小不太可能为了做 Agent 再重新迁移一套存储。公司对数据安全、权限管控有明确审计要求不能接受“开发人员写死一个万能只读账号”这种粗放做法。团队的核心能力在业务本身而不是在大模型中间件研发上。你们想快速看到业务价值而不是花三个月造一个轮子。需要对接企业微信、钉钉等内部入口希望有更成熟的应用链路支撑。反过来如果你只是为了学习 Agent 原理、做课程设计、跑个人实验那确实没必要上企业级方案自己在本地搭一个开源知识库 SQL Agent 更能练手。6. 企业落地要注意的安全与治理细节6.1 敏感字段与脱敏策略数据库接入 Agent 之后最需要提前想清楚的不是“能查什么”而是“哪些不该被查到”。我见过一个案例某公司给内部员工做了个数据问答助手上线第二天就有人问“去年年终奖最高的部门是哪个”Agent 还真就回答了。技术上没任何毛病SQL 生成正确数据也准确但这件事本身就不该发生。这里有几个经验敏感字段用脱敏视图不要直接在 Agent 后面挂裸表。手机号、身份证号、银行账号这些字段在视图层就做掩码处理。Agent 就算查到了也只能拿到138****1234这种结果。聚合结果也要注意有时候原始字段脱敏了但聚合之后仍然能反推出敏感信息。比如“薪酬最高的员工月薪是多少”这种问题即使不展示员工姓名单个月薪数字也等于点名了。这种情况需要靠语义层的规则去拦截。黑白名单机制对核心业务表设置“允许被 Agent 访问”的白名单白名单之外的表一律拒绝。不要走黑名单因为你列不完所有不该访问的表。6.2 审计与反馈闭环最后想聊聊审计。企业级 AI Agent 和普通 API 接口不一样它的输出是“自然语言结论”但来源却可能是数据库里的敏感数据。一旦业务方看到某个数字提出质疑你必须能回溯到“用户问的是什么 → Agent 生成了哪条 SQL → 数据来源于哪张表 → 最终如何拼装成回答”。所以上线前一定要检查审计日志是否包含以下几部分完整的问题记录。实际执行的 SQL 语句、执行时间、影响行数。调用了哪些知识库文档片段。大模型最终生成的回答原文。用户对回答的反馈点赞/点踩/纠错。这不仅仅是合规要求更是持续优化 Agent 的燃料。我每次排查 Agent 回答不准的 case都是先看审计日志里的 SQL 和知识库召回片段找出是哪个环节断了。没有审计就只能盲猜效果优化根本无从下手。最后再分享一个实际经验别在项目一开始就追求 Agent 全自动完成所有任务。即便 PolarDB Agent Express 这类方案已经封装了很多能力我仍然建议上线初期保留“人审”环节业务结果由 Agent 生成、由数据负责人确认后才推送。跑一两个月积累了足够的正反案例再逐步放开自动化。这样既不会让业务方失去信任也能给 Agent 留出成长空间。数据智能的价值在于稳定复用不在于单次惊艳。