研究提案

Sandbox 作为数据合成核心资产：从执行副产品到训练主力军

一个被忽视的视角：不同 Sandbox 配置下同一实验的差异化结果，天然构成高质量的错误诊断训练数据

2026年3月30日 Sandbox 数据合成错误诊断科研AI matrix testing 论文复现

核心洞察

当前 AI 科研 agent 的训练数据有一个共同的弱点：错误轨迹要么是合成的（不够真实），要么是随机注入的（没有科研针对性）。

本提案提出一个几乎未被论文触及的视角：

同一个实验，在不同 Sandbox 配置下跑出不同结果，这个差异本身就是最真实的「错误诊断」训练数据。

这不是 bug，这是数据金矿。

科研实验的「可复现性危机」在学术界已讨论多年——同样的代码、在不同环境、不同时间、不同硬件上跑出不同结果，几乎是常态。过去这被当作一个需要解决的问题。但换一个角度：如果我们主动、系统地制造这种差异，每一对「成功配置 vs 失败配置」就是一条带有完整上下文的诊断轨迹。

这个视角的新颖性在于：它把 Sandbox 从「运行环境」重新定义为「数据生产机器」。

什么样的 Sandbox 变体会产生有价值的错误

并非所有差异都值得收集。有价值的错误需要满足两个条件：可诊断（有明确的根因）和有科研意义（根因指向真实的科研执行挑战）。

以下五类变体是高价值来源：

1. 依赖版本差异

变体示例：PyTorch 1.12 vs 2.0，CUDA 11.3 vs 11.7，transformers 4.28 vs 4.38
典型错误模式：API 变更导致的 AttributeError，精度差异导致的结果偏移，显存分配策略变化导致的 OOM
诊断价值：版本兼容性是论文复现最高频的失败原因，占比超过 40%

2. 硬件差异

变体示例：单 GPU vs 多 GPU，A100 vs V100，不同显存上限
典型错误模式：多卡通信错误，batch size 无法适配，混合精度在不同架构上的行为差异
诊断价值：硬件相关错误往往需要对底层计算有深刻理解，是高难度诊断能力的训练来源

3. 随机种子

变体示例：固定种子 vs 不固定，不同种子值（42, 0, 12345, …）
典型错误模式：结果方差过大（论文声称±0.1%，实际跑出±3%），某些种子触发数值不稳定
诊断价值：帮助模型学习区分「复现失败」和「统计正常波动」，这是科研诊断中极其微妙的判断

4. 数据集版本差异

变体示例：ImageNet 的不同预处理脚本，GLUE benchmark 的不同下载源，自建数据集的不同 split 方式
典型错误模式：指标系统性偏低，训练集泄漏，评估集构成不一致
诊断价值：数据问题是最难发现的错误类型，因为代码运行正常但结果不对，需要更深层的溯源能力

5. 超参数微变

变体示例：学习率 1e-4 vs 1e-3，warmup steps 100 vs 500，dropout 0.1 vs 0.2
典型错误模式：训练不收敛，loss 震荡，过拟合提前出现
诊断价值：超参数敏感性分析是科研实践的核心技能，微小变化导致大幅性能差异的场景是高质量训练数据

数据生产方式：Matrix Testing 系统化流程

核心方法是笛卡尔积配置矩阵（Matrix Testing）——对每篇论文代码，系统地枚举关键维度的取值组合，批量生产配置对。

流程设计

输入：一篇开源论文代码仓库
         ↓
Step 1: 配置维度提取
  - 自动解析 requirements.txt / environment.yml / Dockerfile
  - 识别关键超参数（argparse / config file）
  - 标注硬件依赖项
         ↓
Step 2: 矩阵生成
  - 定义「锚点配置」：能成功复现论文结果的配置（经人工验证或自动验证）
  - 对每个维度生成 N 个变体值
  - 笛卡尔积展开（可设优先级过滤，避免组合爆炸）
         ↓
Step 3: 批量执行
  - 在 Sandbox 集群中并行运行所有配置
  - 完整记录：环境信息 / stdout+stderr / 中间 checkpoint / 最终指标
         ↓
Step 4: 结果分类
  - 成功：指标落在论文声称范围内（±容差）
  - 部分成功：代码运行完成但指标偏差超阈值
  - 失败：运行报错终止
         ↓
Step 5: 诊断轨迹构建
  - 以「锚点配置」为正例
  - 以每个失败/偏差配置为负例
  - 生成「正例 + 负例 + 根因标注」三元组

一条诊断轨迹的数据结构

