数据工程Agent，终于要进真实仓库考试
你让AI写一段SQL，像让人回答一道单独的数学题；让它维护数据仓库，则更像把它送进一家公司，要求先读懂账本、流程和旧规矩，再修好一条出错的报表生产线。后者才接近日常数据工程，也更容易暴露Agent究竟会做工程，还是只会生成看起来合理的代码。
据Snowflake-Labs官方GitHub仓库，Snowflake-Labs开源了data-eng-bench：一套面向“仓库级数据工程”的Agent评测工具。它不只检查孤立的SQL答案，而是把Agent放进可执行的dbt项目。dbt是一种用SQL和工程规则管理数据转换的工具，团队用它把原始表加工成可靠的业务表，并维护测试、依赖关系和文档。
目前关于任务设计、规模和运行方式的信息均来自Snowflake-Labs这一个机构信源。它比最初的帖子提供了更多细节，但尚不能算独立验证。
考的不是一道题，而是一整个项目
所谓“仓库级任务”，是指Agent必须同时理解多个文件、数据表之间的依赖，以及项目已经采用的命名和开发约定。它可能需要按一张工单修改或创建模型，运行dbt，再根据结果继续排错。换句话说，评测对象从“能否写出一句SQL”，变成“能否在现有工程里把事情做完”。
官方仓库称，data-eng-bench使用一个大型仿真零售数据仓库，共设计103项任务。其中包括65项分析任务、16项开发与修错任务、9项维度建模与快照任务，以及13项数据工程任务。难度分布为3项简单、47项中等、45项困难和8项极难。
维度建模是把业务数据整理成便于稳定分析的结构。例如，把订单放进事实表，再连接客户、商品和日期等维度表。它考的不只是语法，还要求Agent理解业务数据应该怎样组织。
每项任务都在容器化的dbt项目中运行。容器可以理解为一间预先布置好的独立工作室，里面装好了项目和运行环境。Agent完成修改并执行dbt后，隐藏的pytest验证器会把最终数据表逐行与参考结果比较。验证规则不提前公开，因此更难靠迎合几个公开样例过关。
两种后端，考不同层次的能力
data-eng-bench的同一批任务可以在DuckDB或Snowflake上运行。DuckDB模式不要求Snowflake账户，并提供封闭环境，适合较容易复现的测试。Snowflake模式则进一步检查Agent能否处理Snowflake SQL方言、warehouse、角色和平台惯例。这里的warehouse指执行和管理数据计算的资源环境，不只是存放数据的“仓库”。
基准运行在Harbor框架上，可以接入Claude Code、Codex、Cortex Code和Terminus等该框架支持的Agent。官方还提供30题快速子集，方便先做成本较低的试跑。
榜单也不只收一个最好看的数字。按照官方规则，每项任务至少运行3次，提交者要公开上传结果并发起PR；CI自动流程会验证提交，维护者还会检查Agent的执行轨迹。这些要求有助于观察结果是否稳定，以及Agent是否通过不恰当的捷径完成任务。
为什么这一步值得看
这套评测最重要的变化，不是题量增加，而是把上下文和执行过程放回考试。真实的数据工程维护很少从空白文件开始：一个改动可能牵动上游原始表、下游报表、测试和既有约定。只考SQL生成，会漏掉这些彼此关联的工作。
data-eng-bench因此提供了一个更接近日常维护的观察窗口：Agent能否读懂项目，跨文件修改，运行工具，并让最终数据正确。不过，“更接近”不等于“已经代表生产环境”。官方所说的“enterprise-scale”和“真实数据工程工作”，在这里落实为大型仿真零售仓库中的可执行任务，并不意味着使用了企业客户的真实生产数据。
局限与未知
- 现有信息仍由Snowflake-Labs单一机构提供，缺少独立复现或第三方审计。
- 材料没有给出各Agent的基线成绩，因此现在还不能判断哪种Agent表现更好，也不能据此宣称它们已经胜任生产数据管道。
- 仿真零售项目覆盖了多类任务，但它能在多大程度上代表其他行业、团队规范和长期维护压力，仍需更多评测回答。