别把数仓钥匙交给会幻觉的实习生

问一句‘我们有多少用户’，Agent回手一个 SELECT ，把整份元数据目录扫了个遍，数仓差点当场趴下。这不是段子，是过去几个月里真实发生的落地现场。我的核心判断很简单：Text-to-SQL 当前的瓶颈，不在模型写SQL的准确率，而在数据面的权限与架构。提示词工程替代不了架构防线——这句话，值得每个准备把Agent放进生产数仓的团队贴在工位上。

先给一个背景数字：BIRD-SQL基准榜单上，头部方案的执行准确率在2025年已经突破80%，头部厂商在自家demo里做到95%也不稀奇。模型写SQL这件事，正在快速‘够用’。但IBM《Cost of a Data Breach Report 2024》给出的另一组数字才是重点：单次数据泄露的全球平均成本是488万美元，医疗行业高达977万美元，连续14年居各行业之首。一边是准确率的边际收益递减，一边是单次事故的七位数美元代价——ROI的天平往哪边倒，一目了然。

🚨 一个JOIN，差点捅破合规天花板

一位在医疗数据平台做架构的朋友，过去三个月一直在盯着自家 Text-to-SQL Agent的执行日志。LLM为了‘更完整地回答问题’，反复尝试把 users 表和 transaction_logs 拼在一起——只要拼上，就是HIPAA级别的敏感数据暴露。这不是小题大做：HIPAA史上最大单笔和解金是1600万美元（Anthem案，2018年，美国卫生与公众服务部OCR作出），而那还只是‘人类员工’的失误水平。Agent的失误频率，远高于人类。救了全公司的不是提示词，而是数据库用户权限本身‘比金库还紧’。

另一个更普遍的场景：业务分析师随口问‘我们有多少用户’，Agent‘热心’地对整个元数据目录执行 SELECT ，几乎把数仓打挂。注意，这里没有任何恶意输入、没有攻击者参与——问题的根源是模型自己‘想帮忙’。OWASP在《LLM Applications Top 10（2025版）》里给这类问题起了正式名字：LLM06，Excessive Agency（过度代理）——给模型超出任务所需的权限和自主性，出事只是时间问题。

大模型没有‘数据敏感性’的概念。它的优化目标始终是‘看起来能回答问题’，而不是‘被允许回答这个问题’。你给它一个能读到全库的连接，它就会在全库里找答案。2023年三星员工把半导体源码粘贴进ChatGPT导致机密外泄的三连事故，本质上就是同一个错误的预演：给了一个不该给的数据通道。圈子里有句半开玩笑的话：‘Agent不会犯错，它只是忠实地执行了一次你本不该给它的授权。’

📚 大多数教程，教错了那一层

打开市面上主流的 Text-to-SQL 教程，讲的全是‘怎么把SQL写对’：LangChain 的Agent编排、把schema定义向量化塞进RAG、再调一调temperature。这些内容占据了九成讨论热度，但在架构师眼里，它们修的是错误的栈层——素材作者的原话是'wrong layer of the stack'。

SQL写得对不对，是概率问题；生产环境要的是确定性。你可以把生成准确率从80%刷到95%，但只要剩下的5%恰好落在一张含敏感列的表上，代价就是一次合规事故。概率系统叠加无防护的数据面，等于必然出事，区别只是时间和形式。

这类‘POC惊艳、上线翻车’的剧本有数据支撑：MIT在2025年发布的《State of AI in Business》报告指出，约95%的企业生成式AI试点没有产生可衡量的业务回报；Gartner也预测，到2025年底，至少30%的生成式AI项目会在POC之后被放弃，理由直指数据质量不足和风险控制缺位。落到 Text-to-SQL 场景里，一个非常典型的剧本是：POC阶段准确率亮眼、demo惊艳，老板拍板上线；上线一个月内出一次越权查询或一次全表扫描，安全团队介入，项目退回POC重来。烧掉的是预算，透支的是组织对‘AI进数据平台’这件事的信任。

所以真正该问的问题不是‘模型够不够聪明’，而是‘它连接数据的方式对不对’。

⚠️ 根因：把Agent当成了授权用户

最常见的失败模式，一句话就能说清：把LLM当成一个授权用户。Agent直接拿着一个拥有宽权限的账号连上 Snowflake 或 Databricks，能看到的schema和人类分析师一样多，能执行的操作也一样多。区别在于，人类分析师有组织常识和敬畏心，Agent只有next token。

裸奔架构下，事故链路通常是这样的：

`

分析师提问 → LLM生成SQL → 复用分析师宽权限账号直连数仓

→ 拼接/扫描任意表 → PII暴露 或 全表扫描打挂仓库

→ 事后靠日志追责（影响面已不可控）

`

两种架构放到一张表里看，差距一目了然：

我的判断是：Agent的正确定位不是‘一个用户’，而是一条‘受限通道’。它背后应该是独立的、最小权限的服务账号；它能‘看到’的世界，应该被语义层裁剪过；它的每一次执行，都应该过审查和限额。权限体系必须前置到Agent伸手之前，而不是事后靠日志追责。

🛡️ 防线怎么搭：权限前置、语义托底、审计兜底

