Agent闯进数仓，先撞上成本墙

AI Agent 不再满足于回答问题，它们开始下场干活——写数据管道、跑数仓、编排任务。但过去几周的几条动态提醒我们：真正卡住 Agent 的，从来不是模型够不够聪明，而是评估框架、运行时基础设施，以及一笔越来越算不过来的 token 成本账。

Elastic 的评估框架进化、MotherDuck 收购 Tower Computing、一句来自一线用户实测的 "Model for the token, not the table"——三件事凑在一起，恰好勾勒出数据基础设施的下一个分水岭。

🔍 没有评估体系的 Agent 产品，等于没有测试的在线服务

先看第一件事。InfoQ 上线了一场来自 Elastic 的技术分享，讲者是 Susan Chang，主题是如何为 Agentic AI 产品构建可复用的评估框架。

故事的开局很熟悉：早期 Elastic 内部的 AI Agent 评估是 "siloed、ad-hoc" 的——各团队各搞一套，临时起意，零散跑测。听起来耳熟吗？这就是十年前数据团队没有数据质量平台时的样子。每个团队都觉得自己写几个脚本就够了，直到线上出事才发现，谁也说不清回归是从哪进来的。

Susan Chang 给出的解法分三层，每一层都踩在真实痛点上：

第一层，评估方法的平衡。 LLM-as-a-judge 灵活但抖动，确定性规则稳定但写不全。Elastic 的做法不是二选一，而是让两者在同一个框架里分工——语义层交给裁判模型，硬边界交给确定性规则。这正是所有做 Agent 产品的团队正在反复踩的坑。

第二层，语言栈的桥接。 数据科学同学用 Python 写评估，生产代码是 TypeScript，两套体系对不上，评估就永远停留在实验室。把 Python 侧的评估能力桥接到 TypeScript 生产链路里，这个细节没有惊心动魄的叙事，却是工程落地的真功夫。

第三层，深度追踪（deep tracing）。 在复杂的 RAG 和网络安全工作负载里，用深度追踪抓回归，同时保留领域上下文——不是简单记录 “答错了”，而是能定位到检索、编排、生成哪一环出了问题。

产业逻辑其实一句话就能说透：评估体系正在从 “研究课题” 变成 “发布门禁”。这是我基于这场分享做出的判断：当 Elastic 这样把评估框架当成生产级基础设施来构建，它实际上宣告了 eval 平台的定位变化——从模型团队的实验开销，转向与 CI/CD、可观测性并列的基础设施预算。谁能把评估做成产品级框架，谁就卡住了 Agent 产品化的咽喉。

🦆 Agent 能回答只是入场券，能替你干活才是真生意

第二件事的信号要强烈得多。MotherDuck，就是 Google BigQuery 前工程负责人创办的那家云数仓公司——宣布收购了 Tower Computing。

Tower Computing 做的事情是数据工程任务的运行时基础设施，理想场景就是让 AI Agent 和 vibe-coded 的管道去执行数据工程任务。这个定位很妙：大模型负责 “想”，Tower 负责让 Agent 的想法真的在数据系统里 “跑起来”。

这笔收购背后有一段圈内人脉故事。MotherDuck 方面透露，早在 Google 时期就与 Tower 联合创始人 Serhii Sokolenko 共事，后者曾被称为 “见过最令人印象深刻的 PM 之一”，随后去了 Snowflake，并在那里结识了另一位联合创始人 Brad Heller。有意思的是，听说 Serhii Sokolenko 要创业时，MotherDuck 的第一反应是遗憾—— “没法招他进公司了”。但团队一直盯着 Tower 的动向，看中的正是 Brad Heller 搭建的那支 “动手快、能交付” 的技术团队。

而收购的种子，早在 Agent 热潮之前就埋下了。MotherDuck 原本只是想找一个工具白名单合作，帮客户更方便地把数据灌进数仓——毕竟 “数据进不来，数仓再好也白搭”。后来 AI 突然成了数据团队的关键词，事情的性质就变了：接入工具的运行时能力，恰好是 Agent 执行数据工程任务最稀缺的那块拼图。

