RRSI

自动研究时间：2026-09-23 09:04（Asia/Shanghai）
来源日期：Hugging Face Daily Papers 页面实际显示 Sep 22，列表最顶部为 RRSI: Regularized Recursive Self-Improvement of Agent Harnesses。¹
研究路径：Daily Papers 列表 -> Hugging Face 详情页 -> arXiv 摘要页 -> arXiv v1 完整 HTML 与 24 页 PDF -> 官方项目页与开源仓库。本文不以列表摘要代替论文正文。

执行摘要

同一个冻结的基础模型，换一套 system prompt、工具描述、控制流、记忆、上下文压缩或子智能体组织方式，表现可以完全不同。于是，近期研究开始让 LLM 根据执行轨迹自动改写自己的 agent harness，并在固定任务集上反复评测、保留高分版本。这是一种发生在智能体系统层面的递归自改进，但它也把经典的自适应过拟合问题带进了软件与提示词搜索：每一轮都看同一批任务，最终选中的 harness 可能只是记住了 benchmark 特征、追逐随机高分，或用更长上下文和更多步骤换来表面提升。

RRSI 的关键观点是：**不必缩小 harness 可编辑空间，但必须约束搜索如何穿过这个空间，以及哪些测得的收益可以永久进入下一轮。**它在 proposal 侧用余弦退火预算限制每个候选能打包的独立修改数，保存所有成功与失败修改的证据，在进展停滞时把少量候选名额引向未探索组件；在 selection 侧先用 critic 拒绝任务名、答案、实体值等 benchmark-specific 逻辑，再用噪声调整后的性能底线、收益—token 成本条件、结构剪枝和域级 guard 决定是否接受候选。²

实验覆盖 8 个 benchmark、3 类任务。每个领域只在一个 evolve benchmark 上搜索，然后把最终 harness 原样迁移到未参与选择的 held-out 或 OOD benchmark。RRSI 在 Terminal-Bench 2.1、Harvey LAB 和 EngDesign 的 evolve 侧分别提升 6.0、1.1 和 4.9 分；在 SWE-bench Verified、Harvey LAB held-out、JobBench、GDPval、APEX-Agents 与 Frontier-Eng 上也全部提升，幅度为 1.8 至 4.7 分。以 agentic workspace 为例，RRSI 的 OOD 平均分为 43.6，未演化 harness 为 39.7，而四种基线平均水平仍接近起点；同时 RRSI 每次 trial 使用 2.42M policy tokens，比无正则演化的 3.80M 少约 36.3%。²

论文最有价值的地方，不是把 $L_0/L_1/L_2$ 名称搬到 agent 上，而是把“高分候选”拆成四个可审计问题：它是否泄漏任务细节、提升是否超过噪声、额外成本是否有足够收益、组件是否持续证明自身价值。消融也显示，拿掉 proposal 或 acceptance 正则都会让 evolve 分数更高、OOD 泛化更差，说明固定测试集上的更大增益可能恰恰是危险信号。

但证据边界同样清楚：主比较集中在同一组 evolve tasks、有限的 policy family 与手工设定超参数；泄漏 critic、分析器和 proposer 多由同一模型家族承担；论文没有给出多随机种子演化的方差，也没有核算搜索阶段的总 token、墙钟时间和费用。RRSI 证明了“正则化搜索过程”是一条可信路线，还没有证明这套具体规则已经是 harness 自改进的通用最优解。

1. 论文基本信息

核心链接：

• Hugging Face 详情页：https://huggingface.co/papers/2609.24972
• arXiv 摘要页：https://arxiv.org/abs/2609.24972
• arXiv 完整 HTML：https://arxiv.org/html/2609.24972v1
• arXiv PDF：https://arxiv.org/pdf/2609.24972
• 官方项目页：https://regularized-rsi.com/
• 开源仓库：https://github.com/google-research/rrsi

2. 背景与动机：Harness 演化为何会“越改越会做题”

2.1 Harness 是模型权重之外的可编程能力层

论文把 agent 写成 $A=(\pi,H)$：$\pi$ 是冻结的 backbone policy，$H$ 是围绕它的 harness。后者不仅是 system prompt，还包括：

