AI查湖仓如何不闯祸？三层防护设计

把大模型智能体直接接到生产Iceberg湖仓上，最先暴露的问题往往不是回答不准，而是账单和权限。一张50TB以上的表，模型若生成未分区或多路交叉连接的SQL，几秒内就能触发数百美元的扫描费用。更隐蔽的是，Iceberg把逻辑表结构与物理分区规格分开管理，静态提示词里的模式信息很快过时，模型会编造不存在的分区列，或者完全错过分区裁剪。此外，语义误判还可能让模型发出非幂等甚至破坏性的DDL、DML语句。

这些风险无法靠更长的系统提示消除。可行的做法是把智能体放进一个确定性执行框架，让它不直接接触物理数据文件，也不把未经审查的SQL发给存储引擎。我采用的设计分为三层：运行时探查元数据、静态AST与零成本干跑校验、受控的向量化读取执行。

第一层解决模式漂移。智能体在运行时访问BigLake Iceberg REST目录，读取当前活跃的表结构、列类型、聚簇键和物理分区变换。把这些信息作为工具返回给模型，而不是写死在提示词里。Iceberg表会持续演进，分区策略也可能变化，每次查询前重新探查才能避免模型基于旧结构生成SQL。这一层只读取目录元数据，不扫描数据文件，成本可以忽略。

第二层是安全与成本闸门。生成的SQL先经过SQLGlot的抽象语法树遍历，只允许SELECT类查询，拒绝子查询中的修改操作和管理命令。AST检查通过后，再把语句交给BigQuery的零成本干跑接口编译，得到预计扫描字节数。只有低于设定预算的查询才被放行。这一步的关键在于，干跑不产生计算费用，却能在计费发生前给出确定的字节估算，等于为智能体提供了一个可验证的自纠正信号。预算可以按场景设定，例如对探索性查询限制在几百MB以内。

第三层执行同样保留约束。获批的查询通过BigLake的向量化Parquet读取器直接在Cloud Storage上执行，返回结果被限制在可控范围内。执行层还会设置作业级计费上限，作为纵深防御。即便前两层出现疏漏，这一层也能兜住最坏情况。

三层工具通过Gemini 2.5 Flash的函数调用绑定到智能体循环中。模型负责理解问题、选择工具、根据干跑返回的字节数调整SQL；确定性代码负责边界。二者分工明确：模型不需要记住表结构，也不需要判断查询是否安全，它只需要在收到预算超限的反馈后重写查询。

一个典型的执行轨迹是这样的：用户要求分析某张大表，模型首轮生成的查询因未加分区过滤，干跑估算扫描量远超预算，工具返回拒绝及估算字节数；模型读取目录元数据后补上分区条件，再次干跑通过，查询才被真正执行。整个过程没有人工介入，成本边界由代码保证。

与直接让大模型对湖仓执行SQL相比，这种架构的差别不在模型能力，而在约束位置。提示词工程可以降低出错概率，但无法提供数学上可验证的边界。AST解析保证语句只读，干跑保证扫描量有上限，目录探查保证模式信息来自真实系统。三者叠加，才让自主智能体在生产湖仓上具备可运维性。

实践中有几点值得注意。元数据探查工具应返回结构化的分区变换信息，而不仅是列名，否则模型仍可能误用分区。干跑预算不宜设得过紧，否则简单查询也会被反复拒绝，影响可用性；也不宜过松，失去防护意义。AST规则需要覆盖DDL和DML的各类变体，不能只检查语句开头。执行层的计费上限应与干跑预算配合，形成两层独立防线。

这套架构并不追求让模型更聪明，而是把不可控的生成行为放进可控的执行路径。对于任何准备把自主智能体接入Iceberg湖仓的团队，先建好这三层约束，再谈智能体能力，顺序不能反。