ScienceIDE：把科学代码变成智能体训练场，奖励函数看物理偏差

2026 年 9 月公开的 ScienceIDE 论文想解决一个听着简单、其实一直没解决的工程难题——为什么 GitHub 上跑得通的科学代码，几乎不能直接用来训练智能体？让一个代码仓库"能跑"是一回事，让它"能教"是另一回事。这篇论文整篇都在讲这中间那道鸿沟怎么被填上，核心抓手是把"物理偏差"而不是"测试通过"写进奖励信号。 ScienceIDE

一、能跑的科学代码，为什么天然不是智能体能学的训练场？

想象一下：你是一个写数值模拟代码的团队，仓库里是 PLUTO（等离子体流体动力学）、MITgcm（海洋大气环流）、Athena++（天体物理磁流体）这样跑了几十年的科学代码。它们在 GitHub 上星标一堆，每个都有官方测试用例。你把其中一个仓库直接接给一个 coding 智能体，让它去修 bug、改模块、加新功能——直觉上，这不就是最丰富的智能体训练素材吗？ MITgcm

直觉是错的。ScienceIDE 论文把这件事叫作 scientific experience bottleneck（科学体验瓶颈），三层原因并列：

第一层，工具链碎片化。这些仓库是几十个团队、跨几十年写的 Fortran/C/C++，依赖、双精度假设、构建系统、MPI 并行模式全都不一样。智能体能跑通 install 都未必能跑通 build，更别说 reproducible 地把代码改对了。

第二层，正确性标准不一样。普通软件工程的"测试通过"是离散判断——这个 case pass、那个 case fail，输赢明确。科学代码的"通过"是物理观测值的容差比较：某个密度场在某个坐标系下的积分跟参考解差 0.5% 以内就算通过；某个能量守恒律在某段演化后偏离参考值不超过某个科学预设的 ρ 也是通过。这种"通过"是连续的，不能光看 yes/no。

第三层，任务需要可验证的物理合约。"能跑的代码"必须先被切成一个个带初始工作区、带可执行产物、带私有验证器的任务单元，且每个任务的验证逻辑必须对"未修前的 baseline"留出上升空间——否则"反射式对答案"就成了智能体唯一学到的本事。

论文给出过一个外部参照系：SWE-bench Science 在 119 个真实科学软件任务、98 个仓库、20 个领域里评测了 8 个主流 model–harness 组合，最强的 Claude-Opus-5 + Claude Code 也只拿到 47.90% Pass@1。SWE-bench Science 团队还在论文里列了四类失败机制：科学知识抽象不足、表层修复没追到根因、多模块集成没顾全、修复在已见样本上对但泛化失败。这些失败有一个共性——它们都在"公开测试通过"和"科学合约仍然成立"之间的夹缝里掉队。 SWE

图注：ScienceIDE 论文 Figure 1。左侧 (a) 把科学代码改造成可复用训练基座；中间 (b)(c) 两个闭环立起全文张力——"科学经验让智能体更强"和"智能体反哺科学工作"；右上 (d) 的环形图把覆盖的领域与 Acceleration / Repair / Discovery / Reproduction / Integration / Calibration / Implementation 七类任务形式摊开；右下 (e) 是 ScienceIDE-Hard 的排行预览，具体数字留给后文。来源：arXiv:2609.19134。

这张图把整篇论文的"是哪一边"讲清楚了：ScienceIDE 走的是 Science4AI 方向——把科学经验（已有的科学代码 + 它内嵌的物理合约）反向训练出更强的智能体；而不是 AI4Science 方向——让智能体去产生新的科学发现。前者有可验证的证据，后者本文不去主张。

二、从仓库到可学习环境：四级抽象怎么把代码变成训练基座

鸿沟既然看见了，怎么填？ScienceIDE 给出了一套四级抽象：module → environment → factory → episode。这四级不是用来挂在 prompt 里的措辞，是把仓库真正重新封装一遍的工程规范。