• 何时规划、行动、反思和停止的控制流；
• 工具接口、工具说明与错误恢复逻辑；
• skill、memory 与 subagent；
• 上下文选择、压缩和长期任务状态；
• 输出文件、验证流程及任务交付约束。

这一定义很重要。Harness 演化不是在一个固定 prompt 上调几个词，而是在开放的软件系统空间里改源代码和配置。它的表达能力远高于普通超参数搜索，也就更容易对有限评测集形成复杂拟合。

2.2 标准自动演化循环反复消费同一批证据

在第 $t$ 轮，当前 harness $H_t$ 在 evolve set 上运行，轨迹被总结成反馈 $F_t$；proposer 生成若干候选 $\mathcal{H}_t$，再在同一 evolve set 上评测，选择经验分数最高者成为 $H_{t+1}$。

问题不只是数据量有限，而是自适应复用。第 10 轮提出什么，已经依赖前 9 轮在同一任务集上的结果；即使单轮评测无偏，经过多轮候选生成与择优后，胜者偏差也会累积。论文归纳出三条主要失效路径：

1. Benchmark-specific fitting：把任务名、实体、固定值、答案模式或某套 verifier 的偏好写进 harness；
2. Noise chasing：多个随机 rollout 中偶然高分的候选被固化，随后又成为下一轮搜索起点；
3. Complexity accumulation：更多上下文、调用、工具和步骤提升 evolve 分数，却没有形成可迁移机制。

这解释了为什么 prior method 常在 evolve split 上明显变好，换到不同任务说明、工具表面或 verifier 后收益缩小甚至转负。Harness 的改动是真的，能力泛化却未必是真的。

2.3 真正目标是“可迁移机制”，不是最高 evolve 分

RRSI 不把 OOD benchmark 放进搜索目标，也没有训练一个泛化预测器。它选择更保守的目标：让进入永久状态的修改更简单、更可归因、更少依赖 benchmark 细节，并要求额外推理成本由可测收益支付。

这个目标也改变了如何读实验：若一种方法在 evolve split 得分最高，却在 OOD 上不如低 evolve 分方法，前者不是被“压制了潜力”，而可能只是更充分地利用了固定评测集。

3. 核心贡献

3.1 把 harness 演化明确为自适应过拟合问题

论文将 agent-system RSI 与 adaptive data analysis 联系起来：反复查看同一有限样本并据此改变下一次查询，会使普通经验最优失去泛化保证。这个视角比“再设计一个更强 proposer”更基础，因为它指出失败可能来自选择制度，而不是生成能力不足。

3.2 保持开放编辑空间，只正则化搜索轨迹

RRSI 允许 prompt、control flow、configuration、context management、tool、skill、memory 和 subagent 被添加、修改或删除。约束作用在每轮转移 $H_t\rightarrow H_{t+1}$，而不是事先规定只能调 prompt 或只能改某几个参数。

3.3 同时约束 proposal 与 selection

Proposal 正则回答“本轮可以试多少、应把搜索预算花在哪里”；selection 正则回答“哪些测得收益足够可靠，值得变成永久状态”。消融表明只做一侧都不够：生成候选的分布和保留候选的规则共同决定过拟合程度。

3.4 用跨 benchmark、跨 policy 与成本证据评估泛化

论文没有只留出同分布任务，而是将演化后的 harness 迁移到 task format、tool interface 和 verifier 均不同的 benchmark，并补充两种 policy family 的独立演化、向未参与搜索的更小模型迁移、token cost 与 trajectory length 分析。

4. 方法：如何正则化递归 Harness 搜索

4.1 形式化目标

对任务集 $D$，论文同时度量性能与策略 token 成本：

其中 $r$ 可以是单元测试结果、规则评分或 LLM-as-a-judge，$c(\tau)$ 是轨迹消耗的 policy tokens。实际选择依赖有限次数 trial 得到的 $\hat J$ 与 $\hat C$，因此 RRSI 的规则围绕经验噪声、结构复杂度和成本变化设计。

4.2 Proposal 侧一：余弦退火的编辑稀疏度

无约束 proposer 可以在一个候选中同时改提示词、上下文、工具、memory 和控制流。即使分数提升，也很难知道是哪项机制有效。RRSI 给每个候选设置“独立可归因编辑数”预算：

