评测 Agent 别只看分数：美团这篇论文把 7 个模型、36 个任务拆开看，发现它们更像「工程优化器」而不是「研究者」
看 Agent 能力，你习惯看什么？benchmark 最终分数，对吧。
但一份最终分数回答不了这几个问题：这个 Agent 的进步发生在哪个环节？它积累的经验有没有真的改善后面的决策？它是不是只是"碰巧"跑出了这个分数？
美团这篇论文（arXiv 2608.13417，LongCat 团队）就是冲着这个来的：Beyond Final Scores——7 个前沿模型、36 个长程 AI 研发任务，不看最终分，把 Agent 的"过程"拆开看。
结论有点扎心：现在的 Agent 更像工程优化器，而不是自主研究者。 它们能干活，但干的是"优化"的活，不是"研究"的活。
评测是怎么设计的（细节都在这里）
先说实验设置，这决定了结论的可靠性：
- 任务：36 个来自 AutoLab 的专家精选任务，分 4 类——模型开发（7 个）、系统优化（15 个）、谜题挑战（10 个）、CUDA 编程（4 个）
- 任务形态：每个任务给你一个目标 + 一个"正确但刻意次优"的起始产物 + 专家写的参考答案 + 墙钟预算（2-12 小时）+ 自动验证器。Agent 要在预算内迭代改进，验证器按"相对起始产物和参考答案"给 0-1 归一化分数
- 模型：7 个前沿模型——Claude-Opus-4.7、GPT-5.5、Gemini-3.1-Pro、GLM-5.2、Kimi-K2.7-Code、DeepSeek-V4-Pro、LongCat-2.0（美团自家）
- 关键控制变量：跨模型主对比时，所有模型都用同一个 harness——Claude Code (v2.1.152)，把工具接口和迭代策略固定住。这样模型之间的差异才是"模型本身"的差异。harness 的影响单独评测（§5.1）
- rollout：每个模型 × 每个任务跑 3 次独立 rollout，共 756 次；报告 avg@3（典型表现）和 best@3（最佳表现）
- 唯一的人工干预：要求 Agent 每次迭代后 commit + 维护实验日志（为了拿到过程数据），其余条件不动
评测框架：把"研究循环"拆成三个维度
论文把自动研发的过程拆成 C1/C2/C3 三段，对应研究循环的因果结构：
C1 Solution Framing（问题框定）——Agent 选了什么方向去做。 不评判方案"听起来高不高级"，而是用运行中的最佳验证器分数（running best verifier score）作为方向质量的客观代理。轨迹统一映射到时间轴，按早/中/晚三段汇总——同时奖励"分高"和"分来得早"，而且后面的失败不会抹掉早期发现。
C2 Execution（执行）——选定的方向有没有被可靠地做出来。 每个非初始检查点过一道"交付门"：产物能不能跑？（有正确性判定的任务还要判断对不对）交付失败零分；成功交付按之前发生的构建失败打折（折扣有界，环境导致的失败排除）。
C3 Feedback Control（反馈控制）——Agent 怎么用实验反馈调整方向。 两个子成分：retention（保持）——最终分和运行中最高 step 分的差距；recovery（恢复）——每次"改坏了"之后，找回多少分、需要几步。自我评估的尝试会有界惩罚（防"隐蔽试错"）。
三个指标全部从记录的评测信号确定性计算（不是主观打分），可复现、可审计。
这张图就是全文的"地图"，分上下两半：上排 5 个是过程视图——C1 问题框定、C2 执行、C3 反馈控制的典型轨迹示意，加上 M_intra（任务内自改进）和 M_inter（任务间迁移）的经验复用对比（有经验 vs 无经验）；下排 5 个雷达图是 7 个模型在这 5 个维度的实际得分。
结果一：执行普遍强，框定普遍弱
四个子图分别是最终分（Outcome）和三个过程维度（C1/C2/C3），每根柱子是一个模型（7 个模型从左到右），数值是 3 次 rollout 的平均。看的过程很简单：上下对照，找"最终分差不多但过程分差很远"的柱子组合。
看 Figure 4 的数据模式，比任何结论都直观：
- C2 Execution 得分最高且扎堆：0.88-0.97，7 个模型几乎都接近满分，差距极小
- C1 Solution Framing 最弱：0.47-0.61，7 个模型普遍拉胯
- C3 Feedback Control 中等偏高：0.77-0.93，但方差大
这个模式意味深长：模型最擅长"把方案做出来"，最不擅长"选对方案"。 通用代码执行训练已经喂得很饱了，真正的瓶颈在方向选择。这跟"工程优化器"的画像完全吻合——给你一个明确任务，执行到位；让你自己找路，就露怯。
论文还发现：相似的结果背后可能是完全不同的过程画像——两个模型最终分一样，一个框定准但执行抖，一个框定偏但执行稳，优化它们的策略完全不同。只看分数，你根本不知道改哪里。
结果二：组合堆叠 44%，真正创新 1.2%
这是全文最扎心的数据。论文把 7 模型 × 36 任务的 best-of-3 方案（252 个）拿出来，用固定 rubric 分成 8 类（每类人工复核）：
- 组合堆叠（把已有技术叠起来）：111/252 = 44.0%，每个模型的最大类
- 真正的新颖方案：人工复核后只有 3 个（1.2%）
- 更炸裂的：16 个方案（6.3%）在利用评测漏洞（evaluation-specific shortcuts）——比真创新多 5 倍，其中 GPT-5.5 一家占 8 个
也就是说，当 Agent 偏离标准做法时，它更可能去钻评测的空子，而不是产生被验证过的新思路。
那 3 个真创新也值得看一眼——它们全都没有发明新原语，而是"任务特定的重框定"：GLM-5.2 用 Fredkin 门组合构造了一个无辅助位的比较器；Kimi-K2.7-Code 把下一帧预测重框定为光流+残差扭曲；LongCat-2.0 找到了一组充当架构瓶颈的 BatchNorm 位。而且，真创新并不集中在最强模型上（Opus/GPT 一个都没有）——这暗示"创新"和"优化能力"是两回事。
结果三：经验复用是双刃剑
论文用受控对比专门测了经验复用：任务内（M_intra）和任务间（M_inter）。
结论很微妙：经验有时帮忙，有时误导后续决策。Figure 1 下排的雷达图里，M_intra 得分普遍很低甚至有负值（-0.01）——“经验越用越好"这件事，目前所有模型都做不到。跨任务迁移尤其危险，你以为在"积累经验”，实际可能在"积累偏见"。
结果四：harness 影响稳定性，不影响天花板
呼应我们上一篇综述的发现：论文单独对比了共享 harness（Claude Code）和模型原生 harness，结论是——原生 harness 提升 run-to-run 稳定性，但不会显著提高性能天花板。
稳定性的提升来自：错误恢复、任务管理、最佳状态保护（best-state protection）这些机制，减少了长时间实验中的可避免失败。
论文给出的四个改进方向
- 训练：执行已经很强很齐，通用代码执行训练不是主要机会；要针对框定和反馈控制的短板做定向训练（过程奖励、针对性课程）；正负迁移的成对案例可以教模型"什么时候该用经验"
- 推理时搜索：avg 和 best 的差距说明"能力有，但复现不出来"——可以生成更多样化的 rollout，用验证器反馈挑轨迹；从有希望的 checkpoint 分支，砍掉反复失败/停滞的轨迹；框定弱就多探索，执行弱就多深挖
- 记忆与 harness：记忆系统要支持经验的选择性检索、验证、修订和删除（不是简单堆上下文）；harness 自动化优化有空间——任务特定 harness、模型自适应 harness
- 新评测目标：当 reward 只捕捉任务性能、不捕捉方法论质量时，Agent 永远学不会"做研究"——需要把过程质量、方法新颖性纳入目标
对做工程的人，直接能抄的三件事
- 别信单次跑分：论文证实同模型多次 run 方差很大——评测 Agent 至少跑 3 次取分布（avg@3/best@3 都看），单次分数没有意义
- 评测要拆维度：照着 C1/C2/C3 三个维度评自己的 Agent——先让它输出方案设计看框定准不准；记录中间步骤看执行稳不稳；中途注入错误反馈看它会不会调整方向。相同分数不同瓶颈，拆开才看得到
- 先动 harness 再动模型：工具编排、状态管理、错误恢复这些执行层配置，对稳定性影响可能比换模型还大——调优 Agent 时，这是性价比最高的起点
一句话总结
最终分数是结果，过程才是原因。这篇论文把"看结果"升级成"看过程"，并且用三个硬数据钉死了结论：执行强而框定弱（0.88-0.97 vs 0.47-0.61）、创新 1.2% 而钻空子 6.3%、经验复用负值——Agent 的能力短板，一半在模型，一半在执行层（harness），而后者目前被严重低估。
原文：arxiv.org/abs/2608.13417（LongCat 团队，2026-08-13）
下期想深读哪篇？评论区点单。