固定模型也能改进，固定测试也能被记住

RRSI 的研究对象可以记作 Agent = 固定模型 π + 运行框架 H。H 决定模型看到什么、怎样调用工具、何时结束、哪些内容进入上下文，以及失败之后如何恢复。权重不变，系统表现仍可能大幅变化。

Google Cloud AI Research 等机构的这篇工作于 2026-09-21 首发，本文核对 v2（09-23）。它把重点放在一个经常被忽略的矛盾上：反复利用任务集改 H，既能修复真正的问题，也能逐渐写入只适用于这组题目的规则。作者约束搜索轨迹，同时保持较大的可修改空间。论文全文

本文最重要的判断是：RRSI 提供了受约束的 harness 搜索及跨任务证据，没有证明改进器能无限增强。 它的实用价值在于把失败历史、候选修改、成本和接受规则组织成可审计的过程。

过拟合发生在整个搜索过程

普通机器学习中，训练集影响权重。这里即使没有梯度，任务的分数和失败轨迹也在影响后续代码。若候选不断看到“这道题失败是因为某路径不存在”，最终就可能生成识别路径、任务名或特定输出的分支。

另一种更隐蔽的情况没有直接写答案。系统发现多用三倍 token，开发集分数就高一点，于是持续堆叠反思、重试和子 Agent。分数增长可能来自资源增加，且附加组件也可能只对已见样本有效。

因此，评价对象不是最后一次补丁，而是产生它的完整适应过程。对最终代码做一次静态检查不能消除之前数十轮评分已经透露的信息。

候选怎样被提出

公开实现把每个候选放进独立 Git worktree。分析器从执行轨迹提取失败，提出器结合历史记录生成修改，再由 critic 在完整评估前筛查任务特定逻辑。历史按组件记录假设、测量变化与结论，使“已经被证伪的想法”有机会从后续搜索中退出。研究代码与流程映射

用一个教学例子说明：Agent 因上下文截断忘记输出要求。候选 A 在每轮重复完整要求；候选 B 将必要约束保存为短状态；候选 C 识别题目名称后插入预设答案。A 可能涨分但更贵，B 可能有可迁移价值，C 即使涨分也破坏实验意义。critic 处理 C，成本规则帮助区分 A 与 B；真正的泛化仍需未见任务。

作者还让编辑预算随搜索推进收紧，停滞时尝试此前没有探索的组件，并提出删除无贡献结构的候选。其因果直觉是：前期允许结构探索，后期减少同时发生的变化，以提高归因能力。它不是对模型权重施加传统 L1/L2 正则；论文借这些术语描述功能相似的搜索约束。预算实现

接受候选并非只看涨分

以下是对公开选择代码的解释。记当前分数为 Sₜ，历史最好分数为 S*，候选分数为 S′，噪声带为 δ；成本变化 ΔC 是相对当前 token 成本的比例，分数变化 ΔS = S′ − Sₜ。首先需要：

S′ ≥ S* − δ

这阻止系统为了成本或新结构而远离历史最好水平。随后规则分支：

若 ΔS > δ：
    ΔC ≤ β₀ + β₁ × ΔS
否则：
    wₛ × ΔS − w꜀ × ΔC + wₙ × novelty > 0

最后还要满足领域约束。通过准入的候选中，选分数最高者；若没有合格候选，则保留当前版本。这段解释依据 selection.py。

“超过噪声才接受”并不准确。噪声带内仍能因为节省成本或探索新结构而通过。Coding 配置的 wₛ = 0，意味着带内的小幅涨分本身不提供接受奖励。novelty 也不是由模型随口判断“有创意”，而由代码里的结构类别和历史记录决定。Coding 配置

这解释了两个看似矛盾的目标：系统可以容忍很小的分数下降，以获得便宜或值得探索的结构；但容忍范围被历史最好分数限制。它是一套启发式决策规则，不能自动解释成“统计显著性检验通过”。δ 也不等于对无限次自适应比较有效的置信保证。

一轮搜索的计算账本

Coding 默认 20 轮，每轮 2 个候选，89 道演化任务每题跑 2 次。若每个候选都通过前置检查并完整评估，仅候选测评就有 20 × 2 × 89 × 2 = 7,120 个 trial；还未计入基线、分析器、提出器、critic、失败修复和分布外测试。这是从公开配置推算的名义工作量，不是论文报告的总账单。配置

