Question 1

为什么即使 ExUnit 报告 0 个失败，SWE-rebench 仍会将通过测试的 Elixir oracle 评为 0 分？

Accepted Answer

已归档的 `parse_log_elixir` 解析器期望日志行以 `test name (...)` 开头，但 ExUnit 输出的行形如 `* test handles arbitrary properties (0.1ms) [L#528]`。由于行首存在 `*`，解析器对具名测试状态返回 `{}`，导致 `FAIL_TO_PASS` 查找失败，oracle 得分为 0。

修复方法是在归档解析器运行之前对 ExUnit 的星号标记进行规范化，例如在 `experiments/post_training/task_curation/datasets/tasktrove/swe_rebench.py` 中：

```python
import re

def normalize_exunit_line(line: str) -> str:
    return re.sub(r"^\s*\*\s+", "", line)
```

在调用 `parse_log_elixir` 之前对每一行日志应用此处理。上述示例将变为 `test handles arbitrary properties (0.1ms) [L#528]`，从而能够检测到具名的通过和失败记录。重新生成或重建 verifier，然后重新运行 `test_state.py::test_patch_resolved`；通过的 oracle 应得分为 1。为通过和失败两种 ExUnit trace 都添加回归测试。该修复已在 PR #10008 中实现。

Question 2

如何修复 MarinSkyRL 的 uv lock 失败错误 "No solution found ... marin-rigging[secrets]>=0.2.123.dev35633925924"？

Accepted Answer

失败的原因是 uv 从固定的 Marin Git 工作区中选择了 `marin-rigging` 0.2.0，尽管 PyPI 上存在兼容的版本。通过在 `config/external/MarinSkyRL/pyproject.toml` 中添加覆盖配置，强制 uv 使用已发布的软件包：

```toml
[tool.uv]
override-dependencies = ["marin-rigging[secrets]>=0.2.139.dev37117265303"]
```

使用固定的 MarinSkyRL/TaskCompendium 修订版所要求的更高版本下限；最初报告的 MarinSkyRL 下限为 `>=0.2.123.dev35633925924`。然后重新运行：

```bash
uv lock --project config/external/MarinSkyRL --upgrade-package marinskyrl
```

使用 `uv lock -v` 验证 `marin-rigging` 是从 PyPI 而非 Marin Git 工作区解析的。在测试中，所报告的修订版通过已发布的 rigging 版本解析了 198 个软件包。此修复已在 PR #9931 中实现。

Question 3

为什么正确的 ARC AGI 和 ReArc 答案在 reasoning-gym 0.1.25 中经过 JSON 传输后得分为 0.05 而不是 1.0？

Accepted Answer

发生这种情况的原因是：`parse_board` 将网格表示为元组，而 `json.loads()` 会将 `metadata['output']` 还原为列表。`arc_agi` 和 `rearc` 评分器会直接比较这些结构，因此一个本来正确的网格只会得到部分分数 `0.05`。

修复方法：在调用 `score_answer()` 之前，将 JSON 解码后的 gold 网格规范化为元组：

```python
metadata = entry["metadata"]
metadata["output"] = tuple(
    tuple(row) for row in metadata["output"]
)
```

例如：

```python
entry = json.loads(json.dumps(entry))
entry["metadata"]["output"] = tuple(
    tuple(row) for row in entry["metadata"]["output"]
)

answer = format_board(entry["metadata"]["output"], dataset.board_format_opts)
print(dataset.score_answer(answer, entry))  # 1.0
```

在 Verifyit 的 JSON 加载/评分边界处，对 `arc_agi` 和 `rearc` 都应用此规范化。修复后，正确的网格得分为 `1.0`，错误的网格得分为 `0.05`，格式错误的答案得分为 `0.0`。随后即可移除 TaskTrove ARC 排除项，但之前已暂存的行必须单独重新转换后才能被纳入。

Question 4

如何修复运行 Iris 原生代理测试时 `verified_identity` 中缺少 `job_id` 的问题?

Accepted Answer

该故障由锁定的 `marin-iris-native==0.1.6.dev31131847556` wheel 引起,该 wheel 不包含 native proxy 的 task-identity 更改。请按照 PR #9994/#10002 中的做法,将 native wheel 更新并锁定为 `marin-iris-native==0.1.11.dev37977873285` 或更高版本。更新 `lib/iris/pyproject.toml` 中的依赖项,刷新 lockfile(例如使用 `uv lock`),然后使用 `uv sync` 重新安装并重新运行:

`uv run pytest lib/iris/tests/cluster/controller/test_native_proxy.py -k test_native_listener_stamps_controller_identity_and_strips_caller_credentials`

更新后的 wheel 应在解码后的 `verified_identity` 中包含 `{'job_id': '/alice/train'}`。

Question 5

如何修复 macOS 上由仅支持 Linux 的 bubblewrap_bin 依赖导致的 rolloutengine ImportError？

Accepted Answer

将 RolloutEngine 升级到包含 PR #9980 的版本。该修复移除了 `lowering.py` 和 `machines.py` 中对 `shellbox.backends.local.machine`（以及本地 TaskCompendium 运行时）的立即导入，改为仅在 lock-only 评分路径内部进行导入。它还将 `isinstance(factory, LocalMachineFactory)` 检查替换为 `factory.backend == Backend.LOCAL`，从而支持委托式工厂包装器。

如果你要自己修补代码：
1. 移除顶层的本地后端导入。
2. 在 `_acquire_machine` 和 `validate_lowered_task` 内部惰性导入本地后端，且仅在选择 lock-only 路径时才导入。
3. 对 `bubblewrap_bin` 的导入加以保护，使 macOS 能够导入该包；仅当 lock-only 评分器确实需要本地后端时，才抛出明确的平台错误。
4. 基于 `factory.backend == Backend.LOCAL` 进行分发，而不是基于具体类。

然后更新/重新安装该包并重新运行测试，例如：
```bash
git pull
pip install -e lib/rolloutengine
pytest
```
升级前的临时解决方案：在 Linux 容器中运行测试或类型检查。

marin

项目简介

README 预览

常见问题 (5)

同类型项目

tensorflow

superpowers

everything-claude-code

flutter