Claude Code、Codex都能做数据工程，Snowflake为什么还要重做CoCo？

图 1｜Snowflake CoCo 官方产品图。来源：Snowflake 官方博客

01

同一个模型，为什么会出现 3.9 倍成本差？

8 月 6 日，Snowflake AI Research 与 Bespoke Labs 开源 data-eng-bench。该 Benchmark 包含 103 个任务：65 个分析类、16 个开发与 Bug 修复、9 个维度建模与 Snapshot，以及 13 个偏工程的增量模型、跨数据库和跨数仓转换任务；难度涵盖 easy 至 very hard。与传统 NL2SQL 或代码生成 Benchmark 不同，每个任务都将 Agent 置于容器化的 dbt 项目中，模拟真实工单需求。Agent 需读取项目、修改或创建 dbt 模型、实际运行 dbt，最后由隐藏的 pytest Verifier 对物化结果逐行核验。换言之，评估标准不再是"SQL 看起来是否合理”，而是最终数据管道是否产出正确结果。官方仓库同时提供 DuckDB 与 Snowflake 两种后端，支持在封闭本地环境或真实 Snowflake 环境中验证方言、Warehouse、Role 等平台相关能力。

图 2｜data-eng-bench 任务构成。根据 Snowflake-Labs/data-eng-bench 官方 README 整理

更有意思的是 Harness 对比。实验结果显示，在 Opus 5 上，CoCo 的 Pass@1 为 73.8%，Claude Code 为 69.6%，相差约 4 个百分点，但 CoCo 成本低约 3.9 倍；在 Sonnet 5 上，两者 Pass@1 均为 56.6%，CoCo 成本低约 2.3 倍；在 GPT-5.6 Sol 上，CoCo 的 Pass@1 为 64.1%，Codex 为 60.5%，高出 3.6 个百分点，同时成本低约 1.5 倍。实验设计的核心并非比较“不同模型谁更强”，而是固定底层模型，将 Harness 作为主要变量。相同模型进入不同 Agent 系统后，最终成本大幅变化，说明“模型能力”与"Agent 完成任务的工程效率”已是两个需分开讨论的问题。

表 1｜data-eng-bench 中相同模型、不同 Harness 的公开结果。来源：Snowflake 官方实验

因此，这组结果不应被简单解读为"CoCo 已证明优于 Claude Code/Codex"。Benchmark 由 Snowflake 参与设计，CoCo 是其自研的数据原生 Agent，任务围绕 dbt 与数据仓库工作流展开，平台原生能力天然占优。更稳妥的解读是：这组实验首次揭示了一个长期被“模型分数”掩盖的问题——同样的模型，只要上下文组织、工具边界、执行策略和停止条件不同，Agent 就会走出完全不同的轨迹，而轨迹直接决定 Token 消耗、Tool Call 次数、延迟和成本。

拆解真实数据工程任务会发现，SQL 生成往往只是中间一小段。Agent 首先需理解工单，判断应查看哪些 dbt 模型、Source、字段和依赖；接着探索 Schema 和数据分布，确认 Join 粒度、时间范围、NULL 处理、业务边界及已有模型约束；写完代码后还需运行 dbt、检查物化结果、处理报错、比对数据，再决定是否回溯。任何一步的不确定都会导致 Agent 进入“读取—查询—修改—执行—再读取”的循环。对于普通软件工程，仓库目录、类型定义、测试和编译错误提供了清晰的搜索边界；但对于数据工程，代码之外还存在更大的环境：Catalog、Schema、真实数据、权限、Lineage、模型依赖和业务规则。

data-eng-bench 刻意构建了足够大的环境。Snowflake 公开的实验环境包含 579 张源表、19 个 Schema 和约 8000 个字段。在此规模下，“模型会不会写 SQL"不再是难点，难的是能否迅速判断下一步该看什么。Snowflake 对 Opus 5 轨迹的分析显示，CoCo 平均使用约 1.5 倍更少的 Tool 操作和 2.2 倍更少的 Agent 步骤；整体 SQL 查询约少 1.7 倍，文件写入约少 1.9 倍。细分来看，两类 Agent 都将大量工作花在开发前的数据探索和开发后的验证阶段，但通用 Harness 更容易在中间反复重读文件、重复 Profile 数据、做额外的跨方言验证或再次检查已确认信息，而 CoCo 更倾向于先集中探索、形成计划，再写入、构建、验证并停止。

这也解释了为何 Sonnet 5 的结果尤其值得关注：两套 Harness 的 Pass@1 完全相同（均为 56.6%），但成本仍相差约 2.3 倍。这意味着，即使最终都能完成同样数量的任务，一个 Agent 仍可能因多走几轮探索、多发几次 SQL、多读几遍文件而显著更贵。对于生产中的 Data Agent，这类差异会被高频任务成倍放大。于是优化目标不再只是“提高几个百分点的成功率”，还必须包括：能否更快缩小搜索空间、能否减少无价值验证、能否在获得足够证据时及时停止。Harness 的价值，本质上开始表现为对 Agent Loop 的压缩。

通用 Coding Agent 的 Harness 通常围绕代码仓库组织：文件读取、代码搜索、Terminal、Git、测试、权限和执行循环。接入数据库 Tool 后，它当然也能做数据任务，但数据库并非“代码仓库旁多一个工具”那么简单。Data Engineering Agent 要处理的是一个会变化、可查询、受权限控制的运行环境。它不仅要知道文件位置，还要知晓当前 Schema、对象存在性、执行 Role、数据依赖、查询返回内容及修改是否真正改变最终物化结果。因而 Data-native Harness 需将 Context、Catalog、SQL Runtime、执行状态和验证机制纳入同一闭环，而非让模型每一步都临时从零发现环境。

