把数据库评分变成 RL 奖励：用 ThinkingBox 后训练智能体

作者：Tuhin Kundu（Microsoft），由 Hugging Face 发布

发布于 2026 年 10 月 22 日

这是我们的第一篇博客《智能体说它做完了。数据库不同意。》的后续。ThinkingBox-Training 现已在 GitHub 上提供。

我们构建 ThinkingBox，通过比较最终数据库状态与预期结果来评估智能体的工作。随后，我们把同类的可执行信号用作 ThinkingBox-Bench 之外训练任务上的奖励。对 Qwen3.8-27B，平均成功率从 51.70% 升至 60.78%，而在全部二十次尝试中都正确完成的任务数从 38 个升至 107 个（用 50 步 GRPO）。

图 1. ThinkingBox 把对终端数据库状态的可执行检查变成奖励，用于在 ThinkingBox-Bench 之外的任务上后训练智能体。

这是一篇由 Microsoft 与 Hugging Face 联合撰写的博客，特别感谢 Microsoft 的 Mirco Milletari 和 Xiang Jiang、Hugging Face 的 Sergio Paniego，以及我们此前的实习生 Zhuochun Li（匹兹堡大学）在共同撰写与审阅方面的贡献。

我们构建 ThinkingBox 是为了抓住那些声称做完了、实际却没做完的智能体。

ThinkingBox-Bench（我们的基准数据集）中的 507 个任务每一个都会交给智能体一套真实后端和一组工具，让它工作，然后检查数据库里真正改变了什么。在第一篇文章中，我们抓到一个模型把客户工单关闭为"已解决"，而背后承运商的异常仍未关闭。九次看起来称职的工具调用，一行错误的数据库记录。

随后我们注意到了自己构建出来的东西。对大多数任务而言，一个可执行检查可以直接从最终数据库状态返回 1 或 0。这不只是评分器。这可以成为奖励函数。+

于是我们从基准之外使用 ThinkingBox 格式的任务构建了一个训练池，并把它们的可执行结果用作奖励。难点在于挑选哪些任务适合智能体训练：大多数任务要么已经被解决，要么对眼前的模型而言毫无希望，而这两类都教不会它任何东西。

难度是相对于策略的：一个任务只在当前模型学会它之前才算难。

我们称之为离线策略相对难度（offline policy-relative difficulty）。我们在训练前用基础策略对每个任务的成功概率估计一次，并在整个训练过程中保持选出的训练池固定不变。

训练之后发生了什么#

我们用离线策略相对难度构建训练池，然后用 GRPO 对 Qwen3.8-27B 微调 50 步。回顾一下：我们每个基准任务评估 20 次。pass@1 衡量全部 10,140 次尝试的平均成功率。pass@20 衡量至少被解决一次的任务占比。Observed 20/20 衡量在每一次记录尝试中都通过的任务占比。

表 1. Qwen3.8-27B 在离线筛选训练池上做 50 步 GRPO 前后的结果。

训练显著提升了可重复的成功率，同时"至少一次覆盖"小幅下降。本文余下部分解释我们如何挑选练习任务、如何构建奖励回路，以及如何测量这一权衡。

在一个任务上，这种改善是什么样子？一位旅客请求降低房型，但公司政策要求先经经理批准。训练前，智能体在 20 次尝试中有 15 次未经批准就修改了预订并发放退款。RL 微调后，它在全部 20 次中都保住了预订与支付状态。

图 2. 一个企业酒店预订任务，每个模型 20 次尝试。基础 Qwen3.8-27B 模型有 15 次在缺少必要经理批准的情况下修改了预订。RL 微调后的模型在全部 20 次中都保住了预订与支付状态；19 次中所有预期记录都匹配。

目录

• 基准发现了什么，六十秒版
• 结果：可靠性那一列动了
• 收益落在哪里
• 可靠性要付出什么代价
• 训练回路
• 离线策略相对难度
• 什么才配得上奖励
• 运行训练栈
• 接下来往哪走

时间紧？头条结果就在上面。实现细节在"运行训练栈"一节。

基准发现了什么，六十秒版#

ThinkingBox-Bench 依据智能体留下的数据库记录来评分。它的 507 个任务每一个都会启动真实后端，交给智能体一组 MCP 工具和一个带私有上下文的模拟 LLM 用户，最后对终端数据库状态运行可执行检查。检查针对的是需要正确的后端记录，而不是具体的工具调用。这会激励模型去发现可能全新的解法路径，而不是"重新发现"人类给出的、可能次优但正确的解法。