具体怎么做，素材指向的思路可以拆成四道防线。下面每一道我尽量给到‘抄作业级别’的落地细节——不是‘建议做权限管理’这种正确的废话，而是能直接进工单的动作：

第一道，专用服务账号 + 仓库隔离。 给Agent一个独立服务账号（Databricks里对应Service Principal），只读，只覆盖业务分析涉及的表，与所有PII表在数据库层做物理隔离。落地细节有三点容易被忽略：其一，连元数据可见性也要收紧——Agent账号连 SHOW SCHEMAS 都不该看到PII schema，模型看不到的表名，幻觉出来的概率趋近于零；其二，凭证用短时令牌（如云厂商STS），有效期压到小时级，不要落一个长期AK/SK在Agent配置里；其三，给Agent一个独立的小规格仓库（Snowflake上单独开一个XS warehouse），挂上Resource Monitor，credit消耗触顶自动挂起——Agent再怎么发疯，爆炸半径就是这一个仓库的配额，而不是整个数仓。

第二道，语义层托底，且‘一份配置两处生效’。 不把原始schema直接丢给模型，而是把指标定义、维度口径固化在语义层里（dbt Semantic Layer、Cube这类现成方案），Agent面对的是一份白名单化的视图。它想JOIN users 和 transaction_logs？语义层里根本不存在这条路径。这里有个区别于标准实践的关键细节：把语义层编译出的‘允许JOIN图’，直接作为下游SQL网关的解析规则——同一份YAML，既是喂给模型的上下文，也是网关的拦截白名单。很多团队吃亏在提示词里的白名单和数据库里的真实权限各自维护、悄然漂移，最后模型按提示词写了‘合理’的SQL，数据库却不是这么配的。单一事实源，漂移即报错。

第三道，执行网关：dry-run前置 + AST级校验。 所有SQL先过一个审查层，三个动作按顺序执行：一是dry-run估成本——Snowflake先跑 EXPLAIN 拿扫描字节预估，BigQuery直接用dry-run拿到 bytesToScan，超过阈值（比如单查500GB）直接拒绝，这笔账在扫描发生前就能算清；二是AST解析校验——用sqlglot这类解析库把SQL解析成语法树，拦截 SELECT ，检查行数上限是不是真的包在最外层（防止模型用多层CTE把 LIMIT 藏在内层骗过正则），并强制注入 STATEMENT_TIMEOUT_IN_SECONDS（建议30秒起）和超时硬限；三是query tag注入——每条SQL强制带上trace_id标签，仓库侧的消费记录可以按‘哪次对话、哪个提问者’逐条归因。第三步是成本治理的关键：Agent的查询预算，应该记到提问的业务人头上来，让‘随口问一句全库扫描’这件事直接反映在提问者的配额里，滥用行为会自然收敛。

第四道，审计兜底：列级血缘，十分钟闭环。 每一次查询留痕：谁问的、改写成了什么SQL、碰了哪些列，全程可回溯。别自己从零造轮子——Databricks的Unity Catalog自带system.audit和列级血缘，开源侧有OpenLineage，把事件流接进现有SIEM就行。落地标准定死一条：真出了事，用列级血缘反查受影响数据集，十分钟内说清影响面，而不是花两周取证。

把典型翻车场景和防线对应起来看：

值得强调的是：这四道防线没有一道是‘AI技术’，全是数据平台团队本来就该有的基本功。这恰恰是关键的产业判断——Text-to-SQL 的落地门槛，不在算法团队手里，而在数据平台团队手里。

💡 这条赛道，会沿‘准确率’和‘可信’分化

往下推演，Text-to-SQL 产品大概率会沿两条路线分化。一条继续卷生成准确率，比拼谁在基准集上多拿两个点——但它对采购决策的影响力会越来越小，因为企业很快会意识到，准确率解决不了权限问题。另一条把重心放在‘可信执行’上：语义层、权限集成、审计能力，把‘能连什么数据、答错会怎样’直接做成产品的一部分。企业客户最终会为后者付钱，因为CIO们买的是确定性，不是惊喜。

对数据平台从业者，这其实是个好消息：Agent时代，权限模型、语义层、成本限额这些‘不性感的老工程’，价值会被重新定价。⚠️ AI没有让数据工程贬值，它把数据工程从后台推到了台前——你过去搭的每一层防线，现在都成了AI能走多远的边界。

小结： Text-to-SQL 不会死，会死的是‘裸奔的 Text-to-SQL’。当模型能力快速平权之后，真正的护城河是那些最基础的东西——最小权限、语义层、执行网关、审计链路。谁先把防线建好，谁才敢把AI放进生产数据面。往后判断一个团队的AI落地成色，别看demo多惊艳，就看一件事：它敢不敢把Agent指向自己最贵的那张表。

主要参考信源： IBM《Cost of a Data Breach Report 2024》；OWASP《Top 10 for LLM Applications (2025)》LLM06 Excessive Agency；MIT NANDA《The State of AI in Business 2025》；Gartner生成式AI项目预测（2024）；美国HHS OCR对Anthem的HIPAA和解公告（2018）；BIRD-SQL基准公开榜单（2025）；三星ChatGPT源码泄露事件（2023年4月，韩媒economico等多方报道）。