主页
让 Agent Harness 自己进化,却不让它刷题刷崩:RRSI 拆解
Letting Agent Harnesses Self-Evolve Without Letting Them Game the Test: Inside RRSI
2026 年 9 月 21 日,Google Cloud AI Research 联合 Stanford、UNC-Chapel Hill、Washington University in St. Louis 等机构提交了论文《RRSI: Regularized Recursive Self-Improvement of Agent Harnesses》。它解决的是一个很具体、很多做 Agent 平台的团队都撞过的问题:让 Harness(提示词、控制流、工具、记忆管理这一整套"脚手架")自动迭代进化,几乎总能在你拿来打分的那个评测集上一路涨分——可一换成没见过的新任务,分数就塌了。RRSI 给这套自动进化流程加了一整套正则化约束,让"在评测集上进步"和"换个任务也真的更好用"这两件事,第一次在多个基准上同时成立。
On September 21, 2026, a team from Google Cloud AI Research — together with Stanford, UNC-Chapel Hill, and Washington University in St. Louis — submitted "RRSI: Regularized Recursive Self-Improvement of Agent Harnesses." It tackles a very specific problem that plenty of teams building agent platforms have already hit: let a harness (the whole scaffolding of prompts, control flow, tools, and memory management) evolve itself automatically, and it will almost always climb the score on whatever evaluation set you're using to grade it — then collapse the moment you point it at an unseen task. RRSI wraps that automated-evolution loop in a full set of regularization constraints, and is the first work to make "improving on the evolve set" and "actually being better on new tasks" hold true at the same time, across multiple benchmarks.
01 · 30 秒版本
01 · The 30-Second Version
🎯开篇速览Overview
Agent 能不能干好活,一半靠模型本身,另一半靠 Harness——也就是围绕模型搭的那套提示词、控制流、工具接口、上下文管理、记忆和子代理配置。人工调 Harness 很慢,于是最近一批工作让 Harness 自己进化:每一轮生成若干候选修改,拿去在一个固定评测集(evolve set)上打分,留下分数最高的那版,循环往复。问题是,这个循环天然会滑向"死记硬背":候选方案越来越针对这个具体评测集的题目特征做优化,而不是真的把 Agent 变强——论文把这叫 适应性过拟合(adaptive overfitting)。
How well an agent performs is half about the backbone model and half about the harness — the prompts, control flow, tool interfaces, context management, memory, and subagent configuration built around that model. Tuning a harness by hand is slow, so a recent line of work lets the harness evolve itself: each round generates candidate edits, scores them against a fixed evaluation set (the evolve set), and keeps the highest scorer, round after round. The problem is that this loop naturally drifts toward rote memorization: candidates get increasingly tuned to the quirks of that specific evolve set rather than genuinely making the agent better — the paper calls this adaptive overfitting.
RRSI(Regularized Recursive Self-Improvement)的做法不是"少进化几轮"这种粗暴限流,而是在提案(proposal)和选择(selection)两个阶段分别加正则约束——前者管"每一步能改多少、怎么改",后者管"改完之后,凭什么留下来"。作者在编码、办公 Agent、工程设计三大类共 8 个基准上验证:分布外(OOD,没见过的新任务)平均提升 3.9 分,是所有对比方法里唯一 OOD 收益为正且稳定的;同时策略 token 用量比不加正则的版本少 30%。
RRSI's (Regularized Recursive Self-Improvement) approach isn't a blunt instrument like "just run fewer rounds." Instead, it adds regularization at both the proposal and selection stages — the former governs how much can change per step and how, the latter governs what earns the right to survive. The authors validate this across 8 benchmarks in three domains — coding, agentic workspace, and engineering design — and see a 3.9-point average gain out-of-distribution (OOD, on unseen tasks), the only method among all baselines with a positive and stable OOD gain, while using 30% fewer policy tokens than the unregularized version.
如果你在做任何"让 Agent 自动变强"的流水线——不管是自动调 prompt、自动挑工具组合,还是自动进化 skills/subagents——RRSI 给出的不是一个具体产品,而是一套可以直接搬过去用的设计模式:怎么设计"退火式"的改动预算、怎么设一个防刷分的验收门槛、怎么判断该剪掉哪些没用的历史遗留组件。
If you're building any pipeline that automatically makes an agent better — auto-tuning prompts, auto-selecting tool combinations, or auto-evolving skills and subagents — RRSI isn't a product to adopt, it's a design pattern you can port directly: how to design an annealed edit budget, how to set an anti-gaming acceptance bar, and how to decide which stale legacy components to prune.
02 · 问题从哪来
02 · Where the Problem Comes From
🧩背景:Harness 为什么要"自己进化"Background: Why Harnesses Self-Evolve
同一个底层模型,换一套 Harness,任务成功率能差出十几个百分点——这在生产环境里已经是共识。但 Harness 的搜索空间很大:提示词怎么写、要不要加规划步骤、上下文该怎么裁剪、工具描述精简到什么程度、要不要拆子代理……人工试错的成本随维度数量指数上升。于是出现了一批"让 Harness 自己进化"的方法(论文里对比的 Meta-Harness、AHE、TTHE、HarnessX 都是这类),整体框架都类似:
The same backbone model can swing performance by ten-plus percentage points depending on the harness wrapped around it — that much is already common wisdom in production settings. But the harness search space is large: how to phrase prompts, whether to add planning steps, how to trim context, how terse tool descriptions should be, whether to split out subagents — and manual trial and error scales exponentially with the number of dimensions. This spawned a family of "let the harness evolve itself" methods (the paper's baselines — Meta-Harness, AHE, TTHE, HarnessX — all belong to this family), sharing roughly the same framework:
- 拿一个基线 Harness H₀,在一个固定的评测集 D_evolve 上跑出基线分数;
- 让一个"提案器"(可以是另一个 LLM)基于历史结果,生成若干候选修改 H';
- 把候选在 D_evolve 上重新打分,选出分数最高的一版作为下一轮的 H;
- 重复 N 轮,直到收敛或达到预算上限。
- Start from a baseline harness H₀ and score it on a fixed evaluation set D_evolve;
- Have a "proposer" (often another LLM) generate candidate edits H' based on the history so far;
- Re-score the candidates on D_evolve and keep whichever scores highest as the next round's H;
- Repeat for N rounds until convergence or the budget runs out.
这个循环的致命伤在于:D_evolve 是有限且固定的,而候选是反复针对它打分、反复针对它调整的。论文把由此产生的三种失效模式概括为:
The fatal flaw in this loop is that D_evolve is finite and fixed, while candidates are repeatedly scored against it and repeatedly tuned to it. The paper summarizes the resulting failure modes into three patterns:
候选修改里悄悄编码了具体任务名、实体名或评测集特有的判分逻辑——离开这个评测集就毫无意义。
Candidates quietly encode specific task names, entity names, or eval-set-specific scoring logic — meaningless the moment you leave that eval set.
评测集本身有随机波动,系统会把这种波动误当成"真实提升"去追,不断做无意义的微调。
The eval set has inherent random variance, and the system mistakes that variance for genuine improvement, chasing it with meaningless micro-tweaks.
每轮都倾向于"加点东西"而不是"删掉没用的东西",Harness 越滚越臃肿、越跑越贵、越难维护。
Every round tends to add rather than remove, so the harness snowballs into something bloated, expensive to run, and hard to maintain.
以上三点叠加的结果:evolve 集分数一路走高,换成没见过的新任务,分数反而可能低于没进化过的基线 H₀。
The compound result of the above: evolve-set scores keep climbing while scores on unseen tasks can actually fall below the un-evolved baseline H₀.
03 · 拆开来看
03 · Under the Hood
⚙️机制拆解:双侧正则化怎么运作Mechanism: Dual-Side Regularization
RRSI 的核心洞察是:正则化管的是"搜索轨迹",不是"能改哪些东西"。可编辑的 Harness 组件词表依然很宽——prompt(提示词)、control_flow(控制流)、config(配置)、context_mgmt(上下文管理)、client_tool(客户端工具)、skill(技能)、memory(记忆)、subagent(子代理)——RRSI 不缩小这个范围,而是约束"每一步能走多远"和"凭什么算数"。具体拆成提案侧三条、选择侧三条,共六道关卡:
RRSI's core insight is that regularization governs the search trajectory, not the scope of what can be edited. The editable harness component vocabulary stays wide — prompt, control_flow, config, context_mgmt, client_tool, skill, memory, subagent — RRSI doesn't shrink that scope; it constrains how far each step can go and what earns the right to count. Concretely, that's three gates on the proposal side and three on the selection side, six in total:
提案侧:管"怎么改"
Proposal Side: Governing "How to Edit"
- 退火式编辑稀疏度:每轮允许改动的数量(edit budget)随进化轮数用余弦退火从 b_max(早期,可一次性打包 3-4 处关联改动)降到 b_min = 1(后期,只允许单点、可归因的改动)——早期允许探索,后期强制克制。
- 证据感知的信用归因:完整记录每次改动涉及的组件、提出的假设、对应的代码 diff、带来的分数/成本变化、是否被采纳——防止反复提出已经被证伪过的同一个假设。
- 结构化探索:当进步在噪声容忍带 δ 内连续停滞 w 轮时,系统会主动把提案配额让给"词表里还没试过的组件",而不是继续在已经收益递减的地方内卷。
- Annealed update sparsity: the per-round edit budget follows a cosine-annealed schedule from b_max (early rounds, allowing 3-4 bundled related edits at once) down to b_min = 1 (late rounds, single attributable edits only) — exploration early, forced restraint late.
- Evidence-aware credit assignment: keeps a full history of which component each edit touched, the hypothesis behind it, the corresponding code diff, the resulting score/cost change, and whether it was accepted — preventing the same already-falsified hypothesis from being re-proposed.
- Structured exploration: when progress stalls within an empirical noise band δ for w consecutive rounds, the system reserves proposal capacity for untried components in the vocabulary instead of continuing to squeeze diminishing returns from an already-exhausted area.
选择侧:管"凭什么留下"
Selection Side: Governing "What Earns Survival"
- 泄漏筛查:一个"批评者(critic)"角色在正式评分前,先拦截编码了具体任务名、实体名、评测特化逻辑或无实际作用的冗余机制的候选。
- 噪声地板接受:候选分数 Ŝ(H′) 必须满足 Ŝ(H′) ≥ S★ − δ(S★ 是历史最佳分,δ 是经验校准的噪声容忍度)——差距在噪声范围内的"伪提升"直接被挡在门外。
- 复杂度感知接受(岭回归式 L2):若提升超出噪声容忍(ΔS > δ),相对成本增幅 ΔC 必须满足 ΔC ≤ β₀ + β₁ΔS——涨分必须配得上多花的资源,杜绝无节制堆料。
- 结构化剪枝(Lasso 式 L1):在一个剪枝窗口 n_prune 轮内持续没有正向实测收益的组件会被直接移除——每个组件都要不断"挣回"自己留在 Harness 里的资格。
- Leakage screening: a "critic" role intercepts candidates that encode specific task names, entity names, benchmark-specific logic, or inert padding mechanisms before formal scoring even happens.
- Noise-floor acceptance: a candidate's score Ŝ(H′) must satisfy Ŝ(H′) ≥ S★ − δ (S★ being the best observed score, δ an empirically calibrated noise tolerance) — "gains" within the noise band are simply turned away at the door.
- Complexity-aware acceptance (ridge/L2-style): for gains exceeding the noise tolerance (ΔS > δ), the relative cost increase ΔC must satisfy ΔC ≤ β₀ + β₁ΔS — a score bump has to justify the extra resources it costs, blocking unchecked bloat.
- Structural pruning (Lasso/L1-style): components with no positive measured gain over a pruning window of n_prune rounds are removed outright — every component has to keep earning its place in the harness.
04 · 先把词认全
04 · Know the Terms
📖术语表Glossary
围绕模型搭建的整套脚手架:提示词、控制流、工具接口、上下文管理、记忆、子代理配置的集合,决定同一个模型能不能把活干好。
The full scaffolding built around a model: prompts, control flow, tool interfaces, context management, memory, and subagent configuration — determines whether the same model can actually get work done.
进化循环里用来给候选 Harness 打分的固定评测集,被反复、适应性地重复使用。
The fixed evaluation set used to score candidate harnesses in the evolution loop, reused repeatedly and adaptively.
没有出现在 evolve set 里、Harness 进化过程中从未见过的新任务/新基准,用来检验进化成果是否真实可迁移。
Tasks or benchmarks never seen during harness evolution, absent from the evolve set — used to check whether evolution gains genuinely transfer.
因为反复针对同一个有限评测集打分和调整,候选方案越来越"懂评测集的题型"而非"懂任务本身"的现象。
The phenomenon where repeated scoring and tuning against the same finite eval set makes candidates increasingly attuned to that set's quirks rather than to the task itself.
每一轮允许提案器同时改动的组件数量上限,RRSI 中随轮数从 b_max 余弦退火到 b_min = 1。
The cap on how many components the proposer may change in a single round; in RRSI it cosine-anneals from b_max down to b_min = 1 as rounds progress.
一个经验校准的容忍区间 δ,分数提升若落在这个区间内会被视为噪声而非真实进步,直接拒绝。
An empirically calibrated tolerance band δ; a score gain that falls inside it is treated as noise rather than genuine progress and is rejected outright.
Harness 在实际跑任务(而非进化过程本身)时,每次试验消耗的 token 数量,用来衡量进化出的 Harness 本身是否臃肿低效。
The number of tokens the evolved harness consumes per trial when actually running tasks (not during evolution itself) — a measure of whether the resulting harness is bloated or efficient.
选择侧的 L1 式正则:在设定窗口内持续没有正向实测收益的 Harness 组件会被主动移除,防止复杂度只增不减。
An L1-style selection-side regularizer: harness components with no positive measured gain within a set window are actively removed, preventing complexity from only ever growing.
05 · 数字怎么说
05 · What the Numbers Say
📊实验结果:数字说了什么Results: What the Numbers Say
作者在三大领域共 8 个基准上评测:编码(evolve 用 Terminal-Bench 2.1 的 89 个容器化 shell 任务,OOD 用 SWE-bench Verified 的仓库级修 bug 任务)、办公 Agent(evolve 用 Harvey LAB 的 120 个法务任务,40 个同分布留出;OOD 用 JobBench、GDPval、APEX-Agents)、工程设计(evolve 用 EngDesign 的 61 个可确定性仿真评分的任务,OOD 用 Frontier-Eng 的 47 个真实优化问题)。
The authors evaluate across 8 benchmarks in three domains: coding (evolve on Terminal-Bench 2.1's 89 containerized shell tasks, OOD on SWE-bench Verified's repository-level bug fixes), agentic workspace (evolve on Harvey LAB's 120 legal-work tasks with 40 in-distribution held out; OOD on JobBench, GDPval, APEX-Agents), and engineering design (evolve on EngDesign's 61 deterministic-simulation-graded tasks, OOD on Frontier-Eng's 47 real-world optimization problems).
| 领域 | 同分布(ID)提升 | 分布外(OOD)提升 |
|---|---|---|
| 编码 | +6.0 分(Terminal-Bench 2.1) | +1.8 分(SWE-bench Verified) |
| 办公 Agent | +1.1 分(Harvey LAB evolve) | +3.5 ~ +4.7 分(JobBench/GDPval/APEX) |
| 工程设计 | +4.9 分(EngDesign) | +4.3 分(Frontier-Eng 奖牌分) |
| 策略 Token 用量 | 2.42M / 试验,较无正则版本(3.80M)减少 30% | |
| Domain | In-Distribution (ID) Gain | Out-of-Distribution (OOD) Gain |
|---|---|---|
| Coding | +6.0 pts (Terminal-Bench 2.1) | +1.8 pts (SWE-bench Verified) |
| Agentic Workspace | +1.1 pts (Harvey LAB evolve) | +3.5 to +4.7 pts (JobBench/GDPval/APEX) |
| Engineering Design | +4.9 pts (EngDesign) | +4.3 pts (Frontier-Eng Medal score) |
| Policy tokens / trial | 2.42M, a 30% reduction from the unregularized version's 3.80M | |
消融实验:每一道关卡都在起作用
Ablation: Every Gate Is Pulling Its Weight
| 配置 | OOD 平均分 | Token / 试验 |
|---|---|---|
| 完整 RRSI | 43.6 | 2.42M |
| 去掉选择侧正则 | 41.0 | 3.59M |
| 去掉提案侧正则 | 41.9 | 2.69M |
| 完全不加正则(evolve 分反而最高,92.8) | 40.3 | 3.80M |
| Configuration | OOD Average | Tokens / Trial |
|---|---|---|
| Full RRSI | 43.6 | 2.42M |
| Without selection-side regularizers | 41.0 | 3.59M |
| Without proposal-side regularizers | 41.9 | 2.69M |
| Fully unregularized (highest evolve score, 92.8) | 40.3 | 3.80M |
最扎眼的一行是最后一行:完全不加正则的版本在 evolve 集上分数最高(92.8),但换到 OOD 反而是四者里最低的——这正是本文开篇讲的"刷题刷崩"现象的实锤。
The most striking row is the last one: the fully unregularized version scores highest on the evolve set (92.8), yet lands lowest on OOD among all four configurations — hard evidence for exactly the "cramming for the test" failure this piece opened with.
跨模型鲁棒性
Cross-Model Robustness
用 Gemini 3.5 Flash 进化出的 Harness,直接搬到从没见过的 Gemini 3.1 Flash Lite 上跑,尽管后者基线水平低得多,仍然带来 +3.4 分的提升——说明 RRSI 学到的不是"怎么讨好某个具体模型",而是相对通用的结构性改进。
A harness evolved with Gemini 3.5 Flash, transplanted directly onto the never-seen Gemini 3.1 Flash Lite, still delivers a +3.4-point gain despite the latter's much lower baseline — suggesting RRSI learns relatively general structural improvements rather than how to flatter one specific model.
06 · 同类方法怎么选
06 · Choosing Among Peers
⚖️对比选型:同类方法的位置Comparison: Where Peers Stand
| 方法 | 核心思路 | OOD 表现 |
|---|---|---|
| Meta-Harness | 对可执行代码做外层优化(Lee et al., 2026b) | +3.6(次优,但 evolve 集表现好、迁移打折扣) |
| AHE | 基于可观测性驱动进化,显式做失败诊断(Lin et al., 2026a) | −1.1 |
| TTHE | 测试时自适应,维护多个候选 Harness(Nie et al., 2026) | −5.4(四者最差) |
| HarnessX | 模块化、带类型的原语,基于轨迹驱动适配(Chen et al., 2026) | −3.4 |
| RRSI(本文) | 提案侧 + 选择侧双重正则化,约束搜索轨迹而非编辑范围 | +3.9(唯一稳定为正) |
| Method | Core Idea | OOD Performance |
|---|---|---|
| Meta-Harness | Outer-loop optimization over executable code (Lee et al., 2026b) | +3.6 (second-best evolve performance, transfer discounted) |
| AHE | Observability-driven evolution with explicit failure diagnosis (Lin et al., 2026a) | −1.1 |
| TTHE | Test-time adaptation maintaining multiple candidate harnesses (Nie et al., 2026) | −5.4 (worst of the four) |
| HarnessX | Modular, typed primitives with trace-driven adaptation (Chen et al., 2026) | −3.4 |
| RRSI (this paper) | Dual proposal + selection regularization, constrains the search trajectory rather than edit scope | +3.9 (only method stably positive) |
值得注意的是 Meta-Harness:它是四个基线里唯一 OOD 收益也为正的,说明"外层代码优化"这个方向本身不差,只是缺了 RRSI 这种系统性的正则约束——两者更像是互补而非对立,一个提供了强的搜索/优化框架,一个提供了让这个框架不跑偏的约束层。
Meta-Harness is worth flagging: it's the only baseline with a positive OOD gain too, which suggests the "outer-loop code optimization" direction isn't itself flawed — it just lacks RRSI's systematic regularization constraints. The two feel more complementary than opposed: one supplies a strong search/optimization framework, the other supplies the constraint layer that keeps it from drifting.
07 · 落地怎么做
07 · Putting It Into Practice
🛠️怎么用:把思路搬进自己的流水线How To Apply This
RRSI 不是一个能直接 pip install 接入生产的产品,而是一套设计模式。如果你在做类似"自动优化 Agent Harness / Prompt / Skill 库"的系统(哪怕规模比论文小得多),可以按这个顺序搬过来用:
RRSI isn't a product you can pip install into production — it's a design pattern. If you're building something like an automated Agent-harness / prompt / skill-library optimization system (even at a much smaller scale than the paper), here's a rough order to port it in:
- 11 先分清 evolve 集和 OOD 集。哪怕你现在只有一个评测集,也要人为切出一部分完全不参与进化的"留出集",否则你连自己有没有过拟合都判断不了。 Split your evolve set from an OOD set first. Even if you only have one eval set right now, carve out a held-out slice that never participates in evolution — otherwise you can't even tell whether you're overfitting.
- 22 给编辑预算做退火,不要一次性放开。早期允许多处改动(快速探索),后期收紧到单点改动(便于归因、便于回滚)——比"全程固定预算"效果更好也更省。 Anneal your edit budget instead of leaving it wide open throughout. Allow multiple edits early (fast exploration), tighten to single edits late (easier to attribute and roll back) — this beats a fixed budget for the whole run and costs less.
- 33 给"接受"设一个不可协商的噪声地板。先估一下你评测集本身重复跑的方差是多少,再据此定 δ——没有这一步,几乎必然会把噪声当成进步来追。 Set a non-negotiable noise floor for acceptance. First estimate the run-to-run variance of your own eval set, then set δ based on that — skip this step and you will almost certainly end up chasing noise as if it were progress.
- 44 涨分要配得上多花的成本,定期剪枝。给"分数提升"和"成本增加"之间加一个显式的权衡规则;同时定期审查每个组件,没有持续正向贡献的直接删——这两条对应的正是"只加不减"这个最常见的失控模式。 Make score gains justify their cost, and prune on a schedule. Add an explicit trade-off rule between "score improvement" and "cost increase," and periodically audit every component, removing anything without a sustained positive contribution — these two directly counter the most common failure mode of only ever adding, never removing.
- 55 把每次改动的"假设 + 证据"存下来。哪怕是最简陋的一张表(改了什么、为什么改、分数变化、是否采纳),也能防止系统绕圈子反复提出同一个已经被证伪的想法。 Log the "hypothesis + evidence" behind every edit. Even the crudest table (what changed, why, the resulting score delta, whether it was accepted) prevents the system from looping back to re-propose an idea already falsified.
如果你在用 Claude Code 的 skills、subagents 或自定义斜杠命令搭建一套自动迭代的工作流(比如让 Claude 自己审查并改进自己的 CLAUDE.md 或某个 skill 的 prompt),RRSI 的框架直接适用:把你现有的一批真实任务切成 evolve/OOD 两份,每次改动只调一处并记录理由,再用"改动带来的效果提升是否配得上新增的复杂度"去判断要不要保留——这比"感觉这次改得不错"要扎实得多。
If you're using Claude Code's skills, subagents, or custom slash commands to build a self-iterating workflow (say, having Claude review and improve its own CLAUDE.md or a skill's prompt), RRSI's framework applies directly: split your existing pool of real tasks into evolve/OOD sets, change one thing at a time and log why, then decide whether to keep an edit by asking "does the improvement justify the added complexity" — far more solid footing than "this change feels better."
08 · 别急着下结论
08 · Don't Jump to Conclusions
⚠️常见误读与审慎边界Misreadings & Caveats
不对。论文反复强调,可编辑的组件词表(prompt/control_flow/config/context_mgmt/client_tool/skill/memory/subagent)完全没有缩小,RRSI 约束的是搜索轨迹(一次改多少、改完凭什么留下),不是"哪些东西不能碰"。把两者混为一谈,会让你在自己的实现里错误地砍掉本该保留的自由度。
Not true. The paper repeatedly stresses that the editable component vocabulary (prompt/control_flow/config/context_mgmt/client_tool/skill/memory/subagent) is never narrowed — RRSI constrains the search trajectory (how much changes per step, what earns the right to survive), not "what's off-limits." Conflating the two risks stripping out degrees of freedom your own implementation should actually keep.
消融实验里最反直觉的一行恰恰相反:完全不加正则的版本 evolve 集分数最高(92.8),OOD 却最低。evolve 集分数本身不该被当作最终验收标准,只有配合 OOD 表现一起看才有意义。
The most counterintuitive row in the ablation says the opposite: the fully unregularized version has the highest evolve-set score (92.8) yet the lowest OOD score. An evolve-set score alone should never be treated as the final acceptance criterion — it's only meaningful read alongside OOD performance.
Evolve 集普遍是几十到一百多个任务的量级(Terminal-Bench 2.1 89 个、EngDesign 61 个、Harvey LAB 120 个),相比很多工业场景的真实任务池仍偏小;论文也没有给出"跑一次完整 RRSI 进化流程需要多少美元/多少小时"这类可直接用于预算决策的成本数字。把 RRSI 的收益规模直接线性外推到自己规模大得多、任务分布也不同的场景之前,建议先在小范围复现验证。
Evolve sets generally run in the tens to low hundreds of tasks (89 for Terminal-Bench 2.1, 61 for EngDesign, 120 for Harvey LAB) — still modest next to many industrial task pools; the paper also doesn't report dollar/hour cost figures usable directly for budgeting a full RRSI evolution run. Before linearly extrapolating RRSI's reported gains to a much larger, differently-distributed setting of your own, a small-scale reproduction first is the safer move.
09 · 对号入座
09 · Who This Is For
🎯谁该关心这件事Who Should Care
已经在做或计划做"自动优化 Harness/Prompt"流水线的团队,RRSI 的双侧正则化清单几乎可以直接当设计检查表用。
Teams already building, or planning to build, an automated harness/prompt optimization pipeline — RRSI's dual-side regularization list can serve almost directly as a design checklist.
论文对"evolve 集分数上涨但 OOD 崩溃"给出了可量化的诊断方法(ID vs OOD 双轨对比),值得直接搬进自己团队的评测报告模板。
The paper offers a quantifiable diagnostic for "evolve-set score climbs while OOD collapses" (the ID vs OOD dual-track comparison) — worth porting directly into your own team's eval report template.
用 skills、subagents、hooks 搭自动化工作流的人,可以把"退火编辑预算""噪声地板""定期剪枝"这几个概念直接用在自己维护 CLAUDE.md/skill 库的习惯里。
Anyone assembling automated workflows out of skills, subagents, and hooks can directly apply "annealed edit budget," "noise floor," and "scheduled pruning" to how they maintain their own CLAUDE.md or skill library.
如果你只是普通使用一个已经调好的 Agent 产品(不涉及自己搭建/优化 Harness),这篇论文更多是"了解行业在解决什么问题",不需要立刻动手实践。
If you're simply using an already-tuned agent product without building or optimizing a harness yourself, this paper is more "understand what the field is working on" than something to act on immediately.
10 · 继续深入
10 · Go Deeper
🔗学习资源清单Further Reading
- 论文原文 —— arXiv:2609.24972,"RRSI: Regularized Recursive Self-Improvement of Agent Harnesses"(2026-09-21)
- 官方代码仓库 —— GitHub: google-research/rrsi
- 项目主页 —— regularized-rsi.com
- Anthropic 工程博客《Effective harnesses for long-running agents》—— 人工设计 Harness 的最佳实践,可与 RRSI 的自动化视角对照阅读
- Anthropic 工程博客《Effective context engineering for AI agents》—— 上下文管理是 RRSI 可编辑组件词表(context_mgmt)里的一项,可作为背景补充
- 本系列历史深度文档《Agent Harness Engineering:智能体运行时工程》(2026-09-07)—— 从人工设计视角理解 Harness 的基础概念
- Paper — arXiv:2609.24972, "RRSI: Regularized Recursive Self-Improvement of Agent Harnesses" (2026-09-21)
- Official code — GitHub: google-research/rrsi
- Project site — regularized-rsi.com
- Anthropic engineering post, "Effective harnesses for long-running agents" — best practices for hand-designed harnesses, a useful contrast to RRSI's automated view
- Anthropic engineering post, "Effective context engineering for AI agents" — context management is one item (context_mgmt) in RRSI's editable component vocabulary, useful background
- This series' earlier deep dive, "Agent Harness Engineering" (2026-09-07) — foundational concepts of hand-designed harnesses