早期预算大，允许组合修改探索新机制；晚期逐渐降到 1，迫使搜索用更小、更可归因的改动收敛。论文将其称为 $L_0$-style cardinality constraint，但明确强调这只是功能类比：编辑池每轮都会变化，并没有在固定连续参数向量上优化 $L_0$ 目标。

三类任务的初始预算分别为 4、3、4，最终都降为 1。这样做的核心不是“修改越少越好”，而是让后期每个胜负结果能提供更清晰的因果线索。

4.3 Proposal 侧二：跨轮证据记账

每个被测 atomic edit 都记录：

• 修改的组件类型；
• 要验证的 hypothesis；
• source diff；
• 性能变化 $\Delta J$；
• 成本变化 $\Delta C$；
• 是否被接受并进入 incumbent 路径。

后续 proposer 不只看上一轮赢家，也会看到被拒绝机制的负证据。被反复证伪的 hypothesis 不应换种说法再次消耗评测预算；真正有效的机制则保留显式 credit。相比只总结“当前失败轨迹”，这更接近一份可审计的实验日志。

4.4 Proposal 侧三：停滞时做结构化探索

若最近 $w$ 轮的进展没有超过经验噪声带 $\delta$，系统判定搜索停滞。此时保留少量 candidate slot，专门尝试尚未被实测的组件类型，而不是继续在熟悉的 prompt rewrite 上局部爬山。

论文把这类机制与 diversity/entropy regularization 类比，但它不是随机追求差异：探索仍受编辑预算约束，并由历史记录指出哪些组件“未尝试”。主实验的 stall window 均为 3，每轮保留 1 个 exploratory proposal。

4.5 Selection 侧一：评测前先做泄漏审查

候选进入完整评测前，critic 阅读 diff，拒绝：

• 任务名、实体名、固定 task-specific value；
• 答案或只服务于 evolve benchmark 的分支逻辑；
• 没有实际作用的 inert machinery；
• 其他把有限任务模式直接编码进 harness 的修改。

这一步必须发生在打分前。若先评测再过滤，泄漏候选的高分已经可能影响分析器、搜索历史和后续 proposal；前置筛查能避免被污染的 fitness signal 进入递归循环。

4.6 Selection 侧二：噪声调整后的性能底线

演化前先重复评测未修改的 $H_0$，估计经验噪声带 $\delta$。设历史最好 evolve 分为 $J^*$，候选必须满足：

这不是要求每轮都显著超过 incumbent，而是防止连续接受多个“各自只差一点、可能落在噪声内”的回退，最终让 harness 在多轮随机波动中逐步下坡。三类实例的 $\delta$ 分别为 0.017、0.004 和 0.020，由 base harness 的重复评测校准。

4.7 Selection 侧三：收益必须为额外成本买单

定义候选相对当前 harness 的性能变化与相对 token 成本变化：

当 $\Delta J>\delta$ 时，候选还必须满足：

$\beta_0$ 表示近乎没有性能收益时仍可容忍的基础成本增长，$\beta_1$ 决定更大收益能换取多少额外 token。作者将它称为 Ridge/$L_2$-style shrinkage：约束总体资源膨胀，但不要求删除某个特定组件。同样，这是一种工程类比，不是平方范数正则。

当变化落在噪声带内，系统改用 shaped admissibility rule，综合小幅得分变化、成本下降和此前未进入 winning edit 的结构组件新颖度。编码实例令小幅分数变化的权重为 0，因此噪声带内的“微涨”不能单独让候选过关，必须由降本或结构新颖性提供理由。

4.8 Selection 侧四：让无效组件失去永久居留权

RRSI 在最近 pruning window 中跟踪组件是否带来严格正收益。已被尝试但没有近期正贡献的组件进入删除候选集，由后续 proposer 提出移除方案。论文将它称为 Lasso/$L_1$-style structural pruning，因为它鼓励离散结构稀疏化，而不是只降低整体成本。

编码、workspace、engineering 的 pruning window 分别为 4、4、5。工程设计域还加了非补偿 guard：若 valid-output rate 相对 incumbent 下降超过 0.03，或 no-submission rate 上升超过 0.02，即使主分数提高也拒绝。这避免主目标收益掩盖基本执行可靠性恶化。