最底层 module 是一个科学仓库里的"模块"——不是按文件分组的代码块，而是承担一块连贯物理责任的代码单元，外加它已经能跑通的测试覆盖。仓库本身被钉在一个特定 commit（论文示例 mitgcm-atmos 任务锁的是 MITgcm checkpoint69q 这个 release），用这个 commit 不是为了"版本控制洁癖"，而是保证未来任何一次评分都跟当前 ground truth 在同一个源码状态下对齐。

往上一层 environment 把这个钉好的 module 跟它的 runtime（容器、依赖、构建脚本）以及 scientific checks——一组"输入-输出对照表+pass policy"——一起封进一个可执行单元。scientific checks 才是这里真正的创新点。每一项检查都是一个固定的输入配一对有容差的物理输出，外加一句白话写的 warrant（"它检验的是什么物理量、为什么合法实现能满足它"）。检查套件在任务生成之前就定下来——后续所有任务都共用这套验收合约，不会因为任务改写而漂移。

再往上一层 factory 是任务生成器。它是一些"可复用的改写程序"+"该环境下的科学上下文"组合——比如把某段代码精确切掉（excise）、在某处注入一个语义缺陷（inject defect）、或者为某个昂贵的运行路径设计探针。这些程序产生的候选任务要交给下一层去验证。

最后是 episode，一次智能体与任务的完整交互：拿到一个可编辑工作区，看代码、看输入、跑实验、产出提交物，被一个独立的 verifier 评分。每一次 episode 都被同一个结构记录下来：动作、回报、check 状态、执行状态、资源消耗。同一个 episode 接口同时支撑 evaluation、SFT 和 RL——这是 ScienceIDE 整套架构的关键设计，三种用途的任务分布因此天然对齐。

图注：ScienceIDE 论文 Figure 2。左侧是版本化的科学仓库被 runtime + scientific checks 封装成 environment；中间是 environment-specific factory 不断产生候选任务；右侧是 validation 环节筛出 episode，让它同时承担评测、SFT、RL 三种用途。来源：arXiv:2609.19134。

论文里反复强调一句容易被忽略的话：factories 的作用是 "amortize rather than eliminate"——它节省专家审核的工作量，但不能完全取代。ScienceIDE 的工程 pipeline 里有一个专门的 Graveyard 来节点处理被拒任务，把"这个任务为什么被拒"和"它教了 pipeline 什么教训"一起留档（这一点直接复刻自仓库 ScienceIDE 仓库 docs/assets/pipeline.svg）。

把抽象落到现实，论文配套的 GitHub 仓库已经发布 15 个 environment，覆盖 Athena++ ×4（astrophysical MHD，BSD-3-Clause）、MITgcm ×6（海洋大气海冰生物地球化学，MIT）、Gkeyll（等离子体动理学）、DScribe（材料描述符）、NEST（贵元素微物理）、Stim（量子稳定子电路）等真实代码；剩余 49 个 environment 锁在仓库外作为 held-out test set。每个 task 目录里都包含 task.toml / instruction.md / defect.json / fix.json 这四件套——defect.json 是精确注入的修改，fix.json 是精确反演，分数就是从这个 baseline 出发算 partial credit。仓库 README 明示整个体系在 ScienceIDE 仓库只是 preview，完整的 64 个 environment 在 Gen-Verse/ScienceInfra 仓库里继续维护。

图注：仓库 docs/assets/pipeline.svg 截图。蓝色五步流程是任务从真实代码到发布的完整路径，每步都带验收门槛：第三步要求 reference fix 必须让 oracle 拿满分、unfixed baseline 必须留出上升空间、整套流程在 grading container 里跑；第四步 Deterministic gates 防止答案泄露、检查 schema 与重复；第五步 Release 把 difficulty 写成 measured facts（measured_pass_rates、unfixed score、edit sites、verification cost 等结构化字段），不靠手工标签。橙色 Graveyard 接收被拒任务，把"拒因 + 教训"留档。来源：aitofound/ScienceIDE 仓库。