图 3｜Snowflake 官方展示的 CoCo Agent Harness 架构：Live Schema、Context Layer、Environment State、Agent Skills 与 Runtime 被放在同一层。来源：Snowflake CoCo 官方产品页

Snowflake 对 CoCo 的描述强调，它并非在模型外套一个通用 Wrapper，而是针对数据生命周期设计专用 Harness。官方架构中，CoCo Agent Harness 上层接收自然语言任务，中间包含 Live Schema Injection、Agent Context Layer、Environment State、Agent Skills 与 Agent Runtime，下层直连 Snowflake Platform 的 Metadata、Compute、Storage、Governance、RBAC 及可选托管模型。这一结构的关键不在于“组件多”，而在于环境信息和运行状态被提升为 Agent 的一等上下文。对于数据工程，正确的 Context 不只是多塞几页 Schema，而是要在正确步骤暴露正确信息：探索时优先找到相关表和依赖，开发时保持已确认上下文，执行时让 SQL Runtime 返回可用于下一步判断的结果，验证时围绕业务边界确认完成度。

因此，更完整的 Data Engineering Agent 架构可从"Model + Database Tool"改写为"Model + Data-native Harness + Catalog + SQL Runtime + Validation + Business Context"。其中，Catalog 的作用不是将整个数据仓库一次性塞进 Context，而是帮助 Agent 缩小当前任务的搜索范围；SQL Runtime 也不只是让模型有能力执行 SQL，而是同时承担探索、诊断和验证；Validation 更不是最后跑一次 Test，它决定 Agent 何时可确信结果满足要求并停止修改。真正高效的 Harness 不是让模型看见更多，而是让模型在每一步只看见足够而正确的内容，并提前剪掉不必要的路径。

data-eng-bench 最值得 Data Engineering 社区关注之处，在于它将评估单位从“模型”推向了“模型 × Harness"。过去讨论 NL2SQL 或 Coding，最常见的问题是哪个模型准确率更高；但到了 Agent 阶段，用户实际部署的从来不是一个裸模型，而是一整套包含 Context、Tool、Planner、Runtime、Memory、权限和验证机制的系统。模型依然决定能力上限——在 CoCo 这一个 Harness 内，不同模型的 Pass@1 仍有明显差距；但 Harness 决定了 Agent 接近这个上限时要付出多少无效步骤。对于数据工程这种强环境依赖任务，这个差异会比普通代码生成更加明显。

当然，Snowflake 的结果仍需带着边界来读。第一，Benchmark 与 CoCo 均来自 Snowflake 体系，当前数据不能等同于独立第三方对不同产品的最终排名；第二，103 个任务虽覆盖分析、Bug 修复、维度建模、Snapshot、增量模型和跨 Warehouse 等场景，但主体仍是 dbt 项目，无法代表数据工程从采集、编排到实时处理、治理、发布的全部生命周期；第三，CoCo 的优势部分源于其对 Snowflake 环境的原生理解，这说明"Data-native"有效，但也意味着这种优势是否能迁移到完全不同的数据栈，需要更多独立实验。好在 data-eng-bench 已开源并提供 DuckDB 版本，其他 Agent 和 Harness 可在相同任务上自行复现，这比单纯看厂商给出的排行榜更有价值。

如果将这组实验真正转化为 Data Agent 的工程指标，后续值得重点关注的就不应只有 SQL 正确率，而应同时观察：任务最终是否完成、每个成功任务的成本、平均需要的 Agent Step 和 Tool Call 数量、探索与验证阶段的重复动作比例、Agent 是否能在证据充足后停止，以及面对错误时的回退路径长度。这样的指标更接近真实生产系统，因为企业最终购买的不是“模型会不会写一段漂亮 SQL"，而是一个能不能在可接受的成本和风险内，把数据任务真正做完的执行系统。

Claude Code、Codex 当然可以继续进入数据工程，它们也会越来越强；但 data-eng-bench 提出的挑战是，当通用 Coding Agent 开始面对数百张表、数千个字段、真实权限和业务边界时，仅仅增加 Database Tool 可能还不够。未来的竞争很可能发生在模型之外：谁能把 Catalog、业务上下文、运行时和验证组织成更短的 Agent Loop，谁就能在相同模型能力下，以更少 Token、更少查询、更少无效修改完成同一件事。也许 Data Agent 最费 Token 的地方，从来不是写 SQL；真正昂贵的是，在一个复杂的数据世界里，不知道下一步该去哪里。

资料来源与说明

• Snowflake Engineering Blog：Introducing Data-eng-bench: Why You Need"Data-Native"Harnesses for Data Engineering

• Snowflake-Labs/data-eng-bench（GitHub 官方开源仓库）

• Snowflake CoCo 官方产品页

• Snowflake Builders Blog：Same Model, 3.9x Cheaper: The Harness Is the Difference

注：文中关于 CoCo、Claude Code、Codex 的对比数据均来自 Snowflake 公开实验，应理解为特定 Benchmark 与特定配置下的厂商实验结果，不等同于第三方独立复现或通用产品排名。

点个在看你最好看

SPRING HAS ARRIVED