AI没换掉查询引擎，换掉的是数据接口

过去两年，业界最热闹的争论之一是：AI会不会干掉SQL、干掉数据分析师？Peihao Yuan在InfoQ发表的一篇文章给出了一个更冷静的答案：AI改变的是数据接口，而不是查询引擎。真正的变化在于——AI Agent开始成为数据的主要调用方，它不需要看板，需要的是一段约束明确的SQL、一个确定性的计算引擎，和一个可以被重放的分析过程。这篇文章基于一次灾备分析工作流，把「确定性拆分」这件事讲透了，也值得每一个还在纠结『要不要为AI重构数据平台』的团队认真读一遍。

“阅读说明：本文中标注为「原文要点」的内容，是对Peihao Yuan文章核心观点的转述；标注为「作者推演」的内容，是本文作者的延伸判断，责任在评注者而非原文。

🤖 从一次灾备复盘说起

想象一个场景：灾备演练结束后，管理层要立刻回答三个问题——数据丢了多少、哪些业务受影响、恢复窗口是否符合SLA。

传统做法是：分析师拉数、写报告、来回确认口径，两天后交付一版可能已经过时的PPT。

“原文要点：文章描述的工作流是另一种样子——AI Agent接收业务问题，生成受限的SQL或Python代码，交给DuckDB直接扫描Parquet文件算出结果，然后由Agent解读这些「事实」，人最后复核。

注意这个流程里最关键的设计：Agent写的不是自由奔放的代码，而是被约束的SQL或Python——查询范围、字段口径、计算边界都被事先框死。引擎输出的不是「看法」，是可复现的事实；解读归Agent，算数归引擎。

这套工作流在工程上之所以成立，有硬事实支撑：DuckDB是阿姆斯特丹CWI研究所研发的进程内OLAP引擎，其论文发表于SIGMOD 2019，核心卖点正是「零依赖、单进程、可直接对Parquet做向量化扫描」——这意味着Agent进程可以把它当库加载，随用随起，用完即弃。

这就是文章标题的含义：LLM没有取代查询引擎，它取代的是人与数据之间的交互层。

（作者推演） 从我们接触到的团队实践看，「Agent贴身计算」的模式确实正在中小规模分析场景快速铺开，但目前主要局限于数据规模小、口径相对固定的内部场景；它是否会成为主流形态，还需要更长时间验证——这一点原文并未给出数据，读者需自行判断。

⚙️ 确定性拆分：算数必须留给引擎

这一节的核心，是原文的一句话：概率的归Agent，确定的归引擎。

这个切分有坚实的技术依据。LLM是概率系统——即便把temperature设为0，由于浮点运算和批处理调度等原因，主流商业API也不承诺逐字节一致的输出；而查询引擎是确定性系统，同一份数据加同一段SQL，永远给出同一个答案。灾备这种场景里，数字差一个百分点都可能改变决策，你不允许「大概是对的」。

“原文要点：Agent负责理解模糊的业务问题、生成受限代码、解读结果——这些环节错了可以被人拦住；而所有「产生事实」的计算，全部下沉到DuckDB这类确定性引擎里执行。数据落在开放的Parquet格式上，引擎只是一个无状态的函数。

由此带来第二个关键能力：可重放分析。把同一批Parquet文件和同一段SQL固定下来，任何人、在任何机器上重跑，都会得到完全一致的结果。这意味着分析过程可以被审计、被验证、被追溯——出问题时你不需要争论「AI是不是又幻觉了」，只需要重放一遍。这与数据库领域「time travel」类特性（如Iceberg的快照机制）的审计思路一脉相承。

`json infographic

{"type":"problemsolution","title":"Agent时代的分析痛点与解法","items":[{"problem":"LLM输出不确定，结果难以复现","solution":"确定性拆分：计算全部下沉到引擎执行"},{"problem":"分析过程黑盒，出错难以回溯","solution":"可重放分析：固定输入即可重跑验证"},{"problem":"小规模数据上托管服务成本过高","solution":"嵌入式引擎本地直算Parquet"},{"problem":"数据规模与并发超出单机上限","solution":"按四信号判断，迁移到托管湖仓"}]}

`

（作者推演） 产业逻辑可以概括为：AI时代的数据可信，不是靠让模型更聪明，而是靠把「聪明但不稳定」的部分和「笨但可靠」的部分物理切开。这其实是分布式系统设计的老原则——在新的接口形态下被重新发明了一遍。

🔀 接口变了，引擎没变

数据库行业有个有趣的规律：每一次交互范式革命，改变的都是接口层，而不是引擎层。

从终端到BI看板，从看板到Notebook，每一次变化都催生新的工具公司，但底下的查询引擎——优化器、执行器、存储格式——几十年来只是稳步演进。这一次轮到AI，剧本大概率不会改写。

“原文要点：变化真正的落点是数据接口。Agent不需要一张漂亮的Dashboard，它需要的是一段机器可读、语义清晰、结果确定的数据契约。SQL和Parquet恰好就是这样一个开放的契约——前者是四十年的查询标准，后者是开放表格式事实上的存储载体。

「开放表格式重要性被放大」这一点，近两年的产业动作提供了可验证的证据：

• Apache Iceberg于2015年成为Apache顶级项目，2024年起被Snowflake、AWS（S3 Tables，2024年12月发布）等主流厂商全面接入；
• Databricks于2024年6月收购Iceberg商业公司Tabular（据报道交易金额约10亿美元量级），并宣布对Iceberg的互操作支持；
• Delta Lake本身在2019年就被Databricks开源——两大巨头用真金白银投票，说明「数据以开放格式躺在对象存储上」已是行业共识。

这对产业意味着两件事：