图注：15 个 environment 名称、对应 upstream code 与 license 的对应表。Athena++ ×4（BSD-3-Clause）、MITgcm ×6（MIT）、Gkeyll（MIT）、DScribe（Apache-2.0）、NEST（Apache-2.0）、EDKit（MIT）、Stim（Apache-2.0）。这张表是论文抽象落到现实的最小证据集：四级抽象不是空话，每个 environment 都是真实科学代码的封装。来源：ScienceIDE 仓库 environments/README.md。

读者到这里应该带走一件事：科学代码要被智能体学习，必须先被重新封装成"同一接口下能跑出可验证结果的 episode"——这不是写一个 prompt，而是把合约前置到 module 这一层。

三、把物理正确性写进 reward：pointwise 校验、invariants 校验与归一化

接第二章，环境封好了，任务也提出来了——接下来最关键的问题是：一次修复算不算合格？通用 SWE 评测给的是二元 pass@1（测试过不过），ScienceIDE 给的是 partial credit。这个设计值得单独讲一章，因为它直接决定了 SFT 数据的标签和 RL 的 reward 信号。

科学检查有两种 pass policy。Pointwise 是直接比较物理观测值：

$$|c - r| \leq a + \rho \cdot |r|$$

c 是观察值、r 是参考值，a 是绝对容差、ρ 是相对容差。a = ρ = 0 时退化为完全相等检查。这种 policy 适用于所有"敏感度可被一个 bound 包住的物理量"。论文专门提醒：存储顺序、自适应步数、计时、rank/chunk layout、随机抽取、特征向量相位——这些不是物理观测值，不该用 pointwise 检验。

Invariants 是另一种策略：当 pointwise 容差包不住随机流、发散流、采样统计、离散输出时，改为比较矩、分布、守恒量、积分范数。比如一个湍流场的瞬时数值点态比较会因随机种子漂移而失败，但它的能量谱密度曲线是否落在参考分布的某个置信带内——这是 invariant 检验。

每一项 check 都配一个 plain-language warrant：它检验什么物理量、它区分什么类型的偏差、合法实现为什么能稳定满足它。Check 套件在任务生成前冻结，后续任何任务的 instruction 只是描述"你想让 agent 做什么"，验收合约本身不动。

接下来是论文的核心公式——partial credit repair reward：

$$r_{\text{repair}} = \max!\left(0,\ \frac{r - f}{1 - f}\right),\quad 0 \leq f < 1$$

r 是修复后的科学合约得分（0–1），f 是修复前 baseline 的得分。归一化的意义是：只有 baseline 留出上升空间（f < 1），归一化才有意义；满分只有"修回参考态"才能拿到。这个 reward 直接作为 SFT 数据的标签打分器和 RL 的奖励信号，单位不是 pass@1，是连续的部分得分。同期 SWE-bench Science 的 47.90% Pass@1 与 ScienceIDE 的 r_repair 是不同单位，不能互相映射——前者是"测试是否通过"的离散判断，后者是"恢复到参考态多少"的连续评分。

为什么这套机制能跑通？因为 episode 是在容器里跑的，而 ScienceIDE 的 episode runtime 正是 Harbor 框架 提供的统一接口。Harbor 把任务抽象成 task.toml + instruction + environment + test + solution 四要素（或图内图标写作 Task/Env/Test/Solution——同一含义），ScienceIDE 的 hard85/mitgcm-atmos/<task>/ 目录就是这套 schema 的本地实例化：把 defect.json 和 fix.json 显式化以支持 r_repair 的归一化部分得分。Harbor 还有一道关键安全开关——verifier.environment_mode 选 separate 时，verifier 跑在独立容器，agent 篡改不了 judge；ScienceIDE 的 85 个 hard85 task 全部走 separate 模式，这是为什么 reward_repair 不会被 agent 越权作弊。

