Turning Database Grading into RL Rewards: Post-Training Agents with ThinkingBox

将数据库评分转化为强化学习奖励：使用ThinkingBox进行后训练代理

返回文章列表

[0

[-1

企业

]

文章

发布于2026年10月22日

点赞

-

[

图欣·昆杜

tuhink

关注

microsoft

这是继我们第一篇博客文章《代理说它完成了，但数据库持不同意见》之后的后续内容。ThinkingBox-Training现已在GitHub上发布。

我们构建ThinkingBox的目的是通过将最终数据库状态与预期结果进行比较来评估代理的工作。随后，我们使用相同的可执行信号作为ThinkingBox-Bench之外训练任务的奖励。对于Qwen3.8-27B模型，平均成功率从51.70%提升至60.78%，而在所有二十次尝试中正确完成的任务数量从38个增加到107个，GRPO步骤达到50个。

图1. ThinkingBox将终端数据库状态的可执行检查转化为ThinkingBox-Bench之外任务的后训练代理奖励。

#### 本文由微软和Hugging Face联合撰写，特别感谢微软的Mirco Milletari和Xiang Jiang、Hugging Face的Sergio Paniego以及我们前实习生李卓春（匹兹堡大学）的合著/评审工作。

我们构建ThinkingBox的目的是捕捉那些声称已完成但实际上未完成的代理。

ThinkingBox-Bench（我们的基准数据集）中的每个任务都会向代理提供一个真实的后端和一组工具，允许其操作，然后检查数据库中实际发生的变化。在第一篇文章中，我们发现一个模型在客户工单已解决的情况下关闭了工单，但背后的承运商异常仍然存在。九次看似专业的工具调用，却错误地修改了一行数据库记录。

随后我们意识到所构建系统的潜力。对于大多数任务，可执行检查可以直接从最终数据库状态返回1或0。这不仅仅是一个评分器，这可以作为奖励函数使用。

因此，我们从基准之外的ThinkingBox格式任务中构建了一个训练池，并使用其可执行结果作为奖励。关键在于选择适合代理训练的任务：大多数任务要么已经被解决，要么对当前模型来说毫无希望，两者都无法提供有效学习。

难度是相对于策略而言的：对于当前模型来说，只有在该模型尚未学习该任务时，该任务才是困难的。

我们将这种现象称为离线策略相对难度。我们在训练前使用基础策略估算每个任务的成功概率，并在整个训练过程中保持所选训练池固定。

训练后的变化

我们使用离线策略相对难度构建训练池，然后使用GRPO对Qwen3.8-27B进行50步微调。简要回顾，我们对507个基准任务中的每一个进行20次评估。pass@1衡量所有10,140次尝试的平均成功率。pass@20衡量至少解决一次任务的比例。20/20观察值衡量所有尝试都通过的任务比例。

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

指标

基础模型

强化学习微调

变化

20/20观察值

38 (7.50%)

→

107 (21.10%)

+69个任务

pass@1（成功尝试）

5,242 (51.70%)

6,163 (60.78%)

+9.08分

pass@20（至少解决一次的任务）

453 (89.35%)

446 (87.97%)

−7个任务

训练显著提高了可重复的成功率，但至少一次覆盖范围略有下降。文章的其余部分将解释我们如何选择练习任务、构建奖励循环并衡量这种权衡。

这个改进在单个任务中如何体现？一位旅客要求降级房间，但公司政策要求必须先获得经理批准。在训练前，代理在20次尝试中的15次更改了预订并发放退款而未获得批准。经过强化学习微调后，代理在20次尝试中都保留了预订和支付状态。

图2. 一项企业酒店预订任务，每种模型进行20次尝试。基础版Qwen3.8-27B模型在15次尝试中未经经理批准就更改了预订。经过强化学习微调的模型在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指标。观察到的20/20结果能显示哪些任务在每次尝试中都能成功，这更接近生产可靠性所需的标准。

可执行的终端状态判决也是训练奖励。在展开训练循环之前，以下是密封基准测试中发生的变化。

结果：可靠性列发生了移动

在训练Qwen3.8-27B后，我们在它从未训练过的507任务基准测试上评估了选定的step-50检查点。这507个任务代表了一个分布外测试集：它们的领域、数据库和大多数MCP工具在强化学习训练期间都未曾遇到。

表2. ThinkingBox-Bench按领域划分的pass@1（%），来自我们第一篇博客表2的选定模型和我们微调模型在不同领域及整体表现。20/20观察值覆盖整个包含507个任务的基准测试。每个模型在所有507个任务上进行20次重复试验。加粗表示列冠军；下划线表示亚军。

| 模型 | 零售 | 汽车保险 | 旅行 | 新银行 | 咨询 | 整体 | |--------------|--------|----------|--------|----------|--------|--------| | Claude Opus 5.5 | 80.97 | 68.40 | 54.28 | 71.25 | 61.58 | 67.16 | | | 241 (47.53%) | | | | | | | Claude Opus 5 | 80.71 | 65.80 | 49.95 | 70.62 | 66.19 | 66.50 | | GPT-5.4 | 76.33 | 62.65 | 68.12 | 65.34 | 54.60 | 65.36 | | | 128 (25.25%) | | | | | | | GPT-5.6 Sol | 67.65 | 65.30 | 60.34 | 59.09 | | |

57.52

61.91

82 (16.17%)

Qwen3.8-27B RLFT

67.91

56.45

62.69

62.40

54.51

60.78

Claude Sonnet 4.6

72.35

54.40

58.94

56.39

54.31

59.19

102 (20.12%)

GPT-6 Astra

71.73

46.55

55.87

60.87

56.83

58.31

231 (45.56%)

Kimi-K3

82.24

50.80

61.83

41.35

51.63

57.37

68 (13.41%)

Qwen3.8-27B

64.03

47.85

53.41

47.88

45.69

51.70

表1中的关键结果是观察到的20/20行。一个27B模型最初在每次尝试中仅完成ThinkingBox-Bench的38项（7.5%），现在每次尝试都能完成107项（21.1%），几乎是原来的三倍。相比之下，Kimi-K3的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% vs 60.78%），但在所有20次记录尝试中完成的任务更少：82 vs 107。Claude Sonnet 4.6的pass@1得分较低，为59.19%，但每次尝试完成的任务数量几乎相同，为102。单独使用任一指标都无法完整反映情况。

观察到的模式与锐化现象一致：可重复的成功率上升，而至少完成一次的覆盖率略有下降。这与先前的研究一致。一种解释是概率分布向能重复成功的轨迹移动，而一些低概率路径消失了。

总体而言，模型并未变得更广泛。它变得更可重复。下一个问题是这些增益体现在哪里。

增益所在

图3。领域级别的基础分数、RLFT分数和百分点变化。绿色变化单元格表示增益，红色单元格表示下降；蓝色阴影表示每个指标内的分数水平。

所有五个领域中的pass@1和观察到的20/20都有所提升。pass@20的结果混合：在neobank和consulting领域有所增加，但在零售、旅行和汽车保险领域有所下降。汽车保险的广度损失最大（-7.0分），而零售的观察到的20/20增益最大（+24.5分）。

可靠性成本

第一篇后续文章使用简单数学计算了一致性成本：将完整20次运行活动的预估成本除以模型每次尝试都通过的任务数量。

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

将相同的成本计算应用于微调检查点的测量令牌使用量：

表3。基础模型和RL微调Qwen3.8-27B的预估评估成本和可靠性。每个成功尝试的成本将总预估活动成本（507 × 20）除以通过尝试的数量。

指标

20次运行的活动成本

$925.80

$855.58

−7.6%

每个成功尝试的成本

$0.177

$0.139

−21.4%

20/20通过的任务数

38

107

2.8倍多

每个可靠任务的成本

$24.36

$8.00

−67.2%

以每个可靠任务$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，但GPT-5.6 Sol在成本上仍更具优势且pass@1指标略高。我们论文中涉及的四款模型价格超出图表显示范围。

美元价值是相对服务指数，不代表发票或云账单金额。使用微调检查点的服务成本与基础模型相同。该计算包含模型推理成本，但不包含训练运行和策略探针成本（用于训练数据集的整理）。

这些结果揭示了变化的原因。接下来的章节将解释训练循环以及为何选择合适任务最为关键。

训练循环

图5。六个阶段的上下文关系：候选任务输入系统，前三个阶段离线执行一次，后三个阶段在每次训练分组中重复执行。训练后的检查点将与ThinkingBox-Bench进行评估。

选择阶段仅针对基础策略模型（即本例中的Qwen3.8 27B）离线执行一次；训练则使用已整理好的固定任务池。图5中虚线琥珀色箭头标记了我们未采用的路径：在训练过程中重新评估难度。

每次训练回合都是完整的对话流程，而非文本补全。系统会分配新的后端服务、独立的MCP会话，并使用GPT-5 Chat作为模拟用户。大多数奖励来自确定性终端状态检查；少数特定评分标准会触发配置的评判者（GPT-5 Chat）。

训练和评估必须对Qwen输出进行完全一致的解析。这包括推理提取、工具调用、参数类型、渲染效果和独立任务状态。否则奖励衡量的将是与评估对象不同的智能体。共享的解析代码位于trainer/core/tb_interpret.py。

在基准测试运行中，我们使用GRPO的token-mean方法对Qwen3.8-27B进行了全参数RL微调，共处理了187个任务。每次更新生成8个回合组（共18组），即在24个H100 GPU上运行144个对话实例。训练过程同步进行，包含参数和优化器卸载；AdamW优化器使用1e-6学习率和零权重衰减。训练持续进行了50个步骤。

训练过程中采用DAPO风格替换零方差组。系统错误单独处理：后端超时不属于智能体错误，因此受影响的组会被重新填充而非标记为失败。

这解释了保留任务的训练方式。剩下的问题是哪些任务进入了训练池。

离线策略相对难度

在深入探讨训练任务选择之前，需要声明：

无任何ThinkingBox-Bench任务被纳入RL训练池。该基准仅用于评估。

ThinkingBox-Bench相对于RL训练池属于分布外数据：其领域、数据库、策略和大多数工具在RL训练过程中均未接触过。两个数据集仍共享ThinkingBox框架、模拟用户机制、可执行终端状态评分、部分通用工具和相似的任务风格。这些共有元素限制了迁移效果的宣称范围。

任务选择的重要性归结为GRPO的一个数学特性。如果八个回合全部失败，奖励向量为[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 提供了可学习的对比样本。这种区分对有状态代理来说成本很高：每次执行都需要为后端提供独立实例，运行真实工具会话，并调用单独模型来模拟用户行为。

因此，我们提出的问题不仅仅是选择哪个模型或优化器？更重要的是：哪些候选任务应该进入固定训练池？

我们通过对后验分布应用离线通过率过滤器来筛选训练池。该方法可以估计哪些任务在基准策略下可能产生对比的终端奖励。

因此我们进行了探测。每个候选任务会反复在基准策略模型上运行。其通俗规则很简单：模型总是失败的任务目前难以教学；模型总是通过的任务已经掌握；模型有时能解决的任务才是提供对比结果的关键。

从有限探测中估计难度

每个候选任务运行 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 筛选、基准模型探测、难度分类、执行组、终端状态评分和 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 x 20。

开始前准备

已在 Linux 和 WSL 上测试，使用 Python 3.12 和 uv。需要配备兼容 CUDA/NCCL 堆栈的 NVIDIA GPU、本地 Qwen3.8-27B 检查点，以及用于模拟用户和判定的 OpenAI 兼容端点。验证过的参考配置使用 3 节点 x 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 轮子替换修补过的源安装。

准备训练数据

从公开提供的示例开始，或在 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 命令：

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

该命令应在不启动 Ray 或分配 GPU 的情况下正常退出（返回码为 0）。在正式运行前，需仔细阅读生成的 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 会话代理和 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 训练检查点启动 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

完整配置文件会在聚合前验证所有10,140个预期任务/重复次数键。

后续发展方向

这项工作的核心价值不在于某个Qwen3.8-27B检查点，而在于将可执行结果转化为奖励的训练循环和训练数据筛选机制。

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

• 训练前请进行探测。使用你自己的智能体任务集，对基础策略运行n次并观察分布直方图。根据我们的经验，很多团队尚未检查过这个分布，且实际分布通常比预期更偏斜。

• 检查一致性。将相同记录的模型输出通过训练和评估解析器重新处理，验证两者是否提取出完全相同的工具名称和参数。否则训练可能奖励与评估解释不一致的行为。

• 同时报告覆盖率和可重复性。说明在k次尝试中至少通过一次的任务数量，以及全部通过k次的任务数量。偶尔能找到解决方案的模型未必能稳定重复该行为。

更多细节请参考以下链接：

• 环境：envs/thinkingbox_env

• 开发环境：ThinkingBox环境文档

• 框架：microsoft/thinkingbox · 教程

• 基准测试：microsoft/thinkingbox-data · v1.0版本

• 数据集查看器：microsoft/ThinkingBox-Bench

• 论文：arXiv:2608.19741 或 HF

• 强化学习训练：microsoft/thinkingbox-training

• 博客：智能体声称已完成，但数据库存在分歧

引用论文

@article{li2026thinkingbox,
  title   = {一次成功不代表可靠性：Thinkingbox——面向状态化业务流程智能体的沙箱与基准测试},
  author  = {李卓春和 Ko, Youngmin 和 Keramati, Ali 和 Kundu, Tuhin 和
             Tsai, Liang-Chun 和 Ferri, Nicola 和 Milletari, Mirco 和 Liu, Jiaxiang 和
             Lopez Pelaez, Susana Palmaz 和 Wang, Yuepeng 和 Smolyakov, Vadim 和
             Jiang, Xiang 和 Olafsson, Kjartan 和 Guy, Tommy},
  journal = {arXiv预印本 arXiv:2608.19741},
  year    = {2026},
  url     = {https://arxiv.org/abs/2608.19741}
}

ThinkingBox代码采用MIT许可；基准测试数据采用CDLA-Permissive-2.0许可。

免责声明：公共基准测试中的每个任务都是合成重建。工作流和策略基于真实企业智能体模式；客户并非真实存在。

ThinkingBox、ThinkingBox-Bench和ThinkingBox-Training由微软Copilot Studio团队与Toloka合作开发，合作方包括匹兹堡大学、西北大学、哥伦比亚大学和加州大学欧文分校的微软实习生。欢迎在下方评论区、GitHub或通过[email protected]邮箱提出问题。

+ 少数任务还包含数据库无法清晰捕捉的二元评分标准；这些检查可以调用配置的LLM裁判进行判断。

++ 该零梯度问题有一个标准的批量时间修复方法：过采样、丢弃退化组、重新填充。完整参数运行正是这样操作的，类似于DAPO但替换了零方差组。但重新填充仍然需要为每次浪费的rollout支付完整代价，直到将其丢弃。

## 本文提到的数据集 1

## 本文提到的论文 1

更多来自该作者的文章

## 智能体声称已完成，数据库却持不同意见

89

2026年10月3日

## 在Foundry托管计算上的Hugging Face模型

21

2026年7月7日

### 社区

编辑

预览

通过拖拽到文本输入框、粘贴或

点击此处

上传图片、音频和视频

轻点或粘贴此处上传图片

评论

· 注册或登录以评论