给Agent扔进980个文件的"垃圾堆"，它还能写对代码吗？

你有没有想过一个问题：现在的 Coding Agent 在 SWE-Bench 上刷得风生水起，可一旦你把它丢进一个真实的数据目录——几百个 CSV、JSON、Parquet、还有几张莫名其妙的图片和 PDF 混在一起——它还能找到那个对的文件，然后写出对的代码吗？

这篇 ICML 2026 的 CoDA-Bench 给的答案有点扎心：最强的系统，成功率只有 61.1%。

一段话讲清楚这篇论文在干嘛

现在评测 Coding Agent 的 benchmark，基本是两拨人各玩各的。一拨盯着"代码智能"——给你一个干净的仓库，看你能不能改对 bug（SWE-Bench、Terminal-Bench 这类）；另一拨盯着"数据智能"——给你几个明确的表格，看你能不能分析对（DS-1000、DA-Code 这类）。问题是，真实的开发场景从来不是这么干净的：你既要在一堆乱七八糟的文件里先找到该用哪个数据，又要写对处理它的代码。

CoDA-Bench 干的就是把这两件事缝起来评。作者基于 Kaggle 生态搭了一个数据密集的 Linux sandbox，平均每个任务环境塞进 980 个文件，Agent 从根目录开始、只拿到一句自然语言指令，必须自己去翻、去找、去写。最终造了 1,009 个任务，覆盖 31 个社区。结果是,即便是 SOTA Agent，端到端正确率也就 61.1%，到了 hard 子集只剩 49.6%。更关键的发现是:真正卡住 Agent 的不是写代码，而是"在垃圾堆里找对数据"这一步——给它直接喂上正确文件路径，准确率能瞬间涨 24 到 28 个点。

论文编号 arXiv:2606.15300，作者来自中国人民大学 DataLab（Yuxin Zhang、Ju Fan、Meihao Fan、Shaolei Zhang、Xiaoyong Du）。这是一篇做得很扎实的 benchmark 论文,我个人觉得它最值钱的地方,是第一次把"数据发现"这件被长期忽视的能力,单独拎出来量化了。

为什么需要这么个 benchmark？

说实话，我第一次看到这个设定的时候，是有点共鸣的。

我之前帮人调一个数据分析的 Agent，沙箱里就放了三五个文件，干净得很。Agent 表现挺好，demo 里一切顺滑。可真要接到实际业务的数据湖上——那种几百上千个文件、命名混乱、还混着历史遗留垃圾的环境——它立刻就懵了。它分不清 sales_2023.csv 和 sales_2023_backup_final_v2.csv 哪个才是该用的，更别说那些主题相关但跟当前任务八竿子打不着的"语义干扰项"。

这就是 CoDA-Bench 想戳破的那层窗户纸。看图 1 就很直观：

图1：CoDA-Bench 联合评估代码智能与数据智能

图1：左上是传统的代码智能评测（SWE-Bench 那一类），给你干净的代码让你改；右上是数据智能评测（DS-1000 那一类），给你明确的表格让你分析。而下方才是 CoDA-Bench 的设定——把 Agent 扔进一个混着 CSV、JSON、TEX、JPG、PDF 的"数据密集环境"，它得先从一堆文件里发现那个含国家名的表，再把 GDP 数据整合进去，最后才能得出结论。这才像真实开发。

作者把现有 benchmark 排了个队（Table 2），结论是：几乎所有人都只给 Agent "任务严格必需的 oracle 文件"，环境里要么就 1 个文件、要么至多 10 个。GAIA、SWE-Bench、DA-Code、DABstep、ScienceAgentBench……无一例外。CoDA-Bench 是第一个把"大规模、相关但未经筛选的数据"塞进评测环境的。

这个区别看着小，其实是质变。当环境里只有 oracle 文件时，"找数据"这一步根本不存在——文件就在那，你直接读就行。可一旦混进 979 个干扰项，"找对文件"本身就成了一道独立的、而且相当难的题。

