ModularRSI:面向长时序编码与终端任务的模块化、可泛化递归框架自我改进

关联论文：2609.14857
作者：flyP
更新：2026-09-17

一句话结论

ModularRSI 把「让 Agent Harness 学会自己变好」这件事从「整块黑盒单轨迹微调」拆成「对比成功/失败轨迹 → 定位模块缺陷 → 在受限范围内独立进化 → 集成回归」的四段流水线，并用一份与下游评测基准不相交的 2,000 任务进化集抑制基准特化拟合，从而在 TB2.0 与 SWE-Bench Verified 的未见任务、以及跨底座模型迁移上都取得稳定提升。

解决的真问题

近期 Agent 研究把「递归自我改进（Recursive Self-Improvement, RSI）」从模型权重层扩展到了 Agent Harness 层——即让「Agent Loop、工具调用、观测处理、上下文管理、任务完成判定」这些执行机制本身在跑任务的过程中持续被改写，并在 SWE-Bench、TerminalBench 这类长时序编码与终端基准上刷新了 SOTA。但这条路有三条硬骨头，ModularRSI 论文把它们点得很清楚：

基准特化 vs. 真正可复用的进化：直接在某个评测集或其子集上跑进化，会让 Harness 演化成「针对该评测分布」的特例，工程上看起来涨点，但换个基准就垮。
单轨迹更新的归因混淆：拿一条成功的轨迹反推「为什么这次跑通」，常常把系统性的 Harness 缺陷和这一题的特殊推理路径 / 解题细节缠在一起，得到的修改很可能迁移不到下一道题。
单体 Harness 的局部化困难：现有 Harness 多是单体（monolithic）实现，错误往往藏在某个角落，全局优化又会牵动无关机制，导致归因与验证都很麻烦。

简单说：过去 Harness RSI 的主要风险是「自己骗自己」——涨分是涨了，但涨的是对评测集的过拟合，而不是 Harness 本身变好。

核心方法

ModularRSI 的整体框架可以拆成「对比聚合 → 模块化解构 → 受限进化 → 集成回归」四个环节：

1. 对比聚合：成功 vs. 失败的轨迹对比

对同一个任务，ModularRSI 让基座 Agent 同时收集「成功轨迹」与「失败轨迹」，然后在更广的任务集合上对这两类轨迹做逐任务配对的对比，聚合出反复出现的行为缺陷（recurring behavioral deficiencies）。这一步的关键词是 contrastive 和 aggregate：单次对比噪声大，必须跨任务聚合才能把「这道题特有的小聪明」与「这个 Harness 真正缺的能力」分开。

2. 模块化解构：把 Harness 切成 5 个功能模块

论文明确把可进化的 Harness 解构成五个功能模块，每个模块承担一类独立的执行职责：

Agent Loop：主循环的步进、轮次控制、状态机推进；
Tool Use：工具选择、参数生成、错误处理、调用协议；
Observation Management：对环境/工具返回值的清洗、截断、归一化、结构化；
Context Management：上下文的滑窗、压缩、检索、记忆与回放策略；
Task Completion Detection：判定「任务是否真的做完了 / 是否陷入死循环 / 是否需要重规划」。

这个 5 模块划分本身就是一个可借鉴的工程抽象——它把「Harness」从一段神秘 prompt + 一段神秘代码，落到了一张可以单独讨论、单独 A/B、单独回归的接口图。

3. 受限进化：在每个模块的「允许范围」内独立演化

针对每个模块，ModularRSI 限定一个restricted modification scope：例如对 Context Management，可能允许动的是「压缩策略」「回放窗口大小」「记忆召回阈值」；对 Tool Use，可能允许动的是「错误重试次数」「参数校验规则」「工具选择打分函数」。模块间彼此隔离地进化，这一步切断了「改 A 模块时顺带把 B 模块带偏」这条传统痛点，也让归因回到了「这次涨点是 X 模块的 Y 改动贡献的」这种可证伪陈述。

