AI 问数上线前，评审表里通常有一项：“数据库使用只读账号。”
打勾以后，大家会松一口气。
只读账号确实防住了删表和改数，却防不住另一些更安静的事：一条 SQL 扫 8 TB；一个问题重试 20 次；10 个 Agent 同时探索相似假设；用户已经关闭页面，查询还在后台跑。
这些事不会把数据写坏，却会把队列、预算和同事的耐心一起占满。
所以，生产级 AI 问数需要的不只是一张权限清单，还需要一套任务预算。每次自然语言问题进来，都要知道它最多可以花多少钱、跑多久、试几次，以及什么时候必须停。
第一层：先给“任务”预算，不要只限制单条 SQL
传统查询治理常按单条 SQL 设置超时和扫描限制。对 Agent 来说还不够，因为一次用户任务可能产生很多条都在限制以内的查询。
建议同时设置三层预算。
单条查询预算
- 最大执行时间；
- 最大扫描字节数；
- 最大返回行数；
- 最大内存或计算配额；
- 禁止的语句与数据源。
单次任务预算
- 最多生成和执行多少条 SQL；
- 最多允许多少次失败重试；
- 累计扫描量上限；
- 累计执行时间上限；
- 最多同时运行多少个分支。
用户与服务预算
- 单个用户每小时任务数；
- 单个部门或应用的日预算；
- 整个 AI 查询服务的并发和资源池；
- 达到阈值后的降级策略。
三层预算解决三个不同问题。单条预算防“大象查询”，任务预算防“蚂蚁搬家”，服务预算防所有人同时来问。
第二层：执行前先估价
Agent 生成 SQL 后，不要立刻送进生产引擎。
先做一轮静态检查和查询估价：
- 解析 SQL，确认只包含允许的语句；
- 检查涉及的表、字段和时间范围；
- 获取查询计划或引擎估算；
- 计算预计扫描量、分区数量和可能的连接风险；
- 根据任务剩余预算决定执行、改写或拒绝。
如果预计成本高，可以把反馈交还给 Agent：时间范围过大、缺少分区条件、连接会产生大规模数据交换、应该先查聚合表。
关键是返回可行动的信息。只说“查询太贵”，模型只能换一种猜法；告诉它“当前扫描 24 个月明细，请先限定到 30 天或使用月汇总表”，它才有机会做对。