第一，开放表格式的重要性被放大了。存储与计算解耦本就是湖仓一体的核心主张，而在Agent时代它多了一层意义：只有数据以开放格式躺在对象存储上，一个嵌入式引擎才可能在Agent进程里「贴身」把它算掉。数据被锁在私有闭源格式里的平台，在Agent生态里会越来越被动。

第二，查询引擎的护城河没有被动摇，被动摇的是入口。过去入口是浏览器里的看板，现在入口是聊天窗口和Agent框架。（作者推演） 谁控制了Agent与数据之间的接口规范，谁就控制了新的分发权；数据平台厂商的核心竞争点，可能会从「谁的UI更好用」转向「谁的接口对Agent更友好」——这一判断目前只有少数早期信号，尚无系统性数据支撑，请读者带着保留态度看待。

换句话说：别再问「AI会不会取代SQL」，要问「你的数据接口对Agent开放吗」。

📊 四个信号：嵌入式够用，还是上湖仓

这篇文章最工程化的部分，是给出了判断标准：什么时候一个嵌入式引擎就足够了，什么时候才值得上托管湖仓。

“原文要点：文中提出了「四个信号」的决策框架。下表的具体形态是作者基于该框架与行业实践推演的具体化，非原文内容。

判断的核心不是「哪个更先进」，而是架构复杂度与实际需求的匹配。灾备复盘、临时取数、数据质量核查、Agent的原生计算层——这些场景里，DuckDB式嵌入式引擎几乎是碾压性的选择：零部署、零运维、直接读Parquet，Agent进程结束它就消失，成本接近于零。

市场也在为这个判断背书：围绕嵌入式DuckDB构建托管服务的MotherDuck，2023年完成4750万美元A轮融资，2025年初又完成1亿美元融资——资本愿意持续下注「嵌入式引擎 + 云端协作」的混合形态，说明这条路线有真实的商业需求。

而当数据成为多团队共享的持续资产、需要管道长期运行时，托管湖仓的治理能力、弹性扩缩和高可用才开始物有所值。用四象限看这个格局会更直观：

（注：图中定位为作者的主观推演，仅用于表达「门槛与价值错位」这一论点，不代表客观市场排名。）

有意思的是DuckDB的位置：技术上它门槛不高——一个嵌入式库，却在Agent时代拿到了过去只有重量级数仓才配拥有的商业叙事空间。这不是引擎变强了，是接口变了，让轻量引擎站到了新的价值位上。

🧭 谁的机会，谁的护城河

（本节整体为作者推演：把原文的判断往产业层面延伸，得到三条线索。）

第一条线：嵌入式引擎迎来第二春。 从SQLite到DuckDB，嵌入式分析的路线已经验证了二十余年——SQLite自2000年发布以来号称是世界上部署最广泛的数据库引擎，DuckDB则用四年时间成为GitHub上增长最快的分析型数据库之一。但真正让它们起飞的是应用场景，这一次是AI Agent。Agent进程天然适合内嵌一个无服务依赖的计算内核：启动快、单进程、可隔离。（作者推演） 据我观察，已有团队把嵌入式引擎直接作为Agent工具链里的标准组件，而不是通过API去调一个远端数仓——这一趋势尚缺乏公开的统计佐证，欢迎读者在评论区补充自己团队的实践。

第二条线：托管湖仓厂商必须重新设计入口。 湖仓厂商过去的卖点是「把你们所有的分析都搬上来」，但Agent模式恰恰相反——大量轻量计算根本不需要上云，只在数据足够大、协作足够重时才值得迁移。这意味着厂商的产品逻辑要从「收留所有负载」转向「接住最重的负载」，并把接口做薄，让Agent可以随时把数据带出去本地算。Databricks开源Delta Lake、收购Tabular后的互操作表态，都可以视为这个方向的早期信号。对习惯了锁定式商业模式的厂商来说，这是需要勇气的转身：开放接口短期是让利，长期是入场券。

第三条线：数据治理的重心前移。 可重放分析的本质是把分析变成可审计的工程制品。当Agent成为主要分析者，治理的对象从「人和看板」变成「Agent生成的每一段查询」。约束生成、输入固定、结果重放——这套机制实际上就是AI时代的数据治理雏形。（作者推演） 近两年Databricks开源Unity Catalog、各湖仓厂商竞相加入行级权限与血缘追踪能力，说明治理层已经开始向「机器调用方」倾斜；谁先把「Agent生成查询的可审计闭环」产品化，谁就在「Data for AI」的赛道上多握了一张牌。

从成本视角看，这个趋势对多数企业是好消息：不需要为了用AI而重建整个数据平台，只需要把接口理顺、把格式开放、让Agent能贴着数据算。引擎还是那个引擎，成本结构却可以低一个量级。

写在最后

回到开头的问题：AI会不会重构数据平台？答案是——它会重构，但重构的位置可能和大多数人预想的不一样。

查询引擎安然无恙，看板时代建立的交互范式却在瓦解。确定性与概率性的拆分、可重放的分析、开放格式上的嵌入式计算，这三件事正在悄悄定义Agent时代的数据接口。

全文总结（三条核心结论）：

1. 架构原则——概率的归Agent，确定的归引擎。LLM负责理解与解读，DuckDB类引擎负责产生可复现的事实，两者物理切开才能保证可信。

2. 产业格局——每一次交互范式革命，动的都是接口而非引擎。开放表格式（Iceberg、Parquet）的价值被放大，数据平台的竞争点从UI转向「对Agent友好的接口」。

3. 行动清单——对工程师来说，下一步该做的不是追新概念，而是检查三件事：你的数据是否以开放格式可被贴身计算？你的分析是否可重放？你的接口对Agent是否友好？

引擎的战争早已打完，接口的战争才刚刚开始。