在第一篇文章中，我们让十八个模型各跑该基准二十次，并报告了头条准确率所掩盖的差距。Kimi-K3 至少一次解决了 93.89% 的任务，但只在全部二十次记录尝试中完成了 507 个任务中的 68 个（13.41%）。Claude Opus 5 则相反：覆盖更窄，一致性高得多。

而且更大或更好的模型并没有消除这个差距。Claude Opus 5.5 在 pass@1 上比 Claude Opus 5 高 0.66 个百分点，却在全部二十次尝试中通过了完全相同的任务数——241 个。头条准确率上的这点收益，没有换来任何额外的可靠性。

如果你要为涉及生产数据库记录的工作挑选模型，不应只看 pass@1。Observed 20/20 展示了哪些任务在每次尝试中都成功，这更接近生产可靠性所需。

可执行的终端状态判定同时也是训练奖励。在拆解训练回路之前，先看封存基准上发生了什么变化。

结果：可靠性那一列动了#

训练 Qwen3.8-27B 后，我们在它从未训练过的 507 任务基准上评估了选中的第 50 步检查点。这 507 个任务构成一个分布外测试集：它们的领域、数据库和大多数 MCP 工具在 RL 训练中都没出现过。

表 2. ThinkingBox-Bench 按领域的 pass@1（%），包含我们第一篇文章表 2 中的部分模型，以及我们针对不同领域和总体微调出的模型。Observed 20/20 是在全部 507 任务基准上统计的。每个模型都在全部 507 个任务上评估，每个任务重复 20 次试验。加粗标记该列最高，下划线标记次高。

头条结果是表 1 中的 observed-20/20 那一行。一个 27B 模型最初每次尝试都能完成 ThinkingBox-Bench 的 38 个（7.5%），现在每次尝试能完成 107 个（21.1%），几乎是三倍。作为对照，Kimi-K3 的 observed 20/20 为 68，GPT-5.4 为 128，GPT-6 Astra 为 231，Claude Opus 5.5 以 241 领先。

平均成功率与可重复性会给出不同的排序。在表 2 中可以看到，GPT-5.6 Sol 的 pass@1 略高于 RL 微调后的 Qwen3.8-27B（61.91% 对 60.78%），但在全部 20 次记录尝试中通过的任务更少：82 对 107。Claude Sonnet 4.6 的 pass@1 更低，为 59.19%，却几乎每次都能通过同样多的任务，为 102。单看任何一个指标都无法反映全貌。

观察到的模式与"锐化"（sharpening）一致：可重复的成功上升，而至少一次覆盖小幅下降。这与先前的工作相符。一种解释是概率分布向能反复奏效的轨迹移动，同时一些低概率路径消失了。

总体上，模型并没有变得更宽。它变得更可重复。下一个问题是这些收益落在哪里。

收益落在哪里#

图 3. 领域级基础得分、RLFT 得分与百分点变化。绿色变化格表示提升，红色表示下降；蓝色深浅表示各指标内的分值水平。

pass@1 和 observed 20/20 在全部五个领域都有上升。pass@20 则有好有坏：数字银行和咨询上升，而零售、旅行和车险下降。车险的广度损失最大（−7.0 个百分点），零售的 observed-20/20 提升最大（+24.5 个百分点）。

可靠性要付出什么代价#

第一篇文章用简单算术给一致性定价：把整个 20 次运行活动的估算成本，除以模型每次都通过的任务数。

每个可靠任务的成本 = 507 × 20 活动的估算成本 ÷ 通过 20/20 的任务数

把同样的成本算术应用到微调检查点实测的 token 用量上：

表 3. 基础与 RL 微调 Qwen3.8-27B 的估算评估成本与可靠性。每次成功尝试成本 = 总估算活动成本（507 × 20）除以通过的尝试数。

以每个可靠任务 $8.00 计，微调后的模型接近配套比较中的 GPT-5.4（$6.80）、GPT-6 Astra（$7.45）和 Claude Opus 5.5（$7.80）。

单次尝试视角#

图 4 把每次成功尝试成本对 pass@1 作图。

