Bench 调研报告

MLS-Bench · EdgeBench · ARC-AGI-3 · nanoGPT —— 为 OPHIS observable 闭环挑选验证平台
作者: Shaoyang Guo 2026-08-13 协作文档 · Google Docs
阅读须知：本文档中 "observable" / "causal" / "闭环" 等概念是 OPHIS 自己的分析框架，并非各 bench 论文原文提出的术语。 各 bench 论文原文没有提出这些概念；本文用 OPHIS 的视角去分析这些 bench 如何承载闭环。 各节的"为何适合 OPHIS"、"契合点" 是本文作者的解读，不是论文主张，请勿误引。
目录
  1. 调研总览
  2. MLS-Bench：让 agent 发明可泛化、可扩展的 ML 方法
  3. EdgeBench：真实环境中的长期学习（含 LIGO 引力波 + 51 开源任务例题）
  4. ARC-AGI-3：第一个交互式推理基准
  5. nanoGPT：作为 OPHIS 的可控 example
  6. Observable 闭环：每个 bench 怎么做 + 缺陷分析
  7. 下一步行动建议
  8. 参考链接
  9. 子报告（OPHIS-baiyu 实验记录）

01 调研总览

Bench本质任务数单任务时长关键评估与 OPHIS 契合点
（OPHIS 解读）
MLS-Bench 发明可泛化可扩展的 ML 方法（非调参） 140（12 领域）
Lite 30		 ~1 天 (H100) 归一化分数 vs 人类 SOTA 每任务 = 可控组件改进实验
EdgeBench 真实环境长期学习（12h+ 连续交互） 134（6 大类）
开源 51		 12–72 小时 学习曲线 log-sigmoid 拟合 LIGO 引力波任务（完整集）；51 开源任务；多级反馈
ARC-AGI-3 交互式推理：隐藏环境探索、目标推断、规划 135 游戏（多关卡） 短交互 turn-based 效率加权分数（人类 100%，SOTA AI <6%） 每步 frame+元数据 = observable 流
nanoGPT 经典 LLM 训练（语言建模） 1（可细分干预维度） 数小时–数天 val loss / gap 已有 gap 研究基础，最可控 example
核心闭环（来自协作文档） —— 每个 bench 都应能承载这个循环：
Observe观察训练
→
Diagnose诊断
→
Intervene选择干预
→
Rerun重跑
→
Observe再观察

02 MLS-Bench：让 agent 发明可泛化、可扩展的 ML 方法

一句话定义：MLS-Bench（ML Science Bench） 评估 AI 系统能否 发明 可泛化且可扩展的机器学习方法，而不是只会应用已有方法或调参。

为什么需要它

规模与结构

140 个任务，12 个领域：

Language Models · 18 Robotics · 12 Vision & Generation · 11 Reinforcement Learning · 13 ML Systems · 10 AI for Science · 10 Optimization & Theory · 13 Classical & Adaptive · 14 Deep Learning · 11 Time Series · 10 Structured & Causal · 10 Trustworthy · 8

任务结构（每任务 5 要素）

要素说明
(i) 研究问题描述研究问题、背景和目标（可执行形式）
(ii) 代码库 + 可编辑范围限制 agent 能改哪些区域，防止改评估器/训练协议/加容量作弊
(iii) ≥3 个强人类基线含社区认可的 SOTA 方法（可复现）
(iv) ≥3 个评估 setting跨 benchmark、环境或 base-model 规模验证泛化
(v) 种子策略多 seed 运行，保证非偶然

具体任务示例（带可视化）

任务目标评估为何适合 OPHIS
LLM 量化感知训练
llm-qat-algorithm		 改进量化感知训练算法，量化 LLM 保持精度、降开销 跨模型规模 + 数据集，量化后 loss/perplexity 是否接近全精度 丰富的 observable（量化误差、梯度噪声、激活分布、loss 曲线）→ 诊断量化引入的 loss 来源再干预
注意力缓存结构压缩
llm-kv-structural-reduction		 发明 KV cache 的结构性压缩方法 长上下文：压缩率 vs 质量保持 需观察 cache 中 token 信息冗余（attention 分布、head 贡献）再设计干预
3D 场景致密化策略
cv-3dgs-densification		 改进 3D Gaussian Splatting 的 densification 策略 重建质量 (PSNR) vs 渲染效率，跨场景 重建误差的空间分布 = 可观察信号
扩散先验逆问题求解器
ai4sci-inverse-diffusion-algo		 用扩散模型作先验求解逆问题（超分辨、去模糊） 重建质量，跨多个逆问题类型 与 LIGO 引力波重建同族（逆问题）
同质-异质图滤波器
graph-signal-propagation		 发明在同质/异质图上都工作的图滤波器 跨多个图数据集 + 同质度 信号传播路径 = 可观察的中间状态
梯度压缩
optimization-gradient-compression		 改进分布式训练的梯度压缩 通信开销 vs 收敛质量 梯度统计 = 直接 observable