怎么造出这么个 benchmark？三步走

造这种 benchmark 最难的地方在哪？在于噪声得像那么回事这件事。

你随便往目录里塞一堆无关文件，Agent 靠表面特征（文件名、格式）一眼就能滤掉，那这噪声就白加了。作者要的是 in-distribution 噪声——干扰文件得跟目标数据在主题和结构上都相似，但就是跟当前任务无关。这样 Agent 没法靠关键词匹配偷懒，必须做细粒度的语义推理。

整个构建流程分三步，图 2 画得很清楚：

图2：CoDA-Bench 的三步构建方法

图2：① 数据密集环境构建——用数据集共现图把语义相关的数据聚成社区；② 基于解决方案的任务构建——从真实 Kaggle notebook 里抽取有确定答案的"解决方案锚点"，反向生成问题；③ 对抗式任务演化——用一组判别器模型给任务打"求解率"，太容易就让生成器加难度，太难就诊断是不是题目本身有缺陷，最后过人工验收。

第一步：用"共现图"造语义噪声

这一步我觉得是整篇论文最巧的地方。

作者的洞察是：Kaggle 上的分析师写 notebook 时，会主动把主题相关的数据拉到一起用。所以两个数据集如果经常在同一个 notebook 里共同出现，它们大概率语义相关。基于这个，作者构了一张无向加权图，节点是数据集，边权重就是共现频率：

\[w(d_i, d_k) = \sum_j \mathbb{1}[d_i \in \mathcal{D}_j \land d_k \in \mathcal{D}_j]\]

然后用 Leiden 算法（分辨率 γ=1.0）做社区划分。对一个目标数据所在的社区，把整个社区的数据全塞进评估环境——目标之外的那些，就成了天然的、同分布的语义干扰项。

数字上，全 Kaggle 的图有 21,122 个节点、93,727 条边，Leiden 切出 323 个社区，模块度 0.711（这个值挺高，说明社区结构很清晰）。最后精选 31 个社区、829 个数据集进入 benchmark。

我挺欣赏这个思路的。它没有人为编造噪声，而是借用了真实世界里数据之间的关联结构——干扰项的"难度"是数据生态本身赋予的，不是作者拍脑袋设计的。

第二步：从真实 notebook 反向造题

光有环境还不够，得有题。作者用的是 solution-based back-construction（基于解决方案的反向构建）。

逻辑是这样：Kaggle notebook 里那些精确的数值结果——某个统计量、某个排名、某个相关系数——只要数据和计算流程固定，就能确定性复现。作者把这些叫"解决方案锚点（Solution Anchor）"。

具体做法：先用 LLM 静态分析，挑出那些"可验证且非平凡"的输出当候选锚点；再动态验证——找出产生这个锚点的最小输入文件集和变换序列，重新跑一遍，确认结果在 $\varepsilon=10^{-6}$ 的容差内能对上。确认无误后，再用 LLM 基于这个锚点和解题路径生成一道自然语言问题，要求问题说清目标但不泄露解法。最后所有问题过人工审核，剔除模糊的、有歧义的。

第三步：用对抗演化把题"磨难"

这一步借了 GAN 的思路。作者把任务演化建模成生成器 G 和判别器 F 的博弈：

\[\min_G \max_F \mathcal{L}(G,F) = \mathbb{E}_{q \sim G}[\mathbb{1}[F(q) = a_q]]\]

跟标准 GAN 的区别是，这里 G 和 F 都是 SOTA LLM，"更新"靠的是离散的任务修改而不是连续的梯度。判别器是 K 个模型的集成（从模型池里随机采），防止对某一个 LLM 过拟合。流程是：算出求解率，太高说明题太简单，让生成器看成功轨迹去加难度；太低就诊断到底是真难还是题目本身有毛病（措辞模糊、信息缺失、答案不唯一）。只有那些"内在难且确实可解"的，才进人工验收。