图 4. 金色箭头标记 Qwen3.8-27B 基础模型的帕累托成本位置到 RLFT（菱形）的移动：pass@1 从 51.70% 升至 60.78%，而每次成功尝试的估算成本从 $0.177 降到 $0.139。带环圆圈标记帕累托成本前沿。

这一移动让微调后的检查点接近 GPT-5.6 Sol，不过后者仍然更便宜、pass@1 也略高。我们论文中定价的四个模型落在绘图范围之外。

这些美元数值是比较用的服务指数，不是发票或云账单。服务微调检查点的成本与基础模型相同。该计算包含模型推理成本，不包含训练运行与用于整理训练数据集的策略探测成本。

这些结果告诉了我们什么动了。接下来几节解释训练回路，以及为什么挑选正确的任务最为重要。

训练回路#

图 5. 六个阶段，放在上下文中：候选任务输入，前三个阶段离线运行一次，后三个阶段在训练运行中每组重复。训练出的检查点再对 ThinkingBox-Bench 评估。

筛选只离线运行一次，针对基础策略模型（本例中为 Qwen3.8-27B）；训练随后使用这个已固定的、经过整理的池。图 5 中的琥珀色虚线箭头标出了我们没有走的路径：在训练运行期间重新探测难度。

每个 rollout 是一个完整回合，而不是一次文本补全。它会获得一个全新后端、一个隔离的 MCP 会话，以及作为模拟用户的 GPT-5 Chat。多数奖励来自确定性的终端状态检查；少数狭窄的评分细则要求会调用配置的裁判（GPT-5 Chat）。

训练和评估必须以完全相同的方式解释 Qwen 的输出。这包括推理提取、工具调用、参数类型、渲染以及隔离的任务状态。否则奖励衡量的就是一个与被评估模型不同的智能体。共享的解释代码在 trainer/core/tb_interpret.py。

作为参考运行，我们在 187 个任务上对 Qwen3.8-27B 做全参数 RL 微调，使用 token-mean GRPO。每次更新生成 18 组、每组 8 个 rollout，即 144 个回合，分布在 24 块 H100 上。训练同步进行，参数与优化器做卸载；AdamW 学习率 1e-6，权重衰减为零。我们跑了 50 步。

训练中零方差组按 DAPO 风格被替换。系统错误单独处理：后端超时不算智能体的错误结果，因此受影响的组会被重新填充，而不是记为失败。

这解释了保留下来的任务是如何被训练的。剩下的问题是哪些任务进入了训练池。

离线策略相对难度#

在深入任务筛选之前，先声明一点：

ThinkingBox-Bench 的任何任务都没有被纳入 RL 训练池。基准被保留用于评估。

ThinkingBox-Bench 相对 RL 训练池是分布外的：它的领域、数据库、策略和大多数工具在 RL 训练中都没有出现过。两个集合仍共享 ThinkingBox 框架、模拟用户机制、可执行的终端状态评分、少数通用工具，以及相似的任务风格。这些共享元素限制了迁移结论的适用范围。

为什么筛选重要，归根到底是一个关于 GRPO 的算术事实。如果八次 rollout 全部失败，奖励向量是 [0, 0, 0, 0, 0, 0, 0, 0]。如果八次全部成功，则是 [1, 1, 1, 1, 1, 1, 1, 1]。无论哪种情况，组内中心化都不会产生任务奖励优势，因为没有哪条轨迹比另一条做得更好。++

而像 [0, 0, 0, 1, 1, 1, 1, 1] 这样的混合组，提供了 GRPO 可以学习的对比。对有状态智能体来说，这种区分很昂贵：每次 rollout 都要准备一个隔离后端、运行一次真实工具会话，并调用另一个模型来扮演用户。

因此塑造这项工作的，不只是"用哪个模型或优化器"，而是：哪些候选任务应该进入固定的训练池？

我们在后验上使用离线通过率过滤器来筛选训练池。它估计哪些任务在基础策略下很可能产生有对比度的终端奖励。

于是我们做探测。每个候选任务针对基础策略模型反复运行。用大白话说：模型总是失败的任务，现在多半还教不会它；总是通过的任务，已经学会了；偶尔能解决的任务，结果才有对比。

从有限探测中估计难度#

每个候选任务运行 n 次，产生 k 次成功。我们用 Jeffreys 后验概率来建模其潜在成功概率：