4.9 一轮 RRSI 的完整决策链

1. 当前 harness 在 evolve set 上运行，analyst 汇总失败与跨轮证据；
2. 根据退火预算、已尝试组件、停滞状态和 pruning target 生成候选；
3. critic 在评测前筛掉泄漏或无效修改；
4. 通过筛查的候选并行执行，得到性能与 policy-token 成本；
5. 依次检查历史最好分底线、成本规则、噪声带内规则与域级 guard；
6. 在所有 admissible candidates 中选择经验分最高者；若没有候选合格，保留 incumbent；
7. 将每个 edit 的 hypothesis、diff、测量值和 verdict 写回历史，进入下一轮。

官方实现将每个候选放进独立 Git worktree；接受候选相当于把 domain 的 evolve branch 快进到该提交。每轮生成两个候选，原始 trial、frontier 和 edit history 都保留在运行目录中，增强了可追溯性。⁴

5. 实验设计

5.1 三个演化入口、六个未见评测面

这里的 OOD 不只是换一批同格式题目。SWE-bench 要修复真实 GitHub issue；JobBench 需要检索与专业交付；GDPval 与人类专家交付物比较；APEX-Agents 提供不同 MCP 世界；Frontier-Eng 涵盖 26 类工程优化问题。最终 harness 在这些评测上保持不变，分数不会反馈给演化循环。

5.2 基线与公平条件

论文比较未演化的 $H_0$ 与四种近期 harness evolution 方法：

• Meta-Harness：把 executable harness code 作为外层优化对象，利用历史 source、score 与 trace 提案；
• AHE：以 observability 为核心组织组件、执行经验和 edit outcome；
• TTHE：在 test-time adaptation 阶段维护并选择可持续的候选 harness；
• HarnessX：用 typed primitives 组合 prompt、tool、memory 与 control flow，并根据 trace 演化。

各方法从同一 $H_0$ 出发，使用相同冻结 policy、evolve set 与 candidate budget。主实验中 policy、proposer、analyst 和 critic 使用 Claude Opus 4.8。Coding 起点是 Terminus-2；workspace 与 engineering 使用 ReAct loop、MCP tool gateway、dynamic toolbelt 和 ReSum-style context management 的组合。

5.3 主要超参数

作者声明超参数只依据 evolve environment 与运行考虑选择，held-out/OOD benchmark 不参与调参。这个隔离是正确方向，但由于每个 domain 只有一组设定，仍无法知道方法对阈值变化有多敏感。

6. 主结果：Evolve 收益不最大，迁移收益反而最稳定

6.1 相对未演化 Harness 的完整结果

RRSI 在论文报告的每个 evolve、ID held-out 与 OOD split 上均未回退。尤其是 Frontier-Eng 使用 task-specific simulator 或 evaluator，不依赖 LLM judge；其 +4.3 Medal points、相对提升约 24.3%，减弱了“harness 只是学会讨好 judge 写作风格”的解释。

但表中各 benchmark 的分数语义不同：Harvey LAB 是 criterion pass fraction，GDPval 是相对专家交付物的偏好胜率，Frontier-Eng 是 Medal Score。跨行比较绝对增益大小要谨慎，不能把 +4.7 与 +4.3 当成同一种效果量。

6.2 与四种演化基线的 Workspace 对照

Meta-Harness 的 evolve 分最高，RRSI 却只取得所有 evolved methods 中最小的 evolve 增益；一到 OOD，排序几乎翻转。TTHE 的 OOD 平均甚至比 $H_0$ 低 1.7 分。这正是论文中心论点的直接证据：在被重复查看的 split 上赢得更多，不等于产生了更通用的 agent 机制。

7. 消融、跨模型迁移与成本

7.1 Proposal 与 Acceptance 正则缺一不可

拿掉 acceptance constraints 后，evolve 分从 90.5 升到 91.5，OOD 平均却从 43.6 降到 41.0，token 成本上升约 48%。拿掉 proposal constraints，evolve 只多 0.2，OOD 少 1.7。全部去掉时 evolve 最高，OOD 只比 $H_0$ 高 0.6，且成本最大。