每次 trial 的 token 成本和一次完整搜索的总成本不是同一指标。如果更复杂的候选每次稍便宜，但用了数百个候选才找到，是否值得取决于未来部署次数。可以用一个简单的盈亏关系思考：

未来节约 = 部署次数 × 每次节约
净收益   = 未来节约 − 搜索与验证成本

这不是 RRSI 原论文的财务模型，而是将其成本指标用于工程决策时必须补上的边界。

开发集更高不一定代表更好

下面保留最能说明机制的 workspace 消融表。单位为论文所用百分制分数，OOD Avg. 是 JobBench、GDPval、APEX-Agents 三项指标的算术平均；各项评分语义并不完全相同。token 是每次 trial 的百万 policy tokens。原文表 2

版本 演化集 同分布留出 OOD 平均 百万 tokens / trial
原始 H₀ 89.4 86.9 39.7 1.56
无正则演化 92.8 88.9 40.3 3.80
RRSI 90.5 89.2 43.6 2.42

论文的启发在于排序变化：无正则版本在演化集更高，但 OOD 平均不如 RRSI。这个观察与“限制搜索可以减少对演化任务的特化”相容。不过，跨多个指标取平均只是描述性汇总，不能据此推导跨领域统一能力增幅。

(3.80 − 2.42) / 3.80 ≈ 36.3%，是相对无正则演化的 token 下降。相对原始系统，(2.42 − 1.56) / 1.56 ≈ 55.1%，RRSI 反而更贵。两者同时成立。摘要中的约 30% 与表格、官网约 36%口径需要并列保留，不能只选择最吸引人的表述。项目页

迁移证据要带着模型和分母阅读

主实验固定 Claude Opus 4.8：Terminal-Bench 2.1 演化集 74.2→80.2，SWE-bench Verified 分布外测试 82.0→83.8，分别增加 6.0 和 1.8 个百分点。另一个 Gemini 3.5 Flash 配置为 64.6→78.7、76.8→79.0；常被引用的 +14.1 点来自后者的演化集，不应替换前者的主结果。原文表 1、表 3

Workspace 使用 120 个演化任务与 40 个同分布留出任务；Engineering 使用 61 个任务、每题 4 次，并另测其他工程任务。这些设计比只看演化集可靠，但仍是有限任务、有限轮次、有限模型下的实验。OOD 表示相对本次搜索未使用的任务分布，不等于现实世界中所有未知任务。

从源码中还能读出什么

预算公式在默认 Coding 配置中使用上取整：

b(t) = ceil[1 + 3 × (1 + cos(πt / 20)) / 2]

循环 t 为 0 到 19。末轮括号内约 1.018，上取整后为 2；到 t=20 才是 1。因此“末期一个改动”的直觉描述不等于默认循环最后一轮的实际预算。这里是公式代入与源码阅读，不是运行整个系统的测量。schedule.py

同样，读取评分实现应检查失败如何进入分母、成本缺失如何处理。公开代码对缺失 trial 保留评分分母，而 token 成本聚合依赖实际记录到的值；若日志缺失偏向失败运行，平均成本可能产生偏差。复现前需要把 token 覆盖率列为检查项。evaluate.py

论文 GDPval 附录同时出现 185 个任务和每位 judge 204 次比较的叙述，未能直接自洽还原。本文不据此补算置信区间。代码和论文的这些细节说明，公开可读不等于所有测量口径已经消除歧义。

对自我改进系统的实际启示

可以直接借鉴的是实验组织：版本化候选、记录可检验假设、先做泄漏检查、保留失败、同时看分数与成本，最后冻结再测。不能直接借用的是“δ 取这个值便普遍安全”或“同一组正则参数适合所有任务”。

RRSI 主要改善如何搜索 H；它没有把整个科学问题生成、评估标准制定、改进器设计都自动化。下一篇的 AlphaEvolve 进一步展示：当反馈可执行、结果可验证时，自动搜索能在哪里走得很远，以及外层问题定义为何仍然关键。

更新于 2026-10-03 · 研究方法