Agent 时代的数据架构
Agent 时代，数据团队到底交付什么？
过去的答案是工具。数仓、BI/报表平台、自助取数、指标系统，这些是绝大多数数据团队持续在做的。它们有用，但更像操作系统里的 ls 命令：谁都离不开，但不直接产生价值。
数据价值产生在两个地方，数据变成洞察，洞察变成执行。这两条链路，现在也正在被 Agent 改写。
这篇谈谈 Agent 时代的数据架构。
全景
┌────────────────────────────────────────────────┐
│ 工作闭环 Plan → Exec → Eval │
│ Eval 结果回流，触发下一轮 Plan │
├────────────────────────────────────────────────┤
│ Line 1 Data → Insight → Solution │
│ 交付打包的洞察，熵减沉淀为资产 │
│ │
│ Line 2 Data → Strategy → Execution │
│ 声明式定义，编译成策略直达执行系统 │
├────────────────────────────────────────────────┤
│ 公共基座 Data Context 六层上下文栈 │
├────────────────────────────────────────────────┤
│ 数据基建 湖仓一体 / 统一元数据 / 计算、存储与调度 │
└────────────────────────────────────────────────┘从下往上读：最底下是这些年攒下来的数据基建，往上是 Agent 理解数据的上下文基座，再往上是数据团队对外交付的两条主线，最上面是让这套东西持续运转的工作闭环。
主线一：交付洞察，不是交付工具
先看一次典型的业务分析长什么样。业务方在群里问一个问题，分析师拉数、分析、贴结论，业务看一眼结论，也许点个头，原来是这样，然后就没有然后了。三个月后另一个团队问了几乎一样的问题，再来一遍。分析的产出是一次性的，组织没有积累。
主线一要改的就是这个：Data → Insight → Solution，交付物从取数工具和报表换成打包的洞察。每个业务线有一份匹配自己场景的洞察数据资产：经过验证、能稳定驱动策略的信号，市场和竞品的关键事实，业务策略的上下文等。颗粒度可以很细，细到原始的用户行为。这些资产统一远端托管，版本可控，是公司级的 context，Agent 和人都直接消费。
这里最重要的设计原则是熵减。传统的标签和画像系统是熵增的：每个团队都往里加标签，越加越多，几年下来噪声淹没信号，没人说得清哪些标签还能用。熵减的做法反过来：只有经过业务验证、能稳定驱动策略产出的信号，才沉淀为正式资产；没验证过的进候选池观察，不进执行链路。资产的价值不在多，在于每一条都被检验过。
主线二：从报告到执行
主线二是 Data → Strategy → Execution。
过去这条链路是这样的：数据团队出分析报告，运营看懂报告，把结论翻译成策略文档，工程师再把文档翻译成代码。每一步都是翻译，每次翻译都有损耗，端到端几周起步。更常见的结局是，报告写得很好，然后什么都没发生。
Agent 时代这条链路可以直接编译：对用户的理解、对内容的理解，编译成执行系统能消费的策略动作，推荐系统、对话助手、运营平台拿来就用，人不再站在中间做翻译。业务方要做的只是声明：关心什么信号，什么条件算命中。剩下的取数、编译、验证、灰度由 pipeline 自动完成。我们给这条链路定的目标：从提出假设到上线验证，1 到 2 天。
这里有一条工程约束：LLM 不进在线主链路。编译是确定性的，规则加特征，因为在线链路每天亿级请求，延迟和可解释性是硬约束。LLM 用在离线加工：内容标注、语义抽取、数据再加工，统一走一套加工基建，不同场景配不同的准确率、成本和时效档位。各业务线不各自建一套 LLM 调用链。
公共基座：Data Context
两条线共用一个基座：Agent 理解数据的上下文栈。从表结构和查询历史，到人工标注的指标口径，到 ETL 代码反推的真实语义，到组织知识，到 Agent 自己的纠错记忆，最后是实时探查数仓的兜底。六层怎么落地，之前在「让 Data Agent 懂业务的六层 Context」里写过，不重复。
在整体架构里它的位置是：主线一靠它产生洞察，主线二靠它驱动执行。基座不牢，两条线都是空中楼阁。
数仓没死，是下沉了
最近又能看到「数仓已死」这类标题，逻辑大致是：数据的消费者变成了 Agent，为人服务的那套数仓体系就过时了。
前半句我同意，数据多了一类消费者这件事，之前专门写过一篇。后半句不对。看我们自己的架构就知道：Data Context 是两条线的基座，但它自己也踩在更老的一层上，湖仓一体的存储、统一元数据、计算、存储和调度系统。这些传统基建在图里画在最底下，不是因为不重要，是因为角色变了：从数据团队的交付物，变成了 Agent 消费的地基。
这个关系很具体。Context 的第一层直接构建在统一元数据之上，表结构、血缘、更新频率都是现成的，元数据平台建得越全，这一层的成本越低。第三层能用 ETL 代码反推表的真实语义，靠的是调度系统存着每张表的产出 SQL 和上下游依赖。第二层的指标口径，源头是指标平台里沉淀了多年的定义。基建缺哪一块，Context 对应的层就得靠人工补，或者靠 Agent 现场探查，都有不小的投入成本。
消费者从人换成 Agent，对基建的要求确实变高了，这个我们有切身体会。表描述写得潦草，人看不懂会问同事，Agent 不会，它会自信地选一张错的表，把分析做完。「DAU」「eDAU」「播放 DAU」这种指标群，口径差异写在自然语言描述里，人能分辨，Agent 会混着用，直到把每个指标的来源表和过滤条件全部结构化才解决。上游悄悄改一个字段的口径，以前是下游报表出错，被人发现、修掉；现在是 Agent 拿着旧的理解继续跑，产出看起来正常的错误结论。元数据的覆盖率、口径的结构化、变更的纪律，这些过去的「软要求」全变成了硬约束。
反过来说也成立：基建烂的公司，这套架构建不起来。Agent 不会修好混乱的元数据，只会更快地把混乱暴露出来。
真正的难点：Work Loop
架构图好画。这套东西能不能运作起来，取决于一个最容易被省略的环节：工作闭环（Work Loop）。
我们把工作方式定义成三段：Plan、Exec、Eval，前一段的输出就是后一段的输入。
Plan 是把模糊的业务问题变成一份明确的计划，目标、路径、资源、风险、验证标准都写清楚。中间要过两道加工：先在数据里做洞察发现，再把洞察收敛成策略。比如业务方的问题是「新用户留存上不去」。数据里翻出来的症结：首日没有完成一次完整播放的新用户，次日大多不回来。策略随之明确，首日引导只做一件事，促成第一次完整播放。落到计划上：灰度一部分新用户，Holdout 观察两周，次留提升不足 0.5% 就退出。当然计划是和业务方共建的，不是接过需求就开工。
Exec 拿着计划和工具去落地，交付的是策略、模型、系统这类能跑起来的东西。Agent 处理能标准化的 80%，人只在四种情况下介入：计划不可行、需要业务判断、发现新的洞察、Agent 遇到边界 case。执行中能复用的能力沉淀为 skill，下次不用重做。
Eval 是最容易被跳过的一段。传统的数据工作交付完就结束了，没人回头拿结果对照当初的计划。Eval 要回答三个问题：计划达成了吗，归因清晰吗；基础设施够用吗，Context 缺了什么；哪些环节下次可以更自动化。根据这些答案：反馈回流，更新 Context、沉淀 skill、训练 Agent；继续做新的洞察，触发下一轮 Plan。
Loop 断在任何一环，前面两条主线都很难规模化交付。
为什么叫 Harness
我把这套架构叫 Data Harness。Harness 在 AI 工程里指围绕模型的那层脚手架：模型本身的能力是给定的，让它真正干成活的是外面这层结构。Claude Code 和裸的 API 用的是同一个模型，能力差距全在 harness。
数据团队的处境类似。数据本身就在那里，决定它发挥几成价值的，是围绕它的这套结构：洞察怎么沉淀，策略怎么编译，Context 怎么积累，反馈怎么回流。
这也回答了 Agent 时代数据团队的角色问题。过去是需求响应者，业务问什么答什么；建好 harness 之后，是工作闭环的驱动者。相应的，考核也需要调整：从需求响应速度，换成 Plan 达成率和 Agent 接管率。这个转变对团队意味着什么？之前在「我为什么要把数据团队从写 SQL 转向训练 Agent」里写过。