这套流水线的过滤效果，Table 1 写得明明白白：

阶段	数量	通过率
数据集社区	323	–
选中的社区	31	9.6%
收集的 notebook	30,624	–
选中的 notebook	1,361	4.4%
提取的解决方案锚点	1,395	–
直接通过演化的问题	742	–
修订后通过的问题	411	–
演化中被拒的问题	242	–
进入人工验证	1,153	82.7%
通过人工验证	1,009	87.5%
最终任务	1,009	总通过率 72.3%

从 323 个社区一路筛到 1,009 个任务，每一关都在做减法。我觉得这个 4.4% 的 notebook 选中率挺说明问题的——大部分 Kaggle notebook 其实并不适合拿来当评测题，能产出确定性可验证答案的是少数。

任务长什么样？还有个"地狱难度"子集

每个任务被形式化成一个三元组 $\mathcal{T} = (q, \mathcal{F}, a^*)$：q 是自然语言指令，$\mathcal{F}$ 是包含目标文件和干扰文件的整个文件系统，$a^*$ 是真值答案。Agent 在隔离的 Linux sandbox 里从根目录起步，只拿到一句话，没有任何文件位置、文件名、数据结构的提示，全靠自己探。

作者还从里头挑了 119 个任务组成 CoDA-Hard，入选标准两条都得满足：

数据复杂度：得从大集合里发现至少两个目标文件；
代码复杂度：参考解法超过 30 行有效代码。

两个 benchmark 的统计对比：

统计项	CoDA-Bench	CoDA-Hard
总任务数	1,009	119
数据社区数	31	15
每环境文件数	980.8	1421.7
每任务关键文件数	1.3	2.4
信噪比 SNR	0.0105	0.0142

注意这个 SNR（信噪比）——关键文件占总文件数的比例，CoDA-Bench 平均才 0.0105。换句话说，环境里大约每 100 个文件，只有 1 个是你真正要用的。环境文件数从 10 到 8,158 个不等，数据总量从 20.3 MB 一直到 45.4 GB。这个规模，已经很接近真实生产环境了。

评了哪些 Agent？结果如何？

作者评了两大类系统：

原生 CLI 工具：Codex CLI（配 GPT-5.5）、Claude Code（配 Opus-4.7 / Sonnet-4.6 / Opus-4.6）；
框架型 Agent：OpenHands（骨干换成 GPT-5.5 / Opus-4.7 / Kimi-K2.6 / DeepSeek-V4-Pro）、Mini-SWE-Agent（配 GPT-5.5）。

评测沿两个维度。Discovery Accuracy 也就是 DA，衡量数据智能——能不能在复杂文件系统里把所有该用的数据都找全：

\[DA = \frac{1}{|\mathcal{T}|} \sum_{t \in \mathcal{T}} \mathbb{1}[\mathcal{F}_{used}^{(t)} = \mathcal{F}_{target}^{(t)}]\]

Execution Accuracy 即 EA，衡量代码智能——端到端答对（数据找对 + 代码写对都得满足）：

\[EA = \frac{1}{|\mathcal{T}|} \sum_{t \in \mathcal{T}} \mathbb{1}[\text{normalize}(a_t) = \text{normalize}(a_t^*)]\]

主结果（Table 4）：

System	Model	Bench DA%	Bench EA%	Hard DA%	Hard EA%	Avg.Turns	$/Task
Codex CLI	GPT-5.5 (xhigh)	75.0	60.5	57.0	42.9	6.8	∼1.42
Codex CLI	GPT-5.5	74.9	60.3	61.4	47.9	6.8	∼1.39
Claude Code	Opus-4.7	77.3	51.9	61.4	45.4	16.1	0.22
Claude Code	Opus-4.6	71.3	47.8	68.4	45.4	17.2	0.20
Claude Code	Sonnet-4.6	77.9	53.8	61.4	42.9	14.7	0.11
Mini-SWE-agent	GPT-5.5	83.0	61.1	67.5	49.6	32.5	∼0.39
OpenHands	GPT-5.5	82.1	59.7	63.2	44.5	18.1	∼0.65
OpenHands	Opus-4.7	72.0	49.3	59.6	38.7	24.4	∼1.17
OpenHands	Kimi-K2.6	71.5	43.8	59.6	37.0	39.4	∼0.41
OpenHands	DeepSeek-V4-Pro	75.9	49.0	58.8	36.1	35.8	∼0.15

