下午三点，群里有人问：“为什么华东区咖啡销量下降了？”
一个分析师会先确认时间范围，再看渠道、门店和商品。查两三张表，发现定义不一致，可能还要回群里问一句。
一个 Agent 不一定会停下来。
它可以同时尝试按城市、门店、渠道、商品、用户群和促销活动拆解，再换几种连接方式，验证不同假设。每条路都像有道理，每条路都能生成 SQL。
最后，它给你一段很像样的解释。
数据库在背后跑了多少次，没人问。
Agent 不是更快的人类分析师
Berkeley BAIR 最近讨论了一种新的数据库工作负载：Agent 查询数据时，不像人，也不像传统 BI 工具。
人会因为疲劳和时间停下来。Agent 可以并行探索大量假设。BAIR 把这种行为称为“agentic speculation”，可以理解为 Agent 为了找到答案，大量试探不同查询方案。
一项高层任务，例如“为什么销量下降”或“哪些用户可能流失”，会展开成组合数量很大的连接、聚合和筛选。单个用户请求可能触发上千条 SQL。
更有意思的是，BAIR 提到的多 Agent Text-to-SQL 实验里，只有约 10%–20% 的子计划真正不同。也就是说，大量查询在做重复工作。
重复并非完全没用。多个 Agent 走不同路径，可以提高找到正确答案的概率。问题是，模型的成功率提高了，计算账单和数据库压力也一起提高了。
Demo 里看不到查询风暴
AI 问数 Demo 通常很安静。
准备一套规模不大的样例数据，问一句自然语言，屏幕上出现 SQL、图表和解释。大家关注的是答案像不像、界面顺不顺。
到了生产环境，问题会变得粗糙：
- 同时有几十个人提问；
- 每个问题会多轮澄清和重试；
- Agent 会探索多个表和多种连接；
- 错误的 SQL 可能扫描大量历史数据；
- 用户关掉页面后，后台查询仍在继续；
- 不同 Agent 可能重复计算相同中间结果。
一条查询慢，不难发现。上百条“都不算特别慢”的查询同时涌进来，反而更麻烦。
如果监控仍然只按数据库账号统计，你甚至可能只看见一个名为 ai_service 的用户突然变得很忙，却不知道是哪次提问触发了这些查询。
别只给 Agent 一个能连库的账号
很多团队做第一版 AI 问数时，会创建一个只读账号，然后认为安全问题解决了。
只读当然重要。它能防止 Agent 修改生产数据，却防不住一条只读 SQL 扫完整个仓库，也防不住 1000 条只读 SQL 同时运行。
“不会改数据”和“不会拖垮系统”是两回事。
至少还要为 Agent 增加四类边界：
- 并发边界：单个用户、单次任务和整个服务最多同时运行多少查询；
- 资源边界：扫描量、执行时间、内存和队列优先级；
- 范围边界：允许访问哪些表、哪些时间窗口、哪些聚合层；
- 生命周期边界：用户取消、页面关闭或上游任务失败后，查询是否一起停止。
这些限制不能只写在 Prompt 里。Prompt 可以提醒 Agent 克制，数据库和网关才负责真正执行限制。
让每条 SQL 都带着“来路”
以后排查 AI 查询，最怕看到一条昂贵 SQL，却不知道它为什么出现。
建议让每条查询至少带上这些标识：
- 用户请求 ID；
- Agent 任务 ID；
- 当前尝试编号；
- 所属假设或分析步骤；
- 是否为重试；
- 使用的模型与工具版本。
这样，数据库慢查询记录才能还原一次自然语言问题在后台发生了什么。
比如你会发现，同一个问题因为字段名理解错误，连续重试了 8 次；或者三个 Agent 分别扫描了同一张明细表，只是筛选条件略有不同。
没有来路，SQL 只是事故现场的一只脚印。带上任务信息，才有可能找到是谁、为什么、走了几遍。
重复查询不一定要重复计算
BAIR 提到，Agent 工作负载可能重新唤起一些并不新鲜的数据库思想：多查询优化、共享扫描、近似查询和中间结果流式返回。
普通团队不必实现新的查询引擎，也可以先做简单版本：
- 对规范化后的 SQL 或逻辑计划做短时缓存；
- 相同用户问题的并行分支共享已完成的中间结果；
- 先查询聚合表或小样本，确认方向后再扫明细；
- 在昂贵查询执行前返回预计扫描量和耗时；
- 对重复失败的计划设置熔断，不让 Agent 无限换写法。
这里最重要的变化，是把数据库从被动执行者变成会反馈成本的参与者。
人看到“预计扫描 8 TB、耗时 20 分钟”，通常会重新想一想。Agent 也可以，只要系统真的把这条信息给它，并且允许它换一条更便宜的路。
先给一次问数做一张账单
如果团队已经有 AI 问数，不用等到数据库报警才开始治理。
找 20 个真实问题，为每个问题记录：
- 生成了多少条 SQL；
- 实际执行多少条；
- 有多少条逻辑重复；
- 总扫描量和总执行时长；
- 失败和重试次数；
- 最终答案是否被采纳。
你可能会发现，有些漂亮答案花了很大代价，有些问题根本不应该从明细表开始，还有些重试只是因为工具没有告诉 Agent 合法字段。
模型调用越来越便宜以后，团队容易误以为“多试几次也没关系”。可 SQL 扫描的不是空气，后面还有计算、存储、并发和人的等待。
AI 可以不知疲倦，数据库会累，财务也会看账单。
下一次演示 AI 问数时，除了展示答案，不妨在旁边放四个数字：查询条数、重复比例、扫描量和总耗时。
那才是它真正做完这件事的样子。
我叫石头，在数据行业里摸爬滚打了十几年，这一轮 AI，我更愿意先看它在后台跑了什么。这里写的，就是这些教训——我觉得值得说出来的那部分。
来源：Berkeley BAIR：Intelligence is Free, Now What? Data Systems for, of, and by Agents