图注：Harbor 论文 Figure 1 局部（按可读取版本）。上方彩色六边形按 9 个 domain 组织约 50+ benchmark；下方左侧"Harbor Adapters: Connect datasets to agents"框列出四个任务要素（图中图标写作 Task/Env/Test/Solution，caption 写作 instruction/environment/test/solution，二者同义）；右侧"Agents + Models"框展示多个 agent 工具 logo；右下预留"Future Benchmarks"和"Future Agents"占位。这张图说明的是 ScienceIDE 自己的 episode 容器层底座：ScienceIDE 的 hard85 任务与 SWE-bench Science 等其他 agentic benchmark 共享同一个 Harbor 抽象，因此 ScienceIDE 不是另起炉灶，而是站在已有生态上。来源：arXiv:2609.04298。

到这里读者应该带走一件事：科学合约不是写在 prompt 里，而是写在每个 environment 的 checks 套件里——同一套校验同时给 SFT 数据打标、给 RL 提供 reward、给评测产出最终分数，这是 ScienceIDE 能统一三类训练流的根因。

四、训练 PhAI-IDE：从 SFT 到 PSRL，让长程科学任务不被"早结束"骗分

抽象到位、reward 设计好，下一步是把模型训出来。ScienceIDE 团队训了一组 PhAI-IDE 模型族（4B / 9B / 72B），分 SFT 和 RL 两段，每段都有需要单独处理的工程细节。

SFT 段：基座分别是 Qwen3.5-4B、Qwen3.5-9B、Qwen2.5-72B-Instruct；训练数据是 4,567 段 / 564 任务，验证 544 段 / 81 任务，train/validation 在 task identifier 层面严格不相交。Teacher = GPT-5.6-sol 的演示轨迹，再用 numerical-equivalence verifier 过滤掉答错的样本。训练框架是 ms-swift + LoRA（rank 32 / alpha 64 / dropout 0.05），BF16、全局 batch 64、36,864 token 序列上限、学习率 2×10⁻⁵、3 个 epoch（216 步），最终权重把 LoRA 合进 BF16 Safetensors。训练指标：4B loss 0.383 → 0.340 / token acc 91.12%；9B loss 0.369 → 0.325 / 91.33%；72B loss 0.401 → 0.313 / 92.01%。最终 checkpoint 不是按公开榜单选出来的——这是 ScienceIDE 给出的一个干净的小细节，避免评测集污染 final selection。

RL 段：RL 部分才是工程上的硬仗，因为科学任务几乎都是长 horizon——一次 PLUTO 跑几分钟到几小时，一次 MITgcm 编译后跑几十万个时间步，多步多文件编辑是常态。论文给这套 RL 命名为 PSRL——veRL 训练器的工程定制，不是新算法。它的关键技术点有三个： HybridFlow

第一，Dr.GRPO 风格 group-relative advantage。veRL 本身是 ByteDance Seed 团队基于 HybridFlow（arXiv:2409.19256，EuroSys 2025）开源的 RL 训练栈；GRPO 的核心思想是不用 critic、对每个 prompt 采 G 条轨迹、用组内 reward 均值作 baseline。Dr.GRPO（arXiv:2503.20783，COLM 2025）进一步去掉标准差归一化和长度归一化——论文的 §4.3 写到"near-bimodal group rewards would otherwise inflate isolated successes"，意思是当组内奖励接近双峰分布时，除以 std 会把孤立成功人为放大，去掉它能让估计更无偏。ScienceIDE 用 G=8 的组规模，优势函数 $\hat{A}i = R_i - \frac{1}{G}\sum{j=1}^G R_j$，配合 DAPO Clip-Higher 的非对称 clip（ε_low=0.2 / ε_high=0.3，让罕见的修复动作还有机会增加概率质量）。