成功概率 | n 次探测中 k 次成功 ~ Beta(k + ½, n − k + ½)

图 6. 离线策略相对难度由对基础策略的重复探测估计，并用于保留那些可能产生对比奖励的任务。

我们把单位区间按 0.08、0.40、0.60 和 0.90 的边界划分成五个桶，这些边界是这些运行中选定的超参数。每个任务被分配到后验质量最大的那个桶：

• 极少解决 [0, 0.08)：丢弃
• 困难 [0.08, 0.40)：保留
• 中等 [0.40, 0.60)：保留
• 经常解决 [0.60, 0.90)：保留用于全参数 RLFT
• 几乎总能解决 [0.90, 1]：丢弃

更多细节见我们 ThinkingBox 论文的附录 C.4。

一个任务的端到端流程#

图 7. 放大来看，一个任务经过全部六个阶段：GPT-5.4 可解性筛查、基础模型探测、难度分类、一个 rollout 组、终端状态评分，以及一次 GRPO 更新。

图 7 追踪一个可能进入训练池的候选任务。对 Qwen3.8-27B 全参数据池，GPT-5.4 先充当可解性筛查。基础策略随后在少量探测中成功，例如 8 次中 3 次，产生 Beta(3.5, 5.5) 后验。其后验质量的最大部分 54.0% 落在"困难"区间。

当它被采样用于训练时，该任务产生了混合奖励组 [0, 0, 0, 0, 1, 1, 1, 1]。于是成功轨迹获得高于均值的任务优势，失败轨迹获得低于均值的优势，给 GRPO 提供了可学习的对比。另一个策略模型可能把同一个任务放进不同的难度区间。

最终的 Qwen3.8-27B 整理训练池包含 187 个任务。

什么才配得上奖励#

与轨迹无关。奖励就是任务自己的可执行判定。

一个回合结束时，沙箱会提取后端中实际改变了什么，并对终端状态运行该任务的确定性检查。任何产生正确终态轨迹都通过。错误、缺失或多余副作用都算失败。奖励为 1 或 0。

在基准中，数据库评分器可以看作"考官"：它抓住了那些报告成功却留下错误记录的智能体。在训练中，同类检查可以看作"老师"，作用在另一组不相交的任务上。

两条奖励路径，一个二元判定

• 可执行检查（绝大多数）：当所需结果体现在终端状态或副作用中时，由确定性测试接受或拒绝；无需调用 LLM 裁判。
• 裁判辅助检查（少数）：当某个狭窄要求无法干净地从数据库状态中判定时，由配置的 LLM 裁判回答一个二元评分细则问题，供可执行测试使用。

运行训练栈#

我们在 microsoft/thinkingbox-training 中发布了用于训练 Qwen3.8-27B 的数据筛选、rollout、奖励和 Verl 集成。仓库 README 是入口。详细指南包括：

• docs/data-preparation.md：任务填充、策略探测、基准排除，以及训练/验证划分；
• docs/reference-q38-run.md：经过验证的 24 卡 H100 Qwen3.8 配置；
• docs/evaluation.md：合并检查点并运行 ThinkingBox-Bench 507 × 20。

开始之前#

已在 Python 3.12 和 uv 的 Linux 与 WSL 上测试。你需要带兼容 CUDA/NCCL 栈的 NVIDIA GPU、本地 Qwen3.8-27B 检查点，以及供模拟用户和裁判使用的 OpenAI 兼容端点。经验证的参考配置使用 3 节点 × 8 块 H100 GPU；更小的自定义配置取决于模型规模、上下文长度和 rollout 并发度。

公开的示例任务列表只用于演示接口。它不是所报告运行所用的私有 187 任务训练池。请提供经授权、且与公开基准保持不相交的训练来源。

安装#

把三个仓库并排放置：

mkdir -p ~/thinkingbox-workspace
cd ~/thinkingbox-workspace

git clone https://github.com/microsoft/thinkingbox.git
git clone https://github.com/microsoft/thinkingbox-data.git
git clone --branch main https://github.com/microsoft/thinkingbox-training

git -C thinkingbox checkout 892964e7226044e5463ad188da119df838f4bec1
git -C thinkingbox-data checkout thinkingbox-bench-v1.0

创建经过验证的环境#

发布的栈面向 Linux、Python 3.12、Verl 0.9.0，以及锁定的依赖包：

cd ~/thinkingbox-workspace/thinkingbox-training

