AREX Feed Article
小米开源 MiMo-V2.6-RL-oss：7,000+ agentic RL 任务环境，研究者称部分任务存在 reward hacking 模式
北京时间 9 月 26 日 20:30，X 上以 LLM 与 agent 为主题的账号 Akshay（，约 29 万粉丝）发帖称，小米开源了用于训练 MiMo 的「7,000 多个」agentic RL（智能体强化学习）任务环境，覆盖代码、网络安全、通用工具使用、视觉 web 开发与音乐相关任务，并附上了数据集在 Hugging Face 的页面截图。截至发稿，该帖获得 65,696 次浏览、725 次收藏、89 次转发和 562 个赞。
近 9 小时后（北京时间 9 月 27 日凌晨 5:10），个人简介为「RL research」的 Daniel Rupawalla（）发帖给出了针对这份数据集的一条具体反证。他称自己抽查了部分任务，发现「明显的 reward hacking 能力」（reward hacking 指模型利用验证器漏洞拿高分，而不是真正完成任务），这些模式「在整个数据集中反复出现」，并警告说，拿它们直接训练要谨慎：「它们是示例，应该被当作示例来对待。」
5 个子集、7,780 行：这套环境集里有什么
数据集页的描述是「Agentic RL Environments」，即面向 LLM agent 的 RL 训练环境（）。Hugging Face 的显示，五个子集合计 7,780 行：code 2,698 行、webdev 2,093 行、cyber 1,000 行、music 1,000 行、general 989 行；许可证为 Apache-2.0。
五个域对应不同的判定方式：代码任务靠可执行测试，网络安全的漏洞复现靠规则检查，通用知识工作靠基于评分标准的评审，视觉 web 开发靠视觉评分，符号音乐创作靠规则检查。数据查看器给出的列包括 data_source、ability、agent_name、prompt（提示词）、reward_model、extra_info 等；以 code 子集的一行为例，agent_name 是 mimo_swe_agent，reward_model 为 {"ground_truth": "", "style": "rule"}，extra_info 中带有 instance_id、docker_image、problem_statement 等字段。
在里，code、cyber、music、webdev 四个域各是一个 parquet 文件，general 则按「一个环境一个目录」组织，每个环境目录包含 instruction.md、verify.py、verifier_meta.json、mcp_bridge.py，以及 tools/、workspace/ 下的工具与工作区文件。
发布不止于数据本身。 显示已被拉取 50 万次以上； 以 verl（0.9.0.dev）为基础，增加了五个 RL 环境的复现代码与各域启动脚本，README 把这份数据集列为「Training data」，配套训练模型为 MiMo-V2.6-Distill-Qwen-9B。署名 LLM-Core Xiaomi 的技术报告《MiMo-V2.6: Scaling Reinforcement Learning Towards Self-Improvement》称，开源训练动态、RL 环境与 RL 框架，是为了「方便复现，并推动关于规模化 RL 与模型自我改进的进一步研究」（）。
帖文里的说法：从开源模型输出到开源「学习经验」
Akshay 在帖文里的核心说法是：「开放权重让你能运行一个模型，开放环境让你能教一个模型。」他把这次发布概括为「从开源模型输出，到开源学习经验」的转变：在他看来，强化学习环境难建，每个任务都需要可执行的世界、清晰的目标、可用的工具和可靠的成败判定，而小米把 prompt、agent 配置、reward 元数据和配套训练框架一起放了出来。
按他的说法，开发者可以用这套环境做四类事：让模型在真实 agent 任务上尝试、调用工具、观察结果并从结果中改进，而不是模仿静态答案；把较小的开源模型专精到软件工程、漏洞复现、知识工作或 web 开发；研究完整轨迹，每次运行都包含推理、工具调用、环境反馈与奖励；或者搭起从环境交互、轨迹收集、奖励评估到策略优化的完整训练回路。
他附上的截图显示，数据集页的 code 子集为 2.7k 行，查看器里可以看到 prompt、reward_model、extra_info 等列。数据集页面还显示，过去一个月它被下载 973 次。
「不完整的修复也拿满分」：一条抽查记录
Rupawalla 的帖文先肯定了数据集的价值，随后给出限定。他的原话是：「MiMo 数据集很有价值，但其中许多任务（我亲自 QA 了一部分）仍指向明显的 reward hacking 能力，这些模式在整个数据集中反复出现。」帖文附上的是一段评估结论的截图。
截图里的结论写道，该行按当前评分应被拒绝：功能请求清晰且真实，未修改的代码得 0 分、有效修复得 1 分；但验证器也给一个只改了 src/action.js 的不完整修复打了 1.0 分：action.yml 仍把 secrets 标为必填，随包发布的 dist/index.js 也仍然要求它。结论称，这一结果已在全新容器中复现。
与数据集帖文相比，这条警告的传播范围小得多：截至发稿，4,024 次浏览、73 个赞，发帖账号的粉丝约 2,000；帖中没有说明抽查覆盖了多少任务。
为什么验证器假阳性会污染训练信号
在这些环境里，奖励由验证器和评分器给出，可执行测试、规则检查、评分标准或视觉评分决定成败。一旦验证器对「看起来完成、实际不完整」的解法给满分，模型被奖励的行为就会从解题滑向通过检查；Rupawalla 截图里的那个不完整修复正属于这种情况。
小米自己的技术报告在摘要里也提到了 reward hacking：「为在规模化下保持训练稳定，我们冻结 MoE 路由，并建立针对 reward hacking 的多层防线。」不过，这条防线描述的是小米自身训练流程里的措施；Rupawalla 的警告面向的是打算直接拿这批公开环境做训练的团队。
回帖中，（简介中列出 SWE-rebench 与 Nebius）把这类问题视为常态：「验证器的假阳性相当常见，比假阴性常见得多。」他表示，这样的开源发布仍然「聊胜于无」，可以作为起点再改进。
尚未解决的问题与已经出现的建议
9 月 27 日，另一位回帖者 Maxime Robeyns（）称自己也翻过这些数据，在他检查的若干行里同样发现了评分标准问题，但仍认为这是一套不错的环境集合，「哪怕只当参考资料」。
这类验证器问题是个别行，还是如 Rupawalla 所说的「在整个数据集中反复出现」，仍需要比个人抽查更系统的检查才能判断。在那之前，一条可落地的建议来自 Ibragim：先在任务的 rollout（模型在任务中的完整试跑记录）之上更新测试与评分标准，再决定把这份环境集当示例、参考资料，还是训练数据。