Harness-Delta 归因：拆解 Agent Harness 进化的性能增益来源
🧭 Agent 评测与进化增益归因
Amazon · New York University
提出 HDA 协议，将 harness 进化增益归因为 overfitting、test-time scaling 与 residual 三类
📌 工作参考价值（4 点）
- 在做 Agent 搜索结果页策略、推荐链路 prompt/tool 搜索时，引入 HDA 式分解：对 search set 的 lift 拆成 artifact overfitting、inference compute scaling 与 residual；只报验证集不够。
- 必须设置 held-out tasks/跨类目流量做泛化验证；电商 query 推荐、广告文案生成等场景，benchmark 相似 query 的增益常不迁移到真实分布。
- 对加入多采样、投票、更多推理步数的方案，单独量化 test-time scaling 贡献，避免把“多算力带来的提升”误判为 harness 设计有效。
- 用 artifact-driven probes（如检测规则式捷径、重复输出短路）暴露过拟合；可在推荐 Agent 中设计反事实或干扰样例来检查泛化。
RRSI：Agent 外壳的正则化递归自改进
🧭 Agent 自改进正则化 · harness 进化 ★ 深度解读
Google Cloud AI Research · UNC-Chapel Hill · Stanford University · Washington University in St. Louis
用 proposal 与 selection 两侧正则化约束 Agent harness 自改进，缓解在有限 evolve set 上的过拟合
📌 工作参考价值（4 点）
- 在电商搜索/推荐 Agent 或购物助手做自动化 prompt、tool description、context 管理的 A/B 调优时，很容易在内部小评测集上过拟合。可复用 RRSI 的 leakage screening：评估前先用 critic 过滤掉显式包含 task name、商品名、类目特定逻辑或实体值的候选，防止这类候选靠局部泄漏获得高 evolve score 进入后续搜索。
- 引入 noise band 接受 floor：先在固定 base harness 上重复评估估计噪声 δ，候选分数必须 ≥ S*-δ 才允许替换 incumbent。这能避免在搜索/推荐 Agent 的策略迭代中，把随机噪声冠军当成稳定改进永久写入系统。
- cost-aware acceptance 对生产很有用：任何候选若增加 policy tokens（例如更长的 few-shot 示例、更多 tool schema 字段、额外 context 读取），必须用 ΔC ≤ β0 + β1 ΔS 证明收益。可以直接迁移到线上成本约束的推荐 Agent 或 LLM 链路，避免演进结果越来越贵但得分不涨。
- 结构化探索和 evidence-aware history 可以复用到 query 改写策略、召回 prompt、排序 Agent workflow 的自动搜索：记录每轮修改的组件、假设和验证结果，停滞时优先探索从未改过的组件（如 control flow / context 管理而非继续改 prompt）。另外可加一个跨模型验证步骤：搜索得到的 harness 若不随 backbone 能力消失，才更像可复用机制而非策略专属补丁。
数据稀缺与模型稀疏：MoE 对重复数据更易过拟合
🧭 LLM 训练 · 数据重复 · MoE 正则 ★ 深度解读
Stanford University · Paul G. Allen School of Computer Science, University of Washington
在重复数据训练下，MoE 比同 active 参数的 dense 模型退化更早更快，且退化程度由 total 参数决定
📌 工作参考价值（4 点）
- 搜索/推荐/广告等业务里若用 MoE 或稀疏 LLM 做召回、排序、query 生成，数据重复是常见场景（行为序列、曝光样本、promo 物料反复出现）。不要只看 active 参数，要把 total 参数计入训练预算；重复率控制在 4× 以内对 MoE 相对安全，超过 8× 需要警惕。
- 当业务数据受限必须多 epoch 训练时，优先在 MoE 的输出侧做 masking：FFN output masking、expert dropout 或 expert output masking，比 router jitter、weight decay 更有效。生成式推荐/query 生成模型可以在 expert 输出上加 token-level 或 expert-level dropout，缓解重复样本导致的过拟合。
- 多域数据混合训练时，如果某个域 unique 数据不足，不要无限重复该域；把它与语义相似的未重复域混合可能起到正则化作用，而语义差异大的域（如 code 与 web）混合无此效果。对电商多源数据（商品、内容、广告、搜索词）做配比时值得验证。
- 路由早稳定是一个可工程化的监控信号：若 MoE 在训练早期 router 决策就接近冻结，并且 train loss 快速降到很低，通常意味着 expert 在过拟合固定 token 子集。可定期做 expert knockout 分析，量化专家冗余与过度 specialization，作为是否继续训练或切换架构的依据。
重新审视智能体 Harness 进化的评估
🧭 Agent Harness 进化评估
Allen Institute for AI · University of Washington · Independent
自动 Harness 进化在公平比较下未超越简单测试时搜索，且泛化有限，呼吁新评估协议
📌 工作参考价值（4 点）
- 公平基线设计：在为业务 Agent 引入自动 Harness 优化时，必须以简单 test-time scaling（如多次采样投票）为基线，匹配推理预算，确保增益来自设计改进而非额外搜索。
- 防过拟合拆分：搜索配置与最终评估必须使用不同任务集，避免在公共 benchmark 上循环优化导致的过拟合，提升上线后的泛化性。
- 谨慎采用自动进化：实验显示自动 Harness 进化并不稳定优于简单基线，落地时优先考虑可靠的固定 Harness，仅当有强泛化证据时才投入自动搜索。
- 关注现实迁移：评估 Harness 时增加留出任务集测试，模拟业务中分布外场景，防止在熟悉任务上虚高，确保 Agent 在真实多变环境中有效。
Multi-LCB：将 LiveCodeBench 扩展至多编程语言的代码生成评估基准
🧭 多语言代码评估基准构建
GigaCode · Yandex School of Data Analysis, Applied AI Institute
将 LiveCodeBench 扩展到 12 种编程语言，揭示 LLM 跨语言代码生成的过拟合与污染问题
📌 工作参考价值（4 点）
- 多语言任务等价转换方法：通过翻译 Python 任务到其他语言并保持评估协议一致，可借鉴用于构建多语言推荐系统的等价测试集，例如将用户查询或物品描述转为多种语言，验证跨语言推荐的一致性。
- 模型过拟合检测：对比模型在 Python 与其他语言的性能差异，发现 Python 过度拟合；在推荐系统中，可通过类似手法分析模型是否过度依赖特定模态或高频特征，识别训练数据偏置。
- 污染感知评估设计：使用时间戳过滤任务，避免训练集污染，该机制可直接用于推荐基准的版本管理，确保评测的公平性和时效性。
- 多语言性能差距分析：暴露的多语言性能鸿沟提示在训练多模态 / 多语言推荐模型时，需平衡各语言的数据配比，并在评估中纳入多语言维度以指导模型优化。