把大模型智能体直接接到生产 Iceberg 湖仓上，最先爆掉的不是回答准确率，是账单和权限。一张 50TB 以上的表，模型生成一条未分区或多路交叉连接的 SQL，几秒内就能烧掉数百美元的扫描费。更隐蔽的是模式漂移：Iceberg 把逻辑表结构与物理分区规格分开管理，写死在提示词里的模式信息很快过时，模型会编造不存在的分区列，或者完全错过分区裁剪。语义误判再往前一步，就可能发出破坏性的 DDL、DML。靠更长的系统提示解决不了这些问题，唯一可行的是把智能体放进确定性执行框架。
第一层：运行时探查元数据
模式漂移的对策是把表结构从提示词里搬出来，变成运行时工具。智能体每次查询前访问 Iceberg REST 目录，读取当前活跃的表结构、列类型、聚簇键和物理分区变换。这一层只读目录元数据、不碰数据文件，成本可以忽略，但换来了模式信息永远来自真实系统——表怎么演进、分区策略怎么改，模型拿到的是当下真值而非昨天的快照。
实现上有个细节：探查工具必须返回结构化的分区变换信息，而不是只给列名。只报列名的话，模型仍然会拿普通列当分区列用，裁剪照样失效。
第二层：AST 检查加零成本干跑
生成的 SQL 先过抽象语法树检查：只放行 SELECT 类查询，拒绝子查询里藏着的修改操作和管理命令。AST 规则要覆盖 DDL 和 DML 的各类变体，只检查语句开头的关键字是不够的，包裹在子查询或 CTE 里的写操作照样能漏。
AST 通过后交给执行引擎的干跑接口编译，拿到预计扫描字节数，低于预算才放行。干跑的关键价值是不产生计算费用，却在计费发生前给出确定的估算——等于给模型一个可验证的自纠正信号。预算按场景定档，探索性查询限制在几百 MB 以内是常见起点。阈值设太紧，简单查询也会被反复拒绝拖垮可用性；设太松，防护形同虚设。
第三层：受限执行兜底
获批查询通过向量化读取器直连存储执行，返回结果限制在可控范围，执行层再设一道作业级计费上限。即便前两层出现疏漏，这层也能兜住最坏情况。两层独立防线的配合关系要想清楚：干跑预算是事前估算，计费上限是执行中的硬顶，两者数值要有差距，否则估算误差会直接触发硬顶报错。
一次完整的自纠正轨迹
典型执行过程长这样：用户要分析某张大表，模型首轮 SQL 没加分区过滤，干跑返回拒绝和估算字节数；模型读取目录元数据，补上分区条件，再次干跑通过，查询才真正执行。全程无人介入，成本边界由代码保证。模型在这里只做两件事——理解问题、根据预算反馈重写 SQL；记住表结构和判断语句安全性都是确定性代码的职责。
分工的本质是约束位置的差异：提示词能降低出错概率，但提供不了数学上可验证的边界。AST 保证只读，干跑保证扫描上限，目录探查保证模式真值，三者叠加自主智能体才具备生产可运维性。上线的验收可以照着执行轨迹验收：构造三条用例——无分区过滤的大表查询应被拒、改写后应通过、含子查询写操作的语句应在 AST 层拦截。三条都过，再谈智能体能力，顺序不能反。
评论0