uv venv --python 3.12
source .venv/bin/activate

uv sync --frozen --extra fast --extra tracking --extra eval-proxy
uv pip install -e ../thinkingbox
uv pip install --config-settings editable-mode=compat \
    -e ../thinkingbox-data/servers/thinkingbox_tools
uv pip install --config-settings editable-mode=compat \
    -e ../thinkingbox-data/servers/tb_business_ops_servers_202606

python scripts/prepare_verl.py --dest .deps/verl --install
python scripts/verify_verl_install.py
uv pip check

最后两条命令应报告一个经过验证的、打过补丁的 Verl 检出，且没有破损的依赖。之后不要再运行自动包同步：它可能用原版 Verl wheel 覆盖打补丁的源码安装。

准备训练数据#

从公开提供的样本开始，或以 ThinkingBox 格式加入你自己获授权的数据集。然后运行仓库的准备脚本：

cd ~/thinkingbox-workspace/thinkingbox-training
source .venv/bin/activate
python data/prepare_data.py --help

该脚本汇总策略探测结果，应用离线策略相对难度过滤与基准排除，并写出选定的 train.yaml 和 test.yaml。docs/data-preparation.md 记录了输入字段、加载器契约和完整命令。

配置并检查启动#

按 docs/reference-q38-run.md 启动 Typesense 和 MCP 服务器，配置模拟用户与裁判，设置模型、任务列表、检查点和拓扑变量，并准备 Ray 集群。凭据应通过运行时密钥注入，而不是提交到文件或留在 shell 历史中。

在分配训练作业之前，先用指南中的试运行命令：

DRY_RUN=true ./scripts/run_train.sh \
  trainer.total_training_steps=50 \
  trainer.save_freq=5

它必须在不启动 Ray、不分配 GPU 的情况下以零退出。在启动运行之前，阅读它输出的 python -m verl.trainer.main_ppo 命令和每一条解析后的覆盖项。

训练#

启动器负责配置训练，不负责准备主机。在参考的三节点拓扑上，在每个节点导出相同的环境变量，把 CHECKPOINT_DIR 挂载到相同的绝对路径，然后启动 Ray：

# 头节点
ROLE=head NODE_IP="$HEAD_IP" GPUS_PER_NODE=8 \
  ./scripts/start_ray.sh

# 每个工作节点
ROLE=worker NODE_IP="$WORKER_IP" \
  HEAD_ADDRESS="$HEAD_IP:6379" GPUS_PER_NODE=8 \
  ./scripts/start_ray.sh

当 ray status 报告全部 24 块 GPU 后，从头节点启动一次：

export RAY_ADDRESS=auto
export GPUS=0,1,2,3,4,5,6,7

./scripts/run_train.sh \
  trainer.project_name=thinkingbox-training \
  trainer.experiment_name=q38-full-rlft \
  trainer.total_training_steps=50 \
  trainer.save_freq=5

通过 OpenEnv 评估检查点#

ThinkingBox 的第一篇文章覆盖了 Typesense、MCP Session Proxy 和 OpenEnv 的配置。按 docs/evaluation.md 合并训练出的检查点，然后用 vLLM 提供服务。

在 OpenEnv 仓库根目录，把 MERGED_MODEL 设置为合并后的模型目录，把 THINKINGBOX_DATA 设置为锁定的基准检出。历史检查点评估使用下面这套八卡 A100 服务配置：

vllm serve "$MERGED_MODEL" \
  --served-model-name q38-rlft \
  --host 127.0.0.1 \
  --port 8001 \
  --tensor-parallel-size 8 \
  --dtype bfloat16 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.85 \
  --max-num-seqs 16 \
  --max-num-batched-tokens 8192 \
  --language-model-only \
  --enable-chunked-prefill \
  --enable-prefix-caching \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml

在另一个终端，从 ThinkingBox Training 检出目录启动针对 Qwen 聊天模板的 OpenEnv 兼容代理。它监听 8014 端口，并把请求转发到 8001 端口上的 vLLM：

cd ~/thinkingbox-workspace/thinkingbox-training
source .venv/bin/activate
bash scripts/launch_sysmerge.sh

评估期间让它保持运行。在另一个终端检查就绪状态：

curl --fail http://127.0.0.1:8014/readyz

