DSAgentBench：真实环境测试275个数据科学任务，最强Agent仅56.7%成功率
DSAgentBench: Can Agents Automate End-to-End Data-Science Workflows in Real Computer Environments?
真实世界的数据科学远不止是在隔离的沙盒中编写几行 Python 代码并顺利通过单元测试。对于一线的分析师和算法工程师而言，日常工作是一个长周期、跨工具的复杂链路：从异构数据源的获取与清洗，到终端环境的依赖管理，再到 Jupyter Notebook 的探索性分析、IDE 中的模型训练以及最终的可视化呈现。这就要求操作者必须在真实的操作系统环境内，协调使用浏览器、数据库、终端和代码编辑器。然而，当前绝大多数用于评估大型语言模型（LLM）或 AI Agent 数据科学能力的基准测试，往往剥离了这些环境交互，仅仅关注静态的代码生成和语法正确性，未能真正捕捉到数据科学实践中多阶段、多工具协作的本质。
ArXiv URL：https://arxiv.org/abs/2608.10366v1
为了填补这一关键空白，来自南洋理工大学、Salesforce 和约克大学的研究团队提出了 DSAgentBench。这是首个旨在评估 AI Agent 能否在真实计算机操作系统内部，端到端地自动化执行完整数据科学工作流的基准测试。该基准提供了一个全功能的环境，强迫模型像人类一样观察屏幕、点击界面、调用外部 API 并编写执行代码。
更为严苛的是，DSAgentBench 摒弃了仅看代码表面的验证方式，转而采用确定性的执行结果评估机制——直接检验 Agent 产生的数据分析结果、可视化图表和最终训练的模型性能。对 15 种主流闭源和开源模型的大规模评测结果揭示了一个冷酷的现实：即使是目前表现最强的 Claude-4.6-Sonnet，其任务成功率也仅为 56.70%（人类基准为 85.09%），而所有参与测试的开源模型成功率更是惨不忍睹地低于 1%。这一数据清楚地表明，当前被寄予厚望的智能体系统在工具编排、系统级视觉定位以及长视距推理方面，距离接管真实数据科学工作流仍有极大的鸿沟。
现有基准的盲区：为何静态代码测试不够？
在深入探讨 DSAgentBench 的创新之前，有必要审视现有基准的局限性。早期的代码生成评准（如 HumanEval）主要依靠孤立的单元测试来验证函数的逻辑正确性，完全不涉及数据分析场景。随后出现的 DS-1000、MLAgentBench、DSBench 和 DSEval 等测试集，虽然将重心转移到了数据操作或机器学习上，但它们依然只是在截取工作流的某一个切片进行考核。
即使是目前最接近真实场景的 DA-CODE 框架，也仅仅将 Agent 限制在一个受控的 Notebook 沙盒环境中运行。在这种设定下，Agent 不需要面对操作系统级别的复杂性：它们无需打开浏览器去检索缺失的文档，无需在终端中处理那些令人抓狂的包依赖冲突，也无需在文件系统中穿梭以加载分散在不同目录下的数据集。
另一方面，像 OSWorld 或 VisualWebArena 这样的多模态计算机控制基准，虽然实现了针对真实操作系统或网页环境的点击与输入测试，但其任务主要集中在日常办公、应用导航和通用网页浏览上，缺乏对深度分析推理和数学计算的考察。换句话说，它们测试的是 Agent “会不会用电脑”，而不是“能不能做数据科学”。
DSAgentBench 正是站在了这两个研究方向的交叉点上。它要求 Agent 必须同时具备强大的系统级交互能力和深厚的数据分析推理能力，在真实的操作系统中跑通端到端的链路。
DSAgentBench 的核心架构与评测机制
为了打造一个无限逼近真实场景的测试床，研究团队以 OSWorld 框架为基础进行了深度扩展。DSAgentBench 运行在一个配置了 Python 及各类主流数据科学库的 Ubuntu 虚拟机环境中。该环境默认捕捉 1920$\times$1080 分辨率的高清屏幕截图，以提供清晰的视觉上下文。
环境中预装了 Visual Studio Code 和 Jupyter Notebook 用于脚本开发与交互式分析，同时内置了 Chrome 浏览器以便 Agent 查阅文档或获取外部数据。此外，为了模拟真实的异构数据获取过程，环境还支持通过 Kaggle API、OpenML 甚至直连 SQLite 数据库来调取数据。Agent 不能调用任何作弊性质的底层 API，必须通过标准的图形用户界面（GUI）动作空间（如鼠标点击、拖拽、键盘输入）来控制这些应用，这完全复刻了人类分析师的工作方式。
极具挑战的 275 个真实任务
基准测试包含 275 个长周期任务。这些任务并非通过大模型随机批量生成，而是经历了一个严密的“人工-LLM协作”与“双盲验证”流程。数据源广泛抓取自 Kaggle 高分竞赛数据集、OpenML、GitHub 仓库（如 Plotly 官方数据）以及需要多表联查的生产级关系型数据库。
专家标注团队耗费约 400 小时，根据真实的 Kaggle 高分 Notebook 提炼出典型的数据流模式。每一个任务都包含一条自然语言指令、一个独立的环境初始化配置以及一个负责验证结果的 Python 评估器。更关键的是，为了保证基准的无懈可击，每一个任务都经过了严格的双人验证：一位标注者负责创建规范和评估逻辑，另一位标注者则必须在基准模型上独立运行该任务，并确认指令的清晰度和评估的绝对正确。只有当双方完全达成一致时（初次一致率达 86%，剩余经过反复修正），该任务才会被纳入最终集合。
从任务的生命周期分布来看，DSAgentBench 极其贴近工业界的真实时间分配：探索性数据分析（EDA）占据了最大的比重（43.3%），其余分布在数据获取、特征工程、模型建立、可视化展示以及模型评估等环节。
确定性执行验证：拒绝“表面文章”
以往的很多测试只要模型输出了正确的代码片段就算成功，但在 DSAgentBench 中，代码写得再好，如果无法在系统中跑通并生成预期产物，依然会被判定为失败。
当 Agent 在规定步数（默认最高 15 步交互）内主动发出 DONE 信号后，隐藏在后台的确定性评估器就会被唤醒。它会潜入虚拟机，提取 Agent 遗留的脚本、生成的数据文件、图表或序列化模型进行深度校验。例如，在计算皮尔逊相关系数的任务中，评估器不仅会检查输出文件是否存在，还会读取计算结果，并判断其是否落在容差范围 $\epsilon=0.01$ 之内。对于分类模型训练任务，评估器会严格验证保存的模型是否达到了预设的性能阈值（如 $F1 \geq 0.7$）。
针对最难量化评估的可视化任务，评估器首先会通过代码层面的元数据检查来确认坐标轴标签、图例、标题是否完备。在此基础上，大约有 10% 的任务会在通过了确定性验证后，引入高等级的视觉大模型作为裁判（为避免“自说自话”，GPT-4o 生成的图表由 Gemini-2.5-Pro 裁判，其他模型则由 GPT-4o 裁判），以评估图表与原始指令在语义上的一致性。最终，只有当该任务的综合得分大于等于 0.95 时，才会被记为一次成功。这种设定允许了极小范围的数值精度误差，但对核心语义和执行结果的要求极其苛刻。
实验结果：开源模型的全线溃败与闭源模型的艰难挣扎
研究团队挑选了 15 个当前最受瞩目的视觉-语言模型进行测试。阵营涵盖了统一架构的闭源巨头（如 GPT-4o、GPT-5、Claude Sonnet 全系、Gemini 2.5 Pro），结合专有规划模型与开源定位模型的混合架构（如 Jedi 配合 GPT-4o），以及专门针对 GUI 交互训练的纯开源模型（如 UI-TARS 2B/7B、GUI-OWL-7B、OpenCUA-72B）。
为了探究系统元数据的辅助价值，评测分为两种观察设定：一是仅依靠纯屏幕截图（Screenshot），二是屏幕截图叠加可访问性树数据（Screenshot + A11y Tree，即当前界面的底层 UI 结构信息）。
测试结果呈现出断层式的差距。在人类能够轻松取得 85.09% 成功率的任务中，Claude-4.6-Sonnet 凭借混合观察设定拿下了 56.70% 的最高分，显著拉开了与其他模型的距离。备受期待的 GPT-5 仅获得了 29.81% 的成功率，而 GPT-4o、Gemini 2.5 Pro 等明星模型的成绩则始终徘徊在 20% 上下。这意味着，一旦把这些顶尖模型放入需要跨应用协调和连续试错的真实 OS 中，它们引以为傲的代码生成能力就会大打折扣。
比闭源模型表现不佳更令人警醒的，是开源模型在这一复杂场景下的集体罢工。所有参测的开源 Agent 在纯截图模式下成功率无一突破 1%（且它们多数在架构上不支持输入 A11y 树）。尽管它们在单步的点击预测或简单的指令跟随测试中可能表现不俗，但面对数据科学任务时，它们暴露出致命缺陷：无法将抽象的分析指令准确映射（Grounding）到当前复杂的 IDE 或终端界面上，频繁陷入盲目点击、死循环或是无法从代码报错中恢复状态的窘境。
关键瓶颈分析：长视距规划与工具链脆弱性
通过对模型执行轨迹和消融实验的深入分析，研究团队精确定位了导致当前 Agent 表现低迷的核心痛点：
第一，随着工作流阶段的拉长，Agent 的成功率呈现断崖式下跌。在执行单阶段任务时，部分模型的成功率还能保持在合理区间；但面对需要多阶段操作（例如先清洗数据，再做特征工程，最后训练模型）的复杂工作流时，几乎所有模型都会在长周期的状态维持中崩溃。它们很容易忘记几步之前的中间结果，或者在遭遇代码报错时，无法像人类一样通过查阅终端日志来定位并修改代码，而是倾向于不断重复错误的操作，直至耗尽步数预算。
第二，工具环境的复杂度对成功率有决定性影响。数据表明，在 Jupyter Notebook 中执行的任务成功率要明显高于在 VS Code 中执行的任务。这主要因为 Jupyter 的单元格交互模式容错率更高，状态可视化更直接；而 VS Code 往往伴随着更复杂的终端环境配置和包依赖管理，Agent 在应对复杂的终端报错和目录切换时极易迷失方向。
第三，底层 UI 树结构（A11y Tree）仍然是目前多模态模型不可或缺的“拐杖”。在剥离了底层文本结构，仅仅依赖纯视觉截图进行定位时，大多数模型的性能都会出现大幅滑坡。即使是目前视觉定位能力最强的闭源模型，在完全没有结构化数据辅助的纯像素级交互中，也很难在密集的 IDE 代码区和复杂的系统菜单中做到精准点击和文字提取。
结论与启示
DSAgentBench 的提出不仅为大模型评测领域引入了一个极具挑战性的高优基准，更重要的是，它戳破了当前关于 AI 即将完全替代初级数据分析师的虚假繁荣。当把代码能力还原到真实的操作系统环境与多工具协调的约束下时，现有模型的脆弱性暴露无遗。
这篇工作为未来的 Agent 研发指明了明确的演进路线。仅仅扩增模型在沙盒中输出 Python 代码的准确度已经遭遇边际收益递减。下一代智能体系统要想真正在实际业务中落地，必须攻克系统级多模态感知（无需依赖 A11y 树的纯视觉精准定位）、长周期跨应用的状态记忆追踪，以及基于中间执行反馈的自适应纠错能力。只有当 Agent 能够像人类一样，在终端里排查报错、在浏览器里查阅 API，并在 IDE 里从容调试时，我们才算真正迎来了自主化的数据科学时代。DSAgentBench 将作为这一进阶之路上的关键度量衡，持续检验行业的技术成色。