DataClawEval：五大引擎100个真实任务，最强Agent得分仅74.9
DataClawEval: A Benchmark for Data Engineering Agents in Real Industrial Harness
在现有的大模型基准测试里，数据处理相关的任务大多停留在相对温和的“象牙塔”环境中。以 Spider 和 BIRD 为代表的 Text-to-SQL 评测，考察的核心本质上是单步语义解析；而 InfiAgent-DABench 或 DA-Code 这类数据分析评测，往往让模型面对单张 CSV 表格，通过几行 Python 代码计算均值、回归拟合或绘制图表。然而，真实企业环境中的数据工程（Data Engineering）远比编写一段孤立的 SQL 脚本或 Python 片段复杂得多。
ArXiv URL：https://arxiv.org/abs/2607.28033
一个合格的企业数据工程师，拿到模糊的业务需求后，首先要自主探查缺少完备文档的元数据，理解跨域业务语义；随后在异构计算引擎中编写复杂的数据清洗与转换逻辑；并在任务执行报错时，根据控制台日志多轮调试，直至目标数据准确落盘物化。为了填补学术评测与工业落地之间的鸿沟，研究人员推出了首个面向真实工业环境的数据工程 Agent 评测基准——DataClawEval。
这项工作完全基于企业一线专业工程师编写的生产级代码构建，涵盖 100 个端到端的离线批处理与在线实时流计算任务，横跨 PySpark、HiveSQL、MySQL、PrestoSQL/Trino 以及 FlinkSQL 五大工业级执行引擎。在完全隔离的容器化沙箱与确定性规则脚本的严格检验下，研究团队对 16 款前沿大模型构建的 Agent 进行了全方位摸底。评测结果给当前狂热的 Agent 落地潮浇了一盆冷水：表现最好的模型综合得分仅有 74.9 分；更关键的是，没有任何一个模型能够统领全局，各家模型在不同引擎上呈现出高度割裂的“偏科”现象，真实场景下的自主数据工程依然是一个远未解决的严峻挑战。
为什么现有数据基准无法评测真正的数据工程？
工业界对“数据工程”的定义，从来不是静态地输出一段文本代码，而是一套闭环的工程实践。在过去的评测体系中，主要存在三类局限明显的流派。第一类是传统的 Text-to-SQL 基准，无论题库设计得多么庞大、脏数据多么复杂，其目标始终局限于“给定固定 Schema，写出单条查询语句”，完全忽略了端到端的数据管道（ETL Pipeline）构建与数据物化。第二类是基于代码执行的数据分析基准，模型通过执行 Python、SQL 或 Bash 命令回答一个封闭式的统计数值，判断标准仅是最终数值是否一致，根本不关心代码是否具备工业部署价值。第三类则是近来出现的跨模态或探索性分析评测，侧重于非结构化信息的检索整合，依然与企业底层的批流计算架构脱节。
即使是少数涉及工程管道的研究（如 ELT-Bench），往往也局限在单一的数仓技术栈内，缺乏对企业异构系统的还原。在实际业务中，离线数仓可能依托 Hive 或 Presto，交互式查询依赖 MySQL，大规模分布式计算需要 PySpark，而高吞吐的实时看板则完全依赖 Flink 的流式处理机制。不同引擎对于时间属性、水印（Watermark）、窗口聚合、分区修剪的处理逻辑大相径庭。
DataClawEval 试图打破这种割裂。它要求 Agent 在一个完全交互式的运行时环境中工作：没有预先注入的完美 Schema 先验，Agent 必须通过命令行与数据库工具主动探索表结构；面对包含多表关联、时间戳截断、边界异常处理的复合需求，编写可执行代码并提交给真实引擎运行；在遇到引擎报错时自主捕获上下文并迭代修复；最终在真实的存储介质中生成结果表。评测考核的不仅是“代码写得像不像”，而是“管道能不能跑通、数据对不对、工程行为规不规范”。
从企业源码到确定性评测：构建可判别的沙箱世界
将企业生产环境中的工程代码直接搬进基准测试是不现实的，因为真实代码往往强依赖特定的内网基础设施，且输入输出过于庞大，难以进行低成本的自动化判别。为了解决这一难题，DataClawEval 团队设计了一套融合“人在回路（Human-in-the-Loop）”的任务重构与验证管线。
如上图所示，整套流水线从企业脱敏源码切入。研究人员首先对生产环境的代码片段进行清洗和特征采样，随后借助大模型逆向重构任务意图，并针对性地合成输入测试表。为了确保合成数据能够精准检验逻辑漏洞，该流水线引入了双向对抗验证：一方面让 Agent 实际执行测试，另一方面由资深数据专家对代码进行边界扰动（Perturbation）。如果一套测试数据无法将正确的基线代码与带有边界错误的扰动代码区分开，输入数据就会被推翻重做，直到其具备高度的“错误可鉴别性”。最后，领域专家对意图描述、输入表、参考实现以及评分脚本进行联合人工复审。
在评测执行层面，DataClawEval 彻底摒弃了当前风靡但饱受诟病的“LLM-as-a-judge（大模型当裁判）”方案。在数据工程这种容错率极低的工业场景下，大模型作为裁判表现出了极强的不可靠性。论文中的对比实验揭示，让主流模型依据细颗粒度评分细则进行文本判分时，LLM 裁判往往会严重高估生成代码的质量，甚至打出超越规则上限的分数，评分方差极大。根本原因在于，基于文本的 LLM 裁判无法观察运行时的实际状态，极易被表面工整但逻辑崩塌、运行时必定报错的代码所蒙蔽。
因此，DataClawEval 采用全自动化的确定性规则脚本进行判分。每个任务都运行在独立的 Docker 沙箱容器中，容器内预装了相应的计算引擎服务、客户端以及命令行调试工具，实现用例间的环境隔离与防信息泄露。评分机制兼顾结果与过程，综合得分公式定义为：
\[\mathrm{Score}=\alpha S_{\mathrm{artifact}}+(1-\alpha)S_{\mathrm{process}}\]其中，产物得分 $S_{\mathrm{artifact}}$ 通过校验目标表是否存在、Schema 字段类型是否吻合，并对物化数据进行逐行逐单元格的精确比对；过程得分 $S_{\mathrm{process}}$ 则记录 Agent 在探索元数据、错误重试、执行频次上的工程合理性。在基准默认设置中，权重 $\alpha$ 取 0.7，既高度聚焦于数据交付的准确性，又对低效、鲁莽的暴力重试行为进行合理扣分。
16款主流模型实测：没有全能选手，行业天花板依旧高悬
研究团队在 DataClawEval 上对 16 款主流前沿模型驱动的 Agent 进行了严格的标准测试。评测覆盖了 100 个任务（中英文描述各占 50 例），横跨金融、电商、广告等五大核心业务领域。
实验数据表明，当前没有任一模型能够轻松驾驭企业级数据工程。在满分 100 分的测试集上，综合表现最佳的模型也仅仅拿下了 74.9 分，而模型间的整体表现分布在 60.3 分到 74.9 分的宽幅区间内。这一结果充分证明了基准的设计具有足够的区分度和广阔的能力天花板，既未出现全员不及格的崩溃现象，也彻底避免了传统基准迅速饱和失效的尴尬。
更具洞察力的发现是，不同模型在各类引擎上的能力分布呈现出鲜明的非对称性。在以离线批处理为核心的 PySpark 和 HiveSQL 场景中，部分以深层代码逻辑推理见长的模型表现亮眼；而在语法约束严格、对时态与窗口语义极度敏感的实时计算引擎 FlinkSQL 上，大量模型的表现出现了断崖式下跌，许多在传统 SQL 任务上游刃有余的系统甚至无法正确声明流式水印与时间属性。综合得分领先的模型，往往在某几个特定引擎上拿到高分，但在其他引擎中却被竞争对手反超。数据工程技术栈的异构性，无情地戳破了“通用全能 Agent”的神话，证明了底层计算架构的理解能力依然高度专业化。
与此同时，任务的语言形式对执行结果没有构成统计学上的显著障碍。在 50 道中文任务与 50 道英文任务的横向对比中，绝大多数模型展现出了稳定的双语跨越能力，得分差异主要来源于底层的工程逻辑复杂度与引擎方言壁垒，而非表层的自然语言理解。
Token消耗不等于质量，频繁试错只是“伪勤奋”
在探索大模型解决复杂工程任务的过程中，人们往往直觉地认为：给予模型更充裕的思考空间、允许其进行更多轮次的交互调试并消耗更多 Token，就应当换来更好的解决方案。然而，DataClawEval 呈现出的实验事实却恰恰相反。
评测中的 Token 消耗量呈现出惊人的离散度，各模型处理单任务的平均 Token 消耗差距超过 4 倍，且该消耗与最终得分不存在任何正相关关系。部分低成本模型凭借紧凑的提示词结构和极高的单次交互效率，以每任务不足 300k 的 Token 开销稳扎稳打；而某些模型单任务消耗逼近 1000k（在特定复杂查询场景下甚至突破 1500k），最终得分却在中间梯队徘徊。过度的冗长推理和反复的无效代码重写，本质上是模型陷入推理死循环与无序排错的表现，非但无法弥补逻辑漏洞，反而大量浪费了计算资源。
上图揭示了工具调用频率与任务得分之间的真实关联。在统计中，工具调用次数与最终表现几乎毫无线性关系可言。散点图以中位数（工具调用约 16.3 次，得分约 71.1 分）为界被划分为四大象限，清晰地展示了四种截然不同的工程行为模式：
-
高效型系统（图中绿色区域）：这类 Agent 位于高分、低调用频次象限。它们通常在动作发起前具备极为清晰的解题规划，先有针对性地探测元数据，随后一击即中地编写出合规的批流作业代码，只需极少量的校验与微调即可完成数据交付。
-
低效挣扎型系统（图中橙色区域）：位于低分、高调用频次象限。这类 Agent 缺乏结构化排错能力，一旦遇到引擎编译或运行时报错，便习惯性地进行盲目试错，频繁调用 Bash 或引擎终端疯狂打印日志或重试代码，最终在耗尽上下文或时间窗口后依旧无法产出合规数据。
-
其余模型则散布在灰色区域，要么由于过早放弃导致调用不足且得分低下，要么展现出一般的工程均衡性。
这一深度分析给未来的 Agent Harness 与系统设计带来了关键启示：在真实工程环境中，盲目追求更多的 ReAct 思考步数或放任工具调用自由发散是低效且危险的。决定数据工程 Agent 天花板的核心，在于面对复杂依赖关系时的精准规划能力，以及从真实的执行引擎报错反馈中提取有效线索的深度 Debug 能力，而非流于表面的调用次数堆叠。
走出单步生成的温室
从宏观技术演进的角度审视，DataClawEval 的诞生不仅是提供了一个测试集，更是对整个代码与数据领域 Agent 研究范式的一次校准。它促使研究者们重新审视一个关键命题：当大模型已经能够非常熟练地在 LeetCode 或单句 SQL 翻译中刷出高分时，它们究竟离接管真实的工业数据中台还有多远？
真实的工业数据场景是严苛且容错率极低的。下游看板的微小口径偏差、分布式作业中的数据倾斜、流处理中的乱序迟到数据，任何一个环节的工程疏漏都会导致整条数据流水线的崩溃。以往那些将任务切碎为简单问答的评测，掩盖了模型在面对长链路依赖、缺少完备文档、异构执行方言交互时的脆弱性。
DataClawEval 明确了这一进阶方向的评测基准：坚持以隔离沙箱为基础，以真实企业计算引擎为依托，以逐行对账的确定性代码为判决法则。唯有走出静态代码生成与 LLM 自评的舒适区，让 Agent 在真实的批流引擎中面对运行错误、面对冷冰冰的行级数据检验，我们才能真正筛选并培育出能够在工业界稳定立足的数据工程自主系统。