任务接口细节（raw，来自任务页原文）

以下内容直接取自 mls-bench.com 任务页，展示 agent 实际面对的可编辑接口 —— 这是理解"observable 从哪来"的关键。

示例 A：llm-qat-algorithm —— 可编辑文件 custom_qat.py

研究问题：设计一个 QAT 算法，最小化全精度 Pythia-1.4B 与 INT4/INT3/INT2 量化后模型的 perplexity gap。必须是训练侧贡献（fake-quant forward、梯度流、可学习参数、优化器调度），且需在 4/3/2-bit 统一有效。

可编辑范围：只能编辑 # EDITABLE REGION START / END 块内的：

  • CONFIG_OVERRIDES dict：learning_rate / num_steps / batch_size / gradient_accumulation_steps / max_grad_norm / warmup_steps / weight_decay
  • fake_quantize_weight(weight, num_bits, group_size)：可微 fake-quant，梯度须回流到原 weight
  • fake_quantize_activation(x, num_bits)：可选（默认 identity，weight-only）
  • quantize_dequantize_weight(weight, num_bits, group_size)：no-grad 真实 QDQ，训练后物化整数模型用于评估
  • class QATWrapper(nn.Module)：包装 nn.Linear，forward 里做 fake quant；可持额外可学习参数（LSQ per-group scales、StableQAT EMA buffers）；可暴露 aux_loss(step, total_steps)
  • prepare_qat_model(model, num_bits, group_size)：把每个 nn.Linear（及 HF GPT-2 Conv1D）替换为 QATWrapper；必须把 LM head 恢复为 plain Linear（全精度）

固定（不可编辑）部分：模型加载（Pythia-1.4B FP32 + 梯度检查点）、WikiText-2 数据采样（block-1024 随机裁剪）、QAT 训练循环（AdamW、cosine LR + warmup、grad-accum、grad-norm clip）、训练后 real-quantization roundtrip、WikiText-2 test perplexity 评估。

评估：三个 bit-width —— qat-1b-int4（易）/ qat-1b-int3（中，8 级）/ qat-1b-int2（极难，4 级）。主指标 wikitext2_ppl（越低越好），次指标 degradation = ppl - fp16_ppl。

关键对照基线：finetune_then_ptq（先全精度 finetune 再 RTN 量化）—— 隔离 finetune 信号与 QAT 信号。一个有效的 QAT 方法必须击败它，否则其收益只是 in-domain finetune 的功劳。

示例 B：ai4sci-inverse-diffusion-algo —— 可编辑文件 algo/custom.py

研究问题：用预训练扩散先验 p(x) 解逆问题。给定前向算子 A 和观测 y = A(x) + noise，从后验 p(x|y) ∝ p(y|x)p(x) 采样重建 x。

可编辑范围：整个 algo/custom.py，需实现 Custom 类：

  • __init__：scheduler、optimizer、超参
  • inference(observation, num_samples)：给定观测 y，返回重建 x

可用组件（固定）：

  • self.net(x, sigma) → denoised estimate（Tweedie's formula: E[x₀|x_t]）
  • self.forward_op.forward(x) → A(x)
  • self.forward_op.gradient(x, y, return_loss=True) → (∇ₓ‖A(x)−y‖², loss)
  • self.forward_op.loss(x, y) → ‖A(x)−y‖²
  • Scheduler(num_steps, schedule, timestep, scaling) → 扩散噪声调度
  • DiffusionSampler(scheduler).sample(model, x_start) → 无条件采样

评估：三个科学逆问题 —— Inverse Scattering（光学断层，PSNR/SSIM）、Black Hole Imaging（EHT 稀疏干涉观测重建黑洞图像，PSNR/blur-PSNR/closure-phase χ²）、FFHQ256 Inpainting（box mask + σ=0.05 高斯噪声，PSNR/SSIM/LPIPS）。

任务 5 要素（结构复述）

Agent 预算设计（当前官方值）

官方默认预算（configs/react.yaml + 论文 4.1）：

  • max_steps = 20（action 上限，整个任务）；Lite 扩展模型 8 actions
  • max_tests = 3（test 调用上限）；Lite 扩展模型 1 test
  • 5 小时探索预算/任务（timeout_sec=18000，Harbor 渲染路径）
  • thinking budget = 10,000 tokens/次调用（Anthropic extended thinking 的每请求参数，非全程累计）
  • web search 默认关闭

