radixark/miles · 标签视图

将 OpenEnv 集成对 tbench2_env 环境包的最低版本要求从 #1012 提升至 #1025，以修复基础设施失败被误判为测试失败的评分漏洞。

这个 PR 是一个重要的、针对性的正确性修复。它解决了一个能悄无声息地污染训练数据的评分漏洞。变更本身风险较低，逻辑清晰，主要是版本门槛提升和文档同步。强烈建议相关维护者和使用 OpenEnv 集成的工程师精读此 PR，特别是理解从源码探测到 per-episode 守卫的双层防御机制为何必要，以及 #1025 修复的具体漏洞场景。虽然没有复杂的代码逻辑，但它展示了在 RL 训练数据流中建立可靠“合约”检查的重要性。

将 e2b SDK 声明为可选依赖并设置最低版本要求，修复与旧版 SDK 的兼容性问题。

该 PR 值得精读。它是一个高质量的 bugfix 与增强性变更，不仅解决了具体问题，还引入了可复用的依赖版本检查模式。关键设计决策在于 `preflight_sdk` 函数的演进（增加 `min_version` 参数）和对缺失包元数据的优雅降级处理，以及配套的全面测试。对于维护类似沙盒后端集成的工程师尤其具有参考价值。

在 TB2 环境构建配方中锁定 mcp<2，修复因 mcp 2.0 破坏性变更导致的 Camel-AI 导入失败。

这是一个**值得精读但逻辑简单的** bugfix PR。其价值不在于复杂的代码变更，而在于清晰展示了对外部依赖破坏性变更的快速响应和修复模式（在构建层通过版本约束进行缓冲）。对于维护依赖复杂生态系统的工程师来说，此 PR 中详细的注释和提交说明是很好的实践范例。建议关注点在于其对依赖管理的处理方式，以及如何通过注释和配方变更来隔离上游破坏性变更的影响。

修复 GB300 16 节点 tbench2 训练崩溃，折叠三个关键配置杠杆

值得精读。这是「用一次 16 节点 smoke run 的逐 token 取证驱动配置和运行期行为修复」的典型范例：PR body 中关于 `--tis-clip-low` 反向后果、SDK 非幂等重试导致 zombie decode 的量化分析（~1000 引擎侧请求 vs 128 活跃样本）尤其值得关注。建议重点阅读三个设计决策：①TIS clip 下限回归默认值的理由（不要为了"梯度稳定"而违背 importance sampling 语义）；②`max_retries=0` 与 `timeout=3600` 的配对逻辑（生成请求不幂等，重试代价高于超时等待）；③`finish_reason == "length"` 终结 episode 的边界语义。同时建议跟进 #2591 与 `--max-weight-staleness` 的后续修复，它们与本 PR 构成完整的崩溃治理链路。

截断轮次立即结束 episode，消除 22.7% 无效生成时间

值得精读。代码量极小（核心仅 3 行），但问题定位方法极具参考价值：用实测数据（6469 episodes、144.7h/638h、单样本 73% 时间被丢弃）量化不可见浪费，通过 dashboard 渲染盲区反推根因，再以训练端丢弃边界校准 rollout 端生成边界。设计上"截断即停止、但保留评分"的取舍清晰、与训练契约严格对齐，是实现最小修复的范例。

15 个示例测试迁入 tests/fast 纳入 CI，并用守卫测试杜绝孤儿测试

值得精读，尤其是 `tests/ci/test/test_ci_discovery_coverage.py` 的三个守卫设计和 `git ls-files` 替代文件系统遍历的决策——这是“用测试约束测试放置”的治理范式，比一次性迁移更有长期价值。值得关注的决策点：①“无法运行的测试应自我声明 skip 而不是隐形缺席”的原则；②`_KNOWN_ORPHANS` 设计为只收缩，条目随文件迁移自动过期，避免豁免永久化；③`test_the_example_suites_reach_the_cpu_plan` 直接调用 `collect_tests(discover_ci_files())` 校验真实计划，而不是断言文件存在这种弱检查。对 CI 治理、测试编排感兴趣的读者可重点参考其结构。

Daytona 客户端进程级复用，修复 fd 泄漏致训练停止

值得精读。这是一个教科书式的 '连接池/客户端复用' 资源泄漏修复：有完整的现场数据（fd 时间线、SSLEOFError 频率）、清晰的根因链（无 close + 闭包持有 + 重试放大）和有效的验证方法（16 节点复跑、fd 收敛曲线）。值得关注的设计决策包括：用 `threading.Lock` + 模块级单例做进程级复用并保留延迟导入、测试中用假模块替换 `sys.modules` 以纯单元方式验证单例语义。对团队而言，可借此建立一条 code review 检查项：凡是 SDK 持有连接池且无 close() 时，禁止在每次调用/重试中新建客户端。

Daytona 配方改用 --fully-async 以启用参数互斥校验

值得快速浏览，特别是对全异步 rollout 参数互斥设计感兴趣的读者，可对照 miles/utils/arguments.py 中 _resolve_rollout_functions 理解校验意图。长期建议为该配方补充一条启动脚本快照测试或文档说明，避免再次出现绕过校验的写法。