落地路径很清晰，分三步走：第一步，Tower 驱动 MotherDuck Flights，让 “一条富数据管道只隔着一个 prompt”；第二步，把 Flights 升级成 Data APIs；第三步，编排数据 Agent，让它们持续替用户干活。

这里的产业判断是我个人的看法：数据平台的竞争维度正在换轴。过去卷的是查询性能、弹性、成本曲线；Agent 时代要多卷一项——“可被 Agent 操作的程度”。运行时基础设施这个原本不起眼的层，一夜之间成了数仓厂商的必争之地。我自己的判断是：数仓的入口正在从 SQL 编辑器变成对话框，谁控制了 Agent 执行任务的运行时，谁就控制了新的入口。

💸 为 token 建模，而不是为表建模

第三件事最小，但可能最扎心。它是数据社区里流传的一句一线实测经验：

““我们把 Gong 的 API 都打爆了，就为了喂 AI。把对话记录用 dbt 在数仓里建模之后，token 成本降了 20 倍。”

场景拆开看：一家使用 Gong（销售会话智能平台）的团队，为了让 AI 分析销售对话，大量拉取原始 transcript 直接塞给模型——API 配额被烧穿，token 账单跟着起飞。转折点是 dbt：团队把 transcript 在数据仓库里认真建模，AI 按需引用结构化结果，token 成本直接降到原来的二十分之一。

20 倍这个数字是这家团队的实测结果，未必人人能复现，但泄漏点是普遍的。其中最可验证的一条是：喂原始 transcript 的做法，换成用 dbt 在数仓建模、按需引用结构化结果后，实测成本下降了 20 倍。至于重复传上下文、检索噪声等其他泄漏点，效果量级因场景而异，这里不做夸大。

关键洞察在于：数据建模的价值正在被重新定价。过去我们论证建模的重要性，说的是 “人查得快、口径统一、维护省心”；现在多了一条硬理由——模型读得省，就是真金白银的 token 成本。表结构设计的优化目标，正在从 “为分析师查询服务” 悄悄加上一条 “为 LLM 消费服务”。

这其实是 dbt 这类建模工具的一次意外红利：当 AI 成了数仓最大的 “读者”，语义建模就从最佳实践变成了成本工程。预算会说话，这条逻辑比任何布道都好使。

🧭 三块拼图，拼出一个新栈

把三条线索摆在一起看，图景开始完整了：

分别对应 Agent 落地数据领域的三大件：对不对、能不能、贵不贵。缺任何一件，Agent 接管数据工程都是空中楼阁——没有评估，不敢发布；没有运行时，落不了地；没有建模，账单爆炸。

再看产业链的位置关系：数仓厂商在向上吃运行时（MotherDuck 收 Tower），评估和可观测能力在向数据平台渗透（Elastic 把 eval 做进产品体系），建模工具的定价逻辑被 token 重写（dbt 的意外红利）。三条线往中间挤，挤出来的就是下一代数据平台的样子。

对从业者的启示也很直接：如果你在数据团队，评估框架、Agent 运行时、面向 LLM 的语义建模，这三项技能正在从加分项变成必修课。这是我个人的推测：数据团队的组织架构里，大概率会出现 “评估负责人” 这样的新角色——就像当年 “数据质量负责人” 从无到有一样。

小结

Agent 闯进数仓，第一脚踢到的不是模型能力的天花板，而是成本与评估两堵墙。Elastic 在把评估做成生产级框架，MotherDuck 用收购补齐运行时，dbt 用户用 20 倍的成本下降证明了建模的新价值——三大件正在全部数据基础设施化。

往前看一步：当 Flights 变成 Data APIs、数据 Agent 被正式编排起来，“数仓 + Agent” 会从营销叙事变成默认配置。留给各家的窗口期不多了——谁能先把评估、运行时、建模打包成 Agent 可用的产品，谁就能吃到下一波数据平台的红利。

最后回到本文的三条信源：Elastic 的分享提供了评估框架的具体做法，MotherDuck 的收购公告明确了运行时的整合路径，Gong 用户的实测给出了 20 倍的成本数字——三件事都有据可查，而它们指向的未来，值得每个人自己判断。这堵成本墙挡住了很多人，也刚好筛出了真正会做基础设施的人。