关键理解：

  • 10k thinking tokens 是「每次 LLM 调用」的限制，不是整个任务 —— 20 个 action 全程可用 ~200k thinking tokens。
  • 1 个 action ≈ 1 次 LLM 调用 + 1 个工具操作（edit/test/submit/undo）。
  • 官方 20 actions / 3 tests 是刻意的公平基准，非技术上限 —— 论文 Test-Time Scaling（5.1）证明：更多 compute/action 在简单任务上收益很快饱和，复杂任务上突破不了 Human SOTA。
  • Verifier-Limited 实验（5.2）把预算放宽到 50 actions / 20 tests，性能反而普遍下降 —— 更多探索不一定更好。
OPHIS 角度：我们后面会增加预算（增大 max_steps/max_tests）。这不会破坏官方可比性（我们本来就不是复现 leaderboard），而是为了：① 给 agent 足够的科学判断空间；② 对比「固定预算下 observables 增强」vs「单纯加预算」哪个更有效（对应 Claim 2/3）。

如何实际运行 MLS-Bench agent（两条路径）

路径 A：Native runner（论文主实验用，自带 ReAct agent）

  • 安装：pip install -e ".[agent]"（Python 3.10+）
  • 配置 configs/react.yaml：填 provider API key（openai/anthropic/deepseek/qwen/gemini/kimi/glm 均可），设 container_runtime: docker|apptainer|local
  • 拉取并构建任务包： 
    mlsbench fetch --name <package>
mlsbench build <package> --config configs/react.yaml
  • 跑 agent（自带非交互 ReAct 循环，不会停下来问用户）： 
    mlsbench agent <task> --model <model> --config configs/react.yaml
mlsbench score task <task>
  • 预算可改：configs/react.yaml 里的 max_steps / max_tests（默认 20/3）
  • agent 类型：InteractiveAgent（ReAct）、OpenEvolveAgent（population 进化搜索）、DiscoverAgent（TTT-Discover）

路径 B：Harbor 数据集（官方 leaderboard 用，兼容任意 agent）

  • 140 任务预渲染成 Harbor 格式，任何 Harbor 支持 agent（claude-code / codex / openhands / terminus-2 / kimi-code 等）都能跑：
  • PYTHONPATH=. harbor run -c run.yaml -a claude-code -m anthropic/claude-opus-4-7
  • 每个任务内置 timeout_sec=18000（5h 探索预算）+ task-specific verifier timeout
  • 官方 leaderboard 全部在 Harbor + 5h 预算下产生 —— 要可比性必须走这条路
  • 注意：Claude Code / Codex 这类交互式 agent 默认会在模糊处停下来问用户；要无人值守需加 --dangerously-skip-permissions 等非交互 flag，或改用自带 native agent
OPHIS 运行建议：我们要做 observables 增强 + 自定义预算，建议走 Native runner 并改造 agent（工具可扩展：在 edit/test/submit/undo 之外加观测工具）；不用 Harbor（它面向现成交互 agent，且不支持自定义预算的可比性保证）。

各任务单次 test 的 compute / 时间消耗（实测 config 值）

以下来自每个任务 config.json 的 test_cmds：compute = 占几张 GPU（<1 表示 CPU/低配可跑），time = 单次 test 上限。hidden=true 表示隐藏 setting（agent 看不到，用于泛化验证）。

超轻量（CPU/低配，compute ≤ 0.33）—— 最适合常驻 8×H100 持续跑

任务可编辑文件每 test 时长compute说明
ml-clustering-algorithmcustom_clustering.py10–15 分钟0.25blobs/moons/digits，纯 sklearn，最快迭代
optimization-multi-objective自定义 ES 算法60 分钟0.25zdt1/zdt3/dtlz2，进化策略
causal-discovery-discretecustom_algorithm.py59 分钟0.25Cancer/Child/Alarm，契合 OPHIS 因果主题
optimization-variance-reduction方差缩减59 分钟0.33logistic/mlp
ts-exogenous-forecast外生变量预测59 分钟0.33ETTh1/Weather
ts-imputation插补模型2 小时0.33ETTh1/Weather/ECL
graph-generation图生成器59 分钟0.33community/ego/enzymes
ai4bio-mutation-effect-predictioncustom_mutation_pred.py59 分钟0.33ProteinGym 突变预测

轻量 GPU 任务（1 张 H100，compute = 1.0）