这组结果支持两个判断：selection 规则主要防止噪声与昂贵修改被固化；proposal 规则即使不直接拒绝候选，也会改变搜索看到的机制分布。它们的作用不是简单叠加“惩罚项”，而是共同改变递归路径依赖。

7.2 不同 Policy Family 都能从中受益

在 coding domain 中独立运行搜索：

这说明方法不只适用于一个 backbone family。更强的 Claude 起点接近天花板，留下的绝对提升空间更小；Gemini 的 evolve 提升更大，但 OOD 仍只有 +2.2，也再次显示训练侧收益会明显衰减。

7.3 Harness 还能迁移到未参与搜索的更弱模型

将 Gemini 3.5 Flash 演化出的 coding harness 原样交给 Gemini 3.1 Flash Lite，Terminal-Bench 从 11.2 提升到 14.6，即 +3.4 分、相对约 +30.4%。这支持 harness 中确实包含部分 policy-independent 机制，而不仅是搜索模型专用 prompt trick。

但绝对分依然很低，说明 harness 不能凭空补足基础模型能力。对本来不可达的任务，更好的工作流也无从创造缺失的推理与编码能力。

7.4 RRSI 更省，但仍比原始 Harness 昂贵

在 workspace evolve split 上，RRSI 每 trial 使用 2.42M policy tokens、平均 26.3 steps。四种 prior method 均更贵且 OOD 更差；AHE 达到 3.82M tokens，比 RRSI 多约 58%，OOD 平均低 4.4 分。

不过，$H_0$ 只使用 1.56M tokens 和 21.2 steps。RRSI 相对 $H_0$ 仍增加约 55.1% token 与 24.1% steps。准确结论是“RRSI 是被比较的 evolved harness 中最轻”，不是“演化后更便宜”。其工程价值取决于额外 OOD 成功率能否覆盖长期推理成本。

7.5 具体决策案例揭示规则如何工作

论文附录给出四个有代表性的候选：

• Coding R0-A 增加有界的提交前验证与长任务非阻塞轮询指导，evolve +3.93，接受；
• Coding R0-B 看似相似，但只提升 +1.69，同时增加 26.1% 成本，被成本规则拒绝；
• Coding R8-B 让 completion gate 重新检查原始要求，成本下降 13.6%，但性能 -2.81，因跌破稳定底线而拒绝；
• Engineering R2 增加对 “workdir must be an existing directory” 错误的通用恢复提示，从 122/244 增至 128/244 passes，只增 1.6% tokens，因此接受。

这些案例说明 RRSI 既不机械偏好降本，也不机械偏好加验证步骤。性能底线是非补偿条件；只有在不破坏可靠性的前提下，成本与新颖性才参与权衡。

8. 如何理解 RRSI 的关键机制

8.1 它正则化的是搜索过程，不是最终 Harness 的静态大小

最终 harness 可以包含复杂的工具、memory 和 subagent。RRSI 限制单轮修改量、要求复杂度有收益依据，并剪掉近期无效结构，但没有直接最小化源代码行数或组件总数。一个较大但持续有效的结构仍可保留。

8.2 “证据记账”比单轮反思更接近科学实验

普通 self-reflection 常把上一轮失败压缩为自然语言，然后重新提案；长期运行后，系统容易遗忘哪些机制已测试、为何失败。RRSI 将 component、hypothesis、diff、score、cost 和 verdict 结构化保存，使负结果也成为下一轮的输入。对自动研究、自动代码优化和长期 agent 运维，这可能比某条具体阈值公式更可复用。

8.3 泄漏筛查与 OOD 评测承担不同角色

Critic 在搜索过程中阻止明显 benchmark-specific logic；OOD benchmark 在搜索结束后检查仍未被 critic 识别的隐性拟合。前者是预防控制，后者是外部审计。只做 critic 无法证明泛化，只做 OOD 测试又无法阻止污染信号改变整个演化路径。

8.4 Token 是可操作的复杂度代理，但不是完整成本

Policy tokens 容易跨候选测量，也与推理价格、时延大致相关，因此适合进入 acceptance rule。但它忽略：

