[two-tiger]

背景

infra/config.json 之前按厂商命名、且是一层平铺：kimi（慢模型凭据）与
jev_endpoint / kev_endpoint / jev_endpoint_file / kev_endpoint_file（排序服务地址）
四键并排，基准路径、rjob、registry、落盘目录混在同一层，还有 _comment 字段当注释用。

三个后果：

1. 配置难读——段与段之间没有边界，说明性字段混在真配置里；
2. 一个文件只能描述一套大脑 + 一套小脑——想比较"不同大脑 × 不同小脑"，
   得为每个组合改配置结构；
3. 换厂商要动代码——SessionConfig 里是 kimi_* / jev_timeout_seconds /
   selector_backend，报错文案也钉死厂商（"Kimi response is missing required fields"
   在大脑已经换成 MiniMax 时照旧出现）。

本 PR 把配置改成按角色组织、模型做成命名 API 登记表，并把已合入的
OSWorld 2.1 子集（#2）按新 schema 重接进来。

改了什么

1. 配置三段结构：harness / eval / log

{
  "harness": {
    "slow_model": {                        // 大脑：规划 / 验证 / 需求抽取
      "default": "minimax-m3.1-flash",
      "apis": {                            // 命名 API 登记表
        "minimax-m3.1-flash": { "base_url": "https://api.minimaxi.com/v1",
                                "api_key": "sk-…", "model": "MiniMax-M3.1-Flash",
                                "max_tokens": 16384, "timeout_seconds": 180,
                                "reasoning_effort": "low", "direct_api": false },
        "kimi-k3": { … }
      }
    },
    "fast_model": {                        // 小脑：候选动作空间里排序
      "default": "jev",
      "apis": {
        "jev": { "backend": "jev", "endpoint": "",
                 "endpoint_file": "…/services/qwen_jev.json", "timeout_seconds": 300 },
        "kev": { "backend": "kev", "endpoint": "",
                 "endpoint_file": "…/services/kev.json", "timeout_seconds": 300 }
      },
      "image_stage": { "write": "…", "read": "…" }
    },
    "route":  { "policy": "auto", "allow_cli": true, "cli_timeout_seconds": 90 },
    "budget": { "max_steps": 30, "max_wall_seconds": 1800 }
  },
  "eval": { "repo_root", "deploy_root", "mounts", "rjob", "inner_image",
            "shared_env", "benchmarks": { "osworld1", "osworld2", "osworld21" },
            "registry" },
  "log":  { "results_root", "record": { "a11y_full": false } }
}

• _comment 等说明字段全删（说明属于文档，不属于配置）；
• 厂商名（kimi / jev / kev）退到条目内部成为字段值；
• 慢模型与快模型都是登记表：启动命令用 --slow-model <名字> / --fast-model <名字>
  按名字挑（缺省取各自的 default），名字写错时错误信息列出全部可选名。
  仍守"唯一配置文件"：登记表在同一个文件里，切换靠命令行——没有环境档案、
  没有占位符展开、没有第二份 config；
• 预算从 rjob_spec 硬编码（15/900）收进 harness.budget（30/1800，与批量脚本
  实际用值一致），命令行仍只覆盖单项；
• 新增开发机侧模块 src/tandem_eval/config_schema.py：schema 校验 + 按名字选 API
  （rjob.py 不再背着 schema 知识；worker 侧仍是 6 文件封顶）。

2. 角色化贯穿到 harness 内部

旧	新
SessionConfig.kimi_max_tokens / kimi_reasoning_effort / kimi_timeout_seconds / kimi_direct_api	slow_*
SessionConfig.jev_timeout_seconds	fast_timeout_seconds
SessionConfig.selector_backend	fast_backend
KimiClient	SlowModelClient
CLI --selector jev|kev	--fast-model <名字>
CLI --kimi-max-tokens / --kimi-reasoning	--slow-max-tokens / --slow-reasoning

文案同步中性化："JEV health check failed" → "fast model health check failed"、
"Kev 响应缺少 …" → "fast model 响应缺少 …"、事件名
jev_service_recovery_wait → fast_model_service_recovery_wait、
score_type jev_omni_choice_softmax → fast_model_choice_softmax。