任务可编辑文件每 test 时长compute说明
llm-ptq-algorithmcustom_ptq.py19 分钟1.07B 模型 PTQ，无需训练，超快
mlsys-sparse-attention-inferencecustom_sparse_attn.py59 分钟1.0稀疏 attention，无需训练
ai4sci-inverse-diffusion-algoalgo/custom.py59 分钟1.0扩散逆问题（黑洞成像！），契合 OPHIS
cv-3dgs-densificationcustom_strategy.py60 分钟1.03DGS 致密化，跨场景
cv-pooling-aggregationcustom_pool.py59 分钟1.0resnet56/vgg16bn/mobilenetv2
dl-activation-functioncustom_activation.py2 小时1.0resnet20/vgg16bn/mobilenetv2
llm-qat-algorithmcustom_qat.py75 分钟1.0Pythia-1.4B QAT 训练（int4/int3/int2）
security-membership-inference-defense隐私损失59 分钟1.0resnet20/vgg16bn/mobilenetv2
quant-concept-drift概念漂移3 小时1.0股票预测（csi300）

重任务（多卡/长时，不适合单卡常驻）

任务每 test 时长compute说明
llm-pretrain-optimizer12 小时4.0GPT-345M 预训练
llm-rl-importance-sampling6 小时2.0deepmath RL
cv-dbm-sampler4 小时4.0Diffusion Bridge 采样
cv-vae-loss1–4 小时8.0CIFAR-10 VAE，8 卡
jepa-planning6 小时0.33×3goal-conditioned planning
robo-diffusion-guidance4 小时1.0×3D4RL MuJoCo
robo-diffusion-policy6 小时1.0×3D4RL MuJoCo
rl-value-discrete2 小时0.33×3cartpole/lunarlander/acrobot
推荐组合（8×H100 常驻，互不冲突）：
  • GPU 1-2：ml-clustering-algorithm（10min/test，最快迭代）
  • GPU 3-4：llm-ptq-algorithm（19min/test）
  • GPU 5-6：mlsys-sparse-attention（59min/test，无训练）
  • GPU 7：ai4sci-inverse-diffusion（59min/test，黑洞成像=逆问题）
  • GPU 8：causal-discovery-discrete（59min/test，契合 OPHIS 因果主题）

当前结果（MLS-Bench-Lite，15 个模型）

对 OPHIS 的启示（本文作者的连接，非论文原话）：论文指出的瓶颈 —— "scientific judgment needed to form hypotheses, choose informative experiments, allocate limited trials, and turn feedback into evidence" —— 与 OPHIS 的 observable 闭环目标高度吻合。但论文本身没有提出 observable 框架，它只是诊断了 agent 的缺陷。OPHIS 的定位是：用更好的 observables 回应这个"科学判断"瓶颈。
契合点（OPHIS 解读）
  • 每任务 = 可控闭环（明确干预目标、强基线、跨 setting 验证）
  • 有 AI for Science 领域，与 LIGO 同族
  • 任务原子化，适合观察→诊断→干预→再观察
注意
  • 计算成本高（Lite 也 ~100 H100-hours）
  • 评分归一化到基线，单任务改进幅度可能很小

03 EdgeBench：真实环境中的长期学习（含 LIGO 引力波）

一句话定义：EdgeBench（ByteDance Seed） —— 134 个真实世界任务，衡量 agent 从真实环境中持续学习的能力：不是一次性能力，而是长期交互中的改进轨迹。

核心发现（环境学习 Scaling Law）

任务设计特点

特点说明
环境学习导向workspace、反馈信号、评估器贴近真实实践；分数反映「如何学习和改进」
超长时程每任务 ≥12h；部分 >72h；人类专家平均 57.2h/任务，最长 320h
六类能力域科学问题 & ML、系统 & SE、专业知识工作、组合优化、形式化数学、交互式游戏
专家构建90%+ 从零构建，非简单包装现有数据集

LIGO 引力波任务（协作文档重点，属于完整 134 集，不在开源 51 内）

  • 任务：从 LIGO 探测器数据中 重建引力波波形（H1 波形）。
  • 反馈：多级反馈（分数、误差信息、改进提示）。
  • 示例运行（GPT-5.5，12 小时）：分数 42.8 → 67.0，共 247 次计分尝试。
  • 改进轨迹：先让任务可度量 → 分解失败 → 识别瓶颈 → 保留有效部分并修正剩余错误。
  • 最后阶段：针对 residual / phase / narrow-band 误差定向修正，H1 波形质量提到 67.0。
注意：协作文档写「EdgeBench: 通过 LIGO 数据重建引力波」。EdgeBench 的引力波任务正是 waveform reconstruction（信号重建，逆问题），与 MLS-Bench 的 diffusion-prior inverse solver 同族。但它属于完整 134 任务集（需联系 ByteDance 获取），不在公开的 51 个开源任务里。用开源子集跑的话，对应的是下方 Scientific & ML 类任务。

具体任务例题（51 个开源任务的 raw 定义，来自 HF 数据集）

以下描述直接取自 HuggingFace 数据集（ByteDance-Seed/EdgeBench）中每个任务的 description 字段。每个任务都是 12h+ 长时程，agent 通过 sforge-submit 反复提交、收到反馈、持续改进。