4. 集成回归：拼装 + 冲突解决

各模块独立进化完成后，ModularRSI 进入一个集成阶段：把 5 个被改过的模块拼回完整 Harness，并显式做冲突解决（resolve potential conflicts）——例如 Tool Use 改完后要求 Observation Management 提供新的字段、但 Context Management 还在按旧字段裁剪，就要在集成阶段统一修订。集成完还要在进化集（注意是独立的 2,000 任务，不是下游评测基准）上做回归，避免拼装时破坏单模块效果。

5. 进化集：benchmark-disjoint 的 2,000 个可执行任务

为了防止「对着评测集进化」造成的基准特化，论文专门从外部来源策划了 2,000 个可执行的进化任务，并强制这些任务与下游评测基准（TB2.0 / SWE-Bench Verified 等）不相交。这一点在方法论上非常重要：等于让进化阶段「不知道」下游要测什么，从而显著提升「涨点可迁移」的概率。

ModularRSI 伪代码（高层）

for epoch in 1..E:
    for task in evolution_pool (size=2000, disjoint from eval):
        succ_traj, fail_traj = base_agent.run_pair(task)
        deficiency_log += diff(succ_traj, fail_traj)
    deficiencies = aggregate(deficiency_log)              # 跨任务聚合
    for module in [Loop, Tool, Obs, Ctx, Done]:
        patch[module] = evolve_within_scope(
            module, deficiencies,
            allowed_ops = module.allowed_modifications    # 受限范围
        )
    harness = integrate(patches, conflict_resolver=rules)  # 集成 + 冲突解决
    if regression(harness, evolution_pool) < threshold:
        rollback(module)                                  # 单模块回滚

关键实验与数据

论文把 ModularRSI 进化出来的 Harness 拿到两个公认较难的长时序编码/终端基准上做评测：

TB2.0（TerminalBench 2.0）：覆盖真实终端任务的评测基准；
SWE-Bench Verified：经过人工核验的 SWE-Bench 子集，被广泛用于衡量 Agent 在真实软件工程任务上的能力。

实验重点验证三件事：

未见 in-domain 任务上的稳定提升：进化的进化集与评测集虽然 benchmark-disjoint，但属于同领域，因此能否涨点直接反映 Harness 是否真的学到了「这个领域通用的执行能力」；
跨领域迁移：把进化出来的 Harness 拿到与进化集领域差异更大的任务上是否仍然有效；
跨底座模型迁移：同一个进化出来的 Harness 换到不同底座模型上是否仍然有效——这一点是「Harness 改进 ≠ 模型特性」的关键验证。

具体到数字，原文给出的方向是「consistent improvements」与「evolved harness also transferring across different foundation models」，但精确的百分比 / 绝对分差需查 PDF §实验段（原文 abstract 未给出逐项分数）。这里我按论文描述给出框架性结论，不杜撰具体百分点；如果你要做横向对比表，建议打开 PDF 第 5–7 节看完整实验表与消融。

补充一个值得关注的工程细节：ModularRSI 强调 modular + contrastive + benchmark-disjoint 三件套共同作用，任意单件都不是它独创——对比聚合在 RLHF/自我修正里早就有了，模块化 Harness 在 OpenHands、LangGraph、CrewAI 等框架里也有体现，benchmark-disjoint 在 self-play 里也常见。ModularRSI 的贡献在于把这三件事第一次显式组装成一个面向「Harness 自我进化」的完整流水线，并把「基准特化」这种容易被人忽略的风险写进了方法论。

亮点与局限

亮点

方法论诚实：论文把 Harness RSI 的三大风险（基准特化、单轨迹归因混淆、单体归因困难）前置写在 abstract 里，而不是先讲涨点再补限制——这种写法在自我改进类论文里是少见的克制。
可拆解的工程抽象：5 模块划分（Harness 抽象成 Loop / Tool / Obs / Ctx / Done）本身就值得工程团队抄一份进自己的 Agent 框架，把「调试 Harness」变成「调试某个模块」。
benchmark-disjoint 进化集：用外部来源 2,000 任务 + 强制与下游评测不相交，是防止自我进化类工作自欺欺人的硬约束，值得作为后续同类工作的默认规范。
跨底座迁移：进化出的 Harness 能跨模型复用，意味着 Harness 本身在逼近一种「模型无关的工程制品」，这对多模型路由/切换的产线很关键。