{
  "paper_id": "arxiv:2301.xxxxx",
  "anchor_config": {
    "pytorch": "1.12.1",
    "cuda": "11.3",
    "seed": 42,
    "lr": 1e-4,
    "result": {"accuracy": 0.847}
  },
  "variant_config": {
    "pytorch": "2.0.1",
    "cuda": "11.7",
    "seed": 42,
    "lr": 1e-4,
    "result": {"error": "AttributeError: 'Tensor' object has no attribute 'data_ptr'"}
  },
  "delta_dimensions": ["pytorch_version", "cuda_version"],
  "diagnosis": {
    "root_cause": "PyTorch 2.0 移除了 .data_ptr() 的隐式转换，需显式调用 .contiguous().data_ptr()",
    "fix_patch": "...",
    "difficulty": "medium",
    "category": "api_deprecation"
  },
  "trajectory": [
    {"step": 1, "action": "run training", "output": "..."},
    {"step": 2, "action": "observe error at epoch 0", "output": "AttributeError..."},
    {"step": 3, "action": "search error message", "output": "..."},
    {"step": 4, "action": "apply fix", "output": "..."},
    {"step": 5, "action": "verify fix", "output": "accuracy: 0.845"}
  ]
}

与现有方案的关系：把副产品变成主产品

这个提案处于两条现有路线的交叉点：

Agent Sandbox（基础设施层） 提供了可控、可重现的实验执行环境。但 Sandbox 当前的角色是「工具」——用来跑实验。本提案把它升级为「数据工厂」。

论文代码复现（数据来源层） 已经在系统性地收集复现轨迹。但当前的数据收集是线性的：一次复现 = 一条轨迹。本提案引入矩阵化维度，让一次复现工作扩增为 N×M 条训练数据。

这个交叉点的价值在于：

边际成本极低：一旦锚点配置建立，矩阵测试可以大规模并行，边际数据成本接近于零
质量护城河：这类数据只能通过「真实运行」产生，无法通过 LLM 合成高质量替代品
领域特异性：错误轨迹来自真实科研代码，而非随机软件工程场景，训练出的诊断能力有科研领域针对性

潜在规模与质量分析

规模估算

以 Papers With Code 上约 10,000 个可运行的开源仓库为基础：

平均每个仓库可提取 5 个关键配置维度
每个维度平均 3 个变体值
笛卡尔积取子集（取 20 个代表性组合）
预计成功率：约 30% 配置成功运行

10,000 仓库 × 20 配置 × 70% 失败率 = 约 140,000 条失败轨迹
× 平均诊断步骤 8 步 = 约 1,120,000 个带标注的诊断动作

质量对比

数据来源	真实性	科研针对性	可规模化	成本
完全合成（LLM 生成）	低	中	高	低
随机 bug 注入	中	低	高	中
Sandbox 矩阵测试（本方案）	高	高	高	中
人工标注复现轨迹	高	高	低	极高

本方案在真实性和科研针对性上接近人工标注，但可以规模化——这是当前其他方案无法同时做到的组合。

开放挑战与风险

计算资源：矩阵测试需要大量 GPU 时间。缓解方案：优先运行低成本实验（NLP 小模型 > 大规模视觉模型），建立运行时长预算上限。

根因标注质量：自动标注根因是难点，LLM 辅助标注 + 人工抽查是初期方案，后续可以用标注好的数据训练专门的根因分类器形成飞轮。

仓库质量参差不齐：Papers With Code 中相当一部分仓库连锚点配置都难以建立。需要设计仓库质量过滤流程，优先处理有 Dockerfile 或详细 README 的仓库。

建议的推进路径

Phase 1（1-2 个月）：选取 50 个高质量论文仓库，手工建立锚点配置，开发矩阵测试 pipeline，验证数据质量。

Phase 2（3-4 个月）：扩展到 500 个仓库，引入 LLM 辅助根因标注，建立质量评估 benchmark。

Phase 3（6 个月+）：全规模运行，数据与模型训练形成飞轮——用训练好的诊断模型辅助标注新数据，降低人工成本。

总结

Sandbox 不只是运行实验的工具，它是一台数据生产机器。

把「可复现性危机」从问题翻转为资产——这是本提案的核心立场。科研 AI 最稀缺的能力之一是错误诊断：当实验结果不对时，能快速定位是环境问题、数据问题还是超参数问题。这种能力需要大量真实的错误-诊断轨迹来训练，而 Sandbox 矩阵测试是目前最具性价比的生产方式。

这个方向目前在论文里几乎是空白，是值得抢占的数据基础设施先机。