周二早上，我打开了第 278 期 Data Engineering Weekly。
这期没有哪一条新闻单独看起来惊天动地。没有“某个模型再次超越人类”，也没有“某家公司重写数据行业”。但把几条消息摆在一起，桌面上的东西突然换了位置。
以前，数据库主要等人来查；图表主要等分析师来画；内部 API 主要等程序来调。现在，Agent 开始站到这三样东西前面，而且它的脾气跟人不太一样。
它会一口气试很多条 SQL，会对着字段名猜语义，也会把一个有 14 个参数的接口用得像刚接手别人祖传脚本的新同事——很认真，也很容易走错。
这周真正值得看的，不是 AI 又会了什么，而是数据系统准备好接待这个新用户了吗？
Agent 查一次数，可能不是一条 SQL
伯克利 BAIR 在 7 月 7 日发布了一篇很有野心的文章，讨论“为 Agent、由 Agent、属于 Agent 的数据系统”。其中一个细节很扎眼：当多个 Agent 并行完成一次 Text-to-SQL 任务时，单个用户请求可能展开成成百上千条子查询。
这和人用 BI 工具不一样。
人通常先看字段，再写一条查询，错了以后改一改。Agent 更像一群精力旺盛的实习生，同时去试不同的连接、过滤和聚合。BAIR 的实验观察还指出，其中只有约 10%–20% 的子计划真正不同，剩下的大量查询在重复劳动。
从 Agent 的角度看，重复尝试能提高成功率。从数据库的角度看，这叫账单。
所以，未来的数据平台不只要回答“这条 SQL 能不能跑”，还要回答另外几个问题：这些探索能不能共享结果？能不能先返回近似答案？能不能在昂贵查询真正执行前，告诉 Agent 预计延迟和成本？
普通数据团队不必明天就重写查询引擎。但如果你正在做 AI 问数，至少应该开始记录三件事：一次问题实际触发了多少查询、其中多少重复、失败重试消耗了多少资源。
只看最终答案对不对，很容易把数据库被折腾得气喘吁吁这件事漏掉。
AI 会画图以后，语义反而更重要
Microsoft Research 在 7 月 8 日开源了 Flint，一种面向 AI 时代的可视化中间语言。
它试图解决一个很具体的麻烦：让模型直接生成完整的 Vega-Lite、ECharts 或 Chart.js 配置，代码往往又长又脆。日期怎么解析、坐标轴要不要从零开始、百分比怎么显示、标签挤不挤，这些细节只要猜错一个，图还能画出来，却可能悄悄误导人。
Flint 的做法，是让 Agent 先表达一份更短的“图表意图”，再由编译器根据语义类型补齐比例尺、格式、颜色和布局。同一份规格还可以输出到多种图表后端。
这个思路有意思的地方，不是又多了一种画图库。
它承认了一件常被忽略的事：图表生成的难点不是把数字变成像素，而是先知道这个数字是什么。
一个字段是金额、排名、比例还是日期，决定了它该怎么被画。AI 可以很快生成代码，但如果语义没有写清楚，它只是更快地做出一张“看起来像图”的东西。
对数据分析师来说，这反而是好消息。以后值钱的能力可能不是记住某个图表库的所有参数，而是能不能把图表意图说清楚：比较什么、强调什么、哪些尺度不能省、什么情况下这张图会误导人。
Grab 换 Iceberg，先处理的不是潮流
Grab 在 7 月 10 日公开了它从 Hive Parquet 迁移到 Apache Iceberg 的过程。
这篇文章最值得看的，不是“又一家大公司用了 Iceberg”，而是它把迁移前的麻烦写得很具体：Hive Metastore 在高并发下成为瓶颈；部分机器学习数据集平均文件小于 1 MB；工程师需要手工注册分区；存储里的真实状态和目录里的记录还可能对不上。
这些问题听起来不新鲜。很多团队的存储架构就是这样慢慢长出来的：先把文件放进去，后来加目录，再后来补脚本，最后谁也不敢动那段每天凌晨两点跑的修复任务。
Grab 没有一键迁移整个数据湖，而是优先迁移扫描频率高、API 成本高、收益明确的表。公开案例里，一个高流量导航数据集的查询时间从约 70 秒降到 6 秒；另一张高频操作表的 S3 API 日成本最多下降约 95%。
这里真正能带回普通团队的，不是这两个数字，而是迁移顺序：先拿查询耗时、小文件数量、对象存储请求和人工维护时间做账，再决定哪张表值得先动。
技术选型会让人兴奋，迁移清单通常不会。可最后真正省钱的，往往是那张清单。
MCP 工具不是把旧 API 换个名字
AWS 这周用同一个搜索后端做了 6 种 MCP 工具设计，逐步比较富描述、Schema 约束、按需加载、服务端解释和 Agent-as-tool。
最初版本直接暴露 14 个内部参数。字段名来自数据库，合法值没有说清，模型只能反复猜。后来他们把参数改成更接近业务语言的名字，用枚举限制有效值，给常见场景设置默认值，再把复杂分类信息改成需要时才加载。
这件事对正在做 AI 工具接入的人很实用。
一个接口对程序员清楚，不等于对模型清楚。程序员看到空结果会去翻文档，模型看到空结果往往再猜一次。每猜一次，都是上下文、时间和调用次数。
所以，把现有 API 原封不动套一层 MCP，常常只是把旧复杂度搬到新入口。真正的工作是重新设计工具边界：一个工具只做一件事，参数尽量少，合法值可约束，错误信息能告诉调用者下一步怎么改。
一个三周做出的分析助手，考的是平台底子
Lyft 还分享了一个挺有反差的案例：一名新工程师把内部分析与出行智能助手 ARIA 作为入职项目，在三周内推进到生产环境。
容易被转述的标题是“三周做出 AI 分析助手”。但更值得注意的是，真正占据生产化工作的仍然是那些不太适合发朋友圈的部分：身份认证、可观测性、状态管理、流式响应、部署路径和内部文档。
一个新人能不能在三周内把东西送进生产，不只说明他会不会写 Prompt。它更像一次平台体检：公共组件是否可用，文档是否能让陌生人走通，权限和发布路径是否已经铺好。
这也给普通从业者一个更可靠的判断标准。面试时别只问“你们有没有 AI 项目”，可以多问一句：“一个新功能从 Demo 到内部可用，需要经过哪些固定步骤？”
答案里如果只有模型和框架，没有权限、测试、日志和责任人，这个项目多半还住在演示厅里。
拾穗解读：先别急着换岗位，先看工作对象变了没有
这五条信息放在一起，指向同一件事：数据工作的对象正在变化。
过去，我们为人设计查询入口、图表和 API。人会犹豫，会读说明，会在成本太高时停一下。Agent 不一定。它会并行探索，会把模糊参数当成猜谜，也会把“能调用”理解成“可以一直调用”。
于是，数据从业者要补的不是又一套 Prompt 技巧，而是三种更朴素的能力：
- 把语义写成约束。 指标、字段、图表和工具参数不能只靠口头默契。
- 把成本变成可观察的数据。 查询数量、重复比例、失败重试、延迟和调用费用都应该留下记录。
- 把生产路径变成可复用的路。 权限、测试、日志、回滚和文档不能每个项目重新发明。
AI 越便宜，试错越多；试错越多，数据系统里的旧含糊就越贵。
下周上班时，不妨先挑一个最常被 AI 调用的接口、一张最常自动生成的图，或者一条最常重复解释的指标。看看里面还有多少内容，只存在某个人的脑子里。
这件事不宏大。但把一处猜测改成一条约束，系统就少一次乱跑，你也少一次半夜解释。
我叫石头，在数据行业里摸爬滚打了十几年，这一轮 Agent，我更关心它会把哪些旧问题放大。这里写的，就是这些教训——我觉得值得说出来的那部分。
来源：Data Engineering Weekly #278 · Berkeley BAIR：Data Systems for, of, and by Agents · Microsoft Research：Flint · Grab：Apache Iceberg adoption · AWS：MCP tool design · Lyft：ARIA analytics assistant