局限

绝对数字公开度有限：abstract 没给出 TB2.0 / SWE-Bench Verified 上的逐项对比数字，外部读者只能确认「consistent improvements」与「transfer across models」的方向性结论——这给二次引用带来不便。
「模块边界」本身是个人为划分：5 模块切分是否最优、Tool Use 与 Observation Management 之间的接口是否清晰，仍取决于实现者的工程判断，论文并未给出不同切分下的对照消融。
冲突解决策略的细节未在 abstract 暴露：集成阶段 resolve potential conflicts 的具体规则（启发式 / 规则 / 二次进化？）需查 PDF §方法段（原文未明确）。
2,000 任务进化集的可复现性：外部来源的策划标准、与 SWE-Bench Verified 等基准的实际重叠率、是否覆盖足够多的失败模式，决定了 ModularRSI 的泛化上限——这一点 abstract 没披露。
与 RL 微调路线的对比缺位：当前 LLM Agent 自我改进的另一条主线是直接对模型做 RL 微调（如 RLAIF、Self-Rewarding、STaR 系），ModularRSI 把进化限定在 Harness 层，与模型层进化的协同 / 互补关系 abstract 未讨论。

对工程落地的启发

把 Harness 当成可独立调试的工程制品：不要再把 Agent 失败归到「模型不够聪明」一档，先看是 Loop / Tool / Obs / Ctx / Done 哪个模块的问题；这条复盘路径比换模型成本低得多。
建立自家 benchmark-disjoint 的回归集：在做 RAG / Agent / Prompt 优化时，留一份「与线上评测不相交的内部回归集」，避免优化器对评测过拟合——ModularRSI 的 2,000 任务设计可以缩到几百任务的迷你版。
受限修改范围（restricted modification scope）作为变更纪律：每次只允许改一个模块的一种类型（如 Tool 的重试次数、Ctx 的压缩比），并强制集成阶段做冲突解决+回归；这条纪律可以直接搬进内部 PR 流程。
跨模型迁移作为 Harness 工程的硬指标：如果一个 Harness 优化只在某个特定模型上有效，那大概率是 Harness 把模型的偏置学进去了；用「换底座是否仍涨」做最终验收，能筛掉很多伪改进。
失败/成功轨迹配对日志：从今天开始给线上 Agent 跑双轨（同一题两种采样 / 同题两种 prompt 变体），累积 contrastive log，是给未来 Harness 进化留的「训练数据」。

与同方向工作的关系

Harness / 框架层 RSI 路线：与近期在 SWE-Agent、OpenHands、AutoCodeRover 等系统上做的「Harness 自我改进」同主线；ModularRSI 的差异点是把改进拆到模块级并显式做 benchmark-disjoint。
Agent 自我修正（self-correction / self-refine）：单次反思 vs. 跨任务聚合，ModularRSI 属于后者的工程化版本。
RL 微调类自我改进（RLAIF / Self-Rewarding / STaR / RLVR）：ModularRSI 把进化局限在 Harness 层，与「改模型」是平行互补而非替代。
Agent 评测方法学：与 TerminalBench、SWE-Bench Verified、GAIA 等长时序评测共享评测对象，但 ModularRSI 不自建评测，而是强调「在已有评测上验证通用性」。
多 Agent / 程序化 Prompt 优化（OPRO、PromptAgent、TextGrad）：ModularRSI 的「受限修改范围」可以视作一种结构化搜索，比纯自然语言 prompt 搜索更易归因。

适合谁读