第二，token-level 截断重要性采样 + TITO prefix 哈希。PSRL 把 rollout 训练拆分到三个池子：vLLM rollout worker（独占 GPU）+ Harbor agent-loop worker（共享 CPU 或独占 CPU+GPU）+ PSRL training worker（独占 GPU）。24 张 H20（95GB）跑一次：8 张 generation（TP=2、4 个 instance）+ 16 张 training（FSDP2 + Ulysses SP=4）。rollout 与训练在分离 GPU 上并发运行，token 级别的截断重要性采样 w_{i,t} = min(exp ρ_{i,t}, C) 校正单步 policy staleness，C = 2.0。每一步轨迹是 token-in-token-out、严格前缀扩展（TITO prefix hashing）。

第三，也是最关键的——截断掩码（truncation mask）。长 horizon 任务的天然陷阱是：策略发现"少做几步更划算"，因为 reward 用 token-mean loss 时，最长轨迹的 token 数被压低，分母惩罚最强——结果智能体学会的不是修复代码，是缩短轨迹。

图注：GiGPO 论文 Figure 2（arXiv:2505.10978v3）。一组并行环境共享 anchor state，分别 rollout 出多条轨迹；GiGPO 做两层 group 计算——episode-level $A^E$（在完整轨迹之间）+ step-level $A^S$（在相同 anchor state 处的动作之间）——产出层次化的相对优势，用于长程 agent 的 fine-grained 信用分配。注意这是 GiGPO 不是 GRPO：GiGPO 在 GRPO 基础上加了 step-level grouping，与 ScienceIDE 的 truncation mask 解决的是同源问题（都是长程 agent 的信用分配），但 PSRL 用的不是 GiGPO，而是 Dr.GRPO + 截断掩码。来源：arXiv:2505.10978。

ScienceIDE 的修法很直接：给被 budget 截断的轨迹套一层掩码——它们的 reward 还能贡献到组 baseline（影响 advantage 计算），但被截断的 token 不进入 loss（不惩罚策略"太长"）。表 tab:rl-truncation 把"打掩码"和"不打掩码"对比写得很直白：未打掩码时 mean reward 从 0.339 升到 0.573 然后塌缩到 0.078——因为策略找到了"缩短轨迹"这条捷径；打上掩码后，truncation rate 从 29% → 2.3%，tokens per turn 稳定在 1095–1165 区间（策略不再靠缩短轨迹拿分），最终 mean reward 0.487 → 0.914。

图注：ScienceIDE 论文 Figure 11。三个池子各占独立硬件：rollout worker 跑 vLLM、独占 GPU；agent-loop worker 跑 Harbor 容器化的 episode，CPU 或 GPU 视并发密度；training worker 跑 PSRL trainer，独占 GPU。三阶段在一个 iteration 内同时进行（rollout → verifier reward → optimizer step），权重异步更新。强调 PSRL 不是新算法，它是 veRL 训练器的工程定制——硬件分工 + 异步更新 + 截断掩码都是工程问题。来源：arXiv:2609.19134。

实际跑 RL 的两个环境（都用 L1 hints：给文件+行号+编辑类别，不给具体修复方案）都从 base Qwen3.5-4B 起步，没有 SFT init。LAPS（99 任务：85 train / 14 val）step-30 时 held-out reward 从 base 0.357 升到 0.857（2.4 倍）；MITgcm-biogeo（87 任务，source split 64/23，验证集实际跑了 21 个 task）从 base 0.286 升到 0.571（2.0 倍）。截断率 LAPS 从 39.5% 降到 6.6%、biogeo 从 34.1% 降到 23.8%——伴随策略没有靠缩短轨迹拿分。

到这里读者应该带走一件事：长程科学 RL 不是"选更好的算法"就能跑通的事——必须把"超时被截断"和"真的失败"区分开，否则策略会学会用更短轨迹骗过 verifier。截断掩码是 PSRL 唯一的新设计，剩下全是现成训练栈的工程组合。

五、科学修复拿下了多少？通用基准上又带回了什么——以及论文自己画的边界

到这里该把账算一算了。PhAI-IDE 在科学代码修复上拿下多少？通用基准上有没有正迁移？论文自己也给得很老实——既有显著的正向数字，也有一条诚实的退化。

