日期：2026-04-20 背景：本文是对《Everybody Talks About It, Nobody Knows What It Is — Harness Engineering 到底是什么》的延伸讨论，聚焦 data infrastructure 领域。
在那篇主文章中，我们分析了 agent 让传统软件可靠性保障链条（防错、观测、状态管理、验证、治理）同时失效的五面墙。Data infra 团队撞上的是同样的五面墙，但墙的形状不一样。原因是 data infra 有一个区别于其他工程领域的核心特性：数据是有下游消费者的，而且下游消费者的需求你不一定知道。
一个 coding agent 写出的代码，你可以跑测试、看结果、判断对错。一个 data agent 产出的数据（清洗结果、ETL 转换、schema 推断、数据质量报告），它的”对错”取决于下游谁在用、怎么用。数据分析师用来做 dashboard，数据科学家用来训模型，业务团队用来做决策，各自的质量标准完全不同。这意味着 data infra 领域的 harness engineering 面对一个额外维度：你不仅要管 agent 的行为，还要管 agent 产出的数据在整个组织中如何流动和被消费。
错误的组合爆炸在数据管线中更隐蔽。 代码层面的错误通常会报异常、会 crash。数据层面的错误经常是静默的：一个 agent 把日期格式从 YYYY-MM-DD 改成了 MM-DD-YYYY，下游 join 不报错，只是结果悄悄变成了空集或者笛卡尔积。传统数据工程用 schema validation 和 data contract 来防这类问题，但这些手段假设数据转换的行为是确定的。当 agent 参与 ETL 逻辑（比如用 LLM 做实体识别、地址标准化、非结构化文本解析），同样的输入每次可能产出略有不同的结果，schema 层面看不出问题，语义层面已经出了偏差。
观测的对象从”管线有没有跑通”变成了”数据有没有变味”。 传统的 data observability（Airflow 任务成功率、数据延迟、行数变化、null 率）度量的是管线的运行状态。Agent 参与之后，管线可能每次都成功跑完，行数看起来正常，但数据的语义质量在漂移。举一个场景：agent 负责把客户反馈分类为正面/负面/中性。初期很准，随着 prompt 理解漂移，越来越多的”中性”被归为”正面”。你的 dashboard 显示客户满意度在上升，实际上什么都没变。传统 data observability 工具（Monte Carlo、Anomalo、Great Expectations）度量的是统计分布的变化，但分类漂移这种语义层面的变化可能不会触发分布告警。
State management 在数据领域叫 lineage，而 agent 让 lineage 变得不确定。 数据工程这几年花了很大力气建 data lineage：从源表到目标表，每一步转换都有记录，出了问题可以追溯。但 agent 引入了一个变量：同样的 lineage 路径，agent 每次走的逻辑可能不一样。一个 text-to-SQL agent 对同一个自然语言查询可能生成不同的 SQL，join 不同的表，用不同的 filter 条件。Lineage 追踪的是”数据从哪来”，但现在这个”从哪来”本身是概率性的。如果一个下游报表的数字出了问题，你顺着 lineage 追上去，发现 agent 上周用了 LEFT JOIN，这周用了 INNER JOIN，你的 lineage 图谱记录的是哪一次？
验证面对的是数据正确性的定义模糊。 代码的验证标准相对清晰：功能对不对、性能够不够、有没有 regression。数据的验证标准本身就是模糊的。什么叫”地址标准化得对”？纽约市的地址和农村地址的标准化规则完全不同。Agent 做数据转换时，验证标准不能只是”输出格式正确”，需要引入领域专家的判断。而且数据量大、人工 review 成本高，你没办法像 review 代码那样逐行看。需要的是抽样 + 统计置信度的验证方式，这和前面文章中讲的”从 pass/fail 到持续评估”是同一个转变，但在数据领域执行起来更复杂，因为评估标准本身依赖业务语境。
治理面对的是 agent 对生产数据的写入权限。 Coding agent 出错了，最坏的情况是写了一段有 bug 的代码，你可以 revert。Data agent 出错了，它可能已经把错误的数据写进了生产数据库，下游的 dashboard、ML 模型、业务报告都已经消费了这些数据。Immuta 把这个问题叫做 identity explosion：传统的 data governance 为有限数量的人类用户设计，这些用户有固定的工作时间、可预期的访问模式、需要走审批流程。Agent 以机器速度请求数据访问，7x24 运行，不填表。现有的 RBAC 系统没有为这种访问模式设计过。一个具体的问题：一个辅助医学研究员的 AI agent，应不应该拥有和研究员相同的数据访问权限？现有系统往往默认给相同权限，但 agent 可能会扫描整个 schema、读取数百万行数据来构建上下文，这和研究员手动查几张表的行为模式完全不同。在金融、医疗、合规这些对数据准确性有法规要求的领域，这个问题尤其尖锐。
除了五面墙的 data 版本之外，data infra 还面对几个其他领域没有的问题。
第一，数据有记忆，代码没有。 代码部署出错了你可以回滚到上一个版本。数据一旦被 agent 修改并写入生产，回滚可能意味着要重新处理几天甚至几周的数据，下游所有消费过这些数据的系统都要跟着重算。数据的不可逆性让 harness engineering 中的”error recovery”在数据领域成本高出一个数量级。
第二，数据的消费者链条很长。 Agent 产出的代码，消费者通常就是跑这段代码的系统。Agent 产出的数据，消费者可能是十几个下游团队、几十个 dashboard、若干个 ML pipeline。任何一处数据质量问题都会沿着这条链条扩散。这要求 data infra 的 harness engineering 不仅要管 agent 本身的行为，还要管数据在组织中的传播路径。
第三，Text-to-SQL 和自然语言查询带来的新攻击面。 越来越多的团队在用 agent 把自然语言翻译成 SQL 查询。生产环境中的表现远低于 benchmark 预期：Pinterest 发现首次接受率只有约 20%，Salesforce 的 text-to-SQL agent 上线初期准确率只有 50% 左右，需要对同一个 prompt 生成 10 条候选 SQL 再通过一致性筛选才提升到约 80%。Google Cloud 总结了六类典型失败模式，其中最隐蔽的一类是：同一个”收入”查询，agent 每次可能 join 不同的表或选择不同的排序字段，返回看起来合理但数值不同的结果，用户无法判断哪个是对的。更严重的是权限问题：在一个 35 张表的企业 schema 测试中，agent 把每个用户当作数据库管理员，意外暴露了供应商定价和可靠性评分等竞争敏感数据。传统的 data governance 不需要考虑”查询本身是 AI 生成的”这个变量。
Data infra 社区已经有一些应对方案在演进。
Data contract（定义上下游之间的 schema 和语义约定）是目前最接近 harness 概念的实践。但现有的 data contract 工具（Soda、dbt tests、Great Expectations）主要验证结构和统计分布，对语义层面的验证能力有限。当 agent 参与数据转换后，需要的不只是”这一列是不是整数”或者”null 率有没有超过 5%“，而是”这个地址标准化的结果在业务语境下是不是合理的”。
Data observability 平台（Monte Carlo、Bigeye、Anomalo）在检测分布漂移方面做得不错，但对 agent 引入的语义漂移缺乏手段。一个分类从”中性”变成”正面”在统计分布上可能只是一个不显著的偏移，但在业务含义上可能完全不同。
Lineage 工具（OpenLineage、Marquez、Atlan）追踪的是静态的数据流图。Agent 让数据流图本身变成了动态的（同一个 agent 节点每次生成不同的查询），现有的 lineage 工具还没有对此做出适配。
结合上面的分析，data infra 团队在引入 agent 时可以考虑以下几个切入点。
在 agent 和生产数据之间加一层 staging。Agent 产出的数据先写入 staging 层，经过验证之后再 promote 到生产。这在概念上类似于 code review：你不让代码直接部署到生产，数据也不应该。验证可以是自动化的（schema check + 分布检查 + 采样人工 review），也可以分级（低风险的自动通过，高风险的需要人工确认）。
把 data contract 从结构层扩展到语义层。现有的 data contract 主要定义 schema 和基本约束。Agent 参与之后，contract 需要增加语义层的约定：这个分类字段的含义是什么，什么样的变化模式是正常的，什么样的漂移需要告警。这本质上是在做前面文章中讲的”为非结构化产出建立度量体系”。
对 text-to-SQL agent 做 query sandboxing。生成的 SQL 在执行前经过静态分析：有没有访问不该访问的表，预估的计算量是不是在合理范围内，有没有遗漏 WHERE 条件导致全表扫描。这些检查在传统 SQL 开发中也有，但 agent 生成的 SQL 不可预测，需要每次都检查。
建立数据版本和快照机制。在 agent 做数据变更之前，自动创建 snapshot。这样出了问题可以回滚到变更前的状态，降低”数据有记忆”带来的不可逆风险。
Data infra 的 harness engineering 和通用的 harness engineering 面对的是同一组原则性问题，但执行环境的差异让问题在两个维度上更严重。第一，失败模式是静默的：一个确定性系统在 schema 变化时会报错，一个概率性 agent 会生成看起来合理但数值错误的结果并继续运行。第二，影响范围更大：一个 chat agent 做了错误判断影响的是一次对话，一个 data agent 写入了错误数据影响的是消费这些数据的所有下游系统。核心差异在于：数据是有下游消费者的、有记忆的、语义是模糊的。这三个特性让 data infra 在五面墙的每一面都有自己特有的表现形态，也需要自己特有的工程实践来应对。
对于已经在做 data contract、data observability、data lineage 的团队来说，好消息是你们已经在做 harness engineering 了，只是没有这么叫。需要做的调整是：把这些工具和实践从”假设数据转换是确定性的”升级到”假设数据转换中有概率性组件”。这个升级的方向和力度，取决于你的 agent 在管线中承担了多大比例的转换工作。