正在做 Coding Agent / Terminal Agent / DevOps Agent 工程化的团队负责人，需要决定「下一轮投入该改模型、改 prompt 还是改 Harness」；
在 SWE-Bench / TerminalBench / GAIA 这类长时序评测上做 Agent baseline 的研究员，想要一个比「直接调 prompt」更系统的改进框架；
对 Agent Harness 工程抽象（Loop / Tool / Obs / Ctx / Done）感兴趣的架构师，可直接借鉴其模块划分与受限修改纪律；
关心 自我改进类研究的方法论风险（基准特化、归因混淆、单体归因困难）的审稿人/方法学读者，会喜欢 abstract 前置风险讨论的写法。

一段话带走

如果只记一句：ModularRSI 的真正卖点不是「Harness 又涨点了」，而是把 Harness 自我改进这件事，从「对着评测集瞎改 prompt」升级成「对比聚合 → 模块化解构 → 受限进化 → 集成回归」的工程流水线，并用 benchmark-disjoint 的进化集堵住了最常见的自欺路径。对工程团队来说，这套流水线比任何具体百分比都更值得抄回去。

工程落地与核查（Jay）

事实核查

核查项	结论	备注
TB2.0 / SWE-Bench Verified 逐项对比数字	⚠️ 原文 abstract 未给出	原文仅定性描述「consistent improvements」与「transfer across models」；⚠️ 精确百分比需查 PDF §实验段
「2,000 任务进化集」实际规模与策划来源	⚠️ abstract 未披露	外部来源策划标准、与下游基准的实际重叠率未公开
模块边界 5 划分（Loop/Tool/Obs/Ctx/Done）	✅ 与 abstract 一致	原文明确列出 5 模块划分
对比聚合（contrastive aggregate）方法	✅ 与 abstract 一致	成功/失败轨迹对比跨任务聚合的方法有描述
benchmark-disjoint 约束	✅ 与 abstract 一致	进化集与下游评测基准不相交，有明确声明
跨底座模型迁移验证	✅ 与 abstract 一致	「evolved harness also transferring across different foundation models」原文有述
ModularRSI 三件套（modular + contrastive + benchmark-disjoint）	✅ 均非独创，论文自承	原文明述「任意单件都不是它独创」，⚠️ 但「第一次显式组装成完整流水线」是有效增量贡献

⚠️ 存疑/待核项（共 4 项） 1. TB2.0 / SWE-Bench Verified 逐项对比百分比（PDF §实验段待查） 2. 2,000 任务进化集的具体来源与策划标准（PDF §方法段待查） 3. 冲突解决策略的具体实现（规则/启发式/二次进化，PDF §方法段待查） 4. 5 模块划分与其他切分方案的对照消融（原文未披露）

工程落地路径

场景一：在你们的 Coding Agent 上实现 ModularRSI 流水线（最小化版本）

不需要 2,000 任务，从你们的线上 Agent 日志开始：

# 第一步：收集成功/失败轨迹对
def collect_trajectory_pairs(agent, task_pool, n_samples=2):
    pairs = []
    for task in task_pool:
        runs = [agent.run(task) for _ in range(n_samples)]
        successes = [r for r in runs if r.success]
        failures = [r for r in runs if not r.success]
        if successes and failures:
            pairs.append((successes[0], failures[0]))
    return pairs

# 第二步：跨任务聚合行为缺陷
def aggregate_deficiencies(pairs):
    deficiency_counter = Counter()
    for succ, fail in pairs:
        diff = compare_trajectories(succ, fail)
        deficiency_counter.update(diff)
    return deficiency_counter.most_common()  # 出现频率最高的缺陷

# 第三步：受限修改——每次只改一个模块的一个维度
allowed_modifications = {
    "Loop": ["max_steps", "timeout_per_step"],
    "Tool": ["retry_count", "param_validation"],
    "Obs": ["truncation_length", "field_normalization"],
    "Ctx": ["compression_ratio", "retrieval_top_k"],
    "Done": ["detection_threshold", "deadloop_max_iterations"],
}