Held-out 科学修复（基于仓库原始数值校验 + 相同 greedy decoding + 8,192 token 上下文 + 2,048 token 回复 + 单次结构化补丁）：

0.0000 → 0.3333 的含义不是"只能修好三分之一"，而是 partial credit 的归一化——模型从 baseline 出发上升到了满分的三分之一。这说明：以前 baseline 完全答不对的缺陷，模型现在能恢复部分科学合约。

通用基准上的正迁移（disjoint items、paired-bootstrap 95% 区间、未对多重比较做校正）：

最后一行必须摆出来——这是诚实的退化。4B 的 HumanEvalFix JavaScript 拿了 +10.98 pp、QuixBugs Java 4B +10.00 pp，但 9B HumanEvalFix Python 掉了 8.33 pp，72B HumanEvalFix C++ 在 confirmation 集上也没稳住。这告诉我们：positive transfer 并不是普适的，selected benchmarks ≠ all benchmarks——论文在 §5 Limitations 里也明确承认这一点。

ScienceIDE-Hard 排行（同一 85 个科学 repair/implementation 任务、一小时 budget）：Fable 5.1 67.1%（单次估计，无区间）、Opus 5 64.6%、Astra 63.1%、Sol 55.0%、其余 11 个 agent 全部 < 40%。需要特别注意：Fable 是单次估计，Opus 和 Astra 的 bootstrap 区间互相重叠——这不是统计意义上稳定的排名。成本分布也很有意思：Fable 67.1% 花了 $7.90/task、平均 85.7k 输出 token；Astra 63.1% 花了 $3.56/task、平均 13.9k 输出 token。资源消耗与科学正确性是两个独立维度，论文里的 Spearman 系数（成功度对运行时间 -0.22、对输出量 0.01）也支撑这一点。

同期对照口径——SWE-bench Science（arXiv:2608.19799）在 119 个真实科学软件任务上做了 Pass@1 评测，最强 Claude-Opus-5 + Claude Code 47.90%。Pass@1 与 reward_repair 不可互相映射——前者是离散判断"测试通过与否"，后者是连续评分"恢复到参考态多少"。把这个区分讲清楚就好。

图注：SWE-bench Science 论文 Figure 6（token vs Pass@1）。横轴是 mean per-task token、纵轴是 Pass@1。Claude-Opus-5 在中等 token 预算 / 最高 Pass@1 区；GPT-5.6-sol 用更少 token 拿到更低 Pass@1；DeepSeek-V4-Pro 输入 token 最多、Pass@1 居中。这张图的价值是说明"Pass@1 与 token 消耗是 trade-off 关系"——并提醒读者：ScienceIDE 的 reward_repair 与 SWE-bench Science 的 Pass@1 不是一个单位，不能画等号。来源：arXiv:2608.19799。

论文自己画的边界——§5 Limitations 的几条主线必须复述给读者：

(1) ScienceIDE 现在的证据只针对 reference-verifiable software tasks（predominantly repair and implementation in computational physics / geoscience），不是开放科学发现；广任务覆盖、1000 environment 的 release 都是开发目标。 (2) Factory 生成的变体可能共享代码路径和假设，任务数量不等于独立科学覆盖率。 (3) Verification 是科学建模选择——与选定观测值和校准容差一致，并不证明这些容差之外的正确性；合法的替代实现可能与参考解不一致。外部独立审计、对抗性 reward-hacking 评测仍是 outstanding。 (4) Factory amortize rather than eliminate 专家审核；扩展仍依赖领域专业知识和上游再分发权。 (5) Retrieval controls 不能排除预训练知识对公开源码的接触；legacy images 保留文件时间戳线索；SFT 增益限于selected public benchmarks，RL 增益限于hinted held-out tasks within training environments——两者都没建立"迁移到未见 codebase"的证据。 (6) RL 比较没估计 between-seed variance。

