数据库的下一个用户，不是人类

数据库行业做了五十年的假设，正在被一行代码改写：假设坐在数据库另一端的，是人。

最近三条产品动态几乎同时落地：Materialize 把两个 MCP 服务器直接内置进了数据库本身；Fivetran 与 dbt Labs 携手公布 dbt Core v2.0 的未来路线，理由开篇第一句就是"AI has changed the game"；还有一篇在工程师圈子里流传甚广的技术文章，讨论一个此前没人认真回答过的问题——当读数据和写数据的都是 Agent 时，谁来扛 token 的成本？

三件事，三家不同的公司，指向同一个判断：数据基础设施的下一个主要用户，不是人类，是 Agent。这不是愿景叙事，是已经写进产品架构里的事实。

🤖 MCP 进数据库：不是集成，是"落户"

一句话：Agent 不再是站在数据库门口的访客，而是搬了进来。

先看 Materialize 的做法。这个流式数据库平台宣布内置两个 MCP 服务器，一个面向"构建在数据之上的 Agent"，一个面向"操作平台本身的 Agent"。关键细节在于架构位置：这两个 MCP 服务器的协议处理器，直接运行在 Materialize 的 HTTP 层内部——和对外提供 SQL HTTP API 的，是同一台服务器。每一个工具调用（tool call），执行的路径与 pgwire 连接走的是同一个查询适配器。

翻译一下：Agent 用的查询通道，和你用 psql 连数据库走的通道，是同一条。没有 sidecar，没有中间代理层，没有为 AI 特设的"降级通道"。

这和市面上大量"给数据库套个 MCP 壳"的集成方案，有本质区别。

两个服务器分工也很清楚：Agent 服务器（/api/mcp/agent）服务的是你的"数据产品"——那些你长期维护的业务实时视图，Agent 来发现它们、读懂每个视图装了什么、然后去查询；运维 Agent 服务的则是平台本身——建模、部署变更、排查故障，全程不需要人一步步驾驶。

两者都走 JSON-RPC 2.0 over HTTP，支持标准的 initialize、tools/list、tools/call，任何合规的 MCP 客户端开箱即用。目前处于公开预览阶段。

产业逻辑很直白：当 Anthropic 定义的 MCP 协议成为 Agent 接工具的事实标准，各家数据库的竞争点就从"有没有 MCP 接口"升级为"MCP 接口嵌得有多深"。嵌在应用层，Agent 是客人；嵌在内核查询路径里，Agent 是住户。权限模型、查询预算、可观测性，只有"住户"才享受得到。

📊 dbt 的转身：转型叙事被 AI 改写

一句话：dbt Core v2.0 的立项理由，只有一句话——AI 改变了游戏规则。

Fivetran 与 dbt Labs 的这次联手，对外释放的信息密度不高，但信号极强。官方博客标题就叫《dbt Core v2.0 的未来》，正文开篇第一句话没有任何铺垫："AI has changed the game. dbt is changing along with it."

这行字的分量，圈内人才能掂出来。过去十年，dbt 的叙事锚点是"分析工程师"——让写 SQL 的分析师用软件工程的方法管理数据转换。整个产品的交互假设是：一个人类，在 IDE 里写模型、跑测试、看血缘。这个叙事支撑了 dbt 成为现代数据栈里渗透率最高的转换层。

而现在，转型叙事变了。AI Agent 要操作数据、建模、部署变更、排查故障——这恰恰是 dbt 管理的那一层。如果 Agent 是新的"分析工程师"，那 dbt 的接口、工作流、甚至社区协作方式，都得为非人类用户重新设计一遍。

据多位接近人士的说法，Fivetran 的数据集成管道加上 dbt 的转换语义层，被视作给 Agent 供应"可信数据上下文"的完整链路——集成保证数据进得来，转换保证数据读得懂。这条链路过去服务 BI 看板，接下来要服务的是会自主决策的 Agent。

产业判断：数据工具链的价值锚点，正在从"帮人少写代码"转向"让机器读懂数据"。v2.0 具体长什么样，官方还没揭晓，但方向已经写在了标题里。

⚖️ 读写都成了 Agent：谁扛 token 的账单？

一句话：Agent 架构的每个选择，本质上都是"让写方还是读方付 token 账单"的选择。

那篇流传甚广的《Context Graphs at Agent Scale》提出了一个极其锋利的框架。历史上，数据系统一直在两种极端之间摆荡：

• 关系数据库：写方可以任性——schema 想怎么设计就怎么设计，脏活全留给读方。人来做 JOIN、人来理解表结构、人来写那条两千行的查询。
• 搜索索引：读方体验极佳——上下文预先处理好，拿来就用。但代价是写方要承担把数据加工成索引的全部复杂度。

这两种模式能共存几十年，是因为读写两端至少有一端是人。人便宜、灵活、会自己补上下文。

现在问题来了：当读方和写方都是 Agent，两端都在烧 token 和算力去"理解对方"，这套经济模型直接崩塌。读方 Agent 每次查询都要自行探索 schema、拼凑上下文、反复试错——每一步都是 token；写方 Agent 如果还要为读方预处理完美的上下文——又是 token。两个 Agent 隔着接口互相浪费算力，这在"Agent 规模"下是不可持续的。

作者给出的解法方向是 Context Graphs（上下文图）——在读写两端之间建立一个双方共享的、结构化的中间层，让上下文不必被每一对读写 Agent 重新发明一遍。用工程的话说：把"理解成本"从每次会话摊销到数据模型本身。

这个框架的价值，在于它第一次把 Agent 时代的数据架构问题，翻译成了成本问题。而数据基础设施的历史反复证明：凡是能改写成本结构的变革，最终都会改写整个产业格局。

🔧 产业链正在重排：Agent 成为一等公民

一句话：数据栈的分层逻辑，正在从"人 → 工具 → 数据"变成"Agent → 工具 → 数据"。

把三条动态放进同一张图里，脉络就清晰了：

Materialize 占住了"Agent 直连数据"的那一层，把协议处理器焊进了查询路径；dbt 与 Fivetran 卡位的是"Agent 读得懂数据"的语义层和"数据进得来"的管道层；Context Graphs 的倡导者则在探索读写之间那层新的中间结构。每一层都有人下注，且都不是 PPT，是 public preview 和已公布的版本路线。

一条范式演进的时间线，值得放在心里：

• PC 与本地数据库时代：用户是人，接口是终端
• 云数仓时代：用户是分析师，接口是 SQL 与 BI
• 现代数据栈时代：用户是数据团队，接口是 dbt 与反向 ETL
• Agent 时代：用户是 AI Agent，接口是 MCP 与结构化上下文

据多位接近人士观察，接下来 12 到 18 个月，各家数据库厂商的"Agent-native"能力会从差异化卖点变成准入门槛——就像当年的 HTTP API 和当年的 CDC，晚了就没有牌桌资格。

小结

三条独立的产品动态，一个共同的前提：Agent 是数据基础设施的新用户，而且可能是增长最快的那类用户。

Materialize 用内置 MCP 回答了"接口怎么建"，dbt Core v2.0 回答了"语义层怎么变"，Context Graphs 回答了"成本结构怎么改"。三个答案拼在一起，是数据栈为非人类用户重写的开头几章。接下来值得盯的，是权限、计费、可观测性这些"老三样"何时跟上——一等公民的待遇，从来不止是能连上。