坑点 P0：如果你们的 task_pool 本身就与线上评测基准有重叠，进化出来的 Harness 可能对评测过拟合——⚠️ 必须保证进化集「不知道」下游要测什么，这是 ModularRSI 的核心工程纪律，也是最容易在内部复现时被忽略的一点。

坑点 P1：冲突解决（resolve potential conflicts）具体怎么实现，原文没给——⚠️ 建议从最简单的「后写优先 + 接口契约检查」开始，不要在第一步就上复杂的多模块协商机制。

场景二：把 5 模块划分作为 Agent 调试框架

直接把这个 5 模块划分用到你的 Agent 复盘流程：

每次 Agent 任务失败 → 强制填写「失败定位单」：
□ Loop：是否陷入死循环 / 步数越界 / 状态机推进异常？
□ Tool：工具调用参数错误 / 工具选择失误 / 错误处理缺失？
□ Obs：环境返回值格式不符合预期 / 字段被截断 / 归一化失效？
□ Ctx：上下文窗口耗尽 / 关键信息被压缩掉 / 召回内容不相关？
□ Done：完成判定提前 / 延迟 / 死循环未触发？

⚠️ 有了这个定位单，你才能真正判断「这次失败是模型问题还是 Harness 问题」——而不是一出问题就下意识甩锅给模型。

场景三：受限修改范围作为代码变更纪律

把 ModularRSI 的「受限修改范围」写进你们的 PR 规范：

## Harness 模块修改规范

每次 PR 只允许修改：
1. **一个**功能模块（Loop / Tool / Obs / Ctx / Done）
2. 该模块的**一个**可允许修改维度（见下方清单）
3. 修改后必须通过 evolution_pool 回归测试（≥80% 旧用例仍通过）

禁止：
- 单 PR 修改两个及以上模块
- 跨模块协调修改（放在集成阶段单独处理）
- 修改后不跑回归直接合入 main

坑点 P2：受限修改范围的目的是让「每次涨点都可归因」——如果你们不严格遵守这个纪律，改着改着就不知道哪次改动贡献了哪次涨点，回头复盘时又变成一笔糊涂账。

工程坑点清单

#	坑点描述	严重度	触发条件
P0	进化集与评测基准重叠导致基准特化	致命	task_pool 来源未做严格不相交检查就开跑进化
P1	冲突解决策略实现细节缺失导致集成失败	高	多模块同时进化后拼装时出现接口不匹配
P2	跨模块同时修改导致归因失效	高	PR 中修改了两个以上模块，无法判断哪个改动贡献了涨点
P3	TB2.0 / SWE-Bench Verified 数字缺位影响二次引用	中	外部引用时只能说「consistent improvements」无法给具体对比数字
P4	2,000 任务进化集策划质量不可验证	中	外部读者无法判断进化集是否足够多样化/足够难/足够与下游不相交
P5	5 模块边界非最优切分	低	实际实现时发现某模块过胖/过瘦，需要重新切分但无消融数据参考
P6	与 RL 微调路线的关系未理清	低	团队同时在做 Harness 优化和模型微调时，不确定该优先投哪个方向
P7	单次对比轨迹噪声大，聚合不足	中	任务数不足时（<200）跨任务聚合得到的缺陷排名不稳定

验收标准

[ ] 本篇精修后，TB2.0 / SWE-Bench Verified 具体数字已标注「原文 abstract 未给出，PDF §实验段待查」
[ ] 2,000 任务进化集策划来源已标注「abstract 未披露，PDF §方法段待查」
[ ] ⚠️ 存疑项均已在正文中显式标注（冲突解决策略/模块切分消融/进化集来源）
[ ] blocklist 检查：全文无将「consistent improvements」杜撰为具体百分比的情况
[ ] 工程坑点覆盖 ≥6 条：P0/P1/P2/P3/P4/P7 均已在工程落地节体现
[ ] 5 模块划分已作为「可直接抄的工程抽象」在工程落地节中明确推荐