几个值得拎出来说的点：

最高 EA 只有 61.1%，由 Mini-SWE-Agent + GPT-5.5 拿下，OpenHands + GPT-5.5 紧随其后（59.7%）。到了 CoDA-Hard，最高也就 49.6%——这意味着一半的难任务都做不对。

DA 看着不低，但别被骗了。 最高 DA 是 83.0%，听起来还行？可换个角度——即便最强的 Agent，也有近 20% 的任务连对的数据都找不全。而 DA 是 EA 的前提，数据都没找对，代码写得再漂亮也是白搭。

模型和框架的"对齐"很有意思。 GPT 系列配 Mini-SWE-agent 更香（EA 比原生 CLI 高 0.8 个点），而 Claude 系列反而在自家原生环境里更强（51.9% vs OpenHands 里的 49.3%）。这说明 Agent 框架和骨干模型之间存在某种"适配性"，不是随便拼就能拼出最优。

性价比这块，Sonnet-4.6 是隐藏赢家。 每任务 $0.11 拿下 53.8% EA，而 Codex CLI + GPT-5.5 虽然 EA 更高（60.3%），但每任务要 $1.39——贵了十几倍。token 消耗上 Sonnet-4.6 平均 81,714，Codex CLI 是 380,558，差了快 5 倍。如果你是要大规模跑数据分析任务，这个账得算清楚。

最值钱的发现：卡住 Agent 的是"找数据"，不是"写代码"

这才是这篇论文真正的洞察所在。作者做了个很关键的消融实验（在 CoDA-Hard 上）：

Community 设置：Agent 得自己从完整环境里发现相关文件（默认设置）；
Oracle 设置：直接在提示里把所需文件的精确路径告诉它。

结果：

Claude Code (Sonnet-4.6)：从 45.4% 飙到 73.1%，涨了 27.7 个点；
OpenHands (GPT-5.5)：从 44.5% 涨到 68.9%，涨了 24.4 个点。

只是把"找文件"这一步省掉，准确率就能涨 24 到 28 个点。 这个数字非常说明问题——数据发现，才是当前 Agent 在数据密集环境下的头号瓶颈。

但话也别说满。即便给了 oracle 上下文，Agent 平均也就 71.0%，还剩 29% 做不对。说明 CoDA-Hard 在代码生成层面也是真有难度——多源整合、需要领域知识才能消解的语义模糊、复杂的多步推理，这些坎光给路径是过不去的。

数据规模一大，性能直接崩

作者还分析了环境特征对 GPT-5.5 性能的影响（图 4 那组散点图，Top 30 社区）：

文件数量：Spearman ρ=−0.271，p=0.148——负相关但不显著，社区间方差大；
信噪比 SNR：ρ=0.466，p<0.01——强难度预测因子；
数据量：ρ=−0.461，p<0.01——规模化的 I/O 瓶颈。

这里有个反直觉的点：真正让 Agent 头疼的不是文件多，而是 SNR 低——也就是相关数据和语义相似的干扰项混在一起、难以区分。导航大量文件这件事 Agent 其实还行，但"在一堆长得很像的东西里挑出对的那个"才是要命的。这恰好印证了用共现图造噪声的设计是有效的——它造出来的干扰项确实够"迷惑"。

数据量上更夸张：3GB 以下的社区准确率还算稳，一过 3GB 就持续掉，到了 8GB 以上的好几个社区直接掉到接近零。当前 Agent 处理 10GB 级生产数据集的能力，基本可以说是不及格。