更新现有 thinkingbox.yaml 中的智能体条目；保留其 MCP、模拟用户和裁判配置：

orchestrator:
  agent_model:
    type: aoai
    endpoint_url: http://127.0.0.1:8014/v1/chat/completions
    deployment: q38-rlft
    credential:
      type: api-key
      api_key: <your_api_key>
    is_reasoning: true
    temperature: 1.0
    top_k: 20
    top_p: 0.95
    max_completion_tokens: 8192
    timeout: 1800

如第一篇文章所述启动 OpenEnv，将 OPENENV_TB_CONFIG 指向这个 thinkingbox.yaml，OPENENV_TB_DATASET 指向 $THINKINGBOX_DATA。一旦 /ready 成功，运行 507 个任务 × 20 次尝试的完整协议：

uv run --project envs/thinkingbox_env --frozen \
  thinkingbox-eval \
  --config "$PWD/thinkingbox.yaml" \
  --base-url http://127.0.0.1:8000 \
  --dataset "$THINKINGBOX_DATA" \
  --output q38-rlft-full.jsonl \
  --errors-output q38-rlft-full-errors.jsonl \
  --repeat 20 \
  --coverage-profile full \
  --aggregate-output q38-rlft-full-aggregate.json \
  --message-timeout 1800

full 配置会在聚合之前校验全部 10,140 个预期的任务/重复键。

接下来往哪走#

这项工作有用的部分不是某个 Qwen3.8-27B 检查点，而是那个把可执行结果变成奖励的训练回路与训练数据整理流程。

如果你正在训练或评估一个会触及真实数据库记录的智能体：

• 先探测再训练。 拿你自己的智能体任务集，用基础策略对它跑 n 次，看看分桶直方图。根据我们的经验，团队往往从未检查过这个分布，而它通常比预期更偏斜。
• 检查一致性。 把同一份记录下来的模型输出分别通过训练与评估的解析器重放，确认两者提取出完全相同的工具名和参数。否则，训练可能奖励那些评估会另作解读的行为。
• 同时报告覆盖与可重复性。 说明在 k 次尝试中至少通过一次的任务数，以及全部 k 次都通过的任务数。偶尔找到解法的模型，未必是能稳定复现它的模型。

更多细节见以下链接：

• 环境：envs/thinkingbox_env
• OpenEnv：ThinkingBox 环境文档
• 框架：microsoft/thinkingbox · 教程
• 基准：microsoft/thinkingbox-data · v1.0 发布
• 数据集查看器：microsoft/ThinkingBox-Bench
• 论文：arXiv:2608.19741 或 HF
• RL 训练：microsoft/thinkingbox-training
• 博客：《智能体说它做完了。数据库不同意。》

引用论文#

@article{li2026thinkingbox,
  title = {One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows},
  author = {Li, Zhuochun and Ko, Youngmin and Keramati, Ali and Kundu, Tuhin and
    Tsai, Liang-Chun and Ferri, Nicola and Milletari, Mirco and Liu, Jiaxiang and
    Lopez Pelaez, Susana Palmaz and Wang, Yuepeng and Smolyakov, Vadim and
    Jiang, Xiang and Olafsson, Kjartan and Guy, Tommy},
  journal = {arXiv preprint arXiv:2608.19741},
  year = {2026},
  url = {https://arxiv.org/abs/2608.19741}
}

ThinkingBox 代码为 MIT 许可；基准数据为 CDLA-Permissive-2.0。

免责声明：公开基准中的每个任务都是合成重建。工作流与政策以真实企业智能体模式为原型；其中的客户并非真实。

ThinkingBox、ThinkingBox-Bench 和 ThinkingBox-Training 由 Microsoft Copilot Studio 团队与 Toloka 合作构建，合作者包括曾在 Microsoft 实习的匹兹堡大学、西北大学、哥伦比亚大学和加州大学欧文分校的实习生。欢迎在下方评论区、GitHub 上，或通过 firstnamelastname@microsoft.com 提问。

\+ 少数任务还包含针对数据库无法干净捕获的结果的狭窄二元评分细则要求；这些检查可以调用配置的 LLM 裁判。

\++ 这种零梯度问题有一个标准的批处理时修正：过采样、丢弃退化组、重新填充。全参数运行正是这么做的，类似于 DAPO 对零方差组的替换。但重新填充仍然要为每一个被丢弃的 rollout 付出全部代价。