Agent查库是人29倍，数据栈慌了

数据平台的用户，正在悄悄换人。

MotherDuck 对自家查询历史做了切片分析，结论相当扎眼：上个月，Agent 跑的查询量是人类的 29 倍，而且这个差距大约每月翻一番。平均每个组织里，Agent 的数量已经是人类用户的两倍。

换句话说，数据平台最大的"客户"已经不是坐在工位上的分析师，而是不领工资、不知疲倦的机器。我们的系统，还撑得住吗？

📈 29倍：Agent成了数据平台的大客户

金句：数据平台的第一用户，已经不领工资了。

先看事实本身。

MotherDuck 基于 DuckDB 云服务 MotherDuck 的查询历史抽样分析，得出三个数字：

• Agent 的查询量是人类的 29 倍；
• 这一差距大约每个月翻一番；
• 平均组织内 Agent 数量已是人类用户的两倍。

29 倍意味着什么？做个简单换算：如果把查询量看成一块蛋糕，人类用户只分到约 3%，剩下 97% 都被 Agent 吃掉了。

这不是实验室数据，而是一家云数仓厂商生产环境的真实切片。更关键的是翻倍速度——如果按"每月差距翻一番"的趋势推演，再过几个季度，Agent 与人类的查询量差距会进入百倍、千倍量级。到那时讨论"要不要为 Agent 优化平台"就晚了，因为人类查询已经退化成长尾里的噪音。

有位接近云数仓厂商的人士私下说过一句很传神的话："以前我们管容量规划叫按分析师人数算，现在得按 Agent 数乘以并发算。"

产业逻辑很清晰：Agent 正在从辅助工具变成数据平台的主要消费方。谁能先看清这个事实并重构产品，谁就拿到下一轮数据基础设施的入场券。

🔥 机枪式查询，撞上了按人设计的架构

金句：人类写查询像写散文，Agent 跑查询像打机枪。

为什么 29 倍这个数字如此刺眼？因为 Agent 的查询行为模式和人类完全不同——这不是"量更多"，而是"物种不同"。（以下行为特征基于 Agent 工作方式的合理推演，供读者对照自身场景验证。）

一个人类分析师写 SQL，会先看表结构、想清楚 join 键、估一下数据量，一条查询写十分钟，跑一次。而 Agent 完成一个任务，可能需要几十上百轮"查询—报错—修正—再查询"的循环，每一轮都真金白银地消耗计算资源。

这对现有架构是釜底抽薪式的冲击：

• 查询优化器面向"少而重"的查询调优，面对海量短查询，元数据解析、权限校验这些固定开销反而成了大头；
• 排队与并发模型按几十个分析师设计，Agent 一开就是几百个会话；
• 缓存策略假设查询有重复性，Agent 的探索式查询命中率天然偏低。

一句话：数据平台是为"人"的直觉设计的，而 Agent 没有直觉，只有吞吐。

💸 Seat 定价正在失灵，成本结构被改写

金句：按人头收费的生意，撞上了不占人头的客户。

过去二十年，数据工具的商业模型几乎都建立在同一个假设上：用户是人，按 Seat 收费。分析师要license，viewer 要席位，企业版按活跃用户数分档。

现在这个地基松了。当组织里 Agent 数量是人的两倍、查询量是人的 29 倍时——

• Agent 要不要买 Seat？它不算"用户"，却消耗 97% 的资源；
• 按查询量计费的平台，账单会突然被 Agent 打爆；
• 按人头计费的工具，收入不变，服务成本翻了几十倍。

多位业内架构师在私下交流中都提到同一个担忧："现在最怕的不是 Agent 不干活，是它半夜干活——没人盯着的时候，成本曲线自己会飞。"

这对厂商和甲方都是重构时刻：

对厂商，定价模型必须从"按人"转向"按消耗"甚至"按任务"，否则就是用人类的收入模型补贴机器的成本黑洞；

对甲方，FinOps 的对象清单里要新增一行：Agent。没有为机器用户设计的预算、限流和告警，一次失控的 Agent 循环就可能烧掉一个季度的数仓预算。

成本结构被改写的另一面，是新的机会：谁先做出"面向 Agent 的资源治理"产品——细粒度限流、任务级配额、异常循环熔断——谁就在这波迁移中卡住了位置。

🧱 dbt退役Native App，工具链提前换挡

金句：旧世界的连接器退役，是新世界的通行证。

就在查询行为剧变的同时，工具链侧也出现了标志性动作：dbt 官方宣布，dbt Snowflake Native App 将于 2026 年 11 月退役。

这件事表面看是一次产品线收缩，往深看是数据工具链在为 Agent 时代腾位置。

Native App 模式的初衷，是把 dbt 的能力以应用形式嵌入 Snowflake 平台内部运行，强调"贴近数据、平台内闭环"。但随着 Agent 成为查询主力，这种深度绑定单一平台的分发方式，显露出与现实需求的错位——Agent 需要的是跨平台、可编排、可被程序调用的工具接口，而不是给人用的图形化应用壳。

注意这里的节奏感：查询行为的剧变先发生，工具链的收缩紧随其后。这不是巧合。当主要用户从人变成 Agent，所有"给人用"的交互壳、平台专属分发形态，都会陆续进入退役倒计时。可以合理预判，未来会有更多厂商对类似形态做出取舍——Native App 未必是最后一个。

对正在使用该能力的企业，时间表已经写在明面上：距离 2026 年 11 月退役，留给迁移评估的时间窗口并不宽裕。越是核心链路，越要早启动影响面盘点。

🛠️ 治理与语义层，Agent时代的新地基

金句：人可以靠默契，机器只能靠契约。

如果 Agent 是数据平台的新主人，那平台需要什么样的新地基？从现有事实出发，有三件事的优先级被急剧拉高：

第一，机器身份与权限治理。 人有两倍数量的 Agent 在跑查询，它们用什么身份接入？权限怎么收口？人类权限模型假设"一人一号、行为可预期"，Agent 打破了这个假设。机器身份、细粒度授权、行为审计，会从合规加分项变成生产刚需。

第二，语义层的价值重估。 人类分析师看到一张命名混乱的表，还能靠经验和同事口口相传搞明白；Agent 没有这层默契，它需要机器可读的语义契约——表是什么意思、指标怎么算、哪些字段能信。语义层从"锦上添花"变成了 Agent 正确性的基础设施。

第三，面向机器的观测与护栏。 29 倍的查询量意味着传统的"人看报表"式可观测性失效。异常检测、成本熔断、循环逃逸，都得自动化。

据多位接近一线数据团队的人士反馈，已经有团队开始为 Agent 单独建"机器用户目录"、单独设成本预算——这不是超前布局，是被账单逼出来的。

小结

29 倍，不是噱头数字，而是一记警钟：数据平台的主要消费者已经换人，而我们的架构、定价和治理，还停留在为人类设计的时代。

MotherDuck 的切片数据揭示了事实，dbt 退役 Snowflake Native App 给出了动作，两者拼在一起指向同一个方向——未来一两年，数据基础设施会围绕"机器消费"重构一轮：按消耗计费、为 Agent 优化的查询路径、机器身份治理、语义契约。先动手的平台，吃 Agent 红利；后动手的，被账单和失控查询反噬。

留给数据团队的问题只有一个：你的平台，准备好接待不睡觉的顾客了吗？