错误会"不可逆传播"——这点我印象很深

交互行为分析里有个洞察我特别认同：一旦 Agent 在探索阶段选错了数据文件，后面再怎么改代码都救不回来——数据发现的错误会在整条分析管线里不可逆地传播下去。

这跟我自己的经验完全对得上。Agent 不像人，人发现结果不对劲会回头怀疑"是不是一开始数据就拿错了"，但 Agent 往往会在错误的数据上反复优化代码，越陷越深。Kimi-K2.6 就是个例子：它用了更多轮数（39.4 轮）反而准确率更低（43.8%）——增加交互次数压根没法弥补模型根本能力的不足。

强模型和弱模型，错得不一样

最后是错误归因（手动分析 200 个失败案例，分四类：数据发现错误、任务理解错误、代码生成错误、执行错误）。对比两个模型：

错误类型	GPT-5.5（强）	Kimi-K2.6（中）
代码生成	44.0%（最大来源）	34.7%
数据发现	33.0%	40.7%（主导）
执行错误	6.5%	12.6%

看出门道了吗？弱模型更多栽在"找不对数据"上，强模型的错误则更多转移到了"分析推理和代码构造"上。 这种能力依赖的错误转移，恰恰证明了 CoDA-Bench 把数据发现和代码推理放一起评的价值——单独评任何一个维度，都看不出这种结构性差异。

我的判断

先说优点。这篇论文我认为是一篇质量很高的 benchmark 工作，它的价值不在于"又造了个更难的榜"，而在于指出了一个被长期忽视、却真实存在的能力鸿沟——数据发现。整个构建方法（共现图建模 + Leiden 社区划分 + 解决方案反向构建 + 对抗演化）逻辑自洽、可扩展，借用真实数据生态来造语义噪声这一招尤其漂亮。DA/EA 的双维度拆解也很到位，让"找数据"和"写代码"的贡献能分开看。

再说几个我会打问号的地方。

一是答案的"确定性"可能限制了任务的丰富度。整套构建依赖"解决方案锚点"——必须是能精确复现、数值容差内可验证的输出。这意味着 benchmark 天然偏向那些有唯一确定数值答案的任务，而真实数据分析里大量是开放式的、需要判断的（比如"这个趋势说明了什么"）。这类任务它没法覆盖，多少限制了对"数据智能"的完整刻画。

二是对抗演化引入的"难度"是否会偏向特定模型的弱点？判别器用的是当下的 SOTA LLM 集成，那么被磨出来的"难任务"，本质上是这些模型当前不擅长的任务。随着模型迭代，这套难度标定可能会失效——不过作者用了模型集成来缓解，算是有所考虑。

三是 61.1% 这个数字的"绝对值"意义有限。它高度依赖所选的 31 个社区和数据规模分布。换一批社区、换一批 Kaggle 数据，这个数能差不少。所以更该关注的是它揭示的相对结论——数据发现是瓶颈、错误不可逆传播、能力依赖的错误转移，这些才是真正经得起时间考验的洞察。

落到工程上，如果你正在做数据分析类的 Agent，这篇论文至少给了两条很实在的提醒：第一，别只盯着代码能力，数据发现这一环可能才是你产品掉链子的地方，值得专门做检索/定位的增强；第二，要给 Agent 加"回溯怀疑"的机制——让它在结果异常时能回头质疑最初选的数据对不对，而不是一条道走到黑地改代码。

数据密集环境下的 Agent 评测，我觉得会越来越重要。毕竟真实世界里没有谁会把干净的 oracle 文件摆在你面前。CoDA-Bench 至少把这个问题摆上了台面。

项目地址：coda-bench.github.io，代码在 github.com/ruc-datalab/CoDA-Bench，数据在 HuggingFace 的 RUC-DataLab/CoDA-Bench。论文编号 arXiv:2606.15300，感兴趣的可以去翻原文，附录里那 11 张图和社区可视化挺值得一看。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我