• tool server、浏览器、容器与 simulator 的计算；
• 并发峰值和外部 API 调用；
• wall-clock latency；
• proposer、analyst、critic 和候选评测的搜索期成本；
• harness 可维护性与安全审查负担。

生产系统可将 $C$ 扩展为多维资源向量，或设置不可补偿的时延、权限和失败率 guard，而不必照搬 token 单指标。

8.5 OOD 全面上涨比单个大增益更重要

论文最大 evolve 增益为 +14.1，最大 OOD 增益只有 +4.7。若只看峰值，效果似乎缩水；若看覆盖面，则 6 个未参与选择的 split 全部上涨，没有发生基线方法常见的负迁移。对部署而言，减少未知环境中的回退概率，往往比在已知 benchmark 上再挤出几分更重要。

9. 局限与批判性分析

9.1 缺少多次完整演化的随机性报告

Harness 评测本身是随机的，proposer 生成、critic 判断和搜索路径也会随机。论文校准了单次评测噪声，却没有报告不同 random seed 下从头运行整条 20 或 40 轮演化的均值、方差和成功率。单条路径上的优势可能高估方法稳定性。

9.2 超参数仍然用有限 Evolve Set 决策

$\delta$、编辑预算、pruning window、$\beta_0$、$\beta_1$ 和 novelty 权重都影响哪些候选能生存。作者没有使用 OOD 数据调参，这是必要隔离；但“只用 evolve environment 与 operational considerations”依然可能形成高层级人工适配。更强证据应展示阈值敏感性，或在新 domain 上零调参迁移。

9.3 搜索角色的模型同源性可能产生共同盲点

主实验中 proposer、analyst、critic 与 frozen policy 都是 Claude Opus 4.8。Critic 可能无法识别 proposer 同模型家族生成的隐性 shortcut；analyst 也可能以相似方式解释失败。使用异构 critic、静态规则、语义 diff 检查和人类抽审，能降低共同失效风险。

9.4 “泄漏”定义依赖可读 Diff，难覆盖行为级投机

任务名和固定值容易发现，但更隐蔽的过拟合可能表现为工具调用顺序、输出风格、对 verifier 偏好的利用或上下文选择策略，并不出现明显字符串。跨 benchmark 结果提供了一定反证，却不能保证 critic 本身具有高 recall。

9.5 基线全面对照主要集中在 Workspace

四种 prior method 的完整表格出现在 agentic workspace。Coding 和 engineering 展示 $H_0$ 到 RRSI 的提升，却没有同等完整的四基线 OOD 对照。因而“RRSI 在所有领域都优于所有 harness evolution baseline”超出了论文直接证据。

9.6 搜索成本没有闭环核算

每轮两个候选，要在完整 evolve set 上多次运行；另有 proposer、analyst、critic 和失败重试。最终 harness 的 2.42M tokens/trial 只回答部署期成本，未回答找到它花了多少。若 harness 生命周期短、backbone 更新快，演化成本可能来不及摊薄。

9.7 Judge-based 与确定性评测各有剩余风险

Harvey LAB、JobBench、GDPval 和 APEX-Agents 在不同程度上依赖 LLM judge，可能受输出风格与模型偏好影响。EngDesign 与 Frontier-Eng 的冻结 simulator 提供了重要互补，但工程 benchmark 规模较小，且 Frontier-Eng 只有 38/47 tasks 实际贡献 credit。跨域证据扎实，但仍不是无限开放世界验证。

9.8 与经典范数正则的对应主要是解释框架

编辑 cardinality、结构删除和总成本约束分别被称为 $L_0/L_1/L_2$-style。论文自己也明确承认，它们不是同一连续参数空间上的范数惩罚。读者不应把这些命名理解为已有理论保证；真正有效的是具体 gate、history 和 pruning procedure，需要以实验而非类比证明。

9.9 冻结权重结论不能直接外推到联合自改进

RRSI 只改变 harness，不更新 backbone weights。若系统同时做 RL、SFT 或 memory consolidation，数据分布、policy 行为和成本会一起变化，固定噪声带与历史 credit 可能失效。论文回答的是 harness-level RSI，不是完整的自我改写模型安全问题。

10. 应用影响

10.1 为生产 Agent 建立“改动准入制”

