一句话结论
TB-MathModel 解决的是评测对象错位：现有数学建模基准要么只给求解器的片段打分，要么让大模型当裁判去评整篇报告，最终数值既没有对齐可信参考，也没有检查物理可行性；这篇论文把整道竞赛题放进容器终端，让智能体只交一个 JSON，并且只对最后一问的数值核心计分，计分前先过一道可行性闸门。
方法要点
数学建模的产出链条是「开放现实问题 → 假设 → 模型 → 解 → 有辩护的建议」，其中真正能被机器判对错的，是最后一问的数值核心。作者围绕这一点重做了任务形态。
任务形态：终端 + 单文件交付
每道题在容器化终端里给出原文题面、官方附件和图片，智能体可以自由读写文件、写脚本、跑代码，最终必须产出一个固定结构的 JSON artifact。这带来两个副作用：一是评测对象从「一段回答」变成「一次可回放的操作轨迹」，二是轨迹本身可以回收做智能体训练数据。
打分设计一：多参考 + 方向感知的单边打分
题目不是对着某一篇国赛/美赛 Outstanding 论文打，而是对着一个由多篇优秀论文组成的参考面板打，模型必须同时贴近多个被接受的答案，而不是碰巧命中某一个锚点。同时采用方向感知的单边计分：结果比锚点更好时不扣分。这一点很关键，否则「超过人类参考」会被当成错误。
打分设计二：两层可行性验证 + 硬闸门
数值对得上，不等于模型在物理上成立。作者加了两层验证：第一层是把题意形式化成若干类可判定的不变式（守恒、边界、单调这类可以被程序直接判定的形式），第二层是把部分约束写成 Lean 4 的证明义务。任何一层不通过，该题直接归零，而不是打折。
# TB-MathModel 单题评测流程（伪代码，按原文描述整理）
task = load_task("CUMCM") # 原文题面 + 官方附件 + 图
box = start_container(task.files) # 容器化终端，只暴露终端
while not box.done() and step < MAX_STEP:
action = agent.observe(box.terminal()) # 观察：终端输出
box.exec(action) # 动作：跑代码 / 读附件 / 写脚本
artifact = json.loads(box.read("answer.json"))
core = artifact["final_question_numeric_core"]
if not invariants_pass(core): # 第一层：可判定不变式
return 0.0
if not lean4_check(core): # 第二层：Lean 4 证明义务
return 0.0
# 多参考面板 + 方向感知单边计分：超过锚点不惩罚
return one_sided_oeval(core, panel=outstanding_papers)
关键数字
| 数据集 | 指标 | 对比基线 | 结果 |
|---|---|---|---|
| TB-MathModel（CUMCM / MCM 真题） | 多参考 O-Eval，越高越好 | 最强的多模态参赛模型 | 64.58% |
| 同上 | 同上 | 标价 2.54 美元的开放模型 | 59.81%，成本约为前者的 1/100 |
| 论文自述体量 | — | — | 20 页正文、4 幅图、14 张表 |
两个分数要放在一起读：最强的多模态模型拿到 64.58%，而一个标价 2.54 美元的开放模型在约 1/100 的成本下拿到 59.81%，两者只差几个百分点。这说明在这个基准上，钱还没能直接换成分数，头部与低成本方案之间尚未拉开代差；也说明当前区分度主要压在「数值核心 + 可行性」这一层，而不是报告写得漂不漂亮。
局限与前提
只覆盖真题，题量与难度分布受赛题约束。 基准取自 CUMCM 与 MCM 的真实赛题，题目来源固定，扩题需要新的官方题面与附件，不能像合成基准那样批量生成。
只评最后一问的数值核心，不是完整评分器。 假设是否合理、模型选择是否恰当、论文叙事是否站得住，这些建模里最见功力的部分不在打分范围内。拿它当「建模能力总分」会高估。
可行性闸门是双刃剑。 硬闸门把不可行答案直接归零，好处是杜绝「数字凑对但物理上荒谬」，代价是形式化本身可能出错：不变式写错了、Lean 4 义务写窄了，会把正确解误杀成零分，而且这种误杀在结果里表现为「模型不行」，很难被发现。
单边打分留了后门。 超过锚点不惩罚是对的，但它也意味着某些远离参考方向、但数值恰好落在合理区间的答案可能不被识别出来。
依赖完整工具链。 容器、Lean 4 工具链、能操作终端的智能体，三者缺一不可，复现门槛明显高于「下载一个 jsonl 跑 infer」。
能不能用
代码是开源的，论文摘要里给了源码链接；权重方面原文没有提及，所以只能复现评测侧，不能指望直接拿到模型。
本地跑起来大致需要：容器运行时（题面、附件、图都在镜像里）、Lean 4 工具链（第二层验证）、以及一个能读终端输出并执行动作的多模态智能体。典型的准备步骤是：
# 复现前置（按论文仓库说明调整具体镜像与命令）
docker pull <tb-mathmodel-image> # 题目容器：题面 + 官方附件 + 图
elan install && lake build # Lean 4：编译可行性证明义务
python run_eval.py --agent <your-agent> \
--artifact answer.json # 只认 JSON 交付物，不认自然语言
适合的用法有两个：一是把它当成「长程建模能力」的可回放信号，用它筛模型、比较提示策略；二是回收终端轨迹做训练数据。不适合的用法是拿它给一篇建模论文打分，或者用它衡量模型的写作与论证质量——那不在它的设计范围内。