Scientific & ML（4 个，全部开源）

任务 ID任务描述（raw）指标
bipedalwalker_locomotion_rl Train a CPU-only locomotion policy for BipedalWalker and its Hardcore variant. The judge evaluates only the submitted policy checkpoint, not the training process. Pre-trained policies and external RL libraries are prohibited. score (maximize)
borden_source_inversion Infer a finite-duration rectangular contaminant source from sparse, noisy monitoring-well observations in a 3D hydrogeological scene. The agent must implement its own forward model and inversion optimizer from scratch. score (maximize)
dabic_gravity_inversion Implement the D-ABIC regularization method for 3D gravity inversion within the SimPEG framework, run on both synthetic and real Vinton salt dome data under L0 and L1 sparse norms, and compare against a Hamiltonian Monte Carlo baseline. score (maximize)
graph_node_classification Implement graph neural networks from scratch using only base PyTorch for semi-supervised node classification on an unseen graph under CPU-only constraints. score (maximize)

Systems & SE（部分代表）

任务 ID任务描述（raw）指标
exchange_core_throughput Maximize peak throughput of a Java financial matching engine built on the LMAX Disruptor by tuning thread topology, wait strategies, ring-buffer sizing, order-book implementation, and JVM configuration. score (maximize)
ffmpeg_swscale_reimplementation Reimplement FFmpeg's libswscale pixel-format conversion and scaling library in Rust, handling multiple pixel formats and scaling algorithms. A correctness-passing scaffold is provided; the agent must optimize for speed via SIMD. score (maximize)
git_rewrite_in_zig Reimplement git as a drop-in Zig binary producing identical CLI output, exit codes, and repository state as the C reference implementation. The C source is available for reading but cannot be compiled. score (maximize)
integer_compression_codec Improve a C++ integer compression codec for better compression ratio and decode throughput on uint32 datasets via techniques such as delta encoding, bit-packing, and SIMD vectorization. Exact round-trip correctness is mandatory. score (maximize)

Combinatorial Optimization（部分代表）

任务 ID任务描述（raw）指标
ad_placement_optimization Partition a large integer grid into non-overlapping rectangles, each containing a designated anchor point, maximizing total satisfaction from how closely each rectangle's area matches its target. score (maximize)
smt_solver Build an SMT solver from scratch for four quantifier-free theories (uninterpreted functions, linear real and integer arithmetic, and their combination). External SMT solvers are forbidden; model witnesses are independently validated. score (maximize)
vehicle_routing_time_windows Implement a capacitated vehicle routing solver with time windows for Solomon-style benchmarks. Scored against best-known solutions on vehicle count and total travel distance. score (maximize)

Interactive Games & Simulators（部分代表）

任务 ID任务描述（raw）指标
anchorhead_text_adventure Play the Lovecraftian interactive fiction game Anchorhead via an HTTP API, sending text commands and receiving prose observations. Scored by peak in-game score, reflecting progression through the multi-day narrative and puzzle chain. game score
nethack_dungeon_agent Implement a decision policy for NetHack via the NLE harness, parsing ASCII map observations and stat vectors to navigate, fight, and survive across multiple procedurally generated runs. score (maximize)
dcss_dungeon_ai Write a Lua bot for Dungeon Crawl Stone Soup that autonomously explores, fights, and descends dungeon levels as a Minotaur Berserker under a wall-clock time budget. Scored by mean in-game score across multiple runs. score (maximize)
openttd_transport_ai Write an AI script for OpenTTD that builds road, rail, and air transport networks to connect towns and industries and grow company value across diverse procedurally generated maps. score (maximize)

Professional Knowledge Work / Formal Math（各 1 例）

任务 ID任务描述（raw）指标
k12_math_recommendation Build a knowledge-tracing and question-recommendation system from hundreds of thousands of student interaction records, evaluated on prediction accuracy, mastery calibration, learning gain, and pedagogical constraint satisfaction. score (maximize)
carleson_formalization Fill proof obligations in the Lean 4 formalization of Carleson's theorem on pointwise convergence of L^2 Fourier series. Transitive axiom checking ensures no dependence on unproved prerequisites. pass rate

EdgeBench 评估 harness：SForge（raw）