团队可以把每次 prompt、tool、memory 或 control-flow 优化视为候选变更，要求通过：泄漏检查、重复评测噪声带、成本预算、可靠性 guard 与 held-out canary。这样，agent tuning 从凭感觉改 prompt 变成类似软件发布的 evidence gate。

10.2 让自动优化器保留失败知识

跨轮 edit ledger 可用于自动研究、数据库调优、编译器 pass 搜索和工作流优化。系统不仅保存 winner，还保存“哪个 hypothesis 在什么版本、什么成本下失败”，避免昂贵实验被后续 agent 遗忘。

10.3 用低能力模型验证 Harness 机制是否真正可复用

若一个改动只对搜索时的 frontier model 有效，可能是 model-specific prompt artifact。把最终 harness 交给不同 family 或更弱模型，是低成本的机制审计。不能提升不代表修改一定无用，但能帮助区分通用工作流与特定模型偏好。

10.4 将成本、安全和可靠性做成非补偿约束

真实部署不能允许准确率小涨抵消权限扩大、敏感工具误用或严重时延。RRSI 的 domain guard 思路可扩展为：

• 禁止新增高风险网络或文件权限；
• 任务成功率提高也不得降低审计日志完整性；
• no-submission、crash、invalid-output 和人工升级率不得越界；
• P95 latency、美元成本和外部工具失败率分别设硬门槛。

10.5 将 OOD 回归集从“最终展示”变成治理资产

RRSI 的结果提醒团队，优化集与审核集必须制度性分离。若 OOD 分数被反馈给 proposer，它很快也会变成新的 evolve set。生产流程需要轮换 canary、限制查询次数、记录谁看过哪些结果，并定期引入全新任务表面。

11. 相关工作与定位

11.1 自动 Harness 演化

Meta-Harness、AHE、TTHE、HarnessX、AutoHarness、Self-Harness、Continual Harness 和 DarwinX 等工作都让 LLM 根据轨迹与评分改写 agent scaffold。它们证明自动改 prompt、code、tool、memory 或 control flow 可以提升任务分数。RRSI 的差异不在编辑对象，而在谁有资格成为下一轮永久状态。

11.2 Harness 泛化与归因

Evo-Bench、EvoHarnessBench、HarnessCompass 以及 harness delta attribution 等研究开始区分 evolve benefit、held-out transfer 与可归因机制。RRSI 延续这条路线，进一步把 proposal history、leakage、noise、cost 和 pruning 放入同一个运行时选择框架。

11.3 Agent 递归自改进

Darwin Gödel Machine、RSI-Exam、NeoHorse、SkillRL、MetaClaw、Agent0 等探索 agent 如何修改代码、技能、训练或 routing harness。RRSI 将问题收窄到冻结权重的 harness-level RSI，并强调：自我修改能力越开放，越不能只依赖同一有限 fitness signal 贪心选择。

11.4 自适应数据分析与多次比较

论文援引 adaptive data analysis 中关于 holdout reuse 的理论直觉。RRSI 没有给出形式化泛化界，但其 noise floor、历史记账和保守准入，本质上是在工程上应对 repeated selection 与 winner’s curse。未来可进一步引入 sequential testing、置信序列或受控隐私噪声，为接受规则提供统计保证。

12. 结论

RRSI 把 agent harness 自动演化中最容易被忽略的问题放到了中心：当系统反复根据同一批任务改写自己时，“变高的分数”既可能是能力，也可能是对 benchmark、噪声和计算预算的拟合。

它给出的答案不是封闭编辑空间，而是建立一套更保守的演化制度：单轮少改、跨轮记账、停滞时有结构地探索；在候选打分前筛泄漏，在接受前检查历史性能底线与成本，在长期运行中删除无法证明价值的结构。实验中，RRSI 主动放弃最大的 evolve-set 增益，换来了 6 个未参与选择的评测面全部提升，以及相对无正则演化更低的部署 token 成本。

对研究者，这篇论文的重要性在于把 harness evolution 从“LLM 自动写更好的 agent”推进到“如何证明每次自我修改值得保留”。对工程团队，最可落地的原则是：任何自动优化系统都应把失败证据、评测噪声、资源成本和未见任务迁移视为一等状态，而不是只保存当前最高分版本。

参考资料