当AI Agent开始追问数据从哪来

凌晨两点，数据平台的告警群又炸了。这次值班的不再只是人，还有被推上排障一线的 AI Agent。它读得懂代码，却答不上一个最朴素的问题：这张表的数据到底从哪来？不是 Agent 不够聪明，而是数据管道从来没向它敞开过自己的记忆。当 Cognee 社区给 Agent 接上 OpenLineage 血缘连接器、StreamSQL 用流流 JOIN 补齐状态化算子最后一块拼图，同一个判断浮出水面——数据基础设施的下一批核心用户，已经不是人。

🕳️ Agent 上岗第一天，先在管道里迷路

Agent 不缺智力，缺的是上下文。

设想一个正在变成现实的工作场景：企业把 ETL 排障、数据来源审计这类活儿交给自主 Agent。素材里列出的三类问题，几乎是所有数据平台值班群的日常——

• 哪条上游 Apache Spark 作业在给 retention_metrics 表喂数？
• 昨天财务报表管道为什么挂了？
• 如果改 orders 表的 schema，下游哪些管道和看板会碎？

人类工程师答这些题，靠的是多年攒下的脑内地图：哪条 DAG 供养哪张表、哪个 dbt 模型动了会炸哪个看板。但绝大多数 LLM 应用对此的感知是零——它们根本观察不到数据怎么在 Apache Airflow 的 DAG、Spark 转换、dbt 模型之间流动。

这就是企业 AI 落地时最尴尬的盲区：Agent 被当成工程伙伴，却没有发它一张管道地图。

上图是人类眼中的管道。对 Agent 来说，没有血缘记忆库那一层，左边整条链路就是不存在的——它只能靠猜，而猜错的代价是生产事故。

产业逻辑很清楚：血缘正在从“治理文档”变成“运行时上下文”。过去血缘服务的是合规和影响分析，属于季度级需求；现在它成了 Agent 每次排障都要检索的实时记忆，属于秒级需求。这一字之差，把元数据从后台拽到了前台。

🧩 给 Agent 装记忆，开源社区给出了标准打法

缺什么补什么，开源社区的动作一向最快。

这条线的具体落点很清晰：开发者 Soumyajit Ghosh（@somuai）在 Mergetober 黑客松（WeMakeDevs x Cognee）期间，给 Cognee 提交了一个 OpenLineage 连接器——PR 是 topoteretes/cognee-community#349，关联并关闭了主仓的 issue #5554。

拆开看这个动作的产业含义，比一行代码重要得多：

1. 连接器模式。不改造管道本身，而是挂一个采集器，把 OpenLineage 格式的管道事件接进来。管道侧零侵入，这是血缘采集铺得开的前提。

2. 记忆化。接进来的血缘事件不是存成报表，而是进入 Cognee 的记忆层，变成 Agent 可检索、可推理的知识结构。

3. 走开放标准。OpenLineage 已经是管道事件的事实标准格式，连接器等于把 Agent 的“眼睛”直接对准了这个标准，而不是私有 API。

一位长期做数据平台的朋友私下说过一句话，我印象很深：“Agent 修不好管道，不是它笨，是它瞎。” 现在社区做的事，本质上就是给 Agent 装眼球。

往深一层推：元数据层正在变成 AI 基础设施。过去平台团队建血缘是给审计和 BI 用的“奢侈品”，今后它直接决定 Agent 的排障上限——血缘覆盖不全的地方，就是 Agent 的能力盲区。这会反过来倒逼血缘采集的完整度和实时性，元数据工程从成本项变成能力项。

⚡ 另一条战线：流式 SQL 补上最后一块拼图

血缘解决“看懂”，而管道本身的实时化，也在同步收尾。

StreamSQL 的版本节奏就是一条清晰的时间线：

状态化算子三件套至此凑齐。v1.3 的流流 JOIN 语义很讲究：两条实时流按主键关联，且事件时间相差不超过 WITHIN 窗口才算匹配；LEFT JOIN 无匹配时补 NULL，天然做“缺席检测”——比如用户下了单却迟迟没支付，这种“该来没来”的场景以前要绕很大圈子。此外还支持 3 条以上流的级联关联，以及 EmitTo 多流喂数。

更值得说的是工程姿态：全部新增为 additive，不写 WITHIN 的存量查询一行代码不用改。做过多流计算升级的人都懂，这一条比功能列表更有分量——流式引擎的历史包袱，往往就是毁在兼容性上。

产业逻辑在哪？流式计算的能力早已被验证，瓶颈在于使用门槛：状态、乱序、水位、窗口匹配，每个概念都劝退一批人。SQL 化是把这些复杂性藏进引擎、只暴露一个声明式查询的办法。声明式接口还有个容易被忽视的附带价值——它天然适合 Agent 调用。让 Agent 读明白一段 SQL，比让它理解一整套命令式 DAG 代码，难度低了一个量级。

🔗 两条线交汇：实时平台必须长出可解释的运行时

血缘和流式，看起来是两件事，实际上是同一场变革的两面。

流流 JOIN 这类算子，恰恰是把管道变“复杂”的推手：状态在引擎里持续维护，匹配关系依赖事件时间和 WITHIN 窗口，一条 JOIN 的输出取决于两条流各自的迟到情况。也就是说，实时化抬高了管道复杂度，AI 化抬高了对可解释性的要求，两者互相加强。

拿一张表对比新旧两类用户，差异一目了然：

注意最后一行：LEFT JOIN 补 NULL 做缺席检测，本身就是一种写进查询里的业务语义。Agent 要运维这样的管道，血缘的颗粒度就必须细化到算子、窗口和字段级，只记录“表 A 到表 B”是远远不够的。

据多位接近平台团队的人士说，不少公司已经把“Agent 可读的血缘”写进了数据平台的立项需求，和 TCO、SLA 并列。这在两年前是不可想象的——那时候血缘还只是合规部门年底检查时要看的那张图。

💡 给平台团队的三条落地建议

看懂趋势不难，难的是接下来一个季度做什么。从工程和成本视角，我的判断是三条：

第一，血缘先标准化，再谈智能化。 优先接入 OpenLineage 这类开放标准，管道侧用连接器零侵入采集，别自造私有格式。自造格式的平台，未来每接一个 Agent 框架都要重写一遍适配，这笔账迟早要还。

第二，把血缘喂进记忆库，而不是只做溯源页面。 Cognee 这个 PR 的关键不在于连接器本身，而在于血缘被当成了 Agent 的记忆而非报表。BI 溯源页面给人看，知识图谱给 Agent 查，载体不同，价值天差地别。

第三，压缩 Agent 的操作面。 像 StreamSQL 这种声明式 SQL 加 additive 兼容策略的组合，对 Agent 极其友好：查询即操作、升级不破坏存量。给 Agent 的接口越声明式，出错半径越小，上线阻力越小。当然，血缘采集和记忆检索本身有开销，高频排障场景下要提前算好这部分的检索成本，别让“Agent 的眼睛”变成新的账单黑洞。

小结：数据管道正在长出两套新接口——对 Agent 的血缘记忆，对人的状态化算子。前者决定 AI 能不能看懂你的平台，后者决定实时能力能不能被更多人用起来。可以做个前瞻：明年再做数据平台选型时，“Agent 能不能看懂你的管道”大概率会和 TCO 一样，成为一道硬指标。管道的下一个用户不是人，平台为它做的每一分投入，最终都会还给人。