EdgeBench 由 SForge 驱动 —— 一个双容器（two-container）长时程评估框架：

  • 双容器隔离：每个任务物化为隔离的 work 和 judge Docker 镜像 —— agent 只能看到 work 环境，隐藏测试在一次性 judge 容器里跑，从根源防止评估作弊。
  • 迭代评估 + 反馈：agent 不是最后提交一次拿一次性分数，而是全程反复提交（sforge-submit），收到细粒度反馈（pass rates、失败测试、分数），持续改进直到超时 —— 所有提交中的最佳结果 = 最终分数。
  • Stop Hook：阻止 agent 过早退出 —— 当 Claude Code/Codex 认为任务完成想退出时，hook 拦截退出请求并返回阻塞信号要求继续工作，确保 agent 用完分配的时间。
  • Auto-Resume：agent 异常退出（API 断连、瞬时错误）时自动用原生 resume 机制重启（claude --continue / codex exec resume --last），最多 100 次重试。
  • 后台 auto-eval daemon：可选的周期性后台评估，agent 不提交也在跑。

Quick start：

pip install sforge
sforge fetch-tasks edgebench
sforge pull --task ad_placement_optimization --registry seededge
sforge serve
SFORGE_AGENT_API_KEY="sk-xxx" \
  sforge run --task ad_placement_optimization --agent claude-code \
    --model "claude-opus-4-8[1m]" --timeout 43200 --run-id edgebench-001

可视化：三种典型学习轨迹

0h 12h 分数 steady improvement early gains → plateau late breakthrough

Agent 学习曲线（12h 内）：左=稳定提升，中=早期快后平台，右=长期卡住后突破。好的 observables 应让曲线更快上升。

契合点（OPHIS 解读）
  • 多级反馈（分数、错误信息、提示）可视为 observable
  • 有真实科学任务（LIGO 引力波）
  • 学习曲线 = 闭环轨迹，适合衡量「更好 observables → 更快学习」
注意
  • 完整 134 任务需联系 ByteDance（zhongshu@bytedance.com）
  • 公开 51 任务 + 完整评估框架
  • 12h/任务，评估成本高；3 次独立 run 才有曲线

04 ARC-AGI-3：第一个交互式推理基准

一句话定义：ARC-AGI-3 衡量 AI agent 在 新颖环境 中探索、即时获取目标、构建可适应世界模型、持续学习的能力。100% 分数 = 像人类一样高效地打赢每个游戏。

与 ARC-AGI-1/2 的区别

ARC-AGI-1/2ARC-AGI-3
格式静态推理（输入输出 grid 对）交互式游戏环境
反馈一次性给定输入输出每步 action 返回 frame + 元数据
漏洞可 test-time compute 暴力采样环境只在行动后揭示规则，无法预生成 10000 候选
分数单次正确率效率加权（动作越少分越高）

游戏机制（技术细节）

具体任务示例：ls20（Agent reasoning）

  • 人类表现：100%（776 次总动作完成游戏），7 个关卡。
  • 环境标识：grid 游戏；agent 通过 7 个标准动作交互；每步返回帧 + 元数据（可用动作）。
  • 模型表现（2026-04 ~ 07 公开发布，arcprize.org/tasks/ls20 原文数据）：
    模型ScoreActions发布日期
    Humans100%776—
    anthropic-claude-opus-5-high5.36%594Jul 21, 2026
    openai-gpt-5-6-sol-xhigh3.65%567Jun 12, 2026
    openai-gpt-5-6-sol-max3.57%632Jun 13, 2026
    anthropic-opus-4-8-high2.06%644May 31, 2026
    openai-gpt-5-6-terra-xhigh1.69%647Jun 20, 2026
    openai-gpt-5-6-sol-high1.41%650Jun 12, 2026
    其他模型（luna/terra/sol 低档、grok-4、gemini-3.1、opus-4.6 等）0%110Apr-Jun 2026
重要洞察：动作数多 ≠ 得分低。模型用接近人类（776）的动作数（594-650）却只得 ~5% 分 —— 说明模型在策略分布上与人类完全不同：可能在前几关大量探索，但没真正理解机制。效率加权评分直接惩罚「无效探索」。

评估方式（效率加权）

可视化：ls20 各关卡动作分布

Level 1
15%
最优通关 · 少量
Level 2
25%
Level 3
35%
Level 4
48%
Level 5
60%
动作数随关卡递增
Level 6
75%
Level 7
92%
后期关卡更难，探索消耗最多

三条参考线：最优通关 / 最佳首跑 / 人类基线。后期关卡动作数显著上升，说明 agent 在后期关卡消耗大量探索。

OPHIS 视角（本文作者解读，非 ARC-AGI-3 论文原话）：ARC-AGI-3 论文（技术报告）没有使用 "observable" 或 "闭环" 概念。它描述的是 agent 通过动作与环境交互、每步获得 frame 与元数据。把 "frame + 元数据" 解读为 OPHIS 的 "observable 流" 是本文的映射 —— 因为 agent 确实依赖这些观测来推断世界规则、决定下一步动作（即干预）。
契合点（OPHIS 解读）
  • 每步 frame + 元数据 = 天然 observable 流
  • 效率加权评分 = 直接惩罚无效探索
  • 隐藏目标/规则 = 需要主动诊断环境