保留的厂商标识：后端 id jev / kev 与其实现类（JevOmniPolicy / KevPolicy）
——它们指的是两套排序协议（就像 "openai" 指一个 provider）；harness 说话用角色，
协议归协议。

3. OSWorld 2.1 子集接入（#2 的内容按新 schema 重接）

eval.benchmarks.osworld21.{root,vm,asset_root,shared_env,proxy,volume_size,inner_image}；
56 题子集（manifest.OSWORLD21_TASK_IDS）；worker 侧独立 env.sh、只查 Pillow、
不打 latest 标签、发布清单固定的 digest 镜像。

过程中修掉两个会让 run 直接死掉的问题：

• 挂载：平台拒绝同一 gpfs source 挂两次（the value of source path repeats），
  而 OSW2.1 的 env.sh 与 prepared/runtime 软链层写的是 canonical 路径
  /mnt/shared-storage-gpfs2/... → evobox 卷只能挂一次、且必须挂 canonical；
  配置里所有 evobox 路径随之统一（旧环境的 env.sh 是自相对的，两种视角都行）。
• 凭据：osworld21 漏在 secrets 白名单外 → spec 的 secrets 是空字典 →
  worker 没有 registry 凭据，拉不了 inner 镜像就退（缺少 registry 凭据）。
  现已补上，并加回归测试：每个真实基准的 spec 都必须带 slow_model / fast_model / registry。

4. verifier 容忍 answer 的形状

这次换脑才暴露：verifier 要求 evidence 是字符串，MiniMax 给的是列表
（偶尔字典）→ 三次重试都过不了校验 → 整题 ValueError。
现在校验器接受 str/list/dict，返回后统一压成文本（下游 control_state_check 要拼字符串）。
答案长什么样不该决定一次 run 成不成——大脑是可换的。

5. 异常题记下原因

episode.json 原来只有 exception_type，事后无法判断炸在哪一步
（一次 run 里 RuntimeError 与 ValueError 无法区分）。现在补 error（脱敏截断的消息）
与 error_traceback（栈尾几行），结果目录契约同步这两个可选字段，demo 在失败原因旁
直接显示消息。

破坏性变更

• CLI 移除 --selector / --kimi-max-tokens / --kimi-reasoning（无兼容别名）；
• SessionConfig 字段改名；providers.KimiClient → providers.SlowModelClient；
• infra/config.json（含密钥，gitignored）必须按新结构重建——本 PR 只提交模板
  infra/config.example.json；
• demo run 文档键：selector_backend → fast_model（并新增 slow_model），
  jev_calls → fast_calls。

验证

项	结果
ruff check src tests demo	All checks passed
pytest	245 passed
tandem check	协议自检 16 样例通过（protocol_version 未变，仍 0.1）
真机 smoke	OSW2.1 单题（--benchmark osworld21 --tasks 004）：镜像拉取✓、依赖自检✓、任务加载✓、慢模型调用✓、环境链路通
真机批量	OSW2 shard 1/5（4 题）：2 题跑完 0 分、2 题异常（原因见下）

协议未改：src/tandem/protocol/ 一行未动（只有结果目录契约文档扩展了两个可选字段）。

已知问题（如实披露，均非本 PR 引入）

• task_001 撞 Thunderbird 登录页：官方设计是 setup 预置 profile 快照、账号本就该就绪
  （task_001.py 的 setup 直接下载 THUNDERBIRD_PROFILE_URL 的 tar.gz），
  agent 却在点 "Other ways to sign in" → 属环境侧 snapshot/账号态问题；
• task_016 抓任务即 ValueError：发生在任务模块 import 期，当时结果目录不记异常消息，
  无法定位；本 PR 的 error / error_traceback 正是为此；
• RETURN_TO_PLANNER 空转（no_action_limit）：小脑在候选里没有明确目标项时偏向选全局
  逃生项 → 只规划不动手。护栏按维护者指示本次不做。

评审建议

• 先看 infra/config.example.json 与 src/tandem_eval/config_schema.py（新的配置契约）；
• 再看 src/tandem_eval/rjob_spec.py（spec 的组装与角色拆分）；
• 命名中性化与 verifier 形状容忍在 cda10e7，改动局部、易扫。