到这里读者应该带走两件事：第一，ScienceIDE 的主张不是"智能体能做科学发现"，而是"科学经验能反向训练出更强的智能体"——前者没证据，后者有正图也有退化，二者必须分开读。第二，reward_repair 与 Pass@1 是不同单位——SWE-bench Science 的 47.90% 不能拿来跟 Fable 的 67.1% 比高低，两个排行的"通过"定义根本不在同一个世界里。

ScienceIDE 给智能体训练基础设施提供了一个具体的答案：把科学代码改造成 episode、把物理合约写进 reward、把长程任务的训练塌缩用截断掩码修掉。整篇论文都是为这条主线服务——skeptical 的一面是：现在的成就只是在 reference-verifiable 的小范围科学软件修复上，正迁移是 selected、不是 all，verification 是 modeling choice 不是真理。一句话：让科学经验反向喂出更强的智能体，ScienceIDE 把"训练基座"这件事认真做了一遍——这本身比"又一个科学代码评测集"重要得多。

想深入可以读原文：ScienceIDE: Turning World's Scientific Codebase into Agent Learnable Environments — arXiv:2609.19134 ｜ 代码仓库 ｜ HF 模型

参考文献

1. Hejia Geng, Zesen Huang, et al. ScienceIDE: Turning World's Scientific Codebase into Agent Learnable Environments. arXiv:2609.19134, 2026. arXiv:2609.19134 — 全文 4 级抽象、reward_repair 公式、SFT/RL 配方、leaderboard、§5 Limitations 的主要来源。
2. Zhipeng Xu, Jiahao Lu, Yining Zheng, Yuxin Wang, Xipeng Qiu. SWE-bench Science: Can Coding Agents Resolve Engineering Tasks in Science?. arXiv:2608.19799, 2026. arXiv:2608.19799 — 119/98/20 任务分布、47.90% Pass@1 同期对照、Chain-of-Evidence Protocol、4 类失败机制的来源。
3. Harbor Framework Team. Harbor Adapters and Harbor-Index: Infrastructure and a Curated Meta-Dataset for Large-Scale Agentic Evaluation. arXiv:2609.04298, 2026. arXiv:2609.04298 — ScienceIDE episode runtime 容器底座、task schema、shared/separate verifier environment 的来源。
4. Sheng et al. HybridFlow: A Flexible and Efficient RLHF Framework. arXiv:2409.19256, EuroSys 2025. arXiv:2409.19256 — veRL 训练栈底层；与 Liu et al. Understanding R1-Zero-Like Training: A Critical Perspective (arXiv:2503.20783, COLM 2025) arXiv:2503.20783 提供 Dr.GRPO 的来源、Feng et al. Group-in-Group Policy Optimization for LLM Agent Training (arXiv:2505.10978, NeurIPS 2025) arXiv:2505.10978 提供 GiGPO 长程信用分配的对照。
5. Minyang Tian, et al. SciCode: A Research Coding Benchmark Curated by Scientists. arXiv:2407.13168, 2024. arXiv:2407.13168 — 80 main / 338 sub / 5 disciplines / Claude3.5-Sonnet standard 4.6% 的科学代码评测前作对照。
6. Ziru Chen et al. ScienceAgentBench: Toward Rigorous Assessment of Language Agents for Data-Driven Scientific Discovery. arXiv:2410.05080, ICLR 2025. arXiv:2410.05080 — 102 tasks / 44 papers / best agent 32.4% / o1-preview 42.2% 的科学 agent 前作对照。
7. PhAI Labs / AItonomy Foundation. ScienceIDE Project Page. aitonomy.org/projects/scienceide — ScienceIDE / ScienceBuddy / JEPA-Anything 三模块组织上下文、PhAI Labs / AItonomy 关系说明的来源。
8. PhAI Labs / AItonomy Foundation. ScienceIDE GitHub Repository & Hugging Face Collection. github.com/aitofound/ScienceIDE / huggingface.co/collections/AItonomy/scienceide-model-series — 15 published environment × upstream × license 列表、task.toml 字段语义、hard85 目录结构、PhAI-IDE-4B/9B/72B model card 的工程化一手来源。