注意
  • 动作接口受限（7 个动作），observable 主要是视觉帧
  • 135 环境无指令/无规则/无目标，评分惩罚暴力搜索（人类 10 步 vs AI 100 步 → 得 1% 不是 10%）

05 nanoGPT：作为 OPHIS 的可控 example

为什么是好 example：nanoGPT 是 Karpathy 的最小可训练 GPT 实现 —— 完全可控、丰富 observable、已有大量基础、从零可复现。

独特优势

闭环示例（基于本项目已有工作）

Observeloss 曲线、gap、table RMS
→
Diagnose低频 token 的 gap 大
(K-1)/r 定律
→
Intervene改进采样/词表/记忆机制
→
Rerun相同 setting
→
Observegap 是否缩小？
是否引入新问题？
契合点
  • 最可控、成本最低的闭环验证平台
  • 已有理论体系（gap 形成机制）作「诊断」知识底座
  • 适合验证 Claim 4（诊断 → 更好干预决策）
注意
  • 单一任务不够「普遍」，需与 MLS-Bench / EdgeBench 搭配成 3 个闭环

nanoGPT 具体任务设定（本项目的闭环平台）

nanoGPT 是 Karpathy 的最小可训练 GPT 实现（GitHub: karpathy/nanoGPT）。核心是 train.py 训练脚本 + model.py（GPT-2 风格 decoder-only transformer）。本项目用它作为 OPHIS 的 example，具体 task 设定：

  • 训练：自回归语言建模，next-token prediction，cross-entropy loss。
  • 数据：OpenWebText 或 TinyStories 等；本项目用 n-gram 频率可控的合成数据（5-gram）来精确操控 token 频率分布。
  • 架构：decoder-only transformer（n_layer/n_head/n_embd 可调），可加/改组件（采样、词表、记忆机制）。
  • 观测维度（observable）：
    • train/val loss 曲线（按 step 记录）
    • gap = train loss − val loss（本项目核心指标，已建立 (K-1)/r 定律：gap 随词表/频率的标度关系）
    • table RMS：词表表项统计与 loss 的对齐诊断
    • token 频率分布、梯度范数、激活分布、attention 模式
  • 干预空间：改采样分布、改词表、改记忆机制、改训练超参（LR/schedule/batch）、改架构组件。

注意：这里 "observable" 是本项目自己的分析框架 —— nanoGPT 本身不提供所谓 "observables"，它只是一套可观测的训练日志。如何从这些原始日志中选择/组合/设计 observables，正是 OPHIS 要研究的问题。

06 Observable 闭环：每个 bench 怎么做 + 缺陷分析

本节性质说明：本节完全是 OPHIS 自己的分析框架，不是任何 bench 论文的内容。表格里"Observable / Diagnose / Intervene / 闭环关键"是本文作者为每个 bench 设计的闭环工作流假设 —— 这些 bench 论文都没有提出 observable 闭环方法。本节用于帮助我们思考 OPHIS 如何落地到这些 bench，不代表 bench 本身支持这套框架。

6.1 总体思路：每个 bench 的闭环怎么做

BenchObservableDiagnoseIntervene闭环关键
MLS-Bench 训练曲线、验证指标、组件相关诊断（量化误差、attention 分布、图信号传播） 识别瓶颈子模块（方法问题 vs 实现/超参/种子问题） 方法级修改（受限可编辑范围），≥3 setting + 跨规模验证 多 setting + 多 seed 防自欺，单点改进不算数
EdgeBench (LIGO) 多级反馈（分数、错误信息、提示）+ 波形残差可视化 把任务可度量 → 分解失败 → 定位瓶颈（residual/phase/narrow-band） 针对瓶颈定向修正 12h 学习曲线 = 闭环轨迹；好 observable 让曲线更快上升
ARC-AGI-3 每步 frame（grid 状态）+ 元数据（可用动作） 从视觉状态推断世界规则（目标？可交互对象？动作效果？） 选择下一个动作（行动即干预） 效率加权评分 = 衡量「理解速度」；好 observable 减少达到理解所需动作
nanoGPT loss、gap、table RMS、token 频率、梯度统计 用已有理论（(K-1)/r 定律、gap ~ U(r) log(r/αK)）定位根源 修改训练/数据/架构组件 快速迭代，验证诊断→干预因果链

6.2 Observable 闭环的缺陷在哪里

缺陷 1：诊断 → 干预的归因问题（根本性）

闭环里最脆弱的一环是「诊断出的原因」是否真是「干预成功的因果机制」。

  1. 相关性 ≠ 因果：观察到的 observable（loss 翘起、gap 大）可能是多个机制的共同表现。agent 可能选了一个「看起来对症」的干预，其实碰巧有效/无效。
  2. 缺少反事实：人类科学家用消融实验、控制变量验证因果；但闭环 agent 通常只看到「干预前 vs 干预后」两条曲线，无法区分「这个干预有效」与「任何改变都有效」（seed 运气、隐式超参改变）。

缺陷 2：observable 的「信息效率」问题（Claim 2/3 核心）

  1. 原始 observable 太多：训练日志、曲线、中间状态海量。盲目全给 → 上下文爆炸 → 信息过载 → 性能下降（正是 Claim 2 说的「饱和甚至有害」）。
  2. 可观察 ≠ 可诊断：即使 observable 完整，agent 也可能不知道看哪里。例如关键信号可能是「某频率 bin 的 loss 翘起」，但原始 loss 曲线看不到。
  3. 缺少「实验设计」的 observable：目前 observable 都是「被动观察训练」，缺少「主动实验」观测 —— 比如「如果我干预 A，会发生什么」的反事实观测。这是闭环里最缺的。

缺陷 3：闭环的「探索-利用」权衡

  1. 干预次数有限：每次重跑都花 compute（MLS-Bench ~5-10 H100-hours/任务；EdgeBench 12h）。agent 需在有限预算内决定「深入一个假设」vs「尝试多个假设」。
  2. 缺「下一个实验该做什么」信号：现在的 observable 描述「当前状态」，但闭环最需要「哪个实验最有信息量」——这本身需要元认知。

缺陷 4：闭环的「自欺」风险（过拟合闭环本身）

  1. 对当前任务过拟合：agent 可能学到「这个 observable 对应这个干预」，换任务就失效。这正是 MLS-Bench 设计多 setting 验证的原因。
  2. 对 observables 过拟合：若 agent 发现「loss 曲线形态」与「最终分数」相关，可能直接优化 loss 曲线形态（如刻意降 LR 让曲线平滑），而不解决真正问题 —— 一种 observable 作弊。

缺陷 5：闭环缺少「人类科学家的隐性知识」

  1. 先验知识：人类知道「梯度爆炸通常调 clip」「loss 平台可能是 LR 问题」。LLM 先验覆盖一部分，但不覆盖领域特定知识。
  2. 「直觉」不可编码：很多科学判断（这个实验值得做吗）难以用 observable 形式化。

缺陷 6：评估闭环本身的指标缺失

  1. 没有标准指标衡量「诊断质量」：目前只衡量最终分数（干预好不好），不衡量诊断对不对。
  2. 无法区分「运气好」和「诊断对」：单次闭环成功可能是偶然；需多次重复 + 统计。

07 下一步行动建议

  1. 选 3 个闭环（建议组合）：
    • nanoGPT —— 最可控，已有基础，作为 example + 方法论开发地
    • MLS-Bench-Lite 的 1-2 个任务 —— 如 llm-qat-algorithm 或 ai4sci-inverse-diffusion-algo（AI for Science + 训练闭环）
    • EdgeBench 的 LIGO 引力波任务 —— 真实科学问题，需联系 ByteDance 获取完整任务；或先用公开 51 任务里的 Scientific & ML 任务
    • ARC-AGI-3 可作为补充/探索（交互式、成本低但评价标准不同）
  2. 先做一个「最小 observable 闭环」原型：在 nanoGPT 上实现「观察→诊断→干预→再观察」，把闭环的缺陷暴露出来（特别是归因问题）。
  3. 针对 Claim 2/3 做可控实验：同一任务，给 agent 不同数量的 observable（少量精选 vs 海量原始），测量闭环改进效率 —— 直接验证「盲目加 observable 会饱和」和「OPHIS 能提升信息效率」。
  4. 探索「主动实验」observable：让 agent 不只被动看训练，还能主动设计小实验（如 probe 中间状态），这可能解决缺陷 2.3。

08 参考链接

Bench链接
MLS-Bench 官网 · arXiv 2605.08678 · GitHub · HF 数据集
EdgeBench 官网 · Blog · arXiv 2607.05155 · GitHub · HF 数据集
ARC-AGI-3 官网 · 技术报告 · Docs · ls20 任务 · GitHub Agents · Kaggle · arXiv 2603.24621
nanoGPT GitHub (Karpathy)

09 子报告（OPHIS-baiyu 实验记录）

以下子报告记录 OPHIS-baiyu 在 MLS-Bench 上的实际 autoresearch 实验：三套系统（官方 InteractiveAgent / 本地 Codex / dsh 极简 harness + deepseek）在多台 GPU 集群上的完整结果、优化曲线与原始 trajectory。

协作文档：OPHIS 协作文档 (Google Docs)